Older blog entries for hudson (starting at number 14)

I've shoe horned the Kalman filtering code into the my aerial robotics Atmel AVR based control board and timed it.

You can see the source code for the embedded version's vector .h, ahrs.h and ahrs.c. The last one is the actual Kalman filtering code.

With the math library the code is about 15k (including 4k of the sensor library and other things). The GNU math library does 32 bit double precision and includes the necessary trig functions. We require roughly 70 ms per call to kalman_step*, so we can only process every fourth sample of the accelerometer (20ms / sample). This is stil fast enough to do a 10 Hz update, which may be sufficient.

I can still do more performance tuning and code compaction. The runtime footprint is a bit large since the code is almost verbatim from the version that was running on my laptop.

*: It requires 285,000 instructions to emulate the floating point math and matrix inversions, etc. An 8 Mhz clock would do it in 35 ms, or the 16 Mhz Mega128 could do it in 18 ms. That would be just about a 60 Hz update rate.

I've posted images of the homebrew 3D rate sensor built with the Murata gyros scavenged from two Gyropoint mice (for the autopilot project). There is room for the two ADXL202-EB's, too, but I need to order another one. There is a top view and a angled view.

The rate sensors are soldered onto Radio Shack PCB's and connected to a quad opamp (also on a RS PCB). The circuit looks like this:

                   ____
                  |    \
  Reference ------| +   \
                  |      >----+------  Output
  Gyro -/\/\/\-+--| -   /     |
         R1    |  |____/      |
               |              |
               |     R2       |
               +---/\/\/\/----+
               |              |
               +----||--------+
                    C1
R1 is 10k, R2 is 47k Ohm, C1 is 0.47 uF.

I haven't taken the steps to calibrate it yet, just checked it out with the multimeter. The zero-rotation output is about 2.5 V, and roughly 90 deg/sec seems to have a 1 V drop.

I like Mark Ramsey's idea of using a turntable to calibrate the rate sensors. Next time I'm browsing for equipment to scavenge at a thrift store I'll pick one up.

The above schematic should be in a monospaced font, but it appears in Mozilla in a proportional typeface. See my post to the mailing list for a properly rendered version.

I just spent the past three hours with Aaron Kahn, former IARC contestant and now UAV designer for ITT. He gave me an indepth description of how Kalman filters work and how to use them to process our gyro and acceleration sensor data. I'm greatly indebited to him for the assistance.

Most of the online tutorials on the filter are very abstract, so I've written a description of the Kalman filter that focuses on its use for attitude reference. It is a little heavy on the math and matrix arithmetic, but I think it does a good job of describing the process. I don't go into the theory for two reasons:

  • There are lots of descriptions of the theory online
  • I don't fully understand it.

My source code to implement an AHRS is online. It uses a simple matrix library that was provided by Aaron. As a bonus there are ECEF transforms for once we start building a GPS aided INS. I plan to recode the common matrix cases as inline functions to ensure type-safety and hopefully speed things up.

The ahrs program doesn't do anything yet, but it will read angular rates and linear acceleration data (in the strapdown inertial reference frame) from stdin and write out the estimated Euler angles in the North/East/Down reference frame. Right not it just test the algorithm in a steady state.

Interestingly, we could build a decent two-axis IMU with the code. It wouldn't have heading information, but would be able to track the attitude fairly well. We do have the problem that in a continuous coordinated bank the filter will slowly erect the attitude, but that plagues both two and three axis strapdown systems.

In response to Matt Minnis' review of the DAS20 dual-axis clinometer, what are the advantages over a dual-axis accelerometer like the ADXL202?

The usable static range of the DAS20 is listed as +/- 20 degrees, while an accelerometer in a static tilt environment will be usable in the full 3D range. Additionally, the size of the DAS20 exceedes the surface mount ADXL202 or even the through-hole ADXL202-EB. I couldn't find a price for the DAS20, but the Analog unit is $10 for SMD or $30 for through-hole.

Both sensors are subject to linear-acceleration errors and not be usable for attitude reference without angular rate sensors. Am I missing something?

Release 2.1 of the realtime code came out on 27 Jan 2002. The major change was to smush all functionality into one file, mainloop.c that dealt with accelerometer sampling, UART handling, servo input, engine tachometer, ADC sampling and all that stuff.

Since the release, the latest version of mainloop.c has a sliding window averaging for the sensor values rather than the discrete time steps that it did before. This means that sensor data never gets "stale" as it used to, but it also means that the readings fluctuate more frequently. Comparison plots of the accelerometer before and after are online.

