# MINS: multisensor-aided inertial navigation with online calibration

> MINS is a tightly coupled multisensor-aided inertial navigation system from the Robot Perception and Navigation Group that fuses IMU, wheel encoders, camera, GNSS and LiDAR in a single filter, with online calibration of the onboard sensors. It suits robotics research teams working on VIO, LiDAR-inertial odometry and multi-sensor localisation, and it ships as source that you build against several ROS versions.

**rpng/MINS** — An efficient and robust multisensor-aided inertial navigation system with online calibration that is capable of fusing IMU, camera, LiDAR, GPS/GNSS, and wheel sensors. Use cases: VINS/VIO, GPS-INS, LINS/LIO, multi-sensor fusion for localization and mapping (SLAM). This repository also provides multi-sensor simulation and data. 

- Repository: https://github.com/rpng/MINS
- Stars: 804 · Forks: 130
- Language: C++
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/rpng-mins

## Five sensing modalities inside one tightly coupled filter

MINS is described as an efficient and tightly coupled Multisensor-aided Inertial Navigation System that flexibly fuses all five sensing modalities, IMU, wheel encoders, camera, GNSS and LiDAR, in a filtering fashion. The three hurdles it names are computational complexity, sensor asynchronicity and intra-sensor calibration, which is a useful summary of why a monolithic multi-sensor estimator is hard rather than merely large.

The exemplary use cases are listed in the project's own terms: VINS in mono, stereo and multi-camera configurations, GPS-IMU with one or several receivers, LiDAR-IMU with one or several units, wheel-IMU, and combinations such as Camera-GPS-LiDAR-wheel-IMU. The last item is the point of the system. Anyone who has fused a camera and a lidar by hand knows that the result is usually two estimators stitched together with a late correction, whereas a tightly coupled filter estimates them in one state.

The state formulation is described as consistent high-order state on manifold interpolation, improved from prior work called MIMC-VINS, together with a dynamic cloning strategy for light-weight estimation performance. Manifold interpolation matters for cameras and lidar because their measurements live on a manifold rather than in Euclidean space, and a high-order state carries the higher-order terms that a plain error state drops. The dynamic cloning is the part that answers the complexity complaint: rather than always estimating the most complex model the project could, the estimator adapts.

The system was written at the Robot Perception and Navigation Group at the University of Delaware, and the work is published in the Journal of Field Robotics in 2025, with a preprint on arXiv and a DOI. For an academic group evaluating estimators, having a peer reviewed reference to cite and compare against is a substantial part of the value.

## Online calibration of every onboard sensor

The feature list leads with inertial based multi-sensor fusion, but the item that distinguishes MINS from a plain visual-inertial estimator is online calibration of all onboard sensors. The repository links exemplary results for that calibration, and the project treats calibration as something that happens while the robot is running rather than as a prior you establish once on a calibration rig.

The reason is practical. Extrinsics between an IMU and a camera drift with temperature, vibration and mounting flex. Calibration done once in a lab stops being true after the robot has been on a road for an hour, and a tightly coupled filter that estimates those extrinsics as part of its state will absorb some of that drift instead of failing on it.

That choice has a cost in observability. Every extra parameter in the state needs excitation to be observable, and a robot that drives in a straight line does not excite the rotation between its sensors in a way that separates them. So the online calibration feature comes with an implicit requirement on how the platform must move, and the evaluation toolbox, described as covering consistency, accuracy and timing analysis, is the tool for checking whether the estimator is actually seeing what you think it is seeing.

The project also flags that it needs very detailed options for each sensor in mins/src/options, which is where the per-sensor configuration lives. That directory is the practical entry point for a user: a default that suits a lab robot is unlikely to suit a vehicle with a different lidar rate or a different GNSS update rate.

## Building the catkin workspace on ROS1

The README gives a four line recipe for the ROS1 build, and it assumes a workspace directory already exported:

```bash
mkdir -p $MINS_WORKSPACE/catkin_ws/src/ && cd $MINS_WORKSPACE/catkin_ws/src/
git clone https://github.com/rpng/MINS
cd .. && catkin build
source devel/setup.bash
```

The clone goes into `src`, `catkin build` is run from the workspace root, and the resulting `devel/setup.bash` is sourced so the package is on the path. Note the use of `catkin build` rather than `catkin_make`, which means the project assumes catkin_tools rather than the original catkin script.

