Copter: check the CH3 value when switch to Stabilize or Acro from any automatic flight mode

[robustini]

Unfortunately a friend has happened this:

https://www.youtube.com/watch?v=KLW1wouIGbA&list=UUPcCCiqkWYZmvxVgHhDZDHA

Over $2000 of damage for this reason, switch from RTL to Stabilize with the throttle stick to lowest position, ie motors off. In fact in our code lacks this obvious safety check, we do not have a check if switch from any automatic flight mode to Stabilize or Acro and the throttle stick too low for any reason (distraction, etc). So I think it needed a simple patch with a parameter: when switch from any automatic flight mode to Stabilize or Acro first check the throttle stick value, if it's lower than the value of "THR_SFT" (new parameter for example, similar to THR_MID but obviously with a lower value) ignore the mode switch, but by moving the throttle stick over that value switching occurs without having to switch back again. Personally I'd rather have the ability to disable this protection, so if the parameter "THR_SFT" is "0" this security check will not be enabled.

[rmackay9]

Did this person change the flightmode from the transmitter or from a ground station? If it was from a ground station then it might be better to add the check into the ground station to say, "you're switching to stabilize and the throttle is zero, are you sure?".

[robustini]

From the tx, the problem is that potentially one of the switches was defective (three position with Stabilize/RTL/PosHold), then this security check is required. Randy, i know that should never put the throttle to zero, but could happen for distraction.

[robustini]

Yes, i agree about the warning in the Planner, but you have to think that not necessarily connected with the telemetry.

[R-Lefebvre]

Marco, I'd like to propose a different solution. How about a Ch7/8 Throttle Hold feature? It would operate just like on a helicopter. When used, it would prevent motor shut down whenever the throttle is brought to the bottom if the switch is "up". This would also help for Acro, because the motors would never shut down.

Conversely, when the switch is "off", the motors would absolutely stop no matter which mode! It's an instant kill switch. This makes it safter.

I've wanted to do this for a long time, but I would need to know that it would be accepted in the code. I think it solves a lot of problems at once.

Often when I'm testing, I get a minor tip-over or something, and because of mot-spin-armed, the motors won't shut off. It's a struggle to try and disarm while the motors are squealing, they could get damaged. This function would solve that problem too.

[robustini]

Yes Robert, is a great alternative, but you should still set something, I would put it is enabled by default in the code, although personally I would like to turn off, i know what I do with the throttle. For the heli the "kill instant switch" is absolutely necessary!

[R-Lefebvre]

I don't think it would be enabled by default. At least not until more people became familiar with it. I'm sure once people get used to it they will like it.

[jschall]

Maybe if we get a switch to stabilize with the throttle lower than mid we should slew the throttle towards the transmitter stick at something like 10 to 20 percent/sec.

[R-Lefebvre]

Then what happens in the case where the person was flying in an auto mode, has crashed, and is trying to shut it down by flipping the mode to Stab with low throttle?

This is a safety issue. (always had been). We are trying to guess the pilot's intent based on the position of a control input.

Does a car shut off every time you take your foot off the gas? No, you have a separate control, which is the key switch.

[robustini]

It is obvious that this thing is a pilot error, the intent is to make sure that does not happen, if the code checking the throttle value from any auto mode to stab/acro definitely can not happen. I think that the proposal that I described initially is the most logical. This control for example with DJI is not active, if you switch from ATTI or GPS to Manual and the throttle is in the lowest position the same thing happens. So in APM:Copter we can implement something that not exist the others flight control. Conceptually my proposal is correct, don't know how easily applicable.

[R-Lefebvre]

My concern is that the proposal creates as many problems as it solves. It's not a net safety benefit. It trades one safety problem for another.

[robustini]

The alternative is easy, don't use Stabilize or Acro. When we have a better stick throttle management (more responsive) in other flight modes like Alt-Hold and PosHold definitely Stabilize and Acro for many become obsolete (all the DJI fan).

[andrea25]

I like the proposal made by Marco Robustini about the throttle check before switching to stabilize.

I have seen a lot of newbye pilots having trouble with this: they was risking to crash their copter by switching in stabilize.

So I think that it be useful to add some kind of feature that can check the throttle vale and prevent switching in stabilize/acro if the throttle value is too low. The check in my opinion should be active and effective in both the case: if you use the tx to switch the mode or if you use the ground station to switch the mode.

