[Bug] Altitude estimation issues

[dakejahl]

Describe the bug

Airframe is the Dexi (ark_pi6x_default)

• No GPS
• Flow + Distance sensor for postion/altitude hold

Below is a quick hover test in Manual mode inside my house.
https://review.px4.io/plot_app?log=2d4d8f06-edca-4e79-a5b9-5c729d971e15

The plot on the left is from EKF replay with EKF2_HGT_REF set to Range

As you can see when EKF2_HGT_REF is set to range the estimate tracks the distance sensor once it starts to hover, although there is still a large bias in the estimated height (I've applied an offset to show that they align)

The problem
The issue I want to focus on however is the standard case where EKF2_HGT_REF = 1 (GPS). Since we are not moving horizontally and the distance sensor data is continuous, we should meet the requirements for "range aid". This should allow the autopilot to control the Z position around the distance sensor data directly.

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-april-02-2025/44681/2

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-april-02-2025/44681/1

[bresch]

So, the baro is set as the height reference (EKF2_HGT_REF) but provides complete garbage data:

The height above ground (dist_bottom) is however correct and following the distance sensor.

This should allow the autopilot to control the Z position around the distance sensor data directly.

Yes, that's what the controller should do when in MPC_ALT_MODE = terrain following or terrain hold (when in position or altitude control modes).

[bresch]

I think it's also a matter of tuning. With the parameters you have, the estimator knows that:

• the baro is the altitude reference (no bias is estimated) (EKF2_HGT_REF)
• the baro measures absolute altitude and is not so accurate (EKF2_BARO_NOISE = 3.5m)
• the range finder measures the distance to the ground and is accurate (EKF2_RNG_NOISE = 0.1m)
• the terrain height can change rapidly while hovering in place (EKF2_TERR_NOISE = 5m/s)

With this information, the absolute altitude slowly tracks the baro and the corrections of the range finder are pushed into the terrain altitude estimate.

[dakejahl]

@bresch Tuning? Which parameters would you adjust?

Regarding the Z estimate:

• I would expect the range finder to be the altitude reference as long as all of the conditions are being met, otherwise
• if I had issued a takeoff to 5m in position mode the drone would have barely gotten off the ground since the estimate is so erroneously high.

[dakejahl]

Here's another quick hover test indoors with the dexi in position mode
https://review.px4.io/plot_app?log=016ceb47-525f-4c08-bf61-372ea94633fc

It sort of works, but the altitude still wanders up and down.

[AlexKlimaj]

Dexi flow, rangefinder, no GPS. Log from boot with EKF replay.

https://youtu.be/aSsXQyXvX-0

https://review.px4.io/plot_app?log=61bba67d-f015-4151-bb20-9d7d248a98e9

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-april-09-2025/44902/1

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-april-16-2025/45072/1