gps-denied-onboard/_docs/00_research/01_source_registry/C1_vio.md

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)