EKF mg hgt timeout - reset to rng hgt

[Frankendrone]

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 1

I discussed this issue with a another community member in the discuss forum and we came to the conclusion that we should open a bug on this.
We suspect that the flightcontroller refuses the data of the sonar as it is too noisy (possibly due to vibration) and therefore resets range and altitude settings after timeout. The drone thinks that it is falling when it is actually hovering and therefore shoots up which is a rather dangerous behavior.

Thanks everybody!

[koby08]

Just commenting that my drone had a similar issue a while ago as well (v1.8.2): "EKF rng hgt timeout - reset to rng hgt" causing the drone to fly into the ceiling. My drone was using a LIDAR that had some noise since I was hovering over a direct-sunlight spot - and it caused the issue above.

Back then I saw that the EKF reset caused a drastic height change in a really small time delta - causing the drone velocity estimation to spike.

Link to the forum thread mentioned above, with some deeper analysis I did back then: https://discuss.px4.io/t/ekf-mg-hgt-timeout-reset-to-rng-hgt

[hamishwillee]

HI, there are a lot of checks that aren't documented.

Looking at the code, I think this comes from here: https://github.com/PX4/ecl/blob/master/EKF/control.cpp#L912

Looks like reset because we've detected a problem with the height estimate and we're using a rangefinder for height source that we think is valid. However clearly it is quite a large difference from what the rangefinder is actually reporting.

@priseborough can you advise on what might cause this, and if I am close above. Also, any particular reason why these warnings are not documented (other than time?). [@julianoes anyone other than Paul who might also be able to advise?]

[koby08]

Hi @hamishwillee, in the scenario I had, the rangefinder was reporting noisy values because of direct sunlight which the sensor doesn't support. Therefore, the EKF rejected its readings (with a large hgt_test_ratio). After 5s, the height estimation was reset based on the distance sensor readings, and I assume this caused a bad velocity calculation (the height estimation went down drastically in an atomic moment, and therefore the drone felt it was falling down, and tried to compensate).

I can try finding the logs from my scenario if it helps, but they look pretty similar to the one @Frankendrone has attached

[hamishwillee]

Thanks. The thing is, I know nothing much about ECL/EKF. So we need expert help to confirm this.