BRD_SAFETYOPTION overrides BRD_SAFETYENABLE

[MidwestAire]

Tested with Copter 3.5.7, 3.6 and master. If BRD_SAFETYENABLE is set to zero (disabled) the BRD_SAFETYOPTION being set to 3 (default) overrides the disabling of the safety switch. This still causes an in-flight disarm if if the switch signal is pulled to ground, no matter what causes it.

The logic should be that if BRD_SAFETYENABLE = 0 the BRD_SAFETYOPTION setting should not apply. BRD_SAFETYOPTION should only apply if BRD_SAFETYENABLE = 1

Referencing this issue posted by @Pedals2Paddles #9266

[WickedShell]

BRD_SAFETYENABLE is misnamed it's actually only an initial state for the safety switch rather then a disable for the button. (I agree it's very misnamed, but in it's defense the parameter documentation does describe this). If you want to disable the switch you need to set BRD_SAFETYOPTION to 0. The code does attempt to prohibit the use of the button if you have the options set to 0. Without setting the third bit though it shouldn't be able to deactivate (or activate) the safety while armed unless there is a communication error on conveying the armed state. (It's retried at 1 second intervals though unless it hasn't succeeded).

Are you seeing an actual failure in this implementation, or is it just a misunderstanding of what the values mean? (and their bad documentation)

[Pedals2Paddles]

I guess I also didn't read the parameter description beyond the name either. I'm having a hard time following the code where this is used. If the option is set for 0, what can the button do while disarmed?

[MidwestAire]

My opinion is that if there is a parameter to disable or enable the switch, that if it is disabled it should be truly be disabled. The circuit should be ignored entirely. I tested this on the bench last night with a Cube and Here GPS with pins 6 & 7 pulled from the plug. BRD_SAFETYENABLE = 0. Which any normal person would consider disabled. Left the BRD_SAFETYOPTION set to the default of 3. I dropped a single drop of water into the open slots in the connector that did nothing more than short the pin signal to the LED driver pin. It instantly shut the controller down from armed state.

Even with both parameters set to zero, as per the issue Matt noted, it still randomly enables itself at boot with ChibiOS. Even with no switch installed.

So I don't think the code logic makes sense. The purpose of the change in 3.5.7 was to prevent in-flight disarm. Instead of adding a complicated option that still allows in-flight disarm why not totally disable that circuit if the landed flag is not set? There is no reason for anybody to ever press that button on an aircraft in flight. The only thing that would cause it is a hardware fault. Philip has noted that circuit is not 100% reliable and the switch is not safety rated in the Here unit. The CUAV switches are actually worse - simply touching the back of one of those to a carbon fiber frame will disarm the controller (tested here with both a V3 and V5).

So my recommendation is get rid of the complicated option. Go back to enabled or disabled, but if the landed flag is not set, the circuit is disabled no matter what.

[Pedals2Paddles]

The parameter isn't supposed to disable the switch as it turns out. It's supposed to set the startup state of the switch, nothing more. The parameter description is correct. The parameter name should be changed to BRD_SAFETY_START or something like that to remove the mistaken (though not unreasonable) assumption it disables the switch for people who didn't read the description (like us).

Leaving the BRD_SAFETY_OPTION set to 3 when you'd never want the button to disarm in flight is operator error IMO. Easy for me to say since I don't even have the button wired up. But the option to prevent it was there and simply not used (or not known?). Or not really a consideration at all until the vulnerabilities became more obvious recently? I'm torn on whether or not that should be the default option.

[Pedals2Paddles]

In fact, let's at least fix the easy misunderstanding. Just made this incredibly simple PR. https://github.com/ArduPilot/ardupilot/pull/9307

[MidwestAire]

Even if you change the name of BRD_SAFETYENABLE to something else, the code logic is still not right. The logic will still allow an in-flight disarm, and I believe there is no reason that exists where that switch should be allowed to cause an in-flight disarm, no matter what the settings are.

The bad part about allowing the switch circuit to disarm the controller in flight is that it shuts down the I/O processor. Both helicopters and airplanes can be flown and safely landed with the controller disarmed in flight - but not if the I/O processor is shut down.

So I view this as a critical safety flaw in the code. A combination of settings will allow a hardware fault to cause an aircraft to fall from the sky with no control when that aircraft is otherwise able to be safely landed if the fault occurs. And the code should prevent that fault from causing a shutdown in the first place. That circuit is only useful on the ground - never in flight.

