Let's Make Robots!

Data Bus: autonomous ground vehicle

Competes in the Sparkfun AVC, drives around building as fast as possible

Data Bus, is the 3rd place winner of the 2012 Sparkfun Autonomous Vehicle Competition (AVC) and veteran of the 2011 Sparkfun AVC. It is a mini, autonomous rover robot based on a 1:10 scale RC truck.

With only three sensors, a simple Kalman Filter, and a total cost of around $650, the robot was able to achieve a top speed of around 20mph, with a total raw time around the building of 37 seconds and a cross track error of ~1 meter (based purely on eyeballing it while chasing it several times around the SFE building in my WRX).

Here's the nickle tour of the robot, it's features, sensors, software, and more.



The robot started as an ElectrixRC "Circuit" 1:10 stadium truck. At $130, it was the least expensive 1:10 RC truck I could find at my local RC Hobbies. It's not cheap, just a good value. It's tough, easily customized, good parts support, and has a loyal fanbase.

It runs a Tacon 3000Kv brushless motor, Hobbywing 35A ESC, 2.4GHz FlySky 3 channel receiver, and 2S, 4000mAH 25C Gens Ace LiPo battery, ElectrixRC 'hard' springs, and Traxxas Anaconda tires on 2.8" All Star black chrome wheels.

Suspension tuning completed the chassis work. I used 50wt oil in all four shocks, and adjusted ride height in back with springs inserted below the shock pistons. The result was a lower center of gravity and much flatter turns.


The body is a Parma PSE "Skool Bus" lexan body custom painted by yours truly with custom decals printed on inkjet self-adhesive paper and coated with automotive clear coat.

Venus GPS


Data Bus uses only three sensors. A Gyro, a GPS, and wheel encoders.


The GPS is a 20Hz Venus638FLPX on Sparkfun breakout board mounted inside with a roof-mounted patch antenna and a ground plane cut from a square of tin that's good for 5-10db signal gain. GPS supplies heading information. The robot ignores GPS position information.



Additional heading information comes from an STM L3G4200D gyro on a Pololu minIMU-9, mounted on an aluminum bracket up front. Communication is via I2C at 400kHz. The gyro is sampled at 100Hz.


Redesigned encoder board


Wheel encoders on both rear wheels provides accurate distance measurement. The 32-stripe wheel encoder discs were created with my WheelEncoderGenerator cross-platform java application.

Sparkfun QRE1113 sensor boards mounted to the bearing carriers sense the stripes and send signals to a tiny surface mount interface board I redesigned using comparators in a Schmitt-trigger configuration.

Experimentation, Simulation, Analysis


I spent quite a bit of time testing, experimenting, understanding and modeling the error modes of the various sensors and their impact on position estimation error. All that up front work explains the unorthodox sensor choices, particularly ditching the compass and using only heading data from the GPS. Fortunately, all the work and the odd choices seemed to have been successful.

Naturally, the sensors are not of much use without a way to use them to estimate position and heading, aka pose.

Pose Estimation

Heading is incredibly important in the Sparkfun AVC. An error of only a couple of degrees is the difference between crashing and finishing. The solution on Data Bus feeds lag-compensated gyro and GPS heading data into a Kalman Filter, using the results to update current heading and position with that historical estimate.

Gyro data is the foundation of the heading estimate. It's corrected for bias using heading data from the GPS. Unfortunately the GPS does its own massive amount of filtering and the result is a reduced dynamic range and lag.


By saving a second's worth of gyro data and feeding that into a Kalman Filter, a very good estimate is generated. From this, the gyro-based heading is updated. The end result is a heading estimate with high dynamic range and negligible bias.

Meanwhile distance traveled is given by the average distance of the wheel encoders. I calibrated the wheel encoders to Google Earth, my waypoint editor, and found the error falls below 1%. So the robot knows how far it's gone and in what direction, giving a position estimate. The position is estimated in cartesian coordinates which I did for one very good reason: updating the position based on the historical heading estimate.

If we know what direction we were pointing a second ago, we can not only update gyro heading calculations up to present, but, using a rotation matrix, we can update the last second's worth of position estimates up to present very quickly.



mbed on motherboard

The microcontroller is an NXP mbed, a NXP LPC1768 Cortex M3 running at 96MHz with 512KB flash, 64KB SRAM, and a plethora of I2C, ADC, UART, SPI and other peripherals. The mbed is mounted on a custom PCB fabricated at Bot Thoughts labs (a messy corner of our garage).

The ample computing power, flash memory, and available RAM open up possibilities that are simply unattainable on the typical 8-bit, low speed microcontroller.

The mbed incorporates a mass storage USB flash drive which stores the configuration file for the robot. The file contains waypoints, compass declination, magnetometer calibration, speed, turning parameters, GPS baud rate, and more. The configuration file saves time by avoiding recompiles.

User Interfaces


Sparkfun Serial Graphic LCD user interface

The robot features two primary time-saving interfaces. The first is a serial, menu-based interface accessible through the built-in USB to serial adapter on the mbed.

The menu gives access to instrument diagnostics, software reset, a unix-like shell for managing and downloading log files, a bridge to raw GPS output to permit PC client software to directly configure the GPS, output for AHRS visualization, Mavlink data output for use with a Ground Control Station, and more.

