Kimera-VIO separates state estimation from mesh generation, and that is why it has two backends

Stereo plus IMU, with monocular as an option

Kimera-VIO is a visual inertial odometry pipeline for accurate state estimation from stereo plus IMU data, and it can optionally use mono plus IMU data instead of stereo cameras.

That single sentence describes the input contract. The pipeline fuses camera measurements with inertial measurements to estimate the state of the platform over time, and the state estimation is the output that matters. The project description adds SLAM capabilities and 3D mesh generation, and the mesh part comes later in the architecture rather than being the primary product.

The authors are Antoni Rosinol, Yun Chang, Marcus Abate, Nathan Hughes, Sandro Berchier and Luca Carlone, from the MIT SPARK Lab, and the README asks you to cite their paper if the library is useful. The primary citation is the Kimera paper on an open-source library for real-time metric-semantic localization and mapping, accepted at ICRA in 2020, with a BibTeX block included. There is a follow-up paper on going from SLAM to spatial perception with 3D dynamic scene graphs, from 2021.

The licence is BSD-2-Clause, with the text in a LICENSE.BSD file at the root, and the primary language is C++.

The evaluation setup is worth noting for anyone judging the accuracy claims. The README links to a Jenkins server hosting the VIO on Euroc performance report, which means the evaluation is reproducible from the CI rather than being a table in the paper that nobody can rerun. The topic list names the Euroc dataset and CPU as the target, and real-time as a property.

The last push to the repository was on 2026-08-06 and it is not archived, so the code is still being touched, even though the tagged releases are old.

The two backends are the architectural decision

The backend optimisation is based on two papers, and the README explains that there is an alternative, which is what makes the design interesting.

The default backend is based on On-Manifold Preintegration Theory for Fast and Accurate Visual-Inertial Navigation, by Forster, Carlone, Dellaert and Scaramuzza, published in IEEE Transactions on Robotics, and on Eliminating Conditionally Independent Sets in Factor Graphs, a unifying perspective based on smart factors, by Carlone and others at ICRA 2014.

The alternative is the `Regular VIO` backend, using structural regularities, described in Incremental Visual-Inertial 3D Mesh Generation with Structural Regularities, by Rosinol, Sattler, Pollefeys and Carlone at ICRA 2019.

So the choice is between a factor graph backend built on general on-manifold preintegration theory and smart factors, and a regularised backend that exploits structural regularities and is the one used for the incremental mesh generation paper.

That distinction matters for a user because the regular backend is what the 3D mesh work is built on. If your interest is in the mesh generation and the associated structural regularities, the regular VIO backend is the relevant path, and the citations tell you which configuration you are running.

Both backends sit on the same GTSAM factor graph infrastructure, which is why GTSAM at 4.1 or newer is a hard prerequisite. The repository root shows the supporting pieces: a `src/` directory with the implementation, `include/` for the headers, `third_party/` for vendored components, `params/` for the configuration files, `scripts/` for the run scripts, `tests/`, `docs/`, `examples/` with a `KimeraVIO.cpp` example, `cmake/` for the build modules and a `Dockerfile_20_04`.

Nine dependencies, and two of them are MIT projects

The prerequisites list is where the real adoption friction is, and it is worth reading in full.

GTSAM 4.1 or newer and OpenCV 3.4 or newer are the two heavyweight ones. OpenGV is next, the geometric vision library. Glog and Gflags are the Google logging and flag libraries, Gtest is installed automagically, and DBoW2 is the bag of words library. Kimera-RPGO is another MIT SPARK project, the robust pose graph optimisation one. And ANMS, the adaptive non-maximum suppression codes, with the source files already vendored in `src/frontend/feature-detector/anms`.

Two observations. The ANMS vendoring is a practical convenience, since the feature detector needs it and shipping the source avoids one more external clone. And DBoW2 is listed with a link to a specific repository, which is a maintenance consideration for anyone building this in a decade.

There are two escape hatches for the dependency burden. The first is a Docker image that installs all of them for you, with the installation instructions in `docs/kimera_vio_install.md`. The second is the ROS route: if you use ROS, the Kimera-VIO-ROS repository can install all the dependencies and Kimera inside a catkin workspace.

