Potentially very dangerous throttle bug

Hi,

I would like to share with community bug that has caused crash of my quad X. I hope someone might help or explain what happened. Unfortunately I don’t have sd card to provide some logs :frowning:

Frame: Quad X – Mark4 5 inch;

FC: Mateksys F405-STD STM32F405 F405, BMP280;

ESC: XRotor Micro 60A 4w1 BLHeli-32 6S v. 32.7;

Engines: Emax RS2306 2750 kV with 5050 propellers;

Arducopter v. 4.0.7

What happened:

I have calibrated my quad for 3s 2200 mah battery and it was stable in stabilize and altitude hold modes. I set failover to RTL. At this stage quad was flying fine.

My 3s battery was old, so I have bought new one – 4s 1550 mah.

Now what I have done (I will describe accurately, I don’t know what is important and what is not):

I have connected USB to FC (battery was disconnected) and clicked “calibrate level (NOT accel!)” – MP hanged so I disconnected usb. I tried this again and it hanged again. I thought it might require battery, so I have plugged battery and USB, I pressed “Calibrate level” (NOT accel!) and this time it was success. I have verified that artificial horizon is level better.

Know I took quad to backyard and connected battery. I have armed it and pushed throttle in stabilize mode to move quad slightly up. As I pushed throttle stick 1 mm up my quad fired up at full speed. After 2 seconds It was at my roof level (about 7 meters high). So I moved throttle stick full down, so my quad turned engines to idle and started falling like a rock. Then I pushed throttle again as little as possible UP, and quad again jumped even higher at maximum throttle.

At this point my control allowed either 100% throttle with throttle stick slightly above minimum and throttle 0% and engines in idle (like after arming) when throttle stick completely down at minimum. Obviously when engines there idling quad was loosing height but it was uncontrollable, so wind has drifted it far far away. I was trying to turn on throttle a little and directing it in my direction, but quad was not reacting much for control and then I was putting engines to idle to lower the flight.

I even switched it to RTL mode hoping it will stabilize altitude, but as I did it quad jumped up and the turn engines to idle again, so RTL was also unable to control engine speed fluently.

To summarize I was able to give 100% throttle or 0%, nothing between that, so I was unable to get back safely. Finally thanks to God’s blessing I managed to crash quad in the grass, but It was very close to hurting someone or damaging parked cars. I almost had an heart attack.

Actually I was planning to do some hovers at 2 meters in my backyard just to test new battery flight time.

What is most strange I have recovered quad. I have noticed arducopter didn’t knew it has crashed, so it was spinning engines lying back, so 2 engines burned out. Later I cleaned it and turned on without propellers to check which engines are working and if I can repeat throttle control loss, but this time it was reacting to my throttle stick properly. I didn’t change ANY settings while doing this test after crash. This is weird and creepy and now I am scared to fly arducopter again, as I was unable to determine what has happened. Is it ESC or arducopter flaw? I could have ended in the jail (injuring someone) or hospital (getting heart attack) for me :frowning: Please help, what could have happened and more important howto avoid it in the future?

I have emergency engine stop programmed and working, but everything happened so fast and my mind was working to slow that day to cut off engines on time.

Please share the dataflash logs of the incident.

Doubt it’s a bug (what version?) but without a log there is not much to go on. You just didn’t have a Sd card inserted?

v. 4.0.7. Yes, I just bought it and will insert now, but i didn’t have card inserted during a crash. I can provide parameter settings, as i can read this from the FC. Will this help?
I don’t know if it is a software bug, but this is very dangerous unpredictable behavior. I think that voltage change shouldn’t cause complete control loss on the throttle.

Probably not but attach it anyway perhaps something will turn up.

Some parameters such us mot_bat_volt_max/min and mot_thst_hov should be updated. Maybe we can see something in your parameters list.

2021-04-23-parametersAfterThrottleFailCrash.param (19.9 KB)

In this parameter file the only thing that I have changed i did accel calibration after the crash.

Actually I am thinking that changing voltage to higher value would cause mot_thst_hov to be to high, but this parameter has nothing to do in stabilize mode as I understand? Am I right?
Is it possible that this parameter value was updated during a crash flight automatically? Maybe it was even higher that it is now and when I changed battery from 3s to 4s, according to datasheet of the engines, my thrust changed from 4 kg to 6,2 kg. Together with old throttle setting that was calibrated for 3s (am I correct that mot_thst_hov is calibrated automatically when in hold altitude mode?) maybe it gave super high power at minimum throttle stick.

Was your rc calibrated?

Yes, Radio was calibrated and quad also. I was using 3s battery while calibrating.

I think this sounds like a parameter error where e.g. the minimum motor speed was very high.

THR_MIN or MOT_SPIN_MIN parameter (depending upon the version)

I would always recommend to make a run without props after significant changes.

I very much doubt you have found some new bug. Ensure logging works and do a new flight , then share the .bin log file.
EDIT: same as what Dave said and he said it first.

1 Like

Well one think I know: this was not suppose to behave like that at any moment. MOT_SPIN_MIN,0.15 was set so it is not it. I think that I can reproduce this situation by setting MOT_THST_HOVER,0.5 or more in quad that has a lot of power, where hover throttle is at about 25%.

