AVC: Data Bus Interfaces and Conveniences

Less than 3 months left before the Sparkfun AVC as I write this. I'd love to build out a full-blown, pretty-looking ground control system that controls every aspect of Data Bus but there's simply no time.

On the flip side, spending all my time fighting bubblegum, duct tape, and bailing wire solutions wastes time and burns me out.

Building a few convenience features into your experimental robot is a good idea. Here are some examples of time-saving features I've added to Data Bus. Read on...

Text-Based Menu. I did this last year. The mbed has a built-in usb-to-serial that talks to the LPC1768's UART0. I wrote a simple, 80's style text-based menu so I could do some basic testing and calibration without having to change the firmware.

I added a software reset function since I snapped the screenshot. Now I can upload firmware and reboot without even touching the robot.

Flashing. The mbed also has a built-in USB mass storage device. It's a small-capacity flash drive from which the mbed reads its firmware and it can also read and write files. When you compile in the mbed online compiler, the web browser downloads the binary which you can then copy onto this flash drive. Too slow. I automated the copy.  I mapped the flash drive to M:\, wrote a batch script to copy the file, and then associated .bin files with the batch script.


Config file. I have a configuration file that allows me to set waypoints, configure calibration parameters for magnetometer, speed, turning radius, etc. I just edit it with Vim or Notepad++.

GPS serial bridge. For sake of debugging, I can bridge between the USB serial and GPS serial ports. I can then run GPS configuration software on the PC and talk directly to the GPS through the mbed. Otherwise I'd have to unplug the GPS and re-connect it to the PC directly.

Display Data. To monitor sensors, I can view output from the AHRS, raw sensor data, etc. This is quite helpful for debugging.

Logging. During a run, the mbed logs over a dozen parameters to the built in microSD flash drive. About 20 times a second! Being able to do post-mortem analysis on the logs is quite useful. The data collected can also help me tune and tweak the heading and position estimation algorithms, or try new ones, all offline.

microSD. Logging is great only if I can get the data off the robot and the microSD card provides a convenient way to store the logfiles and I can yank the card and read it from the PC because it uses a FAT filesystem.

Shell. Even better, I have a unix-like shell on the robot with familiar commands implemented:

• ls list files
• pwd print working directory
• cd change working directory
• touch create file
• head print out the first lines of a file
• cat print out the entire file
• rm remove file
• mkdir create directory
• send sends files
• exit terminate the shell and return to the menu

So I can see what logs were written, manipulate some files, even print and capture the contents of a file without removing the microSD card. But there's an even better way to download log files.

File Transfer. The shell also implements the command send which automatically downloads the specified file from the mbed to the PC. I tweaked a Java-based serial terminal emulator, serterm, to look for a set of escape sequences that initiate the transfer and provide the filename. It then saves the file contents onto the local PC with minimal user interaction.

Front Panel. While playing around with compass calibration I got really tired of having to lug a laptop around with the robot. I created an LCD front panel display with buttons and a simple menu system that allows me to select common functions. I can put the robot in autonomous mode, or initiate a compass swing procedure, and run compass data collection for calibration. Note: red-on-black LCDs don't work well in sunlight. I since switched to a monochrome Sparkfun Graphic LCD mounted at the rear of the Bus.

CMUcam interface. Though only a prototype last year, and while it may not make it onto the 'Bus this year, the interface is worth mentioning. CMUcam uses serial and I was running out of serial ports. I built a Serial-to-I2C bridge using a homebrew Arduino board with serial interface.

It displays a menu over hardware serial for monitoring activity in realtime even while pulling camera data over software serial and servicing I2C requests. I can bridge to the camera directly so I can use the CMUcam PC software, I can monitor I2C activity, and I can display the values for the detected blob.

The little time-savers and convenience things do free up a little time for more hacking. I think even more than that, having to fight a bunch of inconveniences burns me out really fast. So making things easier keeps my frustration level low which lets me hack longer.