FAST-LIVO2: direct LiDAR-inertial-visual odometry for ROS 1 robots

The problem FAST-LIVO2 targets: odometry when one sensor drops out

A LiDAR-only odometry system degrades in a featureless corridor. A visual system degrades in low light or against a blank wall. FAST-LIVO2 is built for the case where neither sensor alone is enough and the platform still needs a pose estimate. The README describes it as a "LiDAR-inertial-visual fusion localization and mapping system," with the stated aim of real-time 3D reconstruction and onboard robotic localization in severely degraded environments. That framing matters: the project is not a general SLAM toolkit for indoor mapping with a single depth camera. It expects three sensor streams, LiDAR, IMU and camera, and it expects them on a moving robot. The intended user is a robotics researcher or engineer who has a calibrated multi-sensor rig, runs ROS 1, and needs metric pose output rather than a point cloud alone. The repository topics list includes lidar-slam, sensor-fusion, colored-point-cloud and gaussian-splatting, which shows the downstream uses the authors have in mind: reconstruction and novel-view work that consumes the fused trajectory, not just navigation. If you have only a LiDAR and an IMU, this is more machinery than you need; a LiDAR-inertial system will be simpler to calibrate and debug.

How the direct fusion works and what the data flow looks like

The word "direct" in the title is the design decision worth understanding. The system operates on raw sensor measurements in a tightly coupled estimator rather than extracting and matching hand-crafted features first. LiDAR points, IMU preintegration and image photometric residuals all enter the same optimization, which is why the repository ships a camera model library. The README states that Vikit "contains camera models, some math and interpolation functions that we need," and that it must be downloaded into the catkin workspace source folder. That dependency is the clearest architectural signal in the repository: camera projection and interpolation happen inside the estimator, so the camera model is not an afterthought bolted onto a LiDAR pipeline.

The repository layout reflects the same split. There are config/, launch/, include/, src/, rviz_cfg/ and scripts/ directories at the top level. The launch files drive the examples, the config directory holds the YAML that carries extrinsics and sensor parameters, and rviz_cfg supplies visualization presets. The README points to FAST-Calib as the recommended way to obtain LiDAR-camera extrinsics and says its output can be filled directly into the YAML file, which tells you where the calibration boundary sits: the project consumes extrinsics, it does not estimate them for you. The accompanying paper, "FAST-LIVO2: Fast, Direct LiDAR-Inertial-Visual Odometry," is the reference for the estimator itself, and a second paper covers the resource-constrained variant. The README does not document the internal state vector, the marginalization strategy or the failure recovery behaviour, so anyone evaluating the estimator on those grounds has to read the papers rather than the repository.

Installing FAST-LIVO2 and running the Avia example

The README targets Ubuntu 18.04 to 20.04 with ROS 1, plus PCL 1.8 or newer, Eigen 3.3.4 or newer, and OpenCV 4.2 or newer. Two dependencies are non-standard and both are installed separately. Sophus must be the non-templated, double-only version at a specific commit, which the README pins:

git clone https://github.com/strasdat/Sophus.git
cd Sophus
git checkout a621ff
mkdir build && cd build && cmake ..
make
sudo make install

Vikit is a catkin package, so it goes into the workspace source folder rather than being installed system-wide. The README notes this is a different fork from the one used in FAST-LIVO 1:

cd catkin_ws/src
git clone https://github.com/xuankuzcr/rpg_vikit.git

With both in place, clone FAST-LIVO2 alongside them and build the workspace:

cd ~/catkin_ws/src
git clone https://github.com/hku-mars/FAST-LIVO2
cd ../
catkin_make
source ~/catkin_ws/devel/setup.bash

A successful catkin_make produces the fast_livo package and its launch files. To run the published example, download FAST-LIVO2-Dataset, which the README links from the Global-LVBA repository, then start the mapping launch file and play the bag in a second terminal:

roslaunch fast_livo mapping_avia.launch
rosbag play YOUR_DOWNLOADED.bag

The mapping_avia.launch file is the only run example the README gives, and it is tied to the Avia sensor configuration. Expect to edit the YAML in config/ before this works on your own hardware, because the extrinsics and camera model have to match your rig. The README does not document what a healthy run looks like in rviz, so the rviz_cfg presets are the practical starting point.

Where FAST-LIVO2 breaks down or is the wrong choice

