hku-mars LiDAR_IMU_Init: Real-Time LiDAR and IMU Calibration
[IROS2022] Robust Real-time LiDAR-inertial Initialization Method.
At a glance
- What is it?
- LI-Init estimates LiDAR to IMU temporal offset, extrinsic parameters, gravity direction and IMU bias before switching to FAST-LIO. It is aimed at robotics developers working with mechanical or solid-state LiDARs in ROS environments.
- Who is it for?
- Engineers who need an online LiDAR and IMU initialization stage should consider LI-Init when their ROS data matches the required topics, units and configuration. It is a poor fit for applications that already have reliable calibration, cannot provide sufficient excitation, or need a deployment outside the documented Ubuntu and ROS setup.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 176 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What LI-Init Solves Before FAST-LIO Runs
LI-Init addresses a specific startup problem in LiDAR-inertial systems: the LiDAR and IMU may not have a known time offset, spatial transform, gravity direction or IMU bias. Without those quantities, a sensor-fusion odometry system can begin with an incorrect model and produce a poor initial trajectory. The repository describes LI-Init as a real-time initialization method that estimates the temporal offset and extrinsic parameters between LiDARs and IMUs, together with the gravity vector and IMU bias. It does not require a target, an extra sensor, a structured environment, a prior point map or initial extrinsic and timing values.
The intended users are robotics developers integrating LiDAR and IMU data under ROS, especially developers working with FAST-LIO2 or systems that need calibration results to be transferred to R3LIVE. The package includes an initialization module and sequential FAST-LIO. After initialization has sufficient excitation, the README says the program reports the estimated extrinsic transformation and temporal offset, then switches into FAST-LIO. This makes LI-Init an online calibration and odometry entry point rather than a standalone configuration utility.
The repository names several sensor families as supported: Hesai, Velodyne and Ouster mechanical spinning LiDARs, plus Livox Avia and Mid360 solid-state LiDARs. The README also says that `livox_avia.launch` theoretically supports mid-70 and mid-40 LiDARs. That wording identifies intended compatibility, but it does not document a complete sensor-by-sensor test matrix. A user should therefore check the launch file and topic configuration for the actual sensor rather than infer that every listed model has identical behavior.
Initialization, FAST-LO and FAST-LIO Data Flow
The documented pipeline has two stages. First, LI-Init processes LiDAR and IMU measurements to assess the data and estimate the calibration quantities. Second, it runs FAST-LIO using the initialized model. The package includes FAST-LO, described in the README as a robust LiDAR odometry component modified from FAST-LIO2. The repository contains implementation files under `include/`, `src/`, `config/`, `launch/`, `msg/`, `python_code/` and `matlab_code/`, but the README does not expose the internal algorithm equations or a complete text description of every processing stage.
Several configuration parameters shape that flow. `lid_topic` and `imu_topic` select the incoming point cloud and inertial measurement topics. `cut_frame_num` splits one input frame into sub-frames to improve odometry frequency. `orig_odom_freq` declares the original LiDAR input frequency. The README recommends a product of `cut_frame_num * orig_odom_freq` equal to 30 for mechanical spinning LiDAR and 50 for Livox LiDARs. These are tuning recommendations, not universal defaults.
The program also evaluates whether the collected data contains enough excitation. It can detect the degree of excitation and instruct the user to rotate or move in a suitable direction. The recommendation to remain still for more than five seconds after launch is tied to building a dense initial map. After initialization, `online_refine_time` controls a FAST-LIO2 refinement period, with approximately 15 to 30 seconds recommended. The result is written to `catkin_ws/src/LiDAR_IMU_Init/result/Initialization_result.txt` after initialization and refinement finish. The README does not document a separate confidence score, covariance report or automatic rollback mechanism for the estimate.
Building LI-Init in a ROS Catkin Workspace
The documented build requires Ubuntu 18.04 or newer, ROS Melodic or newer, PCL 1.8 or newer, Eigen 3.3.4 or newer, `livox_ros_driver` and `ceres-solver`. The README states that the code has been tested on `ceres-solver-2.0.0`. It also provides a Docker starting point in `docker/docker_start.md`, but the README does not reproduce the Docker commands.
The first build uses the clone, `catkin_make` and workspace sourcing sequence documented by the repository:
cd ~/catkin_ws/src
git clone https://github.com/hku-mars/LiDAR_IMU_Init.git
cd ..
catkin_make -j
source devel/setup.bashThe `livox_ros_driver` workspace must be sourced before running any LI-Init launch file, according to the README. The documentation gives this shell line for `.bashrc`:
source $Livox_ros_driver_dir$/devel/setup.bashThe directory placeholder must be replaced with the actual `livox_ros_driver` workspace. The README calls `ws_livox` the expected directory when its official setup instructions were followed completely. Before launching, the operator must inspect the selected YAML file in `config/`, confirm topic names and confirm that IMU angular velocity is expressed in `rad/s`. The README does not provide a separate dependency installation command beyond linking to upstream installation instructions.
First Run with Recorded ROS Data
LI-Init can run against user data, but the launch file and YAML configuration must match the recording. The README recommends using `rosbag info` to inspect topic names before choosing configuration values. This is particularly important for Livox built-in IMUs, whose stationary acceleration norm is documented as 1, and Pixhawk IMUs, for which the documented value is 9.805.
The documented launch workflow is:
cd catkin_ws
source devel/setup.bash
roslaunch lidar_imu_init xxx.launchHere, `xxx.launch` is a placeholder for the launch file selected from `launch/`. The README tells the user to edit `config/xxx.yaml` before running. It does not map every supplied launch file to every supported sensor, so the exact package invocation cannot be determined from the README alone.
For a first recording, the documented guidance is to keep the platform still for more than five seconds after launch, then provide enough rotation or directional movement to produce excitation. The program may report whether the data is sufficient and indicate which motion is needed. After initialization and refinement, inspect `catkin_ws/src/LiDAR_IMU_Init/result/Initialization_result.txt`. The README provides downloadable test bags, but it does not state which calibration result should be expected for each bag. A first run should therefore be treated as a configured experiment whose topic names, sensor configuration and motion coverage are all recorded alongside the output.
Configuration Trade-Offs and Failure Conditions
The main limitation is that successful initialization depends on data quality and configuration correctness. The README explicitly warns that angular velocity must use `rad/s`; degree-per-second input would violate the documented requirement. It also says `data_accum_length` is a threshold for assessing whether enough data exists, and that setting it too small can produce bad-quality results. A launch with incorrect `lid_topic`, `imu_topic`, `mean_acc_norm`, frequency values or filter sizes cannot be treated as a meaningful calibration run merely because the program starts.
The filter settings expose a scene-dependent trade-off. The README recommends `filter_size_surf` from 0.05 to 0.15 meters indoors and 0.5 meters outdoors. It recommends `filter_size_map` from 0.15 to 0.25 meters indoors and 0.5 meters outdoors. Applying indoor settings to a large outdoor scene, or outdoor settings to a small indoor scene, can change the map representation and odometry behavior. The README does not explain the internal filtering criterion or provide an automatic scene detector.
There is also a timing and integration constraint. Initialization produces values for later modules, but the documentation does not describe rollback, confidence intervals, covariance reporting or a formal mechanism for rejecting an estimate before FAST-LIO continues. The result file is the documented inspection point. A deployment requiring independently verified calibration should not assume that an emitted transform has passed a separate validation stage unless the surrounding system performs that verification. This makes LI-Init less suitable when calibration must be completed against a surveyed target or certified measurement process before normal operation begins.
Compatibility, Maintenance and License Implications
The repository is not archived, and its last push was on 2026-04-30. The only listed release is `v1.0` with the `ceres-solver-2.0.0` variant, dated 2022-12-18. The README therefore provides a release anchor but not a documented upgrade policy or migration guide for later `ceres-solver` versions. The explicit upgrade cost is dependency management: the package depends on ROS, PCL, Eigen, `livox_ros_driver` and Ceres Solver, and its configuration must be checked when moving between sensor types or data recordings.
The repository is licensed under `GPL-2.0`. That label identifies the stated software license, but this review does not provide legal interpretation or advice about how a particular deployment, modification or distribution may affect obligations. Teams should review the repository's `LICENSE` file and assess their own integration and distribution situation.
Compared with a workflow that starts FAST-LIO after manually measuring LiDAR and IMU extrinsics and synchronizing timestamps offline, LI-Init performs those tasks as part of a real-time startup process. Compared with calibration approaches that require a target, extra sensor, structured scene or prior map, the documented method does not list those requirements. Manual or offline calibration can be preferable when a deployment already has a surveyed target, controlled motion or an established calibration procedure. LI-Init is more relevant when the system must initialize from sensor motion itself and can meet the documented excitation and configuration requirements.
Editorial conclusion
Engineers who need an online LiDAR and IMU initialization stage should consider LI-Init when their ROS data matches the required topics, units and configuration. It is a poor fit for applications that already have reliable calibration, cannot provide sufficient excitation, or need a deployment outside the documented Ubuntu and ROS setup. Verify the launch configuration, IMU acceleration units and `mean_acc_norm` before judging whether its initialization output is appropriate for FAST-LIO or R3LIVE integration.
Frequently asked questions
What does LiDAR_IMU_Init estimate?
According to the README, LI-Init estimates the LiDAR and IMU temporal offset, extrinsic parameters, gravity vector and IMU bias. It then switches into FAST-LIO after sufficient excitation is provided.
How do I build LiDAR_IMU_Init?
The documented workflow clones the repository into `~/catkin_ws/src`, runs `catkin_make -j`, and sources `devel/setup.bash`. The README also requires Ubuntu, ROS, PCL, Eigen, `livox_ros_driver` and `ceres-solver` as prerequisites.
What should I configure before running LiDAR_IMU_Init?
The README says to check the selected `config/xxx.yaml`, especially `lid_topic`, `imu_topic`, frequency settings, filter sizes and `mean_acc_norm`. IMU angular velocity must be in `rad/s`, and the result is written to `catkin_ws/src/LiDAR_IMU_Init/result/Initialization_result.txt` after initialization and refinement finish.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/hku-mars-lidar-imu-init)Was this useful?