And about CH7/8 throttle hold: and for the ones that don't have a 7/8 channel tx? I'm not kidding. For more that a year I was flying with a 5ch tx and a lot of newbyes fly with 5/6 channel radio.

But I also agree with R-lefebvre: the "kill switch" is needed. And is absolutely necessary in test situation. Maybe this feature can be activable and deactivable by mission planer. So expert user can turn it off, but lot of the newbyes copters are saved in this way.

[laurienzu]

The throttle check is a good idea but I would suggest this further change: When you're changing from an automatic mode to stabilize/acro this two conditions will happen

• if throttle is below hovering level (already calculated by arducopter) the board will switch to althold for 5 seconds so the descent rate is slow and pilot could adjust throttle...

-if throttle is above hovering level the board switch to stab immediately

[R-Lefebvre]

But the problem is, the system is trying to guess what the pilot really wants to do. It could be either:

1) Pilot accidentally switched with throttle low 2) Pilot is trying to stop a flyaway, or shut down the motors before impact. Switching to Stab is the fastest way to do this.

I don't think it's prudent to delay the reaction in the case of #2, in order to protect for #1.

When I crash, that is the first thing I do, is switch to stab and then try to disarm ASAP to prevent damage. That cannot be delayed further, it takes long enough as it is.

[robustini]

I agree Robert, for this reason I prefer this option can be disabled, but is required. Not good for Heli and Plane, but ok for the copter.

[rmackay9]

I wonder if an inexperienced user is going to know that he/she should set this THR_SFT parameter or are we suggesting that we'd set it to a non-zero value by default? I'm not sure yet another parameter which adds more complexity to the setup and interface is the answer.

To be brutally frank, why didn't the pilot raise the throttle? Isn't that the natural thing to do when the vehicle is falling from the sky?

The clear improvements I see are:

1. If the user tries to change to stabilize, Acro or Drift from the GCS but with the throttle at zero, the GCS warns with a "throttle at zero, are you sure?" question.
2. when the kill switch is enabled, we don't stop attitude control until the vehicle is landed. (of course we need to implement a kill switch feature).

[robustini]

I think is easy, for example THR_SFT = 90/80 % of theTRIM_THROTTLE value, or use this exists parameter to implement this safety. Imho the "kill switch" feature is important for Heli, for the copter could be dangerous if badly set.

[JSGordon]

Safety is always a issue of probabilities. Very seldom are there clear answers where not potential bad effects come into play. I think the clearer safety issue have been mostly dealt with and now very mixed cases come into play where we should try and do a more thorough analysis of the issue to decide what may be best in most of the potential scenarios and where potential impacts cay be minimized. Seatbelts help most of the time but kill sometimes.

So in this case what are the scenarios that lead to safety issue, What are the possibilities of it happening and what are the severity of the consequences. First stab - please feel free to disagree and modify add elaborate

1. Operator is in a auto mode where throttle is controlled and mode is changed to Stabilize or Acro where RC transmitter throttle controls Throttle and Throttle is very low or off without intent.

Likelihood: Probability fair - I have seen this happen (actually both with throttle low and high relative to hover).

Consequence: High probability of crash at non safe (not home) location with people or property.

If I understand the fix would prevent switch to stabilize until throttle ~= hover. Then switch would occur. So the craft would remain in control (Aileron / elevator/ yaw) if already in control but would require pilot to manually move throttle on RC transmitter until hover is reached then would gain control in desired mode where throttle is manually controlled.

If the switch was made just to switch control modes (most common scenario) then operator error crash is potentially averted.

Potential issues; Pilot understanding what is happening causing switch to delay and taking proper throttle action.

2.Operator is in a auto mode where throttle is controlled and mode is changed to Stabilize or Acro where RC transmitter throttle controls Throttle and Throttle is very low or off with intent. Pilot wants to stop props due to flyaway or imminent crash.

Likelihood: Possible but significantly lower possibility compared to 1 due to lower likelihood of crash/flyaway scenario.

Consequence: Flyaway - Delay would allow flyaway to continue till pilot take proper throttle action then Stabilize / Acro mode is engaged and control may be regained. No crash would occur unless direction of craft was towards potential impact (building, tree, ground etc.). Issue could delay gaining manual control of direction until proper throttle position is taken by pilot. Without proper throttle pilot could cause crash anyway if delay not in place.

