Odometry drifts with Euroc dataset Machine Hall (MH_01_easy) and Mynteye Camera about r-vio

[huaizheng]

i. For each sequence in machine hall, as what we can notice, there is a phase of "stop->moving->stop" at the beginning which is particular for map initialization of visual(-inertial) SLAM. R-VIO does not need such a procedure to initialize the estimator, because it does not include map points (features) in the state vector. Also, R-VIO is a pure visual-inertial odometry focusing on high-precision motion tracking and quick initialization, for the sequences in machine hall we typically start the estimation after that particular phase to avoid the possible drift.
ii. For the Mynteye camera issue, as you did not provide any details, currently I have no clue on that. While the most important thing to run on your own sensor is to have a correct config file (*.yaml), especially for those fixed sensor parameters, and for the other (tunable) parameters you can change their values based on the types of motion and environment.

[poaongithub]

hi, is there a solution to R-VIO drifts when it on the stationary situation? thanks a lot.@huaizheng

[huaizheng]

@poaongithub First of all, the stationary case is a degenerate motion case for VINS which may cause drifts. As shown in the paper, the influence of such case can be mitigated by R-VIO's inverse depth-based measurement model that tends to only update orientation when motionless (for example, in the urban driving test we had to stop a while before the traffic light while the translational drift was very small). However, if at the very beginning when the state covariance has not "well-converged", it is hard to guarantee that such drift can be prevented. So in this code, I implemented a simple logic, to detect whether the sensor is moving or not using some thresholds that you can tune by yourself, to decide when to start the estimation. And there exist other solutions using map information (in SLAM-based VINS) to deal with the stationary phase in the navigation, for example, in the OKVIS and VINS-Mono.