One of the side effects of allowing that circuit to disable the system at all in flight is that with combustion engine aircraft that use throttle shutdown (no ignition switch) is that they remain running when the safety switch circuit disables the system. The throttle does not return to idle cutoff when the I/O processor is suddenly shut down. The only engines that will actually stop are turbines (FADEC or ECU) that will go into shutdown sequence if throttle signal is lost. But pistons that use a throttle servo will remain running at where ever the throttle servo rests when it disables. If this is a helicopter on the ground, you can't get close to that machine to stop the engine manually because the machine will kill you.

[Pedals2Paddles]

The code logic works fine as designed. It will only disarm in flight if you have the 3rd option bit set. If you do not want that to happen, then do not set the 3rd option bit. Clearly for your purpose (and likely many others), it is not desired and should not be set. But there are probably plenty of other use cases to have the ability.

Perhaps it shouldn't be set by default though? Or perhaps should not be set by default for helis? I'm not sure what discussion went into that decision at the time.

[MidwestAire]

Nossir, it does NOT work as designed. That's why I raised the issue. I had it shut my turbine down last Saturday with both options set to zero but a switch was still connected and I had a hardware fault. Thankfully it was a turbine with its own ECU and not a piston with a magneto. If it would've happened to a piston engine with magneto ignition (or a nitro) there's no way to stop it once the system shuts off the I/O.

Therefore I maintain that the system should never be allowed to use that circuit once the aircraft is off the ground - regardless of what the settings are.

I believe my shutdown was caused by the issue you originally posted where with ChibiOS the system can randomly enable itself at boot. As I had to press the button to get the engine's ECU to initialize and go into start sequence. But it still brought out a glaring fault in the code logic.

[Pedals2Paddles]

The original ChibiOS issue should not affect anything but the startup state of the switch. It couldn't affect anything else since it's just the startup state.

BUT, I think I now know why you had this in flight disarm even with brd_safety_option set to zero. The code logic isn't flawed. The problem is the code logic only exists in the nuttx PX4 I/O. It hasn't been implemented in ChibiOS yet at all. https://github.com/ArduPilot/ardupilot/search?q=safety_option&type=Commits

I think it may be best to stick with nuttx for flight ops other than specifically testing ChibiOS stuff until a critical system like this is implemented.

[auturgy]

https://github.com/ArduPilot/ardupilot/pull/8156 and the linked issues may be of interest.

[MidwestAire]

Well, actually I'm not satisfied with the implementation in PX4/IO either. There should be no combination of settings a user can make that causes that switch circuit to be active in flight. And it should not be active at all with any combination of settings for combustion engine aircraft because there is a danger of loss of I/O leaving an engine running that can't be stopped.

I have brought the issue to attention to make folks aware of the flaw in it. This flaw does not exist in any other autopilot system, FBL unit, or controller I know of. None I have seen have any combination of settings that can shut down pilot control of the aircraft in flight or cause loss of control of engine shutdown. If there is no interest in fixing it in the mainstream code, I will fork Copter 3.6 again like I did for 3.5 and make an ArduHeli build for helicopters that is safe to fly. That prevents users from making arbitrary settings that can cause a dangerous shutdown of the I/O.

Unfortunately, the current implementation might be ok for hobby users. But is simply not suitable for commercial users of the system at all.

[Pedals2Paddles]

I could make an endless list of parameter combinations that could be bad. Demanding that nobody with a legitimate use case for a parameter setting should be allowed to have this functionality because you do not personally want it to exist is just not how it works. The entire user base of ArduPilot cannot revolve around one person's incorrect parameter setting.

The parameter is there for you to disable the button functionality (in nuttx) and it works. If you as the operator set it wrong, that's on you as the operator for making that mistake. No different than setting your failsafe configurations wrong, or setting a kill switch wrong, or any number of settings that are critical to flight. If I screw up some failsafe parameter and turn my copter into a lawn dart, that's my fault for making a mistake. I don't then demand ArduPilot remove failsafe options to prevent me from making a mistake, all other uses be damned.

[MidwestAire]

I'm not demanding anything. I'm pointing out a flaw in the logic. I'll just fork it to fix it so helicopters are safe to fly.

