If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/raulmur/ORB_SLAM2 shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

AVOID — Looks unmaintained — solo project with stale commits

• Other licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live raulmur/ORB_SLAM2 repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/raulmur/ORB_SLAM2.

What it runs against: a local clone of raulmur/ORB_SLAM2 — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in raulmur/ORB_SLAM2 | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 754 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of raulmur/ORB_SLAM2. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/raulmur/ORB_SLAM2.git
#   cd ORB_SLAM2
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of raulmur/ORB_SLAM2 and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "raulmur/ORB_SLAM2(\\.git)?\\b" \\
  && ok "origin remote is raulmur/ORB_SLAM2" \\
  || miss "origin remote is not raulmur/ORB_SLAM2 (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "Examples/Monocular/mono_tum.cc" \\
  && ok "Examples/Monocular/mono_tum.cc" \\
  || miss "missing critical file: Examples/Monocular/mono_tum.cc"
test -f "Examples/RGB-D/rgbd_tum.cc" \\
  && ok "Examples/RGB-D/rgbd_tum.cc" \\
  || miss "missing critical file: Examples/RGB-D/rgbd_tum.cc"
test -f "Examples/Stereo/stereo_kitti.cc" \\
  && ok "Examples/Stereo/stereo_kitti.cc" \\
  || miss "missing critical file: Examples/Stereo/stereo_kitti.cc"
test -f "Thirdparty/DBoW2/DBoW2/TemplatedVocabulary.h" \\
  && ok "Thirdparty/DBoW2/DBoW2/TemplatedVocabulary.h" \\
  || miss "missing critical file: Thirdparty/DBoW2/DBoW2/TemplatedVocabulary.h"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 754 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~724d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/raulmur/ORB_SLAM2"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

ORB-SLAM2 is a real-time SLAM (Simultaneous Localization and Mapping) library that computes camera trajectories and sparse 3D reconstructions from monocular, stereo, or RGB-D camera feeds. It uniquely handles loop detection and camera relocalization in real-time, enabling applications like autonomous navigation and AR to recover from tracking loss and close loops in previously mapped areas. Monolithic C++ library with Examples/ as entry points: Examples/Monocular/, Examples/Stereo/, and Examples/RGB-D/ contain dataset-specific runners (mono_euroc.cc, mono_kitti.cc, rgbd_tum.cc), Examples/ROS/ wraps it for ROS subscribers, and configuration lives in .yaml files (EuRoC.yaml, KITTI*.yaml, TUM*.yaml). Core algorithms are in src/ (not shown in file list but implied by CMakeLists.txt), built as a shared library.

Roboticists, computer vision researchers, and autonomous system engineers building real-time visual odometry and mapping pipelines who need a battle-tested SLAM system supporting multiple camera types (monocular, stereo, RGB-D) with loop closure and relocalization out-of-the-box.

This is a mature, production-ready system: published in IEEE Transactions on Robotics (2015 monocular version, 2017 stereo/RGB-D), widely cited (1000+ citations), and last commit was January 2017. However, no active development for 6+ years suggests it's stable but not evolving—it serves as a reference implementation rather than bleeding-edge.

Key risks: (1) No Git history visible, so unknown commit frequency and maintenance pattern. (2) Single primary author (raulmur) with minimal visible contributor activity suggests low bus factor. (3) Dependencies on OpenCV 3+ and Eigen 3.3+ may conflict with modern projects using OpenCV 4.x or newer Eigen. (4) ROS integration via Examples/ROS/ ties some functionality to ROS ecosystem, creating conditional complexity.

No active development visible from provided data. Last README update was January 2017 (OpenCV 3 and Eigen 3.3 support) and December 2016 (AR demo). The repo appears to be in maintenance mode—a stable reference implementation rather than an active research project.

