Open-source project
hku-mars/Point-LIO avatar
hku-mars/Point-LIO

Point-LIO: High-Bandwidth LiDAR-Inertial Odometry on ROS

High-Bandwidth LiDAR Inertial Odometry

1,364 stars222 forksC++NOASSERTION

At a glance

What is it?
Point-LIO is a C++ LiDAR-inertial odometry package for ROS environments that require high-rate pose output, LiDAR mapping, and operation under fast motion or IMU saturation. It depends on synchronized point-level timestamps, calibrated extrinsics, and hardware-specific IMU settings.
Who is it for?
Adopt Point-LIO when synchronized LiDAR and IMU data, point-level timestamps, ROS Noetic, and correct hardware calibration are available. Do not choose it as a turnkey LiDAR-only or generic SLAM package without confirming those conditions.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 132 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 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Point-LIO's Odometry and Mapping Scope

Point-LIO addresses simultaneous localization and mapping with LiDAR and inertial measurements, with particular attention to high-rate odometry output. The README describes output at 4k to 8kHz and says the package is intended for autonomous tasks such as trajectory planning, control, and perception. Those use cases include high-speed vehicle motion, severe vibration, high angular or linear velocity, and feedback systems that need frequent pose updates. The repository contains C++ source, ROS launch files, configuration files, message definitions, and an RViz configuration, so it is presented as a ROS package rather than a standalone command-line estimator. The documentation also identifies simultaneous LiDAR localization and mapping without motion distortion as a core capability. That combination is different from a system that publishes only a transform between two scans: Point-LIO is intended to combine LiDAR observations with IMU input and produce an odometry stream suitable for downstream autonomous tasks. The package does not claim a universal sensor interface. Its direct run instructions are for Livox devices, especially Avia and other Livox series, through `livox_ros_driver`.

Synchronized Point Data and IMU Configuration

The most important data-flow requirement is synchronization between the LiDAR and IMU. The README explicitly warns that these sensors must be synchronized. It also states that Point-LIO processes data at the sampling time of each LiDAR point, which explains why point-level timestamps are not optional metadata. For supported Livox data, the driver launch `livox_lidar_msg.launch` produces the `livox_ros_driver/CustomMsg` structure that carries the timestamp for each point. The README says that `livox_ros_driver` must be installed and sourced before running Point-LIO launch files. Configuration is not generic because the YAML must describe the actual hardware. The documentation calls for LiDAR and IMU topic names, the transform from LiDAR to IMU, IMU acceleration and gyroscope saturation values, and the acceleration norm in the unit used by the IMU. The extrinsic convention is specific: Point-LIO defines `extrinsic_T` and `extrinsic_R` as the LiDAR pose in the IMU body frame, with the IMU treated as the base frame. The rotation input is limited to a rotation matrix. If extrinsics are known, the README recommends setting `extrinsic_est_en` to `false`. If the package must estimate them, the documentation points to the separate `LiDAR_IMU_Init` project.

Building Point-LIO in a ROS Catkin Workspace

bash
cd ~/$A_ROS_DIR$/src
git clone https://github.com/hku-mars/Point-LIO.git
cd Point-LIO
git submodule update --init
cd ../..
catkin_make
source devel/setup.bash

The driver workspace must also be sourced before building and running Point-LIO. The README gives this environment line for `~/.bashrc`, with the driver directory placeholder already used by its instructions:

bash
source $Licox_ros_driver_dir$/devel/setup.bash

For a custom PCL build, the README says to add the following export to `~/.bashrc`:

bash
export PCL_ROOT={CUSTOM_PCL_PATH}

After sourcing the catkin workspace and driver workspace, the package can be launched with a supported Livox configuration.

Running Point-LIO with Livox Avia Data

The direct run procedure has two launch processes. One starts the Point-LIO mapping node, and the other starts the Livox driver. The driver should be launched after the device is connected and configured according to the Livox driver documentation. For an Avia unit, the documented commands are:

bash
cd ~/$Point_LIO_ROS_DIR$
source devel/setup.bash
roslaunch point_lio mapping_avia.launch
roslaunch livox_ros_driver livox_lidar_msg.launch

