AVC: Encoders, Quantization Error

As I continue working on various aspects of my Sparkfun AVC robot, I learn all kinds of interesting things, this time about quantization error, dither, and the exponential filter.

A recent test run provided the following speed data from the wheel encoders, which digitize position at regular intervals.

Here's a detail view of one of the plots.

Detail speed plot showing quantization error

It seemed to me that a smoother curve might not be a bad idea. Maybe it doesn't matter but I was curious to find out what if anything I could do. Here's what I learned...

AVC: Is a Compass Necessary?

LSM303DLH on Pololu Board

While building my 2012 AVC entry, basic questions keep coming up. What sensors are really needed to reliably run around the course?

Do we really need a compass?

A very sharp fellow I know, Jesse, asked me this recently. I had no answer.

Looking at 2011 top finishers, 3rd place Team XYZZY used an ArduPilot board to create a tilt-compensated compass, adding GPS, and a wheel encoder.

The 2nd place finisher, Team Minuteman, ran only a gyro and wheel encoders using a record-playback approach.

Team Tobor placed 1st for the second year in a row using fairly sophisticated mathematics to fuse data from a 1-axis gyro, 2-axis compass (effectively), encoders, and a GPS. 

What if we just use a gyro, let's say an Analog Devices ADXRS610 like the one used by Team Tobor. How much error are we talking about? Let's find out using simple math and GNU Octave (free matlab-ish tool)...

Pololu MinIMU-9 AHRS

MinIMU-9 on custom carrier board

I've been working on my Sparkfun AVC robot, Data Bus. Right now I'm focused on implementing a much improved AHRS. Data Bus suffered from disorientation last year. I hope to fix that.

After performing some breadboard-based testing on my black Friday Pololu MinIMU-9 and associated Arduino-based AHRS software, it was time to stick it all on a printed circuit board. That way it'll be easier to mount to Data Bus for field testing.

The purpose of the AHRS is to provide an accurate and precise heading and attitude for dead reckoning calculations despite robot acceleration and travel over road surfaces that stray from perfectly level. More on those topics in future articles.

For sake of simplicity, I had planned to start with an Arduino, since the code works out of the box, and migrate to something else: mbed, LPCXpresso, etc.

Rather than an all-in-one board, I created two modules: one to secure the MinIMU-9 board and another for the Arduino AHRS. Later I can build a board with a different MCU and replace the Arduino board.

But, I screwed up. The Arduino board doesn't quite work. More on that in a minute. Here's the schematic and board.

Pretty straightforward on the MinIMU-9 side of things; we just need a place to solder the pin headers and a hole for mounting the thing.

The Arduino side of things, the electronics are straightforward, but it doesn't want to load code. All I had on hand was a 20MHz ceramic resonator, and that probably threw off the baud rate for the bootloader. I tried a few things but I'll have to revisit this later. EDIT: see comments from my readers who quickly pointed out the issues at hand :)

I was going to port the AHRS code anyway so that's what I did. To the mbed platform (here). The code I started with is a derivative of ArduPilot 1.5, ported by Pololu and adapted to the MinIMU-9 devices.

For those that don't know, ArduPilot uses the DCM AHRS algorithm (pdf) found in MatrixPilot, as implemented by William Premerlani and Paul Bizard.

I massaged the code so the DCM AHRS algorithm is encapsulated as a completely standalone C++ library, decoupled from the hardware, making it significantly easier to swap out sensors or entire IMUs.

After running the code in a test program I migrated it into my 2012 AVC code base. After ensuring proper compass calibration, I'll work on dead reckoning and accuracy refinement.

Still on the waiting list to enter the 2012 AVC...