The build itself was tested on Ubuntu 20.04, which the README states plainly, and the presence of `Dockerfile_20_04` at the root matches that. The build is CMake based with a `CMakeLists.txt` and a `cmake/` directory, and there is a `Jenkinsfile` at the root for the CI, along with a `package.xml` for the ROS package description and a `dev_tools/` directory.

One more piece of the layout is worth flagging: a `.patches/` directory at the root. For a project that depends on DBoW2, Kimera-RPGO and other upstream libraries, carrying patches means the build is reproducible, but it also means the patches have to be reapplied when you move to a newer upstream release.

Loop closure is off by default, and that is a deliberate default

The general tips section explains the three flags you are most likely to change, and the first one is a design decision rather than a convenience.

The LoopClosureDetector and the PGO module are disabled by default. If you wish to run the pipeline with loop-closure detection enabled, you set the `use_lcd` flag to true, and for the example script that is done by passing `-lcd` on the command line.

./scripts/stereoVIOEUROC.bash -lcd

The reason is visible in the second flag. To log output you set the `log_output` flag to true, done with the `-log` argument, and by default log files are saved in `output_logs/`. So the intended workflow is: run the odometry, look at the logs, and only then turn on loop closure once you are satisfied the front end and the odometry are behaving.

That ordering makes sense for a pipeline where a misconfigured loop closure detector can silently corrupt the trajectory, and where the raw odometry without loop closure is the thing you want to evaluate first. It also matches the structure of the publications, where the VIO evaluation on the Euroc performance report is the odometry benchmark.

The third flag is `parallel_run`, set to false to run the pipeline in sequential mode with one thread only, done with the `-s` argument in the example script.

For a library that is CPU targeted and real-time, being able to drop to a single thread is a genuinely useful debugging and determinism option, since a multithreaded pipeline that behaves differently between runs is hard to reason about.

Getting the Euroc dataset right, including two sequences that need fixing

The Euroc section is the practical entry point, and it contains a detail that will save you a day if you skip it.

The dataset is the ASL ETH Zurich MAV visual inertial dataset, and the instructions have you download one of the archives, for example `V1_01_easy.zip`, unzip it into a directory of your choosing, and then do one extra thing.

mkdir -p ~/Euroc/V1_01_easy
unzip -o ~/Downloads/V1_01_easy.zip -d ~/Euroc/V1_01_easy

The extra step is that you have to add `%YAML:1.0` at the top of each `.yaml` file inside Euroc, because the dataset's YAML files are not valid for the parser the pipeline uses. The README gives you a script for that, the `yamelize.bash` script in the `scripts/euroc/` directory, which takes the path to the dataset.

cd Kimera-VIO
bash ./scripts/euroc/yamelize.bash -p ~/path/to/euroc

The script name is a pun on YAML and it does one thing, and doing it by hand on a few sequences is also fine.

There is a second wrinkle. The datasets MH_04 and V2_03 have a different number of left and right frames, and the README suggests using the authors' own version of Euroc instead, which is hosted on Google Drive. The same hosted copy also comes already yamelized, so taking that download removes both problems at once.

Running the pipeline is one script, and the script bundles all the command line options and gflags.

cd Kimera-VIO
bash ./scripts/stereoVIOEuroc.bash -p "PATH_TO_DATASET/V1_01_easy"

The README notes you can alternatively use the executable in the build folder directly, `./build/stereoVIOEuroc`, but tells you to check the documentation first, which is a fair warning given how many parameters are involved.

Editorial conclusion

Adopt Kimera-VIO if you need a research grade visual inertial odometry pipeline with a published evaluation on the Euroc dataset and the ability to read every stage of the implementation in C++. Do not adopt it as a production robotics stack without checking the dependency burden, because GTSAM, OpenCV, OpenGV, DBoW2 and Kimera-RPGO all have to be present and the build was tested on Ubuntu 20.04. Verify first that the version of GTSAM you have matches the required range, that the camera and IMU configuration files match your hardware, and that you read the parameter defaults before trusting the state estimate.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. MIT-SPARK/Kimera-VIO on GitHub
4. README
5. Releases