# slamplay: A C++ SLAM Experimentation Toolkit for Computer Vision Engineers

> slamplay wires together a curated set of C++ SLAM libraries, backends, and deep learning tools into a single CMake framework, giving computer vision engineers a ready-made environment for running and studying visual SLAM and LiDAR-inertial odometry examples without configuring each dependency from scratch.

**luigifreda/slamplay** — slamplay is a collection of powerful tools to start playing and experimenting with SLAM in C++

- Repository: https://github.com/luigifreda/slamplay
- Stars: 450 · Forks: 43
- Language: C++
- License: not declared
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/luigifreda-slamplay

## What slamplay Solves and Who Should Use It

Setting up a C++ SLAM development environment means building and linking a chain of dependencies that were not designed to coexist: geometry libraries like Eigen and Sophus, optimizer backends like g2o, GTSAM, and Ceres, vision front-end tools like OpenCV and PCL, loop-closure databases like DBoW2 and DBoW3, and optional deep learning runtimes like TensorRT, TensorFlow C++, libtorch, and ONNX Runtime. Each of these has its own build system, its own set of transitive dependencies, and a history of version-incompatibility surprises.

slamplay was created by Luigi Freda for a computer vision class. Its goal is to install and wire up all of these libraries inside a single CMake framework, alongside commented examples that make each component immediately runnable. The intended user is a robotics student or computer vision researcher who wants to experiment with SLAM algorithms in C++ without spending a week debugging build failures.

The repository is specific to Ubuntu. It has been tested on Ubuntu 20.04, 22.04, and 24.04. There is no macOS or Windows support documented in the README. The deep learning components, including TensorRT, TensorFlow C++, and libtorch, are optional: the core visual SLAM and LiDAR-inertial examples compile and run without them.

## Repository Layout: What Lives Where

slamplay organises its content into topic-specific directories rather than a flat layout. The algebra_geometry folder contains Eigen and geometry tutorials. The backend folder holds optimizer examples covering g2o, GTSAM, Ceres, and se-sync. The frontend folder contains vision and sensor examples including camera models, stereo vision, motion estimation, triangulation, direct methods, and the deep learning tools built on TensorRT, TensorFlow C++, and ONNX Runtime.

The core folder holds shared libraries: DL model wrappers, and the lidar-IMU stack under core/ad/ covering laser_2d, laser_3d, IMU processing, pointcloud, and navigation. End-to-end pipeline applications live under full_slam/, split between vslam/ (visual SLAM frontend, backend, visual odometry, map) and lio_slam/ (LiDAR-inertial frontend, loop closure, pose-graph optimization, localization fusion).

Configuration files for running the full SLAM systems live under the top-level config/ directory, organised into vslam/ and lio_slam/ subdirectories. Output from mapping runs goes to results/ by default. The loop_closure folder covers place-recognition examples using DBoW2, DBoW3, and iBoW.

This folder structure means a user who only wants to study the Ceres optimizer examples can go directly to backend/ without touching the deep learning or LiDAR components at all.

## Getting slamplay Built and Running the First Example

The README documents three steps to get a working build on Ubuntu:

```bash
./install_dependencies.sh
./install_local_opencv.sh
./build.sh
```

The README notes that this takes a while. When the build finishes, examples are found under build/ and can be run directly. The README cautions against skipping the local OpenCV install: mixed dependency versions can cause undefined behavior and may disable features.

For the visual SLAM pipeline, the workflow requires editing a YAML configuration file to point at a dataset, then running the application binary:

```bash
cd build/full_slam/apps/vslam
./run_vslam_kitti_stereo
```

For LiDAR-inertial SLAM, the full offline mapping pipeline (frontend, optimization, loop closure, re-optimization) runs as:

```bash
cd build/full_slam/apps/lio_slam
./run_lio_mapping
```

Default input data for examples can be downloaded with `./install_data.sh`. Deep learning model weights have a separate download script:

```bash
./install_dl_models.sh
```

For TensorFlow C++ API support, the README states that `./install_tensorflow_cc.sh` must be run manually because the step is long. The README links to a separate tensorflow_cc repository for details on this installation.