git clone https://github.com/raulmur/ORB_SLAM2.git
cd ORB_SLAM2
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j4
cd ..
# Download EuRoC/KITTI/TUM dataset and run:
./Examples/Monocular/mono_euroc ../Vocabulary/ORBvoc.txt ./Examples/Monocular/EuRoC.yaml PATH_TO_DATASET_FOLDER TIMES_FILE

Dependencies (from Dependencies.md): OpenCV 2.4.11+, Eigen 3.1.0+, g2o, DBoW2 (Bags of Binary Words).

Daily commands: After build: ./Examples/Monocular/mono_euroc ../Vocabulary/ORBvoc.txt ./Examples/Monocular/EuRoC.yaml <dataset_path> <times_file> for monocular on EuRoC. ROS version: rosrun ORB_SLAM2 Mono Vocabulary/ORBvoc.txt Examples/ROS/ORB_SLAM2/Asus.yaml (or stereo/rgbd variants). GUI is interactive—press space for localization mode, 's' for SLAM mode.

• CMakeLists.txt — Root build configuration that orchestrates compilation of core SLAM library, third-party dependencies (DBoW2, g2o), and all example executables.
• Examples/Monocular/mono_tum.cc — Entry point for monocular SLAM on TUM dataset; demonstrates the primary API pattern for initializing and running the SLAM system.
• Examples/RGB-D/rgbd_tum.cc — Entry point for RGB-D SLAM showing depth sensor integration; essential reference for understanding multi-modal pipeline.
• Examples/Stereo/stereo_kitti.cc — Stereo SLAM example on KITTI dataset; demonstrates binocular initialization and baseline-dependent scale recovery.
• Thirdparty/DBoW2/DBoW2/TemplatedVocabulary.h — Vocabulary abstraction for loop detection and relocalization; critical dependency for global place recognition.
• Thirdparty/g2o/g2o/core/base_vertex.h — Base vertex class for pose-graph optimization; foundational abstraction for all pose and landmark optimization.
• Examples/ROS/ORB_SLAM2/src/ros_mono.cc — ROS monocular interface showing how to integrate ORB-SLAM2 with live sensor streams and publish tracking output.

Add support for a new camera dataset (YAML configuration)

1. Create a new YAML file in Examples/{Monocular,Stereo,or RGB-D}/ with camera matrix, distortion coefficients, image resolution, and ORB feature parameters (Examples/Monocular/TUM1.yaml)
2. If dataset uses RGB-D, add timestamp association file in Examples/RGB-D/associations/ (Examples/RGB-D/associations/fr1_desk.txt)
3. Create a new example executable (e.g., mono_mydataset.cc) that reads frame timestamps, loads images, and calls SLAM pipeline (Examples/Monocular/mono_tum.cc)
4. Update CMakeLists.txt to compile the new example target (CMakeLists.txt)

Integrate ORB-SLAM2 into a new robotic platform via ROS

1. Create a new ROS node file in Examples/ROS/ORB_SLAM2/src/ that subscribes to camera topics (sensor_msgs/Image or sensor_msgs/CompressedImage) (Examples/ROS/ORB_SLAM2/src/ros_mono.cc)
2. Copy and adapt the camera configuration YAML to your platform's calibration parameters (Examples/ROS/ORB_SLAM2/Asus.yaml)
3. Publish camera pose as geometry_msgs/PoseStamped on /ORB_SLAM2/camera_pose and point cloud on /ORB_SLAM2/map_points (Examples/ROS/ORB_SLAM2/src/ros_mono.cc)
4. Add node entry to Examples/ROS/ORB_SLAM2/CMakeLists.txt and Examples/ROS/ORB_SLAM2/manifest.xml (Examples/ROS/ORB_SLAM2/CMakeLists.txt)

Customize feature extraction and matching parameters

