Super-LIO runs a Livox mapping stack on ROS 2 and keeps a ROS 1 branch alive

The ROS 1 branch is where the older stack still lives

The repository layout is a small statement about maintenance priorities. The default branch is ros2, and the README marks it as the active one, covering ROS 2 Humble, Iron and Jazzy. A separate branch named ros1 holds the ROS 1 Noetic version, and the instructions for ROS 1 users are to switch to that branch and follow the instructions there. The update log explains how the split happened. On 2026-01-04 the main branch was renamed to ros1, the ros2 branch was added, and the ROS 2 version was released the same day. Separately on 2026-01-04 the ROS interface and the algorithm were separated, SuperLIOReLoc was refactored to inherit from SuperLIO, and the code style was aligned with the ROS 2 version. In other words, the ROS 1 line is a preserved state of the project rather than a port, and anyone who needs Noetic should expect to work inside that branch without the later fixes.

Dependencies are two apt packages, and the rest is standard ROS

The requirements line is short, which is a good sign for adoption. It asks for Ubuntu 24(22).04, C++20, ROS Jazzy or Humble, Eigen and PCL. The additional dependencies beyond the ROS stack are glog and TBB, and they install with a single command.

sudo apt install libgoogle-glog-dev libtbb-dev

TBB is the one worth understanding rather than just installing, because the system is described as achieving predictable correspondence search, and Intel's threading building blocks are what you reach for when the correspondence search is the part you want to keep predictable rather than merely fast. Eigen handles the linear algebra and PCL handles the point cloud handling, both of which are unremarkable in a LiDAR stack and both of which are versions your ROS distribution already brings. C++20 as a requirement narrows which compiler you can use, and the platform badges in the README indicate X86 and ARM64 support, which matters because ARM64 is the common case for the embedded boards people actually put these sensors on.

Building is colcon, running is a launch file named after the sensor

The build and run sequence is the standard colcon workflow, which means nothing about it is specific to this project, and the specifics come from the launch file you choose.

git clone https://github.com/Liansheng-Wang/Super-LIO.git
cd Super-LIO
colcon build
source install/setup.bash
ros2 launch super_lio Livox_mid360.py

The launch file name is the configuration surface. Livox_mid360.py names a specific Livox sensor, so the shipped configurations are per-sensor, and adding your own means writing a launch file for your model rather than tuning a generic entry. The package name in the launch command is super_lio, written with an underscore character, while the repository and project names use hyphens, which is worth noting if you script around it. The source directory at the top level of the repository is src/, and the docs/ directory holds the system overview diagram that the README leans on to explain the architecture, so the algorithm structure is documented as a picture rather than as prose.

Relocalization reuses a saved map instead of remapping

The relocalization mode is the feature most deployments will care about, and it works by loading a map that was previously saved to disk. The stated prerequisite is simple and worth restating: before running relocalization, a map must have been previously saved to disk. The mode exists to let the system resume localization from a saved map without restarting the mapping process, and the documented use cases are long-term deployment, repeated missions, and recovery after tracking loss.

cd PATH_2_Super-LIO
source install/setup.bash
ros2 launch super_lio relocation.py

The separation of SuperLIOReLoc from SuperLIO, with the re-localizer refactored to inherit from the main class, is what makes this a mode rather than a separate product. That inheritance also means the two share the front end, so improvements to the estimator reach both. The recovery after tracking loss case is the strongest argument for it, because without a saved map a lost track means starting over, and with one the system can place itself again. The gap in the documentation is that the README does not describe how the map file is produced or how the saved map is matched against live scans, so that part is a code reading exercise.

The dataset section is an open TODO

The evaluation section is the weakest part of the project as published. The README states that Super-LIO is evaluated on multiple real-world datasets covering diverse environments, including indoor, outdoor and large-scale scenes, and then says plainly that dataset download links and detailed descriptions will be provided in the future. The datasets are therefore promised rather than delivered, which leaves a reader with the paper and the code. The performance claims in the overview are correspondingly hard to check from the repository alone. The project states that it maintains lower resource consumption and realizes a nearly 1.2 to 4 times higher real-time processing speed than the state of the art it compares against, and the system is described as validated through extensive real-world experiments and comparisons. Those are the authors' own figures from their own experiments, and with no datasets or scripts in the repository, the honest reading is that the claim is not independently reproducible from what is published here. Anyone planning a vehicle deployment should treat the speedup range as something to confirm on their own hardware and their own sensor.

The paper is the stable part of this project

This repository is anchored to a publication rather than to a release. The work has been accepted to IEEE Robotics and Automation Letters for 2026, and the README asks users to cite the paper if the library is useful, providing the citation in LaTeX form with the article title, the six authors, the journal, the year 2026, volume 11, number 3, pages 2666 to 2673 and a DOI. There is an arXiv entry as well, and the corresponding IEEE document is linked. The contributors are Liansheng Wang, Xinke Zhang, Chenhui Li, Dongjiao He, Yihan Pan and Jianjun Yi, and the project carries a GPL-3.0 licence, which is the right choice for robotics research code that others build on. The repository has no GitHub releases, so there is no versioned artefact and no changelog beyond the update log section, and the last push to the ros2 branch was on 2026-07-13. There is a README request to cite and support the project with a star, which is a reasonable request for academic work but is not a substitute for a release cadence.

Editorial conclusion

Super-LIO suits robotics teams already running ROS 2 on x86 or ARM64 who need a Livox compatible LiDAR-inertial odometry stack and are willing to tune it on their own data, since the project ships code rather than a curated dataset. It does not suit anyone who needs ROS 1 as the main target, because that lives on a separate branch, and it does not suit people expecting reproduction numbers out of the box, since the dataset section is an open TODO and the reported speedup is the authors' own claim. Before adopting it, install libgoogle-glog-dev and libtbb-dev, run ros2 launch super_lio Livox_mid360.py on your own sensor, and read the 2026-06-07 update log entry, which is where the algorithm accuracy changes are described.

Frequently asked questions

Official sources

1. Issues
2. Liansheng-Wang/Super-LIO on GitHub
3. License: GPL-3.0
4. README