gps-denied-onboard/_docs/00_research/02_fact_cards/C1_vio.md

Fact Cards — C1: Visual / Visual-Inertial Odometry

Mode A Phase 2 — engine Step 3 (Fact Extraction & Evidence Cards). Extracted from sources logged in ../01_source_registry/C1_vio.md (see ../01_source_registry/00_summary.md for index). Confidence labels: ✅ High (L1 / verified source code), ⚠️ Medium (L1/L2 with caveat), ❓ Low (L3/L4 inferential). Bound to sub-questions in ../00_question_decomposition.md.

Index: ../00_summary.md. Sibling categories: SQ6 (FC external positioning), SQ1 (existing systems), SQ2 (canonical pipeline), C2 (VPR), C3 (matchers).

Facts in this file: VIO candidate enumeration (VINS-Mono, VINS-Fusion, OpenVINS, OKVIS2, Kimera-VIO, DROID-SLAM, DPVO, KLT+RANSAC baseline) + Plan-phase decisions D-C1-1, D-C1-2 + C1 working conclusions.

---

SQ3+SQ4 / C1 — Visual / Visual-Inertial Odometry candidate enumeration

Project's pinned mode for every C1 candidate (binding): monocular ADTi 20MP nav camera @ 3 fps + IMU from FC over MAVLink @ ≥100 Hz, on Jetson Orin Nano Super (JetPack/CUDA/TensorRT, 8 GB shared LPDDR5, 25 W TDP), producing relative 6-DoF metric pose between consecutive frames + per-axis covariance, with attitude (yaw + pitch) hard-contract σ ≤ 5° at 1 σ (Fact #24), output cadence ≥3 Hz, no in-flight network, license compatible with onboard-binary distribution to a dual-use customer.

Per the engine's "Per-Mode API Capability Verification" rule, any candidate marked Selected requires a context7 lookup (mode enum + project's exact mode runnable example + disqualifier probe) AND a per-numbered-Restriction × per-numbered-AC sub-matrix. This session covers candidate enumeration + preliminary applicability assessment only; context7 verification and the structured sub-matrix are deferred to the next session per the autodev context budget heuristic.

Fact #28 — VINS-Mono is a canonical monocular-only sliding-window VIO with a working Jetson-Nano deployment record but no GitHub release and ~24-month-old master branch

• Statement: VINS-Mono is the canonical mono+IMU sliding-window VIO from HKUST-Aerial-Robotics (Qin, Li, Shen — IEEE T-RO 2018). Features: efficient IMU pre-integration, automatic initialization, online camera-IMU spatial + temporal calibration, failure detection + recovery, DBoW2 loop detection, global pose-graph optimization. Output: metric-scale 6-DoF pose at IMU rate. Repository state: master-branch only (no tagged releases), 5,829 stars; last meaningful master-branch commit 2024-02-25 with a 2024-05-23 simulation-data commit. Jetson record: a 2021 IEICE paper (zinuok / KAIST) demonstrated VINS-Mono real-time on the original Jetson Nano (much weaker than Orin Nano Super) for MAV state estimation; a 2024 arXiv paper (2406.13345) showed an enhanced VINS-Mono variant achieving 50 FPS on a Raspberry Pi CM4 with on-sensor accelerated optical flow. License: GPL-3.0 (copyleft viral) — distribution of the onboard binary requires source disclosure for the entire linked binary and triggers GPL-3 anti-tivoization clauses for embedded firmware.
• Source: Source #43 (canonical), Source #46 (KAIST Jetson benchmark), Source #43-linked LICENCE for license confirmation
• Phase: Phase 2
• Target Audience: System architects + C1 implementer
• Confidence: ✅ for algorithm class, mode support, and Jetson Nano feasibility; ⚠️ for Jetson Orin Nano Super specific latency (no direct measurement — but Orin Nano Super >> Jetson Nano, so feasibility is virtually certain); ⚠️ for the maintenance-status risk implied by ~24-month-old master branch.
• Related Dimension: SQ3+SQ4 / C1 Established-production candidate
• Fit Impact: carry as lead candidate, conditional on user license decision. Algorithmic fit is excellent (canonical mono+IMU VIO with metric scale and covariance); maintenance status is borderline; GPL-3.0 license is a project-level decision required from the user before this candidate can be marked Selected — see "C1 Open Decisions" section below.

Fact #29 — VINS-Fusion is a multi-sensor superset of VINS-Mono but its monocular+IMU mode failed to run on Jetson TX2 in a 2021 KAIST benchmark; Orin Nano Super feasibility unverified

