Hacking the APM2 Part #4: Laying out a “hybrid” system

Imagine for one second that you are a UAV developer. The DIYdrones ArduPilot is an awesome piece of hardware; you love all the great sensors that are attached; you love the all-in-one design and the small/light size.  But you are also feeling the limits of it’s ATMega 2560 processor and the limits of it’s 256Kb of RAM.  And maybe, you enjoy developing code within a full blown Linux developers environment with all the supporting libraries and device drivers that Linux has to offer.

Hardware Layout

Here is a picture of a protype “hybrid” autopilot system for small UAV’s.  What you see in the picture includes:

  • An ArduPilot Mega 2.0 (lower left)  The APM2 includes an MPU-6000 IMU, a Mediatek 5hz GPS, static pressure sensor, compass, and a variety of other items.
  • A 1Ghz Gumstix Overo with a Pinto-TH expansion board. (longer thinner board, upper right).  The Overo runs Linux, has 512Mb of RAM, and has a hardware floating point processor.
  • An MPXV7002DP pressure sensor (upper left).  This is attached to a pitot tube and measures airspeed.
  • A Sparkfun TTL level translator (between the overo and the pressure sensor)
  • A Futaba FASST 6 channel receiver (lower right)
  • A set of power distribution rails (8×3 block of 0.1″ pins.)
  • [not shown/mounted remotely] Digi Xtend 900Mhz radio modem.

The above picture was deliberately taken without most of the wires to show the components.  Once all the wires are connected, things will look much more “busy”.  This is a prototype system so the components will be jumpered together, probably with a bit of hot glue here and there to ultimately secure the wiring before flight.

Software Layout

Just as important as the hardware layout is the software layout.  This is maybe a bit more boring and I can’t really take a picture of it to post here, but I will give a few bullet points for anyone who might be interested.

  • The APM2 runs a custom built firmware that simply collects all the sensor data, packages it up into checksummed binary packets, and sends the data out over a uart.  In addition, the APM2 reads checksummed binary packets inbound over the same uart.  Generally inbound packets are actuator commands.
  • The Overo runs a custom built autopilot application that is portable.  It is not device/hardware independent, but it is designed to talk to a variety of hardware over a common interfaces.  This Linux-based autopilot app can read all the sensor data from the APM2 (being transmitted at 100hz over a 500,000 baud link.)  The autopilot app runs a computationally intensive 15-state kalman filter.  Manages the mission tasks, computes wgs-84 great circle navigation targets, runs the low level PID code, and ultimately sends servo position commands back to the APM2 over the same 500,000 baud link.
  • The high level autopilot software runs in an environment that is more natural and has more power/space for developing the “high concept” portions of the code.  The APM2 is great for reading a bunch of sensors really quickly.  In a hybrid system both major components are able to do what they do best without having to suffer through tasks they aren’t as good at.
  • The high level autopilot is configurable through a structured XML configuration system.  It includes an advanced 15-state kalman filter.  It runs the same PID code configured in the same way as the FlightGear flight simulator.  It also includes the same “property system” that FlightGear pioneered.  It includes a rich set of IO API’s, and hopefully will soon sport a built in scripting engine.
  • A word about the “property system”:  The property system is an in-memory tree structure that relates “ascii” variable names to corresponding values.  There is loose type checking and on-the-fly type conversion similar to many scripting systems (I can write a value as a ‘string’ and read it back out as a ‘double’ and the system does sensible conversions for me.)  Any internal module can read/write the property tree, so it is a great way to build “loose” interfaces between modules.  Modules simply reference the values they need and there is no compile time enforcement.  This allows for building “robust” interfaces and eliminates much of the cascading changes throughout the code when a class gets updated.  In addition, we can build external network interfaces to the property system which allows external scripts or other code to monitor and even modify the property tree.  This allows external scripts access to the core values of the sim and access to set modes and otherwise “drive” what the autopilot does.  In addition, there is a natural one-to-one mapping between the property tree and an xml config file.  This is handy for easily loading/saving configurations.  At a low level, property system variable access from the core code is simply a pointer dereference, so using these values is almost as fast as referencing a locally scoped variable.  It is hard to describe in a few words what all the “property system” is or does, but it’s an amazing infrastructure tool that helps build flexible, robust, and high functioning code.

