Hacking the APM2 Part #1: Introduction


I would like to start off my first post in this series by briefly describing where I’ve been and where I’m going.  Hopefully this will give a bit of context to help understand subsequent posts and hopefully will help put my engineering decisions in some context.

History of the World, Part 1

Somewhere around 2005 I became very interested in aerial robotics.  I have always been an aviation enthusiast, I’ve built model airplanes since I was a kid, and I have been flying RC airplanes since high school.  At the time I was working for the Univ. of Minnesota and managed to get myself sent off to a training class for a little device called a Crossbow MNAV.  The MNAV was a small package that included mems gyros, accelerometers, altimeter, air speed, GPS, RC receiver PPM train decoding, and could control up to 8 servos.  It was perfect for building a small UAV autopilot.  As it turned out, even though the MNAV was pretty good for it’s time, it wasn’t perfect — and about 2 years later when I finally had my code up and flying successfully, Xbow announced they had discontinued the MNAV.

My autopilot code was written for Linux.  I had been running it on a 400mhz Gumstix processor (the really old one) and that talked to the MNAV over a serial connection.  The MNAV sent up the IMU and GPS data to the Gumstix which ran the attitude filter, autopilot, and navigation code, and sent servo positions back to the MNAV.  This worked rather well so I was pretty disappointed when the MNAV was terminated.

History of the World, Part 2

In a world with no MNAV I launched off on an adventure to build my own autopilot from off the shelf parts.  What made this possible was the original ArduPilot.  I could buy IMUs, GPSs, and processors off the shelf, but the ArduPilot gave me the ability to interact with RC servos, the RC receiver, and gave me a hardware failsafe mux, so whenever something went wrong with my code, I could immediately take over manual control of the aircraft.  As it turns out, this has saved me more times than I can count.

I ended up with a system built around the new Gumstix Verdex “pro”.  This processor ran at a whopping 600mhz and had enough number crunching power to run a full blown 15-state kalman filter at 50hz.  I connected a SparkFun 6DOFv4 IMU initially (ultimately upgraded to a VectorNav VN-100) for my inertial sensor, a ublox5 for my GPS, and of course the original ArduPilot for servo control.

At that time I hacked my own version of the ArduPilot firmware to talk directly to the Gumstix Verdex.  I left out all the AP stuff and simply used it to read the RC receiver and relay the pilot stick commands to the Gumstix, and then the Gumstix would send back servo positions to the ArduPilot which would take care of moving the servos to the specified positions.

History of the World Part 3

Time passes, a few projects came and went.  Now it’s 2012, and now the APM2 is released.  Compared to the original ArduPilot, the APM2 is a beautiful work of art!  It looks good, it packs on all kinds of high quality sensors, it has a powerful at mega 2560 processor, it is small, it is light, it is cheap, and it’s pretty well debugged because so many people are buying and flying them.

I decided it would be interesting to revisit my old autopilot design and modernize it based on the new APM2.  Any set of engineering decisions has plusses and minues.  Embedded autopilots are always a delicate balance between, size, weight, cost, capability, power requirements, etc.  And within those larger parameters, every architectural choice has subtle implications related to performance, latency, precision, capability, development tools, integration issues, unexpected surprises (good and bad), and on and on. On the one hand, there is a huge matrix of possibilities, and on the other hand specific choices have cascading effects and lead you in specific directions.  In the end, the goal is to find that magic balance of choices that lead you to an ideal outcome without sacrificing too many things along the way.

Looking to the Future

Where am I going with all this?  What do I envision my autopilot will look like at the end of the process?  Here is a quick summary:

  • An APM2 with firmware rewritten to simply collect all the sensor data and pass it up stream to my Gumstix for actual processing.
  • A Gumstix Verdex (1Ghz Arm) with hardware floating point, 512Mb of RAM
  • Linux based Autopilot software that includes a full 15-state kalman filter, XML configurable PID system, and advanced mission/task system.
  • Everything running at 200hz.
My work on this project has begun.  There are many challenges and unknowns that have already been met and solved, and I’m sure a few remaining challenges hiding on the other side of the horizon.  This just scratching the surface — I have been flying autonomous RC planes since 2007 with a variety of sensors and processors.  The autopilot itself is certainly a goal for me, but it is also a doorway we have to pass through to be able to work on so much more.

I plan to continue this “Hacking the APM2” series with future posts describing interesting things that I’ve learned or issues that I’ve solved along the path; culminating (hopefully) with a “Super ArduPilot Mega 2 on 1Ghz ARM Steroids” based autopilot system.

Join the Conversation


Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.

  1. I’m using an old MNAV and Stargate autopilot from Crossbow in a drone project. Does anyone have a Kalman filter program in Matlab or any other software to get the position and orientation of the aircraft with no errors?
    send me a note at: aramirez@ucalgary.ca

    1. Hi Alex, of course there will always be sensor noise and bias so there will always be some errors. I think the U of MN aerospace engineering department has a UAV group that has done some work with kalman filtering. You could try exploring their web site and code repositories. Honestly though, the old stargate does not have much cpu power and I don’t believe it has any floating point hardware, so all floating point math is done slowly through a software library. I don’t believe the stargate has enough cpu power to run a full 15 state kalman filter. The old MNAV project did have some attitude estimation code (also kalman filter based, but with far fewer states) and that was specifically designed to run within the processing limits of the stargate. I think you would do much much better throwing out the stargate and connecting your mnav to something like a beaglebone or raspberry pi. You can also do a whole lot better than the MNAV for sensors these days too. I’m happy to answer questions as best as I can for free, but I also do UAV work as part of my day job, so if you need a consultant on your project I think I could get you up and flying with far better sensors and processors and a full 15 state kalman filter that accurately estimates roll, pitch, and “true” yaw (not influenced by noisy or erroneous magnetometers.)

  2. Hi, this is a fsacinating project, and you have a talent for explaining clearly. What you are doing makes complete sense, since the APM2 is close to its processing limit with that old AVR chip.

    Are you planning on open-sourcing the project, or are you developing a product for sale? I’d be interested either way.

    Thank you!

    1. Hi Adrian, thanks for your kind words. Yes we are currently developing this as a product. the bread board system you see in the 5-part series of posts has been replaced with a dedicated circuit board that all the components plug into, eliminating all the interconnection jumper wires. In addition we’ve added power management so you can power the entire board directly from your flight battery (and in the mean time 3DR have also offered their own solution to providing power to your avionics.) This past week we have been test flying rev2 of our system to clear the way for a few more updates for rev3. The system isn’t officially for sale yet with a definite price, but we are heading that direction.