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..
Funny how were back to the bottleneck being the RS232 standard. Here's a hint. RS232 has a fabulous history and zero future. This is increasingly the case as plane size gets smaller. rs232 is the antithesis of modularity as it is a "saturated" connection in organic chemical parlance: there is no room to add another node once the ports are occupado. If on the other hand I2C were the dominant bus, then one could add another device at /any/ point in the plane. Want to add a sensor or payload; connect it to the nearest component, you never need more than four wires going to any extremity of the plane. Four wires to each wing would support wing lights, airspeed sensors, flaps, ailerons, and gear etc.
If you ran the system on an i2c bus, you could add a datalogger, by merely tapping the i2c. You could add many features by tapping the central cortex, and simply adding the missing sensors or other functionality.
The current trend toward saturated connections is an engineering dead end - and leads to very little network effect. If paparazzi, otto and ardu say for example, used the same i2c addresses for ir, imu, gps, servo controller, and downlink, then these modules would have a larger market, lowering their cost - while create a market for common exenders such as osd and dataloggers, moreover it would allow for payloads to make use of the attitude estimating subsystem.
One could probably experiment with such a system using ardupilot boards as nodes, one could be an I2c servodriver, another could be an ir/imu, and a third could be the "outerloop", The experiment would be complete if the only connections to the outerloop cpu were I2C, and thus all data were necessarily present on the I2C. At that point, one should be able to add servos/etc anywhere, by adding an Ardumodule and connecting the servos/lights/sensors.
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?
I do not want to start an autopilot war here, but I must tell you the Paparazzi project is in fact modular and quite sophisticated. It runs on ubuntu, I can use a full linux OS behind it, I can fit it in a very small package and make it quite portable to run in the aircraft. It allows true 2 way comms, allows for multiple aircraft to be controlled simultaneously and the autopilot side of the hardware on the highest end is sub $1000 USD. I think we have an incredible high end autopilot with paparazzi, and it has been used in many complex DOD and MOD projects to date. So if the gov't is testing it, it must be pretty darn good. I have also seen many for profit UAV companies take paparazzi and customize and re-launch as their own UAV Autopilot. Won't mention any names here, but a post not long ago on here comes to mind :)
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.
1. as for an autopilot that has extra cycles for other things the user "might want to do". Bad idea - going nowhere I hope. - Why? Because in that case, the system design is always changing, and never tested. In a flight platform, it is better IMO to have separate physical devices / cpu for different operations. So an autopilot should be designed on the least power-hungry platform which can achieve the end result.
2. A Bus & Protocol would in fact be useful. Take for example the EXIF format in which camera data is pushed into a jpeg file, it contains GPS, and Accelerometer data (orientation), all camera use the same format, and as a consequence, software can support these data points. I would like to see an SPI or I2C bus with some protocols which allow imu's gps, servos, ESC, xbees, rc receiver, etc... to be laid onto a common wire pair, and the data consumed arbitrarily by any module.
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.
Comments
Tak a look at http://wiki.uavos.com system. It uses CAN bus to communicate between nodes and Linux OS with Gumstix SBC.
If you ran the system on an i2c bus, you could add a datalogger, by merely tapping the i2c. You could add many features by tapping the central cortex, and simply adding the missing sensors or other functionality.
The current trend toward saturated connections is an engineering dead end - and leads to very little network effect. If paparazzi, otto and ardu say for example, used the same i2c addresses for ir, imu, gps, servo controller, and downlink, then these modules would have a larger market, lowering their cost - while create a market for common exenders such as osd and dataloggers, moreover it would allow for payloads to make use of the attitude estimating subsystem.
One could probably experiment with such a system using ardupilot boards as nodes, one could be an I2c servodriver, another could be an ir/imu, and a third could be the "outerloop", The experiment would be complete if the only connections to the outerloop cpu were I2C, and thus all data were necessarily present on the I2C. At that point, one should be able to add servos/etc anywhere, by adding an Ardumodule and connecting the servos/lights/sensors.
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.
1. as for an autopilot that has extra cycles for other things the user "might want to do". Bad idea - going nowhere I hope. - Why? Because in that case, the system design is always changing, and never tested. In a flight platform, it is better IMO to have separate physical devices / cpu for different operations. So an autopilot should be designed on the least power-hungry platform which can achieve the end result.
2. A Bus & Protocol would in fact be useful. Take for example the EXIF format in which camera data is pushed into a jpeg file, it contains GPS, and Accelerometer data (orientation), all camera use the same format, and as a consequence, software can support these data points. I would like to see an SPI or I2C bus with some protocols which allow imu's gps, servos, ESC, xbees, rc receiver, etc... to be laid onto a common wire pair, and the data consumed arbitrarily by any module.
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.
-
1
-
2
of 2 Next