AP_NavEKF3: Check if rangefinder is in range (if in use by EK3_SRCx_POSZ)

[rishabsingh3003]

It is currently possible to takeoff in Alt-Hold, have EK3_SRCx_POSZ set to "RANGEFINDER", and have the rangefinder out of range (can be verified in SITL).
This can cause the EK3 height estimates to grow unconstrained till the rangefinder is back in range.
I recently saw a log where this caused the copter to almost crash.

This PR adds a pre-arm check for this issue.

[tridge]

can't we just check rngValidMeaTime_ms ?

[tridge]

should be in the new pre_arm check in the backends, so we check all lanes, check it is fusing

[rmackay9]

@rishabsingh3003,

I'm pretty sure that I have a bug from a user here in Japan that shows this same issue. The user was on Copter-4.5.7 so it's an existing issue.

[tridge]

@rishabsingh3003 do you have time to test the change I suggested?

[rishabsingh3003]

@tridge I did get to try your suggestions, however it did not work as expected.
The problem is that there is code that "fakes" a rangefinder and forces RNGFNDx_GNDCLR reading when on "ground" even if the rangefinder is unhealthy.
So to the core it looks like there is healthy rangefinder being fused in which will go away as soon as the vehicle arms (at least for Copter).

This is the relevant line I am talking about:
https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_NavEKF3/AP_NavEKF3_Measurements.cpp#L96

[rishabsingh3003]

Hi @rmackay9, I’m a bit confused about the issue.
From what I can tell, the rangefinder height fusion logic seems to be built around the idea of the rangefinder going out of range, at which point the system gracefully falls back to using the barometer. So, in theory, the height estimate shouldn’t grow unbounded as I initially thought.
However, the user I was helping is working with a very small Copter, where the barometer is physically very close to the propellers and basically unusable due to the noise. They’re relying entirely on the rangefinder for height estimation and expect it to be fused exclusively—even if the barometer is available.
Using Lua scripting and the ability to set EKF sources dynamically, I still think having a pre-arm check or mechanism to ensure only the rangefinder is used is a good idea. If someone does want to fall back on the barometer, they can always write a small Lua script to handle that. I think it’s safe to assume that someone choosing to use a rangefinder for height likely doesn’t want to rely on the baro at all.

[rishabsingh3003]

https://www.dropbox.com/scl/fi/a0xzssbfpvklh41saz7s4/00000066.BIN?rlkey=5ltbxc7qcn7kp6rf6qfaxr77o&e=1&st=zw4egz9t&dl=0

[rmackay9]

Hi @rishabsingh3003,

I spent some time looking into this today and I may have a fix for the underlying issue #30490. I wonder though, have you ever been able to re-create the issue in SITL?