We are looking to fly a fixed wing craft close to the ground (~2ft high, within 1-2 inches), so one distance sensor is all we need to provide an accurate altitude data. How may we disable barometer and other estimator, so that the data from the distance sensor is used as the only source of altitude? Would this be in the ekf2 module?
Also, would PX4 correct errors in altitude smaller than an inch, in altitude mode?
Hi,
Take a look at the parameter EKF2_HGT_MODE:
Determines the primary source of height data used by the EKF
Comment: The range sensor option should only be used when for operation over a flat surface as the local NED origin will move up and down with ground level.
Values:
Reboot required: true
Taken from https://dev.px4.io/v1.9.0/en/advanced/parameter_reference.html
This should help you I think 
Thank you for your reply. This is the first thing I tried, but although the distance sensor is getting a reading, the altitude did not change with it. The Pixhawk board was stationary though, so is it a sensor fusion problem?
Also, would there be an issue flying over wavy water?
Can you share abit more information on your setup? What is your rangefinder and how it’s install? What is the wingspan of your aircraft? What is your cruise speed? What type of terrain you are flying over?
For the fusion of the range finder make sure all the EKF2_RNG_* params are correctly set
for your setup and your use case.
For the fusion of the baro data their is two param directly related to the ground effect:
EKF2_GND_MAX_HGT
EKF2_GND_EFF_DZ
after that you can tune these param to modify how much or how little the EKF use the baro data:
EKF2_BARO_NOISE
EKF2_BARO_GATE
What each parameter influence the importance the barometer in the EKF ?
My question is : if we increase the gate/noise of a sensor (gps, barometer, range finder), the EKF use more or little the sensor data ?
Hey, chiming in a bit late here — so I might be missing some context from the original setup, but I’ve been looking at a very similar question recently 
In PX4/EKF2, “distance sensor as the only altitude source” is unfortunately one of those phrases that can mean different things depending on whether you’re talking about:
Estimator height reference (what EKF2 anchors z to), vs
Terrain/HAGL aiding (range being fused conditionally and often treated as “height above ground”), vs
What the controller actually tracks in a given mode (local z vs dist_bottom / terrain estimate).
So even if you “enable range”, you can still see behavior that doesn’t feel like “range-only altitude”, because:
Range fusion is gated (speed/height/quality checks).
Typical knobs are EKF2_RNG_CTRL and the gates like EKF2_RNG_A_VMAX / EKF2_RNG_A_HMAX. If you move faster / fly higher, it can quietly stop fusing.
EKF2_HGT_REF is a preference, not always an exclusivity guarantee.
Depending on the configuration and what else is available, other height sources may still influence the state indirectly (this is the part I’m least certain about without logs).
Alt-hold semantics depend on the flight mode + controller config.
If the controller is tracking local position z while you expect “height above ground”, then the system can be “using range” in the estimator but still not behaving like range-only altitude hold.
If your goal is specifically: “altitude hold should follow the distance sensor (HAGL) as the dominant truth”, I think the most useful debug is a short log checking:
whether range height aiding is actually fused (innovation/test ratio + fused flag), and
which signal the controller is consuming in that mode (vehicle_local_position.z vs distance_sensor / dist_bottom / terrain estimate).
I’ve been trying to untangle this exact semantic/priority mismatch recently (range as height ref vs range as terrain aiding vs controller tracking), but I’m definitely not claiming I’ve got it all right yet. I collected what I found + the relevant code-path notes in this GitHub issue:
https://github.com/PX4/PX4-Autopilot/issues/26226
If anyone still has a reproducible setup / recent logs, I’d be happy to compare notes there (and then we can summarize back into this thread once we’re confident about the intended behavior).
Hi dreamingandsunny, I am encontering a similar issue: at low altitudes (<10m and lower speeds) only the down facing distance sensor should be used for alitude estimate. I see that distance_sensor/current_distance and vehicle_local_position/dist_bottom coincide, but that the local z position is quite wrong (it gives me negative values for a simmple hover flight). I am attaching an image that shown this and the link to flight review where you can see the local z pos
~Nick
