# Source Registry — C1 — Visual / Visual-Inertial Odometry candidates

> Mode A Phase 2 — engine Step 2 (Source Tiering & Exhaustive Web Investigation).
> Critical-novelty sensitivity per Step 0.5 in `../00_question_decomposition.md`. Time windows applied:
> - **Lead-candidate / SOTA claims**: prefer sources within last 6 months; up to 18 months if older is the official authority.
> - **Library/SDK API behaviour**: must reflect the currently shipped version at search time (`context7` mandatory per lead candidate).
> - **Established baselines** (KLT, RANSAC, EKF, ORB, SIFT, GTSAM): no time window.
>
> This file replaces a section of the previous monolithic `01_source_registry.md`. See `00_summary.md` for the full category index. Investigation order is tracked in `../00_question_decomposition.md` and the cross-category Investigation Status table in `00_summary.md`.

---

### Source #43
- **Title**: VINS-Mono — A Robust and Versatile Monocular Visual-Inertial State Estimator (HKUST-Aerial-Robotics)
- **Link**: https://github.com/HKUST-Aerial-Robotics/VINS-Mono ; LICENCE: https://github.com/HKUST-Aerial-Robotics/VINS-Mono/blob/master/LICENCE
- **Tier**: L1 (canonical reference implementation; published in IEEE T-RO 2018 by Qin, Li, Shen)
- **Publication Date**: original 2018; repository last meaningful update 2024-02-25 (per GitHub commit log; 2024-05-23 simulation-data commit only)
- **Timeliness Status**: ⚠️ **Borderline.** ~24 months since the last meaningful master-branch commit at access time (2026-05-07). Established baseline that does NOT trigger Step 0.5's 18-month timeliness rejection because (a) IEEE T-RO publication is the canonical authority for the algorithm, (b) downstream forks (vins-mono-android, embedded variants) keep the algorithm class actively deployed.
- **Version Info**: No GitHub releases / tags (master-branch-only project). Stars 5,829.
- **Target Audience**: Mono+IMU VIO implementers; UAV state estimation researchers
- **Research Boundary Match**: **Full match for the candidate's pinned mode** — monocular camera + IMU producing 6-DoF metric pose. The VINS-Mono README explicitly names this configuration as primary.
- **Summary**: Optimization-based sliding-window monocular VIO. Features: efficient IMU pre-integration (Forster et al. 2017), automatic initialization, online camera-IMU extrinsic calibration, online camera-IMU temporal calibration, failure detection + recovery, loop detection (DBoW2-based), global pose graph optimization. Output is metric-scale 6-DoF pose at IMU rate (typically 100–200 Hz) with covariance from the optimization Hessian. **License: GPL-3.0 (copyleft viral)** — every binary distribution requires source disclosure for the entire linked binary; relevant for dual-use deployment if the companion image is sold or transferred to a customer.
- **Related Sub-question**: SQ3+SQ4 / C1 lead candidate


