[Bug] Unstable height estimates

[mkesselaers]

Describe the bug

We are using an ARK Pi6xFlow without GPS and are trying to reliable takeoff to 2 meters.
We use both EKF2_BARO_CTRL as EKF2_RNG_CTRL and the HGT_REF is set to barometric.
When taking off, sometimes it goes to 2m, but most of the time to somewhere between 3 and 5.

Using 1.16.0 alpha, the height was around 1m

To Reproduce

1. Drone switched on
2. Armed
3. Takeoff to 2m command issued
4. Measure physical distance as soon as the height seem stable)

Expected behavior

Go to the correct height (more or less since exact would be impossible off course)

Screenshot / Media

No response

Flight Log

barometric hgt ref (result 3.2m): https://review.px4.io/plot_app?log=514ae575-9d2e-4687-ab55-6e8836979b02
Range hgt ref (result 2m) https://review.px4.io/plot_app?log=b3753550-44ac-439a-905b-933f7a3932c3
Using 1.16.0 alpha : https://review.px4.io/plot_app?log=8122ff4b-e309-41f5-9257-55d74abbdb5d

Software Version

release 1.15.0 stable

One test with 1.16.0 alpha

Flight controller

ARK Pi6xFlow board (Dexi Airframe from DroneBlocks)

Vehicle type

Multicopter

How are the different components wired up (including port information)

ARK board to ESC to Motors.
Pi CM4 on ark-board, using MicroUXCREAgent to transform UORB to ROS2 topics.

RC and a LED ring are connected to the ARK board as well

Additional context

After takeoff, the height should remain stable, regardless of what the terrain is doing.
That's why we want to use barometric height reference, since a distance sensor will cause problems.
We're also adding VIO using markers, but don't believe that this would be more reliable then a barometer

[bresch]

Checking https://review.px4.io/plot_app?log=8122ff4b-e309-41f5-9257-55d74abbdb5d it seems that the estimator is confused because of the inconsistency between baro and range data: see in the plot below that for the baro, altitude above ground after takeoff is 7m (takeoff at 4 and ends at 11m), and for the range finder, motion occurs later and only to 1.5m; then goes down again.

[mkesselaers]

Hi @bresch ,
We've noticed that too and found the barometer measures strange since it diverts so much from the actual physical height.
We've tested with a second airframe with exactly the same firmware and parameters and it showed the same readings.
Would that assume that something is wrong with the barometer?

During those tests, we were only focusing on the height, which is the reason why there is barely no horizontal movement.

Best regards, Maarten

[bresch]

The baro is most likely getting airflow from the propellers. If the autopilot is enclosed, it could be that the air pressure inside the body drops as soon as the propellers are starting

[mkesselaers]

Good morning,
We've done some tests, but don't really see this behaviour.
The airframe used is a DEXI and the ARK Board is not enclosed.
When arming or giving a bit of throttle, no changes in the pressure are detected, as far as we see.

Is there a good way to test this, besides trying a lot and noting everything down?

[dakejahl]

@bresch thanks for taking a look. This problem has been around for a while although we've tried to fix it a couple of times, it's easily reproducible when flying indoors with an ARK Flow. I'm not very familiar with the estimator/controllers, so I'm hoping I can lean on your expertise. The fundamental issue I believe is the pressurization/prop wash, the idea behind "range aiding" is to alleviate issues with the baro as long as range aiding conditions are met.

The param EKF2_RNG_CTRL states

Conditional mode: This enables the range finder to be used during low speed (< EKF2_RNG_A_VMAX) and low altitude (< EKF2_RNG_A_HMAX) operation, eg takeoff and landing, where baro interference from rotor wash is excessive and can corrupt EKF state estimates. It is intended to be used where a vertical takeoff and landing is performed, and horizontal flight does not occur until above EKF2_RNG_A_HMAX.

In the shared logs these conditions are met, but range fusion isn't occuring and the rng_hgt_bias is climbing while fusion is disabled. Oddly the cs_rng_hgt flag is always true, the rng_hgt_bias stops climbing once baro fusion is disabled, but at this point we're already overshot the takeoff altitude

[dakejahl]

I'm trying to test here at home and discovered that the home reference altitude is unset when there's no GPS. Probably related, I think there is more than 1 issue going on. We should probably get optical flow into gz sim so we can start testing it more regularly.
#24078

[mkesselaers]

Hi everyone,
We tried to shield the barometer to exclude prop wash as a potential culprit.
This actually still gave us the same results, so I think that we can exclude as the reason

[bresch]

@mkesselaers could you also share those logs please?

[mkesselaers]

@bresch Off course.
All of below logs are manual flights where we wanted to make verify that it the local position Z-position is not being affected by something software-related from our side. (We normally use ROS2 to Offboard the quadcopter)
We also switched the logging to start on boot and end on shutdown to have a better overview before and after arming.

Test with RNG_CTRL off : https://review.px4.io/plot_app?log=59b01c16-8ac9-44cf-b45d-d86b2ad3b4d2
Test with all sensors on : https://review.px4.io/plot_app?log=7da33e5d-a942-45ac-a386-f6b14f1cf83c

[TompsonTan]

I met a similar issue，in this log, from 134.5s to 164.5s, Distance sensor and baro alt change is about 2m, but local position z change is less than 0.5m. Very strange.
https://logs.px4.io/plot_app?log=99692990-4d4e-4158-a32f-1acf42bdf432