performance evaluation about gtsam_vio HOT 1 CLOSED

The IMU readings were noisy, causing the predicted pose of the robot to drift (you should be able to see this provided you successfully get the code running - it definitely can be a challenging process if you are new to ROS). We tried fixing the drift by messing around with the covariance of the IMU factors, but ultimately decided that the sensor integration (odometry) done by the camera itself was simpler to use, more accurate, and more efficient than iSAM2‘s solution; see the gtsam documentation from 2018 on how the IMU factors worked - after you look at that I think you’d agree that requiring position, velocity, and bias factors for each new observation adds a ton of overhead to optimizing and solving the graph, when all you need is position. (Note: I think more recent versions of gtsam have made integrating the IMU more efficient. You may want to check that out.)

Your time would probably best be served by trying to understand the iSAM2 algorithm more deeply (beyond what I mentioned in the powerpoint/paper) using the references, and looking into the ZED mini and gtsam documentation.

The lag that happens from having to solve for too many factors & variables and the insolubility of the graph if you over-constrain your variables is inevitable as far as what I experienced with iSAM2. You may be able to avoid some of these problems with newer algorithms or libraries that use multi-threading to simultaneously solve/update the graph while running other pre-processing code.

from gtsam_vio.