If crash already imminent and pilot is trying to shut off props crash proceeds with powered props if pilot does not take action to bring throttle up to gain control and then down to power off in time allotted by circumstances - potentially causing more damage then unpowered crash. Crash proceeds whether fix in place or not.

Potential issues: Pilot understanding what is happening causing switch to delay and taking proper throttle action. In flyaway case or where auto mode is directing craft in direction pilot does not want does not regain manual control of direction until proper throttle action is taken.

Just thinking about above how about a the option where throttle is maintained at current level before switch but other inputs are switched to desired mode. This would address the flyaway scenario. The imminent crash and desire to have power off would still be an issue.

[R-Lefebvre]

I'm going to be very clear here.

The #1 most important consideration in this issue is this: The case where the multirotor is about to, or has impacted a person, where serious injury is likely to occur.

There can be no situation where we change the program such that the operator has no ability to shut down power to the propellers immediately. Not 3 seconds from now. Not 2 seconds from now. Not 1 second from now. They must be able to command full prop-stop immediately.

Any attempt to reduce the likelihood of some random crash due to operator error is secondary to the issue of having a method to stop the props in the case where an impact has already happened. The problem of people switching to manual mode with the throttle down accidentally needs to be solved another way. This is especially true in the case we have now, where it is not possible to disarm a copter from an auto mode, for some period of time due to the copter thinking it is still flying. The ONLY way to stop those props is to switch to a manual mode, and we must not delay that further.

Period.

On 3 March 2015 at 10:41, JSGordon notifications@github.com wrote:

Safety is always a issue of probabilities. Very seldom are there clear answers where not potential bad effects come into play. I think the clearer safety issue have been mostly dealt with and now very mixed cases come into play where we should try and do a more thorough analysis of the issue to decide what may be best in most of the potential scenarios and where potential impacts cay be minimized. Seatbelts help most of the time but kill sometimes.

So in this case what are the scenarios that lead to safety issue, What are the possibilities of it happening and what are the severity of the consequences. First stab - please feel free to disagree and modify add elaborate

1. Operator is in a auto mode where throttle is controlled and mode is changed to Stabilize or Acro where RC transmitter throttle controls Throttle and Throttle is very low or off without intent.

Likelihood: Probability fair - I have seen this happen (actually both with throttle low and high relative to hover).

Consequence: High probability of crash at non safe (not home) location with people or property.

If I understand the fix would prevent switch to stabilize until throttle ~= hover. Then switch would occur. So the craft would remain in control (Aileron / elevator/ yaw) if already in control but would require pilot to manually move throttle on RC transmitter until hover is reached then would gain control in desired mode where throttle is manually controlled.

If the switch was made just to switch control modes (most common scenario) then operator error crash is potentially averted.

Potential issues; Pilot understanding what is happening causing switch to delay and taking proper throttle action.

2.Operator is in a auto mode where throttle is controlled and mode is changed to Stabilize or Acro where RC transmitter throttle controls Throttle and Throttle is very low or off with intent. Pilot wants to stop props due to flyaway or imminent crash.

Likelihood: Possible but significantly lower possibility compared to 1 due to lower likelihood of crash/flyaway scenario.

Consequence: Flyaway - Delay would allow flyaway to continue till pilot take proper throttle action then Stabilize / Acro mode is engaged and control may be regained. No crash would occur unless direction of craft was towards potential impact (building, tree, ground etc.). Issue could delay gaining manual control of direction until proper throttle position is taken by pilot. Without proper throttle pilot could cause crash anyway if delay not in place.

If crash already imminent and pilot is trying to shut off props crash proceeds with powered props if pilot does not take action to bring throttle up to gain control and then down to power off in time allotted by circumstances - potentially causing more damage then unpowered crash. Crash proceeds whether fix in place or not.

Potential issues: Pilot understanding what is happening causing switch to delay and taking proper throttle action. In flyaway case or where auto mode is directing craft in direction pilot does not want does not regain manual control of direction until proper throttle action is taken.

Just thinking about above how about a the option where throttle is maintained at current level before switch but other inputs are switched to desired mode. This would address the flyaway scenario. The imminent crash and desire to have power off would still be an issue.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1797#issuecomment-76969402 .

