# stella_vslam: a visual SLAM system carried on after its upstream ended

> stella_vslam is a monocular, stereo and RGBD visual SLAM system that exists because the original OpenVSLAM repository is gone, and the README is unusually candid about what that means, pointing at the upstream termination statement and at the pull request that removed the ORB-SLAM2 similarities, with a deprecation note for anything older than 0.3. The engineering itself is strong, especially in camera model handling and in map reuse for relocalization.

**stella-cv/stella_vslam** — This is a unofficial fork of OpenVSLAM (https://github.com/xdspacelab/openvslam)

- Repository: https://github.com/stella-cv/stella_vslam
- Website: https://stella-cv.rtfd.io/en/latest/
- Stars: 1,266 · Forks: 468
- Language: C++
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/stella-cv-stella-vslam

## What the system is, and why it exists

stella_vslam is a monocular, stereo and RGBD visual SLAM system, and the first line of the README explains its own existence. It is a community fork of the OpenVSLAM project, created to continue active development of OpenVSLAM on 31 January 2021, because the original repository is no longer available. The README does not simply state that, it asks the reader to read the official statement of termination carefully and understand it before using this, which is a responsible way to introduce a fork of a dead project. The underlying technology is sparse feature visual SLAM, and the research write-up is the arXiv preprint 1910.01122. The project is hosted under the stella-cv organisation, publishes its documentation on Read the Docs with a documentation status badge, and carries a continuous integration badge for its main workflow.

## The licensing history, which is the part to read carefully

The README spends its most prominent paragraph on licence provenance, and that is deliberate. The original OpenVSLAM was built on an indirect SLAM algorithm with sparse features, including ORB-SLAM, ORB-SLAM2, ProSLAM and UcoSLAM, so the original version had similarities with ORB_SLAM2, and those similarities have been removed by pull request 252. The README then invites readers who find any other licence issue to point it out, and links issues 37 and 249 for the discussion so far. Below that there is a hard boundary, that versions earlier than 0.3 are deprecated, and that if you use them you should treat them as a derivative of ORB_SLAM2 under the GPL license. The current code is under a two clause BSD licence, and the tree carries both `LICENSE.fork` and `LICENSE.original`, which is a good sign, since it means the two codebases' terms are kept distinguishable rather than merged into one file.

## Camera models, which is where this fork is strongest

The feature list leads with compatibility with various camera models, and the README singles this out as noteworthy, saying the system can deal with perspective, fisheye and equirectangular models, and that users can implement extra models such as dual fisheye and catadioptric with ease. The visual shown in the README is a visual SLAM algorithm using equirectangular camera models, with the RICOH THETA and insta360 series named as examples. That flexibility is not a small feature in SLAM, because the projection model changes how features are detected, how the epipolar constraint is derived and how the map is triangulated, and a system that only handles pinhole cameras forces every user into a crop and a resize. The second feature in the list is that the system is fully modular, with several functions encapsulated in separate components with easy to understand APIs, and the README says code snippets are provided to understand the core functionalities. For a reader, that combination of a stable component structure and an extension point at the camera model is what makes a research codebase usable by someone who did not write it.

## Maps you can store, load and localise against

The third notable feature is that created maps can be stored and loaded, after which stella_vslam can localise new images based on the prebuilt maps. This is the difference between a research demo and a system you can deploy, because relocalisation against a saved map is what turns SLAM into something usable in a product, where the robot or camera returns to a known place and needs to know where it is without rebuilding the map from scratch. The examples directory in the repository is organised by dataset, with directories for the AIST, EuRoC, KITTI, TUM RGBD and TUM VI sequences, which tells you the intended evaluation set, and the documentation has a section on running SLAM with standard benchmarking datasets such as the KITTI Odometry dataset. A sample ORB vocabulary file is published separately for download, and sample datasets are provided as well, so a first run does not require you to assemble a corpus yourself.

## What was rewritten, and what was borrowed

The acknowledgements section is unusually precise about intellectual lineage, which is useful for a project in this situation. The core architecture is based on ORB-SLAM and ORB-SLAM2, and the code has been redesigned and written from scratch to improve scalability, readability and performance. Two specific influences are credited with earlier work. UcoSLAM had already implemented the parallelisation of feature extraction, map storage and loading, and ProSLAM had already implemented a highly modular and easily understood system, and the README notes that the modularity and the parallelism in this code come from those earlier projects. The original OpenVSLAM authors are named, Shinya Sumikura, Mikiya Shibuya and Ken Sakurada, and the README asks that the OpenVSLAM paper be cited for it, noting that OpenVSLAM won first place in the ACM Multimedia 2019 Open Source Software Competition. A separate ROS wrapper lives in its own repository, stella_vslam_ros, for people who need the system inside a robotics stack.

## Dependencies, the g2o caveat and the Docker images

The licence section also documents the vendored third party code file by file, which is the part most projects skip. The `3rd/` directory contains nlohmann/json at version 3.6.1, spdlog at 1.3.1, tinycolormap and FBoW, all under MIT licences, with FBoW itself a fork of rmsalinas/fbow. Three source files are derived from other projects, the essential five point solver from libmv under MIT, the pose solver from laurentkneip/opengv under a two clause BSD licence, and the ORB extractor and the ORB point pairs from OpenCV under a two clause BSD licence. Then there is a dependency note that matters for a build, that you should use g2o as the dynamic link library because the csparse_extension module of g2o is LGPLv3 or later. The build is CMake with presets, and the repository ships five Dockerfiles, for CUDA, for a desktop build, for Iridescence and one using a socket, alongside Docker instructions in the documentation, and the tree also carries a ROS package manifest and a test directory.

## The roadmap is a priority list, and the maintenance signal is recent commits

The README has a section titled Currently working on, and it is a stack of items with an explicit ordering rule, that the higher up the list the higher the priority, and that feedback, feature requests and contribution are welcome. The list is refactoring first, then algorithm changes and parameter additions to improve performance, then adding tests, then marker integration, then the implementation of extra camera models, then Python bindings, and IMU integration last. That ordering is a useful signal about the state of the code, because a refactoring and testing effort at the top of the list tells you the priority is making the existing system maintainable rather than extending it, and the fact that the testing item is third suggests the test coverage is still thin. Support runs through GitHub Discussions. The last push was on 2026-08-26 and there are no GitHub releases, so the versions you find in the repository or in your package manager are the only version history, and the deprecation of anything before 0.3 means you should not start a new deployment on an old snapshot.

## Conclusion

Adopt stella_vslam if you need a visual SLAM system that handles unusual camera models, that can reuse a stored map instead of rebuilding one, and that you are willing to compile from source with CMake and Docker. Do not adopt it without reading the licensing section, because the project is a fork of a discontinued repository with a history of similarity to ORB-SLAM2 that was addressed in a specific pull request, and versions before 0.3 are explicitly deprecated as GPL derivatives. Before you start, read the upstream termination statement the README asks you to read, and pick a version at or after 0.3. The core code is under a two clause BSD licence with vendored third party components listed individually, the last push was on 2026-08-26, and the repository publishes no GitHub releases.

## FAQ

### What is stella_vslam and why does it exist?

It is a monocular, stereo and RGBD visual SLAM system, and it exists because it is a community fork of the OpenVSLAM project created on 31 January 2021 to continue its development after the original repository became unavailable. The README asks readers to read the upstream statement of termination before using it.

### Which camera models does stella_vslam support?

The README says the system can deal with perspective, fisheye and equirectangular models, and that extra models such as dual fisheye and catadioptric can be implemented with ease. The featured example uses equirectangular cameras such as the RICOH THETA and insta360 series.

### Can stella_vslam reuse a map it built earlier?

Yes. One of the notable features is that created maps can be stored and loaded, after which the system can localise new images based on the prebuilt maps, which is what makes relocalisation practical rather than rebuilding the map each time.

### What licence does stella_vslam use?

The current code is under a two clause BSD licence, and the README lists the vendored third party files individually, including nlohmann/json, spdlog, tinycolormap and FBoW under MIT and parts of OpenCV and opengv under two clause BSD. Versions earlier than 0.3 are deprecated and should be treated as ORB-SLAM2 derivatives under the GPL, and the repository keeps separate LICENSE.fork and LICENSE.original files.

## Sources

- [Issues](https://github.com/stella-cv/stella_vslam/issues)
- [Project website](https://stella-cv.rtfd.io/en/latest/)
- [README](https://github.com/stella-cv/stella_vslam/blob/main/README.md)
- [stella-cv/stella_vslam on GitHub](https://github.com/stella-cv/stella_vslam)

---

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