1. Open your dataset's YAML file and modify ORB feature parameters: nFeatures (target count), scaleFactor (pyramid scale), nLevels (pyramid depth), iniThFAST, minThFAST (Examples/Monocular/TUM1.yaml)
2. Recompile example executables; SLAM will extract features with new parameters on next run (CMakeLists.txt)
3. Monitor tracking quality in real-time by checking published pose and map density in ROS visualizer or GUI (Examples/ROS/ORB_SLAM2/src/ros_mono.cc)

• ORB features (FAST + BRIEF descriptors) — Fast, rotation-invariant, memory-efficient; enable real-time matching on embedded and desktop platforms without GPU.
• DBoW2 (Bag of Words) — Enables scalable loop closure detection via visual vocabulary; queries are O(log n) in vocabulary size, not O(n) in map size.
• g2o (pose-graph optimization) — Modular, sparse non-linear solver; supports generic vertex/edge abstractions for bundle adjustment, loop closure constraints, and large-scale pose graphs.
• OpenCV + Eigen — Mature computer vision and linear algebra libraries; OpenCV provides image I/O and feature matching; Eigen provides fast matrix operations for SLAM algebra.
• ROS (optional) — Enables integration with robotic middleware; decouples SLAM from hardware drivers via standardized message interfaces.

• Sparse (not dense) 3D reconstruction

  • Why: Feature-based SLAM is computationally tractable on CPUs; dense reconstruction requires photometric consistency and higher memory.
  • Consequence: Output is keypoint-level map (100s–1000s of points), not volumetric; sufficient for localization and navigation, not 3D shape modeling.

• Monocular, stereo, and RGB-D in single library

  • Why: Unified ORB tracking and mapping backend; camera model differences isolated to initialization and depth estimation.
  • Consequence: Monocular requires manual scale initialization and is scale-ambiguous; stereo and RGB-D recover metric scale automatically but require binocular/depth calibration.

• Real-time local bundle adjustment, deferred global optimization

  • Why: Local BA keeps tracking responsive (~30ms/frame); global BA happens only on loop closure, amortizing cost.
  • Consequence: Loop closure refinement causes momentary pose jump; drift accumulates between loops until global optimization.

