Hi,
I am investigating a repeatable vertical estimator problem on a 3.5" 6S cinewhoop running ArduCopter 4.7.1.
I am sharing three original DataFlash logs showing two different behaviours depending on the vertical position source.
DataFlash logs
Log 01 – BARO runaway, EK3_ALT_M_NSE=0.5
01_BARO_RUNAWAY_ALT_M_NSE_0.5.bin
Download Log 01 from Google Drive
Log 02 – BARO runaway, EK3_ALT_M_NSE=2.0
02_BARO_RUNAWAY_ALT_M_NSE_2.0.bin
Download Log 02 from Google Drive
Log 03 – RangeFinder comparison / bad VD after landing
03_RF_ONLY_BAD_VD_AFTER_LANDING.bin
Download Log 03 from Google Drive
The vehicle has multiple EKF3 source sets configured.
During the BARO events discussed below, the selected source set uses BARO for POSZ and no VELZ.
The RangeFinder comparison uses RangeFinder for POSZ, Optical Flow for VELXY, and no VELZ.
I would appreciate some help understanding what is happening inside EKF3.
Hardware
- FC: Flywoo GOKU H743 Pro Mini / STM32H743
- Dual ICM42688P IMUs
- External IST8310 compass
- FlyFish M10 GPS
- MicoAir MTF-02P RangeFinder / Optical Flow
- AM32 ESCs with ESC telemetry
The relevant configured source sets are:
SRC2:
POSXY = None
VELXY = Optical Flow
POSZ = RangeFinder
VELZ = None
SRC3:
POSXY = None
VELXY = None
POSZ = Barometer
VELZ = None
For the BARO tests:
EK3_HRT_FILT = 2
GND_EFFECT_COMP = 1
Log 01 – clearest BARO runaway
01_BARO_RUNAWAY_ALT_M_NSE_0.5.bin
This log uses:
EK3_ALT_M_NSE = 0.5
During the relevant event, the BARO source set is selected.
The EKF vertical velocity (XKF1.VD) starts developing a significant error. XKF1.PD then begins to diverge even though the physical altitude indicated by the available measurements does not justify the EKF altitude change.
As the discrepancy grows, XKF4.SH eventually exceeds 1.
In this log, SH starts exceeding 1 at approximately 52.95 s.
About 5 seconds later, at approximately 57.95 s, PD makes a very large discontinuous correction of roughly 7.5 m, which appears consistent with the EKF height timeout / ResetHeight() path.
The concerning part is that the large height correction does not appear to recover the vertical velocity state. VD remains abnormal and subsequently becomes much worse.
The sequence appears approximately:
VD starts becoming incorrect
↓
PD diverges
↓
height innovation grows
↓
SH > 1
↓
height fusion becomes unhealthy/rejected
↓
~5 seconds
↓
large PD correction/reset
↓
VD is still incorrect
↓
vertical solution diverges again
EK3_ALT_M_NSE=0.5 was intentionally tested to see whether giving the BARO observation substantially more weight would prevent the divergence.
It did not.
Log 02 – independent BARO occurrence with ALT_M_NSE=2
02_BARO_RUNAWAY_ALT_M_NSE_2.0.bin
This is an independent occurrence using:
EK3_ALT_M_NSE = 2.0
Again, the BARO source set is selected during the relevant event.
This log is included mainly to show that the behaviour in Log 01 is not specific to the experimental EK3_ALT_M_NSE=0.5 setting.
Again, VD becomes incorrect and the vertical EKF position subsequently diverges.
So simply changing the BARO observation noise does not appear to address the underlying problem.
The BARO runaway does not appear to start from high vibration
I initially suspected IMU vibration.
However, in the BARO logs the vertical estimator problem begins while vibration levels are still low and there is no accelerometer clipping.
For example, during the developing divergence in Log 01:
VIBE Z ≈ 3–4
Clip = 0
The very high vibration and clipping occur later, after the vehicle behaviour has already deteriorated.
Therefore, the high vibration seen near the eventual crash does not appear to be the initial trigger of the estimator divergence.
I have not ruled out a lower-frequency accelerometer/bias issue.
Accelerometer Z bias may be relevant
Looking at XKF2.AZ, EKF3 is estimating a significant Z accelerometer bias.
Across these logs it is commonly approximately:
-0.2 to -0.4 m/s²
depending on the point in the flight.
Both ICM42688P IMUs show similar behaviour, so I have not found evidence pointing to a failure of only one IMU.
I am not claiming that this bias is the cause of the runaway.
I am wondering whether the observability/correction of the Z accelerometer bias and VD becomes important when there is no independent VELZ observation.
Log 03 – RangeFinder comparison
03_RF_ONLY_BAD_VD_AFTER_LANDING.bin
During this test the selected source set uses:
POSXY = None
VELXY = Optical Flow
POSZ = RangeFinder
VELZ = None
I do not see the same large vertical position runaway.
However, after one landing the RangeFinder measures approximately:
~0.02 m
with the vehicle physically stationary on the floor, while EKF VD remains around:
~-0.4 m/s
for a significant period.
In other words, the EKF still appears to believe it has an upward vertical velocity while the vehicle is stationary.
The RangeFinder appears able to strongly contain the position error while the vertical velocity state can remain incorrect for some time.
The contrast between the logs appears approximately:
LOG 01 / LOG 02
BARO POSZ + no VELZ
VD becomes incorrect
↓
PD starts following the incorrect VD
↓
height innovation becomes too large
↓
height fusion becomes unhealthy
↓
large vertical runaway
versus:
LOG 03
RangeFinder POSZ + no VELZ
VD can still be incorrect
↓
RangeFinder strongly constrains PD
↓
large position runaway does not develop
My current interpretation
I do not think the evidence supports simply:
no VELZ → runaway
Normally the vertical position observation should also constrain the vertical states indirectly through the EKF.
What appears unusual in Logs 01 and 02 is that VD begins to diverge, PD follows it, and eventually the BARO height measurement becomes statistically incompatible with the EKF state.
Once height fusion becomes unhealthy, there is no independent VELZ observation to directly constrain VD.
Log 03 is particularly interesting because it shows that VD can apparently be significantly wrong without producing the same large PD runaway when the RangeFinder is used as the vertical position source.
Questions
- With BARO POSZ and VELZ=None, how strongly should EKF3 height fusion normally constrain
VDand the gravity-aligned accelerometer bias? - In Log 01, if the large PD correction at approximately 57.95 s is indeed caused by the height timeout /
ResetHeight()path, is it expected thatPDcan be reset while an incorrectVDremains largely unaffected? - Could this explain why, after the large PD correction in Log 01, the vertical solution immediately starts diverging again?
- Does the behaviour in Log 03, where the RangeFinder strongly constrains the position while
VDremains significantly non-zero on the ground, provide a useful clue about what is happening to the vertical velocity state? - Is there any known issue in Copter 4.7.1 / EKF3 involving vertical velocity or accelerometer-bias observability when there is no independent vertical velocity source?
- Are there relevant EKF3 changes in newer code concerning on-ground zero-velocity fusion or accelerometer Z-bias estimation that could affect this behaviour?
The three original DataFlash BIN files are available from the Google Drive links at the beginning of this post, so the actual parameters, source switching and estimator behaviour can be checked directly.
I am mainly trying to understand the estimator mechanism before changing more parameters.
Thanks.
