Motor 1 uncontrollably goes to 100% Throttle when disarmed (32.9)

[JWebb-FPV]

This is an urgent safety issue. My hand is seriously injured because of this.

So, the issue. On Sunday, the 6th of November 2022, I was flying my 5” quad with a few friends. This is a freestyle setup with a Foxeer Reaper 65A (128KHz) and a Kiss ULTRA flight controller. The setup is less than 3 months old and has less than 10 flight hours. On this day, I had already flown 15 batteries with this setup, with no issues leading up to the incident. On this last battery, I took off, and flew as normal. As I came in to land, I set my controller on the battery case next to me, and went to pick up my quad, just as I had already done 15 times that day.

As I picked the quad up, and went to unplug the battery, Motor 1 started spinning at full throttle, with my right hand directly in the path of the prop. It was spinning for less than a quarter of a second, but at full throttle on 1975kv 6S (roughly 43,000rpm with the battery discharged), it caused significant damage to my 4th and 5th fingers on my right hand, with the knuckle on my 5th finger requiring surgery.

The first person I spoke to was Alexander Federov, the man responsible for the development of Kiss Ultra. After explaining the situation, and roughly an hour of backwards troubleshooting, we both determined that the cause of the accident had nothing to do with the flight controller. Not only does my radio have a safety switch for arming, but Kiss Ultra also has a feature called ‘soft arm’, where the gyro is inactive at idle, and only activates when input is applied. On top of this, there are 8 individual arm inhibitors that would prevent the drone from going to 100% throttle, even if the arm was somehow triggered. He showed me the code to verify this. My next thought was “turtle mode”, where it’ll intentionally spin motors in the opposite direction to flip the quad over in the event of a crash. Once again, it’s not the case, as it has the same amount of arm inhibitors as the regular arm command, and it will always spin two motors, not one.

The reason why I’ve come to talk here is because of 32.9. Yesterday, I realised that this isn’t the first time this has happened. This year, almost four months ago, one of our contracted pilots at HeliGuy was setting up his X8 Shendrones Thicc, a 6S cinelifter with two T-Motor F55A Pro II ESCs connected to a Lumenier Lux F7 flight controller. When he powered on his setup, Motor 1 spun up, rotating in the wrong direction, to 100% throttle… with 7” props on. Thankfully, the drone shot out of his hand, and he wasn’t injured, and we decided to take the setup out of service. At the time, I blamed the components, as they were almost two years old, and under immense load from carrying cinema payloads of over 1.5kg.

But now it’s happened to me, with significantly worse consequences than the last instance. Two different setups, two different ESCs, two different flight controllers running completely different firmware… having the exact same failure. The common denominator? BLHeli 32.9. In the 7 years that I’ve been operating FPV drones, using SimonK, BLHeli, BLHeli_S, and now, BLHeli32, I’ve never had this issue before, nor have I seen any reportable instances of it happening. Now, with BLHeli 32.9, there’s been two identical instances within the span of four months.

Attached to this email is a video; there was no visual coverage of the incident, but you can audibly hear a single motor spin up to full throttle briefly, with the cracking sound being my knuckles breaking. (Note, the 3 beeps before the accident are from my friend’s quad that the GoPro is attached to. The three beeps on Ultra mean that the gyro is initialised).

I hope a solution is found.

trimmedGH017276.mov

[sskaug]

Testcode with additional protection against unintentional spoolups is now posted here: https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM/Dshot%20extended%20telemetry%20testcode

[awesomelionel]

@sskaug when would this fix be released? I just had the same issue above but luckily without any injury. This is a serious safety issue

[sskaug]

Really glad you did not experience any injury. What FC are you using?
As you are probably aware, a fix is available as testcode. The amount of usage of this testcode is however still very low.

[defiantfpv]

I too recently had this happen although I was not on 32.9 mine happened on 32.7

[defiantfpv]

My hand also got messed up requiring stitches, with the same exact story as to how many happened as jwebb story, flashed 4.4 flew a pack all was fine unplugged strapped fresh pack on after final esc tone 1 motor spulled up to 100% right into my hand

[jcink]

Since we can't get 32.10 anymore, for those of us on 32.9 what are the options? This is a known, acknowledged safety hazard regardless of how rare it is and now there is no way for users to protect themselves.

[awesomelionel]

I guess that since this project is dead now, it's time to move on to BLHeli_S or BlueJay as open source alternatives. I believe you can flash those onto the BLheli_32 Escs that you already have

[jcink]

I guess that since this project is dead now, it's time to move on to BLHeli_S or BlueJay as open source alternatives. I believe you can flash those onto the BLheli_32 Escs that you already have

No, you cannot or this would not be an issue right now. Blheli32 is 32 bit, BlueJay and S for are 8-bit.

[cbf123]

Reposting comment from sskaug in rcgroups.com:

When we had the initial report of injury and started implementing improvements for Rev32.10, during the course of the development it turned out that the issue was also related to an issue with Betaflight. BF had longer periods of time when the signal going to the ESCs was in an uncontrolled state. Which it is really hard for the ESC to give a guarantee of proper operation for.
We did what we could to reduce the risk of hazardous events due to invalid or erroneous input signal in 32.10, like not allowing redetection of signal after the initial powerup, shortening timeouts etc. And as far as I know, BF have also addressed their issue with undefined or erroneous signals going to the ESCs.

[Lau-r-a]

Just noting the personal liability of the owners of the company regardless of its status for cutting of body parts.