I was thinking about an idea of a redundant UAV with 2 x APMs, 2 x RXs, Dual Servos/surfaces, 2 x ESCs and 2 x motors. The plane should be designed so that it could fly with only one motor if needed.

The idea of functionality:

  • If something in APM(A) network fails or works not well the plane would automatically switch to APM(B) network.
  • If one of the servos fails there would always be another servo and another surface to control the steering.
  • If one ESC or engine fails there would still be another to go.
  • If one RX fails the system could use the (B) network.

How the system detects a failure?

  • (If both APMs had the same planned route and the working APM(A) detects that the plane has drifted too far away from desired flight path it would automatically switch to standby mode and let APM(B) network do the job?
  • If APM(A) network RX looses signal the failsafe would automatically switch the board to standby and let the other network take the control.
  • The idea would be that the other network would always be in active mode and the other one would be in standby mode.

I hope you could give some additional ideas to this draft philosophy of a Dual APM plane....

Views: 1674

Comment by Paul Feely on June 20, 2012 at 2:58pm
You might want to check out Andrew Tridgell's post on running 2 APMs http://diydrones.com/profiles/blogs/two-apms-one-plane, P
Comment by Veikko Vierola on June 20, 2012 at 3:33pm

Yes, Tridgell's post describes exactly what it is all about. I would also add the redundant control surfaces for both pilots. Could this be done without the banda boards?

Comment by Brad Hughey on June 20, 2012 at 3:34pm

The primary axiom of redundant systems is to avoid any single-points-of-failure.  Often times, engineers tend to graft on switching mechanisms, heartbeat detectors, or other ancillary components into the topology which themselves end up being a SPOF.  The best approach here would be akin to datacenter-like N+1 clustering, but that would involve a parallel topology of self-diagnostics and a status-sharing internetworking bus of some sort.  In other words, to do it right is not a trivial exercise. 

Comment by Veikko Vierola on June 20, 2012 at 3:58pm

Yes you are right, it is always possible to make the system very complex but I was mainly thinking about a poor man's solution for the redundancy, something simple. I have also noticed that for example only a redundant elevator makes the plane much more reliable. I don't know if there has to be any fancy Kalman filters to detect the quality of the navigation. Maybe it would be just enough that if APM A can't navigate the route within selected tolerance it switches the control to the APM B network and lets it try the navigation? For example the APM A output elevator servo cord has a failure and the APM A is no more able to control altitude. When the altitude goes too much higher or lower the planned route altitude the APM A understands to give up and let the APM B try to stay on the right altitude, and of course in this case the APM B is able to keep the altitude, because it still has functional servo output cords.

Comment by Toby Mills on June 20, 2012 at 5:02pm

Veikko

As brad suggests, this is not an easy approach. In effect, you are trying to build two planes in one airframe.
As someone involved in IT infrastructure design, I'd say this is always going to be cost prohibitive for small systems. Large systems carrying people are a different story.

You have to way up the odds of something going wrong against the odds of something going wrong with the things you put in place for redundancy. Sometimes a simple design is more reliable than a fault tolerant design simply by the fact it is much simpler and there are fewer things to go wrong.

The chances of multiple things going wrong in a multiple redundant (thereby causing a combined single point of failure) design may actually be higher than the odds of a single point of failure occurring in a simple design.

The ultimate solution may be the equivalent of disk mirroring in the IT world. Simply build two identical planes to do the one job. If one fails, then the other will take over and complete the task.


You would probable find that the chances of two independent planes failing both at the same time on the same mission are lower than the chances of a single plane failing with redundancy.

This method also gives you wing redundancy and lightning strike redundancy that the single plane design does not have. The more important the mission is, the more planes you could add to ensure success.


The cost of building two identical planes (in time and money) is significantly lower than designing a single plane with redundancy. No amount of redundancy helps you if a wing falls off in flight or your plane gets struck by lightning.

Comment by Karl Bielefeldt on June 20, 2012 at 7:09pm

Toby, the problem with the multiple plane approach is that outside fields like military and law enforcement the primary mission is often to recover the aircraft intact.  Most things are just not urgent enough that you wouldn't prefer to try again after making minor repairs.  Other than that, your points about redundancy and complexity are sound.


Moderator
Comment by Sgt Ric on June 20, 2012 at 7:28pm
Your top level controller has to be able to instantly detect the fault and decide which of the systems (your A or B) are more accurate/intact and able to complete the mission.

Not an easy thing to program.
Comment by Toby Mills on June 20, 2012 at 7:30pm

A parachute or a flat spin failure mode may be better approaches to aircraft recovery under failure conditions than trying to prevent the failure conditions from occuring.

An old iPhone with a cracked screen bought on ebay for next to nothing can give you independent remote location and would probably weigh less than having all the other redundancy.

I just struggle to see how something this complicated could be more reliable than the simplest solution. I suspect you would lose more planes developing the redundancy to the point of reliability than what you would just sacrificing a few planes ;)

Comment by ernani reis on June 20, 2012 at 8:17pm

If you fear this so much, consider using the 2 APMs on a full split, right APM to the right aileron, left APM to the left aileron, split the empenage surfaces in two elevators and 2 rudders, and move them with two small servos, each connected to one APM, will be heavier, maybe not much, and probably cheaper. I would not do for myself, though. Redundancy is not a trivial thing, usually people will multiply the failure probability. Aircraft people know how to do it, telecommunications people do not, from my experience.

Comment by Ove on June 20, 2012 at 10:15pm

Nice idea: But I suggest to make sure what kind of problem you are tracking and how to recover. By your criteria to switch the APM's I got the feeling that you might switch because of external problems and not because your active APM is in an error situation. For example if your APM looses RC transmissions, is the reason your APM or is is because you turned off the transmitter or the plane is simply to far away.

Switching between the APMs might help you to keep your plane active while one APM fails (I don't will intend on error detection in 2:1 systems). But if you switch while everything is ok, you might get the problem that your plane is not doing anything anymore because the system is busy with switching control and not controlling. And this may lead to the problem you originally want to avoid.

So for example you might think of something like: if the second APM takes over, it's job is to return your vessel safe to earth and do not try to be a full backup.

Comment

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

Join DIY Drones

Social Networking

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.

A list of all T3 contests is here

Groups

Advertisement

© 2013   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service