[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

[bresch]

@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

If this flight, the following happened:

1. while on ground an just after arming, the distance sensor quality is 0 so the distance sensor aiding cannot directly start
2. the baro altitude increases by 6 meters on takeoff, which makes the drone think it's climbing; as a result, it stays close to the ground
3. since the quality was 0 for a long period of time, the "stuck" check is active and a distance variation of 10cm is required to pass the check
4. the dist_bottom then resets to the range finder and gets valid
5. the flow fusion can start because dist_bottom is valid and resets the velocity. The problem is that it uses the "filtered flow velocity" that is still partially wrong due to the incorrect dist_bottom before its reset, so the velocity state is screwed up and the vehicle moves away.
   

So, the main height problem is due to the baro altitude on takeoff. Then the race condition due to the reset to "filtered flow velocity" should be addressed.