A lot of these terms came to mind when staring at the current state of Poolbot, and imagining trying to get it to cross a body of water larger than… well, a pool. The most recent problems with getting long-range communications equipment mounted just compounded the negativity.
Then, an epiphany: why not have Poolbot carriedby some other vehicle. It could be simply dropped into position by a surface “carrier”, which needn’t submerge. All the GPS, communications, solar charging, etc. equipment can be kept on the carrier, which would be more visible and more stable, with much more reliable communications.
Having seen recent stories on the late, engineer-lamented Lockheed-designed US Navy experimental ship, Sea Shadow (IX-529, torn up for scrap in 2012), using a SWATH design for the carrier makes good sense. Poolbot could be suspended under the main hull during surface transport, above the waterline.
Nevertheless, despite a total lack of originality, a SWATH-based carrier for Poolbot is the new plan. The NATO ASV design does not cover certain key details about deploying and recovering its AUV. Nor are charging and comms covered. To that end, here are a few specifics for Poolbot’s carrier:
solar panels mounted to the top and sides
“claw” under main hull for Poolbot, to keep AUV above the surface during transport
GPS, XBee, cellular antennas on carrier hull
at least one main-hull-mounted camera
batteries in main hull body
wireless communication (XBee) only with Poolbot – no wires for data!
wireless charging, if possible, for Poolbot (inductive charging pad under claw?)
All of this should allow both Poolbot and the carrier to carry out operations autonomously, indefinitely, without having to be opened up for anything other than serious drydock maintenance. Even better, almost all of the original Poolbot plans and code can be kept unchanged.
Technical details are sketchy in the article (what exactly are “sustainable optic sensors”?), but the use of Iridium satellite communications is confirmation that it’s a viable approach for long-range control.
After some weeks of hefty programming (and after being interrupted by having to return to a regular non-robot-related work schedule), a few successes can be noted:
Poolbot’s control language now includes status reporting
XBee signal strength is back to normal, after re-soldering the antenna to the right contacts this time
A Python remote control is now working and can be used to actually drive the robot
A motor calibration jig has been built to determine settings vs. actual speeds on each motor
Why calibrate the motors? Because Poolbot relies on libraries that set motor speed to a value between 0 and 255 (and Poolbot’s language sets that to a percentage), and “127” on the left motor may not give the same speed as “127” on any other motor. Waxy buildup and motor variations make the speeds hard to predict.
(the port size float has been removed above, to accommodate the calibration sensor)
The calibration jig simply combines a stopwatch function and a button with an interrupt-based counter. The interrupt is tripped by a somewhat expensive Omron reflective sensor. When the propeller passes in front of the sensor (with a white backing taped in-place), it trips and interrupt and adds to the counter. If the clock is running, RPM values are automatically calculated and displayed.
And the controller? It reports GPS location, signal strength (in dB), current Poolbot mode, and last command sent. Buttons set whether to enable a particular motor and the direction to use. Four sliders set the actual speed of each motor, from 0 to 100. All of this is handled through the XBee link, in real time. Put the ‘bot in the water, and you can drive it “digitally” until the signal strength goes to zero.
There are actually two controllers, as having sliders for the drive motors is pointless in the water (if the ‘bot makes it below the surface, GPS and XBee signals will be lost, which will translate into a lost robot).
All told, the project now features ~1000 lines of C code on Poolbot itself, plus ~300 in the Python remote. It’s more than likely these can be reduced by careful use of functions, but that can wait.
Next steps: water test, move to a larger central tube, add new ballast controls, and upgrade the XBees to a longer range using a real external antenna…
A depth sensor has arrived: a Measurement Specialties 5541C, which should be good to 14 bar (at least 450 feet of depth). It’s quite simple, featuring 8 solder points, of which only 6 are needed for normal operation.
It uses the Serial Peripheral Interface, though not by name (the documentation merely mentions a “three-wire interface”). However, a little research shows that removing the device select wire from standard 4-wire SPI gives you the same connections as the sensor uses. Like the camera (next post), the sensor operates with a lower supply voltage than the Arduino, so level-shifting is needed.
This should be relatively easy. Here’s the hard part:
Mounting it to a PCB with some sort of 6-pin connector is going to be a major challenge.
Hardware development has been suspended for some time while some fundamental software improvements are made. In an earlier post, a plan was shown to use an XBee connected to a PC to control Poolbot in remote mode. This required some serious software changes, but hard work pays off. The following features have now been implemented in the Arduino Mega 2560 R3 software inside Poolbot:
diagnostic checks of all sensors and electronics (except the motor shield), with timeouts, have been moved into the setup() function
reporting of diagnostics over hardware serial (usually over USB to a PC in drydock)
XBee communications with the base station include signal strength reporting and confirmation of successful receipt
(biggest of all) motor speed and direction are now controlled remotely; no more pre-programmed paths
The great XBee libraries for Arduino from Andrew Rapp enables transmission and reception of simple text string “payloads” (100 bytes each), taking care of the details of checksums and packet assembly between Poolbot and a base station. Each payload can be used to carry commands, data requests, and the like. To do this, Poolbot needed its own custom control protocol, so that the base station could command the motors to do something, or request sensor status, or even change operating state. The format for the protocol was blatantly ripped off from lovingly constructed in homage to NMEA codes used for the GPS. The format is comma-separated and looks like:
$M<2-character motor ID>,<motor speed percentage>,<direction>
So, to tell the right dive motor to spin backwards at 60% of maximum speed, the command would be:
Using comma separators permits using strtok to token-ize the command string. The compact format also allows Poolbot to communicate without violating the 100-byte XBee data payload limit. “P” is used in the second position to indicate propulsion motors, while “L” would indicate the left motor, and “F” indicates forward. “$MAS” instructs all motors to stop.
In future, sensor status can be reported with a “$Sxx” structure, but other non-motor commands are possible. The only limit to the language is the Mega’s storage. The entire program is about 23 kB in size, which is 2/3 of the maximum supported by an Uno, but still pretty small for a Mega.
This means that the PC side hardware can be reduced to this:
This also means that a Linux box, or even a Raspberry Pi, could be used as the Poolbot base station (think battery-operated!) – multiple operating systems are now supported. The Python program is somewhat simple at present, featuring a simple set of pre-programmed commands, but it does respond to user input and reports XBee status and received signal strength.
How does it all look working together? Check out the results on a single 32-bit Microsoft Windows XP laptop, with Poolbot in drydock on COM5 (left side), and the Python input/output from the control XBee on COM4 (right side):
The commands are pretty obvious from the screen shot. Further, the frame ID tracking ensures that commands aren’t accidentally missed. The programs both wait for interaction, so Poolbot can be left on and waiting indefinitely – no more rushing to seal up the ‘bot before the motors click on. And, yes, the correct motors turned off and on when expected.
The hardest part of all of this was, believe it or not, getting strings vs. bytes sorted out correctly in both Python and Arduino’s flavor of C.
Future enhancements will include:
adding sensor $S reporting to the Poolbot language
fixing the XBee signal strength (yes, it’s really on the order of -80 dBm, even though the two XBees were only a few feet apart; this is likely due to bad soldering during recent repairs)
a control GUI…
That last one is the real reason for using Python – the tkinter binding/toolkit allows cross-platform graphical displays and controls. This means that the command language can be abstracted away in favor of buttons, dials, text boxes, and pretty LED-like lights where appropriate. Here’s the first crude attempt:
At the very least, the speed adjustments shown will allow motor calibration without permanently adding encoders to each motor.
Three languages, multi-OS support, and a new GUI – not bad for five days’ work.
Selecting batteries or even solidifying the electronics means figuring out the maximum dimensions of any given rectangular shape that will still fit within the tube. If only the diameter is limited, then a variety of rectangles may fit. Time to pull out some geometry…
Thanks to a particularly good website for batteries, a complete set of dimensions for a variety of batteries is available. The equation above can show whether a particular battery will fit in the tube or not, based on its width and length (assuming “depth” extends along the tube’s axis). Performing some calculations with the existing central tube, electronics and two batteries, some options emerge:
using an alternative 12 V battery, at 3.8 Ah, measuring 7.6″ x. 2.8″ x 1.85″
stacking the electronics within a 5″ x 2.25″ area gives 2.68″ of available height for both the electronics and ballast (not much, but usable)
Motor load measurements are still needed to confirm that 3.8 Ah is sufficient for propulsion. The Arduino Mega and Motor Shield fit within an area 5″ x 2.25″, but the connectors and DHT11 sensor need to be cleverly stacked on top. And 2.5 lbs of ballast needs to fit under the electronics within about 2.28″ of space, total.
It’s either this or recalculating displacement using a longer tube, plus actually building it.
What’s Poolbot’s maximum operating time in-water before needing to recharge?
The motors are tied to two (2) 6 V, 4.5 Ah batteries. It would be convenient to use the same kind of supply for the electronics, but it depends on the current drawn. For the electronics alone (not the motors), a quick set of measurements reveals some unfortunate numbers:
the Arduino Mega 2560 R3 alone draws a reasonable 70 mA, which would allow at least 70 hours of operation (assuming correct reading of the capacity charts) before needing a recharge
the GPS and XBee (1 mW) draw only about 7 mA
the current draw by the motor shield is a less reasonable 200 mA
At 277 mA, Poolbot will need a recharge after only about 17 hours of operation. It’s also not known how long the 12 V solar panel will take to recharge the battery packs. If it takes more than 7 hours, or if there’s less than full sunlight, Poolbot may need significant “basking”/sleeping time between operations. This assumes that the electronics can be effectively turned off, and doesn’t even count needing to charge the motor batteries. What happens if Poolbot drifts while charging?
There’s another issue. There’s no room left inside Poolbot for all the new electronics, ballast, and four 6 V batteries. With two batteries for the motors, at 1.75 lbs of weight per battery, about 6.5 lbs of ballast and electronics battery weight remains to maintain Poolbot’s neutral buoyancy (see previous post).
Using a single 6 V battery to power the Arduino Mega and its accompanying electronics is a bad idea; below 7 V, the Arduino’s on-board regulator won’t work well and operation will become unstable. So, either a single 12 V battery with the right dimensions and similar Ah figure must be used (good luck) or some significant filtering must be used on a single supply for both the motors and the electronics.
The minor update: a recent pool test showed Poolbot making only starboard turns; this turned out to be due to a broken starboard propeller.
The more significant issue involves ballast.
Both the ComPod and the main body of Poolbot were recently analyzed for displacement and overall ballast neededto dive. Recall that ComPod has to protrude from the water at least partially in order to allow the XBee inside to communicate with the shore.
Previous displacement checks were done on Poolbot alone, less to get an actual displacement number and more simply to visually check buoyancy, and adjust trim and freeboard in the water. The ComPod was tested for actual displacement in the kitchen at least once, but using some dificult and questionable methods. To get a better number, the following extremely high-tech test bed was assembled:
The hard plastic bowl is filled to just before overflowing. The softer plastic bin will catch the water displaced by the ComPod once it’s inserted into the bowl. Measure the water in the bin to get displacement.
This measurement went exceptionally well, and resulted in a displacement within about 12 mL of the previous ComPod checks. The final numbers:
ComPod’s volume (displacement): approximately 1470 mL
ComPod’s weight: 549 g (including internal electronics)
For neutral buoyancy, the item weight must equal the weight of the volume of water displaced. As 1 kg of fresh water = 1 L of fresh water (pretty clever that metric system is), ComPod’s required ballast is… 921 g, or 2 lbs, 0.5 oz.
To measure Poolbot’s displacement, aside from the ComPod, is harder. Poolbot is rather large, requiring a tank at least 25 inches (sorry metric system) long and 11 inches wide, with about the same depth. Any catch basin must be larger still, to accommodate the overflow without losing any.
Thanks to several smaller bins, four plastic bags, and some tape, a reasonable up-scaled version of the previous dunk tank was created; there’s just enough clearance to allow water to overflow straight down into the smaller bins. The flaw in this design will be obvious from this post-dunking picture.
Use a rigid container, if possible, for the actual dunking. The soft plastic deformed enough to raise concerns about accuracy. The strap shown above is wrapped around the bin and several pieces of acrylic plastic and plywood, to make the sides more stable. The risk is that the plastic will deform, rather than water overflow, when the object is dunked.
Poolbot floats, so is obviously guilty of witchcraft.
Here are the numbers, +/- 100 mL or so for water loss and bin expansion:
Poolbot’s volume (displacement, without ComPod): 8050 mL
Poolbot’s weight (without ComPod or batteries): 3.6 kg
This means that Poolbot’s ballast must be 4.45 kg, or 9.82 lbs, to compensate for buoyancy. This number includes all of its current electronics, but does not include batteries.
The challenges that remain:
Can the ComPod be kept sufficiently above the waterline to transmit and receive messages? Or is it time for the extended antenna?
If ComPod protrudes enough for XBee communications, are the motors powerful enough to allow for diving without dive planes or some sort of ballast compensation system?
Unfortunately, there’s a third problem lurking, which will be addressed in the next post…
The latest Poolbot program updates have enabled XBee transmission of arbitrary strings up to the 100 byte payload limit. In drydock, the Arduino is connected via USB to a PC, used as a “dumb terminal”; the Arduino is doing all the display work, and the XBees operate in a simple loop confirming that a communications link exists.
The next steps are to move all the serial link data processing from the Arduino Mega 2560 to a PC. The Arduino can then transmit compressed sensor data via XBee payloads, and let the PC locally decompress the payload and print the information in a human-readable format. Remote control of the motors becomes possible.
Pictures sometimes explain better than words, so here’s the design today, and what’s planned for the future.