open3d_slam: a point cloud SLAM library built to be read

What makes this SLAM library different from the others

Most SLAM libraries are built to work on real vehicles, which means they fuse every sensor available, carry years of accumulated tuning, and resist being read end to end. open3d_slam takes the opposite position, and the project says so plainly.

The stated difference is that open3d_slam was designed to be simple and used for education purposes, and it uses only well-established algorithms in their basic form. The stated goal is that this makes it easier for newcomers to enter the field. That is a design constraint rather than a slogan, and it explains most of what follows in this article.

Two consequences follow directly from that constraint. The input is point clouds, and the project states that no additional input such as IMU is required. And the system can do three things: build a map from scratch, localize in a given map, and extend a given map with new measurements.

Those three modes are the ones a student needs to understand about SLAM, and having all three in one codebase with one set of concepts is what makes the library educational rather than merely small.

The implementation is based on Open3D, described as a well-maintained and highly performant library for 3D data processing. So the heavy lifting in geometry and point cloud handling sits in a separate, actively maintained dependency, and the code here is the part you are meant to read.

The directory layout splits the system into four pieces

The top level of the repository holds five directories and a handful of files, and the split tells you how the system is organised.

open3d_slam/ is the library itself, the C++ code you would read to understand mapping and localization. open3d_utils/ sits next to it as a utility layer. open3d_catkin/ holds the catkin wrapper for Open3D, provided so that Open3D can be used in ROS projects, with its own README for details. ros/ holds the ROS side of the integration.

The documentation/ directory contains the project documentation and the images used in the README, and the separate documentation site is at open3d-slam.readthedocs.io, where the documentation and example datasets live.

There is also a .clang-format file at the root, which tells you the project uses an enforced C++ formatting style, and a pyproject.toml at the root even though the library itself is C++.

The pyproject.toml is worth a closer look because it is not what you would expect. The build backend is flit_core with the requirement flit_core >=3.2,<4, the project name is open3DSLAM, and both version and description are declared dynamic. The author entry names the open3d_slam authors with the same contact address as the README. There are no dependencies listed, which fits a project whose real dependencies are the Open3D library and a ROS installation rather than Python packages.

For a newcomer, the reading order follows the directory names: start in open3d_slam for the algorithm, then open3d_utils for the helpers, then ros/ and open3d_catkin/ for how it is wired into a robot.

Mapping, localizing and extending a map from one codebase

The three operating modes of the library deserve to be separated, because they exercise different parts of a SLAM system and each one is a natural first exercise.

Building a map from scratch is the case where the robot has no prior knowledge of the environment. The system consumes point clouds as it moves, registers them against each other, and produces a map. This is the mode where the front end, the keyframe or scan matching logic, and the graph optimisation all participate.

Localizing in a given map is the case where the map already exists and the robot needs to know where it is inside it. The difference in computational character is real, since localization does not have to build or extend the map, only place the current observation within it. The README is careful to state that the system can localize in a given map rather than implying that the two modes are the same code path.

Extending a given map with new measurements sits between them. The map is loaded and then updated as new data arrives, which is what you want for a mapping session that spans several runs or a site that changes gradually.

What is not mentioned anywhere in the documentation is worth noting too. There is no mention of loop closure being optional, no sensor model beyond the point cloud, no IMU or wheel odometry integration, and no covariance or uncertainty estimate exposed in the interface description. For a library whose stated purpose is education, that simplification is the feature rather than a gap. But anyone planning to run it on hardware should not expect the feature list of a production SLAM stack.

Citing the work, and what the release tags say about ROS versions

The README asks that if you find the work useful, or use it for your research, you cite the corresponding work. The citation is given in BibTeX form:

@inproceedings{jelavic2022open3d,
  title={Open3D SLAM: Point Cloud Based Mapping and Localization for Education},
  author={Jelavic, Edo and Nubert, Julian and Hutter, Marco},
  booktitle={Robotic Perception and Mapping: Emerging Techniques, ICRA 2022 Workshop},
  pages={24},
  year={2022},
  organization={ETH Zurich, Robotic Systems Lab}
}

