Altitude tracking drift in Altitude mode

Hi everybody,

I did a preliminary flight test in Altitude mode, where I have chosen a flight height acting on the throttle stick and then I merely acted on pitch and roll stick in order to move the copter forward/backwards along a line.
The test result, I mean what I have observed by eyes, was that the copter drifted upwards, so I corrected the hight setpoint by acting on the throttle stick and then I repeated the forward/backward movement and this time I drifted slightly downwards.

Here the log file analysis: https://review.px4.io/plot_app?log=6e86edb8-683b-4423-8b7c-4f70f963b023
Looking the log file, it can be seen that the EKF2 estimate is wrong wrt that I have experimentally observed. In particular, the Z local position estimate doesn’t account for the observed drift.
The copter is equipped with a pixhawk 4 (hence IMU, baro, compass) plus a rangefinder (GARMING LidarLite) pointing downward measuring the distance from the ground. Obviously, the ground is flat (I am flying in my office room).
In the log file, I can see that the rangefinder is measuring the upward and downward hight drift, but this isn’t reflected in the Z position estimated performed by the EKF2.

Doesn’t anyone have an idea of what is wrong?
I suppose that EKF2 is not using the range information…

EKF will always use rangefinder data to estimate distance to ground, but it won’t use them to estimate UAV altitude by default.

Try setting EKF2_RNG_AID=1, to incorporate range data into the height estimation procedure and let us know if this helps.

Thanks @Georacer-avy for your advice, I will give it a try.
I am charging the battery, as soon as I am ready I will perform the same test putting the EKF2_RNG_AID=1.
By the way, such a parameter was not consider since I put EKF2_HGT_MODE=2, hence EKF2 should use the range finder to estimate the vehicle height.
In the meanwhile, I did another test where I slided on the desk the vehicle in order to point the lidar sensor alternatively on the ground (around 80cm below) and on the desk top (around 10cm).
Here the log: https://review.px4.io/plot_app?log=5117d7a9-414e-4772-986b-4b3453a95b18
As you can see, the range sensor is somehow integrated in the EKF2 estimate… I have an overshoot but at the end the estimation converges at the measured distance to the ground.

Ah, I didn’t notice EKF2_HGT_MODE=2. That should be enough for your case… weird.

I’ll try to take a second look.

I can’t find out what’s wrong within reasonable time, sorry.

Indeed the local position should track the distance to ground; maybe we’re missing some parameter.

As a hacky solution, could you also try MPC_ALT_MODE=1? Only on Altitude mode, it will stabilize the UAV in terms of ground, not its own position.

well…
I did the test setting EKF2_RNG_AID=1 as suggest, but the result is the same: the drone drift along the Z position.
Concerning the MPC_ALT_MODE parameters, within the several performed tests, I switched between value 0 (Altitude following) and 1 (Terrain following) without observing a markable difference.
In particular, in Terrain following control, I have observed a little altitude variation passing over an obstacle (a desk or a drawers in my case), but such a variation was order of magnitude lower than the measured ground distance variation. Even in that control modality, altitude drift was evident.
Finally, I have never tried the combination MPC_ALT_MODE=2 (Terrain hold) and Range_Aid (EKF2_RNG_AID=1). This is the test I would like to do next Monday even if I think it will not solve the problem.
I think the real problem consist in range measure acceptance… something related with the consistency checks, but right now I don’t know how to debug it.
Any idea @Georacer-avy ?
Thanks for your time…

Sorry, but I don’t think I can help you further with this. I’m very interested to hear the result, if one is reached.