Servers by jDrones

Uncontrolled ascend! Crash out of 260m!

(Fabian Koch) #1

Hi there,

I fly a XL quadrocopter with 8kg weight, 24 inch Props and Holybro Pix32.
I already had some successful flights behind. Then yesterday the copter was ascending continuously in the air and was not stoppable. Throttle was in mid position and even when I pushed the throttle down, the ascending was reduces just abit. In land mode the copter ascending also! In 260m I had to activate the emergency switch! Barometer, gps and vibrations values seem fine. How can that be?! This was very dangerous!

Please help me to find out why this happened.
Here is the Log file: (uploaded with WeTransfer)
https://we.tl/t-XmhJ5i8psz

(rmackay9) #2

This will likely be caused by very high vibration levels. If you have a dataflash log file we can confirm this is the cause. We are planning to add a high vibration failsafe to 3.7 and Invensense has released some IMUs (including accelerometers) with larger acceleration ranges which will help with some newer boards but until then it’s best to review the vehicle’s vibration isolation and also keep your eye on the VIBE message on the MP’s HUD.

1 Like
(Fabian Koch) #3

Hi Randy,
thanks for your fast respose! Sorry, I accidentally wrote “parameter file”.
The above link leads to the log file of course. Please tell me if you need anything else.
I am aware that it may be possible that high vibrations lead to an ascending, but I have very low vibration, as you will see in the logs. Are such high vibrations captured by the log at all?
Just for info, we fly the drone with our own ground station and control the drone via mavlink only.

Thanks in advance!

(Fabian Koch) #4

If you look at CTUN in the logs, you can see that the climb rate is already in negative range before the actual flight, which is why the copter wants to compensate of course and therefore continuously ascends.
Does that mean the Pixhawk’s ACC is broken?

(Mike Boland) #5

I looked at your logs, initially at the CTUN to see what you were referring to and could see no divergence until after you hit emergency stop.

It does appear that motor 1 is not having to work as hard as the other 3.
Cant offer an explanation for this.

And the other curious thing I noted was that your IMU’s are not zeroed, that is, it would seem the flight controller is not level as the initial offsets are not zero for X/Y and 9.8 for Z.


But your offsets don’t reflect this.

No definitive answers I know, just a few anomalies I noted.

And your vibrations are good, even looking at the raw IMU they are not excessive at all and certainly no clipping in VIBES.

I do have to make the comment that flying any drone without the ability to take manual control is the dangerous part, especially large copters like this.
Please take this as constructive advice from someone who builds and flies a lot of large Copters.

1 Like
(peterbarker) #6

Many of the arming checks are disabled. That’s very not good for an 8kg vehicle.

dronekit-la points out velocity-variance, compass-variance and solution status issues. It also points out several fence breaches. The vertical fence appears to have been breached - and after moving it back a few times the vehicle RTL’d - but kept climbing.

The vehicle was obeying your channel switch. I think it may have been entirely recoverable with RC input in stabilize mode (or any other pilot-throttle mode).

This is probably a strong clue as to what’s going on:

The baro and GPS agree on the velocity. The EKF has a different idea - it’s consistently thinking the vehicle is going down.

And here’s why:

Calibration is stuffed (unless you’re on Uranus).

You only seem to have a single IMU here - which board is it?

Have you any idea how the miscalibration may have occurred?

1 Like
(Fabian Koch) #7

Thank you @mboland and @peterbarker for taking the time to look at the log file! It’s a mystery to me, how it could happen that the drone got such wrong ACC values. If the drone had taken a strong hit shortly after switching on, or one had flicked a finger at the Pixhawk, I could understand that the values are shifting, but that’s not the case. I’ve also connected the same Pixhawk (Pix32 from Holybro) again and the ACC values seem fine again, like nothing happend.

In any case, I have now improved the arming checks in my groundstation, so that this can never happen again! A reboot and better security checks would surely have prevented the crash.
Fortunately, nobody came to harm. So many thank you for your advice, I’m very grateful for that.