orbslam3
Visual, visual-inertial and multi-map SLAM for monocular, stereo and RGB-D cameras.
orbslam3 is an independent reference site for ORB-SLAM3, the open-source SLAM library developed by the research group at the University of Zaragoza. ORB-SLAM3 builds directly on ORB-SLAM and ORB-SLAM2, and was presented as the first system able to run visual, visual-inertial and multi-map SLAM with monocular, stereo and RGB-D cameras, using both pin-hole and fisheye lens models.
- Open source, GPLv3
- C++ with ROS examples
- Independent resource, not an official page
3 parallel threads
Tracking, local mapping and loop & map merging run concurrently, with a fourth thread for full bundle adjustment after a loop is accepted.
Two camera models
Pin-hole and Kannala-Brandt fisheye projection are both supported, so wide-angle lenses do not have to be cropped or rectified first.
Easy to understand
Plain-language explanations of tracking, keyframes, map points and loop closure, written for people meeting SLAM for the first time.
Feature focused
Each major capability of ORB-SLAM3 gets its own explanation, including what it changes compared with earlier releases.
Updated resources
Build steps, dependency notes and troubleshooting collected in one place instead of scattered across issue threads.
User friendly
Guidance that works whether you are running a dataset demo or wiring the library into your own robot stack.
What Is orbslam3?
ORB-SLAM3 is an open-source SLAM library. SLAM stands for simultaneous localisation and mapping: the camera works out where it is while building a map of the space around it, without a prior model of that space and without external positioning. The name comes from ORB features, the fast binary keypoints the system extracts from every incoming frame and reuses for tracking, relocalisation and loop closure.
It was released by the SLAM lab at the University of Zaragoza as the third generation of the ORB-SLAM family, following ORB-SLAM and ORB-SLAM2. Two changes define it. The first is a tightly coupled visual-inertial mode built on maximum-a-posteriori estimation, where inertial measurements are optimised together with visual ones rather than fused afterwards; that also gives a monocular camera real metric scale. The second is Atlas, a multi-map representation: when tracking is lost the system starts a fresh map instead of stalling, and can merge it back into an earlier map when the place is recognised again.
Around those two ideas sits the architecture the family is known for. A tracking thread localises every frame and decides when to insert a keyframe. A local mapping thread refines a window of nearby keyframes and map points with bundle adjustment. A third thread looks for loop closures and map merges, and a full bundle adjustment runs separately once a loop is accepted. Place recognition uses a bag-of-words index over ORB descriptors with an added local consistency check, which the authors introduced to raise recall.
Practically, ORB-SLAM3 accepts monocular, stereo and RGB-D input, each of which can be combined with an IMU, and it handles pin-hole and fisheye lenses. It produces a sparse map of point features and a keyframe trajectory, not a dense surface reconstruction, so it is usually the localisation layer inside a larger system rather than the whole pipeline.
What the library gives you
- Camera pose for every processed frame
- A sparse map of ORB point features
- Keyframes linked by a covisibility graph
- Loop closure and map merging
- Relocalisation after tracking loss
- Metric scale in any inertial mode
Independent site. orbslam3.com is an informational resource. It is not affiliated with, endorsed by or operated by the University of Zaragoza, the ORB-SLAM3 authors or any organisation connected to them. Always confirm details against the official repository and the published paper.
orbslam3 Features
Six sensor configurations
Monocular, stereo and RGB-D input each run on their own or paired with an IMU. The choice is a trade-off: monocular is the cheapest to rig and the hardest to initialise, stereo gives scale immediately, and inertial modes hold up best through fast motion and low-texture stretches.
Tightly coupled inertial estimation
Inertial residuals are optimised jointly with visual ones under a maximum-a-posteriori formulation, including a dedicated IMU initialisation phase that estimates scale, gravity direction and biases instead of assuming them.
Atlas multi-map system
Maps are kept in a set rather than discarded. One map is active; the others stay available for recognition and merging. Losing tracking starts a new map and costs you the session only until the old place is seen again.
Improved place recognition
Recognition runs over a bag-of-words index of ORB descriptors, with a geometric and local consistency check before a candidate is accepted. It is the component that makes loop closure, relocalisation and map merging possible at all.
Pin-hole and fisheye models
Both the standard pin-hole model and the Kannala-Brandt fisheye model are supported natively, so wide field-of-view lenses can be used without cropping away the periphery that makes them useful.
Keyframes and covisibility
Rather than optimising every frame, the system promotes selected frames to keyframes and connects them in a covisibility graph. Local bundle adjustment then works on a bounded window, which is what keeps the cost real-time as the map grows.
Concurrent architecture
Tracking, local mapping and loop & map merging run as separate threads, with full bundle adjustment spun off after an accepted loop. Heavy optimisation therefore does not block pose output on the next frame.
Open source and inspectable
The code is published under GPLv3 with the accompanying paper, dataset examples and ROS nodes. You can read exactly what the estimator does, which is why it is so often used as a baseline in research and teaching.
How orbslam3 Works
Track the frame
ORB features are extracted from the incoming image and matched against the local map. The tracking thread solves for the camera pose, and when the view has changed enough it promotes the frame to a keyframe.
Refine the local map
Local mapping takes new keyframes, triangulates fresh map points, culls unreliable ones and runs bundle adjustment over a covisible window so the geometry near the camera stays consistent.
Close loops, merge maps
Place recognition compares each keyframe against the Atlas. A match inside the active map triggers loop closure; a match in another map triggers a merge, which welds the two into one.
Optimise the whole Atlas
After a loop or merge is accepted, a separate thread runs full bundle adjustment while tracking continues, and the corrected map is handed back without dropping frames.
Why people search for orbslam3
The keyword covers a wide range of needs, from a student checking what the acronym means to an engineer deciding whether the library belongs in a production stack. Grouping those intents is useful, because the answer to what is it and the answer to why does my build fail sit in completely different places.
The six patterns on the right cover almost everything people ask. Each has a matching section further down this page, so you can skip straight to the part that applies to you.
Understanding what it is
Most visitors arrive from a paper, a lecture or a repository link and want a plain description before committing time to a build.
Comparing sensor modes
Choosing between monocular, stereo and RGB-D, with or without an IMU, is the decision that shapes everything else about the rig.
Checking compatibility
Which Ubuntu release, which OpenCV, which Eigen. Dependency questions are the single most common reason people search for the project by name.
Getting it to build
Compiler errors on newer toolchains and mismatched third-party libraries account for a large share of first-run problems.
Running it on real hardware
Moving from a recorded dataset to a live camera raises calibration, timing and synchronisation questions that the demos never surface.
Fixing drift and lost tracking
Scale drift, failed initialisation and tracking loss in featureless corridors are the recurring complaints once a system is running.
orbslam3 Compatibility
Operating system
The project documents builds on Ubuntu 16.04, 18.04 and 20.04. Other Linux distributions generally work with the same dependency set. macOS and Windows are not the documented targets; people usually reach for WSL, a container or a virtual machine.
Toolchain
A C++11-capable compiler and CMake are the baseline, and newer compilers often want the standard raised to C++14 plus a couple of missing includes added. GCC versions close to the tested Ubuntu releases give the smoothest experience.
Core dependencies
Pangolin for visualisation, OpenCV, Eigen3, and DBoW2 with g2o bundled under Thirdparty. Python is used by the evaluation scripts. Exact versions are stated in the README of the release you build.
Sensors
Monocular, stereo and RGB-D cameras, with pin-hole or fisheye lenses, and an optional IMU in every mode. Inertial use adds requirements: known camera-IMU extrinsics, noise parameters and a reliable time base.
ROS
ROS1 example nodes ship with the repository and are built separately from the core library. ROS2 support lives in community forks rather than the original tree, so behaviour there depends on the fork you pick.
Hardware
A multi-core CPU carries the load and no GPU is required. Achievable frame rate depends on image resolution, the number of features per frame and how large the active map has grown.
Version matters. Dependency versions, supported sensor modes and build flags have changed between releases and differ again across community forks. Treat any compatibility list, including this one, as a starting point and confirm it against the README of the exact revision you are checking out.
How to Use orbslam3
Six stages that take you from a fresh clone to a trajectory you can actually trust.
Pick the sensor configuration
Decide before you write any code. Stereo or RGB-D give metric scale without an IMU. Monocular needs translation to initialise. Adding inertial data helps through fast motion but raises the calibration bar sharply.
Calibrate properly
Intrinsics, distortion and, for stereo, the baseline all feed the estimator directly. For inertial modes you also need camera-IMU extrinsics, noise densities and any time offset. Poor calibration looks exactly like a buggy algorithm.
Write the settings file
Each run is driven by a YAML file holding camera parameters, ORB extractor settings such as feature count and pyramid levels, viewer options and, for inertial runs, the IMU block. Start from the example closest to your rig.
Extract the vocabulary and run
Likely reason: The ORB vocabulary ships compressed and has to be extracted before first use. The example executables then take the vocabulary path, the settings path and the sequence, in that order.
Read the viewer
The map viewer shows keyframes, map points and the current pose. Sparse points, a stalled keyframe count or a pose that jumps are your earliest signals that something upstream is wrong.
Save and evaluate the trajectory
Trajectories can be written out at shutdown and compared against ground truth with the evaluation scripts or a tool such as evo. Do this on a public dataset first so you know your setup is sane.
How to Install orbslam3
Check the requirements
Confirm your distribution, compiler and CMake version against the README of the revision you plan to build. Note the OpenCV and Eigen versions the authors tested; a mismatch here causes more failures than anything else in the process.
Prepare the system
Install build tools and the dependency set: Pangolin, OpenCV, Eigen3 and the usual development headers. Build Pangolin from a version compatible with the release rather than assuming the newest one will work.
Build the library
The repository ships a build script that compiles the bundled DBoW2 and g2o under Thirdparty and then the library and examples. Run it from the repository root and read the first error rather than the last, since later failures usually cascade.
Build the ROS nodes if you need them
ROS examples are compiled in a separate step and expect the package path to be on your ROS package path. Skip this entirely if you are calling the library directly from your own C++ code.
Verify with a public dataset
Extract the ORB vocabulary, download a sequence from a dataset the project provides an example for, and run it. A clean dataset run proves the build before your own camera introduces new variables.
Keep it updated
Pull changes, then rebuild the Thirdparty directory as well as the library. Stale object files from a previous dependency version are a classic source of link errors that look unrelated to the update.
No files are hosted here. This site does not distribute the library, mirror binaries or link to unofficial builds. Get the source from the project’s own repository, and read the licence terms before using it in anything commercial — ORB-SLAM3 is released under GPLv3.
Built to be swapped into any rig
One estimator, six ways to sense the world
Most SLAM systems commit to one sensor arrangement. ORB-SLAM3 keeps a single feature-based back end and lets the front end change: the same map points, keyframes and place recognition serve a bare monocular camera and a stereo-inertial rig alike. That is why it turns up so often as the baseline in comparisons — you can change one variable at a time and keep the rest of the pipeline fixed.
- Same back end across all sensor modes
- Maps survive tracking loss instead of restarting
- Metric scale as soon as an IMU is initialised
- Published with the paper that describes it
Tracking, local mapping and loop & merging run concurrently, plus a full bundle adjustment thread after an accepted loop.
Pin-hole and Kannala-Brandt fisheye, chosen in the settings file rather than at compile time.
Open source, with commercial use requiring a separate arrangement with the authors.
orbslam3 Comparison
Sensor support
Monocular, stereo and RGB-D, each usable with an IMU
Monocular, stereo and RGB-D, no inertial mode
Inertial modes need calibrated camera-IMU extrinsics
Camera models
Pin-hole and Kannala-Brandt fisheye
Pin-hole input
Fisheye support avoids cropping wide-angle images
Map handling
Atlas keeps multiple maps and can merge them
A single active map
Matters most when tracking is lost and later recovered
Place recognition
Bag-of-words matching with an added local consistency check
Bag-of-words matching
Aimed at higher recall, at some extra computation
Estimation
Maximum-a-posteriori estimation including inertial states
Bundle adjustment over visual measurements
Inertial residuals are what give monocular runs metric scale
After tracking loss
Starts a new map and can merge it back on re-recognition
Relocalise into the same map, or restart
One of the headline changes in the third generation
Licence
GPLv3
GPLv3
Commercial use requires contacting the authors
Highlights and things to consider
orbslam3 highlights
- Mature, widely cited implementation with a paper describing the method
- One code base covers monocular, stereo and RGB-D, with or without an IMU
- Runs in real time on a normal multi-core CPU, with no GPU requirement
- Multi-map Atlas makes tracking loss recoverable rather than fatal
- Example nodes for public datasets make verification straightforward
- Source is readable, which is invaluable for teaching and for debugging
Things to consider
- Produces a sparse feature map, not a dense surface reconstruction
- Accuracy is bounded by calibration quality more than by anything else
- Build friction on newer toolchains, usually dependency version mismatches
- Low-texture and repetitive scenes remain difficult for feature matching
- Inertial modes need well-characterised IMU noise and reliable timestamps
- GPLv3 has real consequences for closed-source commercial products
Common orbslam3 Problems & Solutions
The build fails on OpenCV
Likely reason: CMake found a different OpenCV to the one you expected, or the API changed between the 3.x and 4.x lines.
Try this: Check which versions the README lists as tested, point OpenCV_DIR at that build explicitly, and clear the build directories before trying again so no stale cache survives.
Compiler errors on a newer system
Likely reason: Newer GCC releases are stricter about headers and defaults than the toolchains the code was written against.
Try this: Missing declarations such as usleep are fixed by adding the relevant system header, and raising the standard to C++14 in CMakeLists resolves many of the rest. Otherwise use a container with a tested toolchain.
Pangolin errors or no viewer window
Likely reason: Pangolin's own API has moved on, or you are running on a headless machine with no display available.
Try this: Build a Pangolin revision compatible with your ORB-SLAM3 version. On a headless host, disable the viewer in the settings file or run behind a virtual framebuffer.
Vocabulary file not found
Likely reason: The ORB vocabulary ships compressed and the examples expect an extracted file at the path you pass in.
Try this: Extract the archive in the Vocabulary directory, then pass the resulting text file as the first argument. Use an absolute path if you are launching from somewhere other than the repository root.
Monocular tracking never initialises
Likely reason: Monocular initialisation needs parallax. Pure rotation, a static camera or a blank textureless wall cannot produce it.
Try this: Translate the camera sideways across a textured scene for the first few seconds, verify the intrinsics in your settings file, and raise the feature count if the image is genuinely sparse.
Drift or wrong scale in inertial mode
Likely reason: Almost always calibration: inaccurate camera-IMU extrinsics, wrong noise densities, or an unmodelled time offset between the two streams.
Try this: Recalibrate with a dedicated tool, confirm your IMU rate and timestamps are consistent, and keep the motion well excited during initialisation so scale and gravity can be observed.
orbslam3 Tips & Best Practices
Prove the build on a dataset first
Run a public sequence before your own camera. If that works, every later problem belongs to your hardware or calibration rather than the build.
Treat calibration as the main lever
Time spent on intrinsics, extrinsics and stereo baseline pays back more than any parameter tuning. Redo it whenever the rig is disturbed.
Excite the IMU during initialisation
Scale and gravity are only observable under varied motion. Starting an inertial run from a slow, smooth glide is the usual cause of a bad initialisation.
Version your settings files
The YAML is part of your experiment. Keeping it in the repository next to results is the difference between a reproducible run and a story about one.
Record raw sequences
Log the camera and IMU streams so you can replay the exact input after changing a parameter. Debugging against live motion you cannot repeat wastes hours.
Watch the map, not just the pose
Keyframe and map point counts tell you when tracking is about to fail. A map that stops growing while the camera keeps moving is an early warning.
Complete orbslam3 Guide
Where ORB-SLAM3 came from
The ORB-SLAM line began as a monocular system built around ORB features, keyframes and bundle adjustment. Its successor added stereo and RGB-D input. ORB-SLAM3 is the third step, and the one that changed the shape of the system rather than just its inputs: inertial measurements were folded into the estimator itself, and the single map was replaced by a set of maps. Everything else that made the family useful — the covisibility graph, the keyframe strategy, the bag-of-words place recognition — carried over.
What the system actually estimates
For every processed frame you get a camera pose. Behind that sits a map of sparse three-dimensional points, each one seen from several keyframes, and a graph recording which keyframes share observations. In inertial modes the state also carries velocity, gravity direction and IMU biases. What you do not get is geometry: no meshes, no dense depth, no textured surfaces. If your application needs those, ORB-SLAM3 supplies the pose and map that a separate reconstruction stage consumes.
Choosing a sensor configuration
Monocular is the least demanding hardware and the most demanding to operate: it cannot recover absolute scale on its own and needs genuine translation to initialise. Stereo fixes scale from the baseline and initialises immediately, at the price of a rigid, well-calibrated pair. RGB-D gives dense depth per pixel and suits indoor work, but most sensors of that type struggle in sunlight and at range. Adding an IMU to any of these improves robustness through fast rotation, motion blur and brief featureless stretches, and gives a monocular rig metric scale — in exchange for calibration and synchronisation work that is easy to underestimate.
What good input looks like
Texture, light and motion, in that order. The extractor needs corners, so blank walls, glass and repeating patterns all reduce the number of usable features. Exposure that hunts between bright and dark regions breaks matching between consecutive frames. Rolling-shutter distortion under fast motion introduces errors the model does not account for. Global shutter, fixed exposure and a scene with visible structure will outperform a better algorithm fed worse images.
Running it beyond the demos
The example executables exist to validate a build, not to be the product. Real integration means driving the library from your own code or a ROS node, feeding images and inertial samples with consistent timestamps, and deciding what your system does when tracking is lost. Atlas makes that decision less painful, since a new map starts rather than the session ending, but downstream consumers still need to know that the pose they just received belongs to a different map.
Limits worth knowing early
ORB-SLAM3 is a research-quality implementation released under GPLv3, and both halves of that sentence matter. The licence has real implications for closed products. The research framing means the code optimises for clarity and reproducibility rather than long-running deployment, so watchdogs, memory limits and recovery behaviour are yours to add. It is an excellent baseline and a strong starting point; it is not a supported product with a roadmap behind it.
orbslam3 Download & Resources
orbslam3 resources
Papers, dataset links and reference material collected in one place.
Installation guide
The build sequence, dependency notes and the failures that follow each one.
Latest information
Release notes, forks worth knowing about and changes to the dependency set.
Before you download anything. Use reputable sources only, and prefer the project’s own repository over mirrors and re-uploads. Check which release or commit you are taking, because dependency versions and supported modes differ between them, and read the GPLv3 terms if the result will ship in a product. Nothing on this page is an official distribution channel.
orbslam3 Frequently Asked Questions
ORB-SLAM3 is an open-source visual SLAM library that estimates a camera’s pose while building a sparse map of the surrounding scene. It supports monocular, stereo and RGB-D cameras, each optionally combined with an IMU, and handles both pin-hole and fisheye lenses. It was developed by the SLAM research group at the University of Zaragoza as the successor to ORB-SLAM2.
ORB features are extracted from each frame and matched against a local map to solve for the camera pose. Selected frames become keyframes, which a local mapping thread refines with bundle adjustment. A third thread searches for loop closures and map merges using bag-of-words place recognition, and a separate full bundle adjustment runs after a loop is accepted.
Six sensor configurations from one code base, tightly coupled visual-inertial estimation with a dedicated IMU initialisation phase, the Atlas multi-map system, improved place recognition, support for pin-hole and fisheye camera models, and a concurrent architecture that keeps heavy optimisation off the tracking path.
Running a dataset example is straightforward once the build succeeds. Using it on your own hardware is harder, because accuracy depends on calibration, timestamps and image quality rather than on the library alone. Comfort with C++, CMake and Linux tooling makes the difference between a smooth start and a frustrating one.
Any machine with a multi-core CPU and a supported build environment can run it; no GPU is required. On the sensing side it works with monocular cameras, stereo pairs and RGB-D cameras, with an optional IMU. Achievable frame rate depends on resolution, feature count and how large the active map has grown.
Confirm your distribution and compiler against the README, install the dependency set including Pangolin, OpenCV and Eigen3, then run the supplied build script from the repository root to compile the bundled Thirdparty libraries and the examples. Build the ROS nodes separately if you need them, and verify the result on a public dataset.
Pull the latest changes, then rebuild the Thirdparty directory as well as the library itself. Clearing previous build directories avoids link errors caused by object files compiled against an older dependency. Re-run your dataset check afterwards so you can attribute any behaviour change to the update rather than to your own configuration.
The most common causes are a dependency version mismatch during the build, a vocabulary file that was never extracted, an incorrect settings file, or a calibration that does not match the camera in use. Work through them in that order: a clean run on a public dataset separates build problems from hardware and calibration problems.
Your operating system version, compiler and CMake version, and the OpenCV and Eigen versions the release was tested against. Also check that you have enough disk space for the dependency builds and that a display is available if you intend to use the viewer. Reading the README of the exact revision saves the most time.
Yes, and this is worth taking seriously. Dependency versions, supported sensor modes and build flags have changed between releases, and community forks diverge further, particularly around ROS2 support. Any compatibility list you read, including the one on this page, should be confirmed against the specific revision you are building.
The project’s own repository is the canonical source for code, build instructions and example configurations, and the accompanying paper describes the method in detail. Public datasets used in the examples publish their own documentation. This site collects explanations and troubleshooting around those primary sources rather than replacing them.
Isolate one variable at a time. Confirm the build with a dataset sequence, then swap in your own camera, then enable inertial mode. Read the first error in a failed build rather than the last, since later failures usually cascade. Watching keyframe and map point counts in the viewer often reveals the problem before the pose visibly breaks.
It is a library you build from source rather than a system package, so removing it usually means deleting the repository directory and its build output. Dependencies you installed for it, such as Pangolin or a specific OpenCV build, are separate and may be used by other projects, so review those before removing them.
Note the commit or release you are currently on and keep a copy of your settings files, since parameter names occasionally change. Record a baseline trajectory on a dataset sequence so you can compare behaviour afterwards. If the library sits inside a larger system, update it in isolation rather than alongside other changes.
Yes. Beyond a C++ toolchain and CMake it needs Pangolin for visualisation, OpenCV for image handling and Eigen3 for linear algebra. DBoW2 and g2o are bundled in the repository’s Thirdparty directory. Python is used by the evaluation scripts, and ROS is only needed if you build the ROS example nodes.
Because it is distributed as source, the reliable answer is the commit hash or tag you checked out from version control rather than a version string printed at runtime. Recording that hash alongside your results is good practice, especially if you are comparing runs made weeks apart or on different machines.
Build failures from mismatched OpenCV or Eigen versions, compiler errors on newer toolchains, Pangolin and viewer issues on headless machines, an unextracted vocabulary file, monocular initialisation that never converges, and drift or scale errors in inertial modes caused by imperfect camera-IMU calibration.
Start with the published paper, which explains the estimator and the multi-map design properly, then read the repository README and the example configurations. The wider SLAM literature on bundle adjustment, bag-of-words place recognition and visual-inertial initialisation fills in the background the paper assumes you already have.
No. This site is an independent informational resource. It is not affiliated with, endorsed by or operated by the University of Zaragoza, the ORB-SLAM3 authors or any related organisation, and it does not host or distribute the software. Always treat the official repository and paper as authoritative.
That most early difficulty is environmental rather than algorithmic. Get a clean build, verify it on a public dataset, and only then introduce your own camera. Invest in calibration before tuning parameters, and remember that the output is a sparse map and a trajectory, not a dense reconstruction of the scene.
Explore orbslam3
Everything on this page is here to shorten the distance between reading about ORB-SLAM3 and having it running on your own footage. Start with the guide if you are still deciding, or go straight to the installation steps if you already know you want it.
orbslam3.com is an independent resource and is not affiliated with or endorsed by the ORB-SLAM3 authors or the University of Zaragoza.