Drift on no movement when odometry lost

[BarzelS]

Hi, I'm using rtabmap and robot_localization with my D435i for VIO, I'm getting a drift as seen on the gif when the odometry get lost without any movement of the camera. Any idea why?

[matlabbe]

If visual odometry may is be published, robot_localization updates the pose only with IMU. Estimating position only with IMU's accelerometer will generally create this kind of drift.

[BarzelS]

If visual odometry may is be published, robot_localization updates the pose only with IMU. Estimating position only with IMU's accelerometer will generally create this kind of drift.

I've tried also witout the IMU and Im still getting this drift

[matlabbe]

What i the VIO approach? Is it the output of robot_localization that is drifting, or its inputs?

[BarzelS]

What i the VIO approach? Is it the output of robot_localization that is drifting, or its inputs?

F2M approach, both the robot localization and rgbd odometry output drift(when setting publish_null_when_lost to true)

[matlabbe]

When lost rgbd odometry would send null values, I would set publish_null_when_lost to false to avod sending non-valid values to robot_localization.

[BarzelS]

When lost rgbd odometry would send null values, I would set publish_null_when_lost to false to avod sending non-valid values to robot_localization.

Thanks @matlabbe,

1. But if I still want to have a continues odometry data when I'm lost(like for example 2 seconds moving in-front of a white wall) what can I do? I tried to set this flag to false but the fact that the velocity values before entering lost are wrong are the reason for that drift, the IMU data in robot localization cant "stop" that drift, any suggestion?
2. I think the main reason for the drift is that I'm getting wrong large velocity values on the outputs right before entering lost mode. Any idea how to avoid it? (This non-continues movement or drift can really effect the map construction)

[matlabbe]

Is the accelerometer from the IMU used to estimate the position? If he filter doesn't receive anymore sensor update, it may use its internal representation to update the pose based on time and probably a constant velocity model. It will indeed take the latest velocity received and estimate its position while the sensor is blocked. Unless you have a super accurate IMU (like xsens) for pose tracking, it will be very difficult to know how much you moved when looking to a white wall. You have two choices, either the filter stop updating when it receives null odometry, or estimate as constant velocity (maybe use accelerometer to adjust a little) based on last one received.

It is why in kinect example, when we cannot estimate odometry anymore, we just stop, forcing the user to come back where it worked and try to scan different the textureless area (like scanning from farther, or scanning to have always some features to track).