September 7, 2012 Update:

Here is a picture showing the whole system plugged together with 6″ sparkfun jumper wires.  The wiring gets a little “busy” when everything is connected together so I plan to do some work buttoning things up, simplifying, and cleaning up the wire runs.  I’ve attached 3 servos to test auto vs. manual outputs.  You can see a 900Mhz Xtend modem (1 watt power, 115,200 baud), and the entire system is powered by a single RC receiver battery.  In the aircraft this should all run just fine off the BEC.  And here is a video of everything in action:

That’s about it. The modified APM2 firmware is happy and running.  The overo autopilot code is up and running and talking to the APM2.  Next up is validating the radio modem ground station connection, and then I’m running out of things to do before dropping this into an airplane!

September 17, 2012 Update:

It’s far from a perfect integration, but I spent some time this evening bundling up wires.  Definitely an improvement.  Working towards full integration into a Senior Telemaster (electric powered) and hope to do some first test flights later this week.  Today I test fit everything, powered everything from the main flight battery and verified basic control surface movements in manual mode and autopilot mode.  The radio modem link is running and the mapping and instrument panel views on the ground link up and run.

16 Replies to “Hacking the APM2 Part #4: Laying out a “hybrid” system”

  1. Hi Curt,

    I am a student working on a similar project. I want to connect Gumstix Overo with APM 2.6 through a I2C port since I dont’s have any serial port left in APM. I see from your post that you had used serial communication between your APM and Gumstix. Do you have any suggestions on how to connect Gumstix Overo to APM 2.6 through the I2C port? Your suggestion is greatly appreciated.


    1. I’m sorry but I know very little about i2c. I know you need a master and a slave, but I’m not sure either gumstix or apm can act as an i2c slave. Maybe it’s possible, but it’s out of my area of knowledge. You might also consider a beaglebone which I believe exposes 3 or 4 serial ports. Good luck, juggling all the inputs and outputs for an embedded project is one of the tricky parts.

  2. This is awesome!! I’m looking to do something similar but with a Raspberry Pi instead of a Gumstix board. Do you have any suggestions? Also- did you write the custom APM code yourself or is it hosted somewhere? I’m starting from scratch and just looking into things at this point.

    1. Hi Jake, I used the APM2.5 sensor libraries and then wrote my own app on top of that to collect the data and relay it to the linux system upstream. It’s not hosted anywhere right now. This was developed as part of an internal work project so we haven’t really tried to turn it into a ‘for sale’ product or think through distribution. I’ve never used the raspberry pi myself. My understanding is the gumstix uses a higher end processor running at a faster clock rate, but then also costs correspondingly more. On the linux side I’m running a 15-state kalman filter so that enjoys the extra processor headroom the overo offers — that algorithm might be cutting it close on a pi, unless I ran everything at a slower update rate.

      1. Hey Curt,
        Thanks! That’s what I was wondering. I don’t really want to make an autopilot- I just want to read all the sensor data from the APM2.5 and log it to a database on the raspberry pi. After more reading it looks like the only way to do it is with the APM libraries. I’m assuming you just wrote a .pde?

        1. Hi Jake, I wouldn’t say the *only* way to do it is through the arduplane libraries, but I felt that was the path of least resistance. Theoretically you can update to newer library version as the arduplane team releases new code. Practically that’s a bit of a challenge because they can change a lot of things and you have to do an extremely careful review of each new change and thoroughly test before integrating it into your own code base. With software it’s way too easy to break an otherwise well functioning system. That’s one of the challenges of life and engineering I guess.

  3. Hi, thanks for your article. I am trying to set up a similar system (hybrid system with gumstix) for my research project. So far, I am using sample data to test my software on gumstix. I now need to interface a sensor unit with this COM to build a complete autopilot. I came across navstik (www.navstik.org), which seems quite compact and suited for my project. Also, it is based on STM32, which is a big plus. Do you have any experience in using it? If not, do you know of any other hardware (besides APM) that would suit this purpose (sensor board for Gumstix-autopilot)?

    Thanks a lot for your help.

    1. Hi, I do not have any personal experience with the navstik so I can’t really say anything useful about that. In an earlier project I did connect a VectorNav VN-100T to a gumstix processor. The VN-100T is a very nice IMU that is temperature calibrated (this can make a really big difference in the performance of your attitude estimate filter.) Gyros can be field calibrated pretty easy to current conditions, but accelerometers are really difficult to get a good field calibration. I’ve also connected up gps’s and other devices directly to the gumstix. But the challenge there is you start running out of uart and spi ports very quickly. That’s why I took a look at the APM2.5. They have pretty decent sensors packed up in a small/inexpensive package and you can get access to them all through a single uart port on the gumstix. I wrote my own custom firmware for the APM2.5 to just collect raw sensor data and pass it upstream to the gumstix. Oh, and in addition, the APM2.5 gives you the ability to read the pilot stick inputs via the RC receiver and command servo output and do the auto/manual failsafe mux, all on the same single board that includes all the sensors. So for the purposes of building an autopilot, I think the APM2.5 is going to be pretty hard to beat. If you do run across something you think might be better, or if you do decide to try the navstik, I’d love to hear about your experiences. (Now that I take a look at the navstik web page, I do recall seeing these guys back when we were trying to decide what direction to go, and I don’t recall specifically why we decided not to use them, but for whatever reason, on the whole, we decided for our project the APM2.5 was going to be a bit better fit.)

      1. Thanks a lot for the detailed response!

        It is really great to learn about your experiences in building a hybrid system with gumstix. I am considering using a hierarchical distribution of tasks, eventually. For this, I would prefer to use an independent unit for gathering sensor data and basic uav-control (real-time tasks), and reserve the use of gumstix for computationally intensive tasks. So, I would need something more than just VN-100T (bare sensor). Its pricing seems a little steep, too.

        It seems that I am pretty much left with just two options, APM2.5 and navstik. While APM2.5 seems to be the de facto standard for UAV automation, navstik seems somewhat new. Although, it does seem offer a good set of features, esp. tight integration with gumstix overo (no need of gumstix expansion board), really small-size, and 32-bit STM32 processor with RTOS (vs. 8-bit AVR on APM2.5). They are also both priced in the same range (navstik is somewhat cheaper). Let me see if I can find some projects using navstik.

        Thanks again for your help. I will keep you posted on how it goes.

        1. Just some random thoughts in reply. I think (I could be mistaken, but I think) there was some issues with fragility of connectors on the navstik and the way everything stacks up into a complete system. The navstik has been around for a while, probably it existed (largely in it’s current form) before the APM2 (and now they are up to APM2.5). 3DR makes the APM line, and now they are moving to the PX4 platform so that might be worth taking a look at. We are located in the USA so for us, dealing directly with a USA company has some advantages (similar time zones, lower shipping costs & delivery times, etc.) But bear in mind all of these comments are made without the experience of actually purchasing a navstik and trying to make it work (so it’s all purely speculative.)

          The VN-100 is pricey, but you get temperature calibration over a wide range of temperatures. That isn’t 100% necessary, but yields significantly better performance and faster convergence of your attitude estimation filters. It may not be a big deal for your application, but for professional applications that need high quality flight control, it could be important.

          1. I did a little more digging up on all the modules. Navstik seems to have been released in sept/oct 2012. It seems quite recent (using STM32 and MPU6000, etc.), and there are few users who seem to be using it. I found a video on youtube of a co-axial MAV flying with navstik.

            PX4 looks very promising (32-bit processor, Nuttx OS, larger user-base). In fact, both PX4 and navstik seem to have very similar hardware specs (same processor and sensors), though different designs. The problem is that if I go ahead with PX4, I will still need to use an expansion board for gumstix, and then interface gumstix with PX4 using wired connections. PX4 also does not have an onboard GPS or an airspeed sensor. Those have to be externally connected, as well. So, there will be too many boards, all connected using wires.

            I think, this is where navstik wins. It seems to offer everything on a single board (same size as gumstix). Even the GPS and airspeed sensors are directly mounted on the same PCB! Plus, gumstix can be directly installed on it.

            While PX4 is available from 3DR in US, navstik has to be ordered from abroad. However, they seem offer fedex international priority (3-5 day). So, it should pretty much take same time to deliver. I am feeling a more inclined towards navstik after my study, so far. But let me do a little more research before I take a call.

            I also tried to investigate VN-100T further. It essentially has the same quality sensors that are used on APM2.5, navstik or PX4. All they do is “calibration”, i.e., implement the correction factors in software for temp compensation, etc. (I mean, they are not really offering higher quality accelerometers or gyros, as such). This seems doable on any other board, as well. It sure will take some time and effort, but from hardware point-of-view, all other systems seem to offer exactly same capability (at fraction of the cost)!

          2. Hi Alison, thanks for the information. Just a couple quick comments in reply. (1) if you don’t need temperature calibration, then I agree that there’s no point in paying a premium for that, but having worked with both calibrated and non-calibrated sensors, I wouldn’t minimize the importance of calibration (nor the difficulty and time required to do it well.) Essentially the performance of your vehicle is limited by the performance of your sensors. Non calibrated sensors can have a bias (constant offset) and also a scaling error. MPU-6000 can be off by +/- 1-2 m/s^2 in any axis before calibration. So if you are using accelerometers to help determine your roll/pitch, that can put you off by many degrees (just for example.) Hopefully you have a kalman filter or similar that estimates the bias of your sensors over time, but even so, running with a calibrated imu means your filter has to work a lot less hard and can converge far quicker (and dealing with scaling errors on top of bias errors gets pretty complicated.) But that said, you can definitely go with uncalibrated sensors and make them work. (2) Sounds like the navstik is evolving and being updated since I last took a look so that’s good news. (3) depending on your telemetry (or video transmitter) locations, or other locations of things on your aircraft, the ability to remote the gps receiver/antenna can be a feature. If you have to mount everything inside a carbon fiber airframe for example, an integrated gps may not be such a feature any more. Thanks for taking the time to share the information you have found!

  4. Hi there,

    I’m a student working on a UAV project. I read that you have experimented with Gumstix + VectorNAV-100 (which we’re intending to use). What is your experience with this combination? Did you use SPI or UART communications?

    I’m new to the DIY electronic scene, so any help is much appreciated. Email will be best! Thanks!

    1. The VN-100 is a good sensor, and the temperature calibrated version is even better. I’ve done both uart and spi communication between the vnav and the gumstix. Uart was the easiest and is probably the path of least resistance if you have an open uart on your gumstix to use. SPI also works well, but for me was trickier because I’d never hooked up an SPI device before and I then discovered I had to write my own SPI driver to get the communication to work. Scott has posted some great spi tutorials @ jumpnowtek.com and I was able to follow through those and get the communication running. But there are timing and work load challenges and I could never get the SPI communication rate up as high as I wanted before I maxed out the CPU load. It seems odd, but linux has a kernel vs. user space setup and SPI happens in kernel space, but your application runs in user space. So there are some issues you have to pay attention to with querying the device in kernel space vs. exchanging data with user space vs. the 100hz tick rate of the overo vs. kernel work load — and the end result was that the spi query performance was not what I had hoped. My preference is to use something like an arudiuno chip to do the low level device communication and save the gumstix overo for the higher level number crunching and coding.

  5. I don’t think I have the versiion with encryption and mesh network, but for a point to point wireless serial connection it works pretty well. I don’t get 115,200 baud through it in the field, but I haven’t spent time playing with the configuration much either — I think it has a low level protocol that retransmits things and checks validity of data so that probably is adding some overhead for me. But it’s mostly fast enough for what I need. So yeah, they are a lot more expensive than an xbee, but faster and have always worked well and been solid. Oh, and they’ll do 3v and 5v TTL without any horsing around, and in my latest experiments it seems like they even handle 1.8v TTL without any glitches. So I can’t say if they are better than something else, but they are solid and haven’t given us any reasons to go looking for anything else.

    Oh, that said, I have eyeballed some “IP” modems which are even more expensive, but being able to do longer range ethernet comms to the UAV would be pretty sweet. ssh in remotely, scp files back and forth “on the fly”, but I figure I can’t have everything all at once — that wouldn’t be fair. 🙂

  6. Whats your thoughts about that Digi Xtend 900Mhz OEM radio? Does it perform well in the field? The AES Encryption & Mesh Networking seems perfect for UAV control.

    I am working on a simular project to yours; those modules might just be worth the expense.

Leave a Reply

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

Time limit is exhausted. Please reload CAPTCHA.