HELP: Runaway Throttle Failsafe Crash (SOLVED)

ArduCopter Copter 3.4
1

Hi All,

I recently encountered a problem that has me a little puzzled and I am hoping someone can help me figure out the cause. a few days ago I was adding the finishing touches on my new build and wanted to ensure that battery failsafe was configured correctly. I am using a 3rd party current sensor so I began the process of making sure it was tuned properly. I set the voltage and the current according to my watt meter and everything was running smooth. I decided to test and make sure the FAILSAFE_BATT worked as expected. I was doing the endurance test inside a warehouse as the weather was bad outside. My copter did not have a GPS installed and I was hovering in AltHold the entire time. The failsafe was configured to LND when it either hit 22.0v or 500mAh reserve, the battery is a 6s 8A. Upon hitting FAILSAFE_BATT-1 the copter appeared to start descending about a foot before going full throttle and slamming into the ceiling 15ft up then smashing into the concrete floor, I was hovering about 5ft when the failsafe activated. The battery did not sustain any damage from the impact, I charged it back up and 7200mAh was put back. I was watching the HUD on MissionPlanner and the voltage was about 22.3v when failsafe activated. I cant seem the figure out why it would shoot up. Maybe there is a setting flipped that I have overlooked, but AltHold works really well so I assume PixHawk knows how to climb and decent? I’m hoping someone can take a look at the Log from the flight and help me figure out how to prevent this from happening again.

Addition information:
PixHawk is flipped 180 and AHRS has been adjusted.
The TX used has a spring to center throttle. (works well for AltHold)
Firmware: Copter 3.4.6 X8 configuration

You can see right after failsafe was triggered the vehicle began to climb, then the user pulled down on the throttle (RC3) to stop it from continuing the climb (without success). When you see the mode switch back to ALT that was because we cycled the mode switch to try and get the quad under control again. Not sure if we were able to establish any control because at this point it had already made contact with the ceiling. The full throttle you see on the input (RC3) was because the quad started to fall from the impact with the ceiling (natural reaction).

The thing that really has me confused is why ThI (Throttle In) goes crazy when failsafe gets activated which in tern causes the ThO (Throttle Out) to go max 100% you can see this on the other graphics attached, the ThI was smooth the entire flight until FailSafe activated why would RC3 (throttle) input read smooth and accurate but ThI (Throttle In) go sporadic? In the documentation for reading the log files it states “The pilot’s throttle in as a number from 0 to 1000” but it clearly went to 12 on the graph, does that mean it was seeing a value of 12000?
Is there potentially a value switched that would cause it to accelerate up instead of establishing a decent? when you graph CTUN.Alt and BARO.Alt, both match the entire flight until FailSafe activates, then the CTUN.Alt goes opposite of the BARO.Alt. Is that normal?

I should hopefully have things repaired pretty soon and would like to get this figured out, both for me and maybe someone else that might have experienced the same thing.

Potential troubleshooting steps:

  • Set a mode to: LND and make sure it works properly, allowing me to switch back if it doesn’t.

  • Roll back to a previous firmware and see if there is any change.

I am not sure how repeatable the problem is and do not plan on sending it back into the ceiling again. Ill need to figure out a way to anchor the quad and make sure the FailSafe behaves as planned.

I started a post over on DIYDrones with no luck and hopefully someone here has encountered this problem and can help.

FAILSAFE Graphic.jpg3844×4926 796 KB

ThI-1.JPG3760×1425 133 KB

DCRt-1.JPG3761×1013 111 KB

Flight Log: https://drive.google.com/file/d/0B15aUn3vB-goQXZIR1VnZklBNnc/view

2

I think I see what happened here. Does the buzzer play a tone when it goes into batt failsafe?

This plot shows the main IMU being fooled into thinking it’s falling. That’s why the throttle saturates high.

Capture.JPG1966×446 68.2 KB

I’m thinking your buzzer is hard mounted to the flight controller. You can change the mount, or disable the sound.

3

Jeffrey,

Thank you for the reply!
I am not sure how you figured this out but you may be correct… The buzzer is indeed mounted beneath the PixHawk on the under side of the fiberglass plate. The PixHawk has foam tape securing it to the plate and so does the buzzer. When failsafe of any kind is activated the buzzer continuously goes off. I guess that would explain the rapid climb if it does affect the PixHawk in that way. It makes sense that this could be the cause and it would have taken me a while to figure this out if at all. Is it stated anywhere in the wiki documentation that the buzzer may cause issues in flight if hard mounted near the PixHawk?

I will bench test with the buzzer in the same location and moved to see if this is the problem and report back.

4

We do have a warning in the wiki: http://ardupilot.org/copter/docs/common-pixhawk-wiring-and-quick-start.html?highlight=buzzer#connect-buzzer-and-safety-switch

Do you think that’s not explicit enough?

5

Thanks for the help in figuring this out!

I recorded the bench test and that was the answer. You can see az on the HUD and when failsafe activates, the beeper goes off. Watch the az number and how it will go from a stable 1000 all the way down to ~15.

I see now that this is mentioned in the wiki, thank you for pointing this out. I have been using Arducopter for many years and guess I haven’t looked at the “basic” setup page in a while (this was very much overlooked by myself). I don’t think it is clear enough the impact it could have on your system, I am not sure if it would have necessarily changed my setup had I read it, because of how bazar the scenario actually is (the buzzer can cause your copter to crash? really? nah…) but it will if you are not carful… Now that I know the behavior and what to look for. I am certain that I have seen side effects of this before, but because I rarely hit FailSafe (a constant beeping state) it hasn’t caused much more then a twitch.

Also when you say noise are you referring to EMI “noise” or vibrations form the high frequency audible “noise”.

The warning on the wiki.

Warning: “Mount the beeper is at least 5cm away from the flight controller or the noise may upset the accelerometers.”

Maybe change it to: “Beeper has been known to cause erratic flight behavior that can lead to a crash if mounted within 5cm of the flight controller. Insure adequate spacing when mounting beeper to eliminate issues form noise that will upset the accelerometers.”