I believe that, since the altitude control loop isn’t particularly fast, the 5 Hz update rate of the GPS altitude data should be sufficient.
That might happen with the velocity data, but when it comes to altitude, the fusion process is handled a bit differently. see: EK3_OGN_HGT_MASK , Velocity Source Fusing
In my opinion, you could configure the primary height source in the main EKF lane to be GPS, while keeping the other lanes active with their default height source (barometer) as backups. see: EK3_IMU_MASK, EK3_SRC1_VELZ
This way, if anything goes wrong—especially since it’s your first time using GPS as the height source—you’ll still have reliable fallback options during testing.
By the way, the GPS performance looks solid—the data quality is good, and the altitude accuracy is within about a meter, which I believe is more than adequate for this use case.
I didn’t imply outer loop tuning issue. My observations were regarding high baro variance.
For a stable plane you can use manual mode to recover from any autopilot control loop misbehaving but if the plane is unstable you have to use inner loops to keep it pointing where you want it so RC control can’t be used to recover inner loop issues like poor attitude tune caused by outer loops.
In any case having RC control is better than not having it.
In my plane setup workflow, I strive to do first autotune as soon as practical, preferably in first or second flight so any failsafes requiring automatic flight will work reasonably.
Sounds like a solid approach.. thanks for the clarification. I’m curious though, why are all three altitude sources (SRC1, 2, 3) typically set to baro by default? Wouldn’t it make sense to have at least one set to GPS, considering baro noise is fairly common?
I see your point, and I agree having manual control would definitely be safer. Unfortunately, it’s not practical in my case due to the high speed, and honestly, I’m not experienced enough as a pilot yet to handle it manually at those speeds.
For now, I’m sticking to AUTOTUNE in SITL, both in RealFlight and Simulink, as part of a more analytical, academic tuning process.
SITL AUTOTUNE clearly hasn’t produced adequate results. If you want to do analytical tuning you need to measure actual system dynamics and for that you need sufficiently stable tune as SysID mode will excite the system.
If you can’t manage the plane LoS you should either equip it with FPV system or up the HUD (attitude) refresh rate and fly IFR with an observer. Tuning and testing can be done in that way if you don’t have a lot of tall obstacles around.
In that case find an experienced pilot who can. Right now you are dealing with a fire and forget “missile” which will land/crash wherever it wants and you have little control over it.
The only documentation for them is source code . Delta takes data and identifier (which should be unique) you have to multiply the result by sample rate (only works for fairly jitter free streams like IMU, I haven’t found any way of calculating delta timestamp). Lowpass additionally takes a number that specifies contribution from current state and previous state, lets call it “a” then new_state=prev_statea+current state(1-a).
. Delta takes data and identifier (which should be unique) you have to multiply the result by sample rate (only works for fairly jitter free streams like IMU, I haven’t found any way of calculating delta timestamp). Lowpass additionally takes a number that specifies contribution from current state and previous state, lets call it “a” then new_state=prev_statea+current state(1-a).