Hi,
I am looking for some help understanding a potentially dangerous vertical control / EKF behaviour on a small, very high thrust-to-weight 3.5" quad running ArduCopter 4.7.1.
Complete DataFlash log:
2026-09-13 16-20-19.bin
Google Drive download:
Hardware / firmware
- ArduCopter 4.7.1
- Flywoo / GOKU H743 Pro Mini (STM32H743)
- 3.5" quad, 6S
- AM32 ESCs with ESC telemetry
- FlyFish M10 GPS, 5 Hz
- IST8310 external compass
- DJI FPV Remote Controller 3
- Onboard FC barometer
- Vibration levels are low and there are no accelerometer clipping events
Relevant configuration
At the time of this flight:
EK3_SRC1_POSZ = 1 # Barometer
EK3_SRC1_VELZ = 3 # GPS
EK3_ALT_M_NSE = 2.0
EK3_HGT_I_GATE = 500
EK3_GLITCH_RAD = 25
EK3_GND_EFF_DZ = 4
GND_EFFECT_COMP = 1
PSC_D_POS_P = 1.0
PSC_D_VEL_P = 5.0
PSC_D_ACC_P = 0.017
PSC_D_ACC_I = 0.034
MOT_THST_HOVER = 0.17
The low ACC-Z P/I values are intentional because this quad requires only approximately 0.17 normalized thrust to hover.
What happened
The relevant part of the log is approximately 164–172 seconds.
The quad was descending very quickly and I switched into altitude-controlled modes in an attempt to arrest the descent.
Relevant mode transitions:
164.241 AltHold
164.521 Loiter
167.016 Stabilize
168.081 AltHold
171.868 Stabilize
Before the ground contact, the high descent rate appears to be real. GPS vertical velocity and the EKF both indicate approximately 6–9 m/s downward.
The altitude controller starts attempting to arrest the descent, but there is insufficient altitude and the vehicle reaches the ground.
Around the ground contact there is then a very large and physically impossible barometer transient.
For example:
165.258 s EKF altitude ~6.3 m Baro altitude ~3.0 m
165.458 s EKF altitude ~4.3 m Baro altitude ~16.6 m
So the indicated barometric altitude changes by approximately 13 m in only ~0.2 seconds.
After this event, the vertical state estimate becomes extremely abnormal.
Later in the event I see approximately:
CTUN.CRt maximum: +48.9 m/s
CTUN.CRt minimum: -24.0 m/s
Baro altitude maximum: ~43.8 m
EKF altitude maximum: ~37.0 m
These vertical velocities and altitude changes clearly do not represent the actual vehicle motion.
Main concern: alternating 0–100% throttle
The part I am particularly concerned about happens after the altitude estimate becomes corrupted.
While an altitude-controlled mode is active, the controller begins commanding almost alternating minimum and maximum thrust:
ThO -> 0
ThO -> 1
ThO -> 0
ThO -> 1
...
The motors follow these commands and the quad is physically launched upwards.
GPS confirms that a substantial part of the subsequent climb is real, although the barometer/EKF altitude and vertical velocity estimates are clearly corrupted.
At approximately 171.87 s I switch back to Stabilize, removing the automatic altitude control, and I am able to recover the vehicle.
What I would like to understand
I understand that the initial high-speed descent and ground contact are extreme conditions, and I am not suggesting that ArduPilot caused the initial impact.
My concern is specifically the behaviour after the barometer transient and corruption of the vertical state estimate.
I would appreciate some guidance on the following:
- Is the alternating
ThO 0 -> 1 -> 0 -> 1response expected when the EKF vertical state becomes corrupted this severely? - Should EKF3 have rejected the barometer measurement earlier in this situation?
- Is there a recommended EKF configuration for a small high-thrust quad where propwash / pressure transients can generate large, short-duration barometric altitude errors?
- Would increasing
EK3_ALT_M_NSEbe preferable to reducingEK3_HGT_I_GATE, or is there another EKF parameter/protection that would be more appropriate? - Is there any existing mechanism that should prevent the altitude controller from repeatedly commanding full/minimum thrust when the vertical state estimate has become implausible?
Additional test
After this incident I tested:
EK3_HGT_I_GATE = 300
During a subsequent normal flight, the primary EKF lane’s XKF4.SH remained below 1.0, with a maximum of approximately 0.68, so I did not observe a height measurement rejection.
For this reason I am hesitant to reduce the height innovation gate further without understanding whether that is actually the appropriate solution.
I am mainly trying to determine whether what I am seeing is:
- expected behaviour following an extreme barometer disturbance,
- an EKF configuration issue,
- a vertical controller configuration issue,
- or a situation where additional EKF/controller protection could be useful.
I can provide additional normal-flight logs for comparison if useful.
Thanks for taking a look.