Secondly, the robot features an onboard interface consisting of a Sparkfun 128x64 graphical LCD display and 3 buttons on the Bus body. Status information is displayed and various calibration functions are available. Most importantly, this is the interface used to tell the robot to start racing.

Data Logging


Data is logged as text CSV to an onboard FAT-32, 2G microSD card connected to one of the mbed SPI ports. Around 20 system state values are logged at a rate of 50Hz and typically take no more than 150usec to write but the logging is buffered and done in the non-time critical outer loop. Logfiles are named with sequential numbers.

Offline analysis scripts in Processing, perl, and Octave plot and visualize the sensor data, or prepare KLM files for display in Google Earth. The onboard shell command 'send' in combination with a customized Java serial terminal program initiates on-the-fly download of logfiles.

Power Supply

Lots and lots of wires...

The main electronics power supply is a Pololu 5V, 3.5A step-down (buck) switching regulator fed by the same battery powering the ESC and RC receiver. The mbed's onboard 3.3V regulator supplies power to all the 3.3V circuits.


All the wiring uses 0.1" pin headers and crimped and soldered female connectors on custom cables, all consistently color coded to eliminate race day goofs. I've learned that loose connections and rats nests of wiring suck, so I made a concerted effort to keep things somewhat organized underhood.

Printed Circuit Boards

Eagle board and circuit files, etc.

Because it's fun and because I hate breadboards for anything but prototyping, all the custom circuits are implemented on custom board designs. Two boards were professionally fabricated through the DorkbotPDX PCB service; the rest were etched at home.

For an added touch of elegance, I emblazoned each of the homebrew PCBs with a Bot Thoughts logo using the toner transfer method for "silk screening"  After transfering the toner, each board is sprayed with clear acrylic for a pseudo-professional look. Each board carries an OSHW logo as well as the entire robot is open source.



An RC switch (multiplexer) circuit based on designs online enables me to take control of the robot within a few milliseconds at any time by switching on the remote control transmitter. Control was returned to the microcontroller by switching off the transmitter.

The circuit takes pulses from the receiver and pumps up a capacitor, reaching a voltage that then controls a 74HC244 bus driver acting as a multiplexer.

The circuit is populated onto a custom PCB created at Bot Thoughts labs.


mbed code
Data Bus Code Repository
Ranger Board Software
Analysis Software
Ground Control Software (such as it is...)

The software onboard DataBus is written in a mix of C and C++ in the mbed cloud IDE and tallies up to almost 20,000 lines at last count. The mbed libraries abstract interfaces to the microcontroller peripherals (Serial, I2C, ADC, etc.)  I reused as much code from others as I could.

For example, I did a custom port of TinyGPS to mbed parses NMEA data from the GPS and provide methods for polling the availability of new GPS data. GGA and RMC sentences are parsed, only. I reused others' sensor libraries where I could. Most of the code base for Data Bus was developed last year by me.



This year, most of the effort went towards improved sensors and revised position and heading estimation software. To that end, quite a bit of additional software is written in Perl and Octave to process and analyze logs from the Bus. A Processing program does simple visual playback of data runs, and this program was adapted as a rudimentary simulation program.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Congratulations on your success and your very cool bus.

I find it very annoying when someone just post a photo and a link to their website with about 2 sentences to explain the photo.

I was very interested in your solution/problems with the heading. It sounds like you would be better off just using the sun for a compass. Admittedly this then limits you to bright sunny mornings or afternoons as accuracy will deteriate towards midday.

The heading thing was interesting. I didn't expect to end up with the heading sensors I did, but the experiments and analysis led me there and it ended up working--cool. Let me know if you want me to expound more on what I discovered.

  Congrats on the podium finish. Excellent documentation.

+1 for the top quality picture you have taken. +1 for looks!

The more I play with robots the more I realize how noisy and unreliable sensors can be!  The GPS I use is of typical accuracy. At best, maybe 10 feet or so. It's also very sensitive, picking up a reasonable signal in my basement. Although the position definitely jumps around all over.

It seems GPS is best used for drift correction over the long term. The question is, how long of a term. I read a paper that said position averaging works best over the span of months(!)  I still haven't worked out the sensor fusion but my feeling is that GPS will be only of minimal help to very gently nudge the dead reckoning position estimate a little at a time.

I still feel if I can get a decent heading estimate, I'll be in much better shape. I have an AHRS I plan to use in 2012 and so far it looks fairly promising.

This robot seems to handle GPS-"jumpiness" in a sane way: http://letsmakerobots.com/node/18922 Maybe you could get some tips from it?

Yeah. That's what I've heard too.


From what I understand, most people use the GPS to get a heading and then use the compass module to stay on that heading, and using sensors to avoid objects.


Get heading, turn until compass is correct, go forward, check heading from compass, correct if needed until we reach our goal.

One thing I've seen about GPS is that it is very jumpy when you stand still. What some people have done is simply ignore GPS-positions when the robot is stationary. 

how  accurate is the GPS unit you are using ?, my little hand held GPS unit can only go as small a 3 to 4 meters .i have a friend who is a surveyor ,and he tells me that they use a second GPS unit in a known location to calculate some kind of off set . so it is down to 1mm :)