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.
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.
Bad choices all around…
One minor and one major update…
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.
Here is a close-up image of the Poolbot main control board, using the Arduino Mega 2560 R3. The Adafruit Motor/Stepper/Servo shield is mounted on top, while individual wires connect to the motors, batteries, and ComPod. The DFRobot “wings” from the Arduino Uno R3 came in handy for making these connections.
The motor batteries are not connected in this picture.
The small blue rectangle in the center is the DHT11 temperature/humidity sensor. This, plus a few capacitors, is mounted to a breadboard, and can indicate whether Poolbot overheats or encounters a severe-but-not-catastrophic leak.
Yes, that’s a rubber band on the right-hand side. It’s called a “prototype” for a reason.
As the current revisions to Poolbot have turned into exclusively software problems — the hardware engineer’s kryptonite — pause to consider the Poolbot design features. If all are included, Poolbot will be an extremely flexible platform for all sorts of long-range surface and sub-surface operations: mapping, inspection, support of divers… “the deep’s the limit.”
The list below shows both the implemented items (in black) and the unimplemented ones (in red), grouped by category. Features are listed only once, even if they could credibly be associated with more than one category.
A few notes:
- RockBLOCK – the minds at FishPi found this, a small, inexpensive, Arduino-compatible module for SMS communications through the Iridium satellite network. It appears to carry its own GPS, so using it would enable removing the current GPS module.
- AIS – the Automatic Identification System is a vessel-tracking network based on VHF, satellites, and GPS, to enable collision avoidance and traffic monitoring. A unique ID on each vessel enables reporting of vessel position, ports of call, type, and other useful information. Several sites show AIS information free of charge to the public, including MarineTraffic.com. Again, the integrated GPS means that the current Poolbot antenna can be removed.
These two toys will be the most expensive items, assuming that second-hand AIS units are still available (and programmable).
The 3-axis accelerometer has been purchased and tested with an Arduino Uno, but has not yet been integrated into Poolbot. The full report on how the GPS, XBee, Mega, temperature sensor, and motor control work together will have to wait until the next post.
The last three days have been spent making fairly drastic hardware and software alterations to Poolbot. The next post will cover the software and electronics issues; for now, consider the new addition to the Poolbot structure: the ComPod.
The main body of Poolbot will contain four (4) 4.5 Ah 6 V batteries. There just isn’t room anymore for all of the electronics plus the power systems. More importantly, Poolbot’s main body hangs under the floats at the water’s surface. Putting the XBee even slightly under the water makes it impossible to communicate (and, to respond to a perceptive reader’s comment, fitting an external antenna will likely be needed anyway for the long-distance XBee Pro later, but the logistics of getting the antenna properly sealed are too much to handle at the moment).
Hence, ComPod, a smaller sealed PVC pipe containing the XBee and GPS shields, has been connected to Poolbot’s main body by an Ethernet cable sealed with the now-ubiquitous composite wine bottle cork.
Here’s the first iteration of Poolbot with the ComPod in-place on the workshop table (yes, that’s EconTalk playing on the Ubuntu machine in the background).
The first image also shows the solar panel which will eventually be fitted in an acrylic case on Poolbot’s top.
Sadly, this design badly compromises Poolbot’s buoyancy, which will be covered in a future post…