When using mono-inertial codes on my own data, I always got frequently initilization and failure issue, which report is this:
First KF:0; Map init KF:0
New Map created with 271 points
Fail to track local map!
IMU is not or recently initialized. Reseting active map...
SYSTEM-> Reseting active map in monocular case
LM: Active map reset recieved
LM: Active map reset, waiting...
LM: Reseting current map in Local Mapping...
LM: End reseting Local Mapping...
LM: Reset free the mutex
LM: Active map reset, Done!!!
mnFirstFrameId = 10
mnInitialFrameId = 0
4 Frames set to lost
I viewed almost all issues about mono initialization under this repo, and found solutions (or at least, suggestions), which solved my problem. Here I give a summary. For stereo-inertial system, some comments may also fruitful.
About how to determine the calibration is correct: calibrate the system for severl times, to see if the results are same. The translation difference should be within just a few millimeters.
As the paper already pointed out (the last paragraph in conclusion), which is also emphesized by authors in this issue, the IMU initialization should include IMU roll/pitch rotation.
In applications with slow motions, or without roll and pitch rotations, such as a car in a flat area, IMU sensors can be difficult to initialize. In those cases, if possible, use stereo SLAM.
Since during the initialization, the first 2 second frames are used for initial map, and then IMU gravity initialization, so at the beginning of the data, the camera should move with enough translation (and still guarantee the tracking features https://github.com/UZ-SLAMLab/ORB_SLAM3/issues/221#issuecomment-748597473, and the same time, enough roll/pitch rotation for IMU.
The above solutions solves my problem. And here are some suggestions from others:
Modify the ORB extractor configs in yaml file: increase the nFeatures, nLevels, and decrease iniThFAST and minThFAST;
Use camera's resolution around 640x480 with default parameters;
As for IMU and camera frequency, there are many discussitions. For me, the influecne of different frequencies is much less than the calibration & motion issues. IMU > 100Hz, and camera about 10-30Hz works under most of issues.
Hope this issue could end most of discussions about the VI initialization failure.
JinXiangLai
commented
1 year ago
When using mono-inertial codes on my own data, I always got frequently initilization and failure issue, which report is this:
I viewed almost all issues about mono initialization under this repo, and found solutions (or at least, suggestions), which solved my problem. Here I give a summary. For stereo-inertial system, some comments may also fruitful.
Since there are too many issues, I cannot mention all of them, but I guess the following issues are due to the same reason more or less: https://github.com/UZ-SLAMLab/ORB_SLAM3/issues/501, https://github.com/UZ-SLAMLab/ORB_SLAM3/issues/664, https://github.com/UZ-SLAMLab/ORB_SLAM3/issues/28, https://github.com/UZ-SLAMLab/ORB_SLAM3/issues/264, https://github.com/UZ-SLAMLab/ORB_SLAM3/issues/356, https://github.com/UZ-SLAMLab/ORB_SLAM3/issues/569. Also, under those issues (and not mentioned ones), there are suggestions from authors of this repo/paper, and other guys. I followed the authors suggestions first, and list others comments just for reference.
As authors point out, there are two reasons for initialization failure: 1. inaccurate camera and IMU extrinsics, and 2. not enough motion during the initialization process. See https://github.com/UZ-SLAMLab/ORB_SLAM3/issues/221#issuecomment-748597473 and https://github.com/UZ-SLAMLab/ORB_SLAM3/issues/435#issuecomment-1000170690.
First, about the IMU and camera extrinsics, here's my suggestion and comments:
Second, about the initialization process:
The above solutions solves my problem. And here are some suggestions from others:
nFeatures,nLevels, and decreaseiniThFASTandminThFAST;Hope this issue could end most of discussions about the VI initialization failure.