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