• CPU-only optimization (no CUDA)

  • Why: Portability across research, mobile, and embedded platforms; dependencies (Eigen, g2o, OpenCV) are stable and widely available.
  • Consequence: Slower than GPU-accelerated solutions on high-end hardware; suitable for real-time on modern multi-core CPUs (~2–

(1) ORB vocabulary file required: Examples assume Vocabulary/ORBvoc.txt exists; this must be generated or downloaded separately—not in repo. (2) Dataset-specific format: Each dataset (EuRoC, KITTI, TUM) has different timestamp/association formats; wrong format causes silent failures. (3) Stereo baseline tuning: Stereo examples require accurate baseline calibration in .yaml or reconstruction scale is garbage. (4) ROS buildspace isolation: Examples/ROS/ is a separate catkin package and may conflict with overlays if symlinked. (5) Eigen version lock: Some Eigen 3.3 code may not compile with Eigen 4.x; check CMakeLists.txt CMAKE_CXX_STANDARD.

• ORB (Oriented FAST and Rotated BRIEF) — ORB-SLAM2 is built on ORB features—efficient, rotation-invariant descriptors central to feature matching, loop detection, and relocalization; understanding ORB's speed-accuracy tradeoff is crucial for tuning nFeatures.
• Bag of Words (BoW) place recognition — DBoW2 quantizes ORB descriptors into vocabulary words to quickly identify loop closures without brute-force matching; critical for relocalization and loop closing without global pose search.
• Pose Graph Optimization (PGO) — g2o optimizes a graph of camera poses and 3D points to minimize reprojection error; understanding pose graphs helps when debugging drift or tuning optimizer hyperparameters.
• Bundle Adjustment — ORB-SLAM2 performs local and global bundle adjustment to refine camera poses and 3D point positions jointly; this is the core optimization loop keeping reconstruction accuracy high.
• Epipolar Geometry & Triangulation — Stereo and monocular tracking use epipolar constraints to match features and triangulate 3D points; understanding epipolar geometry is essential for debugging tracking failures.
• Covisibility Graph — ORB-SLAM2 builds a covisibility graph connecting keyframes that observe the same 3D points; this structure enables efficient local mapping and relocalization without global searches.
• Essential/Fundamental Matrix Decomposition — Initial pose estimation from stereo or monocular frame pairs relies on decomposing the essential matrix (E) into rotation and translation; failures here cause tracking loss.

• IntelRealSense/librealsense — Provides SDK for RGB-D cameras (RealSense) compatible with ORB-SLAM2's RGB-D pipeline; often used as source for live camera data.
• dorian3d/DBoW2 — Bag-of-Words place recognition library used directly by ORB-SLAM2 for loop detection; listed as co-author contribution and can be studied separately.
• RainerKuemmerle/g2o — Graph optimization backend that ORB-SLAM2 depends on for pose graph and bundle adjustment; understanding g2o is essential for customizing optimization.
• JakobEngel/ORB_SLAM2_SSD_semantic — Community fork adding semantic segmentation to ORB-SLAM2; exemplifies extension patterns for the core library.
• opencv/opencv — OpenCV is the fundamental image processing and feature detection dependency; ORB-SLAM2 uses cv::ORB, cv::BFMatcher, and image I/O directly.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add ROS integration tests for mono/stereo/RGB-D pipelines

The repo has ROS examples (Examples/ROS/ORB_SLAM2/src/) but no automated tests verifying these ROS nodes work correctly. This is critical for a SLAM library used in robotics, as ROS integration can break silently. Tests should verify topic subscriptions, tf publishing, and output correctness across all three camera types.

• [ ] Create test directory Examples/ROS/ORB_SLAM2/test/ with rostest configurations
• [ ] Add integration tests for ros_mono.cc, ros_stereo.cc, and ros_rgbd.cc that publish test camera data and verify /tf output
• [ ] Add CMake configuration to run rostest targets in the ROS package CMakeLists.txt
• [ ] Document expected ROS topics/tf frames in Examples/ROS/ORB_SLAM2/README.md (currently missing)

Create unified dataset loader tests with TUM/KITTI/EuRoC validation

The repo has hardcoded example files for 3 major datasets (KITTI, TUM, EuRoC) across 3 camera types, but no automated tests verify that the dataset loaders (implied in Examples/*.cc files) correctly parse timestamps and camera calibrations. A contributor could create regression tests ensuring format changes don't break compatibility.

• [ ] Create tests/datasets/ directory with minimal test data samples for TUM (Examples/RGB-D/associations/fr1_desk.txt), KITTI (KITTI00-02.yaml), and EuRoC (EuRoC.yaml) formats
• [ ] Add unit tests in tests/DatasetLoaderTest.cc that verify YAML parsing for all camera calibration formats (Monocular/KITTI03.yaml, Stereo/EuRoC.yaml, RGB-D/TUM1.yaml, ROS/Asus.yaml)
• [ ] Verify timestamp file parsing (Examples/Monocular/EuRoC_TimeStamps/ and Examples/Stereo/EuRoC_TimeStamps/) produces correct frame sequences
• [ ] Integrate tests into CMakeLists.txt build target

Add camera calibration validation and conversion utilities with tests

The repo has 12+ .yaml calibration files (KITTI00-02, KITTI03, KITTI04-12, TUM1-3, EuRoC, Asus) but no validation that these files are well-formed or consistent. Different datasets use slightly different naming conventions. A contributor could add a validation utility and tests to catch calibration format issues early.

• [ ] Create src/CalibrationValidator.cpp with functions to validate required YAML fields for each camera type (e.g., Camera.fx, Camera.fy for all; bf for stereo; depthMapFactor for RGB-D)
• [ ] Add tests/CalibrationValidatorTest.cc with test cases for each .yaml format in Examples/
• [ ] Create a CLI tool tools/validate_calibration.cc that can be used to check user-provided calibration files
• [ ] Document expected YAML schema in a new Examples/CALIBRATION_FORMAT.md referencing the actual .yaml files in the repo

• Add unit tests for ORBextractor feature detection (Examples/Monocular/mono_euroc.cc calls ORBextractor but no test suite in visible file list). Create test_orb_features.cc validating descriptor count, scale consistency, and rotation invariance on synthetic/known images.
• Document the .yaml configuration schema in YAML comments. Examples/Monocular/EuRoC.yaml, EuRoC_Timesamples/TUM*.yaml, and Stereo/EuRoC.yaml lack inline documentation—add parameter descriptions (e.g., what does Camera.fx vs Camera.k1 mean, thresholds for LoopClosing.covisibilityConsistencyTh).
• Create a parameter tuning guide with concrete examples. Add Examples/CONFIG_TUNING.md showing (a) how to calibrate a custom camera and populate EuRoC.yaml, (b) adjusting ORB.nFeatures for fast vs. slow hardware, (c) tweaking loop closure sensitivity for small vs. large loops—critical for practitioners bringing new datasets.

ORB-SLAM2 is an academic SLAM research project with moderate security posture. Primary concerns include significantly outdated dependencies (dating back to 2017), vendored third-party libraries that may not receive timely security updates, and lack of formal security documentation. The project lacks typical injection vulnerabilities (SQL, XSS) as it's a computer vision library rather than a web application. However, the age of the codebase and absence of dependency maintenance practices present moderate risk. For production use, comprehensive dependency auditing and updates are essential. The ROS integration introduces network-based risks that should be carefully managed in deployment scenarios.

• Medium · Outdated Dependencies Information — README.md, Dependencies.md. The README indicates support for OpenCV 3 and Eigen 3.3 with a note from January 2017. These are significantly outdated versions that may contain known security vulnerabilities. The dependency file (Dependencies.md) was not provided for analysis, but the age of the project suggests dependencies have not been updated in several years. Fix: Update all dependencies to their latest stable versions. Review and patch OpenCV, Eigen, and other third-party libraries (especially DBoW2 in Thirdparty/) for known CVEs. Implement a dependency management strategy with regular updates.
• Medium · Third-party Library Dependency - DBoW2 — Thirdparty/DBoW2/. The project includes DBoW2 as a vendored dependency in Thirdparty/. The last update information visible is from the original author's repository. Vendored dependencies can become stale and miss critical security patches if not actively maintained. Fix: Regularly audit and update the vendored DBoW2 library. Consider using a package manager instead of vendoring, or establish a process to periodically sync with upstream security patches.
• Low · Missing Input Validation Documentation — Examples/Monocular/*.yaml, Examples/Stereo/*.yaml, Examples/RGB-D/*.yaml. Configuration files (YAML files in Examples/) are loaded and processed without visible input validation framework. While this appears to be a research/academic project, processing external configuration files without documented validation could lead to unexpected behavior. Fix: Document the expected format and constraints for YAML configuration files. Implement schema validation and error handling for configuration loading. Validate camera calibration parameters and file paths.
• Low · No Security Policy or Vulnerability Disclosure — Repository root. The repository lacks a SECURITY.md or similar file documenting responsible disclosure practices or security policies. This is typical for academic projects but could hinder security issue reporting. Fix: Add a SECURITY.md file with responsible disclosure guidelines and contact information for reporting security issues. Consider adding security-related documentation.
• Low · ROS Integration Security — Examples/ROS/ORB_SLAM2/. The project includes ROS integration examples (Examples/ROS/) that communicate via ROS topics and services. ROS topics can be accessed by any process with network access to the ROS master, potentially exposing camera data and SLAM state information. Fix: Document security considerations for ROS deployments. Implement ROS network security measures (firewall rules, ROS_DOMAIN_ID filtering). Consider encrypting ROS communications in sensitive environments. Validate ROS message formats.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.