Comment by Matthew Coleman on June 20, 2012 at 10:42pm

Many large aircraft systems use an ARINC standard CANbus setup.  This enables a multidrop sensor and actuator network with redundancy.  Every system can be assigned as primary or backup.  If either a network or a node fails, the system will drop back to the working network or node connection.

Large scale acrobatic aircraft (IMAC) have two servos driving each aileron/elevator.  If one servo dies, the other servo is strong enough to overdrive the broken one.  Simple....

Developer Comment by John Arne Birkeland on June 21, 2012 at 2:12am

The challenge as I see it is reliably detecting unwanted behavior. Except for obvious things like missing RX signals etc, how do you know when a single APM is wrong? And with two of them how do you know which one is wrong and which is right? It is a chicken and egg problem. If the APM knows it is wrong, it should be able to correct itself.

Granted you system could cope with electronically problems, but I do not think it would be reliable for navigational/AHRS problems. For such scenarios you would need a third APM so that you can have a voting system.

Comment by Zachary Eldridge on June 21, 2012 at 5:57am

As a engineer that system will cause more problems than you think. Running 2 APM I can see some issues. Are they going to connect the same radio or seperate? Have you though of failsafe and running away plane issues? Say one APM gets the flight information but the other just simulates or fails then you click your mode switch on your transmitter from FBW to RTL well what if the other one wants to stay in FBW. Also split of two from one side to the next your looking at confusion with flight systems. Since each side will fight each other to get closest to it heading it would be a wobble flight. I would look a extra or another external gps. If you were able to make all systems run parallel from each other than you that would be a better system. Just my thought. I would do some ground test though.

Comment by Matthew Coleman on June 21, 2012 at 7:07am

What are the most common failures? I might guess at:

1. Servo or servo connector failure

2. Broken wires or loose connectors (not shorted)

3. Wiring shorts (further down the list?)

...

N. Software glitch

N+1. Undetectable software glitch.

Please challenge me if you think this is wrong but I believe that the majority of failures are going to be detectable.

Problems:

1. Synchronising data - Fixed with the panda board.

2. Sharing servo outputs

If the panda is doing critical information passing then it is a single point of failure and there is no point having two APMs.  It is therefore not the best plan to use it for routing servo information.  The only way I can think of to prevent this problem is to have every servo connected to both autopilots with at least two separate signal networks.  Each servo also needs the knowledge of which autopilot is in control. Getting this knowledge in a robust way is not easy.

My suggestion is that you take a look at what large aircraft use for redundancy and take your lead from there.

Comment by Zachary Eldridge on June 21, 2012 at 7:14am

I agree. Have a fail safe reciever and transmitter will help also.

Comment by Mathew krawczun on June 21, 2012 at 8:24am

Most redundant systems I know of use three computers because choosing the right command becomes a simple two out of three vote. The problem with two is the world is complex and what looks like bad behavior in a lab setting can be good behavior in the real world.

Comment by Veikko Vierola on June 21, 2012 at 11:13am

Thank you for your opinions and ideas. As someone already said my approach is pretty close to building two planes in one frame. It is just so that the more you put money and electronics to your plane the more you want to think about the redundancy. I also agree that a very good emergency parachute system could safe the plane a bit easier and cheaper way, but it doesn't give a solution for continuing the flight. 

Developer Comment by John Arne Birkeland on June 21, 2012 at 1:29pm

Matthew: I ave been flying traditional R/C, FPV and UAV's for many years and have never had a wiring problem or electronic die in the air, except for some very cheap servos. Granted I work with electronics so I know how to solder and such, but still. All my problems have been physical (wings/control surfaces breaking off, tearing servo gears etc), and auto pilot software/loss of radio control related. Granted this is anecdotal evidence, but securing wires and proper soldering is basic must have know-how if you plan on doing R/C and UAV experiments. Also remember that servo control is one way, meaning that unless you do some modification you can not detect a broken servo or lose servo wire.

Comment by Lorentz on June 21, 2012 at 2:47pm

I agree with John Arne. most of the problems come from software errors. By the way, Redundancy only protects against random hardware failures, it does nothing against common cause failures and systematic failures. The former may arise from things like overtemperature, overvoltage, EMC disturbances whereas the latter comes from poor specifications, design, tests both HW and SW. I would stick to a simple but reliable system (aircraft, electronics, software), take a list of reasonable failures along with their probability and severity of consequences and add some measure (redundancy,diversity,tested SW) only to prevent the riskier of them

Comment by Matthew Coleman on June 21, 2012 at 8:21pm

John, Lorentz,  Thanks for opinions on this.

I would like to show a few examples of recent incidents at my local flying field.  They are nothing new, we have seen it before and will see it again.  These examples are on non UAV aircraft.

1. A Medium scale acrobatic aircraft lost elevator control.  The aircraft was badly damaged.  Root cause is thought to be the elevator connector at the radio which was found to be loose.

2. A medium scale acrobatic aircraft wing spar broke.  The aircraft landed safely and without further damage but not in a controlled location.

3. A high powered ducted fan model rudder linkage failed.  Result was an exciting landing under reasonable control

4. Radio failure on a glider during landing approach.  Failsafe mode entered which brought out airbrakes. Radio control came back shortly before impact.  Result was damage to wings from a tree.  Root cause suspected to be radio software failure. See Hitech optima Rx firmware issues.

5. Medium scale acrobatic aircraft pilot became disoriented and rolled into the ground. Result was complete destruction of aircraft.

6.  The example I do not have is where an autopilot fails and causes an accident.  There are plenty of forum examples of this and I must acknowledge this.

We can't do much about #2 unless we start to do materials inspections.  The spar was similar to that on other similar aircraft. There is a limit to how far you can go.

#1 and #3 are the same thing but one is mechanical and one electrical.  As John said, a servo failure is one way.  They are solved by having more than one complete "one way" systems.  This is what large scale and jet aircraft people do for this very reason.

#4 is a software failure, just like an autopilot software failure.  In this case adding an autopilot would have saved the aircraft from damage.

#5 Geofencing solves this. It would need to be very advanced to prevent this particular error.  Out of radio range RTL is also an example of geofencing.

#6 Adding an autopilot will greatly increase the risk of software failure but reduce the risk of radio related problems.

Even experienced modellers get unexpected failures.  Good build quality and regular inspections reduce the risk  of failure but it will still happen.  The question of where to put your effort to reduce what risk is a good one.  There is not much point building redundant systems if you fly it into the ground on manual.

Personally, I mostly fly on manual with the autopilot as a mixer and co-pilot for resting during long flights.  The main autopilot code is not a big risk.  The greatest risks are electrical connector faults, radio failure and mostly my own flying capabilities.

Comment

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page