At the recent LCA'2014 conference in Perth I gave a couple of talks about research projects I'm working on with ardupilot. These show a couple of the things that we are working towards with APM.
The first is a talk on differential GPS which is part of a collaboration between Ben Nizette at ANU and myself.
Video:
https://www.youtube.com/watch?v=sl8aJlG52PE
Slides: http://uav.tridgell.net/LCA2014/dgps.pdf
The second talk is about the research project to run ardupilot directly on embedded Linux boards, which opens up some really interesting possibilities for APM:
Video:
https://www.youtube.com/watch?v=ealH3qP_pBE
Slides: http://uav.tridgell.net/LCA2014/AP_Linux.pdf
These projects are really just a small part of what we are working on, but I thought a few people might be interested in them.
Cheers, Tridge
Comments
great stuff :)
btw, have you seen pcduino v2 board with wifi? That one looks promising to me
Hi Andrew.
I didn't actually think it was a trivial task, but one of the more serious problems we face is going to be getting aircraft actually "certified" for use and fly by wire systems traditionally suffer from weakest link in the chain realities.
We are already building in a small level of redundancy with back up sensors (recently up to three) which makes it possible to continue even in the event of failure.
And we have failsafe code running that can do an RTL or land or some other remedial measure.
I am sure the Grumman, Boeing and Northrup are all running something similar to the architecture I have shown above. (If they aren't they are Damn fools.)
And Nasa has been using it almost from the beginning (with 8080's and Z80's I might add).
And frankly if the FAA is ever going to approve flight systems for non-LOS use in our airspace they are almost certainly only going to approve vehicles containing the sort of architecture I have shown.
The voting or decision architecture is only as difficult, complicated (and robust) as you desire to make it.
It can be as simple as assigning one flight controller processor to run everything, setting the others to low power standby mode and simply checking their heartbeat periodically.
Or having one controller performing primary flight operation with the other 2 running passively but cross checking for significant discrepancies and switching or isolating the primary controller as necessary.
Or full interactive with realtime averaging and boundary condition checking looking for any indication of divergence or failure and then switching out the offending processor.
With the architecture I have shown, only one flight control processor is actually controlling the outputs in any case.
From the current primary flight controllers standpoint it only has to check that the other controllers are running within nominal parameters and the other fight control processors each only have to check if the primary controller is working within those same parameters.
Other than that resources can be shared as available for increased accuracy as desired (GPS for instance).
And the system I have shown is also capable of being switched manually from the ground at any time by a fully redundant radio system as well.
Any one flight processor unit should be capable of providing at least complete failsafe actions and could also even be fully capable of completing a mission. (Maybe 2 levels of controller, but reality is that with cheap tiny micros, there is really no reason each controller shouldn't be fully capable.)
Most Missions can be most appropriately terminated and failsafe return initiated, but some are critical and should attempt to continue regardless.
Of course the military is using this, but the fact is it is even more necessary for civilian safety issues (and our regulatory agencies are painfully aware of this).
And the MCP (Master Control Processor) is really just there to provide enhanced (non-flight critical) functionality and can itself be locked out by the flight control processors at any time.
A few years ago I looked at this architecture as being too expensive, too large, too power hungry and just too failure prone to be even remotely practical, but the reality is if the same resources we are using were dedicated to making this available to the public we could bring it in well under $1000.00 and 3DR would still make it's profit on it.
I would actually think a connector stacked architecture (think 3 modified PX4's plus an MCP module and a output logic combiner module optically isolated from each other and stacked together might do it.)
Our current PX4 processor probably has sufficient power for this, the one they are using in the BeagleBone almost certainly does and the Quad core processors running in the Odroids likely have more than enough even for the MCP.
Yeah - TRON :-)
Best Regards,
Gary
So just like an election then
Then of course the problem is bugs in the voting logic
Gary,
The problem with voting flight controllers is that the output of a flight controller isn't a yes/no value. All 3 controllers will output different floating point values for all outputs. All 3 might be perfectly valid ways of continuing the flight. So you will be constantly in a state of conflict.
I'm sure this could be handled, but it is a non-trivial research problem with a huge pile of corner cases. I would not be surprised if the voting logic ended up being quite a bit more complex than all of the rest of the autopilot code put together. Then of course the problem is bugs in the voting logic.
Cheers, Tridge
Hi Tridge - All,
Just thought I'd stick in my concept for a reasonably robust voting style flight controller:
Nasa style voting and all but the final output fully redundant and isolatable into any 1 of 3 control circuits.
Won't fit in our current footprint.
All processors can investigate heartbeat and status of others and isolate any non-conforming section.
Any given surviving flight control processor(s) could elect to continue flight or abort to RTL or other failsafe based on preset criteria.
Redundant telemetry could also be used.
Master control processor could provide enhanced ability while functional and be switched off line by flight control processor(s) if performance is compromised.
Flight could continue or proceed to failsafe as required.
Board sections could be isolated physically and with opto isolated interconnections.
Output combiner would be only single vulnerable component and good use of optical isolation could minimize that hazard.
Maybe next generation - - - or two.
Best Regards,
Gary
@Tridge,
In your excellent DGPS presentation you made reference (36') to Google Satellite image registrations and their variance.Have you come across http://maps.six.nsw.gov.au/? While not useful to everyone in this forum, it may be of interest to you and your work. Then again, you may be aware of it already.
Mark
or is this some variant of the SITL(linux) make target?
HZL
So are the changes being checked into github for the regular ardupilot tree or someplace else?
HZL
Where will the cape be available?
@Swift, Heh-heh.
I live in Chile, ordered it from a local distributor. I guess we don't have as many of this type of user here...
Anyways, we'll see if it actually comes. They announce next day delivery and were glad to receive my money, and didn't have a back-order notice.
If it comes we could see how many more they have.... :) They accept on-line orders but don't ship internationally.
Cost me $70 here, after the distributor covers his costs and profit.
Still, good, well worth it.
-
1
-
2
-
3
-
4
-
5
of 6 Next