The repository layout backs up the claim that this is a research toolkit rather than a single package. Alongside `mins/` there are `mins_data/` for data, `mins_eval/` for the evaluation toolbox, `thirdparty/` for the vendored dependencies, a `CMakeLists.txt` at the root, a `run_format.sh` script and a `.clang-format` file. The vendored dependencies are named explicitly: OpenVINS, an open source filter based visual-inertial estimator, and ikd-tree, an incremental k-d tree. MINS was built on top of both, and they are carried in the `thirdparty` folder rather than fetched at build time, which is what the `.gitmodules` file is likely to relate to.

Carrying the dependencies in-tree is convenient for reproducibility and awkward for maintenance, since you are responsible for any local modification to a vendored copy.

## Running the simulation and the real-mode node under ROS2

For ROS2, the project points you at its Dockerfiles for the build instructions and the dependencies, and the repository ships one per supported distribution, named Dockerfile_humble_22_04, Dockerfile_jazzy_24_04 and Dockerfile_lyrical_26_04 alongside the ROS1 and ROS-free variants.

After building and sourcing, the simulation starts with a single run command:

```sh
ros2 run mins simulation mins/config/simulation/config.yaml
```

Real mode subscribes to live topics instead:

```sh
ros2 run mins subscribe mins/config/euroc_mav/config.yaml
```

To feed it, play a bag in another terminal, for example from the euroc_mav dataset after converting it with rosbags:

```sh
ros2 bag play data/MH_01_easy
```

In both cases the README points you at rviz2 to look at the path as estimated by MINS. The split between `simulation` and `subscribe` is worth noting: the simulation entry point is a self-contained node that generates its own sensor data, while the subscribe entry point is a live pipeline you can point at either a bag player or real hardware.

For ROS1 the equivalent commands are launch files rather than run commands. The simulation launch enables cameras and lidar:

```sh
roslaunch mins simulation.launch cam_enabled:=true lidar_enabled:=true
```

And the display configuration for rviz is checked in:

```sh
rviz -d mins/launch/display.rviz
```

Because the display file is in the repository, a fresh checkout gives you the same panels and frames the authors used, which saves a lot of guesswork.

## The build matrix has moved ahead of the Dependency section

Here is a documentation inconsistency that will cost you time if you do not notice it. The Dependency section of the README says that MINS is tested on Ubuntu 18 and 20 and only requires the corresponding ROS versions, Melodic and Noetic. That statement is narrower than everything else the project says about itself.

The build badges at the top of the README cover ROS1 Melodic on Ubuntu 18.04, ROS1 Noetic on Ubuntu 20.04, ROS2 Humble on Ubuntu 22.04, ROS2 Jazzy on Ubuntu 24.04, ROS2 Lyrical on Ubuntu 26.04, ROS-free builds on Ubuntu 22.04, 24.04 and 26.04, macOS on arm64, and Windows on x64. The top level directory listing matches: there are Dockerfiles for melodic, noetic, humble, jazzy and lyrical, and separate ones for ROS-free Ubuntu builds, plus a `build_ros2.sh` script.

So the dependency paragraph describes the original ROS1-only target while the project now builds across nine CI configurations. A reader who trusts the paragraph will try to build on a modern ROS2 system and wonder why the instructions do not cover their case. The Dockerfiles are the reliable source, and the ROS-free variants are notable because they show the estimator is not welded to ROS.

That ROS-free path is also the practical answer to anyone who wants the filter without a ROS installation. The trade is that the launch files and the bag tooling are ROS-specific, so the interface you integrate against changes.

## Datasets, evaluation tooling and what the mirrors contain

Running real data is easy because the project supplies the inputs. Directly reading a ros bag is one launch line with a config name, a ground truth path and a bag path:

```sh
roslaunch mins rosbag.launch config:=kaist/kaist_LC path_gt:=urban30.txt path_bag:=urban30.bag
```

The KAIST urban dataset was converted to rosbag files with kaist2bag, and the rights for the underlying data remain with KAIST. The project provides mirrors of the converted rosbags, urban18 through urban39, together with their ground truths, on Hugging Face and on a NAS link.

The ground truth argument is the part that matters for anyone reproducing a result. The launch file takes the truth path explicitly, so the same bag can be evaluated against different truth files, and the evaluation toolbox in `mins_eval/` is what turns a trajectory and a truth file into the consistency, accuracy and timing numbers the paper reports.

The alternative to the bag path is subscribing to live messages:

```sh
roslaunch mins subscribe.launch config:=euroc_mav rosbag:=V1_03_difficult.bag bag_start_time:=0
```

