Category Archives: Successes

Mk III Takes Shape

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
  • new thrusters
  • 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.

Open Beam, acrylic, and Mega
Open Beam, acrylic, and Mega

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.

New Mount for the SUP 500 GPS Module
New Mount for the SUP 500 GPS Module

Motor Calibration and Completed Python Remote

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.

Counter Closeup

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.

Offline Calibrator

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).

Online Calibrator

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…

Going Multi-lingual, Multi-OS

Long post – snacks are suggested…

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. 

On the PC side, lots of options exist for software (including a hardware cheat of connecting an XBee through an Arduino Uno to handle serial communications), but ultimately Python made the most sense.   Using Python 3.3 was made possible by Chris Liechti’s excellent set of libraries for serial communication (pySerial) and a similarly excellent library collection for XBee communication by Paul Malmsten.

This means that the PC side hardware can be reduced to this:

USB SparkFun XBee Adapter

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):

diags and commands
Diagnostics and comms

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:

Python Tkinter controller prototype

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.

Broken Propellers and Trial by Ordeal

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:

Tank 1
High-Tech Displacement Tank 1

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.

tank 2
High-Tech Displacement Tank 2

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.

Tank 3
Post-dunking recovery

Key findings:

  • 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…

TinyGPS++ to the Rescue

Thanks to the brains behind Arduiniana, Mikal Hart, Poolbot has moved to the brand-new GPS library set, TinyGPS++.  This saved enormous time in developing custom code to process and check the validity of NMEA codes.  Here’s a screenshot of Poolbot’s latest drydock test program, using TinyGPS++ grabbing data indoors (hence the improbable rate of movement):

Latest Poolbot software output

(Mikal Hart is also apparently a RockBLOCK fan and thanks to his efforts, yes, there’s a library for that)

Once some more stringent validity checks are in-place, Poolbot will move onto the next stage… as detailed in the next post.

GPS, in the library, with a hammer

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):

SkyTraq Reporting from PoolBot

The ST22/SUP500F is a fairly popular module, as a fellow hacker points out.

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!).

Poolbot improvements
Sensors and Poolbot

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”:

Poolbot reporting
Poolbot reporting

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

Slow and steady wins the race…


Voyage to the Bottom of the Pool

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.

Key learning:

  • 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)

(link to MP4 of Test #4)

(link to MP4 of Test #5)

(link to MP4 of Test #6)

Post-mission lurking