[JSGordon]

Robert not disagreeing but your comment does not address the issue that a more likely cause of injury and loss could be the situation where the throttle is lost inadvertently and it falls like a stone.

So the question is how do we improve the overall safety of Arducopter. The "ONLY" way to stop props is not necessarily Manual mode. And if the issue of inadvertent throttle loss does more damage than the benefit of immediate prop stopping we should strongly consider how we fix the issue.

I personally like throttle hold switch use where I can stop the props. Part of this comes from flying helicopters but I also use switch on planes and multicopters. I am in favor of the idea of a extra safety switch to prevent early startups of props on any vehicle and to allow the operator to kill props in the advent of a crash. But I view this as two issues which both can be solved and if done improve the overall safety. I use a switch I cannot easily hit by mistake but I can quickly hit if need be. Depending on the platform I disarm, reduce throttle to zero or whatever to make sure I can do this if at all possible. I have had too many circumstance where on the ground, in the air, after landing I needed to cut throttle for safety and I have not been able or it was complicated

Overall Safety is the number one issue. How can the platform be made the safest as possible. UAS have a bad record partly because these issues are not fully addressed and largely because dumb operator errors that could be prevented are not. The Ardu platform has done a great deal with pre-arm checks, GPS glitch protection, Throttle hover point setting, etc. but more needs to be done.

But again in the end it is not a particular feature it is the assessment of overall safety that should be focused on. That in the end is "most important". How do we do this not what we don' t do.

Most all industrial equipment has a Emergency Switch that overrides all else and shuts down the equipment. I don't see why here is should not apply but as in industrial cases there typically is some protection against accidental shutdown which can be problematic as well especially with aerial vehicles.

The two most used bailout for errant vehicles I use are switch to stabilize and throttle hold. I sort of like the idea of the vehicle not making a throttle adjustment when going from a system controlled throttle to manual until the operator gives a actual input that commands this. So if the pilot has the throttle in a reasonable position at switch and reduced throttle it happens immediately and if he has the throttle near full or off he must move to a hover position then throttle control is returned to manual. A pilot in control remains in control at the switch one making an likely error is required to ginve a input showing he wants a particular action.

[R-Lefebvre]

I agree with the need for a throttle kill switch. That will happen soon. But in the meantime...

Unless a pilot is hovering their copter low over somebody's head, which in and of itself is a terrible thing to do and we cannot protect against pilots who would do such thing, then the case where the switch to Stabilize with throttle down should not pose much real risk. You simply raise the throttle, and start flying again. While the current situation is not ideal, it's manageable unless the pilot was already flying recklessly.

Conversely, the risk of additional injury due to not being able to stop the motors quickly, is very real. It could happen due to many different problems, which may or may not be due to reckless flying. When you need to stop the motors, if switching to Stabilize and setting down the throttle does not stop them immediately, there is no other option currently.

On 4 March 2015 at 09:21, JSGordon notifications@github.com wrote:

Robert not disagreeing but your comment does not address the issue that a more likely cause of injury and loss could be the situation where the throttle is lost inadvertently and it falls like a stone.

So the question is how do we improve the overall safety of Arducopter. The "ONLY" way to stop props is not necessarily Manual mode. And if the issue of inadvertent throttle loss does more damage than the benefit of immediate prop stopping we should strongly consider how we fix the issue.

I personally like throttle hold switch use where I can stop the props. Part of this comes from flying helicopters but I also use switch on planes and multicopters. I am in favor of the idea of a extra safety switch to prevent early startups of props on any vehicle and to allow the operator to kill props in the advent of a crash. But I view this as two issues which both can be solved and if done improve the overall safety. I use a switch I cannot easily hit by mistake but I can quickly hit if need be. Depending on the platform I disarm, reduce throttle to zero or whatever to make sure I can do this if at all possible. I have had too many circumstance where on the ground, in the air, after landing I needed to cut throttle for safety and I have not been able or it was complicated

Overall Safety is the number one issue. How can the platform be made the safest as possible. UAS have a bad record partly because these issues are not fully addressed and largely because dumb operator errors that could be prevented are not. The Ardu platform has done a great deal with pre-arm checks, GPS glitch protection, Throttle hover point setting, etc. but more needs to be done.

