EKF2 output divergence from Visual odometry data

🧪 Flight Testing & Log Analysis
1

Firmware version: 1.9.2
log file: https://logs.px4.io/plot_app?log=d4ec8b1f-48fe-498e-993f-8a561b540c85
Flight mode: Position Control

Hi,

we just had a crash during an indoor flight using visual odometry data. Looking at the flight video, it appears the visual odometry was giving correct output (drone drifting along the positive Y axis) but the EKF interpreted the opposite (drone drifting along the negative Y axis), thus causing control inputs to increase the drift until we hit a wall and crashed. The controls were unresponsive (likely due to the EKF diverging and feeding a wrong velocity Y state to the position controller).

Before the drone started drifting, it was oscillating in a toilet bowl motion when the pilot was in position hold (no input from the sticks), it seems like the estimator’s performance was bad from take off.

We struggle to understand what could have caused the EKF to output an opposite pose estimate to what the visual odometry was feeding, any ideas?

2

@francelico Have you finally managed to solve the issue? I am using Firmware version 1.10.1 and recently experienced a very similar issue. However, in my case, it was happening when I set up EKF_EV_DELAY (delay imposed in VIO processing stage) for 200ms. Therefore the internal buffer on PX4 couldn’t store all the messages from the past 200ms and it simply got the messages broken. I had to enlarge a buffer and don’t have diverging EKF2 anymore, however, it’s far from perfect.
I believe that in your case there was an issue in the connection itself between FCU and companion PC since you got big Round Trip Times (RTT).