Distance Sensor faulty readings affecting local position estimate significantly (PX4 v1.11.3)

Crash Analysis

A crash occurred with a PX4 v1.11.3 custom version (with no changes to core flight control) multirotor was landing in a mission & had a crash due to the faulty distance sensor readings. Here’s the diagnosis:

  1. Vehicle was descending at 0.5 m/s (MPC_LAND_SPEED), and was closing in on the ground
  2. When the distance sensor data was coming in & got considered valid (vehicle_local_position/dist_bottom_valid) at around 436 seconds mark, EKF2 fused local position z value started to ‘decrease’ (indicating vertically upwards movement)
  3. As the z position setpoint generated from the “FlightTaskAutoLineSmoothVel” with jerk limited trajectory continued increasing (as it integrated velocity setpoint), current fused z position & it’s setpoint started to diverge
  4. Due to P-gain in Multicopter Position Controller, the “vz” velocity setpoint increases significantly and saturated at 1.5 m/s (MPC_Z_VEL_MAX_DN)
  5. Multirotor descends rapidly, overshooting the vz setpoint, and crashes (438.5 seconds mark, based on gps0_alt_m curve showing ground truth terrain at 144.755 meters AMSL)


There are multiple things that went wrong, but I wanted to focus on the estimator’s behavior regarding the distance sensor’s faulty readings.

As far as I can tell, estimator did provide kinematically inconsistent estimation of it’s z coordinate value as the faulty distance sensor data came in.

Estimator fuse of Height Above Ground Level

When checking the HAGL test ratio & innovation, it is clear that it saturated at 0.15 & 0.1 respectively moments before the crash. Their values were:

  • HAGL innovation variance: 0.02 - 0.03
  • HAGL innovation test ratio: Saturated at 0.023
  • HAGL test ratio: Saturated at 0.15
  • HAGL innovation: Saturated at 0.10

Also, checking the estimator_status/control_mode_flags value of “8389783” which got set after “vehicle_local_position/dist_bottom_valid” got set to true, indicating that the range finder is being fused as primary height reference.

Questions & Answers

I effectively answered my own questions, but may be incorrect in some places, open for feedback!

First, the “EKF2_HGT_MODE” was set to 1 (Primary source: GPS) (Link to v1.11 Parameters doc). Why did the distance sensor reading cause so much disturbance although it was not primary source?

To answer my own question, I think it’s this logic:

Second, is it possible to disable the range finder disturbance to the height fusion?

To do that, we need to make this condition false:

We can either:

  1. Set “EKF2_RNG_AID” to 0 (it was 1), to make sure range sensor never disturbs the estimate of height
  2. Set lower “EKF2_RNG_GATE” (e.g. to 1.0, as it was 5.0 before), or “EKF2_RNG_A_IGATE” (e.g. to 0.5, as it was 1.0 before)

Extra link to logic where range finder aid suitability is checked:

Third, given the obviously inconsistent distance sensor data (for sure kinematically, as distance was increasing when velocity was expected to be down, closing in on the ground), the kinematic gate added in the following PR (for v1.13 and onwards) seems to likely solve this issue (and will reject range finder appropriately). Is this true?

@bresch Do these diagnosis & solution make sense? I’m also curious if there’s any sane value that RNG_GATE and RNG_A_IGATE params should be set to, instead of lowering them arbitrarily.

1 Like

Feedbacks from @bresch for visibility:

it’s unfortunate but normal that the height estimate is affected by the range finder when range aid is enabled. Range aid is something we didn’t like and this is why I removed it in 1.14

Some reference documents:

My further questions

After some investigation, it seems that range aiding isn’t really removed (as it’s still ‘conditional’, and those conditions are the same, except for the influence from terrain estimator in regards to kinematic consistency check).

Thus, wouldn’t the system from v1.11 with EKF2_RNG_AID = 1, act the same with v1.14 with EKF2_RNG_CTRL = 1 (Conditional), regarding the disruption of height estimation? (Except for the cases where kinematic consistency check is failing)


Hi, not exactly. You can have the same behavior if EKF2_HGT_REF is set to “range”. Otherwise, if set to baro or GNSS, the conditional range finder fusion shouldn’t affect too much the height estimate if bad. In 1.11, when range fusion was active (through range aid), it automatically became the reference. Now it isn’t the case anymore, the reference doesn’t change.

Follow up questions

Ahhh gotcha, there’s a difference between being the reference vs just aiding on the side (since v1.14)