The filter estimate of altitude does not track our external nav input (using vision_position_estimate message) when flying in Altitude Hold. EKF2 does a much better job of using our input in Stabilized mode. What would cause a difference in EKF2 performance based on flight mode?
Hello @Kefka,
Can you provide your flight logs, to have a look at your parameters and experience ? 
In STABILIZE mode, the power from the motors for altitude is directly linked to the stick of the pilot in the RC. In ALT_HOLD, the Copter tries by itself to control the altitude according to the stick (for ex, if the stick is in the middle, the Copter will stays at the same altitude). So, in my opinion, this is normal to not see the same behavior between the two graphs.
I see that you have EK2_ALT_SOURCE = 2, means the GPS is the primary source for altitude.
From what I understand, you want that external navigation gives this altitude.
I recommand to follow my PR, which gives you this option :
For EKF2, ALT_SOURCE :
0 Use Baro
1 Use Range Finder
2 Use GPS
3 Use Range Beacon
4 Use EXTNAV_Z
Otherwise, if you don’t want to follow this PR, the ArduPilot code work as following :
If you have ALT_SOURCE = 0, but you are providing external navigation, then the primary source will be external navigation by default (and not the baro). Which is for me a wrong way of working, but it does work.
We attempted the same type of flight (Stabilized and then Altitude Hold) with EK2_ALT_SOURCE = 0. We saw no noticeable change in the EKF2 altitude estimate behavior (see below figure).
The stick behavior differences between flight modes makes sense to us, but in either mode it seems that the EKF2 estimates should behave the same; i.e. it should track the external navigation altitude estimate that we are passing in regardless of stick position. It seems as if there is a gain or measurement noise difference between the two modes that affects how the filter estimates altitude.
Here are the log files for the latest flight.
LogFiles_8_7_19.zip (1.37 MB)
Here, I’m just suggesting, because I never saw that case.
Maybe the altitude estimation takes into account other sensors, like accelerometers. In the case of the altitude provided by the “VISP” is too large compare to the real pose of the drone, then the altitude estimation will reduce this value.
Check if the vision pose is accurate enough ?