The most concrete constraint is the platform range. Ubuntu 18.04 to 20.04 with ROS 1 is stated plainly in the prerequisites, and there is no ROS 2 branch mentioned in the README. On a machine running Ubuntu 22.04 with ROS 2 Humble, the catkin_make workflow does not apply, and the pinned Sophus commit and the catkin-only Vikit fork are both awkward to port. That is a real cost, not a documentation gap.

Synchronization is the second boundary. The README points to the authors' own handheld device repository, LIV_handhold, which it describes as "hard-synchronized" and which includes CAD files, the synchronization scheme, STM32 source code and wiring instructions. The fact that the authors open-sourced a hardware synchronization design alongside the algorithm is a strong hint about how much the fusion depends on tight time alignment. If your camera and LiDAR are triggered independently and you plan to reconcile timestamps in software, the direct photometric residuals are the part most likely to suffer, and the README offers no guidance on tolerance.

Calibration is the third. The system consumes extrinsics from a YAML file, and the README recommends FAST-Calib to produce them. If your camera is rolling shutter, or your LiDAR and camera have a non-trivial lever arm that you cannot measure, the project gives you no fallback. It is also the wrong tool if you want a permissive licence: the code is GPLv2, and the README directs commercial users to email the authors about an alternative licence. Finally, the repository carries no tagged releases in the metadata reviewed here, so you cannot pin a version; you track the main branch.

FAST-LIVO2 against LiDAR-inertial-only pipelines

The natural alternative is a LiDAR-inertial odometry system that omits the camera entirely, which is what the same lab's earlier FAST-LIO line represents. The difference is not a matter of tuning. A LiDAR-inertial system estimates pose from geometric residuals between scan points and a map, and it needs no photometric model, no camera intrinsics and no LiDAR-camera extrinsics. That removes the hardest calibration step and the Vikit dependency, and it removes the failure mode where a bad extrinsic silently biases every image residual.

What it also removes is the information a camera provides when geometry is thin. A wall with no depth variation gives a LiDAR-inertial system little to constrain along the wall plane; image texture can still constrain it. FAST-LIVO2 exists to exploit exactly that complementarity, and the README's emphasis on degraded environments is consistent with it. The trade is complexity for coverage. If your scenes are geometrically rich and your platform is stable, the LiDAR-inertial route is less to calibrate and less to break. If you are flying or driving through corridors, tunnels or open spaces where one modality goes quiet, the extra sensor earns its keep. The second paper on resource-constrained platforms is the place to look if compute is the limiting factor rather than sensor coverage.

Licence terms and the real upgrade cost

FAST-LIVO2 is released under GPLv2. That is a copyleft licence, so if you distribute a product that links this code, the terms of the GPL apply to the distributed work. The README anticipates this and states that for commercial use you should contact the authors, listing two addresses, to discuss an alternative licence. Nothing in the repository suggests a dual-licence file or a separate commercial grant, so the alternative is a negotiation, not a checkbox. This is not legal advice; if you are building a product, the licence question is the first thing to settle, before you spend time on calibration.

Upgrade cost is shaped by the absence of tagged releases. The repository metadata reviewed here lists no releases, and the README's news section records the code release on 2025-01-23 as the notable event. Without version tags, updating means pulling main and rebuilding, and the pinned Sophus commit plus the catkin-only Vikit fork mean a dependency change can ripple through both. The repository was last pushed on 2026-03-08, so the code has been stable for months rather than moving under you, but that also means any fix you need is something you write yourself. Budget for the estimator to be a component you maintain, not a dependency you consume.

Editorial conclusion

Adopt FAST-LIVO2 if you already run ROS 1 on Ubuntu 18.04 or 20.04, have a LiDAR, IMU and camera that are hard synchronized, and want direct LiDAR-inertial-visual odometry rather than a loosely coupled pipeline. Do not adopt it if you are committed to ROS 2, if your sensors are not time-synchronized, or if you need a permissive licence for a closed product, since the code is GPLv2 and commercial use requires contacting the authors for an alternative. Before committing, verify that your camera intrinsics and LiDAR-camera extrinsics can be produced in the format the YAML file expects, and confirm that your Ubuntu version matches the 18.04 to 20.04 range the README states, because that constraint decides whether the build even starts.

Frequently asked questions

Official sources

1. hku-mars/FAST-LIVO2 on GitHub
2. Issues
3. License: GPL-2.0
4. README