Data Bus: The Nickle Tour
 |
| Data Bus, April 2012 |
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).
Data Bus mbed baseboards are now available on Tindie as a fundraiser!
Here's the nickle tour of the robot, it's features, sensors, software, and more.
Chassis
Robotifying an RC Truck
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.
 |
| Brushless goodness |
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.
GPS
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.
Serial communication runs at 38400 bps on one of the mbed UARTs. GPS supplies heading information. The robot ignores GPS position information.
Gyro
Precision Gyro Calibration Reloaded
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.
Encoders
 |
| Redesigned encoder board |
For Sale on Tindie
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
Why The Wrights Flew First
Magnetometers and Motors
Magnetometer Calibration
Is a Compass Necessary?
Is a 3D Compass Necessary?
Magnetometer Calibration Error
Encoders and Quantization Error
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 and Position 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.
What's Wrong With Data Bus?
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.
Microcontroller
Choosing an MCU
Brain Transplant and Updates
 |
| mbed on motherboard |
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
Data Bus Interfaces and Conveniences
 |
| Sparkfun Serial Graphic LCD user interface |
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
Logging Data to SD Cards
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... |
Wiring
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.
Safety
Robot Kill Switch
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.
Software
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.
Analysis
First Autonomous Runs
Visualizing Position
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.
2012: What Worked, What Didn't
2012 Sparkfun AVC Recap
Well, obviously on the final run, things worked fine. :) A fact which has me probably more relieved and thankful, than anything else. :) But lots didn't work in the days and hours prior to the final successful run. I very nearly blew it more than a few times.
Several estimation improvements were required for race day. Three days before the race, the robot couldn't get around the building more than once in five times, usually slowly drifting into curbs, and whatnot. All seemed lost until some log analysis turned up two problems. The third issue didn't rear its head until race day.
First, the steering system on my cheap RC truck was too loose. The robot was making fine adjustments to heading that were having no effect on the steering system. A couple of modifications tightened the steering and revealed another problem. The heading estimate was just bad enough to send the robot into curbs.
The GPS heading estimate started out wrong at the start of each run and took about 3 or 4 seconds to converge. I changed the code to ignore the GPS heading estimate for awhile. Then, I initialized the Kalman Filter with the calculated heading between the starting waypoint and the next waypoint.
While the robot waits on the starting line, it is assuming the heading is, say, 90.5° and the Kalman Filter basically unbiases the gyro in that time. Thursday night testing was like watching a miracle. The robot was going around the building with eerie consistency and at impressive speeds! It was incredibly exciting to watch!
On race day, first run, Data Bus took off and steered into a wall. The heading was all over the place right after taking off. Bouncing off the starting line ramp was enough to jostle the gyro and send the heading estimate all over the place. My attempt at a fix failed in the second run. The robot veered left into the crowd.
The third attempt, thanks to Ted (team Daisy Chain) for the elegant suggestion, was to start off going slow off the ramp then punch it. In that run, the robot tracked beautifully around the building, made a picture perfect jump over the ramp, and landed about 2' from its intended stopping point.
2011: What Worked, What Didn't
2011 Sparkfun AVC Recap
 |
| Disastrous Dead Reckoning |
Why? Sensor errors baffled and delayed me, and I wasn't able to figure out a sane way to fuse the data. The robot had no clear idea where it was or where it was pointed. No wonder it crashed.
I had quickly gotten overwhelmed by all the sensor issues. I fought in vain to get correct and consistent compass heading data, reliable, reasonably accurate GPS data, and usable gyro heading information. On top of this, all attempts at implementing reliable obstacle detection, with several sensors, resulted in failure. Without detection, avoidance was impossible.
Having a poor idea where it was pointed and no idea if it was about to run into anything was bad. But on race day, I now believe I didn't give the GPS enough time to acquire a good signal so it also didn't really know where it was.
I now have a much better understanding of the quirks of the various sensors, and what really works and really doesn't work. Real world testing has been encouraging but there's still a lot of work ahead to make the most of the usable data and increase speeds to competitive levels without giving up accuracy or precision.
One minor victory in 2011 was that Data Bus was designed to be weather resistant with sensors and electronics mounted inside or within weather-resistant housings. On that snowy, rainy day in April 2011, I was one of the few robots that didn't need to be wrapped in plastic bags. It's electronics were safely warm and dry, ready to consistently drive the robot into walls.
Some other minor successes from 2011 include data logging, steering, user configuration, and hardware/electronics. This year, data logging helped in prototyping estimation algorithms on the PC.
The steering algorithm is similar to what's called a pure pursuit algorithm. Essentially it's a feedback control where relative bearing to the waypoint is the error and steering angle is the output. The algorithm calculates the desired turn radius to intercept a point at a fixed distance towards the waypoint.
User configuration via a configuration file has been helpful. It allows me to change waypoints, steering, throttle, navigation and other parameters on the fly without recompiling the software.
Except for a loose GPS connection that plagued me for about a month, the electronics and hardware have been pretty reliable. I'm pleased and relieved to be able to focus on software and algorithms more than electronics.
While I got a few things right, mostly I failed to put it all together in 2011.
Data Bus Teaser, 2012
Official Entry Video for 2012
Official Entry Video for 2011
Are you navigating by dead reckoning? You state that you ignore position from the GPS. How do you know your initial orientation? Do you set the bot at a known angle? Or do you just wait to start moving and get direction updates from the gps? If so, don't you get a lot of uncertainty right at the beginning?
ReplyDelete@NATO: yes, dead reckoning. In this 2012 version the robot uses GPS heading but ignores GPS position. The position is initialized to the starting waypoint. The heading is initialized to the bearing from starting waypoint to next waypoint and I set the robot to point to the next waypoint. The GPS heading data converges to a good estimate after about 3 seconds of driving; the software then starts to feed this into the Kalman Filter. I was getting a lot of uncertainty at the beginning until I changed the initialization. It helps to move the robot before arming it so the GPS gets an initial guess at the heading that's close.
ReplyDeleteCool. I thought only Roadrunner and I were using dead reckoning. In our code we have completely done-away with any reference to earth-based coordinates, though(lat, lon, north, south, etc). We strictly go off of initial position and angle. This means that we can't update the gyro with gps headings, but the gyro drifts so little that it's not a problem. Were your gps readings (for heading) consistent in the area between the pond and the building? It seems like that's where most gps's have troubles.
ReplyDeleteBTW, here is my writeup:
http://www.diydrones.com/profiles/blogs/minuteman-avc-2012?commentId=705844%3AComment%3A897388&xg_source=msg_com_blogpost
-Minuteman
@Minuteman - I will have to analyze logs again but off the cuff I think I was seeing about a 1-2 deg deviation in gps heading on the southeast side of the building, not sure about elsewhere. I remain incredibly impressed with the Venus GPS. I like setting waypoints visually in Google Earth; other than that I run in cartesian coordinates now. I'm able to unbias the gyro with the Kalman Filter which seems to work well and results in consistent performance barring other issues like ramps jarring my gyro :)
ReplyDeletePS: I found GPS position to simply be too affected by position bias which seems to shift depending on sats in view. Heading is much more stable and far less noisy (thanks to massive filtering by the Venus). If I can figure out how to deal with the gps position bias I'll most likely start to do position filtering, too. We'll see... :)
ReplyDelete