But again in the end it is not a particular feature it is the assessment of overall safety that should be focused on. That in the end is "most important". How do we do this not what we don' t do.

Most all industrial equipment has a Emergency Switch that overrides all else and shuts down the equipment. I don't see why here is should not apply but as in industrial cases there typically is some protection against accidental shutdown which can be problematic as well especially with aerial vehicles.

The two most used bailout for errant vehicles I use are switch to stabilize and throttle hold. I sort of like the idea of the vehicle not making a throttle adjustment when going from a system controlled throttle to manual until the operator gives a actual input that commands this. So if the pilot has the throttle in a reasonable position at switch and reduced throttle it happens immediately and if he has the throttle near full or off he must move to a hover position then throttle control is returned to manual. A pilot in control remains in control at the switch one making an likely error is required to ginve a input showing he wants a particular action.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1797#issuecomment-77165421 .

[abvgdeyoj]

This is hardly a feature to be discussed. It should be implemented for when needed, and when you need it, you know that you need it. Personally, i need it as i have a parachute set on a camera trigger (because i dont like the existing parachute system implementation), and i would also prefer to have a way to shut the rotors. Also, i do see some use for this in acro.

[JSGordon]

abvgeej, Is this a vote for a throttle hold?

[JSGordon]

Robert, I think the area we disagree on is risk assessment. I find it had to classify on out of control condition so very different from another in results. A copter dropping like a rock at some random point can cause just a much damage and injury as a copter in a flyaway or out of control situation.

On a single rotor heli my opinion would be different as opposed to a falling rock. There the greatest danger is from the blades of the copter and in the case of a single rotor you can autorotate. But again here I would use the throttle hold capability since dropping throttle would propel the copter down with negative pitch.

[R-Lefebvre]

Let me put it this way. Most machines these days are required to have a safety kill switch. It must be simple and accessible. It must cause the machine to cease power output immediately.

Dropping the throttle is currently our only kill switch. We cannot remove it at least until it is replaced with something better.

On 6 March 2015 at 10:03, JSGordon notifications@github.com wrote:

Robert, I think the area we disagree on is risk assessment. I find it had to classify on out of control condition so very different from another in results. A copter dropping like a rock at some random point can cause just a much damage and injury as a copter in a flyaway or out of control situation.

On a single rotor heli my opinion would be different as opposed to a falling rock. There the greatest danger is from the blades of the copter and in the case of a single rotor you can autorotate. But again here I would use the throttle hold capability since dropping throttle would propel the copter down with negative pitch.

— Reply to this email directly or view it on GitHub https://github.com/diydrones/ardupilot/issues/1797#issuecomment-77572611 .

[hotelzululima]

this would be ok if this mode was ONLY entered in volition.. but when a tablet is used then stab at throt 0 on the RCTX has to be set to arm from the tablet/telemetry, if and when a RCTX comms error occurs that STAB with throttle =0 setting on the RCTX will promptly override the current GCS mode and crash the craft guided by an arducopter/APM/PIXHAWK currently(speaking from experience today).

see issues 1951(1951 is similar to this issue but relates to the RCTX error causing unintentional entering of STAB thr=0 as part of tablet/telemetry channel arming of the vehicle

issue 1952 addressing the different facets of SAFETY and interlocks vs GCS vs RCTX and modes/thr settings.. throttle dropping as a supposed "safety" if needed needs to be a specially distinct "CRASHME" mode... and a covered kill switch should be mounted for this function ,NOT kidding about this name either.. it needs to be labeled that so it will NEVER be selected in error or by default it should above all NOT be labeled STOP(that will get pressed/tried in error). nb I suggest you check either OSHA or Cal OSHA for safety stop switch requirements and interlocks since you claim this is FOR that safety function(a whole army of tort specialists could be in your future :) if you get it wrong here :) (HINT: THE FAA HATES CRASHME SWITCHES!) it will never get by the flight safety folks..:) either in this name or other names.

   hzl

[R-Lefebvre]

How does the computer system determine "volition". Did the pilot command this state on purpose, because they need to stop the props, or by accident (because they did not program their FS_THR system in this case, and their RCTx auto-powered-off)

You did not utilize one of our primary safety features. I think the safety-shaming here is misplaced.

[hotelzululima]

You never stop props on an aircraft in flight that has ZERO glide ratio... small safety issue :) 9.8 m/s**2 is an unforgiving constant...