I have two questions then:

  1. What is the influence of parameter MOT_THST_HOVER on stabilize flight mode? Is it taken into account in any way?
  2. If i set MOT_SPIN_MAX to 0.5 will this limit or scale my motors output to half power? What other consequences may I expect?

I would appreciate if someone could explain or give link to detailed documentation that says how those two parameters are affecting flight in stabilize mode.

To be honest long weekend in May is coming, so I flashed betaflight on my quad. It has motor output limit, but is lacking altitude stabilization. I don’t trust arducopter anymore for now, it is too powerful for experimenting.

I will be configuring arducopter heli on my trex500 with flybar and futaba 401 gyro and ardupilot on glider.

You should do your calibrations and setup with the type of battery you’re going to fly. If you set any of the MOT variables based on 3S then flew a 4S something is going to go wrong. Did you try the Alt-A Initial Parameter Calculator? Did you perform the initial tuning steps as per the wiki? (Not just the calibrations)

If you would like us to help with the setup, please post a .BIN log file from your flight (I read you didn’t have an SD card, but for next time…) or at least a parameter file and very likely someone will be able to identify the problem and get you flying.

Many of us here fly both Betaflight and Arducopter. Two different animals. Personally, I feel the extra features and capabilities of Arducopter mean the initial setup is a little more involved than Betaflight but the end product is worth it.

Mostly I agree with you. But.!!! Huge “but”!
This situation with an unexpected “jump” is happening quite “often”. Almost every one of my friends who used AP was experiencing this issue in a past at least a few times.

And yes, I agree, this is a misconfiguration. But I believe this is a question of safety. Tens and hundreds of thousands of users day by day are launching this software. And there should be a way how to prevent this really unsafe behavior. Probably default parameters should be turtled up to absurd limits. Or there should be a mechanism that would prevent a drone from possible madness and it should be enabled by default.

for instance, if the hovering throttle is set to a high value (let’s say >0.3, even if it is still no so high) it should be achieved not momentarily but rather in a logarithmic way. And this kind of safety features shall be applicable for the basic manual modes, like stab, althold and poshold…

So where do developers draw the line? The user of this type of firmware needs to accept personal responsibility to read the information and learn about the setup before they stand 1m away from a four table saws blades and let it go. If the developers make it so safe that it’s totally fool proof, the cost will be loss of user functionality. Or there is aways somebody who will still turn off the safety. How many times do we read “Turn ARMING_CHECKS back on”? It’s not going to be a smooth road with an open source project. It is about development. If you want a safe, and fool proof system go buy an off-the shelf solution.

If you want good position hold and altitude control then there is a lot more set up, and it matters a lot how overpowered or underpowered your aircraft is. Once the aircraft is flyable, tuning can significantly improve the attitude control.
MOT_THST_HOVER looks after itself and is an “indicator” and starting point for next time hovering is required. If it’s too close to MOT_SPIN_MIN that indicates there’s a problem that needs fixing.
Vibrations are a BIG problem with holding position and hovering, and it’s a subject that gets a lot of discussion here.

Basically you want to do these steps:

  • Initial calibrations and params
  • check and fix any vibrations issues
  • harmonic notch filter
  • autotune

…and .bin log files are your friend.

EDIT: and just adding that choosing the correct combination of motors/props/ESCs (and even frame) is really important too. Very big multirotors through to racing-quad size can all fly extremely well following exactly the same process.

1 Like

And again, I fully agree with you. However it is matter of fact, that drone are trendy nowadays and mentioned before issues are happening more often. It means that unsafe software (yes yes even fool proof) is a big risk, because of the low level of relevant knowledge on a user side. So I think it would be nice to put more attention to the safety aspect especially for novice :slight_smile:

P.S.
Sometime in 1980-x many ppl were saying “just drive safe, take responsibility on your own”, but nowadays it is hard to imagine a car with no brake assistance and the other safety aspects…

Yup, thank for that comment :slight_smile: Autotune bit scaring me :smiley: But have to try it…

Don’t try Autotune until logs are checked for vibrations and basic attitude control. If the quad is not behaving well Autotune can make it crash, since it tries extreme values to find out what is possible and what works best. Autotune will work great when the basics are in place and working as expected.

Ardupilot is not something you “get out of the box and it just works” - there’s over a thousand parameters and it can be made to run almost ANYTHING (not just a small quad).
Companies that produce objects that “just fly out of the box” have spent untold man-hours and research dollars getting them to work that way, and they also can’t be repurposed or adjusted.

I think we’re arguing different sides of the same coin. And that you’re bringing up 1980’s cars suggests we may have similar levels grey hair to reference back to. I don’t wish to hijack this tread any more so I’ll say my bit and get out.

What has me wound up about this thread is that the OP is claiming this is a “bug” when it is most likely, as you’ve pointed out, a “misconfiguration”. The instructions are in the wiki. There is an abundance of support in this forum. The hard work by many users (some who’ve already posted in this tread) has helped many willing novices to safely fly their quads and planes. There just needs to be the effort.

Let’s agree we see this slightly differently. So let’s meet at the field, shake hands (or what ever is appropriate now) and go fly some drones. Sound good?

Edit: @xfacta, I was going to make a comment about DJI Naza, but I think you essentially covered it.