A big part of the DIY Drones credo is keeping it safe, and by that I don't just mean adhering to FAA regs and staying away from built-up areas, but also keeping it safe for your expensive UAV! The truth, as we all know, is that computers crash and that aircraft flown by computers crash harder ;-)

The aim of a good UAV is to have a fall-back system by which a human pilot can take over if (when!) the autopilot goes funky. There are at least three ways to do this, all of which we feature in one or more of the autopilots here:

  1. Completely separate the navigation and stabilization systems and ensure that the stabilization system can be overridden by manual RC control. That's what we do in GeoCrawlers 1, 2 and 3, all of which use the FMA Co-Pilot for stabalization (it controls the ailerons and elevator, leaving just the rudder for the autopilot and navigation). If the autopilot crashes, you can still fly the plane with ailerons and elevator alone, something we end up doing all too often! (The FMA system always allows for manual input)
  2. Mechanically separate the autopilot and RC control systems. In the case of the Lego UAV ("GeoCrawler1"), the Lego Mindstorm system moves the whole rudder servo back and forth, but the RC system can always turn the rudder servo arm, allowing it to override the autopilot if need be.
  3. Install a stand-alone "MUX" or servo multiplexer, that allows the operator to switch control from the RC system to the autopilot and back again with the gear switch on the transmitter, even if the autopilot catastrophically fails. As far as I know, there's only one commercially available one of these out there, and that one, by Reactive Technologies (shown), is not cheap ($99). Still, if you install one and give it an independent power supply, there should be no reason why you can't regain control of your plane no matter how wonky your onboard computer has gone.
What you should probably not do is exactly what we do (temporarily) with the Basic Stamp autopilot (GeoCrawler3), which passes RC signals through the Stamp chip and synthetically recreates them on the other side for the servos. If that program has a bug or the chip otherwise freezes, you've basically lost your rudder and elevator, which could make keeping the plane in the air difficult indeed. You'll still have control of the ailerons and throttle, but good luck getting the plane down in one piece if your program decides to crash with the rudder and elevator at full deflection.

So the Basic Stamp UAV project might be a good place for a MUX. Anybody know of a cheaper one? (This guy is looking for one, too)

Views: 2237


Developer
Comment by Jordi Muñoz on January 15, 2008 at 11:58pm
The diagram is already updated, the component is:
http://www.datasheetarchive.com/pdf/1002554.pdf
is used by paparazzi here (4017):
http://paparazzi.enac.fr/wiki/index.php/Tiny_v2

Developer
Comment by Jordi Muñoz on January 16, 2008 at 3:47am
I confused now, check this:
http://paparazzi.enac.fr/wiki/index.php/Other_Hardware
They mention PWM and PPM...maybe is the same...
Comment by Paul Gregory on January 16, 2008 at 4:33am
Just a slight note of caution. While adding an additional card for harware switching of servos can help recover from a software failure in a prototype autopilot, it could increase the risk of harware failure with all the additional wires, connectors etc.

I have been reading my way through the code and documentation for the SparkFun GPS- UAV. In this firmware, the servo inputs are connected to input pins with interupt on rising and falling edges of the pulse train. These inputs are set to the highest priority and the service routine simply copies the inputs to the servo outputs. Simple, and this part will continue to work even if some part of the navigation code gets into a loop or other exception.

Then you can use NotOK flags that are set and reset at the start and end of each processing routine. A high priority watchdog interupt timer, running at say 1 sec intervals, could then turn the autopilot off, unless all the flags are in the correct state.

I think I will read a bit more about failsafe code development. Most things seem to have already been developed, if only you can find them.

PJG
Comment by James Hall on January 16, 2008 at 7:50am
How about a failure occured on the processor, a separate process reads a low byte from a pin and triggers a parachute recovery?

:)
Comment by Ken Ter on July 8, 2019 at 8:55am

I am new to drones but am embarking on building a drone for my final year of school. it is supposed to be a fail safe FPV and I am so confused on the right way to bring this to realization. my aim for the project is to make the UAV smart enough to return home when it has consumed 50% if the startup power. 

since I am meeting pros here and the topic seems related, I felt I ask on advise on the right approach to this and possible suggestion on the most economical but effective components to make use of.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service