Recent blog entries for hudson

I've posted a high res (5.9 MB) and low res (1.9 MB) QuickTime of the tuning process on our Bergen Observer. We ran out of time to fully smooth out all the oscillations and enable the collective control due to a tropical storm that moved in over Charleston, SC.

On the Nova we have position tuned to +/- 30 cm and altitude tuned to +/- 20 cm. The Observer is a bit more "pitchy", which is causing it to drift forwards and backwards. I'm hoping to get the CCPM code working with the JetCat mechanics soon and try tuning it on a turbine.

The onboard systems hovered Dennis' Nova helicopter for entire tanks of fuel yesterday! We closed all the control loops except altitude, so the throttle/collective were still under manual control. Despite a 20 degree magnetometer error, the flight controller managed to keep the helicopter within 1 m CEP during calm winds and 2 m CEP during gusts.

Onboard the Nova was our IMU / Servo controller, our three axis mangetometer, a Cerfboard with 802.11 CF, and our new u-blox TIM-LP / IO board.

We'll have movies and plots of the sensor data (plus overhead maps) available from autopilot.sourceforge.net. And Rotomotion will be selling IMU / INS kits and turnkey UAV systems based on the designs, too.

Fast on the heels of my 1-D Kalman Filter for tracking gyro bias and determining tilt angle in a balancing robot, I've checked in code for an entire GPS aided inertial navigation system. You can see the full source code for the 17 state Kalman filter in gpsins.cpp andgpsins.h.

This filter uses the 3 axis, 6 dof IMU from Rotomotion, a three axis magnetometer from PNI and a u-blox TIM-LP GPS. It computes position in a local tangent frame for ease of use with the flight controller and tracks both gyro and accelerometer biases. We all know about the gyro drift problems, but the ADXL units also have a slight amount of temperature drift that can be tracked by the filter.

I'm still doing static testing on the software and hardware. Hopefully within a few weeks I'll be able to flight test it on my helicopter. As far as I know, this is the only Free Software GPS aided INS in existance.

For folks building balacing robots like Dave Anderson's marvelous nBot or Larry Barello's gyrobot, I've written an extensively commented Kalman Filter that uses a dual axis accelerometer and a single axis angular rate gyro to accurately determine tilt angle, angular rate and gyro bias. The filter is able to be tuned for different amounts of noise in the sensors and to place varying trust in the different sensors. It also automatically tracks the gyro bias by comparing the covariance of the state estimate with the state measurement.

The full source code is in tilt.c and tilt.h. It is available under the GPL for your use and education.

I've just added Futaba and JR high-speed digital servo support to my autopilot control board. The Futaba servos use 275 Hz refresh rate, while the JR units use a 166 Hz rate. The data pulse is the same, between 1 and 2 ms long. This is a hardware upgrade that requires the new Rev 2.4 boards.

I also wrote a page that details the Futaba PCM format. We'll have a software-only upgrade to support PCM transmitters / receivers soon.

PCM decoding is working! I've managed to reverse engineer most of the protocol used by Futaba PCM1024 equipment and am now tackling the checksum and failsafe features. My code is able to accurately determine six of the nine channels fairly reliably, although some timing issues still remain.

Speaking of which, why can't they just use a regular serial protocol? There is a full MCU inside the PCM receivers, so it would be possible to include more useful features like start and stop bits, Manchester waves, sync points and such. Tracking an unknown 150 usecond bit clock over 30 ms is just asking for jitter and skew.

Full code is available from the CVS tree; a more details writeup will be posted on http://autopilot.sourceforge.net/ soon.

I've redesigned my controller boards to be more modular and fit in less space. Several folks wanted the inertial sensors to be separate from the microcontroller and servo interface, so I've put them on their own boards. You can see the preliminary files and images, although some changes do need to be made.

I have also been hard at work decoding the Futaba PCM radio protocol. It is far more complex than the PWM pulse train that is PPM and will require a software uart to decode. The important bits are that it uses a 150 usecond bit clock, a 2.7 msec sync pulse and two 120 bit frames.

These frames are then transmitted inverted, including the sync pulses. I suppose if there are any errors the frame is to be discarded. You can see this clearly in an image of the PCM frames. Each raster line is the four frames. The source code for generating this is in plotpcm, which uses the output of the microcontroller running onboard/rev2/pcm.c.

I've spent last night and this morning hacking on my Kalman filter code to process inertial measurements from my board's gyros and accelerometers.

We had several successful autonomous flights running the filter on my Linux iPAQ. I optimized the C++ AHRS code to produce a lean, fast version that will run on an 8 bit microcontroller. Right now it can sample the sensors at 60 Hz and produces an attitude estimate every 20 Hz. That should be good enough for jerky autonomous flight.

I'm amazed at how much extra speed there was to wring out of the code. The iPAQ has a 206 Mhz StrongARM SA-1110, while the 2.2 board has an 8 Mhz ATmega163, yet the speed difference between the C++ code and the C code is only a factor of five. Wowza! I guess the very clean templated Matrix math code is easier to read and write, but sure does add some speed penalties.

There is an banner ad encouraging me to try the ISOPOD. 40 MIPS is five times faster than the 8 MIPS I have now; it might be worth a try...

IT ACTUALLY WORKS! This weekend, Aaron Kahn and I flew the Rev 2.2 board on my Concept 60 helicopter. Unlike the past few weekends of sensor calibration and data collection, we turned on the autopilot software and it actually flew the helicopter.

The first day we spent tuning the control loops to remove oscillation in the pitch axis and slowly expanded the control authority that the software had. We destroyed a CF 802.11 card due to vibration and had to stop for the day. But it flew!

The second day we came back with new software that I wrote the night before. This allowed Aaron to give attitude commands to the autopilot rather than flight commands to the servos. The standard helicopter is flown by directly commanding the cyclic and collective (and throttle and anti-torque and ...). If you hold forward cyclic, the helicopter will nose over and do a loop or two before crashing.

With our software and hardware, he was able to instead provide attitude commands with his joystick. If he holds the stick full forward, it instead commanded the software to maintain 8 degrees nose down. If he released the stick, it would level out. Suddenly, it became a very flyable aircraft, rather than an unimaginable nightmare to fly.

Next weekend we'll have the compass and GPS hooked up, which should provide even better control. The GPS aided INS won't be running, but we will have a working heading hold.

I've curated flight data from Sunday and we have movies, too:

• Starting the helicopter
• One autonomous flight in pitch and roll
• Another autonomous flight

The Rev 2.2 IMU boards are being assembled by lots of folks and many of them have reported successful assemblies. I'm glad to hear that everyone has had such good luck so far.

Aaron Kahn wrote a six state Kalman filter AHRS that tracks gyro bias. We've found that the Toking CG-16D gyros have significant drift and temperature sensitivity, so this extra state is required. Full source code is available in sim/src/imu-filter/ahrs.cpp.

The code works great and tracked twelve hours of data with no problems. It runs at 62 KHz on my P4 and 70 Hz on my iPAQ. We'll be running with the iPAQ on the helicopter, so this is fast enough for realtime sensing. There is no FPU in the SA1110, so it is an enormous difference in speed between it and a desktop CPU.