Most of the focus in Copter is on multi-rotor aircraft which are electric. More advanced aircraft with engines are different and have different requirements. Since I have already found a flaw, despite settings that were supposed to prevent it in a release that is soon going "stable" I have no choice but to fix it for commercial users of the system. And that will require a fork as the consensus is that the current implementation is "just fine".

Eventually all the things we put in ArduHeli 3.5.x eventually made it into Copter 3.6 as it was found there was flaws in the mainstream code, mostly related to multirotor aircraft. Now we have new ones in 3.6.

[Pedals2Paddles]

In nuttx, which is the only rtos currently stable for production use, you have the parameter to disable this while in flight. The parameter works fine. The logic works fine. The code works fine. User error not setting the parameter correctly is not an ArduPilot/code/logic flaw. Wanting the functionality entirely removed for all users to match your personal use case, to prevent you from personally making a parameter setting error, is absolutely a logical flaw that I don't think is reasonable to force on everyone.

You are someone I would personally consider an authority figure when it comes to RC trad heli. I'd wreck one of those things before it gets off the ground. So I absolutely defer to your expertise on it have no use case whatsoever in trad-heli. So perhaps what would be more reasonable is proposing that the functionality be removed only from trad-heli?. I think this can be done with preprocessor ifdef directives, as is done all over the place in the code where heli differences from multi. That would allow trad-heli to have no way to make this mistake, without adversely affecting all other multirotors, planes, and rovers that do have use cases for it.

ChibiOS is not production stable yet. There is no expectation that everything works properly. Safety switch related issues in ChibiOS still have to be worked out and that should be expected. Your recent experiences in ChibiOS should have absolutely no bearing on stable/production use of parameter settings that do work perfectly fine. You can't mix the two to form one argument... that's flawed logic :)

[MidwestAire]

I think I will close this issue, as the discussion is centered around (my point) that no combination of settings should be allowed to be made that can cause the safety switch circuit (regardless of a switch being installed) active if the ap.land_complete flag is not set. There is no logical reason, despite any settings, to have that circuit be recognized as being active with an aircraft in flight. It is a serious flaw.

Since this is not recognized by the rest of the dev team at this point as a problem, I will fork it and fix it in the code I fly. The fix will eventually be PR'd to Copter 3.7 when it is better accepted after more people experience the problem :-)

[Pedals2Paddles]

I don't speak for the dev team. My discussion with you on this matter is not reflective of the dev team or anyone by me.

[lvale]

@ChristopherOlson Reopening because it deserves a careful trace of the logic, and possible unexpected hardware interactions

[MidwestAire]

@lvale OK, that's fine. I'll just quietly fix it in the mean time and then we'll see what the rest of the dev team thinks about it. After I found out a single drop of water will shut one of these things down with the default settings, that sort of raises some alarm flags.

[WickedShell]

I was not attempting to dismiss any of the points raised here. I was primarily looking to differentiate between requested behavior and expected behavior in the parameters.

If you are able to actuate the safety state with both parameters set to 0 then I 100% agree that is a bug and not the expected behavior, and is something we should investigate with a priority.

Just to clarify a couple of things if anyone involved in the conversation wasn't following: Both PX4 and ChibiOS builds use the same PX4 IO firmware, the difference is only on the FMU firmware, and they use different implementations of the protocol to talk to the IO processor. (The ChibiOS one is missing a number of calls at the moment, primarily related to mixers and failsafes).

There is no logical reason, despite any settings, to have that circuit be recognized as being active with an aircraft in flight. It is a serious flaw.

There absolutely are reasons to have it be recognized, but it is an active tradeoff with the risk of it being pressed in flight, and what vehicle type you have. The landing detection code can't be considered reliable, and the button can be used to stop all motors in the event of a crash. (This is primarily useful on Plane, usually in conjunction with BRD_SAFETY_MASK to allow control surfaces but not motors to keep moving). I grant that for helicopters where you'd never want to reach into a crashed vehicle anyways that this isn't of any value, and I even disable the switch on my quadplanes, as it doesn't feel any safer to be reaching around motors on them.

Just so I'm tracking (and can attempt to reproduce the issue) with BRD_SAFETYENABLE 0 and BRD_SAFETYOPTION 0 you can still actuate the safety switch? And is this happening under both PX4 and ChibiOS builds?

[MidwestAire]

