Tag Archives: design

State of the Machine

After some non-robot delays (got to pay the bills), intellectual work resumes.  Here is a top-level state machine for Nematon, showing the various modes of operation.  Driving around occurs during “Surface” mode, while diving operations happen during “Dive” mode.  “Remote” mode is intended for real-time control, akin to an RC car or airplane.

More software planning updates to come…

PDF Version:  nematon-state-machine-july2015

State Machine
State Machine Diagram


Formal Documentation

The Federal Communications Commission recently sent two letters indicating that the celebrations regarding Nematon I receiving an official ship station license were premature (the letters will be posted shortly).  The license has been withdrawn until further data can be provided.

In response to the FCC’s requests for additional information, the enclosed report was prepared.  It includes some of the Sketchup drawings mentioned in the last post, reference listings of the sources of various components, plus an extended (amateur) analysis of the regulatory status of watercraft like Nematon I.



Getting Serious About Mk III Design

Due to a documentation requirement (which will be explained in the next post), some detailed drawings of Nematon I had to be generated in a hurry.

Using Sketchup and its associated Engineering Toolbox, a pretty detailed drawing in 3D was created.  A couple of images are shown below.  Some work is underway to embed a 3D image in this site for viewing, but until that’s done, these will have to do.

Note the exploded XBee antenna, courtesy of ERobishaw on 3D Warehouse.


Nematon I Front View
Nematon I Front View
Nematon I Left View


Cross-section of Changes

The cross-section of the carrier should look similar to the diagram below.  Note that the critical dimensions are:

  • the distance from the underside of the main hull to the waterline: this prevents Poolbot from dragging in the water
  • the width between the pontoons at the water line: this ensures enough room for Poolbot and the “lifting claw”
  • the main hull’s height must be sufficient to allow for batteries and control electronics
  • the width of the main hull should be sufficient for another solar panel

The actual length of the carrier will be somewhat less, scaled, then its experimental Navy cousin, making It squarish when in the water.

The chief problems now:

  • the lifting claw – how to get Poolbot out of the water and how to maneuver the two in close enough proximity to make this happen reliably
  • how to charge Poolbot without physical, wired connections
  • how to perform data exchange with Poolbot without physical, wired connections
SWATH cross-section
Carrier SWATH cross-section


Cutting a Wide SWATH

Impractical.  Inefficient.  Just plain difficult.

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 carried by 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.

This idea is brilliant.  So brilliant, in fact, that a NATO research group at Italy’s University of Genoa outlined a highly similar design… in 2010.

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.

Next post: dimensions and a mock-up…

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.

Space Available

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…

Geometry calculation

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) 
tube sizing
Tube size calculations

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.

Current Affairs

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…

Designs Today and Tomorrow

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.

Today’s Poolbot design