This page created November 2008

Trippy the robot Compass testing.

I am testing the magnetic compass I got from sparkfun.



It's installed on Trippy at the top of a long wooden dowel.
Click on the picture to see a larger version.


The first thing I did was to sample the compass while Trippy was sitting up on some soda cans so it couldn't move.

You can see that the compass is pretty crazy, jumping down to zero all over the place.
I figured I was getting bad data from the compass sometimes (since I'm bit-banging I2C. Barf)
but when I looked real closely at the data, I saw I was right up against the 359.9-degree to 0.0-degree boundary, and I could see the swapping when I zoomed-in:

So the data is good, and I just needed to rotate away from the discontinuity for now.

Here's another sample showing the zero-crossing while Trippy is rotating 90-degrees at a time:



So I went back to up-on-blocks and sampled again and I got a nice sample:


But when you zoom in to this data, there are upwards-going spikes that are pretty far off the average:


When you zoom in to THIS data, you can see that the upwards-going spikes are only single samples:
So I might be able to filter them out, but I want to figure out where they come from just like Jeff.


I'm also experimenting doing closed-loop control of heading using the integrated rate-gyro
information. Here are a few 90-degree gyro-moves looking at the compass:


This is a single 90-degree turn.


There are a couple things going on:
- I've got a "dead-zone" programmed-in to the gyro integrator where if
the turn-rate is less then 1.6 degrees-per-second, I ignore it and don't integrate it into the heading.
This allows me to not have to worry about the gyro's baseline drift yet, but it makes the
gyro insensitive to slow turns.

So, when Trippy is turning slowly, the gyro doesn't notice, but the compass does.
That's what you see in the left-hand part of the graph when the angle is increasing
even though the heading-hold part of the program doesn't notice.

- Because of the dead-band, when Trippy starts and stops the move, that motion does not
get integrated into the total-move, so Trippy overshoots the desired angle.

So, this is the start, I'm going to look into the source of the upwards-going glitches
by disabling things on Trippy as well as by trying a slower sampling-rate.
I see that the data sheet shows continuous sample-rates of 1Hz, 5Hz, 10Hz and 20Hz,
so maybe 100Hz is way to fast. I'll see and let you know.