I don't know about PX4. I was running ChibiOS. I started the system up and did my pre-flight, including swash correlation checks. I have a special setup for starting turbines because the throttle has to go to wide open to initialize the FADEC to begin the start sequence and engage the starter. When I armed I got "hardware safety switch error" from the ground station and the red LED was blinking on the Here GPS unit. So it failed to arm. I pressed the button on the thing and then it armed so I started the engine, it went self-sustaining at ground idle. I increased power to flight idle (throttle hold on a heli), engaged the clutch and spun up to rated power. Increased collective to light on skids and just lifted off when it flamed out and shut down. The red LED was blinking again and it disabled the I/O.

That controller I found had a hardware problem - the GPS connector and traces had come loose from the board. But I did have both params set to zero so it should've ignored it. That controller was a Cube.

I did further testing on the bench with a CUAV V5 and found I can randomly get that one to ignore the settings as well on the bench.

The landing detection code can't be considered reliable, and the button can be used to stop all motors in the event of a crash.

It seems to me, that at least in Copter, that if the landing detector is reliable enough to perform auto landings or takeoffs that it should be reliable enough to disable the switch circuit if the flag is not set. I think the original idea of those switches was prevent accidental start of multirotor aircraft, which normally start spinning their motors as soon as the system is armed. So it adds an extra step that was presumed to add safety somehow.

But in the case of helicopters (and likely plane as well) all the servos are active with the system unarmed, except for the throttle servo. This is because these aircraft can continue to fly just fine with the controller disarmed, and land it. But if the I/O is shut down by a fault in that switch circuit it can't be flown in an emergency (either intentional or unintentional) disarm in flight.

I don't see where ability to press the button after a crash to stop motors has anything to do with having the circuit disabled in flight by default. But if the aircraft crashes either the landing detector or crash detector should enable it again if that is the setting - it is no longer in flight.

At any rate, to reproduce the issue on the bench, use a ChibiOS build (have not verified with NuttX), set your params to zero, and repeatedly boot the controller until you get a code logic fault and the switch is now self-enabled.

The other way I found I could get it to happen is to simulate a hardware fault by shorting the LED driver pin to the switch signal pin, which will also enable the switch. I did it by dropping a drop of water into the GPS port (with the switch disconnected by pulling pins 6 & 7), which instantly shut the system down. But it should be able to be done by physically shorting the pins as well.

[MidwestAire]

@WickedShell Must stress this is random (at least with ChibiOS). It does not happen every time. During bench testing it is just a chance happening that the switch will self-enable. I thought it was my hardware problem until Matt posted an issue that indicates he has experienced self-enabling of the switch at boot as well.

[Pedals2Paddles]

Testing this in nuttx is important. You're making these accusations of horrible fault that makes ArduPilot unworthy of your use, when you're testing it on a non-production work in progress that is known to be incomplete (ChibiOS). After being told numerous times the safety switch issue is not done yet in ChibiOS. Again, Nuttx is the safe, stable production RTOS.

That controller I found had a hardware problem - the GPS connector and traces had come loose from the board. But I did have both params set to zero so it should've ignored it. That controller was a Cube.

First you blamed and trashed the HERE for this. Now you're blaming the Cube. But it's not the cube, it's the carrier really. But in your video and prior posts about this, you showed that it was because you had the carrier too close to the hot engine and melted it. It would best to not blame hardware and/or firmware for operator error.

[MidwestAire]

Matt, feel free to help test it with NuttX if you want. NuttX is being deprecated in ArduPilot and if you want to continue using it you'll have to go to PX4. ChibiOS is getting the development effort. Since I identified this problem with ChibiOS, that is what I'm using to track it down.

Since I have identifed that a hardware fault can cause undesired results from the switch logic, that was supposed to prevent those undesired results, I'm going to change it. That change will only be implemented for helicopters which can never under any circumstances ever have the I/O disabled.

[Pedals2Paddles]

It isn't deprecated yet. And it is still the safe, stable, production RTOS, which is what you should be using if you commercial customers require safe, stable production firmware. ChibiOS is known to be incomplete, and you are wrong to act like anyone is claiming otherwise. Ranting that ArduPilot has all these horrible flaws, forcing you to make your own fork is complete non-sense. You are intentionally not using the safe stable version, and complaining that isn't safe and stable. It's absurd.

[MidwestAire]

