Older blog entries for hudson (starting at number 26)

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:

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.

Aaron Kahn and I did flight testing of our Rev 2.2 control boards over the weekend. I've performed post flight analysis of the flight data that recorded and posted the curated data. You can see the calibration run, the initial starting and liftoff, several pirouettes and sensor tuning steps, and an autorotation following fuel exhaustion. We damaged part of the accelerometer on due to a somewhat sudden stop. You can see the acceleration spike in the last graph.

I was able to snap a great many pictures of the helicopter in flight, and the best one of all is available as 1024x768 wallpaper image. Let me know if you like it!

We finally put together a group order of our control boards and the parts have started to arrive in bulk at my apartment. I've put together assembly instructions to show the other users how to solder the parts together and test them.

These boards are " feature packed " -- twenty 16-bit servo controllers, an LCD interface, a PPM decoder, three axis rate gyros, two axis accelerometers, three extra analog inputs, an NMEA GPS interface, an engine tachometer, a video overlay interface and a serial port. And, Pong! We had a few kb in the flash left over, so I wrote a pong game that is played with the PPM decoder and displays on the video overlay.

I have a few extra kits, if anyone is interested for US$120 + shipping. Here is the list of included parts list and a clarification.

802.11 had some range issues that need to be worked out for controlling the helicopter, so we're back to using the "traditional" interface. However, I have hacked my Hitec RCD3500 to output its PPM signal on a servo port and can now process it with our onboard systems. Here is an image of the jumper soldered on the receiver.

This means that the 802.11 can be used for data logging, while actual control will flow over the FM PPM stream. We can also use the switches on the transmitter to toggle between different modes of augmented flight control.

As I mentioned earlier, I've written some details on decoding the PPM stream and some source code for the AVR ATmega163.

I'm almost done with rev2 of my control board for my helicopter robots. Last week I redesigned the mainloop to make better use of the hardware available on the AVR MCU.

The first big improvement is using the hardware PWM generator to produce the PPM signal that drives the servos. A 4017 decade counter then divides the signal to ten servos. Since the Mega163 has two sixteen bit PWM outputs, we can drive twenty servos with zero interrupts and minimal CPU overhead. More importantly, the CPU overhead is "whenever" the mainloop gets to it, rather than having hard realtime constraints. The source code is in rev2/servo.h and here is an image of the board with the 4017 + 10 servos. As a side benefit, driving the twenty servos only requires three IO lines rather than twenty.

We can also decode a PPM signal in realtime with no CPU overhead thanks to the input capture feature on the MCU. I've written details on the PPM waveform and how to interface with it. The decoding source is in rev2/ppm.h.

There are other big changes. I need to finish the board design and have ExpressPCB fab up another set.

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.

17 older entries...

X
Share this page