Poolbot is evolving. The original prototype successfully floated and dove, while the addition of the ComPod credibly turned it into Poolbot Mk II.
Mk III is now taking shape.
The technical details for the Mk III will be posted soon. However, the basics design involves the same core electronics as before plus new physical features:
separate compartments for the thruster batteries
solar panel mounts
solid frame for the electronics
hollow posts for communications antennas and the GPS module
The last two can be seen below. Thanks to Open Beam, some standoffs and a sheet of acrylic, the electronics will have a solid mounting and cleaner wiring. The Mega and two separate dummy shields should suffice to connect everything.
Using a blank perfboard, PVC, epoxy, a plastic I-beam, and a Dremel, a pretty smart-looking GPS post has taken shape. The SUP 500 was removed from its old shield and soldered directly, with backup battery, to the perfboard. Tested with SkyTraq, it works like a champ.
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…
The initial motor tests of Poolbot in the pool used an Arduino Uno R3 and the motor shield, and not much else. The program waited two minutes after the batteries were connected to start the motors in a timed pattern. No sensors, no I/O, no intelligence.
In order to accommodate additional sensors and features, moving to the Arduino Mega 2560 R3 was needed. However, the first obstacle was getting the original motor program to work with the new hardware — on first attempt with the Mega, only one motor worked. Some research and code updates got the Mega to work with the motors.
The next step was to integrate some new components, specifically:
The latter two were tied into Poolbot and its software without a hitch. Using two of the Mega’s four hardware serial ports enabled direct, fast connections of the XBee and the GPS shield. While the XBee took some adjustment, it functions. The GPS shield, however, was flaky in the extreme. Satellites wouldn’t lock, and data would arrive corrupted.
As it turns out, the GPS shield is physically fine. After some research, it turns out that the shield’s GPS module, a SkyTraq ST22, has its own nifty configuration software, which can be used with an Arduino Mega configured to echo between serial ports. Using this showed the Dexter module worked great – the libraries just didn’t function reliably.
Most GPS modules write out information using simple ASCII strings called NMEA codes. Thanks to a simple program from perceptive coder “Muthanna”, the Mega was able to read incoming GPS data and write it to a laptop screen using a local USB serial port; even when the ComPod was sealed up, Poolbot could even write directly to the SkyTraq viewer software through the USB serial port (some of the GPS information has been blacked out, to avoid revealing the Secret Location of Poolbot’s Development Cabana):
After writing custom code to pick off the GPS NMEA codes, Poolbot can now (at least on dry land):
report its RTC date and time settings
establish a serial link with a nearby XBee
read GPS data, including date, time, location, and heading
read and report internal temperature and humidity information
All this is done through a direct USB link, so in-water testing of all this isn’t yet possible. The Mega, along with attached sensors, exposed ComPod “guts”, and the separate XBee receiver, is shown below (note the green light showing an active link and receiver signal strength on the XBee labeled “2”; this is connected to a USB cellular charger – no controls here!).
Note that ComPod has been moved (more on that in an upcoming post). Thanks to the SkyTraq software, the GPS module has been configured for “boat” mode, and updates every second.
And here the serial data reported back through the Poolbot USB connection can be seen; all this text is being generated by the Arduino Mega 2560 on-board custom code, developed here at the Poolbot drydock, based on what Poolbot’s sensors report. The PC is simply a “dumb terminal”:
The GPS doesn’t always report the full set of NMEA codes, due to some faulty string parsing. This will be fixed shortly. The other sensors work just fine (the XBee sometimes takes a few seconds to respond, but the code now has a built-in retry mechanism).
The next steps are:
Enable reporting of this status data through the remote XBee receiver rather than Poolbot “local” USB
Post-process the GPS NMEA codes, checking for signal stability before reporting
Reduce the data reported via XBee, and use local Processing code to expand compressed data from Poolbot
Increase the serial port speeds
Seal everything up and run some water tests, including dives