KISS-SLAM: a LiDAR SLAM system that installs with one pip command

One pip install instead of a robotics toolchain

KISS-SLAM is a 3D LiDAR SLAM system from PRBonn, the group at the University of Bonn, and the claim in the README is deliberately modest: it just works. The practical evidence for that is the install step, which is a single command:

pip install kiss-slam

That matters more than it might sound. LiDAR SLAM stacks are usually assembled from several separate libraries that must be built, matched and configured, and the usual failure mode is a dependency that will not compile on the target machine. Here the Python side pulls in a compiled core and the user gets a working command line tool.

The audience is a robotics researcher or engineer who needs odometry and mapping from a LiDAR and does not want to spend a week on the build. The repository classifiers describe the intended audience as developers, education, other audiences and science or research, and the licence is MIT.

The homepage is the IROS 2025 paper PDF, and the citation is a real constraint rather than a formality. The bibliography asks that any academic use cites the original paper, and the paper lists the authors as Tiziano Guadagnino, Benedikt Mersch, Saurabh Gupta, Ignacio Vizzo, Giorgio Grisetti and Cyrill Stachniss, published in the 2025 IEEE/RSJ International Conference on Intelligent Robots and Systems with pages 5363-5370.

The project is community driven, the README says so, and pull requests are the stated route for contributions.

The Python package wraps a C++ core built with scikit-build-core

The repository layout shows a hybrid project: a kiss_slam/ Python package, a CMakeLists.txt, a Makefile, a pyproject.toml and a .clang-format file.

The build system is scikit-build-core with pybind11, which is the modern way to ship compiled extensions inside a Python wheel. The pyproject.toml lists the build requirements as scikit_build_core and pybind11 with the build backend scikit_build_core.build, and the scikit-build section sets a build directory, requires a minimum CMake version of 3.22, and turns on editable rebuilds with a redirect mode. The Makefile has an install target that pip installs the project verbosely, an uninstall target, an editable target that installs the build tooling and then installs the project with no build isolation, and a cpp target that configures and builds with CMake in parallel.

The Python dependency list is short and tells you what the system actually uses: kiss-icp at 1.2.3 or newer, map_closures at 2.0.2 or newer, open3d at 0.19.0 or newer, numpy, PyYAML, pydantic 2, tqdm and pydantic-settings. The use of pydantic and pydantic-settings for the configuration means a malformed config is caught with a typed error rather than a silent misparse, and tqdm gives progress bars over what are often long point cloud operations.

Two console entry points are registered. kiss_slam_pipeline points at kiss_slam.tools.cli:run and kiss_slam_dump_config points at kiss_slam.config.config:write_config. That naming is a bit of a trap, because the package name is kiss-slam while the CLI commands use underscores, kiss_slam_pipeline and kiss_slam_dump_config.

Generating a config and tuning it for indoor rooms

The configuration workflow is the part of the system a new user touches first, and it starts with a command that writes a default file:

kiss_slam_dump_config

The README notes that this generates a kiss_slam.yaml file, and that you can then modify the parameters and pass the file to the --config option when running the kiss_slam_pipeline. So the sequence is: dump a default, edit it, run the pipeline with the edited file.

Two parameters are called out specifically for indoor applications. The first is odometry.preprocessing.max_range, which should be reduced to 50.0, and the note explains that this automatically reduces the voxel_size to 0.5. The second is local_mapper.splitting_distance, which should be reduced to a distance suitable to the scale of the indoor environment.

The reasoning behind these two is worth spelling out because it shows the shape of the system. max_range controls how far from the sensor points are considered at all, and indoor spaces have walls close by, so keeping distant returns out of the odometry avoids feeding the estimator sparse, irrelevant geometry. Reducing it in turn reduces the voxel_size, which is the resolution of the downsampled cloud the estimator works on. A smaller voxel means more points per volume and more detail retained, at a cost in processing time.

The splitting_distance in the local mapper controls how the map is divided into pieces, and in a small room the default scale is likely too coarse. The README gives no numeric default for either value, so the practical approach is to dump the config, read what the defaults are, and adjust from there rather than guessing.