### Source #44
- **Title**: VINS-Fusion — Optimization-based multi-sensor state estimator (HKUST-Aerial-Robotics)
- **Link**: https://github.com/HKUST-Aerial-Robotics/VINS-Fusion ; LICENCE: https://github.com/HKUST-Aerial-Robotics/VINS-Fusion/blob/master/LICENCE
- **Tier**: L1 (canonical reference; superset of VINS-Mono)
- **Publication Date**: original 2019 (Qin, Cao, Pan, Shen — ICRA workshop / IROS); repository last update 2024-05-23
- **Timeliness Status**: ⚠️ **Borderline.** ~24 months since the last update at access time. Same Step-0.5 reasoning as VINS-Mono — established class.
- **Version Info**: master-branch-only. Stars 4,476. Top-ranked open-source stereo-VIO on KITTI Odometry as of January 2019.
- **Target Audience**: Multi-sensor VIO implementers (mono+IMU, stereo, stereo+IMU, +GPS fusion)
- **Research Boundary Match**: **Full match** for monocular+IMU mode. VINS-Fusion README explicitly enumerates four sensor configurations (mono+IMU, stereo, stereo+IMU, +GPS toy example).
- **Summary**: Superset of VINS-Mono adding stereo and GPS-fusion modes. Same algorithmic core (sliding-window optimization with IMU pre-integration). Online spatial + temporal camera-IMU calibration; visual loop closure; ROS Kinetic/Melodic build dependency. **License: GPL-3.0** — same dual-use distribution constraint as VINS-Mono. Independent KAIST benchmark (Source #46) found VINS-Fusion CPU mode + VINS-Fusion-imu **fail to run** on Jetson TX2 (insufficient memory and CPU); GPU-accelerated VINS-Fusion-gpu does run on TX2. Implication for project: VINS-Fusion-imu on Jetson Orin Nano Super is feasible but not certain; needs MVE.
- **Related Sub-question**: SQ3+SQ4 / C1 lead candidate


### Source #45
- **Title**: OpenVINS — An open source platform for visual-inertial navigation research (Robot Perception and Navigation Group, U. of Delaware — rpng)
- **Link**: https://github.com/rpng/open_vins ; docs: https://docs.openvins.com/ ; LICENSE: https://github.com/rpng/open_vins/blob/master/LICENSE
- **Tier**: L1 (canonical research implementation; ICRA 2020 paper Geneva, Eckenhoff, Lee, Yang, Huang)
- **Publication Date**: original 2020; latest tagged release v2.7 = 2023-06; ongoing master-branch commits through 2024–2025 (latest issue threads through Feb 2025)
- **Timeliness Status**: ✅ Currently valid (master branch active; latest tagged release ~35 months but library is in stable/maintenance mode with continued issue triage).
- **Version Info**: Stars 2,828; 30 contributors; 12 releases. v2.7 is the current tagged stable.
- **Target Audience**: MSCKF/EKF VIO implementers; researchers needing a reference MSCKF
- **Research Boundary Match**: **Full match** for monocular+IMU mode. OpenVINS supports mono, stereo, multi-camera (1–N cameras) + IMU; mono is a documented first-class mode.
- **Summary**: Modular MSCKF (Multi-State Constraint Kalman Filter) implementation built around an Extended Kalman filter that fuses inertial state with sparse visual feature tracks via the sliding-window MSCKF formulation (Mourikis & Roumeliotis 2007). Supports SLAM features (in-state landmarks) plus pure MSCKF features (out-of-state). ROS1 + ROS2 (Humble) builds documented; Jetson Orin Nano Dev Kit + JetPack 6 + ROS 2 Humble compilation **confirmed working** by community contributors (rpng/open_vins issue #421, fdcl-gwu/openvins_jetson_realsense Nov 2025 setup guide). **License: GPL-3.0** — same dual-use distribution constraint. Reported latency ~270 ms on Xavier NX (4-core, ARM, 40% CPU usage) per issue #164; needs Jetson-Orin-Nano-Super MVE for production budget verification.
- **Related Sub-question**: SQ3+SQ4 / C1 lead candidate


### Source #46
- **Title**: Run Your Visual-Inertial Odometry on NVIDIA Jetson — Benchmark Tests on a Micro Aerial Vehicle (Jeon, Jung, Lee, Choi, Myung — KAIST)
- **Link**: https://arxiv.org/abs/2103.01655 ; KAIST VIO dataset: https://github.com/zinuok/kaistviodataset
- **Tier**: L1 (peer-reviewed conference, IROS-track preprint with public dataset)
- **Publication Date**: arXiv 2021-03-02
- **Timeliness Status**: ⚠️ Older than the 18-month Critical-novelty window, but **uniquely authoritative** for the specific question "do these VIO algorithms run on a Jetson?"; the included algorithms (VINS-Mono, VINS-Fusion, ROVIO, ALVIO, Stereo-MSCKF, Kimera, ORB-SLAM2-stereo) are all classical baselines whose runtime characteristics on ARM CPUs have not changed materially. Jetson hardware comparison (TX2 / Xavier NX / AGX Xavier) does NOT include Orin Nano — must extrapolate.
- **Version Info**: Conference paper.
- **Target Audience**: UAV state-estimation engineers picking a VIO for a Jetson companion
- **Research Boundary Match**: **Strong match for the question**, partial for the hardware (no Orin Nano). KAIST VIO dataset is indoor mocap, not UAV-aerial-nadir — the *latency / CPU / memory* numbers transfer; the *accuracy* numbers do not transfer to our domain.
- **Summary**: Comprehensive benchmark of 9 algorithms on TX2, Xavier NX, AGX Xavier: VINS-Mono, VINS-Fusion (CPU), VINS-Fusion-gpu, VINS-Fusion-imu, ROVIO, Stereo-MSCKF, ALVIO, Kimera, ORB-SLAM2-stereo. **Hard findings**: (a) on TX2, **VINS-Fusion (CPU) and VINS-Fusion-imu fail to run** due to insufficient memory and CPU performance — VINS-Fusion-gpu does run; (b) all algorithms except ROVIO show >100% CPU usage (multi-core utilisation, OK for our 6-core Orin Nano A78AE); (c) Kimera has the highest memory usage among VIO methods (numerous computations per keyframe), failure-prone on Xavier NX-class memory; (d) Stereo-MSCKF has the lowest memory among stereo VIOs; (e) ROVIO has the lowest CPU usage owing to its patch-tracking formulation. **Implication for project**: Jetson Orin Nano Super (8 GB shared, 6-core A78AE, Ampere GPU, 67 TOPS sparse INT8) is between Xavier NX and AGX Xavier in CPU performance and memory; algorithms passing on Xavier NX should pass on Orin Nano Super, but VINS-Fusion-imu's TX2 failure is a yellow-flag for memory pressure under co-resident C2/C3/C5 modules.
- **Related Sub-question**: SQ3+SQ4 / C1 (VINS-Mono / VINS-Fusion / OpenVINS / Kimera / Stereo-MSCKF / ROVIO Jetson runtime evidence), SQ5 (resource-budget failure modes)


### Source #47
- **Title**: OKVIS2 — Realtime Scalable Visual-Inertial SLAM with Loop Closure (Leutenegger, ETH/Imperial/TUM Smart Robotics Lab)
- **Link**: https://github.com/ethz-mrl/okvis2 ; arXiv: https://arxiv.org/abs/2202.09199 ; LICENSE: https://github.com/ethz-mrl/okvis2/blob/main/LICENSE
- **Tier**: L1 (canonical implementation; arXiv 2022 by paper author)
- **Publication Date**: original arXiv 2022; OKVIS2-X T-RO 2025 successor (Boche, Jung, Laina, Leutenegger — IEEE T-RO 2025, vol 41 pp 6064–6083, DOI 10.1109/TRO.2025.3619051; arXiv 2510.04612, Oct 2025). Repository last push 2026-03-17 (ethz-mrl/OKVIS2-X).
- **Timeliness Status**: ✅ **Current.** Active development through 2026; OKVIS2-X is the most recent published VI-SLAM system in this class.
- **Version Info**: ethz-mrl/okvis2 (core) and ethz-mrl/OKVIS2-X (multi-sensor extension with optional GNSS / LiDAR / dense depth).
- **Target Audience**: Factor-graph VI-SLAM implementers; mid-large-scale loop-closure use cases
- **Research Boundary Match**: **Full match** for monocular+IMU mode. OKVIS2 README + paper explicitly support mono and multi-camera VI configurations. OKVIS2-X adds GNSS fusion (relevant: VINS-Fusion-style GPS-when-available drop-in IS the project's eventual posture in non-spoofed regions).
- **Summary**: Factor-graph VI-SLAM with bounded-size optimization. Innovation: pose-graph edges from marginalised observations can be "seamlessly turned back into observations" upon loop closure, reviving old landmarks and reprojection errors. Includes lightweight CNN segmentation for dynamic-region removal. OKVIS2-X (2025) generalises the core to fuse multi-camera + IMU + optional GNSS + LiDAR/depth — directly aligned with project's "VIO that may opportunistically fuse a non-spoofed GPS update" pattern and AC-NEW-2's spoof-promotion path. **License: 3-clause BSD (permissive)** — no copyleft / dual-use distribution friction. Note: GitHub UI shows "Other (NOASSERTION)" because of the standard BSD clause language pattern; the LICENSE file is canonical 3-clause BSD.
- **Related Sub-question**: SQ3+SQ4 / C1 lead candidate (factor-graph + permissive license + active maintenance)


### Source #48
- **Title**: OKVIS2-X: Open Keyframe-based Visual-Inertial SLAM Configurable with Dense Depth or LiDAR, and GNSS (Boche, Jung, Laina, Leutenegger — TUM / ETH Zurich Smart Robotics Lab)
- **Link**: https://github.com/ethz-mrl/OKVIS2-X ; arXiv: https://arxiv.org/abs/2510.04612 ; IEEE T-RO 2025 vol 41 pp 6064–6083 DOI 10.1109/TRO.2025.3619051
- **Tier**: L1 (peer-reviewed IEEE Transactions on Robotics, Special Issue Visual SLAM 2025)
- **Publication Date**: arXiv 2025-10-04; T-RO 2025 vol 41
- **Timeliness Status**: ✅ Current (within 6-month Critical-novelty window)
- **Version Info**: 295 stars; 38 forks; 2 contributors; created 2025-09-23, last push 2026-03-17. License: NOASSERTION on GitHub UI; per-paper license follows ethz-mrl convention (BSD-3 derived).
- **Target Audience**: Multi-sensor SLAM researchers; large-scale VI-SLAM with optional GNSS/LiDAR
- **Research Boundary Match**: **Strong match** — extends OKVIS2 monocular+IMU mode with optional GNSS fusion (Visual-Inertial SLAM with Tightly-Coupled Dropout-Tolerant GPS Fusion lineage from IROS 2022). Project's `MAV_CMD_SET_EKF_SOURCE_SET` switch + companion-side spoof-detection conceptually mirrors OKVIS2-X's "GPS as drop-out-tolerant signal".
- **Summary**: Non-trivial extension of OKVIS2; submap-based volumetric occupancy mapping. Demonstrates that the OKVIS2 factor-graph backbone can absorb spoofing-aware GPS without re-architecting. Useful as architectural template for project's C5 estimator + C8 adapter integration. License: same as OKVIS2 (BSD-3-derived). Two named contributors (bochsim, SebsBarbas) actively pushing through Mar 2026.
- **Related Sub-question**: SQ3+SQ4 / C1 (OKVIS2 lineage; VI-SLAM with optional GPS/LiDAR), SQ8 (GPS-fusion dropout-tolerant lineage)


### Source #49
- **Title**: Kimera-VIO — Visual Inertial Odometry with SLAM capabilities and 3D Mesh generation (MIT-SPARK)
- **Link**: https://github.com/MIT-SPARK/Kimera-VIO ; LICENSE.BSD: https://github.com/MIT-SPARK/Kimera-VIO/blob/master/LICENSE.BSD
- **Tier**: L1 (canonical implementation by MIT SPARK Lab)
- **Publication Date**: original 2020 (Rosinol, Abate, Chang, Carlone — ICRA 2020); ongoing development through 2024–2025 issue threads (Dec 2024 / Feb 2025 ROS2 / mono-inertial discussion).
- **Timeliness Status**: ✅ Active maintenance (recent issues / PRs through 2025).
- **Version Info**: master-branch-only; LICENSE.BSD = BSD 2-Clause "Simplified".
- **Target Audience**: VI-SLAM + mesh-mapping researchers
- **Research Boundary Match**: **Partial.** Stereo+IMU is the primary supported configuration; mono+IMU is **optional but documented**. Kimera also produces 3D mesh and high-level semantic labels (relevant to neither C1 nor the project's bandwidth budget — overhead).
- **Summary**: Frontend (image processing + IMU pre-integration) + Backend (factor-graph optimization in iSAM2 or GTSAM) + Mesher + Pose-Graph-Optimizer. **License: BSD 2-Clause (permissive)** — no dual-use distribution friction. **Penalty for project**: Source #46 KAIST benchmark found Kimera has highest memory usage among the VIOs tested (numerous computations per keyframe), and Kimera failed to fit on Xavier-NX-class memory under multi-process load. Mesh + semantic features are unused by the project — Kimera's overhead is unjustified vs OKVIS2 / OpenVINS for the project's narrow C1 mandate. **Status**: viable secondary fallback if OKVIS2 / VINS-Mono runtime issues arise; not a lead candidate due to overhead misfit.
- **Related Sub-question**: SQ3+SQ4 / C1 secondary candidate (BSD-permissive but resource-heavy)


### Source #50
- **Title**: DROID-SLAM — Deep Visual SLAM for Monocular, Stereo, and RGB-D Cameras (princeton-vl, Teed & Deng)
- **Link**: https://github.com/princeton-vl/droid-slam ; arXiv: https://arxiv.org/abs/2108.10869 ; NeurIPS 2021
- **Tier**: L1 (canonical reference)
- **Publication Date**: NeurIPS 2021; repository latest tagged baseline.
- **Timeliness Status**: ✅ Foundational reference; DPV-SLAM (Source #51) is the lighter successor.
- **Version Info**: master-branch-only.
- **Target Audience**: Deep-learning-based VO/VSLAM researchers
- **Research Boundary Match**: **Disqualified by hardware budget.** Inference requires ≥11 GB GPU VRAM per official README; project budget is 8 GB **shared CPU+GPU** on Jetson Orin Nano Super, leaving <8 GB for VO + VPR + matcher + estimator + cache co-resident. DROID-SLAM is also **monocular VO/SLAM, not VIO** — no native IMU fusion; metric scale recovery requires external scale alignment.
- **Summary**: Recurrent dense bundle adjustment over a complete history of camera poses. State-of-the-art accuracy on TartanAir / EuRoC / TUM-RGBD at the cost of GPU memory. **Disqualified outright for C1 lead** by AC-4.2 (≤8 GB shared RAM) and the lack of IMU fusion that would require an additional ESKF/UKF wrapping. Kept as **reference baseline** to be cited as "what we cannot afford" in `solution_draft01`.
- **Related Sub-question**: SQ3+SQ4 / C1 disqualified candidate


### Source #51
- **Title**: DPVO — Deep Patch Visual Odometry (princeton-vl, Teed, Lipson, Deng) + DPV-SLAM (Lipson, Teed, Deng — ECCV 2024)
- **Link**: https://github.com/princeton-vl/DPVO ; LICENSE: https://github.com/princeton-vl/DPVO/blob/main/LICENSE ; ECCV 2024 paper: https://www.ecva.net/papers/eccv_2024/papers_ECCV/papers/00272.pdf
- **Tier**: L1 (canonical implementation; NeurIPS 2023 + ECCV 2024)
- **Publication Date**: NeurIPS 2023 (DPVO); ECCV 2024 (DPV-SLAM); repository last update 2024-10-12.
- **Timeliness Status**: ⚠️ Borderline. ~19 months since last code update; ECCV-2024 publication of DPV-SLAM keeps the algorithm class within the 6-month claim window for the SLAM successor.
- **Version Info**: 989 stars; primary languages C++ / Python / CUDA. **License: MIT (permissive)** — no dual-use distribution friction.
- **Target Audience**: Deep-learning VO/SLAM with reduced memory footprint
- **Research Boundary Match**: **Partial.** DPVO is **monocular VO only — no IMU fusion**. Output pose is in arbitrary scale (no metric scale recovery). To be a viable C1 candidate the project must wrap DPVO with an external IMU+scale-fusion stage (loosely-coupled ESKF / VIO-fusion module). This makes DPVO **not a drop-in C1** like VINS-Mono / OpenVINS / OKVIS2; it is a **VO module that needs a separate VIO wrapper**.
- **Summary**: Sparse patch tracking + differentiable bundle adjustment back end. Outperforms DROID-SLAM on TartanAir / EuRoC ATE while using ~1/3 of DROID-SLAM's GPU memory (DROID-SLAM: 8.7 GB VO mode vs DPVO: ~3 GB). DPV-SLAM (Lipson, Teed, Deng — ECCV 2024) adds full SLAM capability with 4–5 GB GPU usage. **Jetson runtime evidence**: indirect via DPVO-QAT++ (Source #52) — peak reserved memory 1.02 GB on RTX 4060 (8 GB) after INT8 fake-quant + custom CUDA kernel fusion; not directly tested on Jetson Orin Nano. **Status for C1**: pure-VO candidate (must be paired with separate IMU integration to deliver metric scale + attitude); would not satisfy "monocular VIO" gate alone, but viable as the *VO half* of a hybrid C1+C5 design.
- **Related Sub-question**: SQ3+SQ4 / C1 conditional candidate (VO not VIO; needs external IMU wrapper)


### Source #52
- **Title**: DPVO-QAT++: Heterogeneous QAT and CUDA Kernel Fusion for High-Performance Deep Patch Visual Odometry (Cheng Liao)
- **Link**: https://arxiv.org/abs/2511.12653 ; project HTML: https://arxiv.org/html/2511.12653
- **Tier**: L2 (single-author preprint, code partially released; no peer-review yet)
- **Publication Date**: arXiv 2025-11-16 (within 6-month Critical-novelty window)
- **Timeliness Status**: ✅ Current
- **Version Info**: arXiv preprint; code & weights released for QAT-only and fused-CUDA variants.
- **Target Audience**: Embedded-platform DPVO deployers
- **Research Boundary Match**: **Partial.** Hardware tested = RTX 4060 (8 GB) + Intel Core Ultra 5-125H + 32 GB RAM — desktop GPU, NOT Jetson Orin Nano. Direct extrapolation requires Jetson MVE; Orin Nano Super's Ampere GPU is architecturally similar but smaller than RTX 4060.
- **Summary**: Quantization-Aware Training framework for DPVO with fused CUDA kernels. Reduces peak GPU memory from 1.94 GB → 1.02 GB (-47%) on a representative TartanAir sequence; +34.6% median FPS on TartanAir, +26.7% on EuRoC; -22.8 ms / -19.7 ms median P99 tail latency on TartanAir / EuRoC respectively. Heterogeneous precision: front-end pseudo-quantization (FP16/FP32 with INT8 simulation) + FP32 back-end geometric solver. **Implication for project**: shows DPVO has a documented Jetson-suitable footprint **path** but not a Jetson-Orin-Nano measurement. ATE accuracy comparable to baseline DPVO across 32 TartanAir + 11 EuRoC validation sequences. Notable: requires a teacher-student distillation training pipeline before deployment — adds operational complexity vs classical VINS-* / OpenVINS / OKVIS2.
- **Related Sub-question**: SQ3+SQ4 / C1 supporting evidence for DPVO embedded feasibility


### Source #53
- **Title**: Pure VO baseline — KLT optical flow + 5-point essential matrix or homography RANSAC (OpenCV reference)
- **Link**: https://docs.opencv.org/4.x/d4/dee/tutorial_optical_flow.html ; representative public implementation: https://github.com/alishobeiri/Monocular-Video-Odometery (MIT, 2018) ; tutorial reference: https://zxh.me/posts/2022-12-19-monocular-visual-odometry/
- **Tier**: L1 (OpenCV official documentation) + L2 (representative public implementations)
- **Publication Date**: OpenCV docs continuously updated; tutorial 2022-12; reference implementation 2018 (algorithmic class is foundational, no time window per Step 0.5)
- **Timeliness Status**: ✅ Foundational baseline (no time window).
- **Version Info**: OpenCV `cv::calcOpticalFlowPyrLK` (KLT) + `cv::findEssentialMat` (5-point Nister) or `cv::findHomography` with RANSAC.
- **Target Audience**: Implementers needing a transparent low-complexity fallback
- **Research Boundary Match**: **Full match for the simple-baseline candidate.** Suits planar nadir-down UAV at altitude (Ukrainian steppe is ~planar at 1 km AGL — homography is geometrically appropriate; for non-planar relief the essential matrix path is more appropriate but adds scale-recovery work).
- **Summary**: Established classical pipeline: Shi-Tomasi or FAST corner detection → KLT pyramidal optical flow tracking → 5-point essential matrix or homography RANSAC → relative pose with arbitrary scale (must be metric-scale-aligned via IMU integration externally). Reference implementations widely available in OpenCV samples and pedagogical repos. **Status**: candidate as the project's `Simple baseline / known-runnable / known-failure-mode` C1 option per Component Option Breadth rule. Not a lead, but mandatory fallback presence per the research engine's "include at least one simple baseline" rule.
- **Related Sub-question**: SQ3+SQ4 / C1 simple-baseline candidate


### Source #54
- **Title**: OpenVINS — `context7` per-mode capability lookup (`/rpng/open_vins`, master)
- **Link**: context7 query against `/rpng/open_vins`, accessed 2026-05-08; canonical doc references returned: `https://github.com/rpng/open_vins/blob/master/docs/gs-tutorial.dox`, `https://github.com/rpng/open_vins/blob/master/docs/gs-datasets.dox`, `https://github.com/rpng/open_vins/blob/master/docs/gs-calibration.dox`, `https://github.com/rpng/open_vins/blob/master/docs/propagation-analytical.dox`
- **Tier**: L1 (project-official documentation reachable via the project's documentation generator)
- **Publication Date**: live docs (master, accessed 2026-05-08)
- **Timeliness Status**: ✅ Within Critical-novelty window (active master + community evidence through 2025–2026)
- **Version Info**: master HEAD at access time (no tagged release for ROS 2 path; ROS 1 / ROS 2 build paths both documented)
- **Target Audience**: System architects + C1 implementer
- **Research Boundary Match**: **Full match** for monocular + IMU mode. The `subscribe.launch.py` ROS 2 launch script (and its ROS 1 sibling) declare `use_stereo` and `max_cameras` as DeclareLaunchArguments — setting `use_stereo:=false max_cameras:=1` selects monocular operation; `config:=` selects an estimator-config directory (`euroc_mav`, `tum_vi`, `rpng_aruco`, …). KALIBR + RPNG IMU intrinsic calibration models are both documented in `propagation-analytical.dox` with the corresponding state-vector composition.
- **Summary**: Confirms documentary evidence for OpenVINS' three sensor configurations exposed at the launch layer (mono / stereo / multi-camera), all with IMU mandatory; confirms the project's pinned mode (`use_stereo:=false max_cameras:=1`) is a first-class launch configuration that requires no source patch. Confirms that estimator config files in `ov_msckf/config/<dataset>/estimator_config.yaml` are the parameter-tuning surface and that supported IMU intrinsic models include both KALIBR and RPNG. **Open**: `context7` Disqualifier-Probe query did not surface explicit per-mode latency/memory limits or sub-20-Hz validation evidence; those constraints carry into the Jetson-Orin-Nano-Super hardware MVE (D-C1-2 deferred phase).
- **Related Sub-question**: SQ3+SQ4 / C1 — OpenVINS per-mode API capability verification (Mandatory `context7` lookup per Per-Mode API Capability Verification rule)


### Source #55
- **Title**: VINS-Mono — official README + VINS-Fusion `context7` per-mode capability lookup (`/hkust-aerial-robotics/vins-fusion`, master) [cross-source documentary evidence for the mono+IMU mode shared with VINS-Mono]
- **Link**: VINS-Mono README — https://raw.githubusercontent.com/HKUST-Aerial-Robotics/VINS-Mono/master/README.md (accessed 2026-05-08); VINS-Fusion docs — context7 query against `/hkust-aerial-robotics/vins-fusion`, accessed 2026-05-08, canonical reference returned: https://github.com/hkust-aerial-robotics/vins-fusion/blob/master/README.md
- **Tier**: L1 (project-official READMEs of both repos)
- **Publication Date**: VINS-Mono README — 2019-01-11 last major revision (master-branch only, no tagged releases); VINS-Fusion docs — live (master, accessed 2026-05-08)
- **Timeliness Status**: ⚠️ borderline (per Step 0.5 timeliness — VINS-Mono master last meaningful commit 2024-02-25 / 2024-05-23; older than the 18-month preferred window for live API behaviour, but the algorithm class remains the canonical mono+IMU sliding-window VIO referenced by 2025 community work — see Fact #36)
- **Version Info**: VINS-Mono master HEAD; depends on Ceres v1.14.0 (versions ≥2.0.0 have build issues per README). VINS-Fusion master HEAD has `euroc_mono_imu_config.yaml` as a first-class config.
- **Target Audience**: System architects + C1 implementer
- **Research Boundary Match**: **Full match** for the project's pinned mode (mono + IMU). VINS-Mono is single-mode by construction — "real-time SLAM framework for **Monocular Visual-Inertial Systems**" — the project's pinned mode is the only mode the project will use the binary in. VINS-Fusion `euroc_mono_imu_config.yaml` is the documentary cross-source evidence that the algorithmic mono+IMU path remains a first-class configuration in the same authors' active fork.
- **Summary**: Confirms VINS-Mono = monocular + IMU only (single mode); ROS Kinetic / Ubuntu 16.04 reference build; pinhole + MEI camera models supported; rolling-shutter support with calibrated reprojection error <0.5 px; online camera-IMU extrinsic + temporal calibration; loop closure via DBoW2; pose-graph reuse and map merge supported. **Critical recommended-input bound**: README §5.1 — *"The image should exceed 20Hz and IMU should exceed 100Hz."* — the project's nav cam target is 3 fps; this is a documentary signal that VIO performance below the recommended frame rate is not validated by the upstream authors. License: GPLv3 (confirmed in README §8). **Cross-source note**: VINS-Fusion `euroc_mono_imu_config.yaml` is named explicitly in `context7` results and uses the same algorithmic core; treat as evidence for VINS-Mono's mono+IMU mode while honouring the per-mode rule that VINS-Fusion's mono+IMU mode is a separately-cataloged candidate (Fact #29).
- **Related Sub-question**: SQ3+SQ4 / C1 — VINS-Mono per-mode API capability verification (Mandatory `context7` lookup per Per-Mode API Capability Verification rule, with cross-source documentary evidence from VINS-Fusion since VINS-Mono itself is not indexed in `context7`)


### Source #56
- **Title**: OKVIS2 — official README (`smartroboticslab/okvis2`, main)
- **Link**: https://raw.githubusercontent.com/smartroboticslab/okvis2/main/README.md (accessed 2026-05-08); papers cited in README: arXiv:2202.09199 (Leutenegger 2022), IJRR 2015, RSS 2013
- **Tier**: L1 (project-official README; arXiv canonical paper)
- **Publication Date**: README live; canonical paper 2022-02; OKVIS2 master last push within the Critical-novelty window (per Fact #36 timeliness audit, OKVIS2-X 2026-03-17 push confirms active)
- **Timeliness Status**: ✅ Fully within Critical-novelty window
- **Version Info**: OKVIS2 main HEAD; cmake build with optional ROS 2 wrapping (`BUILD_ROS2=ON`); optional sky-segmentation CNN via LibTorch (`USE_NN=OFF` to disable)
- **Target Audience**: System architects + C1 implementer + Step-7.5 reviewer
- **Research Boundary Match**: **Full match** for the project's pinned mode (mono + IMU). README confirms multi-camera support (camera frames `C_i` for the i-th camera) plus IMU mandatory; mono operation is a documented configuration via the example apps (`okvis_app_synchronous`, `okvis_app_realsense`). OKVIS2-X is the GNSS-fusion extension (T-RO 2025) that aligns architecturally with the project's spoof-promotion path.
- **Summary**: Confirms OKVIS2 = keyframe-based VI-SLAM (factor-graph backbone with loop closure); BSD-3 license (no copyleft); coordinate-frame contract (`W` world, `C_i` cameras, `S` IMU, `B` body); state representation (`T_WS` pose + velocity + gyro/accel biases); two-callback API (`setOptimisedGraphCallback` for batch updates incl. loop closure + `setImuCallback` for high-rate prediction). Calibration prerequisites: camera intrinsics + camera-IMU extrinsics + IMU noise parameters + tight time sync (Kalibr toolchain explicitly recommended). Optional LibTorch sky-segmentation CNN can be disabled (`USE_NN=OFF`) to remove a major Jetson dependency. ROS 2 build path (`BUILD_ROS2=ON`) with `okvis_node_realsense.launch.xml`, `okvis_node_realsense_publisher.launch.xml`, `okvis_node_subscriber.launch.xml`, `okvis_node_synchronous.launch.xml`. **Health warning** in README: poor calibration → poor results; this is shared with all VI candidates but is more strongly emphasised in OKVIS2 docs. **Open**: README does not state explicit minimum frame rate (cf. VINS-Mono's documented 20 Hz minimum) — keyframe-based selection generally tolerates lower input frame rates than sliding-window optimisation; this needs explicit Jetson MVE validation at 3 fps.
- **Related Sub-question**: SQ3+SQ4 / C1 — OKVIS2 per-mode API capability verification (Mandatory `context7` lookup per Per-Mode API Capability Verification rule, with WebFetch fallback to official README since `context7` returned no match)