Here the bag is passed to the launcher and a start time is supplied, which is how you evaluate a specific segment of a long recording rather than the whole thing. Both routes point at the same estimator, so the difference is only in how the data reaches it.

The simulation toolbox is the third leg: a multi-sensor simulator for IMU, camera, lidar, GNSS and wheel, enhanced from prior work called OpenVINS. Running synthetic data with known ground truth is the only way to test a configuration change without collecting a new dataset, and for a system with online calibration it is also the only way to check whether a bad calibration is the estimator's fault or the data's.

## GPL-3.0 and vendored third-party code

MINS is licensed under GPL-3.0, with the licence file at the repository root. For a research group evaluating the system this is unremarkable. For anyone planning to embed the estimator in a product, it is the single most consequential fact on this page, and it deserves a conversation with whoever owns the licence in your organisation before the code is copied into a repository.

The details of the grant are a legal question rather than an engineering one, so the useful engineering note is structural: the code lives in `mins/` with the estimator in `mins/src`, its options tree in `mins/src/options`, evaluation code in `mins_eval/`, data handling in `mins_data/`, and the borrowed libraries in `thirdparty/`. Any of those directories is a boundary you may need to reason about separately, since vendored dependencies carry their own terms and the README credits them by name rather than shipping a single consolidated licence file.

The build system reinforces the separation. There are CMake files at the root and per configuration Dockerfiles, a `build_ros2.sh` helper and a `run_format.sh` script, and the project asks contributors to keep formatting consistent through a checked in `.clang-format`. Those are the conventions that make the tree readable for the next group of people, which is the same courtesy you would want from any code you depend on.

The maintenance picture is current: the repository is not archived, and the last push was on 2026-10-20. It publishes no GitHub releases, so version tracking is done through the repository history and the paper rather than through tagged artefacts.

## Conclusion

MINS is worth adopting when your robot carries more than one auxiliary sensor and you want a single tightly coupled estimator with online extrinsic calibration rather than a stack of loosely coupled front ends, and when your group is prepared to build the code and read the options tree in mins/src/options before running it. It is the wrong choice for a fixed, single-sensor rig where a smaller estimator would do, and for a commercial product that cannot carry GPL-3.0 obligations. Verify first that the ROS version on your machine matches a configuration the project ships, since the build instructions cover catkin for ROS1 and separate Dockerfiles for Humble, Jazzy and Lyrical, and note that the Dependency section still names only Ubuntu 18 and 20 with Melodic and Noetic even though CI builds for Ubuntu 22, 24 and 26 and for macOS and Windows.

## FAQ

### Which sensors can MINS fuse together?

MINS is a tightly coupled multisensor-aided inertial navigation system that fuses all five sensing modalities, IMU, wheel encoders, camera, GNSS and LiDAR, in a filtering fashion. The listed use cases include VINS, GPS-IMU, LiDAR-IMU, wheel-IMU and combinations of camera, GPS, lidar and wheel with IMU.

### Does MINS calibrate its sensors online?

Yes. Online calibration of all onboard sensors is listed as a key feature, and the project links exemplary results for it. The estimator also uses a consistent high-order state on manifold interpolation plus a dynamic cloning strategy for light-weight estimation performance.

### How do I build and run MINS on ROS2?

The README points to the Dockerfiles for the ROS2 build instructions and dependencies, one per distribution. After building and sourcing, you can start the simulation with ros2 run mins simulation mins/config/simulation/config.yaml, or the live pipeline with ros2 run mins subscribe mins/config/euroc_mav/config.yaml, and inspect the estimated path in rviz2.

### Which datasets can I use to evaluate MINS?

The project uses the KAIST urban dataset and provides mirrors of the converted rosbags urban18 through urban39 with their ground truths on Hugging Face and a NAS link, and it also points to the euroc_mav dataset for the subscribe example. The evaluation toolbox in mins_eval/ covers consistency, accuracy and timing analysis.

### What licence does MINS use and can I use it in a product?

The repository is licensed under GPL-3.0 and also vendors third-party libraries in the thirdparty folder, including OpenVINS and ikd-tree, which carry their own terms. Whether that combination works for a commercial product is a licence question rather than a technical one, and the README credits the code to the Robot Perception and Navigation Group at the University of Delaware.

## Sources

- [Issues](https://github.com/rpng/MINS/issues)
- [License: GPL-3.0](https://github.com/rpng/MINS/blob/master/LICENSE)
- [README](https://github.com/rpng/MINS/blob/master/README.md)
- [rpng/MINS on GitHub](https://github.com/rpng/MINS)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rpng-mins