Developer install and the paper tag

For development, the README gives a separate path that installs the system toolchain first and then does an editable install of the cloned repository:

sudo apt install git python3-pip libeigen3-dev libsuitesparse-dev
python3 -m pip install --upgrade pip
git clone https://github.com/PRBonn/kiss-slam.git
cd kiss-slam
make editable

The apt line is not incidental. libeigen3-dev is the Eigen linear algebra headers and libsuitesparse-dev is SuiteSparse, and both are header-only C++ dependencies of the g2o optimisation library that this system builds on. Their presence in the developer install list tells you that a source build of the core needs them, and that the plain pip install path is the one that avoids that requirement by way of a prebuilt wheel.

The developer install also upgrades pip first, which matters because the editable target installs with no build isolation, so the build backend has to be present in the ambient environment. The Makefile's editable target makes that explicit by installing scikit-build-core, pyproject_metadata, pathspec, pybind11, ninja and cmake before the project itself.

The other developer-facing command is for reproducing the published numbers. Because the team continued developing past the scope of the IROS paper, they created a git tag so researchers can consistently reproduce the results in the publication, and the checkout is a single command:

git checkout IROS25

That is a thoughtful detail. A SLAM paper's tables are only meaningful if you can get the exact code that produced them, and the tag freezes the state for that purpose while main keeps moving.

What KISS-SLAM inherits and what it leaves out

The acknowledgements section names the three projects this system builds on, and reading them tells you both its strengths and its boundaries.

KISS-ICP provides the odometry core, MapClosures provides loop closure, and g2o provides the graph optimisation. The consequence for a user is that the odometry quality, the loop closure behaviour and the pose graph solver are all inherited behaviours rather than novel contributions here. What this repository adds is the integration, the configuration surface and the pipeline that puts them together, packaged so it can be installed rather than assembled.

The project describes itself as a simple, 3D LiDAR SLAM system. Read strictly, that means odometry plus mapping, with the pieces that turn a stream of scans into a trajectory and a local map. The release history shows v0.0.1 in March 2025 and v0.0.2 in May 2025, so the version numbering is still early, and the repository has not published a release since, even though the last push was on 2026-08-11.

If your requirement is a full mapping stack, with global optimisation over many sessions, map merging, or the sensor support that comes with a mature suite, this is the wrong size of tool. The honest framing is that it is a small, well packaged, citable core from an academic group whose other projects cover the wider problem space, and the dependencies it lists are where the rest of that space lives.

Verifying the help output before you trust the run

The README suggests a specific first move, and it is a good one. After installing, type:

kiss_slam_pipeline --help

The README says this should print a help message, and the repository carries a screenshot of what that output looks like. Checking the help text before anything else confirms that the entry point is on your PATH, that the console script was generated correctly by the packaging, and that the command names match what you expect.

That last point is worth a moment of attention. The package on PyPI is kiss-slam, the module directory is kiss_slam/, and the commands are kiss_slam_pipeline and kiss_slam_dump_config, spelled with underscores. Nothing in the naming makes the mapping obvious, and a mismatch here produces a command not found error that is easy to misread as a broken install.

The last push to the repository was on 2026-08-11, and the project is not archived, so the code continues to change after the v0.0.2 release that is on PyPI. If you need the published results, use the IROS25 tag, and if you need current behaviour, work from a clone and install in editable mode, which is the path the developer install section describes.

Editorial conclusion

Adopt KISS-SLAM if you need a working 3D LiDAR SLAM stack for robotics research and want an install that is a single pip command rather than a robotics toolchain assembly. Do not adopt it if you need loop closure, multi-session mapping or the other features a full SLAM suite offers, since the project describes itself as a simple system and leaves the larger scope to other work. Verify first that your LiDAR input matches what the odometry preprocessing expects, that you set odometry.preprocessing.max_range and local_mapper.splitting_distance for your environment as the README suggests for indoor work, and that the pip wheel builds on your platform, since the package needs a C++ toolchain behind scikit-build-core.

Frequently asked questions

Official sources

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