small observation.. no RCTX I have ever owned since 1975 has ever had an autopower off??

another observation.. if it is a PRIMARY safety feature then how come its(THR-FS) NOT set by DEFAULT?

another observation is that without specific interlocks to address this issue of RCTX comms error causing preemption of the commanded GCS flight mode then indeed

its SAFETY SHAMING as you so eloquently stated.. (ps a THR-FS setting is NOT the proper design feature to address this issue

(small point dad was a Chief Flight Safety inspector/Crash investigator(GS-14) in OKC for the FAA before he retired, and a test pilot for the first Semi Automated flight inspection system platform in 1973.) Convair 580 with a mainframe computer and 8 track tape drives aboard(state of the art in 73 :)

I am a FAA certified gyrocopter pilot since 1985 and a P4 rated paraglider pilot.

I LIVE EAT and BREATH flight safety to a much greater degree than your normal RC pilot.

NO CRASHME switches even hidden should ever be on a craft that is airborne without benefit of a glide ratio especially those in the RETAIL CONSUMER MARKET (even sold at frys.com now)

DJI understands this.. why does it seem such a problem of comprehending this here with this project.

[lthall]

Copied from another issue: The current assumption Arducopter works on is that the RC transmitter is the primary control and all other methods of control are secondary. We could implement a ch7 or ch8 switch that is used to define that we are not operating the RC transmitter and are instead operating from the GCS. This could then be used to ensure we enter Loiter, RTL or Land (or what ever we think is appropriate) if we loose GCS (or switch back from the GCS). The RC transmitter operator can then take control at any time by flicking that Ch7/8 switch back to RC control.

And:

hotelzululima, anybody who flies over random people at the local park, like you described yourself doing, is a long way from flying safely. Also you should google "argument from authority fallacy", although your also make use of a few other Logical Fallacies in your arguments but they are less obvious.

[R-Lefebvre]

Is there ANY manned aircraft that has a zero glide ratio? I can't think of any. Even an F-104 can glide, and no hover-car or jetpack has ever made it into production, probably because of this. And as stated in the other issue, if you don't fly overhead people, zero-glide will never be an issue.

I do not know for sure that your RC Tx has an auto power off. But I can confirm that many modern controllers now do. The Taranis does for sure, and I would not be surprised to find out that EVERY modern computer radio now does this. Hopefully they all give ample warning as the Taranis does (at least a minute of beeping) but again, I have not sampled every unit out there.

Why is FS_THR not configured on the Iris? I'm not sure, that's a good question. And FS_THR would have absolutely prevented your specific problem. It is absolutely the proper design feature to address this issue.

Was your Dad ever a safety regulator on unmanned aircraft systems? I think not. If he were, you would probably be aware that flight termination protocols for UAVs are not only not-illegal, but are actually MANDATORY in more and more jurisdictions.

DJI does many things right, and many things wrong. We can debate which side of that they're on on this issue, but you'll probably lose, as I have said, many jurisdictions MANDATE external flight termination systems. In fact, DJI may have been the primary reason this has become required...

[hotelzululima]

@ithall uh small comment about random people using a space.. 3RD employees do this(flying over random people) pot kettle meet mr black.. on a semi regular basis at the Berkeley marina.. cant be avoided really... from a practical aspect

@R-Lefebvre 9XR with stock software does NOT have a autopower off configured..

btw in 73 the ONLY drones flying were old regulus missles and ryan firebee target drones always used for target practice no other functions .

Dad made decisions involving flight safety systems.. 3DR code and drones would have been barred from the NAS given what has been observed by myself and 3DRs own test pilot Marco Robustini

BTW my only concerns here are about the US/NAS and the California product safety commission.. in BOTH cases the use of a flight termination system that can be invoked in error is a FAIL court wise..

and flight termination systems that can be invoked on a RCTX in error while in flight is the real issue here.. NOT flight terminations systems themselves which again should not be associated with a flight mode named "Stabilize" Trust me in that this is a lawsuit you are guaranteed to lose given the decisions and statements you and the other developers have already made and posted their opinions of..

The rest of us out here get it ,Flight Safety is NOT the overriding concern of the APM development group! the mere fact you have and use a term such as "safety shaming" informs me the developer culture fostered here is the real core issue..

and when the product safety class action suit happens in California against 3DR for people hurt by this issue you can bet the developer intransigence shown by your attitude, lthalls and Craig Elder in these discussions WILL be a factor in how large the jury award will be , as I have stated before.. Toyota/OKC changed the entire tort landscape for lawsuits using embedded computer systems..

and again this is NOT a debate.. this is informing you and 3DR officially that there is MAJOR false preemption issue with the way that the IRIS/IRS+ is sold and recommended for use with GCS AND BACKUP TX SIMULTANEOUSLY IN THAT CASE THIS IS A FAIL, Marco's friend hit it and I hit it.. only difference is I have been inside your code and the fucking emperor has NO FUCKING CLOTHES on..ie there ARE NO interlocks to determine volition from xmission errors vs GCS vs RCTX errors.

All manned aircraft have a zero glide ratio at zero airspeed.. safety is in flight height and airspeed...

[lthall]

hotelzululima, If you have a problem with 3dr's practises or products then take that up with 3dr. This is an open source project and is not owned by 3dr or anybody else.

As for black pots and kettles. I don't care how many other people are flying over people, or who those people are. It is not a safe practise and YOU should not be doing it. Flight safety is YOUR responsibility.

THIS IS NOT A 3DR FEEDBACK SITE!!!

(Spelling corrected in response to ad hominem argument from someone who doesn't know how to use capital letters or punctuation - face palm)

[hotelzululima]

lthall.. this development is funded by 3DR and they will be the ones who suffer/get sued from using this.. as to your attitude? stuff it youngster!... as you stated its an opensource project.. look for a flood of issues to be filed regarding this.. and code changes..

and again the attitude of you and others towards flight safety will just get the patron of this code(3dr) sued.. good job !

btw learn to use a spell corrector.. sheesh..

[rmackay9]

Guys, let's keep the discussion focused on the issue originally raised and how it can/can't be implemented. To keep things civil, personal comments should be avoided For example the comment about the spell checker.

By the way, the IRIS does come with the FS_THR enabled. https://github.com/diydrones/ardupilot/blob/master/Tools/Frame_params/Iris.param#L20

[hotelzululima]

thanx for that last.. so many parameter files have been loaded to this IRIS.. it probably got lost in the shuffle.. and again these bugs and comments are being filed by myself in attempt to comply with California product safety law for my customers eventually..

and again.. folk can sing and dance about saying you cant sue us open source project .. and since 3DR is a California corp and is the main financial supporter of APM and uses that code in their products solely they ARE responsible for what goes on here in California with their products.

The real issue here has been flight terminations systems associated with ANY flying mode.. In that Marco, Rob and I seem to be agreed..

while there is a safety case for a flight termination system, folks are crashing because its tied in a negligent fashion to a flying mode and as such copters ARE crashing and someone WILL get hurt in California eventually where 3DR can be taken to task in court.

The manner to date in which this bug has been handled is in FACT negligent under California product safety law.

I AM trying to prevent that as I was planning on using 3DR products in my vending to City agencies which of course are in California.. would be a bit inconvenient..

[JSGordon]

The fact that we are trying to determine the safest way to program the system is evidence this is not negligent. Also any it is highly prejudicial for you to state as a "fact" that there is negligence under California or any other body of law. Let's quite with hyperbole and bullying and focus on working to find the best solution. Many of the arguments seem to be in regards to when certain are implemented relative to others and what the relative risk factors are.

So lets start by focusing on the end game. Regardless of the order features may be implemented can we come to a consensus on what the final state of safety systems would be for the issues we are discussing including how props stops or auto to manual mode switches are handled.

Again I think a systematic analysis approach is best as this is a proven approach to handling safety issues and can help us get a better grip on the issue and relative risks as well as proposed fixes. We should concentrate on proposed fixes we can come to agreement on rather than focus on what we don't like about each other suggestions. Focus on end state. This should be considered more brainstorming for solutions and then we can try to determine the best solution. But cutting down every idea is pointless.

So I will try to summarize later proposed issues and solutions and risks mentioned. Let's try to make this a positive results oriented approach rather than a negative evasive discussion. Please try to add suggestions or explain your proposed end state in the meantime. When safety issue become more complicated in advanced systems with complicated and variable environments there is noanswer tthat can fix every scenario so we deal with trying to find the best solution with the least risk overall.

What we are missing unfortunately is a database of failure occurrences to help us in our understanding of risks. Automobiles and full size aircraft have this to guide in such decisions. We are using our own experiences to guide us and these may vary due to randomness of small data sets and different user applications and implementations.

[JSGordon]

Also to keep this more on track can we use scenarios and not talk about whether some is flying over peoples heads or whatever. This does not help us focus. One could be flying on a auto mode see the aircraft is going in a direction other than intended or the ground situation has changed. Either if these could lead to a situation where the copter could drop on unintended areas. Just because someone does not intend to get into situation where the vehicle is in a situation where damage or harm could be a result does not mean the situation will not arise. This issue for the system is once the situation does arise no matter the cause how do we deal with it. And as UAV progress if they are used in urban area this is going to be reality as it is with normal aircraft. The provision we fit in now will help insure safety when these situation become more common. Military UAV obviously go over people. Mapping UAV will probably run into this and systems like Google on other are talking about will fly over people eventually. I don't now because the systems are not reliable enough and don't have enough safety features but the day will come where this is done purposely and our systems should have provisions for the circumstance where we are over people and are trying to take taking appropriate action. today we need to make sure if this happens inadvertently or due to error we have the best systems in place.

Sorry for the soapbox

[R-Lefebvre]

JS, you make a good point about how we could unintentionally end up over people's heads. Thanks for the rational commentary.

[hotelzululima]

yes indeed thanx JS..your soapbox is quite welcome here and again my customer base(public safety agencies) is already doing this with present day tech. so effectively all this is in catchup mode..

   hzl

[JSGordon]

Guys I'm running a little behind on daytime stuff. Will update as soon as I can

[nocomp]

hi folks, finishing my plane, and did some testing andI am facing one issue regarding throttle. In manual mode everything is fine, when i switch to stabilize mode, no more throttle, same for rtl. am i missing something? first time it does that to me. thxx for your help and your time.

[andrea25]

I think this is not the right topic.

By the way have you ARMED your plane? Have you finished all calibration?

By the way, is better if you post the question in the right topic.

[nocomp]

yes, plane is armed, sorry didn t knew it had topics here. sorry for inconvenience

[andrea25]

Don't worry ;) Try to find the information that you need in one of these places: http://plane.ardupilot.com/ (The Wiki) https://github.com/diydrones/ardupilot (Use the Plane section) http://diydrones.com/ (Use the right topic/post)

I hope that this can help.

I'm sure that someone that can help you will pop-up ;)

[nocomp]

yep i am hunting for an asnwer everywhere, not much success, i wonder if that happends because the plane is not moving, i am doing the test in my office in fact

[andrea25]

Maybe you can also ask something here: http://diydrones.com/forum

But for understanding better your issues is better if you open a topic and attach a log and a video. With the log and the video is much easier to undestand where the problem is.

[nocomp]

already done ;) http://diydrones.com/forum/topics/help-arduplane-no-more-throttle-after-switch-to-any-assisted

thx for your time

[rsilk1949]

Thanks for referencing my duplicate issue. Was any conclusion reached on a solution for this? My issue proposes a failsafe optional param -- switch over to AltHold if a maximum rate of descent is exceeded. An alternative, as suggested above, could be to compare throttle position value less than a particular setting (e.g. THR_SFT) as the trigger.

[Saxin]

Wanted to add my 2 cents:

Today (Starting from AC 3.3) we have "brake" mode which can be assigned to aux switch / toggle on the RC, so in the event of uncontrolled descend / ascend one can switch into brake and arrange his thoughts (don't forget to breath), adjust sticks to required position... (Refer to wiki for demonstration of Brake mode)

(I've had it all, crash when switching into stab from pos hold with zero throttle, copter firing itself half km height, same scenario but throttle was 0.75, switch to stab during RTH with throttle at 0 and many more.... I'm not against the requested feature and I think I personally and many more will benefit from it but we need to see the other side of the coin - solving one issue but introducing another is always a bad practice, it will bite you if not right away sometime it will...)

[rsilk1949]

This manual method is OK if the operator realizes what is happening and has the presence of mind to throw the switch in time to avoid disaster -- which is often only a second or two, depending on the current altitude. Personally, I would prefer programmed intervention as being a safer and more reliable method. However it is done, it should be an optional failsafe.