Copter: Flight Safety Interlock needed for GCS as primary

[hotelzululima]

Hi All on APM/Copter 3.2.1 when running Telemetry/GCS as primary flight control with a RCTX setup to allow launching from the tablet(rctx=stab mode with throttle 0)

a loss of autoguided primary flight control will be experienced if a comms error for the RCTX is seen on the APM end(in the case above the Arducopter/APM immediately switches to the last throttle setting and mode seen on the TX switches(which were stab and throttle stick position zero to allow arming and takeoff from tablet)

ie the RCTX was left powered on as a "recommended" backup control... :(

An immediate crash is the end result here without such an interlock , preventing mode change different from primary GCS control current mode would prevent ,GCS rf loss could be used to allow a switch back to RCTX as primary if throttle stick position and mode appropriate on rc/tx or simply continue mission. if no current mission ie follow me or guided then land or RTL on GCS RF loss..

[R-Lefebvre]

I reviewed the flight logs related to this incident.

You did not set up the Throttle Failsafe system on this. FS_THR_ENABLE = 0, and FS_THR_VALUE = 975. So these are default settings. RC3_MIN is 985.

I imagine what happened is that your RCTx automatically shut itself off due to inactivity. Your RCRx appears to be programmed to set Ch3 to min, 986 in this case. Ch5 goes from 1305, which is Mode 2 (Loiter) to 1171 (Stabilize). Since the Ch5 changes to something other than min, I assume you have programmed the failsafe in the Rx. You did not program it to drop below the FS_THR_VALUE, nor did you turn on FS_THR_ENABLE.

If you had set up the FS_THR system as recommended, your copter would not have crashed.

[rmackay9]

@hotelzululima, I'm deleting your comment because of the personal comments about me. Feel free to repost without those lines. I'll do the same for any other comments by anyone.

Let's all be cool. It's just a feature we're discussing and we all want AC to be as safe as possible. It's a discussion about how to make that happen.

[hotelzululima]

this is NOT about the crash and is about the uncontrolled mode switching that occurs on RC xmit errors this is definitely NOT about what you imagined happens.. but is instead what happened in reality.. RCTX errors can cause a flight MODE switch in the standard recommended config with a backup RCTX left on in the state it has to be for GCS commanded arm and takeoff.. .

If in doubt 3DR will be sued over this by any 3rd parties injured and this comment and closing of the bug prematurely will NOT contribute to a successful defense by 3DR .

I am trying to make sure that 3DR actually knows there is an REAL SAFETY issue here that needs to be handled pronto.

[hotelzululima]

another comment: about flying over folks heads.. it IS happening.. given my customer markets indemnification against suits(LEO/Forensics) its really hard to convince folks who carry and use firearms for their job that flying over folk in an unlawful demonstration is dangerous , they hear me but when push comes to shove and a demonstration happens and lawbreaking is observed. those multicopters will take flight over crowds.. just a fact of life.. its already happened over suburban homes in Santa Clara and other places by local PD and FD. fortunately DJI was the vendor in that incident. its time to take safety engineering for drones to a new level as a result. None of the objections we raise seem to have ANY effect on this unsafe usage btw TJPD is using 3DR X8RTF over crowds and they are the second city in mexico to do so.. http://www.utsandiego.com/news/2013/dec/07/drones-3D-robotics-tijuana-san-diego-mayor/

again the drone industry overall not just 3DR/APM needs to step up its code/FC safety game in view of this

[R-Lefebvre]

Other people's decision to fly over people's heads is not under our control. Neither can we write programs to make the propellers not fall off, bearings not to fail, motors not to burn out, or ESC's not to lose sync with the motor commutation. This is why it is not safe to do, and nothing we can do will change that.

There was no uncommanded mode switch that caused your crash. There was a COMMANDED mode switch which occurred because of your negligent configuration of the system. And if you had chosen to fly overhead of people, that also would have been your fault.

The program did exactly what it was supposed to do, in response to a command received from an external system that you configured. If you had configured the system properly, the flight controller would have understood the RC Tx had problems, and would have responded appropriately. However, due to your changes made to the 3DR default setup, the system could not determine what the condition of the RC Tx was. Therefore, it responded exactly as it was programmed to do, and that which is very clearly described in all of the operational instructions.

This situation where zero throttle is used to cut motor power, may seem anachronistic, but must be understood in the full context of the very rapid development of this technology over the past ~5 years. Not that long ago, these aircraft were typically comprised of 4 standard airplane ESC's, and 3 Futaba 401 helicopter gyros arranged in a simple signal mixing configuration. Reducing throttle to zero was the ONLY way to stop the motors. As flight control technology advanced, this methodology was retained as it was well understood. It was the norm, and remains the norm across virtually all flight controllers available.

What you are asking us to do, is essentially rewriting one of the most fundamental safety systems of this technology, one which has been widely used with an excellent track record of safety since the inception of this technology. We take our responsibility to get this right very seriously, which is why we will not move rashly to make a snap change to satisfy newcomers who have not taken the time to read their manuals, learn to fly, and configure their systems properly. The fact is, that people who operate like this, are bound to have an accident sooner or later, and there is nothing anybody can do to prevent that.

If you had been operating a completely standard system as delivered by 3DR, you might have a stronger cause for criticism. But YOU modified the system, and you did not do it with a full understanding of how the system works. The crash would not have happened under the standard configuration. The accident is YOUR fault.

Regardless, we are still working, cautiously and prudently, to figure out how to make the system altogether more safe, and not trading one failure mode for another.

[rmackay9]

I think we've really discussed this issue thoroughly now. Let's move onto implementing the code changes we've all agreed we're going to make.

[hotelzululima]

Rob,

Mode switches commanded by RCTX errors are NOT a pilot commanded mode switch.. period..

and having a THR_FS save the crash is a separate issue, the issue here which has NOT been addressed is the mode switch occurring from an RCTX error.

Systems used for public safety CANT have a state where the craft is taken out of flight planning control by missynchronized mode switches

And the flying over peoples head by public safety agencies is being done with systems vended to Tijuana from 3DR with the FULL knowledge of 3DR..

So what is it that they are flying if NOT APM???

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0CC4QFjAC&url=http%3A%2F%2Fwww.utsandiego.com%2Fnews%2F2013%2Fdec%2F07%2Fdrones-3D-robotics-tijuana-san-diego-mayor%2F&ei=fML9VNqXF4b7oQTA34LYCA&usg=AFQjCNHb1x6BoxPTNEJXNTm_cznfLPtFOQ&sig2=ei9njbB_d-JESShQhEYJIw&bvm=bv.87611401,d.cGU

pretending on the part of development staff that this is NOT done wont "fly" in a California court of law and is ludicrous. I suggest instead of protesting against what I have said here you instead look at what is actually going on: if these involuntary mode switches succeed in harming a 3rd party you can bet ALL these conversations will surface.

The issues here are making SURE that the FC code does exactly as intended, at present it does not.

 hzl

ps this is not about protesting from a "newbie".. I have been working in unmanned systems fixed wing software development with test flights with Paparazzi. since 2005 and onavi based flight controller development since 2001. and again I have been a rotary wing certified pilot since 85.. I suggest it might be you who is a bit "new" :)

"Other people's decision to fly over people's heads is not under our control. Neither can we write programs to make the propellers not fall off, bearings not to fail, motors not to burn out, or ESC's not to lose sync with the motor commutation. This is why it is not safe to do, and nothing we can do will change that.

There was no uncommanded mode switch that caused your crash. There was a COMMANDED mode switch which occurred because of your negligent configuration of the system. And if you had chosen to fly overhead of people, that also would have been your fault."

[hotelzululima]

and rob last comment.. on the THR_FS.. I agree totally that this parameter would have indeed saved the day if the RCTX had been totally off the air out of range and there is indeed a setting to continue with auto mission.. and as Randy verified that setting has been in the IRIS files from early IRIS days, I just verified that with my own saves.. sometime around 2/13/15 when working with a beta copy of mission planner those parameters were changed and saved to the IRIS. I was not able to set FS parameters for whatever reason and that current set was inadvertently saved..

thats on me.. no issues with same(although I forseee a check to always set these params before saving since they are safety critical)

this issue again is about RCTX errors commanding mode switches and since the RCTX did command it by being newly noticed again after an error I DONT think that the logic of the THR_FS would have necessarily caught this as the RCTX was commanding STAB mode at THR=0 due to the switches being left in a position that permitted arming from the Tower app, as this happened about 10 meters up during the transition from home to landing on the tower app. ie it looked totally like what the Pilot in command had requested.

ie the only way to handle what looked like a legit pilot command is a priority/preemption logic section deciding who was the arming authority was initially... the RCTX or tablet/mavlink/gcs (I for one will be quite glad to totally lose the RCTX permanently once the software is a bit safer)

this does make me very reluctant to use an RCTX as a control backup given the requirements for arming from a tablet in the presence of an RCTX. one more thing to add to the prearm and flight checklist I normally execute, resetting RCTX switches to a safe mode after arming from a tablet GCS..

hzl

ps I DONT feel this issue was closed correctly as the RCTX error issue is still there for transient errors close in

[hotelzululima]

On 3/9/15 5:58 AM, Robert Lefebvre wrote: There was no uncommanded mode switch that caused your crash. There was a COMMANDED mode switch which occurred because of your negligent configuration of the system.

ah Rob.. the STAB thr=0 is required for arming of the system from the TOWER app.. the craft was then flown from the tower app in guided mode/followme..

when the RCTX error occutred and the TCYX reseen by the APM is where the problem occured and THR_FS would NOT have saveed the day at all since the RCTX switch and stick were in that config for tablet launch and were powered on in case of fly away in which case I would have commanded STAB/thr=0 deliberately to avoid issues (and yes I have used it..)

according to my understanding of the failsafe THR_FS woud not have saved the issue even if configured and all stock equipment used in the face of RF errors in the band of the RCTX and the stick/switches left in the position for arming from a tablet.

also note the IRIS+ was 10 meters overhead... not distant and at the very start of transitioning to landing...

absent control channel interlocks are the direct cause of this mishap and inadequate code to handle not modded configs..

      hzl

[davidbuzz]

HZL - your concern/anger has been noted by the core devs. As a result of your raising this issue, they've been discussing the general concepts of in-air-termination, throttle-cut, failsafes, the hand-over process between RC/TX and tablet control, GCS/tablet design concerns in that area, and are considering what (if any) action to take in regard to your concerns. I believe it's also been tabled for discussion on their weekly call. They've also noted that you seem very confrontational, and at least one of them called you a troll... so please try to be understanding at that point that you are dealing with real humans with real feelings, and they do this becasue they love it, not because they get paid. Buzz.

[hotelzululima]

Hi Buzz, I think ALL of us here are a BIT obsessed about our individual points of view, I admit to being very confrontational where safety is concerned when issues addressing this were opened and then closed by folks who hadn't worked through the issues I am experiencing.

I deliberately use charged language with certain keywords to make sure the legally responsible folk hear & pay attention to the issue which is compounded by the fact of being in California with a rather Kafkaesque system of product liability laws .

And I don't respond that way unless attacked first, I do recognize what are the actual "facts on the ground" as regards present day deployment of UAV systems by municipal agencies and others and I am acutely aware of FAA regulations regarding "public"(those operated by a city or state agency)aircraft as opposed to civil aviation.

and while I am glad that these issues is finally being looked at and addressed.. the fact I had to spend so much time trying to convince folks that this is a REAL issue not solved by THR_FS.. makes me somewhat sad.

I have felt insulted by the language from lthall, randy and rob at times and have responded in kind. Safety is my #1 #2 and #3 concern here and whatever it takes to get this issue addressed is the limit I am willing to go.

I don't get paid to be a test pilot on hardware purchased for eval but within 6 test flights I fell into this defect , had the core developers addressed the real issue instead of acting insulting and calling me a "newbie" perhaps things would NOT have gotten to that point.

And thats besides the factor of $600.00 plus in broken hardware directly caused by this defect while flying on RELEASED APM 3.2.1 not RC or beta level code.

Something perhaps for the "core developers" to think about.

a very disgruntled HZL