Tower Hobbies has discontinued the sale of the White man flying stand that I planned to use to teach the software how to hover the aerial robot. Does anyone know where I can find them? Other than eBay, that is.

The older GyroPoint mice arrived and I've stripped one down to get at the Murata ENC05-EA and -EB gyros. They appear to have some applification / filtering circuits on the daughterboard. The gyros are the silver components on the small board to the right in the image.

I summed up most of my observations on post to the autopilot-devel mailing list.

I haven't finished decoding the wiring harness, but Marc Ramsey seems to have done so. I hope to get some code sampling these new gyros this weekend.

In other news, the software for the realtime board will need to be redesigned. I tried to do a very modular, easily maintained design with lots of high-level readable functions. And it is too slow, has too much interrupt overhead and causes servo jitter. My plan is to squish it all into one mainloop, hand code portions in assembly and generally make it a pain to port or extract code out for other projects.

Sorry about that....

Another day lost to a dead glow plug ignitor... I met Mike Pearson to fly his Eco 8 electric and my 10cc prototype, but was unable to get the large prototype engine started. I believe the problem is that my glow plug driver needed to be charged.

So, in a fit of frustration I build a new field box that incorporates a "Power Panel" with step down circuitry to drive the glowplug from my 20 AH gel cell. It required a new case to fit properly, but on the plus side the fuel bottle is now stored upright and the transmitter is better protected.

I also tried to characterize the errors in the accelerometer sampling code. There is a plot of data readings for ten minutes of the IMU (image) on a stationary workbench.

I'm working this evening on tuning the PID loop with a static leveling test. It is no where near as difficult as the actual helicopter stabilization system, but a good workout for the IMU boards, the servo controlls, the accelerometer sampling and PID tuning.

So I built a small "level bot"(click for an image) that has one servo to control its roll axis. Based on the accelerometer readings fed into the PID code, the servo rotates to adjust the angle of the board. The HS-81 micro-servo has an allen wrench for the lever-arm since the servo arm barely reaches to ground...

You can see a textual graph of the leveling action in my post to the autopilot-devel mailing list.

15 Jan 2002 (updated 17 Jan 2002 at 03:41 UTC) »

Last night's all night hacking session has produced an iMac styled case for the autopilot. I also installed magnets in the fan disc for the N1 engine tach. The Hal effect sensor does not seem sensitive enough. I might have to purchase different ones. More details are in my post to the mailing list.

I also made Release 2.0 available over the weekend. This release is named "fly-by-wire" and is the first to support the Mega163 on the custom PCB. It has support for the servo outputs, sampling the gyros and accelerometer data as well as reading commands from the serial port.

My goal for the next release is to have the engine tach functioning and the PID loop governing the engine speed. I don't know much about control loop tuning, but I'll figure it out as I go...

I made good progress today on the realtime board. First, the good news:

  • Crystal clock problems have been resolved.

    Rather than frying another chip with uisp, I tried PonyProg2000. It's an IDE style programmer for just about every serial chip on the market and has GPLed some versions of the code. The latest is a binary-only release for Linux that includes suppot for the Mega163. Download it from:

    http://www.lancos.com/prog.html

    Based on John Cunningham's suggestion, I set the CLKSEL fuse bits to 1011 and the little board is now screaming along at 4.0 Mhz or so. The toasted chip is still in paperweight mode. I haven't tried resurrecting it yet.

  • Servo output works and is jitter free.

    Nothing really had to change. The 163 does have a direction control for Port C, while the 103 does not. Simple code change to set DDRC for output. I've tested it with the Futaba S3001 and HiTec HS-81 servos from our two prototype aircraft.

  • Accelerometer sampling looks good and fairly smooth.

    The faster clock rate helps give us a bit more precision. I've added a very simple weighted average to the sampling. The response is fairly good.

The Bad news:

  • Analog voltage sampling is still hosed.

    No matter what I try I can not get the internal voltage reference to come online. The bandgap is enabled (BODEN) and I can sample it and confirm that it is at 1.22 volts. But the reference voltage will not change from AVcc = 5.0V. Any ideas? You can see the ADC code here:

    http://autopilot.sourceforge.net/cgi-bin/source?onboard/avr/adc.c

  • The board is UGLY.

    All those jumpers and cut traces offend me. Rev 1.0 is a mess and needs to be cleaned up. The boards are available if anyone wants one. Just add parts.

  • Murata gyros will mess it all up.

    I'll have to redesign the board, but that is life.

5 older entries...

X
Share this page