Older blog entries for hudson (starting at number 20)

The fly by wire tests from last weekend were a success. We collected good sensor data, some of which I am still processing. I have graphs of the engine RPM from the tach posted and am processing the angular rate data. It came out really clean, but the acceleration data was unusable.

The tether, however, was a complete pain. You can see it in this image of the hover tests. Aaron is on the left and actually flying it; I'm on the right and you can see the laptop on the ground.

In order to do away with the tether, we've purchased 802.11 cards for the onboard iPAQ, as you can see in image of Holly running the simulator. We should be able to send servo commands to the iPAQ and have it log the sensor data for us.

I've also built an interface to Futaba's "buddy box" trainer port. This will allow us to have the system in the loop for further tests, as well as allow our pilot to use a familiar controller rather than the USB joystick that we were using. I've taken a picture of the custom interface board and hope to have schematics online this weekend. Source code for the board is available in tinystick.S.

I'm rushing to get my prototype helicopter flying for a Fun Fly this coming weekend. I've taken some pictures of the Concept 60 loaded with the basic control hardware mounted. It won't be able to do much autonomously, but I'm hoping that we'll be able to use the "fly by wire" control software and collect flight data from the IMU. We might be able to use the yaw gyro in "heading hold" mode and the engine RPM governor, although my guess is that we'll do most of the flying under pure manual control. In any event, it will be interesting to compare the flight data with the simulator results.

The canopy won't fit with the curent board; we'll have to slim it down sometime if we want to enclose everything... The IMU is mounted underneath the tray but between the skids where it won't hit the ground. It should be fairly safe.

I'm hesitant to use the X-Cell at this time, since we've never flown it and I wouldn't want to have its first flight be disasterous due to a software bug or hardware glitch. The Concept is fairly well tuned at this point (thanks, Aaron!), so hopefully we'll be able to give it a good go.

NateW -- I like the look of your Juice simulator and am eagerly awaiting the free-software + Linux version. I would like to port my helicopter simulator math model to your framework so that you can simulate aerial robots, too.

Any more thoughts on when it will happen?

I've just started doing hardware-in-the-loop helicopter simulations with our flight controller software. The hardware platform for now is an iPAQ running Familiar Linux. This allowed me to move the controller from my i386 Linux desktop to the iPAQ with zero code changes. That is an amazing range of portability!

On the down side, the iPAQ is roughly 400 times slower than the Pentium 4 at 1.4 GHz, so it will require more tuning to run everything fast enough. Right now it is just running the four SISO PID loops based on the exact data produced from the simulator, but soon it will have to do it with simulated IMU data and then the real thing.

I also went through the code and made it all Unit and Reference Frame safe. Earlier I had converted the math library to be vector-size safe, which made common math errors compile time errors. Now it is a compile time error to add Velocity to Rotational rate or add Body frame velocity to tangent plane velocity. The code for this is in sim/src/mat/Frames.h. I've also written an overview of how to use the new library.

gear21: I also ordered my boards from ExpressPCB. They arrived two days later and were well made. The mini-board size fit my original design goals quite well and worked out without any problems.

Our next revision of the board will require SMD pieces and be more complex. I'm not sure what company does that sort of work in small (<10) quantities. Any ideas?

Thanks to some contributions of folks, we've been able to put together a helicopter simulator for Linux. It isn't photorealistic, but it does simulate many of the critical parameters that we need to tune the PID loops and test the Kalman filtering.

I've written some code that uses the inertial data from the simulator and PD and PID loops to hover the model helicopter (266kb MPEG). I'm now very eager to try it on the real thing, although I know it will be very different from the model.

My next step is to introduce "noise" into the simulator's outputs so that the control software has to deal with an unpredictable environment. I'm also going to add wind gusts that occasionally disturb the orientation of the helicopter to see how well it recovers. Hopefully these steps will make the code more resiliant once we do move it to an actual helicopter.

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

11 older entries...

Share this page