For containerized use, the README points to a separate rosdocker project maintained by the same author, which provides Docker images with and without CUDA. No Docker support is included inside the slamplay repository itself.

## Deep Learning Integration and Its Build Constraints

Several components in slamplay depend on a working CUDA ecosystem. The frontend and semantics folders include C++ tools built on TensorRT, TensorFlow C++, and ONNX Runtime. These tools implement SuperPoint, SuperGlue, Depth-Anything, HFNet, and SAM (Segment-Anything Model) as C++ feature extraction and depth estimation modules.

The README links to a separate GPU_support.md file that documents tested CUDA, cuDNN, and TensorRT configurations. This means that the deep learning front-end is not a generic install: users must match the CUDA version, cuDNN version, and TensorRT version to a configuration that has been verified. Using an untested combination can silently produce incorrect results or build failures.

The TensorFlow C++ API step is called out specifically as long-running and requiring a manual invocation. This is not an oversight: the README explicitly states that `./install_tensorflow_cc.sh` must be run by hand rather than through the automated build chain.

For users who do not need deep learning features, the build remains fully functional. The visual SLAM and LiDAR-inertial examples that rely only on OpenCV, PCL, Eigen, and the optimizer backends build without any CUDA dependency.

## How slamplay Compares to Building Each Library Manually

The alternative to slamplay is assembling the same environment by hand: cloning each upstream library, resolving its dependencies, patching version conflicts, writing CMake find scripts, and repeating the process for a dozen components. That approach gives full control over each library version but consumes significant setup time and produces a build system that is difficult for other researchers to reproduce.

slamplay takes the opposite position: it pins a known-working combination of library versions and provides a single build entry point. The trade-off is that users cannot independently update one library without potentially breaking the others. The build scripts also do not offer fine-grained control: the README documents config.sh as the place to set the OpenCV directory, but the scripts otherwise run the full install sequence.

RoboticsToolbox for Python, maintained by Peter Corke, covers similar conceptual ground from the Python side: it provides SLAM algorithms and geometry tools in a high-level interface. The difference is that slamplay targets C++ performance and direct access to libraries like g2o and GTSAM that production SLAM systems actually use. A Python wrapper is appropriate for prototyping; slamplay is appropriate for studying or benchmarking C++ implementations.

## License and Maintenance

The repository does not declare a top-level license. The README's credits section references third-party libraries included in the build, each with its own license terms, including GPL-licensed components in g2o and DBoW2. Users who intend any commercial use should audit each bundled dependency's license individually before proceeding.

The last push was on 2026-05-19. The repository has no GitHub releases. The README credits Luigi Freda as the author and notes that slamplay was created for a computer vision class and developed during free time, which is relevant context for evaluating its long-term support trajectory.

## Conclusion

slamplay is the right starting point for a robotics or computer vision engineer who needs a working C++ SLAM environment fast, without manually resolving the version conflicts between g2o, GTSAM, OpenCV, and TensorRT. The toolkit does not carry a stated license, which is a practical constraint for any commercial use: verify the terms of each bundled library before building a product on this codebase. The last push was on 2026-05-19.

## FAQ

### What is slamplay and what is it used for?

slamplay is a C++ SLAM experimentation toolkit that installs and connects a set of robotics libraries including g2o, GTSAM, Ceres, OpenCV, and optional deep learning tools into a single CMake build. It is used for studying and running visual SLAM and LiDAR-inertial odometry examples on Ubuntu.

### What operating systems does slamplay support?

The README states that slamplay has been tested on Ubuntu 20.04, 22.04, and 24.04. There is no documented macOS or Windows support.

### Does slamplay require ROS to build and run?

No system ROS installation is required. Examples that read .bag files use a minimal ROS1-compatible C++ subset vendored in thirdparty/ros/, which includes librosbag.a and message headers. There is no catkin workspace and no dependency on a distro ROS package.

## Sources

- [Issues](https://github.com/luigifreda/slamplay/issues)
- [luigifreda/slamplay on GitHub](https://github.com/luigifreda/slamplay)
- [README](https://github.com/luigifreda/slamplay/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/luigifreda-slamplay