Matt, please. I have identified an issue that is highly dangerous with combustion engine helicopters, related to the safety switch logic. I have tested it and determined IT IS NOT SAFE TO FLY. This does not affect you at all until the fix I apply to it in my custom fork is eventually PR'd to master. The fix will likely not be initially popular in the mainstream code.

In the mean time we need to identify why the switch circuit is being randomly enabled with ChibiOS. And fix that in the mainstream code first.

[peterbarker]

On Tue, 28 Aug 2018, Chris Olson wrote:

which can never under any circumstances ever have the I/O disabled.

Why are you using the "safety switch" in the first place?

AFAICS they're insane.

So... what do people think about having an RCn_OPTION to enable/disable the "hardware safety switch"? It would be safer than having people reach into the whirling blades of death to arm or disarm their vehicles.

[WickedShell]

@ChristopherOlson I'm very confused here. You earlier stated you could recreate the problem by shortening the pins and you thought it should be disabled. Since shorting the pins is identical to pressing the button that means that pressing the button to test is identical/sufficient for attempting to get the switch to misbehave on the ground. What where the parameters at this time and was the vehicle armed? I'm trying to get a description of the failure you are describing and thus far it's very unclear to me. If you want to post a log file that would be fine as that would make it easy to investigate (assuming you log while disarmed). At the moment though I just can't tell what the parameter set is that you are attempting to work with.

The main value to pointing at if it occurs in PX4 builds is because that narrows it down to either being a regression or a failure in the PX4IO code (which you are still using on ChibiOS). As it stands if you want to chase this from a ChibiOS build first perspective you have a much wider scope of possible causes. I'm only asking about the PX4 builds as it's the first (and significant) step to a narrower reproduction case.

(and likely plane as well) all the servos are active with the system unarmed, except for the throttle servo.

This is not the default behavior for plane, you have to opt into it. Copter has it because it sets the default value for BRD_SAFETYMASK to be the inverse of the motor mask.

[MidwestAire]

@WickedShell I am only testing ChibiOS.

I'll recap: When I first found the problem I had a switch hooked up because it's included by default in the Here unit. The LED on the switch alerted me to the fact that it had ignored my SAFETYENABLE = 0 setting. It was a What? and enabled it anyway by pressing the button. it disabled again by itself when I tried to take off with it.

Well, this wasn't good.

Ever since I have been testing on the bench to see why it did that. I have one test machine with a Here GPS with a button, and another one with no button installed. My initial testing params were to have the button disabled, but I had the default bitmask (3) that came with the new BRD_SAFETYOPTION param since I had never looked at it before. Since, I have tested every combination of bitmask set for BRD_SAFETYOPTION to see if there one that causes it to self-enable. I have not found one - it is random. When it enables by itself I am shorting the pins on the one test unit because I don't have a switch on it. I want to see what happens if there is a hardware fault and it enables by itself. I have tried various things, including pulling the pins from the Here unit, I put water in the connector to see what would happen, etc.. None of the results were particularly confidence inspiring in this safety switch system.

So then, after all this testing my question became, if BRD_SAFETYENABLE = 0 why is the switch circuit active at ALL? That doesn't make sense. What good does it do to disable something if it is not truly disabled?

Any reasonable logic says: BRD_SAFETYENABLE = Disabled; it is disabled and can never be active and cause a problem

BRD_SAFETYENABLE = Enabled; so now it works and we have a new BRD_SAFETYOPTION that be set to control HOW it works.

Twisted logic says: BRD_SAFETYENABLE = Disabled; well, it's not really disabled, that's only for the startup state and you have to set BRD_SAFETYOPTION = 0 to really disable it. But it doesn't actually say that in the wiki:

This controls the activation of the safety button. It allows you to control if the safety button can be used for safety enable and/or disable, and whether the button is only active when disarmed

So you read this and go "what?" It was set to 3 by default. A hardware fault may have triggered it, but wait a minute - according to my calculations that bitmask means the sum of ActiveForSafetyEnable + ActiveForSafetyDisable. It is not ActiveWhenArmed. So......why did my helicopter shut down from armed state at full power?

Ah, there is a problem in the code. Should've known there was a problem in the code when it self-enabled and I have it disabled. And I've been trying to identify what it is ever since.

