EKF mg hgt timeout - reset to rng hgt

Hi everybody,

I am trying to fly indoors with a rather big and powerful drone.
Set-up:

Pixhawk 4
PX4 - master build
Lumenier 4in1 ESC with PWM control
PX4 flow with sonar

I was flying in Altitude mode over a flat surface and even though the high vibrations caused some shaking the flight over all was stable.
Out of a sudden the drone shot up to the ceiling and I had to use the kill switch.

Prior the crash the warning
“EKF mg hgt timeout - reset to rng hgt” has been given out and I can not find any documentation regarding this?

Here you will find the flight log. I would be very thankful if you guys can help me out!
https://review.px4.io/plot_app?log=659ed558-3d2a-43d6-afcb-6290400b296a

Thanks!

Hi,

Several weeks ago I had the exact same issue.

My analysis back then (it might be inaccurate as I’m not a PX4 dev): The EKF started rejecting the distance sensor reading as it did not match its prediction (there are some variables that control the amount of noise EKF agrees to accept). After 5 seconds timeout, the EKF gives up its older state prediction and resets its prediction to the current values read from the distance sensor.

As a result, the velocity calculation has a large spike (because in a very short time the drone thinks the height has changed drastically) and therefore tries to compensate.

I’m pretty sure about the first part of the analysis, the second part is an assumption.

What I ended up doing is increasing EKF2_RNG_NOISE because I’ve noticed my range sensor was much noisier than the default value. Since then I didn’t have the problem - but it affects the hgt estimation of the drone. This means EKF rng timeout will not occur.

I still think the second part of the problem (i.e. the drone velocity estimation after EKF timeout, assuming it does occur) is a big issue. Would love to hear if some dev can give more info.

Hi Koby,

thanks for your input! I think that you are on the right track with your analysis but I am still wondering about some of the graphs.

  1. It seems like that there has been only two periods where the drone had an actual Z position setpoint. I guess this could be explained by your theory of rejected distance sensor readings.

  2. The setpoint of the Z velocity though is almost constant at around 0.8 m/s but the Z estimated velocity shoots up.

In general I would like to know what this warning message “EKF mg hgt timeout - reset to rng hgt” means as I can not find any further information in the documentation.

Regarding #1 I’m not sure, but regarding #2 thats basically the point - the drone setpoint is 0.8m/s but it “feels” like its failling down quickly (high Z velocity estimation) - therefore it tries to compensate and shoots up. That’s at least my theory.

Have you opened a bug on this issue? I think we should.

Hi Koby,

I agree with you.
I have not opened a bug yet but I would say that the drone behavior is not a safe one so we should open one. Unfortunately I haven’t done this before but I guess github is the way?

Best,