GenZ-ICP: LiDAR odometry that expects degenerate corridors

A robotics lab publishing the code behind the paper

GenZ-ICP is a LiDAR odometry system, and the repository is the reference implementation of a paper rather than a general purpose library.

The paper is GenZ-ICP: Generalizable and Degeneracy-Robust LiDAR Odometry Using an Adaptive Weighting, by Daehan Lee, Hyungtae Lim and Soohee Han, published in the IEEE Robotics and Automation Letters in 2025, volume 10, number 1, pages 152 to 159, with a DOI and an arXiv preprint from November 2024. The keywords the citation gives are Localization, Mapping and SLAM.

The two words in the title carry the argument. Generalizable is the claim about environments, that the same configuration should work in the places a robot actually goes, and degeneracy is the claim about failure, that a corridor or a tunnel gives the optimiser almost nothing to work with, and that most of the published remedies treat the symptom rather than the cause.

The project is built in two languages, with a C++ implementation and a Python one, and it ships ROS 1 and ROS 2 packages, which is the packaging a robotics group needs in order for their students to run it. The repository has a cpp directory, a python directory, a ros directory and a pictures directory, with a clang-format configuration, a cmake-format configuration, a pre-commit configuration and a CITATION.cff file for citation metadata.

The licence field points at a licence file that the hosting platform cannot classify, while the badge in the readme says MIT, and the last push to the repository was on 2026-10-13, with the newest release listed as v0.3.2 from 2026-05-05.

The pip install arrived in May 2026

The distribution story is recent, and the readme dates it.

A note in the header says that on May 19, 2026, pip installation went live, and the command is the ordinary one:

pip install genz-icp

The package is on PyPI, and the entry point is a pipeline command, genz_icp_pipeline, whose help message lists the supported dataloaders and options. The readme also points at a separate readme inside the python directory for the advanced instructions, which is the usual arrangement when the quick start in the top level readme has to stay short.

The dataloader list is the interesting part of that help message. A LiDAR odometry tool is only useful if it can read the format your robot records, and the different robot fleets produce different files, so the set of dataloaders the binary knows about is effectively the set of sensors and bags the project has been pointed at. It is the first thing to check before anything else, because a dataloader that is not there makes the rest of the pipeline irrelevant.

That the Python path was the last thing to arrive is worth noting for anyone reading the repository. The ROS packages and the C++ core are the original artefacts, and the Python package is the wrapper that a user without a ROS installation can actually pip install.

ROS 1 and ROS 2, built with catkin and colcon

The ROS support is the part of the repository that most users will touch, and it is provided for both generations of ROS with two separate, and slightly different, procedures.

For ROS 1, the build is a catkin workspace. The commands create the workspace source directory, clone the repository into it, build the genz_icp package with catkin in release mode, and source the resulting setup script:

mkdir -p ~/catkin_ws/src
cd ~/catkin_ws/src
git clone https://github.com/cocel-postech/genz-icp.git
cd ..
catkin build genz_icp --cmake-args -DCMAKE_BUILD_TYPE=Release
source ~/catkin_ws/devel/setup.bash

For ROS 2, the same shape with colcon, and the build selects the single package and uses symlink installation, which is what makes editing the configuration during development practical:

mkdir -p ~/colcon_ws/src
cd ~/colcon_ws/src
git clone https://github.com/cocel-postech/genz-icp.git
cd ..
colcon build --packages-select genz_icp --cmake-args -DCMAKE_BUILD_TYPE=Release --symlink-install
source ~/colcon_ws/install/setup.bash

The differences run deeper than the tool names. The ROS 1 launch file is odometry.launch and the ROS 2 one is odometry.launch.py, because ROS 2 launch files are Python. The bag format differs too, a .bag file for ROS 1 and a .db3 file for ROS 2. And the ROS 1 build produces a devel directory while the ROS 2 one produces an install directory.

The release build type is set in both cases, which is worth noting because an odometry pipeline built without optimisation is not the pipeline the paper measured.

A topic, and optionally a pre-tuned configuration

Running the pipeline is two commands in both ROS versions, and there are two ways to do it.

With a pre-tuned configuration, the launch file takes the topic and the configuration file:

ros2 launch genz_icp odometry.launch.py topic:=<topic_name> config_file:=<config_file_name>.yaml
ros2 bag play <rosbag_file_name>.db3

With only a topic, the configuration file argument is dropped and the defaults are used. The ROS 1 forms are the same with roslaunch, rosbag play and a .bag file.

The two ways matter more than they look. A configuration file is the accumulated result of tuning the pipeline against a particular sensor and a particular environment, and the repository ships a parameter tuning guide at ros/config/parameter_tuning_guide.md for working out what to change. A pre-tuned configuration that suits the authors' rig will not necessarily suit yours, and the tuning guide is where the parameters and their effects are described.

The repository also points at a readme under the ros directory for examples and download links for demo datasets, which is a practical way to check the pipeline before pointing it at your own robot. The demo bags and the tutorial videos linked in the header are the fastest route to seeing whether the output is the trajectory you expect.

The parameter tuning guide being a first class document rather than a wiki page is a good sign for a project that expects people to tune it, which is the honest expectation for a LiDAR odometry pipeline.

KISS-ICP is the foundation and the community is the plan

The acknowledgements are unusually specific, and they name the code the project stands on.

The thanks go to the KISS team, Ignacio Vizzo, Tiziano Guadagnino and Benedikt Mersch, for providing the LiDAR odometry code, and the readme points at the KISS-ICP project for more information. That is the lineage, and anyone reading the source will recognise it.

The contributors section says something about the project's intentions. Like KISS-ICP, the authors envision GenZ-ICP as a community-driven project, and they say they love to see how the project is growing thanks to the contributions from the community, with an invitation to open a pull request.

The contact details are listed at the end of the readme, and they show the two institutions involved, Daehan Lee at POSTECH and Hyungtae Lim at MIT. That combination explains the range of the release, a robotics laboratory with sensor rigs to test on and a machine learning group with the time to turn a paper into a package other people can install.

The citation block is also careful about a related system. For the LiDAR-inertial odometry extension, the readme asks you to refer to GenZ-LIO, whose paper is GenZ-LIO: Generalizable LiDAR-Inertial Odometry Beyond Confined--Open Boundaries, an arXiv preprint from 2026 with a longer author list.

That distinction matters for a reader choosing between them. GenZ-ICP is the LiDAR-only odometry described in the RA-L paper, and GenZ-LIO is the version that fuses inertial data, with its own preprint and its own repository.

Editorial conclusion

GenZ-ICP fits a robotics team whose LiDAR keeps losing track in a corridor, a tunnel or a long empty hall, because the paper's argument is that those failures come from geometry rather than from noise, and the code comes with three surfaces, a C++ core, a Python pipeline and the ROS launch files. It is the wrong choice if you need a turnkey SLAM stack, because this is odometry, and the sibling GenZ-LIO paper is the one that adds inertial data. It is also the wrong choice if you cannot read the parameter tuning guide, since the pre-tuned configurations are the difference between a working run and a diverging one. Before you deploy it, work through the parameter tuning guide for your sensor, check the launch file names for your ROS version, and note that the Python package only became installable with pip in May 2026.

Frequently asked questions

Official sources

1. cocel-postech/genz-icp on GitHub
2. Issues
3. README
4. Releases