KISS-ICP: the install is documented, the parameters are not

Point-to-point ICP shipped as a wheel with one executable

KISS-ICP is a LiDAR odometry pipeline written in C++, published to PyPI under the name `kiss-icp` and driven by a single executable named `kiss_icp_pipeline`. The project's own framing is narrow and worth reading closely: a pipeline that works "on most of the cases without tunning any parameter", typo included. That is a scope limit rather than a promise. Odometry here is frame to frame LiDAR registration, and the method takes its name from the paper title, "KISS-ICP: In Defense of Point-to-Point ICP", printed in IEEE Robotics and Automation Letters in 2023, volume 8, number 2, pages 1029 to 1036, doi 10.1109/LRA.2023.3236571. Anyone wiring LiDAR into a robot and hoping to skip a parameter search is the intended audience, and the repository topics say so in one line: 3d-mapping, icp, lidar-slam, robotics, ros, ros2 and slam.

A config directory the README never opens

The repository root ships a `config/` directory, and the README never names a file inside it, a key, a default value, or a flag for changing registration behaviour. Advanced Python instructions are delegated to `python/README.md`, so tuning lives one level down from the page most readers stop at. That gap is the real cost of the no-tuning claim: either the pipeline works on your sensor, or you go read config files the project never introduces. Nothing is hidden behind a flag here, it is simply absent from the prose. The same silence covers the `eval/` directory in the root listing, for which no evaluation or benchmark command appears anywhere. Meanwhile three badges at the top of the page name Linux, Windows and macOS, so the supported platforms are stated plainly while the supported settings are not.

The pip package compiles the C++ core it ships

Two installation routes reach the same algorithm and they are not the same artefact. From PyPI, one line covers the whole install:

pip install kiss-icp

That command delivers a build of the C++ sources under `cpp/`, and the Makefile shows why: its editable target installs `scikit-build-core`, `pybind11`, `ninja` and `cmake` before installing with `--no-build-isolation`, which puts a C++ toolchain in the install path even for users who never open a C++ file. Formatting is enforced the same way, with `.clang-format`, `.cmake-format.yaml` and `.pre-commit-config.yaml` all committed at the root. `.gitattributes` and `.gitignore` complete a file set typical of a repository whose distributed artefacts are compiled rather than typed. The entry point the install leaves behind is a single executable, and the README asks you to look at it rather than describing it:

kiss_icp_pipeline --help

The resulting help message is published as an image, so no option name inside it appears as text anywhere in the project documentation.

A cmake path with no documented way to run it

The cpp target in the Makefile offers a source-only route for C++ integrators, and it is the whole route:

cmake -Bbuild cpp/kiss_icp/
cmake --build build -j$(nproc --all)

Those two `cmake` lines configure a build directory from `cpp/kiss_icp/` using every core the machine reports. Documentation stops there. No binary name, no launch command, and no sample configuration follows that build anywhere in the README, so a team integrating at the C++ level is left reading the repository. For a team that only needs a pose stream in C++, that silence is the deciding factor: the build is spelled out while the invocation is not. Test coverage is uneven in the same way. `pytest` runs from `./python/` through the Makefile test target, so the suite ships with the Python package, while the C++ tree has no test target at all.

pytest -rA --verbose ./python/

Three spellings of one name across install and run

One codebase, three spellings. PyPI installs `kiss-icp` with a hyphen, the executable `kiss_icp_pipeline` separates each word with a low line instead, and the package colcon selects in a ROS 2 workspace is `kiss_icp`, matching the directory `cpp/kiss_icp/` and the uninstall target that removes `kiss_icp`. Nothing in the documentation maps one spelling onto another, so a wrapper script or a CI job that mixes the hyphen with the separated form breaks before any sensor data is read. Getting that split right is the first thing to check when a launch file runs on a laptop and not inside a container. The removal path adds one more wrinkle, since that same target addresses the distribution as `kiss_icp` while the install line on the file points at a repository path rather than a name.

ROS 2 builds in a workspace while ROS 1 stops at v0.3.0

The ROS 2 path is the most complete command sequence the project offers, a single line that clones the repository into `~/ros2_ws/src/` and builds only `kiss_icp`:

cd ~/ros2_ws/src/ && git clone https://github.com/PRBonn/kiss-icp && cd ~/ros2_ws/ && colcon build --packages-select kiss_icp

ROS 1 is deprecated and no longer officially supported, and ROS 1 users are pointed at `v0.3.0`, a tree that sits far behind the current numbering on `main`. For a team with ROS 1 in production, that is the honest upgrade cost: the old tree is frozen, the pip package and the ROS 2 wrapper are the only moving line, and nothing in the README enumerates what changed between them. Detailed instructions for the wrapper sit behind the linked `ros/README.md`, which the top-level page does not inline, so the migration path is assembled from a root page plus a second one.

The homepage is a paper PDF and the docs are two files

The homepage field for this repository points at the PDF of the RA-L paper hosted by the university, not at a documentation site, so the deepest written account of the method sits outside the tree. The root listing has no docs directory either. Two prose files exist beyond the README, `python/README.md` and `ros/README.md`, each linked as the advanced path for its own audience, and `CITATION.cff` at the root carries the bibliographic record for tooling that reads it. Academic use comes with one explicit instruction, to cite the original paper for any academic work. So the practical documentation set for an adopter is three pages, and one of those three is a paper rather than a manual.

Two install routes can land in one environment

KISS-ICP can arrive in one environment by two documented routes, PyPI or the install target in the Makefile, which runs the following against a clone:

pip install --verbose ./python/

The README does not describe removing one before installing the other, and an uninstall target does exist. Nothing prevents both copies from sitting in a single virtual environment, where the import path and the compiled extension then come from different sources. The MIT licence covers reuse of either form, and the last push landed on 2026-06-09, with the v1.3.0 date at 2026-04-26. Pin whichever route you take and record it, because the project says nothing about the two copies coexisting.

Editorial conclusion

KISS-ICP suits an engineer who wants LiDAR odometry running from PyPI this afternoon and accepts a README that documents no parameters at all. It does not suit a team that needs a documented configuration surface, a recorded evaluation run, or a supported ROS 1 tree. Before adopting it, open config/, run kiss_icp_pipeline --help and read the flags yourself, because the no-tuning claim is scoped to most cases and the thresholds behind it are not written down. Both the install route and the frozen ROS 1 tree are cheap to inspect before either one becomes a dependency.

Frequently asked questions

Official sources

1. License: MIT
2. PRBonn/kiss-icp on GitHub
3. Project website
4. README
5. Releases