The authors are Edo Jelavic, Julian Nubert and Marco Hutter of ETH Zurich Robotic Systems Lab, and the README lists Jelavic as the main contact. The paper is from the ICRA 2022 Workshop on Robotic Perception and Mapping, and a poster and abstract link is given through the ETH Zurich research collection.

The release tags follow a different naming scheme, and it is an important one for anyone integrating with ROS. The two tags are jazzy-v0.2.0 dated 2026-03-26 and jazzy-v0.1.0 dated 2026-03-17, both named after the Jazzy ROS distribution. The tag name tells you which distribution the release was cut for, which is more useful than an opaque version string when you are picking a branch for a particular robot.

The last push to the repository was on 2026-10-01, and the repository is not archived. The licence is BSD-3-Clause, which sits in the LICENSE file at the root.

The distinction between the paper year and the release dates is worth holding onto. The work dates from 2022, the releases here are from 2026, and the last push is more recent than both, so the code has continued to move since the tagged versions.

ROS integration: the catkin wrapper and why it exists

The integration story is the ros/ and open3d_catkin/ pair, and the reason it exists is stated in the README: a catkin wrapper for Open3D is provided so that Open3D can be used in ROS projects, with documentation in the open3d_catkin README.

The topic list of the repository names open3d-catkin among its tags, along with ros, slam, lidar, localization, mapping and pointcloud, so the ROS relationship is central rather than incidental.

Wrapping a third party library in a catkin package is a recurring need in ROS. A library built with a plain CMake build system does not always play nicely with the catkin workspace layout, and the wrapper adapts it so that a ROS package can depend on it as an ordinary dependency. The practical result is that you can declare Open3D as a dependency in your own package and let the wrapper resolve it, rather than building Open3D separately and pointing include paths at it.

If you are setting this up, the order matters. Build the wrapper first, since your own package depends on it, and then build your package against it. The open3d_catkin README is where the exact steps live, and the main documentation site is where the example datasets are published for you to test against.

One thing the documentation does not spell out is the version compatibility matrix between the open3d_slam releases and the Open3D versions they expect. The jazzy tag names give you the ROS distribution, and the catkin README is the place to look for the rest.

Where this library stops and production stacks begin

The honest comparison is with a production SLAM stack, and the difference is not a matter of degree.

A production SLAM system for a vehicle fuses lidar with IMU and wheel odometry, uses a probabilistic state estimator, maintains an explicit covariance, and handles loop closures at scale with a pose graph that can be optimised over a whole trajectory. The libraries in this space, whether the robotics framework ones or the more specialised ones, are built for data collected at speed over long distances where drift accumulates.

open3d_slam does not claim to be that. It says it uses well-established algorithms in their basic form, that it works with point clouds, and that no additional input such as IMU is required. That last point is the design decision with the most consequences, and it cuts both ways. A point cloud only system is simpler to understand and to debug, and it removes the synchronisation and calibration problems that sensor fusion brings. It also gives up the ability to use motion as a constraint, which means the mapping quality in a corridor with repeated geometry is not going to match a fused system.

The documentation is also not a production documentation set. There is a readthedocs site with documentation and example datasets, plus a poster and abstract for the workshop paper, but no API reference pages, no performance benchmarks and no changelog in the repository listing.

So the correct framing is this: open3d_slam is a teaching implementation that has been packaged well enough to build and run on a real robot. If your goal is to understand how mapping and localization fit together, reading it will be faster than reading a production system. If your goal is a mapping product, this is the wrong project.

Editorial conclusion

Adopt open3d_slam if you are teaching or learning SLAM, because the implementation sticks to well-established algorithms in their basic form and runs on point clouds alone with no IMU input required. Do not adopt it as a production mapping stack for a real vehicle, since the project states its purpose is education and simplicity. Before building, read the documentation site for the example datasets and the open3d_catkin README for ROS integration, and confirm your ROS distribution matches the jazzy release tags before you start integrating.

Frequently asked questions

Official sources

1. Issues
2. leggedrobotics/open3d_slam on GitHub
3. License: BSD-3-Clause
4. README
5. Releases