What do you think the APM should do on fail safe

by Brad Smith [ http://diydrones.com/profile/BradSmith454 ]

May 29, 2012

DIYDrones.com

First this IS NOT a bashing session this is a search for answers and opinions so try to be respectful and courteous !

me personally i think the APM is capable of bringing my plane back and landing if the rx fell out ! do i think DIY should be responsible to implement it ? no but they are flying too so if we come up with a good proposal i,m sure they would try to make it happen !

this discussion is intended to come up with scenarios where your platform would go out of control ! and what we can do ! there should be a sister post Mitigating the chances of losing control .

i,ll start out . with Geofencing(here after to be referred to as GF) turned on i can't see how your platform can fly away so maybe GF should be turned on from default with a tiny box that you have to adjust to your area,platform,and conditions ? but not all of us carry a laptop to the field so maybe we should be able to save it and recall a few different versions for different fields and or conditions that way you could program it at home and go fly , but if you turn it on to far away from the place you selected as home it should lock up and beep or flash an error that way it wont try to fly 40mls back to your house (00) a safe configurable selectable autoland function tied too GF would be nice too.

at least this would protect the DIY community from litigation and put responsibility on the user and would save a newbie from a painful costly learning experience !!! feel free to poke holes in my ideas !

Questions leads to answers and isn't it wonderful we need not wait another second to make the APM better and if we do a good enough job maybe the government will force the AMA to use our product on all there large dangerous aircraft ! and would help in the UAV community acceptance into the sport

now have at it

10:14am

by Zen [ http://diydrones.com/forum/topic/listForContributor?user=1npquptqvcifb ]

May 29, 2012

I'll just repost part of my reply in the other thread as its relevant and apparently was glossed over::

"It is entirely down to the operator to examine their airframe and airfield and select an appropriate response to loss-of-signal.

It is not the place of Jake Stew, myself, 3DR or DiyDrones to make that decision, and this was never about what the APM should do on LoS..."

I wholeheartedly disagree. My logic says that the APM should ship with some sort of default failsafe, one that can be overridden by the user, clearly, if they deem a different method more appropriate for their particular situation. However, for an autopilot capable "brain" for lack of a better term - a piece of hardware that is receiving data from multiple built-on sensors and has the capability to act on its own, there should be some expected out-of-the-box functionality and failsafe.

From Chris Anderson:

"... let me explain a little more more how the PPM encoder works. First, it runs on the 32U2 chip, not the 2560, so it's loaded at the factory and can only be changed with an AVR programmer. Second, because it's running on a different chip the same PPM encoder code applies to all platform software, from ArduCopter to ArduPlane to ArduRover, etc."

How I think I understood that is the APM cannot make any failsafe decisions because the PPM encoder operates independently and is not flashable through software/Mission Planner. This means that the same code running on that independent chip applies no matter what platform you're running on. That would also mean that there is no communication between that system and the APM, or that the communication is bad/damaged/whatever ultimately making it unusable, thus the APM cannot make any decisions. With all the other sensors on the APM I would think information pertaining to the communications/control signal quality would be good info to have. If we have the hardware to fly autonomously and make a certain level of decisions then let it do just that no matter what mode you're flying in.

The same failsafe code has to be used on every platform. Rarely in life does one shoe fit all, and technology, especially NEW technology, is no exception.

If I were flying a plane I would think that upon signal loss preventing safe control of the aircraft it would be best to throttle up, circle (gps hold), and beep the buzzer - hopefully alerting you to the fact that there is a problem that needs your immediate attention and give you some time to fix it.

If I were driving a boat, rover, or any other "land" based platform I would absolutely not want it to throttle up, in fact I would want the opposite. If signal loss occurs for too long I want it to STOP. A runaway gas powered rover throttling up to 60MPH can cause some serious damage, injury, or who knows what. STOP, BRAKE, BEEP. Alert me that there is a problem so that I can correct it.

If I were flying a single, quad, hex, etc al chopper I wouldn't want it dropping from the sky, that's unsafe, and I sure as shit don't want it to throttle up and fly away! In my case there was a 3-4MPH crosswind so it climbed vertically and horizontally. This thing is supposed to know where it's at spatially as it's packed with sensors and designed to self fly... Why not do an Altitude + GPS hold and beep? No matter what it's doing, once failsafe kicks in it will auto stabilize, STOP, BEEP, and hold position even if there is a crosswind. Altering you to a problem. Regardless it wont fly away and it wont come crashing to the ground.

If you wanted to get fancy the failsafe code could change its actions should the battery reach a certain depleted state. In the case of a plane it could auto-spiral down still staying GPS locked. In the case of a land vehicle same result - STOP. And for a chopper it could slowly descend to the ground. It could also include a beeping signaling low/critical battery.

GF is a great way to contain your craft but it doesn't work on or solve the above issues. GF is a great way to vet hardware and test failsafes, but how would it fair using it all the time for every flight no matter the size of the fenced in area?

I believe a certain level of functionality should be possible and defaulted. I think some attention needs to be paid to monitoring the quality of the only signal that's telling this thing what to do.

At this point if the battery gets too low it drops from the sky. If signal is interrupted or lost it either drops from the sky or flys away. It's monitoring for loss of control signal but has no way to act on it. No matter what happens the pilot on the ground has no idea what's going on - either their gear is under control, flying away, or crashing to the ground. Seems like autopilot hardware should be expected to "auto" a little more.

I just want to see this taken care of for everyone's safety, but also so I can feel confident in flying this equipment without the fear of losing my gear or chopping something/one up.

10:46am

by Jake Stew [ http://diydrones.com/forum/topic/listForContributor?user=2egm7fj1oj7qk ]

May 29, 2012

One problem I see with this, and the earlier discussions, is that nobody is actually talking about a failsafe. Everyone wants to talk about what things you could think of for the APM to do in various situations.

A failsafe is for when control fails. What everyone wants to talk about is fallback modes for minor problems.

There's no point in talking about that until it's worked out how we're going to implement the failsafe. We're going to need a watchdog or other timer to activate the failsafe. So all of these fallback plans are going to have to update/reset that timer regularly to prevent failsafe activation. Until that system is worked out these fallback plans are just going to be additional ways to defeat or avoid having a real failsafe.

10:50am

by Zen

May 29, 2012

Everyone wants to talk about what things you could think of for the APM to do in various situations.

Isn't that exactly what we're talking about? Without the APM this device is a dumb device with no sensor input or decision making abilities. If the APM were to fry I would expect the craft to stop, completely, and become inoperable. Since we need the APM to make decisions (autopilot) why does it not do exactly that? My radio signal was lost and because the PPM encoder cannot talk to the APM, and the APM isn't designed with safety in mind, my heli flew away at full throttle. The same thing could have happened at Chris's talk at Maker Faire, only he had an audience 10ft away, I did not.

Why can't the APM monitor signal quality or presence through a sensor and make decisions based on that info as well as all the other sensor info it's receiving? I'm not talking about doing black magic here, the PPM encoder, the one piece of hardware that interacts with the signal from the remote the pilot is using, cannot or does not talk to the APM, thus the APM has no idea what's going on with the signal. Not to mention that fact that it forces the same code to run on all platforms, which isn't the best answer. Why not replace the current PPM encoder with something a little more intelligent or communicative to the APM so the autopilot we have all bought into can auto-pilot when there is a need to?

11:34am

by John Arne Birkeland [ http://diydrones.com/forum/topic/listForContributor?user=06y3ki3y983p5 ]

May 30, 2012

OK let's try dealing with a specific case related to failsafe performance, instead of all this high level abstraction going on.

ArduPPM (ppm encoder) failsafe and throttle channel:

First some back story. Reading PWM signals from up to 8 R/C receiver channels and maintain timing so that you have good stick resolution (>1000 steps), is very difficult with the atmega32u2 hardware. The PWM pulses from all the channels has to be intercepted and dealt with using a single shared interrupt, regardless of the channel signal pattern that may or may not have overlapping pulses. At the same time you also have to stay compatible with the USB<->Serial conversion code that Arduino use to reach the main atmega2560 chip from a USB connection (replacing the expensive FTDI chip used earlier).

So certain shortcuts had to be made in the design, to make it possible. One such shortcut is not dealing with the (physical) loss of single channels. Checking for such combination in a shared interrupt, takes to long and would affect stick resolution. So the loss of throttle channel (actual wire signal loss) not triggering failsafe has been a known weakness from the start.

Now for the dealing with a specific case part.

I think it would be possible to make a special case for the throttle, without having to degrade the stick resolution. But it would have to be a very specific set of behavior. I see two possible behaviors (that would be possible with the limitations set by timing requirements).

1. After a certain duration without a valid throttle signal, the 'all channels lost' failsafe option is triggered (throttle 900, channel 5 1555 (mode 4), the rest centered at 1500) . This failsafe would then stay active until a valid input is detected on the throttle again. The problem with this is that it would actively disable input from other channels if throttle dies.

2. After a certain duration without a valid throttle signal, throttle is set to 900. How this is dealt with is then up to the main logic in the APM code.

As I see it option 2. is the best solution. Any suggestions, comments before I implement this?

2:02pm

by Jake Stew

June 2, 2012

What happened to Kevin? Apparently he wasn't only banned... he was permabanned and all his posts completely erased.

That's too bad since he's probably contributed more to safety than anyone else here.

1:18pm

by Ellison Chan [ http://diydrones.com/forum/topic/listForContributor?user=14kv2wqzbon9k ]

June 2, 2012

Yes, I agree that Kevin had some good inputs to this board, even though his style was a little combative. However, he was not banned for that. Read this thread for more details.

http://www.diydrones.com/profiles/blogs/housekeeping-note-kevin-finisterre?commentId=705844%3AComment%3A876395&xg_source=msg_com_blogpost

1:27pm

by John Arne Birkeland

June 3, 2012

I have updated the ArduPPM firmware for the APM2 (v2.2.67) so that it will detect a missing throttle signal and set the the throttle value to 900us. APM1 version will come later.

Binaries: http://code.google.com/p/ardupilot-mega/source/browse/#git%2FTools%2FArduPPM%2FBinaries

How-To: http://code.google.com/p/ardupilot-mega/wiki/APM2Encoder

5:17am

by Andreas M. Antonopoulos [ http://diydrones.com/forum/topic/listForContributor?user=3hvpzrrpppnrf ]

June 3, 2012

John,

have you had a chance to test on a stock 9X (or other controllers) or should I do that now?

12:42pm

by John Arne Birkeland

June 3, 2012

There has been no change in the encoder logic, so I have not done extensive testing with different systems. Just the usual latency and timing tests with a scope using my regular Futaba radio and the FASST system. Only difference now is that if you unplug the throttle channel, instead of keeping the last known value it will change to 900us.

So please do any tests you feel like. There is no such thing as to much testing. :)

1:52pm

by John Arne Birkeland

June 5, 2012

What I meant is that there has been no change to the logic used in the code to make ppm from the servo signals, so behavior is exactly the same as earlier except that it now also will detection and handle lost of the throttle signal. So unless you have a broken throttle wire or one of those 9x radios that stop the throttle signal on failsafe, you will not notice any difference.

If you decide to update, follow the wiki how-to.

11:51pm

by Jake Stew

June 6, 2012

Not flying away to later crash who knows where, possibly still under power, whenever a non-locking signal wire connector comes loose seems like a pretty major safety improvement.

Don't you think everyone should be doing the update? Shouldn't every page on this site have a big red warning notice telling people they need to perform this critical safety upgrade ASAP?

12:10am

by John Arne Birkeland

June 6, 2012

Unless you change your tone of communication, this will be the last time I respond to any of your messages..

Yes, there is/was a design flaw in the PPM encoder under certain conditions. At the moment of design the 9x FS behavior was unknown, so the possible danger of the flaw was balanced against the need for good overall performance and decided to be at an acceptable level. When I was made aware of the 9x FS behavior, a patch was made since the danger no longer was at an acceptable level.

You behave like you have never flown R/C and UAV's before, and yet have a fixed expectation as to what is possible. R/C and UAV at the hobby level and even more so at the DIY level crash all the time. The developers who know the system better then anyone, crash more then most people. Heck even the big boys from the military and well known aviation companies spending big money, crash all the time. So it is all a balancing act where you try and find acceptable solutions, but guess what. In this hobby you will crash, it is just a matter of time.

12:29am