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
After some study, a tough decision, filling out of forms, and payment of an application fee, the Federal Communications Commission (FCC) has approved a Ship Radio Station License, Recreational or Voluntarily-Equipped (SA) for Poolbot. Poolbot now has an identifiably-American MMSI (see below) and a callsign: WDH7858.
This was tricky. Poolbot is intended to eventually operate internationally, and US treaties apparently require a special radio license for such craft. However, a lot of the laws and regulations are for “vessels”, which carry passengers or cargo, and are usually of a certain length or gross tonnage far larger than Poolbot will ever get.
A letter was filed with the FCC stating that Poolbot is a “drone”, explaining that passengers and cargo are impossible, and specifying that no search-and-rescue craft would ever be required if Poolbot were to get into trouble.
No questions asked, they took the money and issued the license. Poolbot is now government classified as a “Pleasure Ship”, specifically a “Research or Survey Ship”
What remains unknown is whether Poolbot is operating legally if the Restricted Radiotelephone Operator (required for the radio license) is physically miles away from the craft. The law really hasn’t caught up to the drone age yet.
Why do any of this? To get an MMSI number for an AIS unit – in essence, a unique ID that would allow live tracking of Poolbot via the web (see marinetraffic.com or vesseltracker.com) or using appropriate equipment on other ships and Vessel Traffic Services. This lets Poolbot be “seen” in waterways and prevents it from becoming a hazard to navigation.
One last point: the FCC form requires the craft in question to have either a registration number from the US Coast Guard or the state of California… or a name. US Coast Guard and California state regulations still only apply to cargo- and passenger-carrying vessels “used or capable of being used as a means of transportation on water” or engaged in fishing or towing operations. So Poolbot now has a new name:
An explanation of the name will be the subject for the next post. Thanks for your patience.
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.
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 a fairly long dormant period, in which Poolbot took a local vacation, work has resumed. Much of this consists of research and planning improvements. Some highlights:
- The GPS has suddenly become spotty, which may drive finding a replacement.
- The MSI depth sensor has been lost, despite the shop now having small PCBs and an air-soldering station to attach them. Fortunately, the good folks at OpenROV have a combination depth sensor, gyroscope, and accelerometer board that works over I2C.
- Just stuffing wires, batteries, and boards into the central tube isn’t reasonable. OpenBeam allows a more rigid structure to be used, supporting sliding in of PCBs or acrylic plates.
- The wax-potted motors are, at best, unreliable and inconsistent in their speeds. Low-cost thrusters are hard to find… except the Blue Robotics team now has the T100, which will explode onto Kickstarter in a few days.
- Speaking of which, their solar-powered autonomous surf board has some common design elements with Poolbot, including solar panels, an Arduino Mega-based microcontroller system, and a RockBLOCK satellite communications unit.
- Finally, The Economist has a story on a system of Arctic environmental measurement paid for by the US Navy, involving autonomous robots called Seagliders and Wave Gliders. The Wave Glider image bears a strong resemblance to Poolbot’s intended surface profile.
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
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…
Returning to the blog after a long stretch of work and personal exertion…
The UK’s Telegraph newspaper reports that Rutgers University has deployed a fleet of 16 autonomous underwater vehicles for ocean mapping.
Technical details are sketchy in the article (what exactly are “sustainable optic sensors”?), but the use of Iridium satellite communications is confirmation that it’s a viable approach for long-range control.
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…
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:
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):
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:
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.