Copter: Relative Altitude not calibrated on arming, not always set to 0m by barocal

[AndKe]

The attached log shows non-zero relative altitude on arming/takeoff
00000031.zip

I observed that rel.alt as presented by QGC, mavproxy is often far from 0m due to time on ground before arming.
It's not reset to 0m (barometer calibrated) on arming, but it'd also only occasionally it works via GCS.
For example, on mavproxy, I may command:
(relative altitude is 3m)
barocal
-get success message, no change in altitude
barocal
-get success message, no change in altitude
reboot
-(Pixhawk 2.1 reboots, now at 1,5m)
barocal
-get success message, altitude drops to 0m

This is not mavproxy related, same happens with QGC.

[AndKe]

Adding a .tlog of a tlog replay (from a much bigger one.
unable to calibrate-tlog.zip
)

It shows many calibration attempts, each resulting in a "success", but the indicated relative altitude does not change, then a reboot (which gives better altitude, and a good calibration)

in
void AP_Baro::update_calibration()
There are conditions that will skip calibration silently if not "healthy"

bool healthy(uint8_t instance) const { return sensors[instance].healthy && sensors[instance].alt_ok && sensors[instance].calibrated; }

[rmackay9]

I haven't looked at the logs but there are a few things to keep in mind:

• the alt sent to the GCS is the alt-above-home and should be reset to zero as part of arming. I haven't re-checked the code but it's possible it's not reset to zero if the vehicle doesn't has GPS lock... I'm unsure about this case.
• when looking in the dataflash logs, make sure that you're looking at the alt-above-home (CTUN.alt). Some other altitudes may be the alt-above-EKF-origin including the altitude reported by the barometer. Because the EKF origin does not move (in general) the alt-above-EKF-origin will not be reset to zero as part of arming.

[Pedals2Paddles]

Mine resets baro.alt, ctun.alt, and dAlt all to zero upon arming, with or without GPS. Tested and verified on both 3.5.3 and master.

[AndKe]

@rmackay9 Hi , thanks for looking, yes, you will see (in the attached dataflash log or tlogs) that nor CTUN.alt or (HUD in tlog) altitudes are reset, this BIN log starts with +6meters.

• observed on Mavproxy console & QGC. - I am very familiar with the normal behavior.

I suspect the health of the sensors to be the issue. The uploaded log is an early flight on this machine, where the arming checks were disabled due to bad compass setup, but the tlog and newer logs are with prearm checks = 1 , and still behaves like that.

every reboot resets it to zero, then it climbs to +/- some meters within minutes. I had some barometer calibrations to succeed, resetting properly, but 9/10 does nothing. the tlogs from that UAV car are day-long (huge) and I had to cut them down. I can/will provide any number of .BIN logs with this issue if needed (the UAV is not mine, I do not have access to it until Sunday/monday)

@Pedals2Paddles yes, I do not claim this affects all. I too can provide logs on other UAV where it works perfectly. This one, however, have the is reproducible nearly every time.

[AndKe]

I just uploaded a good log example. - two flights before that, altitude were reset just fine. (there were no config changes between those flights)

[AndKe]

another log here: https://discuss.ardupilot.org/t/please-review-my-tuning-results-25kg-x8-with-bad-yaw/25619

[rmackay9]

@AndKe I've replied on that thread but I think if you arm and takeoff in Loiter you'll find the altitude reset. The cause is just that the ekf origin hasn't been set yet at takeoff (I think).

[IamPete1]

@AndKe any update? Is this still a issue?

[rmackay9]

I think we can close this and if it is still an issue with 4.1 we should create a discussion to track it here first: https://discuss.ardupilot.org/c/arducopter/copter-41/159

[AndKe]

I haven't seen that issue for years.