After the discussion from today’s devcall with this little thought experiment,
I realised I already observed something similar to this already in 4.7-beta1.
I did a series of quick tests and I’m not sure what to conclude from my observations so I request you to try this out. My test setup includes an optical flow with rangefinder and no GPS. I have also set USE_HGT to -1 but have enabled surftrak, if this is of any relevance.
First, do not set an arbitrary EKF origin yet. You’ll find that the altitude shown in MP (baro altitude) reset to 0 whenever you arm. The same is true for local_position_ned’s z value. If you hold the copter in your hand raised up to a certain altitude and then arm, both these readings snap to 0 at that instant.
Now if you do have an EKF origin set, only the baro altitude gets reset and the fused altitude stays as it is, and may be off by 1-2m. Is this currently as intended?
Txs for the report. I’ll look into this when I look into the existing issue of the baro offset when switching from rangefinder to baro (see "Altitude estimate offset when switching between baro and rangefinder source " on the AP 4.7 issues list)
Ah okay, I think the key is that the z value does not update if an EKF origin was set. I guess the devcall topic was about resetting this z to 0 if the origin was set.
Yes, the dev call discussion was around this proposed change from AndyP to reset the barometer altitude each time the vehicle is armed. This needs careful thought though because it will cause issues if the vehicle arms, flies to a location, disarms, re-arms and then flies home.