Making a UAV fail-safe

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:

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)
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.
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)

Yeah, I'm thinking if you loose power, you're probably dead anyway. You could loose power to the radio electronics or to a servo too. I don't know if it's valid, but my main worry is the software using the same chip for control switching that's being used to read and process data from the GPS, accelerometers, gyros, etc. There are a number of systems that could fail and affect the control loop. If something wonky happens with the GPS and a serial read blocks, or if you have a mistake in your code and divide by zero, you loose control (and with the aircraft still at full power).

So you could have 2 controllers. Controller 1 takes input from the radio, gps, sensors, etc., does the math, and produces an output signal. Controller 2 also takes pwm signals from the radio and additionally from controller 1's processed output, and it chooses the appropriate source to output to the motors.

The code in the switching controller is very simple, and you go over it with a fine tooth comb and prove its validity. Then you can experiment with your code in the flight controller all you like and not have to worry about something catastrophic happening.

You need to be a member of diydrones to add comments!

Join diydrones

Comments

Developer

Jordi Muñoz January 15, 2008 at 10:37pm

You only need to hack the receiver to sniff the PPM signal and leave unconnected the channels 1,2,3,4, only the channel 5 is going to be connect to a servo. Then the PPM signal is connected to a input 1 of the switch, the input 2 cames form Arduino autopilot, the switch output is connected to a PPM decoder (TI 4017), the PPM decoder controls the servos (individually). The switch is controlled by the servo connected to channel 5
3D Robotics

Chris Anderson January 15, 2008 at 10:26pm

"You only need to hack the receiver to sniff the PPM signal"

Only!!! No idea how to do that...
3D Robotics

Chris Anderson January 15, 2008 at 10:17pm

But what is that "PPM" box (yellow one)? I'm also confused by the terminology. PWM is pulse-width modulation, which is what I'm used to with servos. What's PPM and PMM?
Developer

Jordi Muñoz January 15, 2008 at 10:08pm

Check this diagram:
http://jordii07.googlepages.com/AutoPilot2cores.jpg
Using two Arduino (dual core) to divide the work. The red, yellow and black boxes are totally separated (independent power). The channel 5 is a servo connected (clip) to a mechanical switch to select between manual mode or auto mode, if some think goes wrong with Arduinos you always going to have the control.
Jason Striegel January 15, 2008 at 9:56pm

Good point. I suppose you could do something like have the flight controller output serial to a servo motor controller, and then take that into the fail-safe switch. You'd be trading additional weight and circuit complexity for the software simplicity in the switch, though the complexity would all be on the flight controller side and isolated from the fail-safe.
3D Robotics

Chris Anderson January 15, 2008 at 9:22pm

This is actually a great idea. My only concern is this: The optimal servo output of a Stamp is serial, not PWM (too much processing overhead). That means that the MUX would have to take PWM from one source and serial from the other, which is totally possible but introduces a good bit of additional complexity. Which means another potential point of failure?
Jason Striegel January 15, 2008 at 9:06pm

Yeah, I'm thinking if you loose power, you're probably dead anyway. You could loose power to the radio electronics or to a servo too. I don't know if it's valid, but my main worry is the software using the same chip for control switching that's being used to read and process data from the GPS, accelerometers, gyros, etc. There are a number of systems that could fail and affect the control loop. If something wonky happens with the GPS and a serial read blocks, or if you have a mistake in your code and divide by zero, you loose control (and with the aircraft still at full power).

So you could have 2 controllers. Controller 1 takes input from the radio, gps, sensors, etc., does the math, and produces an output signal. Controller 2 also takes pwm signals from the radio and additionally from controller 1's processed output, and it chooses the appropriate source to output to the motors.

The code in the switching controller is very simple, and you go over it with a fine tooth comb and prove its validity. Then you can experiment with your code in the flight controller all you like and not have to worry about something catastrophic happening.
3D Robotics

Chris Anderson January 15, 2008 at 8:52pm

You mean on the same board as the autopilot? I suppose if you don't lose power to that board, it would be fine. Certainly better than what we're doing with our Basic Stamp autopilot right now ;-)
Jason Striegel January 15, 2008 at 8:45pm

What are your thoughts on using a separate microcontroller with the sole purpose of switching input and monitoring battery life or other critical events (maybe radio signal)? The routine can be simple enough to be trusted, and you can fit the whole package into a single IC.
3D Robotics

Chris Anderson January 15, 2008 at 1:48pm

Here's the link:
http://www.rcgroups.com/forums/showthread.php?t=801709

Let me know if there's anything I can do to help.

of 3

This reply was deleted.