The launch file name does not limit the software to Avia hardware. The README says `mapping_avia.launch` theoretically supports Mid-70, Mid-40, and other Livox series devices, but the relevant YAML values must be set first. The driver launch choice is narrower. Point-LIO relies on the per-point timestamp structure produced by `livox_lidar_msg.launch`; the README says `livox_lidar.launch` does not produce the required data. A useful diagnostic is the warning `Failed to find match for field 'time'.` The documentation associates that warning with missing point timestamps in the rosbag or input stream. Since Point-LIO processes each LiDAR point at its sampling time, this warning identifies a data compatibility problem rather than a minor formatting issue. For a custom frame rate, the README directs users to change `publish_freq` in `livox_lidar_msg.launch` and rebuild the driver package.

IMU Saturation, Gravity, and Downsample Trade-offs

Point-LIO is designed for cases where inertial data can saturate or the platform is exposed to aggressive motion, but that feature depends on configuration rather than automatic sensor discovery. The YAML values `satu_acc`, `satu_gyro`, and `acc_norm` must match the IMU manufacturer’s saturation values and acceleration units. The README specifically reports motion at 75 rad/s in its test, while also cautioning that the sensor configuration must be supplied accurately. These claims describe the project documentation, not an independent performance result. Output frequency is another explicit configuration choice. The README says that `publish_odometry_without_downsample` should be set to `true` when high-rate output is required without downsampling. This can produce `TF_REPEATED_DATA` warnings because adjacent odometry messages may be closer in time than the TF consumer expects. The documentation gives a separate branch of `geometry2` intended to reduce that warning frequency. This workaround changes logging behavior, not the estimator’s fundamental sensor requirements. LiDAR-only operation is also supported. In that case, the README specifies `imu_en` set to `false`, a predefined `gravity_init` value, and `use_imu_as_input` set to `0`. That mode removes the inertial input but requires the user to supply the gravity assumption.

Maintenance, Licence, and Adoption Boundaries

The repository is not archived, and its last push was on 2026-06-13. That date indicates recent repository activity within the six-month window used for this review, but the project has no GitHub releases, so there is no release stream or published upgrade path to rely on. Users should expect to build from the default branch and inspect repository changes directly. The repository metadata identifies the primary language as C++ and lists the default branch as `point-lio-with-grid-map`. The repository includes a top-level `LICENSE`, and the repository metadata classifies it as a custom licence that GitHub cannot categorize. This review cannot state redistribution or modification permissions beyond that classification. The absence of a release history also means that compatibility between the Point-LIO package, `livox_ros_driver`, PCL, ROS, and YAML configuration should be checked directly. The README links to the Point-LIO paper in Advanced Intelligent Systems with DOI `10.1002/aisy.202200459`, but the source package does not provide a separate support policy or a documented migration procedure for configuration changes.

Editorial conclusion

Adopt Point-LIO when synchronized LiDAR and IMU data, point-level timestamps, ROS Noetic, and correct hardware calibration are available. Do not choose it as a turnkey LiDAR-only or generic SLAM package without confirming those conditions. The first checks should be the sensor synchronization, the `time` field in incoming messages, and the YAML values for IMU units, saturation, gravity, topics, and extrinsics.

Frequently asked questions

What does Point-LIO require before it can process LiDAR data?

The README requires synchronized IMU and LiDAR data when IMU input is enabled. Point-LIO also needs the timestamp for each LiDAR point, supplied through the supported `livox_ros_driver/CustomMsg` data structure.

Which ROS and operating system versions does Point-LIO document?

The documented environment is Ubuntu 20.04 with ROS Noetic. The README warns that Ubuntu 18.04 and earlier versions have environment problems and should be avoided.

Can Point-LIO run without an IMU?

Yes. The README says to set `imu_en` to `false`, provide a predefined `gravity_init` value, and keep `use_imu_as_input` set to `0`.

Official sources

  1. hku-mars/Point-LIO on GitHub
  2. Issues
  3. README
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.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/hku-mars-point-lio.svg)](https://hysenlabs.com/projects/hku-mars-point-lio)

Was this useful?