I have spent a lot of time looking around at all of the different models of autopilot from the simplest Arduino implementation to the most complex solutions in the $10K range. The thing that most of these seem to lack is modularity. I'd like to see the community come together to develop a "Main Board" and then a bunch of additional add-on components that are designed to work together with the appropriate code. As an example, say I want to start out with a simple main board, thermopiles and a gps, but them later decide I don't want the thermopile anymore and I want an IMU based system, and acoustic rangefinder for auto-landing - but wait, later still I want a system with a laser rangefinder, onboard video for FPV, and I want to log the data from a bunch of the components...obviously, I'd be throwing out a lot of hardware every time I wanted to learn more or upgrade. So how about it?? Who is in? I'm kinda liking the name ModuPilot..
Paparazzi definitely does not run Linux on the Tiny boards. Running an OS on the "inner loop" layer of any autopilot is unnecessary and detrimental. Why would you want to add that layer of complexity and the slow down associated with any OS? The advantages of it are heavily outweighed by the disadvantages.
I believe the best solution is what has been described by Chris. A separation of the control layers joined together with some sort of communication protocol.
After having talked to lots of autopilot developers about this, the only consensus seems to be that having an modular IMU, compute layer and payload layer makes sense. That's what we, AttoPilot, and everybody we talked to at NASA is doing. The only standard interface between them seems to be TTL serial or RS232 (lots of non-standard interfaces, too).
On the payload layer of the larger NASA UAVs, the modular interface tends to uses the PC104 standard.
None of this is plug and play, and mostly it just achieves electrical and mechanical compatibility. Code glue is custom as usual
I think as long as this thread stays on topic and doesn't become a "my AP is better than your AP" discussion, we are actually getting somewhere.
So what we are really talking about is getting to some standardization of sorts on the bus on which all of these "modules" communicate, with some processor(s)...so what would that look like? Which parts do you keep separate and which ones are integrated? I think it makes a lot of sense to have some redundancy too, if possible (I know, I know, more layers of complexity.) I'll throw together a quick diagram of where I think we may be headed, and we can go from there.
Paparazzi is running Linux on the Tiny 2.11 board? I know it's running Linux on the groundstation/laptop, but you seem to be suggesting it's running a full OS on the autopilot itself. True?
We just got back from a day with the UAV teams at NASA Ames, talking about a lot of this stuff. They use a wide range of autopilots, ranging from stuff developed in house to six-figure commercial ones. A lot of these separate the "inner loop" IMU/AHRS system from the "outer loop" control/navigation system and then some have yet another outer layer for payload management. NO autpilots use an operating system for inner loop stuff (IMU/AHRS). Some of the autopilots use Linux for outer loop stuff, but most do not use any OS at all (Like Piccolo).
I note that even Curt's autopilot doesn't use an OS for IMU functions, so our disagreement here may simply be over the definition of "autopilot". I don't think RTOSs are appropriate for the typical IMU/AHRS function that is the core of an autopilot, and it appears NASA agrees. But if you're willing to exclude that from the definition of "autopilot" and just assume that it's a black box plugging into a higher-level computing platform, the real-time demands get a lot more modest and I can see more modularity coming into play.
Originally MicroGear was built around the Xbow MNAV because that's what I had available, but recently I've been working on abstracting out these dependencies in preparation for supporting other IMU's. However, it's a tedious process because there are no direct replacements for the Xbow MNAV that are available The MNAV had 3 axis gyros, 3 axis accelerometers, 3 axis magnetometers, 2 pressure sensors, PPM signal decoder, ability to drive 8 (9?) output servos, and probably some other things I'm forgetting ... oh yea, an integrated gps.
So I've been working on piecing this functionality back together. Right now I have a Sparkfun 6dof v4 IMU on my desk and that looks very promising, although it's foot print for just the gyros, accelerometers, and magnetometers (lacking pressure sensors, gps, or servo control) is the roughly the same as the original MNAV. I've looked at an analog devices cube (I forget the part number) but that's almost twice the price of the sparkfun imu in single quantities and it talks SPI which I'm afraid of (at least if I'm trying to talk to it from a linux host.)
So this goes back to my previous statement, MicroGear isn't a recipe for an instant UAV. It is just one piece of the larger puzzle.
Well I know you guys have built a cell phone autopilot before...what about breaking one down into modules, and using that as a basis. I have quite a bit of Android development experience, so I will use that as a frame of reference. I could take the Dev Phone 1 BOM and break that down into sub components, add a few additional ones that are necessary for an AP, and have a VERY complete feature set with loads of functionality, and be well under $500. So I would have GPS, WiFi, Bluetooth, Cellular communication capabilities, a 3 megapixel camera, 6DOF IMU, compass, micro SD card expansion, ALL along with the raw processing power and the Android OS, programming model, open source community, etc. It will likely be a huge task to modularize all those pieces - but what a powerful platform that would be - and if you don't want any of those pieces, you can either just turn it off in software, or lose the "module."
Oh, I forgot to mention, if you want to poke around the MicroGear source code to see what it might or might not offer, I just migrated the source code repository over to here:
This is just one piece of a larger system ... don't expect to fetch the code and be up and flying by the afternoon, but I think that MicroGear could provide a solid software backbone for a modular system and it's structured in a way that is easy to add support for new sensors, new actuators, and new filters.
I don't intend to disagree with anything Chris has said, but let me describe the approach I've taken with my "MicroGear" project.
If you are focused on a $24 autopilot solution, then yes, you are working with very small embedded processors ... still amazing for their size, but without full operating system capabilities.
I personally have been focused on ARM7/ARM9 type processors (ex: gumstix.com) which do indeed give you a full blown linux operating system. If nothing else, this is really cool to have all that processing power, all that memory, all that storage (i.e. 1Gb MMC card) all in a very compact package and flying onboard your aircraft. There's a price ... a gumstix board with a few add ons can top out over $200 so now I'm comparing apples to oranges with Chris's perspective.
I do think a gumstix (or similar) style solution gives you tremendous power and flexibility. None of this is helpful though if there isn't software written to leverage all this power. This is where MicroGear comes into the picture. MicroGear development goes back to 2006 so it's not exactly fresh out of the starting gate. MicroGear has been proven with many hours of autonomous flight time, some of that entirely over water (including launch and recovery from a small boat.)
MicroGear leverages modern software and design principles. It has a flexible and adaptable internal mechanism for sharing data between modules. It supports multiple sets of sensors. It's even possible to rig up multiple gps receivers, multiple imu's and feed those through multiple competing filters to produce several attitude solutions. (Maybe you have a primary data path, and a backup path if something breaks.) MicroGear includes a very sophisticated autopilot control system that allows you to configure multi-stage PID loops, create triggers that will activate one set of PID's versus another ... so you could switch from elevator based speed control to throttle based speed control in mid-flight just by setting a flag (which can be done remotely from the ground station for instance.)
This might all sound pretty crazy to run onboard an aircraft, but take a stock gumstix "Verdex" running at 600mhz which you can get for about $149 last I checked, and all this code (including the IMU kalman filter) burns about 5% of the available CPU, leaving the rest left over for any number of other tasks you might be interested in doing. How about onboard image processing? Some sort of advanced navigation algorithm? A scripting system? Other sensor processing? What have you been dreaming about doing some day?
And it's running Linux, so it's possible to run other processes and applications concurrently with the autopilot (if you are careful in the setup and design.)
Going back to modularity. This is still a challenge. How do you connect up your sensors? What interfaces are available? The gumstix has a couple serial ports and usb. Depending on the board and configuration you might have access to bluetooth, i2c, spi, can bus, etc.
One cool thing (I thought) is I was able to connect a USB (hockey puck style) GPS to my gumstix, run the standard linux "gpsd" and immediately talk to it. I then easily modified MicroGear to talk to gpsd through it's standard interface, so now MicroGear can support just about any GPS (serial or usb) that "gpsd" supports.
The gumstix by itself does not offer a manual/autopilot rxmux type circuit. I don't think the older gumstix offer pwm servo support, a gumstix based system will probably not be a single board, totally integrated solution. This is why I hacked an ardupilot to do all the servo work for me. I plan to plug that into a gumstix and let the gumstix be the work horse, and the ardupilot be the servo control module.
So of course there are trade offs with any approach, but I have to give Chris a little "push back" :-) when he suggests that the ardupilot/shield arrangement will be the state of the art for the next decade. It maybe the state of the art for folks with a $25 total budget, but if you save up a few more of your nickels, then other interesting options (I think) are available.
I don't think autopilot technology is mature enough for the sort of plug and play approach described here. For one thing, autopilots typically don't have operating systems or a device driver layer. And all of the standard interoperability protocols assume there is intelligence in every device, which is not the case for sensors and most autopilot peripherals.
The way Arduino (and ArduPilot) works, with an intechangeable "shield" layer, is about as close as you're going to get for the next decade or so, I think. Anything more PC-like than that will be too big, expensive and inflexible. Just check out BugLabs as a Lego-like example of what you *don't* want in an autopilot.
Comments
I believe the best solution is what has been described by Chris. A separation of the control layers joined together with some sort of communication protocol.
On the payload layer of the larger NASA UAVs, the modular interface tends to uses the PC104 standard.
None of this is plug and play, and mostly it just achieves electrical and mechanical compatibility. Code glue is custom as usual
So what we are really talking about is getting to some standardization of sorts on the bus on which all of these "modules" communicate, with some processor(s)...so what would that look like? Which parts do you keep separate and which ones are integrated? I think it makes a lot of sense to have some redundancy too, if possible (I know, I know, more layers of complexity.) I'll throw together a quick diagram of where I think we may be headed, and we can go from there.
Paparazzi is running Linux on the Tiny 2.11 board? I know it's running Linux on the groundstation/laptop, but you seem to be suggesting it's running a full OS on the autopilot itself. True?
I note that even Curt's autopilot doesn't use an OS for IMU functions, so our disagreement here may simply be over the definition of "autopilot". I don't think RTOSs are appropriate for the typical IMU/AHRS function that is the core of an autopilot, and it appears NASA agrees. But if you're willing to exclude that from the definition of "autopilot" and just assume that it's a black box plugging into a higher-level computing platform, the real-time demands get a lot more modest and I can see more modularity coming into play.
So I've been working on piecing this functionality back together. Right now I have a Sparkfun 6dof v4 IMU on my desk and that looks very promising, although it's foot print for just the gyros, accelerometers, and magnetometers (lacking pressure sensors, gps, or servo control) is the roughly the same as the original MNAV. I've looked at an analog devices cube (I forget the part number) but that's almost twice the price of the sparkfun imu in single quantities and it talks SPI which I'm afraid of (at least if I'm trying to talk to it from a linux host.)
So this goes back to my previous statement, MicroGear isn't a recipe for an instant UAV. It is just one piece of the larger puzzle.
http://code.google.com/p/microgear/
This is just one piece of a larger system ... don't expect to fetch the code and be up and flying by the afternoon, but I think that MicroGear could provide a solid software backbone for a modular system and it's structured in a way that is easy to add support for new sensors, new actuators, and new filters.
If you are focused on a $24 autopilot solution, then yes, you are working with very small embedded processors ... still amazing for their size, but without full operating system capabilities.
I personally have been focused on ARM7/ARM9 type processors (ex: gumstix.com) which do indeed give you a full blown linux operating system. If nothing else, this is really cool to have all that processing power, all that memory, all that storage (i.e. 1Gb MMC card) all in a very compact package and flying onboard your aircraft. There's a price ... a gumstix board with a few add ons can top out over $200 so now I'm comparing apples to oranges with Chris's perspective.
I do think a gumstix (or similar) style solution gives you tremendous power and flexibility. None of this is helpful though if there isn't software written to leverage all this power. This is where MicroGear comes into the picture. MicroGear development goes back to 2006 so it's not exactly fresh out of the starting gate. MicroGear has been proven with many hours of autonomous flight time, some of that entirely over water (including launch and recovery from a small boat.)
MicroGear leverages modern software and design principles. It has a flexible and adaptable internal mechanism for sharing data between modules. It supports multiple sets of sensors. It's even possible to rig up multiple gps receivers, multiple imu's and feed those through multiple competing filters to produce several attitude solutions. (Maybe you have a primary data path, and a backup path if something breaks.) MicroGear includes a very sophisticated autopilot control system that allows you to configure multi-stage PID loops, create triggers that will activate one set of PID's versus another ... so you could switch from elevator based speed control to throttle based speed control in mid-flight just by setting a flag (which can be done remotely from the ground station for instance.)
This might all sound pretty crazy to run onboard an aircraft, but take a stock gumstix "Verdex" running at 600mhz which you can get for about $149 last I checked, and all this code (including the IMU kalman filter) burns about 5% of the available CPU, leaving the rest left over for any number of other tasks you might be interested in doing. How about onboard image processing? Some sort of advanced navigation algorithm? A scripting system? Other sensor processing? What have you been dreaming about doing some day?
And it's running Linux, so it's possible to run other processes and applications concurrently with the autopilot (if you are careful in the setup and design.)
Going back to modularity. This is still a challenge. How do you connect up your sensors? What interfaces are available? The gumstix has a couple serial ports and usb. Depending on the board and configuration you might have access to bluetooth, i2c, spi, can bus, etc.
One cool thing (I thought) is I was able to connect a USB (hockey puck style) GPS to my gumstix, run the standard linux "gpsd" and immediately talk to it. I then easily modified MicroGear to talk to gpsd through it's standard interface, so now MicroGear can support just about any GPS (serial or usb) that "gpsd" supports.
The gumstix by itself does not offer a manual/autopilot rxmux type circuit. I don't think the older gumstix offer pwm servo support, a gumstix based system will probably not be a single board, totally integrated solution. This is why I hacked an ardupilot to do all the servo work for me. I plan to plug that into a gumstix and let the gumstix be the work horse, and the ardupilot be the servo control module.
So of course there are trade offs with any approach, but I have to give Chris a little "push back" :-) when he suggests that the ardupilot/shield arrangement will be the state of the art for the next decade. It maybe the state of the art for folks with a $25 total budget, but if you save up a few more of your nickels, then other interesting options (I think) are available.
The way Arduino (and ArduPilot) works, with an intechangeable "shield" layer, is about as close as you're going to get for the next decade or so, I think. Anything more PC-like than that will be too big, expensive and inflexible. Just check out BugLabs as a Lego-like example of what you *don't* want in an autopilot.
-
1
-
2
of 2 Next