Thursday, April 9, 2009

Inscrutable Measurement Unit

When SparkFun told me the battery connector on their IMU was a "standard 2-pin JST connector", I didn't realize that JST is a global manufacturer of dozens of connectors, and that what SparkFun considers standard is not at all compatible with the "JST connector" widely used in the R/C hobby world. Oh well, I have something jury-rigged for now, and the proper connector on order.


Once powered, you can talk to the SparkFun IMU with Bluetooth. I'll use a hardwired connection when flying, but this is handy for experimenting, or at least it would be if this weren't the most irritating radio link ever! It constantly gets hung up if you breathe on it long (requiring a reboot), it doesn't reconnect cleanly after disconnection (requiring a reboot), it has some bizarre control protocol that doesn't give feedback, it tends to drop characters (or something) if you send them too quickly. This really makes me appreciate the XBee modules a lot more, which just (by default) give you a transparent serial link with no fuss and no muss.

(Speaking of which, I got my new XBee Pro XSC modules. Their range is indeed far greater than my old XBee Pro's; in a range test, the XSC has good signal several blocks away, right through suburban houses and trees and stuff. Line-of-sight they're supposed to get 15 miles or something ridiculous like that.)

I also discovered that I need to program my ESCs for the proper throttle range (which in this case is 0-100 because I'm synthesizing the PWM pulses directly). That's sort of a pain the way things are set up now, I should see if I can find a Turnigy ESC programmer somewhere (they're all out of stock everywhere?).

Anyway, back to the IMU. So I got it powered up and wrote a Python script to read out and plot the data it's reporting:


After playing with it for a while, my conclusion is, wow, that's a lot of data (9 channels * 350 Hz), and it's noisy and drifty data, not super well calibrated or zeroed, and not trivial to interpret. So I've been doing a bunch of reading about IMUs and Kalman filters and so on. Here are some links I found handy, for my reference as much as anything:
There are also a lot of bad resources, confused people, and clumsy papers out there, but generally speaking this is the deal: Accelerometers give absolute pitch and roll (not yaw) for stationary objects. However, your object is not stationary (you want to fly, not just sit on a desk). Gyros give delta pitch, roll, and yaw (but not the absolute value). However, inexpensive (MEMS) gyros have a drifting zero point. Using a Kalman filter can combine the two for decent overall pitch/roll reading. The Kalman state variables to use are the current attitude and the gyro zero point.

For yaw, you need to bring in the magnetic compass. Apparently the magnetic compass is finicky and annoying to work with, and gets screwed up by nearby motors and things. (Great.) You need to compensate the compass for the current pitch, roll, and magnetic declination.

If you can get all that put together, then theoretically you can get a decent model of attitude. That still leaves positioning, where presumably you use accelerometer data (subtracting out the expected component from the attitude) combined with the GPS. This is all kind of cool in theory, cross-checking your way between 12 data streams (compass X/Y/Z, accelerometer X/Y/Z, gyro pitch/roll/yaw, GPS latitude/longitude/elevation) to get a decent model of what's going. And then you feed all *that* back into a control system and hope for the best? In practice, I'm somewhat surprised this ever works at all.

Maybe instead of an autopilot I can learn to fly my unit manually by sending keystrokes over the XBee. Ha ha.

On a completely unrelated note, my hydroponic tomato plants seem to be sprouting nicely:


No comments:

Post a Comment