First tests of APM on a RaspberryPi
Andrew Tridgell
September 28, 2013
First tests of APM on a RaspberryPi using an Oil pan for sensors on SPI and I2C
Andrew Tridgell
September 28, 2013
The RPi isn't actually a great board for this, but it has the advantage that I have one! I'm waiting for my BeagleBone Black to arrive, which has a lot more GPIO, plus hw PWM and some nice realtime co-processors.
Andrew Tridgell
September 28, 2013
The APM HAL port is here if you are curious: https://github.com/diydrones/ardupilot/tree/master/libraries/AP_HAL_Linux
Curtis Olson
September 28, 2013
Our hybrid APM2.5 + Overo (800Mhz ARM) system has been trucking along and performing very well for us. There are tons of way to divide up the work load, but I just rewrote the APM2.5 main() trying to reuse as much of the library code as possible and turned the APM into what I call a "sensor head". It just reads and reports the sensor values, and then receives servo commands and drives the servos as well. I do all the heavy lifting, kalman filtering, navigation, mission, communication stuff on the Overo (running linux) .. and at that level I can crunch a lot of math, use spherical geometry for navigation, run a 15 state kalman filter, pull in the FlightGear 'property system' (which is a in memory hierarchical key/value tree ... makes inter module communication and external scripting, config files, etc. a breeze ... well flexible and powerful anyway. I personally stay away from threading ... that's a design choice. I can do threading just fine (heck I have a master's degree in computer science even.) But I don't trust that I can remember all the threading order and locking nuances 6 months from now, and I certainly wouldn't trust anyone new catching all the subtleties. So I use non-blocking IO on everything and run my master loop at 100 hz ... and leave all the sensor IO to the APM.
But that's just the way I've done it... lots of other great ways to design autopilots as well and every approach has it's strengths and weaknesses.
Andrew Tridgell
September 28, 2013
yep, good approach given you already have the fg code that you are familiar with.
The reason I'm doing it with a direct APM port is that means we can run the same autopilot code on a 16MHz APM1 as we run on a 1GHz beaglebone. We can still take advantage of the extra CPU and memory though, as we can have alternative modules for each part of the autopilot which can be switched in mid-flight. So once we add in a Kalman attitude/position filter we'll be able to run it in parallel with our existing DCM system and switch between which one is controlling the plane mid-flight. On the APM1/APM2 you just won't be able to switch in modules which can't fit in the resources of that board.
We've already been doing this (in-flight backend switching) with our navigation, speed-height and attitude controllers. It is a great way to test a new module - takeoff with the old module, then switch on the new module and see what happens. If it doesn't do well then switch back again.
Right now we run on 7 different types of boards (APM1, APM2, PX4, Pixhawk, Flymaple, Linux and SITL) and I expect we'll get more ports soon.
Andrew Tridgell
September 28, 2013
make that 8 - I forgot the VRBrain port. Sorry Roberto!
Curtis Olson
September 28, 2013
Lots of ports is generally a good thing. Every compiler and platform catches/exposes slightly different things.
Andrew Tridgell
September 28, 2013
yep. This Linux port is particularly good for bug-catching. It's the first time I've been able to run our SPI and I2C drivers under gdb and valgrind.
Curtis Olson
September 28, 2013
Are you happy with your spi driver performance under linux? My spi drivers I setup for the VN-100T (to run on an overo/arm) started to bottleneck at about 130-150hz (from memory) and at those speeds I was pulling 100% cpu with nothing left over to do anything else. But that was my first (and only) SPI driver I had ever written, so I could have been doing something dumb/naive. I was following a tutorial I found on line that showed how to develop a simple spi driver called "spike". One of these days I'd like to revisit that, because I still have a temp calibrated VN-100T sitting here not being used mainly due to my driver writing deficiencies.
Andrew Tridgell
September 28, 2013
The SPI performance on the RPi isn't great. I'm using the spi_bcm2708 kernel driver which comes with recent RPi builds. I'm running the bus at 2MHz, sampling the accels/gyros at 1KHz, transferring 17 bytes per sample. It causes 60k interrupts per second. Looking at the driver source it's clear the chip does have a FIFO, which makes it a bit surprising it generates 3 interrupts per byte. I suspect the higher level driver isn't taking full advantage of the chip. It uses about 30% of the CPU on the RPi. I'll have a bit of a poke at it.
I'm hoping the driver on the beaglebone black will be a bit better.
Copyright 2013 Andrew Tridgell