Stuck in endless QVIO's "ERROR waited more than 0.3 seconds for imu to catch up, dropping frame"

ErezI

Hi,

In my company, we use your VOXL-FLIGHT modules for PX4’s offboard indoor & outdoor
GPS-denied flights (using the QVIO as the PX4 navigation source).

We get occasionally (in different PX4 modes: position, offboard, alt hold, etc)
QVIO errors that lead to position lose.

An example scenario:
Our drone is in the middle of the flight, using your recommended PX4's outdoor parameters
for the QVIO as the PX4 navigation source.

The QVIO & the relevant IMU seems to be OK
QVIO page in the portal (good Q, enough features, right X / Y /Z positions,
and the QVIO / relevant IMU inspectors without any errors (using ssh to the target).

Suddenly (moving or hovering) the following QVIO errors occurs consecutively:
“ERROR waited more than 0.3 seconds for imu to catch up, dropping frame”
or (in debug execution)
“waiting for imu”.

In this situation, the PX4 lose its position, causing a manual intervention
in order to prevent the drone's crash.

The IMU’s inspector without any errors in this stage,
and the problem occurs using imu0 and also using imu1 as the QVIO's input.

Restarting the QVIO (ssh / adb) fixing this problem, but the QVIO parameters reset
and we can’t continue the GPS-denied navigation flight / ground simulation.

Can you help us.

Regards,

Erez

Chad Sweet

Hi Erezl, a little more information might help

Are you using a flight deck with known extrinsic parameters or have you mounted the image sensors yourself?
Are you running other processes when this error occurs?

ErezI

Hi Chad,

We are using the VOXL-Flight board with the tracking camera as the QVIO camera and also a SF20 Lidar as altitude range aid.

We wrote our VOXL code to enable the OffBoard mode, and in order to receive position local ned parameters (X, Y, Z, YAW) from a ground GUI application via the wifi medium.

We use your recommended PX4's indoor parameters and board's extrinsic for the VOXL-Flight board (with a tracking a position shift according to our camera emplacement / self mounted 45 degrees down).

We tried to suspend and resume the imu pipe in the QVIO server to solve the problem, and also disabled the vision possibility to perform hard reset of the QVIO and let our manual pilot deal with the drone in order to understand the problem and prevent unpredictable uncontrolled navigation

We also execute your QVIO inspection and print additional QVIO & position debug information
in a ssh terminals to the VOXL board.

We use station wifi's mode, and we get errors regardless the PX4 mode (position/ offboard, etc).

We try to rule the drone from the takeoff to the land using position commands & maximal MPC velocities (x,v,z,yaw) using the PX4 offboard mode in GPS denied environment.

Are you acquainted with this problem (problem only with the imu pipe side in the QVIO server)?

Thanks,

Erez