Regular readers (both of you) will have noticed that the video formats and styles change regularly. This is due to issues with getting the video links to play across devices and operating systems. Right now, videos are posted in both FLV and MP4 format, but Android and iOS devices appear to have some difficulty displaying the MP4 files automatically. Until this is fixed, separate links to the MP4 files will be provided along with the FLVs.
The good news: API communications between two XBees can be relatively easily set up using an Arduino and the appropriate libraries.
The bad news: 2.4 GHz XBee frequencies don’t travel even six inches through fresh water. It’s microwave – this should have been obvious.
The latest test involved using the Arduino XBee libraries available as open-source code, and battery-powered XBee units, with one placed in Poolbot. A modified example program would transmit regular ASCII “payloads” from inside Poolbot from one XBee; the other was connected to a Sparkfun XBee Explorer USB (plugged directly into an AC wall socket) with an RSSI LED to indicate a working data link.
Sure enough, there was no problem maintaining a data link when Poolbot was sealed with an Arduino-controlled XBee inside on dry land. But put it into the water and the link died immediately and repeatedly, even though the water was only about six inches deep.
To fix this, the next move is to mount the XBee inside a sealed external box on top of a small PVC pipe connected to Poolbot that will stay above the waterline until diving is needed. Otherwise, remote mode operations are pretty much impossible.
In related news, 60 mW XBees allow up to 1 mile of separation between modules…
Poolbot’s current program relies on a simple timer before operations start; this allows about 2 minutes to get the back end of the PVC pipe sealed, Poolbot in the water, and all ballast balanced correctly before the motors turn on. This is a bit annoying.
Poolbot’s eventual “Remote” mode will be using XBee® 802.15.4 transceivers from Digi International (these are also called Series 1 transceivers) to communicate with a very nearby shore (or ship) station, to bring Poolbot home before entering drydock. In the short term, though, using the XBees would be really handy for just plain turning on Poolbot test modes.
Using code from the Arduino Cookbook (2nd ed.) by Michael Margolis plus advice from the web, XBee testing is going on right now. An Arduino Mega and a Sainsmart XBee shield are inside Poolbot right now, downstairs in the family room. The Arduino has a simple loopback program running to echo data back. The other XBee is hooked up to the upstairs office PC, transmitting test packets. Throughput at 19200 baud is about 94%, which is pretty good considering the amount of interference and solid walls involved.
If you like code, here is the Poolbot rev. 5 test code used for the operations shown in the earlier videos. This was written for the Arduino Uno R3, compiled under Arduino 1.03, and uses the Adafruit Motor/Stepper/Servo v. 1.0 shield. Some additional libraries are needed to make the entire thing work. The code is posted as a text file; copy/paste into the Arduino development environment to compile and upload. Enjoy!
Today saw not one, not two, but three successful test runs (out of five attempts) for Poolbot to operate at the surface and dive. The two other runs are deemed less than successful simply because Poolbot didn’t actually dive.
Buoyancy adjustment is absolutely critical. The three successful runs occurred only because Poolbot was nearly perfectly weighted with four (4) batteries, four (4) external pounds of lead weight and two (2) pounds, 5.7 ounces of internal weight. The floats provide stability and just barely break the surface when everything is ideally weighted.
The composite cork solution needs sealing, but is working nearly perfectly. The final three tests were conducted without any attempt to drain Poolbot.
Motor repairs are holding up well, though some speed calibration is needed.
Code for the test program will be posted separately.
Because “video, or it didn’t happen”, the first two videos were shot using a fixed tripod, so operations far away from the camera are hard to see. The third video was shot hand-held, which makes maneuvering harder to perceive, but diving and surfacing easier to see.
(due to file sizes, the videos may take a moment to load)
An administrative note: some may have observed that comments and registration were not working properly. This is apparently a side-effect of the use of a domain pointer; while the problem is being fixed in the longer term, you should be able to register and comment freely now. Sorry for any inconvenience.
As the physical prototype winds down, other design aspects move into more serious development. These include XBee-based controls, depth sensing, ballast controls, GPS location-finding, etc. Tying these all together is the state machine, grouping everything that Poolbot will do and providing a framework for programming. Here’s version 1:
The format is somewhat non-standard, in order to make the diagram more readable and useful. The arrow directions and connections show from which state each other state is entered, and what options are available. The central state, “Drydock”, is assumed to be the starting point out of reset. The states may be described as follows:
Charge: daytime-only “hover” mode, to charge Poolbot’s batteries using a solar panel while avoiding obstacles and drifting
Drydock: for testing and transition in and out of the water; navigation is off, as are most obstacle sensors
Remote: assumed at the surface, within line-of-sight of XBee transceiver; for manual control to get Poolbot out of the water or to transfer small amounts of data
Surface: for navigation to “station”; assumed to be at night; navigation, lighting, and obstacle avoidance most active here
Sub-surface: diving operations; depth sensors, lighting, cameras and obstacle avoidance in 3D required, but GPS is off; can only get here from “Surface”
Panic: the all-purpose emergency state; in case of catastrophic damage, leaks, or other failure where autonomous recovery isn’t possible but the electronics are operational, automatic light beacons are activated and ballast is ditched
Note that any state can lead to “Panic”, and “Panic” is pretty close to fatal – if it occurs, recovery to “Remote” or “Drydock” are the only options allowed. If the beacons are on a separate power supply and the structure is (mostly) intact, then someone may find Poolbot on the open seas, scoop it up, and figure out where it came from.
Time to put an address and “Return Postage Guaranteed” on the outside.
Motors have been repaired and some slight changes have been made to the Arduino Uno test program. Before testing can continue, Poolbot’s “nasal drip” problem has to be addressed.
The main body of Poolbot is a 24″ long, 4″ (ID) black ABS pipe. At each end, a specialty Rectorseal Tom-Kap adapter has been glued into position with marine sealant. The flush caps that actually cover the pipe ends don’t leak when properly wrapped with plumber’s Teflon tape. However…
… one of the end caps has a large hole in it, at Poolbot’s nose, to allow the eight motor wires into the pipe. Covering the hole and wires with gobs of marine sealant just didn’t do the job and fairly significant amounts of water ended up inside the ‘bot on every test.
The next solution was to attempt liquid electrical tape. This reduced the leak, but didn’t eliminate it, and stresses on the wires from remounting the screw cap didn’t help.
What’s really needed is a gasket for each wire, but these can be expensive and sizing can be a problem. Staring at things in the kitchen, the solution appeared in a bottle of wine – literally. The composite cork is remarkably flexible, so could be put through a 3/4″ diameter hole in the end cap, but is solid enough to grip wires run through it.
After 10 minutes of manually twisting a small drill bit eight times through a cork, plus more time drilling a hole very precisely through the end cap, a quick couple of tests showed no leakage. Filling a wine bottle with water and inverting it showed no leaks, and a dunking of an open-ended Poolbot with a non-composite cork only showed droplets where the corkscrew had emerged.
With motors (almost) completely repaired, Poolbot made its first successful foray into the water with electronics yesterday. The simple program on the Arduino Uno was designed to show motors working separately and together in both directions, under battery power. The video below shows the results.
The starboard motor still “sticks”, though it does turn with help. Additional work is needed there.
Poolbot can’t dive with its dive motors alone. The modern military submarine is designed correctly – the machine should “drive to dive” by keeping both the propulsion motors going while the dive motors are on as well (Poolbot’s dive motors substitute for adjustable ballast and/or dive planes).
Poolbot leaks. This wasn’t fatal, but it was disappointing.
Poolbot’s initial ballast and weighting calculations were completely wrong. No exterior weights were needed once the fourth “dummy” battery was added inside.