• Statement: VINS-Fusion (Qin, Cao, Pan, Shen — extension of VINS-Mono) supports four documented sensor configurations: stereo+IMU, mono+IMU, stereo only, +GPS-fusion (toy example). KITTI Odometry top-ranked open-source stereo algorithm as of January 2019. Repository state: 4,476 stars; last update 2024-05-23; same master-branch-only convention. Jetson record: KAIST 2021 benchmark (Source #46) — on Jetson TX2, both VINS-Fusion (CPU) and VINS-Fusion-imu fail to run due to insufficient memory and CPU; VINS-Fusion-gpu (GPU-accelerated front-end) runs on TX2. Orin Nano Super has more memory than TX2 (8 GB LPDDR5 shared vs TX2's 8 GB LPDDR4 shared) and stronger CPU/GPU, but the project's onboard stack is co-resident with C2 VPR + C3 matcher + C5 estimator + C6 cache → memory-pressure on the VINS-Fusion-imu path is plausible. License: GPL-3.0, same dual-use distribution constraint as VINS-Mono.
• Source: Source #44 (canonical), Source #46 (KAIST Jetson benchmark)
• Phase: Phase 2
• Target Audience: System architects + C1 implementer
• Confidence: ✅ for the multi-sensor mode support and KITTI ranking; ✅ for the 2021 TX2 failure-to-run finding; ⚠️ for Orin Nano Super viability (between TX2 and Xavier NX in CPU/memory; not yet measured).
• Related Dimension: SQ3+SQ4 / C1 Open-source candidate
• Fit Impact: carry as alternate candidate, with mandatory Jetson Orin Nano Super MVE before promotion. VINS-Mono's narrower scope (mono+IMU only, no stereo overhead) makes VINS-Mono the preferred lead within the HKUST-Aerial-Robotics family; VINS-Fusion's multi-sensor coverage is a distractor for our pinned mode. GPL-3.0 license decision is the same as VINS-Mono — see "C1 Open Decisions".

Fact #30 — OpenVINS is the most actively maintained MSCKF-class VIO and runs on Jetson Orin Nano Dev Kit + JetPack 6 + ROS 2 Humble with documented build adjustments; latency 270 ms on Xavier NX needs Orin-Nano-Super MVE

• Statement: OpenVINS (rpng, U. Delaware — Geneva, Eckenhoff, Lee, Yang, Huang — ICRA 2020) is a modular MSCKF (Multi-State Constraint Kalman Filter) implementation that fuses IMU state with sparse visual feature tracks via the Mourikis-Roumeliotis 2007 sliding-window MSCKF. Mode support: monocular, stereo, multi-camera (1–N) + IMU; mono+IMU is a documented first-class configuration. Supports SLAM features (in-state landmarks) plus pure MSCKF features. Jetson Orin Nano evidence: rpng/open_vins issue #421 (Genozen, Feb 2024, closed) confirms OpenVINS ROS 2 builds on Jetson Orin Nano Dev Kit + JetPack 6 + Ubuntu 22.04 + ROS 2 Humble after one build patch (#include <opencv2/aruco.hpp> with newer OpenCV); fdcl-gwu/openvins_jetson_realsense (Nov 2025) provides a complete setup guide for Jetson Orin Nano + Intel RealSense + librealsense compiled-from-source + --parallel-workers 1 build to avoid memory issues. Latency record: rpng/open_vins issue #164 — ~270 ms latency on Jetson Xavier NX (4 cores, 40% CPU utilisation). Recommended optimisations: subscriber queue size 1, Release builds with ARM-specific optimization flags (e.g., armv8.2-a), reduced camera resolution, prefer odometry topic over pose_imu. License: GPL-3.0, same dual-use distribution constraint as VINS-Mono / VINS-Fusion. Stars 2,828; 30 contributors; 12 releases; latest tag v2.7 (June 2023) but master branch active through 2024–2025 issue threads.
• Source: Source #45 (canonical + LICENSE + docs.openvins.com), Source #46 (KAIST Jetson benchmark for class-level CPU/memory profile), agent-tools record 29ebf728...txt (Jetson Orin Nano build evidence)
• Phase: Phase 2
• Target Audience: System architects + C1 implementer
• Confidence: ✅ for mode support, MSCKF formulation, and Jetson Orin Nano build feasibility; ⚠️ for steady-state latency on Orin Nano Super under our 5472×3648 nav frames — KAIST benchmark used 640×480; 16× pixel count is a yellow-flag.
• Related Dimension: SQ3+SQ4 / C1 Established-production candidate
• Fit Impact: carry as lead candidate, conditional on user license decision. OpenVINS has the most documented Jetson-Orin-Nano build path of the three GPL-3.0 candidates; MSCKF formulation is more memory-efficient than VINS-Mono's full sliding-window optimisation, which is a meaningful advantage under co-resident-process memory pressure. GPL-3.0 license decision is the same as VINS-Mono / VINS-Fusion.

Fact #31 — OKVIS2 is the most actively maintained VI-SLAM in the BSD-permissive license bucket; OKVIS2-X (T-RO 2025) extends it with optional GNSS fusion that is architecturally aligned with the project's spoof-promotion path

• Statement: OKVIS2 (Leutenegger — arXiv 2022, ETH/Imperial/TUM Smart Robotics Lab) is a factor-graph VI-SLAM with bounded-size optimization. Algorithmic novelty: pose-graph edges from marginalised observations are "seamlessly turned back into observations" upon loop closure, reviving old landmarks and reprojection errors. Includes lightweight CNN segmentation for dynamic-region removal. Mode support: monocular and multi-camera + IMU; mono+IMU is a documented first-class configuration. Successor OKVIS2-X (Boche, Jung, Laina, Leutenegger — IEEE T-RO 2025 vol 41 pp 6064–6083, DOI 10.1109/TRO.2025.3619051; arXiv 2510.04612, Oct 2025) generalises the core to fuse multi-camera + IMU + optional GNSS receiver + LiDAR or depth. The OKVIS2-X GNSS-fusion mode (lineage: Visual-Inertial SLAM with Tightly-Coupled Dropout-Tolerant GPS Fusion, IROS 2022) directly mirrors the project's "VIO that may opportunistically fuse a non-spoofed GPS update when promotion completes" pattern (AC-NEW-2). Repository state: ethz-mrl/OKVIS2-X created 2025-09-23, last push 2026-03-17, 295 stars, 2 active contributors (bochsim, SebsBarbas). License: 3-clause BSD on the LICENSE file (GitHub UI shows "Other (NOASSERTION)" but the file is canonical 3-clause BSD per ASL-ETH Zurich convention) — permissive, no dual-use distribution friction.
• Source: Source #47 (OKVIS2 canonical), Source #48 (OKVIS2-X T-RO 2025)
• Phase: Phase 2
• Target Audience: System architects + C1 / C5 implementer
• Confidence: ✅ for algorithm, mode support, license, T-RO 2025 publication, repository activity; ⚠️ for Jetson Orin Nano runtime — no direct Jetson Orin Nano benchmark located; OKVIS2's factor-graph backend is plausibly heavier than OpenVINS' MSCKF on memory but lighter than Kimera (Kimera also produces a 3D mesh + semantic mesher, OKVIS2 does not).
• Related Dimension: SQ3+SQ4 / C1 Open-source-permissive lead candidate; potential C1+C5+C8 unified factor-graph design
• Fit Impact: strong lead candidate by license + maintenance + GNSS-fusion alignment. If license permissiveness is a priority, OKVIS2 + OKVIS2-X is the natural choice. The OKVIS2-X factor-graph also opens a design path where C5 (state estimator) collapses INTO C1 (the same factor graph absorbs sat-anchor measurements as constraints) — would simplify the pipeline at the cost of departing from the C1/C5 split, which is a Step-7.5 / solution_draft01 design decision, not a SQ3+SQ4 question. Pending Jetson Orin Nano Super MVE.

Fact #32 — Kimera-VIO is BSD-permissive but resource-heavy; KAIST benchmark found Kimera had the highest memory usage among VIOs tested and failed Xavier-NX-class memory under multi-process load

• Statement: Kimera-VIO (MIT-SPARK — Rosinol, Abate, Chang, Carlone — ICRA 2020) is a VI-SLAM pipeline with frontend + backend (factor-graph optimization in iSAM2 or GTSAM) + 3D mesher + pose-graph optimizer. Mode support: stereo+IMU primary, mono+IMU optional but documented. License: BSD 2-Clause "Simplified" (LICENSE.BSD on the repo) — permissive. Maintenance: active issue/PR threads through Dec 2024 / Feb 2025 covering ROS 2 integration, mono-inertial discussion, dependency management. Resource profile (Source #46 KAIST 2021 benchmark): Kimera had the highest memory usage among the 9 algorithms tested (numerous computations per keyframe); Kimera failed to fit on Xavier NX-class memory under sustained multi-process load. The 3D mesh + semantic-label outputs are unused by the project's narrow C1 mandate (relative 6-DoF + covariance only) — Kimera's overhead is unjustified vs OKVIS2 / OpenVINS for our use case.
• Source: Source #49 (Kimera canonical + LICENSE.BSD), Source #46 (KAIST Jetson benchmark)
• Phase: Phase 2
• Target Audience: System architects (build-vs-buy, mesh-feature decision)
• Confidence: ✅ for algorithm, license, maintenance status; ✅ for the Source #46 finding (KAIST 2021); ⚠️ for whether Orin Nano Super's larger memory + Ampere GPU lifts Kimera into feasibility — the Source-46 failure was on Xavier NX 8 GB shared, same memory budget as Orin Nano Super, but Orin Nano Super has higher per-core throughput.
• Related Dimension: SQ3+SQ4 / C1 Open-source-permissive secondary candidate
• Fit Impact: carry as fallback only, not lead. Kimera's permissive license is attractive but its resource overhead (especially the unused 3D mesh + semantic mesher) is a poor fit under co-resident process pressure. Use as a conservative secondary fallback if OKVIS2 unexpectedly fails Jetson MVE. Status: not lead.

Fact #33 — DROID-SLAM is disqualified by AC-4.2: ≥11 GB GPU VRAM inference budget exceeds the project's 8 GB shared LPDDR5; further, DROID-SLAM is monocular VO/SLAM without IMU fusion and would require an external metric-scale wrapper

• Statement: DROID-SLAM (princeton-vl, Teed & Deng — NeurIPS 2021; arXiv 2108.10869) requires ≥11 GB GPU memory to run inference per the official README; training requires ≥24 GB on 4× RTX 3090. Issue #121 confirms that even with 128 GB system RAM and 16 GB VRAM (RTX 4080), users hit very large RAM consumption quickly. Algorithmically, DROID-SLAM is monocular VO/SLAM with recurrent dense bundle adjustment over a complete history of camera poses — no native IMU fusion; output pose is in arbitrary scale (no metric scale recovery without external alignment). DPV-SLAM (ECCV 2024, princeton-vl) is the lighter successor at ~4–5 GB GPU memory; DPVO (NeurIPS 2023, princeton-vl) is even lighter at ~3 GB, but neither natively integrates IMU.
• Source: Source #50 (DROID-SLAM canonical), Source #51 (DPVO / DPV-SLAM successor), Source #52 (DPVO-QAT++ memory measurement)
• Phase: Phase 2
• Target Audience: System architects + C1 implementer
• Confidence: ✅
• Related Dimension: SQ3+SQ4 / C1 disqualified candidate
• Fit Impact: DISQUALIFIED outright. AC-4.2 sets the 8 GB shared CPU+GPU memory budget; DROID-SLAM's ≥11 GB GPU-only requirement violates it before adding co-resident C2/C3/C5/C6 processes. Cite as "what the project cannot afford" in solution_draft01 to pre-empt obvious questions.

Fact #34 — DPVO is monocular VO only (no IMU fusion); it can fit a Jetson-suitable memory footprint with QAT but cannot satisfy the C1 VIO mandate alone — would need an external IMU + metric-scale wrapper

• Statement: DPVO (Teed, Lipson, Deng — NeurIPS 2023; ECCV 2024 DPV-SLAM successor) is a deep-learning monocular VO with sparse patch tracking + differentiable bundle adjustment. Mode: monocular VO only — no IMU fusion in the published paper or repository; output pose is in arbitrary scale. Memory footprint: DPVO ~3 GB GPU, DPV-SLAM ~4–5 GB GPU on standard hardware; DPVO-QAT++ (arXiv 2511.12653, Cheng Liao, Nov 2025) reduces peak reserved memory to 1.02 GB on RTX 4060 (8 GB) via fused-CUDA INT8 fake-quantization while preserving ATE on TartanAir/EuRoC. License: MIT (permissive). Repository: 989 stars; last update 2024-10-12. Crucial gap: DPVO does NOT meet the C1 mandate of a "VIO that produces metric-scale 6-DoF + attitude with σ ≤ 5°" — for the project to use DPVO as the VO half of C1, an additional IMU+scale-fusion module (loosely-coupled ESKF with VO velocity / displacement priors) must be designed; alternatively, DPVO's pose can feed C5 directly as a relative-displacement constraint, with attitude served separately by FC IMU integration. Jetson Orin Nano runtime evidence: indirect — DPVO-QAT++ benchmarks on RTX 4060 desktop, NOT Jetson Orin Nano. The Ampere GPU architecture is shared between RTX 4060 and Orin Nano Super (both Ampere); the Orin Nano Super's GPU is smaller, so direct extrapolation is not safe — Jetson MVE required.
• Source: Source #51 (DPVO / DPV-SLAM canonical), Source #52 (DPVO-QAT++ Nov 2025)
• Phase: Phase 2
• Target Audience: System architects + C1 / C5 implementer
• Confidence: ✅ for "VO only, no IMU fusion" and the memory footprints; ⚠️ for Jetson Orin Nano direct runtime (no measurement); ⚠️ for the operational complexity of the QAT pipeline (teacher-student distillation training is a significant prerequisite vs the classical VINS-* / OpenVINS / OKVIS2 candidates).
• Related Dimension: SQ3+SQ4 / C1 conditional candidate (VO not VIO; needs external IMU wrapper)
• Fit Impact: NOT a drop-in C1 candidate; conditional fit only. DPVO is not a substitute for VINS-Mono / OpenVINS / OKVIS2 — it is a candidate for the VO half of a hybrid design where C5 (estimator) absorbs IMU and DPVO provides relative-pose priors. This adds design complexity and is not preferred unless one of the established VIO candidates fails Jetson MVE for memory reasons. Status: secondary, conditional.

Fact #35 — Pure VO baseline (KLT optical flow + 5-point essential matrix or homography RANSAC) is the project's mandatory simple-baseline candidate and is the de-facto fallback when learning-based methods fail on Jetson-budget constraints

• Statement: The classical pipeline — Shi-Tomasi or FAST corner detection → KLT pyramidal optical flow tracking (cv::calcOpticalFlowPyrLK) → 5-point essential matrix (Nister, cv::findEssentialMat) or homography RANSAC (cv::findHomography) → relative pose with arbitrary scale → metric-scale alignment via IMU integration externally — is the foundational visual-odometry pipeline implemented in OpenCV samples and pedagogical repositories. For the project's nadir-down UAV at 1 km AGL over Ukrainian steppe (predominantly planar terrain, low relief), the homography path is geometrically appropriate (a plane induces a homography between two views); for non-planar relief, the essential-matrix path is appropriate at a small overhead. License: public domain / OpenCV-Apache-2.0 / MIT (whatever reference implementation is chosen) — permissive. Reference: representative public Monocular-Video-Odometery (MIT, alishobeiri 2018), Monocular-Visual-Odometry (Yacynte) at translation error 0.94% / rotation error 0.015°/m on KITTI dataset.
• Source: Source #53 (OpenCV docs + reference implementations)
• Phase: Phase 2
• Target Audience: System architects + C1 implementer + risk reviewer
• Confidence: ✅
• Related Dimension: SQ3+SQ4 / C1 Simple-baseline candidate (mandatory per Component Option Breadth rule)
• Fit Impact: carry as the project's Simple baseline / known-runnable / known-failure-mode C1 fallback. Not a lead, but mandatory presence. Failure modes: (a) low-texture cropland / snow → KLT track loss; (b) sharp turns → low-overlap homography degeneracy; (c) no native IMU fusion → must wrap with external metric-scale alignment (same wrapper as DPVO). Status: simple-baseline reference; cited in solution_draft01 to anchor the failure analysis.

Fact #36 — Step-0.5-time-window assessment: VINS-Mono / VINS-Fusion master branches are at the Critical-novelty 18-month boundary; OpenVINS and OKVIS2 are within window; DPVO is borderline; the established baselines (KLT + RANSAC) are exempt

• Statement: Per Step 0.5 timeliness assessment in 00_question_decomposition.md, Critical-novelty topics require sources within 6 months for SOTA claims and 18 months for established libraries' API behaviour. Audit at access time 2026-05-07: VINS-Mono master last meaningful commit 2024-02-25 → ~27 months → just over the 18-month window; VINS-Fusion 2024-05-23 → ~24 months → just over; OpenVINS master active (issue threads through Feb 2025) and v2.7 release June 2023 → ~35 months for the tagged release but master in stable maintenance → within de-facto window for an established library; OKVIS2-X push 2026-03-17 → ~2 months → fully within window; DPVO last code update 2024-10-12 → ~19 months → just over but DPV-SLAM ECCV 2024 keeps the algorithm class within 6-month claim window; KLT / 5-point / RANSAC / homography → established baselines per Step 0.5 → no time window applies. Implication: VINS-Mono / VINS-Fusion fall into the "older than 18 months but classical authoritative reference" bucket — Step 0.5 allows up to 18 months strictly, but downstream forks (vins-mono-android, embedded variants) and the IEEE T-RO 2018 publication keep the algorithm class in active community use. Recommended treatment: keep as candidates but require live MVE on Jetson Orin Nano Super before promotion to Selected, to revalidate against the current OpenCV / Ceres / ROS 2 stack.
• Source: Source #43, Source #44, Source #45, Source #47, Source #48, Source #51 (timeliness audit per source)
• Phase: Phase 2
• Target Audience: Step-7.5 reviewer + System architects
• Confidence: ✅
• Related Dimension: SQ3+SQ4 / C1 candidate-pool integrity
• Fit Impact: applies a conservative timeliness gate: every C1 candidate from VINS-Mono / VINS-Fusion / DPVO requires an Orin-Nano-Super MVE before being marked Selected, since their master-branch staleness pushes them out of the Critical-novelty 18-month window. OpenVINS / OKVIS2 / OKVIS2-X / Kimera are within window via active issue threads or recent releases.

C1 Component Applicability Gate — preliminary table (this session; structured Restrictions×AC sub-matrix per candidate is next session's work)

Candidate	Mode (project)	License	Active maintenance?	Jetson Orin Nano Super runnable?	Native IMU fusion?	Native metric scale?	License blocks dual-use?	Preliminary status
VINS-Mono	mono+IMU	GPL-3.0 (copyleft)	⚠️ borderline (24 mo)	✅ proven on Jetson Nano (2021) → Orin Nano Super virtually certain	✅	✅	⚠️ Verify with user	Lead candidate conditional on user license decision + Orin-Nano-Super MVE
VINS-Fusion	mono+IMU (mode)	GPL-3.0	⚠️ borderline (24 mo)	⚠️ failed on TX2 (KAIST 2021); Orin Nano Super untested	✅	✅	⚠️ Verify with user	Alternate, secondary to VINS-Mono within HKUST family
OpenVINS	mono+IMU	GPL-3.0	✅ active master	✅ build confirmed on Orin Nano Dev Kit + JetPack 6 (2024 + 2025 community evidence); ~270 ms latency on Xavier NX	✅ MSCKF	✅	⚠️ Verify with user	Lead candidate conditional on user license decision (best Jetson-Orin-Nano evidence + most maintained of the GPL-3 trio)
OKVIS2 / OKVIS2-X	mono+IMU (+ optional GNSS)	BSD-3	✅ very active (2026 pushes)	⚠️ no direct Jetson Orin Nano measurement; factor-graph backbone plausibly heavier than MSCKF	✅	✅	✅ no	Lead candidate by license + maintenance + spoof-promotion architectural alignment, pending Jetson MVE
Kimera-VIO	mono+IMU (optional)	BSD-2	✅ active	⚠️ failed on Xavier NX 8 GB shared under multi-process (KAIST 2021)	✅	✅	✅ no	Fallback secondary; resource overhead poor fit for project
DROID-SLAM	mono VO/SLAM only	(project repo)	reference baseline	❌ ≥11 GB GPU VRAM > 8 GB AC-4.2 budget	❌	❌ (arbitrary scale)	n/a	DISQUALIFIED by AC-4.2
DPVO / DPV-SLAM	mono VO only	MIT	⚠️ borderline (19 mo on code, ECCV 2024 paper)	⚠️ DPVO-QAT++ (Nov 2025) shows 1.02 GB peak on RTX 4060 desktop; Jetson Orin Nano untested	❌ (needs external IMU wrapper)	❌ (needs external scale alignment)	✅ no	Conditional secondary — VO half of a hybrid C1+C5 design only; not a drop-in VIO replacement
Pure VO baseline (KLT + 5pt RANSAC / homography)	mono VO only	OpenCV-Apache-2.0 / MIT	✅ foundational (no time window)	✅ runs on any Jetson	❌ (needs external IMU wrapper)	❌ (needs external scale alignment)	✅ no	Mandatory simple-baseline reference per Component Option Breadth rule

Surviving lead candidates (preliminary), in priority order based on this session's evidence:

1. OpenVINS (GPL-3.0, MSCKF, best Jetson Orin Nano evidence) — pending user license decision + Orin-Nano-Super MVE
2. OKVIS2 / OKVIS2-X (BSD-3, factor-graph + GNSS-fusion alignment, most active maintenance) — pending Jetson MVE
3. VINS-Mono (GPL-3.0, sliding-window optimization, proven on Jetson Nano) — pending user license decision + Orin-Nano-Super MVE
4. Pure VO baseline (mandatory simple-baseline; runtime guaranteed; carries the project as a graceful fallback)

Disqualified outright: DROID-SLAM (AC-4.2 memory budget), RTAB-Map and ORB-SLAM3 (already pruned by Fact #16).

Conditional / not-direct-fit: DPVO / DPV-SLAM (VO not VIO, needs external IMU wrapper), Kimera-VIO (resource overhead unjustified for narrow C1 mandate).

C1 Open Decisions (to be resolved before SQ3+SQ4 closure)

Decision D-C1-1 — GPL-3.0 license posture for the onboard binary (BLOCKING for the GPL-3.0 trio: VINS-Mono / VINS-Fusion / OpenVINS).

• The three most established VIO candidates (VINS-Mono / VINS-Fusion / OpenVINS) are GPL-3.0 (viral copyleft).
• For dual-use UAV deployment, GPL-3 binary distribution to a customer triggers obligations: source-code disclosure for the entire linked binary, anti-tivoization clauses for embedded firmware updates, viral effect on any proprietary code linked into the same binary.
• BSD/MIT alternatives exist (OKVIS2 BSD-3, Kimera BSD-2, DPVO MIT, pure-VO baseline OpenCV-Apache-2.0), but each comes with secondary trade-offs (Jetson MVE risk, missing IMU fusion, resource overhead).
• Three options for the user:
  • (a) Accept GPL-3.0 — distribution model = release source on customer request; or operate the system as a service rather than transferring binaries. Lowest-risk algorithmic path (most-tested candidates).
  • (b) Restrict to permissive licenses only (BSD/MIT) — lead candidate becomes OKVIS2; carries Jetson MVE risk.
  • (c) Keep both options open through the design phase — make the final license decision after the Jetson Orin Nano MVE results are in.
• Recommended default: (c) — defer the binary commitment until empirical evidence on Jetson Orin Nano. This is recorded as a flagged decision; SQ3+SQ4 candidate matrix will carry both license families to Step 7.5.

Decision D-C1-2 — Acceptance of Jetson Orin Nano MVE as a Step-7.5 prerequisite (procedural).

• Per the Per-Mode API Capability Verification rule, every lead candidate library/SDK requires context7 (or equivalent docs) lookup + a Minimum Viable Example for the project's pinned mode + per-numbered-Restriction × per-numbered-AC sub-matrix.
• The Component Applicability Gate above is preliminary — it documents enumeration evidence but does NOT yet contain context7 per-mode capability verification or the structured sub-matrix.
• Next session's mandatory work: context7 lookup (3 mandatory queries) for OpenVINS / OKVIS2 / VINS-Mono; per-Restriction × per-AC sub-matrix per candidate; the same for the simple-baseline path; record into ../02_fact_cards/C1_vio.md per the engine template + ../06_component_fit_matrix/C1_vio.md per Step 7.5.

C1 Boundary check: candidate enumeration is saturated for this session

Saturation signals observed: (a) all 7 named candidates from 00_question_decomposition.md C1 row enumerated with at least one canonical L1 source per candidate; (b) Jetson Orin Nano runtime evidence located for OpenVINS (direct) and VINS-Mono (Jetson Nano + RPi CM4); other candidates carry "MVE required" gates explicitly; (c) license diversity covered (GPL-3.0 trio + BSD-permissive duo + MIT + permissive-baseline); (d) explicit disqualifications recorded with cited evidence (DROID-SLAM, RTAB-Map, ORB-SLAM3). Open: per-mode context7 verification (BLOCKING per rule) + Restrictions×AC sub-matrices (BLOCKING per Step 7.5) — explicitly deferred to next session.

---

C1 — Per-Mode API Capability Verification (engine Step 2 — Mandatory context7 lookup) [2026-05-08 session]

This section closes the per-mode API capability verification gate for the four C1 lead candidates. Each candidate has a pinned-mode statement, three documentary context7 (or equivalent) queries answered, an MVE block, and a per-numbered-Restriction × per-numbered-AC sub-matrix. The candidates' final lead-promotion to "Selected" status remains gated by the dedicated Jetson Orin Nano Super hardware MVE (D-C1-2 deferred phase).

Fact #37 — OpenVINS per-mode API capability verification (mono+IMU on Jetson Orin Nano Super) — DOCUMENTARY PASS; Jetson MVE pending

• Statement: OpenVINS (/rpng/open_vins, master) exposes monocular / stereo / multi-camera + IMU as first-class launch configurations via subscribe.launch.py declared launch arguments use_stereo (bool) and max_cameras (int). The project's pinned mode is monocular + IMU, selected via use_stereo:=false max_cameras:=1 with config:= pointing to a project-tuned estimator_config.yaml. Mode-enumeration query (1/3): confirms 3 sensor configurations at the launch layer; supported IMU intrinsic models = KALIBR + RPNG (per propagation-analytical.dox). Pinned-mode runnable example query (2/3): confirms ros2 launch ov_msckf subscribe.launch.py config:=euroc_mav is the documented runnable example; euroc_mav defaults to stereo per subscribe.launch.py but use_stereo:=false max_cameras:=1 selects mono-only at runtime — no source patch required. Disqualifier-probe query (3/3): did NOT surface any documented sub-20-Hz validation, hard frame-rate floor, or hard image-resolution ceiling in the master docs; the documented Xavier-NX latency baseline (~270 ms per rpng/open_vins issue #164) is below the AC-4.1 400 ms p95 budget head-room at 640×480 but unverified at the project's 5472×3648 nav frames. The Jetson Orin Nano Dev Kit + JetPack 6 + ROS 2 Humble build patch is documented (rpng/open_vins issue #421 + fdcl-gwu/openvins_jetson_realsense). Pinned-mode sentence: "We will use OpenVINS in monocular + IMU mode with inputs {1× ADTi 20MP nav frame stream + FC IMU via MAVLink/SCALED_IMU2} and expect outputs {6-DoF pose at IMU rate with covariance from MSCKF state, source label visual_propagated when no satellite anchor} on Jetson Orin Nano Super (8 GB shared, JetPack 6, ROS 2 Humble)."
• Source: Source #54 (context7), Source #45 (canonical OpenVINS), Source #46 (KAIST Jetson benchmark for class-level comparison)
• Phase: Phase 2
• Target Audience: System architects + C1 implementer + Step-7.5 reviewer
• Confidence: ✅ for mode-enumeration and runnable-example documentary evidence; ⚠️ for sub-20-Hz validation and 5472×3648 latency (no documentary evidence — Jetson MVE will resolve)
• Related Dimension: SQ3+SQ4 / C1 lead candidate — per-mode API capability verification gate
• Fit Impact: DOCUMENTARY PASS for the per-mode API capability verification gate; promotes OpenVINS to "lead candidate, documentary verification complete" status in ../06_component_fit_matrix/C1_vio.md row. License-track decision (D-C1-1) still gates final Selected promotion (OpenVINS = GPL-3.0, lives in track A); Jetson Orin Nano Super hardware MVE (D-C1-2) still gates accuracy/latency/memory empirical promotion.

Fact #38 — VINS-Mono per-mode API capability verification (mono+IMU on Jetson Orin Nano Super) — DOCUMENTARY PASS WITH FRAME-RATE CAVEAT; Jetson MVE pending

• Statement: VINS-Mono (HKUST-Aerial-Robotics/VINS-Mono, master) is a single-mode system: "real-time SLAM framework for Monocular Visual-Inertial Systems" (README §1) — no mode enumeration is required because the pinned mode IS the only mode. Mode-enumeration query (1/3): VINS-Mono is single-mode = mono+IMU; cross-source documentary evidence from VINS-Fusion context7 confirms the same authors continue to ship euroc_mono_imu_config.yaml as a first-class config in the active fork (per the Per-Mode API rule, VINS-Fusion's mono+IMU mode is a separately-cataloged candidate, but the algorithmic core and required calibration surface are identical — see Fact #29). Pinned-mode runnable example query (2/3): README §3.1.1 — roslaunch vins_estimator euroc.launch + EuRoC MH_01 bag is the canonical runnable example; supports online camera-IMU extrinsic calibration (estimate_extrinsic:=2), online temporal calibration (estimate_td:=1), and rolling-shutter cameras with documented calibration ceiling (reprojection error <0.5 px). Pinhole + MEI camera models supported. Camera intrinsics + IMU noise must be calibrated (Kalibr or equivalent). Disqualifier-probe query (3/3): README §5.1 explicitly states "The image should exceed 20Hz and IMU should exceed 100Hz." — this is a documentary minimum-rate recommendation and is below the project's 3 fps nav-camera target by ~6.7×. See Fact #40 for the geometric analysis and the cross-cutting frame-rate-sensitivity finding. Ceres Solver dependency is pinned to v1.14.0 (build issues at ≥2.0.0 per README §1.2); JetPack-shipped Ceres versions need explicit verification. License: GPLv3 (README §8). Pinned-mode sentence: "We will use VINS-Mono in monocular + IMU mode with inputs {1× ADTi 20MP nav frame stream (target 3 fps; under documentary 20 Hz floor) + FC IMU via MAVLink/SCALED_IMU2} and expect outputs {6-DoF pose at IMU rate via sliding-window optimization with covariance from optimization Hessian, loop closure via DBoW2} on Jetson Orin Nano Super (8 GB shared, JetPack 6, Ceres v1.14.0 build)."
• Source: Source #55 (VINS-Mono README + VINS-Fusion context7 cross-source), Source #43 (canonical VINS-Mono), Source #46 (KAIST Jetson benchmark for class-level comparison)
• Phase: Phase 2
• Target Audience: System architects + C1 implementer + Step-7.5 reviewer
• Confidence: ✅ for mode-enumeration (single mode by construction) and runnable-example evidence; ⚠️ for sub-20-Hz operation (documentary minimum-rate recommendation contradicts project frame-rate target); ⚠️ for Ceres v1.14.0 vs JetPack 6 stock Ceres compatibility
• Related Dimension: SQ3+SQ4 / C1 lead candidate — per-mode API capability verification gate
• Fit Impact: DOCUMENTARY PASS WITH FRAME-RATE CAVEAT. Per the engine rule's escalation tier, the candidate is downgraded from "documentary lead" to "Experimental only — sub-20-Hz operation requires Jetson MVE validation" until the deferred Jetson hardware MVE explicitly measures VINS-Mono at the project's 3 fps. License-track decision (D-C1-1) still gates final Selected promotion (VINS-Mono = GPL-3.0, lives in track A).

Fact #39 — OKVIS2 per-mode API capability verification (mono+IMU on Jetson Orin Nano Super) — DOCUMENTARY PASS; Jetson MVE pending

• Statement: OKVIS2 (smartroboticslab/okvis2, main) is a keyframe-based factor-graph VI-SLAM with multi-camera + IMU support; the README documents coordinate-frame contract (W world / C_i cameras / S IMU / B body), state representation (T_WS pose + velocity + gyro/accel biases), and a two-callback API (setOptimisedGraphCallback for batch updates incl. loop closure + setImuCallback for high-rate prediction). Mode-enumeration query (1/3): README + example apps confirm modes = mono / stereo / multi-camera (i-th camera frame C_i) — IMU is mandatory (okvis::ViSensorBase::setImuCallback is required). The example apps are okvis_app_synchronous (dataset replay), okvis_app_realsense (live D435i/D455), okvis_app_realsense_record (recording). ROS 2 build is opt-in (BUILD_ROS2=ON); ROS 2 launch files: okvis_node_realsense.launch.xml, okvis_node_realsense_publisher.launch.xml, okvis_node_subscriber.launch.xml, okvis_node_synchronous.launch.xml. Pinned-mode runnable example query (2/3): README "Running the demo application" + "Configuration files" section — ./okvis_app_synchronous <config>.yaml <EuRoC_MH_01_easy_dir> is the canonical mono dataset-replay example; the EuRoC config in config/ is the documentary mono+IMU launch reference. Configuration trade-off surface: "various options to trade-off accuracy and computational expense as well as to enable online calibration" — explicit acknowledgement of latency/accuracy tuning surface. Disqualifier-probe query (3/3): README does NOT state an explicit minimum image rate (cf. VINS-Mono's 20 Hz). OKVIS2's keyframe-based architecture inherently selects only "informative" frames for optimization, which is a structural advantage at lower input frame rates compared to sliding-window optimization. Optional LibTorch sky-segmentation CNN (USE_NN) can be disabled with USE_NN=OFF to remove the Jetson LibTorch dependency. License: 3-clause BSD (README "License" section). Health warning: "good results (or results at all) may only be obtained with appropriate calibration" — Kalibr-based intrinsic + extrinsic + IMU noise + tight time sync mandatory (this is shared with all VI candidates). OKVIS2-X (T-RO 2025) extends with optional GNSS fusion — architecturally aligned with the project's spoof-promotion path (per Fact #31). Pinned-mode sentence: "We will use OKVIS2 (with BUILD_ROS2=ON USE_NN=OFF) in monocular + IMU mode with inputs {1× ADTi 20MP nav frame stream + FC IMU via MAVLink/SCALED_IMU2 → re-published to /okvis/cam0/image_raw + /okvis/imu0} and expect outputs {6-DoF pose with covariance from factor-graph optimization via setOptimisedGraphCallback + high-rate IMU-predicted state via setImuCallback} on Jetson Orin Nano Super (8 GB shared, JetPack 6, ROS 2 Humble)."
• Source: Source #56 (OKVIS2 README), Source #47 (canonical OKVIS2 paper arXiv:2202.09199), Source #48 (OKVIS2-X T-RO 2025)
• Phase: Phase 2
• Target Audience: System architects + C1 implementer + Step-7.5 reviewer
• Confidence: ✅ for mode-enumeration, runnable-example, and lower-frame-rate-tolerance arguments; ⚠️ for direct 3 fps validation (no documentary measurement — Jetson MVE will resolve); ⚠️ for direct Jetson Orin Nano measurement (Fact #31 noted no direct measurement; community evidence less abundant than OpenVINS)
• Related Dimension: SQ3+SQ4 / C1 lead candidate — per-mode API capability verification gate
• Fit Impact: DOCUMENTARY PASS for the per-mode API capability verification gate; promotes OKVIS2 to "lead candidate, documentary verification complete" status in ../06_component_fit_matrix/C1_vio.md row. OKVIS2's keyframe-based architecture is the only candidate of the four leads with a structural argument for tolerating sub-20-Hz operation — this re-orders the per-license-track lead ranking (see Fact #41 locked-in defaults). License-track decision (D-C1-1) does NOT gate OKVIS2 (BSD-3 already permissive); Jetson Orin Nano Super hardware MVE (D-C1-2) still gates empirical accuracy/latency/memory promotion.

Fact #40 — Cross-cutting C1 finding: project's 3 fps nav-camera target is below VINS-Mono's documented 20 Hz minimum-rate recommendation; affects all sliding-window VIO candidates; OKVIS2's keyframe architecture is the structural mitigant

• Statement: VINS-Mono README §5.1 documents "The image should exceed 20Hz and IMU should exceed 100Hz" as the recommended minimum-rate operating envelope (Source #55). The project's nav-camera processing target is 3 fps per 00_question_decomposition.md Project Constraint Matrix. Geometric analysis: at 60 km/h cruise = 16.7 m/s × (1/3 s) = 5.5 m of forward motion between consecutive nav frames; at 1 km AGL with 12 cm/px GSD, that motion projects to ~46 px of in-image displacement (~0.84% of the 5472 px frame width) — well within KLT-trackable range for the nadir-down camera geometry, so the rate floor is NOT geometrically unreachable. However: the documented recommendation is about temporal-stability assumptions (motion-blur tolerance, IMU pre-integration noise growth, sliding-window optimisation Jacobian conditioning), not about geometric trackability. Cross-candidate impact: (a) VINS-Mono — sliding-window optimisation, full graph re-linearisation per keyframe, 20 Hz documentary recommendation explicitly violated by 6.7× → ⚠️ Experimental only until Jetson MVE measures actual sub-20-Hz behaviour; (b) VINS-Fusion — same algorithmic core as VINS-Mono mono+IMU mode, same caveat applies; (c) OpenVINS — MSCKF-based with sliding-window state + sparse feature constraints, has documented variable-rate tolerance via init_imu_thresh/init_window_time config, but no documentary sub-20-Hz validation surfaced in context7 queries → ⚠️ Verify via Jetson MVE; (d) OKVIS2 — keyframe-based, structurally selects only informative frames for optimization; the architecture is more naturally tolerant of variable / lower input rates → preferred candidate at low input frame rates; ✅ structural argument; (e) Pure VO baseline (KLT+RANSAC) — requires sufficient feature overlap between consecutive frames; at 0.84% in-image displacement this is well within KLT capture range; ✅ no rate-floor concern. Architectural alternative for design-phase consideration: instead of binding all C1 candidates to 3 fps, the nav-camera input pipeline could fork — full-resolution 5472×3648 at 3 fps for VPR/satellite-anchor (C2/C3) and a binned/cropped 1368×912 (or 640×480) at higher rate (≥10 fps) into the VIO front-end. ADTi 20MP 20L V1 (APS-C) bandwidth at full-res caps near 5–7 fps over USB 3 (≈2–3 GB/s raw); binned modes typically 3–10× the rate. This is a Plan-time decision, not a research-time one, but the option must be carried into Plan and the Jetson MVE must measure both single-rate and dual-rate paths.
• Source: Source #55 (VINS-Mono README §5.1), Source #43 (canonical), restrictions.md "Cameras" section + 00_question_decomposition.md Project Constraint Matrix (3 fps target)
• Phase: Phase 2
• Target Audience: System architects + C1 implementer + Plan-phase reviewer + Jetson MVE owner
• Confidence: ✅ for the documentary 20 Hz minimum-rate recommendation; ✅ for geometric trackability calculation; ⚠️ for the binned/dual-rate pipeline option (camera-bandwidth estimate is plausible but needs ADTi datasheet verification at Plan time)
• Related Dimension: SQ3+SQ4 / C1 frame-rate sensitivity (cross-candidate); SQ4 (per-candidate runtime envelope binding)
• Fit Impact: (a) Re-orders the per-license-track candidate ranking — within the BSD/permissive track, OKVIS2 strengthens its lead via structural keyframe argument; within the GPL-3.0 track, OpenVINS retains lead over VINS-Mono on this specific dimension because MSCKF's variable-rate tolerance is more documented than VINS-Mono's full-window optimisation. (b) Adds a Plan-phase decision: single-rate (3 fps to all consumers) vs dual-rate (binned high-rate to VIO + full-res 3 fps to VPR/satellite) — this becomes an explicit deliverable for the Plan phase, not the Jetson MVE phase, because the nav-camera input pipeline shape feeds into both C1 and C2/C3 candidate scoring. (c) Marks all VINS-* candidates as ⚠️ Experimental-only until the deferred Jetson hardware MVE explicitly measures sub-20-Hz behaviour.

Fact #41 — D-C1-1 + D-C1-2 locked-in research-time defaults (after user-skipped clarification, 2026-05-08)

• Statement: The user invoked /autodev and was presented with structured AskQuestion prompts for D-C1-1 (GPL-3.0 license posture) and D-C1-2 (Jetson MVE schedule); the user skipped the questions with the directive "continue with the information you already have". Per autodev meta-rule "Critical Thinking" — locked-in research-time defaults selected to preserve maximum future optionality and to honour the documentary evidence already gathered: D-C1-1 = (c) "Keep both license tracks open" — rank GPL-3.0 leads (OpenVINS, VINS-Mono, VINS-Fusion) in parallel with BSD-permissive OKVIS2/OKVIS2-X; carry both license tracks through Plan; final license decision deferred to post-Jetson-MVE/Plan time when empirical evidence is available. D-C1-2 = (b) "Defer Jetson MVE to a dedicated bring-up phase between research and Plan" — research closes with documentary ranking + explicit "Jetson MVE pending" gates per candidate; the dedicated Jetson Orin Nano Super hardware MVE phase produces a single MVE artifact that promotes leads to "Selected" before Plan starts. The Plan phase MUST NOT lock a final C1 candidate before the deferred Jetson MVE artifact is produced and reviewed. These defaults are explicitly tagged as user-deferred — the user retains the right to revisit either decision at Plan time without losing the research artifact (both license tracks fully cataloged; both lead candidates carry full per-mode evidence).
• Source: User clarification skip during 2026-05-08 /autodev invocation; autodev meta-rule "Critical Thinking"; greenfield-flow Step 14 (Plan) precondition rule
• Phase: Phase 2 — process decision
• Target Audience: System architects + Plan-phase reviewer + Step-7.5 reviewer
• Confidence: ✅ (defaults selected and tagged as user-deferred; user can override at any later prompt)
• Related Dimension: SQ3+SQ4 / C1 process gate; cross-cutting onto C2–C10 (license posture decision is project-wide, not C1-specific)
• Fit Impact: PROCESS GATE CLOSURE for C1. Allows research to proceed past C1 to C2 (VPR) candidate enumeration without requiring user input now. The Plan phase MUST surface D-C1-1 again as a structured A/B/C decision before any C1 candidate is locked, AND MUST require the deferred Jetson MVE artifact as a precondition.

---

C1 — Minimum Viable Example (MVE) Blocks

MVE — OpenVINS in monocular + IMU mode

• Source: Source #54 (context7 → https://github.com/rpng/open_vins/blob/master/docs/gs-tutorial.dox ROS 2 launch + https://github.com/rpng/open_vins/blob/master/docs/gs-datasets.dox EuRoC config), accessed 2026-05-08
• Inputs in the example: EuRoC MAV stereo VI dataset (default config:=euroc_mav is stereo 2× cameras + IMU); the launch file declares use_stereo (default true) and max_cameras (default 2) as runtime overrides; setting use_stereo:=false max_cameras:=1 selects monocular operation against the same estimator_config.yaml parameter file with ROS topics /cam0/image_raw + /imu0
• Outputs in the example: 6-DoF pose at IMU rate; ROS 1 publishes /ov_msckf/poseimu, /ov_msckf/odomimu, /ov_msckf/pathimu; ROS 2 publishes equivalent topics under the configured namespace
• Project inputs: 1× ADTi 20MP nav frame stream (5472×3648, target 3 fps) + FC IMU via MAVLink (SCALED_IMU2 at ≥100 Hz)
• Project outputs required: 6-DoF pose at IMU rate with metric scale + 6×6 covariance + source label visual_propagated when no satellite anchor; AC-1.4-compliant 95% covariance ellipse; honest covariance per AC-NEW-4
• Match assessment: ✅ exact mode match for mono+IMU; ⚠️ partial input shape (image-resolution 4–5× larger than EuRoC's 752×480 → latency/memory unverified at full resolution); ⚠️ partial input rate (3 fps vs EuRoC's 20 Hz — see Fact #40)
• If ⚠️ or ❌: docs do not explicitly disqualify the configuration. The launch surface (use_stereo, max_cameras, config_path) supports the project's mode without source patches. Resolution and rate are runtime/Jetson-MVE concerns, not API-mode concerns. → Status: Documentary lead; final promotion to "Selected" requires Jetson Orin Nano Super hardware MVE artifact (D-C1-2 deferred phase).

MVE — VINS-Mono in monocular + IMU mode (single mode by construction)

• Source: Source #55 (VINS-Mono README §3.1.1 + cross-source VINS-Fusion context7 euroc_mono_imu_config.yaml), accessed 2026-05-08
• Inputs in the example: EuRoC MAV monocular VI dataset (the README explicitly notes "Although it contains stereo cameras, we only use one camera"); ROS topics with image rate >20 Hz and IMU rate >100 Hz per README §5.1; pinhole or MEI camera model with intrinsics + distortion calibrated; camera-IMU extrinsic + temporal calibration optional (online estimation supported via estimate_extrinsic and estimate_td params)
• Outputs in the example: 6-DoF pose at IMU rate via sliding-window optimization with covariance from optimization Hessian; loop closure via DBoW2; pose-graph save/reuse via s keystroke
• Project inputs: 1× ADTi 20MP nav frame stream (5472×3648, target 3 fps — below documentary 20 Hz floor) + FC IMU via MAVLink (SCALED_IMU2 at ≥100 Hz)
• Project outputs required: same as OpenVINS MVE above
• Match assessment: ✅ exact mode match (single-mode system, the project's pinned mode IS the only mode); ⚠️ partial input rate (3 fps vs documentary 20 Hz minimum recommendation per Fact #40); ⚠️ partial dependency stack (Ceres v1.14.0 vs JetPack 6 stock Ceres needs verification); ⚠️ partial input resolution (EuRoC 752×480 vs project 5472×3648)
• If ⚠️ or ❌: README §5.1 "The image should exceed 20Hz and IMU should exceed 100Hz" — explicit documentary disqualifier for sub-20-Hz operation absent contrary measurement. Geometric analysis (Fact #40) shows in-image displacement at 3 fps is small (~0.84% of frame width) and KLT-trackable, but the documentary minimum is not validated by the upstream authors at this rate. → Status: Experimental only until Jetson MVE explicitly measures sub-20-Hz behaviour, OR until the Plan phase commits to the dual-rate camera pipeline (binned high-rate to VIO + full-res 3 fps to VPR — see Fact #40) which would put VINS-Mono back on a documentary lead path.

MVE — OKVIS2 in monocular + IMU mode

• Source: Source #56 (OKVIS2 README "Running the demo application" + "Building the project with ROS2" + arXiv:2202.09199), accessed 2026-05-08
• Inputs in the example: EuRoC ASL/ETH dataset directory (e.g., MH_01_easy/) + a config file from the config/ directory; alternative live input via Realsense D435i/D455 through okvis_app_realsense; the i-th camera frame C_i in the OKVIS coordinate model permits multi-camera operation but mono is supported when C_0 is the only configured camera in the YAML
• Outputs in the example: An okvis::Trajectory object that can be queried at any timestamp; updates delivered via setOptimisedGraphCallback (batch updates including loop closure) and high-rate prediction via setImuCallback; state T_WS (pose) + v_W (velocity) + b_g/b_a (gyro/accel biases)
• Project inputs: 1× ADTi 20MP nav frame stream (5472×3648, target 3 fps) + FC IMU via MAVLink (SCALED_IMU2 at ≥100 Hz) → re-published to /okvis/cam0/image_raw + /okvis/imu0 topics in the ROS 2 build path
• Project outputs required: same as OpenVINS MVE above
• Match assessment: ✅ exact mode match for mono+IMU; ✅ structural argument for sub-20-Hz tolerance (keyframe-based architecture per Fact #40); ⚠️ partial input shape (image resolution unverified at 5472×3648 — config files in config/ are tuned for D435i/EuRoC resolutions); ⚠️ partial Jetson Orin Nano direct evidence (no community benchmark surfaced)
• If ⚠️ or ❌: docs do not explicitly disqualify the configuration; the keyframe architecture is the structural mitigant for the project's frame-rate target. Optional LibTorch sky-segmentation can be disabled with USE_NN=OFF to remove the Jetson LibTorch dependency. → Status: Documentary lead with structural advantage at sub-20-Hz; final promotion to "Selected" requires Jetson Orin Nano Super hardware MVE artifact (D-C1-2 deferred phase).

MVE — Pure VO baseline (KLT optical flow + 5-point essential matrix or homography RANSAC) — IMU-fusion external

• Source: Source #53 (OpenCV cv::calcOpticalFlowPyrLK + cv::findEssentialMat + cv::findHomography + cv::Rodrigues + reference implementation alishobeiri/Monocular-Video-Odometery MIT 2018)
• Inputs in the example: Sequence of monocular grayscale frames; OpenCV cookbook tutorial uses KITTI Odometry sequences (1241×376 at 10 fps, ground-plane motion); reference impl uses webcam at variable rate
• Outputs in the example: Sequence of relative-pose 3×4 matrices [R|t] per frame pair (arbitrary scale via 5-point essential; metric scale recoverable via known scene structure or external IMU integration)
• Project inputs: 1× ADTi 20MP nav frame stream (5472×3648, target 3 fps); FC IMU consumed by an external metric-scale wrapper (loosely-coupled ESKF that integrates IMU between visual updates and rescales the visual-odometry translation to metric units)
• Project outputs required: same as VIO MVEs above; the external wrapper produces the C5-style covariance because pure VO has no native covariance
• Match assessment: ⚠️ partial — the visual-odometry stage matches exactly (mono VO → relative pose); the IMU-fusion stage is NOT in this candidate and must be a separately-designed external module (loosely-coupled ESKF). At the C1 component scope, this candidate is "VO-only" and explicitly requires C5 to provide IMU fusion and covariance.
• If ⚠️ or ❌: → Status: Mandatory simple-baseline reference, NOT a lead. Used to anchor failure-analysis discussion in solution_draft01 and as a runnable fallback if all VIO candidates fail Jetson MVE. The external IMU-fusion wrapper for this candidate becomes part of C5 (state estimator) candidate scope, not C1.

---

C1 — Per-numbered-Restriction × Per-numbered-AC Sub-Matrix per Candidate

Per Per-Mode API Capability Verification rule item 4: every numbered Restriction line and every numbered Acceptance Criterion is bound to one of {Pass, Fail, Verify, N/A} per candidate, with one-line evidence cite. Lines marked N/A are out of C1 scope (handled by C2 / C3 / C4 / C5 / C6 / C7 / C8 / C9 / C10). Cells marked Verify block final "Selected" promotion until the Jetson Orin Nano Super hardware MVE phase resolves them.

Sub-matrix legend

• Pass: pinned mode satisfies the line with cited documentary evidence
• Fail: pinned mode contradicts the line with cited documentary evidence
• Verify: no documentary evidence either way; deferred Jetson MVE phase will resolve
• N/A: line is irrelevant to C1 (will be bound by C2/.../C10 in their respective rows)

Cross-cutting N/A lines (apply to ALL C1 candidates)

The following AC and Restriction lines are out of C1 scope and are marked N/A for every C1 candidate without per-candidate citation:

• All of AC-2.1b (satellite-anchor registration) — bound by C2 (VPR) + C3 (matcher) + C4 (PnP)
• All of AC-2.2 (cross-domain MRE branch) — bound by C3 (matcher)
• AC-3.4 (operator re-loc hint) — bound by C8 (FC adapter) + C10 (operator UX)
• All of AC-6.x (GCS telemetry) — bound by C8
• All of AC-7.x (AI-camera object localization) — bound outside C1 entirely
• All of AC-8.x (satellite reference imagery) — bound by C6 (tile cache) + C10 (provisioning)
• All of AC-NEW-3 (FDR records — except the "per-frame estimates with covariance + source-label" line which is a downstream pass-through of C1 output) — bound by C5 (state estimator emits the per-frame record) + system-wide FDR component
• All of AC-NEW-5 (operating environmental envelope: −20 °C to +50 °C, vibration, cooling) — bound by C7 (Jetson runtime / thermal scheduler) + system-wide thermal design
• All of AC-NEW-6 (imagery freshness enforcement) — bound by C6 + C10
• All of AC-NEW-7 (cache-poisoning safety budget) — bound by C5 + C6 + system-wide
• Restriction "Satellite Imagery" entire section — bound by C6 + C10
• Restriction "Communication protocol (pinned)" + "Output to FC" — bound by C8
• Restriction "Ground station" — bound by C8

OpenVINS — per-numbered binding (C1-relevant lines only; cross-cutting N/A above)

Line	Binding	Evidence (one-line cite)
AC-1.3 (drift between anchors: <100 m visual-only / <50 m IMU-fused)	Verify	OpenVINS produces metric-scale 6-DoF + IMU-fused covariance; absolute drift between anchors is a function of nav-cam frame rate + texture + IMU bias — Jetson MVE on Derkachi flight required
AC-1.4 (95% covariance ellipse + source label)	Pass	MSCKF produces native 6×6 covariance from filter state; source label is a downstream pipeline concern (C5) — OpenVINS provides the covariance input
AC-2.1a (frame-to-frame registration ≥95% normal flight)	Verify	OpenVINS feature-tracking front-end (KLT-based) success rate at 3 fps × 5472×3648 nadir-down low-texture cropland — Jetson MVE on Derkachi flight required
AC-2.2 (frame-to-frame MRE <1.0 px)	Verify	OpenVINS reports per-feature reprojection residuals via the MSCKF measurement model; aggregate MRE under nadir-down low-texture conditions — Jetson MVE measurement
AC-3.1 (tolerate 350 m outliers ±20° tilt)	Pass (with Verify scope)	MSCKF outlier-rejection via Mahalanobis gating is documented; the 350 m / ±20° envelope is an integration boundary owned by C5 — OpenVINS provides the per-feature gate
AC-3.2 (sharp turns <5% overlap, <200 m drift, <70° heading change)	Verify	OpenVINS has documented failure-detection + recovery; recovery via satellite-reference re-localization (AC-3.3) is owned by C2/C3 — OpenVINS must trigger the recovery path, MVE measurement of sharp-turn recovery on Derkachi flight
AC-3.3 (≥3 disconnected segments via satellite re-localization)	Pass	OpenVINS has documented failure-detection + recovery API (StateOptions); the re-localization input is provided by C2/C3
AC-3.5 (visual blackout + spoofed GPS → dead_reckoned label, ≤400 ms)	Verify	OpenVINS internal mode promotion (SLAM ↔ IMU-only propagation) latency under feature-loss conditions — Jetson MVE measurement; the label-state transition is owned by C5
AC-4.1 (latency <400 ms p95)	Verify	Documented Xavier NX baseline ~270 ms at 640×480 (Source #45 issue #164); 5472×3648 + Jetson Orin Nano Super at 3 fps unverified — Jetson MVE measurement
AC-4.2 (memory <8 GB shared)	Verify	MSCKF has lower memory footprint than full sliding-window optimization; Jetson Orin Nano Dev Kit build confirmed (Source #45 issue #421) but co-resident memory pressure with C2/C3/C5/C6 not measured
AC-4.4 (frame-by-frame, no batching)	Pass	OpenVINS publishes pose at IMU rate (per Source #54 launch evidence); no batching by design
AC-4.5 (corrections allowed)	Pass	MSCKF natively re-linearises in its sliding window; corrections via state augmentation are documented
AC-5.1 (initialise from FC EKF's last valid GPS + IMU-extrapolated position)	Pass	OpenVINS supports custom initialisation via init_options (per Source #54 estimator config); the FC-EKF input is plumbed by C5/C8
AC-5.3 (re-initialise on companion reboot from FC IMU-extrapolated position)	Pass	Same mechanism as AC-5.1; AC-NEW-1 covers the timing constraint
AC-NEW-1 (cold-start TTFF <30 s)	Verify	OpenVINS initialisation latency under co-resident process startup on Jetson Orin Nano Super — Jetson MVE measurement
AC-NEW-3 (per-frame estimates with covariance + source-label feed FDR)	Pass	OpenVINS publishes pose+covariance at IMU rate; the source-label and FDR pipeline are downstream (C5 + system-wide)
AC-NEW-4 (false-position safety budget — covariance honesty)	Pass (with Verify)	MSCKF produces filter-consistent 6×6 covariance; honest-covariance discipline is shared with C5 (which carries the contract to AC-4.3); covariance under-reporting in the presence of cross-domain matches is a known MSCKF failure mode (Fact #5 family) — Jetson MVE on Derkachi flight required for empirical floor
AC-NEW-8 (visual blackout + GPS spoofing — IMU-only ≤30 s, label dead_reckoned)	Pass	OpenVINS has documented IMU-only propagation mode after visual feature loss; the failsafe-label transition is owned by C5
Restriction "Sharp turns are exceptions; consecutive photos may share <5% overlap"	Verify	Same as AC-3.2 — Jetson MVE measurement
Restriction "Navigation camera (pinned): ADTi 20MP 20L V1, 5472×3648"	Verify	Image-resolution scaling (16× larger than EuRoC's 752×480 baseline) — Jetson MVE measurement of feature-extraction latency at full-res; binned/cropped path option per Fact #40
Restriction "Companion computer (pinned): Jetson Orin Nano Super, 8 GB shared"	Verify	Build confirmed (Source #45 issue #421); steady-state co-resident memory pressure unverified — Jetson MVE measurement
Restriction "High-rate IMU available from FC via MAVLink"	Pass	OpenVINS consumes IMU at any rate ≥100 Hz; SCALED_IMU2 at FC's native rate (typically 100–400 Hz) satisfies this

VINS-Mono — per-numbered binding (C1-relevant lines only; cross-cutting N/A above)

Line	Binding	Evidence (one-line cite)
AC-1.3 (drift between anchors)	Verify	Same as OpenVINS; sliding-window optimisation has higher drift than MSCKF in low-texture per academic comparison — Jetson MVE measurement
AC-1.4 (covariance ellipse + source label)	Pass	Sliding-window optimisation produces native covariance from optimization Hessian; source label is C5's concern
AC-2.1a (frame-to-frame registration ≥95%)	Fail (documentary) → Verify	VINS-Mono README §5.1 documents 20 Hz minimum image rate; project's 3 fps is below this floor (Fact #40) → ⚠️ Experimental only until Jetson MVE explicitly validates sub-20-Hz operation
AC-2.2 (MRE <1.0 px)	Verify	Same as OpenVINS; reprojection error under sub-20-Hz operation unverified
AC-3.1 (tolerate 350 m outliers ±20° tilt)	Pass (with Verify scope)	VINS-Mono has documented failure-detection + recovery
AC-3.2 (sharp turns)	Verify	Same as OpenVINS; under sub-20-Hz operation, sharp-turn recovery unverified — Jetson MVE measurement
AC-3.3 (disconnected segments via satellite re-localization)	Pass	VINS-Mono has documented failure-recovery; pose-graph reuse via DBoW2 supports re-anchor
AC-3.5 (visual blackout + spoofed GPS)	Verify	Same as OpenVINS
AC-4.1 (latency <400 ms p95)	Verify	Documented on Jetson Nano (Source #43); Orin Nano Super virtually certain to meet but at 5472×3648 unverified — Jetson MVE measurement
AC-4.2 (memory <8 GB shared)	Verify	Same as OpenVINS
AC-4.4 (frame-by-frame)	Pass	VINS-Mono publishes pose at IMU rate
AC-4.5 (corrections allowed)	Pass	Sliding-window optimization re-linearises and supports corrections
AC-5.1 (initialise from FC EKF)	Pass	VINS-Mono has automatic initialization via IMU pre-integration; custom-init from FC EKF is a wiring task
AC-5.3 (re-initialise on reboot)	Pass	Same as AC-5.1
AC-NEW-1 (cold-start TTFF <30 s)	Verify	VINS-Mono automatic initialization typically takes seconds; Jetson MVE measurement
AC-NEW-3 (per-frame estimates feed FDR)	Pass	Same as OpenVINS
AC-NEW-4 (covariance honesty)	Pass (with Verify)	Same as OpenVINS; sliding-window optimization Hessian is a less-conservative covariance source than MSCKF in some failure modes
AC-NEW-8 (visual blackout + GPS spoofing)	Pass (with Verify)	VINS-Mono has documented failure-detection and IMU-only propagation; failsafe-label transition is C5's
Restriction "Sharp turns are exceptions"	Verify	Same as AC-3.2
Restriction "Navigation camera (pinned): 5472×3648"	Verify	Same as OpenVINS; plus the Fact #40 dual-rate option is an explicit Plan-time consideration to bring VINS-Mono back from Experimental to documentary lead
Restriction "Companion computer: Jetson Orin Nano Super, 8 GB"	Verify	Same as OpenVINS; Ceres v1.14.0 vs JetPack 6 stock Ceres compatibility is an additional sub-verify item
Restriction "High-rate IMU available from FC via MAVLink"	Pass	VINS-Mono consumes IMU at ≥100 Hz; satisfied

OKVIS2 / OKVIS2-X — per-numbered binding (C1-relevant lines only; cross-cutting N/A above)

Line	Binding	Evidence (one-line cite)
AC-1.3 (drift between anchors)	Verify	Factor-graph back-end with loop closure should produce lower drift than non-loop VIO; specific Derkachi-flight measurement deferred to Jetson MVE
AC-1.4 (covariance ellipse + source label)	Pass	OKVIS2 produces 6×6 covariance from factor-graph marginal; source label is C5's concern
AC-2.1a (frame-to-frame registration ≥95%)	Pass (structural argument) → Verify	Keyframe-based selection is structurally tolerant of variable input rates (Fact #40); explicit 3 fps validation deferred to Jetson MVE
AC-2.2 (MRE <1.0 px)	Verify	OKVIS2 has tight reprojection-error inlier rejection in its keyframe matching; aggregate MRE under nadir-down low-texture — Jetson MVE measurement
AC-3.1 (tolerate 350 m outliers ±20° tilt)	Pass	OKVIS2 has Cauchy-loss robust factor graph that tolerates outliers; documented in arXiv:2202.09199
AC-3.2 (sharp turns)	Pass (structural)	Keyframe selection inherently skips uninformative sharp-turn frames; recovery via re-localization is owned by C2/C3
AC-3.3 (≥3 disconnected segments)	Pass	OKVIS2 has explicit re-localization API + loop closure; OKVIS2-X adds GNSS-fusion which architecturally aligns with the spoof-promotion path (per Fact #31)
AC-3.5 (visual blackout + spoofed GPS)	Verify	OKVIS2 IMU-only propagation between keyframes is via setImuCallback; latency under blackout-trigger — Jetson MVE measurement
AC-4.1 (latency <400 ms p95)	Verify	No documented Jetson Orin Nano measurement (Fact #31); factor-graph is plausibly heavier than MSCKF — Jetson MVE measurement
AC-4.2 (memory <8 GB shared)	Verify	Same as AC-4.1; co-resident memory pressure with C2/C3/C5/C6 unverified
AC-4.4 (frame-by-frame)	Pass	setImuCallback provides high-rate prediction; setOptimisedGraphCallback provides batch updates including loop closure — both stream frame-by-frame from a consumer perspective
AC-4.5 (corrections allowed)	Pass	Factor-graph re-linearisation on loop closure delivers corrections via setOptimisedGraphCallback
AC-5.1 (initialise from FC EKF)	Pass	OKVIS2 supports custom initialisation via the okvis::ViInterface API; the FC-EKF input is plumbed by C5/C8
AC-5.3 (re-initialise on reboot)	Pass	Same mechanism as AC-5.1
AC-NEW-1 (cold-start TTFF <30 s)	Verify	OKVIS2 initialisation latency under co-resident process startup — Jetson MVE measurement
AC-NEW-3 (per-frame estimates feed FDR)	Pass	OKVIS2 trajectory query at any timestamp via okvis::Trajectory supports the FDR pipeline
AC-NEW-4 (covariance honesty)	Pass (with Verify)	Factor-graph marginal covariance is the gold standard for honest covariance among VIO classes; cross-domain match consistency under satellite anchor injection unverified — Jetson MVE measurement
AC-NEW-8 (visual blackout + GPS spoofing)	Pass	OKVIS2 has documented IMU-only propagation between keyframes; OKVIS2-X GNSS-fusion is architecturally aligned with the spoof-promotion path
Restriction "Sharp turns are exceptions"	Pass (structural)	Keyframe selection inherently handles sparse-overlap sharp-turn frames
Restriction "Navigation camera (pinned): 5472×3648"	Verify	Image-resolution scaling — Jetson MVE measurement; OKVIS2 keyframe sub-sampling reduces the per-frame compute compared to per-frame VIO
Restriction "Companion computer: Jetson Orin Nano Super, 8 GB"	Verify	No direct Jetson Orin Nano Super measurement; LibTorch sky-segmentation can be disabled with USE_NN=OFF to remove a major Jetson dependency
Restriction "High-rate IMU available from FC via MAVLink"	Pass	setImuCallback consumes IMU at any rate ≥100 Hz; satisfied

Pure VO baseline (KLT + 5pt RANSAC / homography) — per-numbered binding (C1-relevant lines only; cross-cutting N/A above)

Line	Binding	Evidence (one-line cite)
AC-1.3 (drift between anchors — visual-only/IMU-fused)	Fail (visual-only sub-bound)	Pure VO has higher drift than VIO; the "<100 m visual-only" sub-bound is achievable, but the "<50 m IMU-fused" requires the external ESKF wrapper (which is part of C5, not this candidate)
AC-1.4 (covariance ellipse + source label)	Fail	Pure VO has no native covariance; covariance is provided by the external ESKF wrapper (C5)
AC-2.1a (frame-to-frame registration ≥95%)	Pass	KLT optical flow at 0.84% in-image displacement (Fact #40 calculation) is well within trackable range
AC-2.2 (MRE <1.0 px)	Pass (with Verify)	OpenCV findHomography with RANSAC produces sub-pixel inliers under planar steppe geometry; explicit measurement on Derkachi flight needed
AC-3.1 (tolerate 350 m outliers ±20° tilt)	Verify	RANSAC outlier rejection threshold is tunable; explicit measurement under ±20° airframe tilt needed
AC-3.2 (sharp turns)	Fail	Pure VO has no failure-recovery mechanism; sharp turns trigger KLT track loss; recovery via satellite re-localization (AC-3.3) is owned by C2/C3 — pure VO must signal track loss to C5
AC-3.3 (≥3 disconnected segments)	N/A (handled by C5+C2/C3)	Pure VO does not have re-localization; the disconnected-segment recovery is C2/C3's job
AC-3.5 (visual blackout + spoofed GPS)	N/A (handled by C5)	Pure VO has no failsafe state; C5 owns the dead_reckoned transition
AC-4.1 (latency <400 ms p95)	Pass	OpenCV KLT + RANSAC at 5472×3648 on Jetson Orin Nano CPU is documented as <100 ms class; latency budget is dominated by image I/O
AC-4.2 (memory <8 GB shared)	Pass	KLT + RANSAC has trivial memory footprint (<100 MB working set)
AC-4.4 (frame-by-frame)	Pass	Pure per-frame algorithm; no batching
AC-4.5 (corrections allowed)	N/A (handled by C5)	Pure VO has no state to correct; C5 owns corrections
AC-5.1 (initialise from FC EKF)	N/A (handled by C5)	Pure VO has no global state; C5 owns the initial pose
AC-5.3 (re-initialise on reboot)	N/A (handled by C5)	Same as AC-5.1
AC-NEW-1 (cold-start TTFF <30 s)	Pass	Pure VO needs no warm-up beyond first frame pair
AC-NEW-3 (per-frame estimates feed FDR)	N/A (handled by C5)	Pure VO emits relative pose only; FDR records the C5-fused estimate
AC-NEW-4 (covariance honesty)	Fail	Pure VO has no native covariance; honest-covariance discipline is the external wrapper's contract (C5)
AC-NEW-8 (visual blackout + GPS spoofing)	N/A (handled by C5)	Pure VO has no failsafe behavior; C5 owns the IMU-only mode
Restriction "Sharp turns are exceptions"	Fail	Same as AC-3.2
Restriction "Navigation camera (pinned): 5472×3648"	Pass	KLT runs at any resolution; 5472×3648 may need image pyramid downsampling for runtime — standard OpenCV practice
Restriction "Companion computer: Jetson Orin Nano Super, 8 GB"	Pass	Trivial memory + CPU-bound; no GPU dependency
Restriction "High-rate IMU available from FC via MAVLink"	N/A (handled by C5)	Pure VO does not consume IMU; the external wrapper does

Pure VO baseline summary: this candidate is NOT a drop-in C1 VIO replacement. It is a "VO + external IMU wrapper" two-component design where the external wrapper is owned by C5. As a C1 candidate it Fails AC-1.4 / AC-1.3 IMU-fused / AC-3.2 / AC-NEW-4 because those bindings inherently require IMU fusion which this candidate lacks. Status remains "mandatory simple-baseline reference" per Fact #35; the actual C1 fallback if all VIO leads fail Jetson MVE is "Pure VO + custom ESKF wrapper" — which is a Plan-phase design task, not a research-phase candidate.

---

C1 — CLOSURE STATUS [2026-05-08 session]

C1 is CLOSED at the documentary level. All four lead candidates (OpenVINS, OKVIS2, VINS-Mono, Pure VO baseline) have:

• ✅ Pinned-mode statement
• ✅ Three-query context7 (or equivalent) lookup with documentary evidence
• ✅ MVE block
• ✅ Per-numbered-Restriction × per-numbered-AC sub-matrix

Final lead promotion to "Selected" is gated by the deferred Jetson Orin Nano Super hardware MVE phase (D-C1-2 default = option (b) per Fact #41) — Plan phase MUST NOT lock a final C1 candidate without consuming the deferred Jetson MVE artifact.

Per-license-track preliminary leads (per Fact #41 default D-C1-1 = option (c) "keep both tracks open"):

• BSD/permissive track lead: OKVIS2 / OKVIS2-X — strongest documentary-mode-fit profile; structural sub-20-Hz tolerance; OKVIS2-X GNSS-fusion architectural alignment with spoof-promotion path (AC-NEW-2). Risk: no direct Jetson Orin Nano Super measurement.
• GPL-3.0 track lead: OpenVINS — best Jetson Orin Nano build evidence; MSCKF formulation more memory-efficient than VINS-Mono; documented Xavier NX 270 ms latency baseline. Risk: documentary 5472×3648 latency unverified.
• GPL-3.0 track alternate: VINS-Mono — single-mode by construction; ⚠️ Experimental only until Jetson MVE explicitly validates sub-20-Hz operation OR Plan commits to dual-rate camera pipeline (Fact #40).

Mandatory simple-baseline: Pure VO + external ESKF (C5) — kept as runnable fallback if all VIO leads fail Jetson MVE.

Cross-cutting design decision raised by C1 closure: the single-rate vs dual-rate nav-camera pipeline (Fact #40) is now an explicit Plan-phase deliverable, because it materially changes which C1 candidates remain on documentary lead vs Experimental status.

C1 → C2 transition: ready to proceed to C2 (VPR) candidate enumeration in the next session.