AVC: Progress Update

I'm still on the waiting list. I'm assuming enough teams will throw in the towel to make room for me. I'm going to submit my video before the June 1 deadline.

Magnetometer calibration and accuracy has been a big challenge. I'm developing a calibration turntable to help quantify magnetometer error.

I'm evaluating several IMU sensor options including the MinIMU-9.

The robot has not yet run autonomously. For that matter, I've not done any data collection runs. I feel like I'm falling behind again.

I've also been investigating a few interesting sensor technologies in hopes of improving various aspects of the robot's performance. Implementing any of them would be kinda cool, I think.

I've been looking at options to improve linear acceleration and cornering performance. Probably getting ahead of myself there since the robot has yet to run by itself.

Oh, and I'm also enrolled in the free online course, CS 373: Programming a Robotic Car, taught by Professor Sebastian Thrun of Stanford SAIL, DARPA Grand Challenge winner, and Google Car fame. I've made it through Unit 1 and am working on the homework for Unit 2. So far the class is beyond fantastic but more on that later.

Oscilloscope Calibrator: Part 4

At long last, I've finally finished my Oscilloscope Calibrator, based on a design for the Heathkit IG-4505 and it's made with a number of parts from my neighborhood Radio Shack. And more than a few not from Radio Shack, but who's counting?

On the front panel, you see a power switch on the left, a frequency selector knob on the right with 6 LED indicators for frequencies of 10e1 through 10e6, a switch on the left multiplies the frequency by 1 or 2 indicated with two more LEDs, a BNC and two banana jacks for output.

To revisit the design briefly, it's all TTL. Gloriously space-wasting, electricity-burning, old-school TTL. A typical microcontroller could do everything this stack of TTL ICs does, in a fraction of the size, cost, and power usage and with many more features. Boring!

TTL is way more fun. The circuit is a bunch of cascaded counters acting as frequency dividers. The input is a 4MHz crystal feeding into a /2 and /4 divider to give 1MHz or 2MHz as the base frequency. That feeds into six /10 counters.

The output of the various counter stages are wired to a Radio Shack 6 position, 2 pole rotary switch. The switch selects which pulsetrain to send to the output jacks. It also select which front panel LED to light. It's topped with a knob from "The Shack" too.

A DPDT switch (yes, from RS) selects 1X or 2X frequency multiplication.

The BNC jack is one of several I ordered from an overseas seller on eBay and the banana jacks are from the second TGIMBOEJ to cross my path (but, RS carries some too).

The power switch is another Radio Shack part and I think the fuse holder is, too. If it isn't, it could have been.

The power cable is salvaged from some piece of old audio gear I picked up in a thrift store (once again, you can probably find the necessary parts at... you know)

What's inside?  In the upper right is the power supply. My very first home-made PCB (I've come so far since then...sniff, sniff, ...) using ferric chloride and copper clad board from RS.

Upper middle is, as you guessed, a transformer for the power supply. It's from Radio Shack. In the lower right is a power distribution board, nothing more than a cut down Radio Shack prototyping PCB.

Bottom middle is a stack of blue prototyping circuit boards holding the frequency generator, a cascade of TTL IC counters, a 74LS393s and a handful of 74LS160s plus a 4MHz ceramic resonator and a 74HC04. I don't remember where I sourced these. Maybe Jameco or All Electronics or something. The prototyping boards come from dipmicro.com and they are great. I'll be posting more about those at another time. But they also could've come from the big red R.

LEDs were purchased several years ago. I don't remember where but I could have easily gotten red ones from... do I have to say it?  (Of course it would've cost me a fortune but anyway)  Standoff hardware for the PCBs comes from several sources: Radio Shack (#4 hardware), All Electronics (#4 spacers), a few eBay sellers (M3 standoffs), and smallparts.com (M3 nuts, machine screws).

The enclosure is salvaged from a broken function generator I bought a few years ago. I used plain old aluminum sheet (K&S Metals stand at the local hardware store) for the front and rear panels.

I decided to omit the amplitude feature from the original IG-4505. I may go back and add that later. There's plenty of room in the case for another circuit board. I may be able to stuff another switch selector somewhere on the front panel. We'll see.

So anyway, it's done and now I know that my Hitachi V212 is pretty close at most scale settings, whereas the Hitachi V1050F isn't. I will have to calibrate it one of these days.

Part 1: Signal Generator
Part 2: Amplitude
Part 3: Power Supply

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