This problem did not exist with ChibiOS before the change was made to put in the BRD_SAFETYOPTION. I have been flying and testing ChibiOS since day one. Prior the halt in rc testing and the big push to get BRD_SAFETYTOPTION into 3.5.7 I never had single instance where that Crash Switch enabled itself. The logic with those two parameters is so illogical that if you enable the button and set OPTION = 0 the aircraft becomes extremely safe because you can't arm it and fly it. The button is enabled but it don't work.

There is some airframes where it is absolutely dangerous to ever shut down the I/O. Helicopters are one of those. Changing the name of the parameter doesn't fix the base problem. I have reviewed reverting the code that put that SAFETYTOPTION in, then permanently disabling and removing the BRD_SAFETYENABLE for helicopters. I'm going to make that change tomorrow and build it and test it and see if the problem goes away.

[MidwestAire]

I'm only asking about the PX4 builds as it's the first (and significant) step to a narrower reproduction case.

@WickedShell at the present time I am not able to help with testing PX4 builds as I have none of those controllers in my helicopters with servos hooked up. Since the servos on helicopters are active when disarmed I use that as the benchmark as to whether or not the I/O is actually disabled by the fault.

Reverting the commits that put the OPTION in the code and testing that is pretty easy. If the problem goes away that should narrow it down. On my last bench test it took over 20 reboots to get the fault to happen.

[MidwestAire]

@WickedShell I reverted all the commits in ArduPilot and PX4Firmware that added the new logic and never got it to happen again.

I guess I've found a solution that will work for helicopters, and that I can probably modify to prevent the I/O from ever being shut down on helis. It is frustrating to figure out what is causing it because I've flipped the master switch on and off to continually to reboot the controller for 5 - 10 minutes sometimes before I get the fault. On one of those tests when it went Self Aware I continued testing by trying the switch. When it shut down the I/O it slammed the throttle wide open (disaster of epic proportions if you have a magneto piston engine) and happily simultaneously broke the rudder linkage when the servos exceeded their set limits: https://photos.app.goo.gl/pbQdkocYvA5tQ6xM6

So this absolutely cannot be used on helicopters at all. Since we are a minority among the vehicle types we'll have to do an independent fix that never allows use of that so-called "safety switch" on heli's. This gets harder to do as the push is to have one build for all Copter aircraft and get rid of the if HELI_FRAME statements in the code. But this one thing that definitely needs to be totally locked out for heli frames.

As it is, I have no clue how to identify where it is failing randomly when it initializes. Only that it doesn't go SkyNet after removing it.

[WickedShell]

It is not ActiveWhenArmed. So......why did my helicopter shut down from armed state at full power?

I assume the armed state you are referring to here is the FMU/Flight stack not the safety? What was the delay between FMU arming and the safety activating? The armed state is only communicated from the FMU to IO at 1Hz, so within the first second of arming (+ longer if there is a reliability problem) the safety can still operate after arming.

@ChristopherOlson You do realize that simply reverting the commits puts you into a situation where the safety switch can always be activated if it's pressed? The point of the commits was to prevent the button from operating while it was armed, obviously you seem to have an issue there, but what you've moved to is a setup where anything on the pin can trigger the safety for you.

On one of those tests when it went Self Aware I continued testing by trying the switch.

What do you mean self aware? That's not a useful technical description of what happened. Was this test before or after reverting the commits?

[MidwestAire]

You do realize that simply reverting the commits puts you into a situation where the safety switch can always be activated if it's pressed?

It was a way to test to see if the problem goes away. The switch can be permanently disabled in px4io.

What do you mean self aware? That's not a useful technical description of what happened.

In computer-controlled robotics the term "Self Aware" means something that has seemingly gone rogue despite attempts to disable it. What is the exact technical description of setting BRD_SAFETYENABLE = 0 and it self-enables anyway? At random.

[MidwestAire]

I'm closing this issue because it's the same as this one, which was closed in favor of the current implementation https://github.com/ArduPilot/ardupilot/issues/8016

The purpose of this issue is not to troubleshoot the logic in the new switch code. It was to find out if there is a global disable that we can use as default for heli frame that was possibly overlooked in the implementation of the new logic.

There was a patch in PX4 for ignoring the SAFETYENABLE setting. https://github.com/ArduPilot/ardupilot/issues/2217

But there is some other issues that must be addressed for heli, and this is not simple to remain compatible with multicopter frames. For now we'll do a standalone fix for heli and maybe eventually incorporate it into Copter.