Refactor documentation for splittable artifacts and update references

Updated various documentation files to clarify the handling of splittable artifacts, allowing for folder equivalents of key markdown files when they exceed size limits. Adjusted references in multiple sections to reflect this new structure, ensuring consistency across the research methodology. Enhanced clarity on the saving actions and artifact organization, particularly for `01_source_registry.md`, `02_fact_cards.md`, and `06_component_fit_matrix.md`. This change aims to improve usability and maintainability of the research documentation.
2026-06-22 23:01:13 +00:00 · 2026-05-08 23:39:30 +03:00
parent e0a6f0d9d5
commit 846670a5c5
56 changed files with 6686 additions and 1244 deletions
@@ -0,0 +1,171 @@
+# Source Registry — Summary & Index
+
+> 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.
+>
+> Investigation order saved in `../00_question_decomposition.md` → "Next Step": SQ6 → SQ1 → SQ2 → SQ3+SQ4 per component (C1→C8) ✓ → C10 next → SQ5 interleaved → SQ8 → SQ9 synthesis at engine Step 8. **SQ7 (datasets / SITL / replay) deferred to Test Spec (greenfield Step 5) per 2026-05-08 C9 / SQ7 restructure** — see `../00_question_decomposition.md` → "C9 / SQ7 Restructure" section.
+>
+> This folder replaces the previous monolithic `01_source_registry.md`. The full per-source description for any source `#N` in the table below lives in the category file linked in its row.
+
+## Category Index
+
+| Category | File | Sources | Status |
+|---|---|---|---|
+| SQ6 — ArduPilot Plane vs iNav external positioning | [`SQ6_external_positioning.md`](SQ6_external_positioning.md) | #1–#24 | Saturated for protocol-level architectural decision |
+| SQ1 — Existing GPS-denied UAV systems | [`SQ1_existing_systems.md`](SQ1_existing_systems.md) | #25–#37 | Saturated |
+| SQ2 — Canonical pipeline decomposition | [`SQ2_canonical_pipeline.md`](SQ2_canonical_pipeline.md) | #38–#42 | Saturated |
+| C1 — VIO candidates | [`C1_vio.md`](C1_vio.md) | #43–#56 | Closed at documentary level |
+| C2 — VPR candidates | [`C2_vpr.md`](C2_vpr.md) | #57–#68 | Mandatory pre-screen complete (5/5) |
+| C3 — Matcher candidates | [`C3_matchers.md`](C3_matchers.md) | #69–#81 | Closed at documentary level |
+| C4 — Pose estimation candidates | [`C4_pose_estimation.md`](C4_pose_estimation.md) | #82–#87 | Closed at 3/N |
+| C5 — State estimator / sensor fusion candidates | [`C5_state_estimator.md`](C5_state_estimator.md) | #88–#91 | Closed at 2/N (batch 1 closed) |
+| C6 — Tile cache + spatial index candidates | [`C6_tile_cache_spatial_index.md`](C6_tile_cache_spatial_index.md) | #92–#98 | Closed at 2/N (batch 1 closed) — Cand 1 (mirror-suite-pattern) RECOMMENDED PRIMARY; Cand 2 (PostGIS+pgvector) DEFERRED secondary |
+| C7 — On-Jetson inference runtime candidates | [`C7_inference_runtime.md`](C7_inference_runtime.md) | #99–#105 | Closed at 3/N (batch 1 closed 2026-05-08) — Cand 1 (TensorRT native) RECOMMENDED PRIMARY; Cand 2 (ONNX Runtime + TRT EP) modern-competitive-lead-cross-architecture-portability; Cand 3 (pure PyTorch FP16) mandatory simple-baseline |
+| C8 — MAVLink / MSP2 FC adapter candidates | [`C8_fc_adapter.md`](C8_fc_adapter.md) | #106–#113 | Closed at 3/N (batch 1 closed 2026-05-08) — Cand 1 (pymavlink → MAVLink GPS_INPUT) RECOMMENDED PRIMARY for ArduPilot Plane; Cand 2 (MSP2_SENSOR_GPS via Python MSP V2) RECOMMENDED PRIMARY for iNav (locked SQ6 + AC-4.3 transport); Cand 3 (UBX impersonation via pyubx2 NAV-PVT) DEFERRED secondary for iNav after comparative-improvement verdict |
+| C10 — Pre-flight cache provisioning (CROSS-COUPLING MINIMAL scope per 2026-05-08 user choice C; D-C6-3 + D-C7-7 confirmation pipelines only, operator tooling deferred to Plan-phase) | [`C10_preflight_provisioning.md`](C10_preflight_provisioning.md) | #114–#121 | Closed at 2/N (batch 1 closed 2026-05-08) — D-C6-3 confirmation: direct `faiss.write_index`/`faiss.read_index` Python API + `python-atomicwrites` + content-hash verification gate at takeoff (FAISS MIT, atomicwrites MIT); D-C7-7 confirmation: hybrid Polygraphy CLI primary + `trtexec` for cache-reuse fast rebuilds + direct `IBuilderConfig` Python API escape hatch (Polygraphy + TensorRT 10.x Apache-2.0 throughout) |
+
+## Investigation Status
+
+| Sub-question | Status | Notes |
+|---|---|---|
+| SQ6 — ArduPilot vs iNav external positioning | **Saturated for protocol-level architectural decision** (further detail deferred to SQ8 for spoofing-side fields and to design phase for SITL parameter tuning) | Major finding: iNav has no inbound external-positioning MAVLink handler; AC-4.3 wording must be revised. See `../02_fact_cards/SQ6_fc_external_positioning.md` "SQ6 Conclusions". |
+| SQ1 — Existing GPS-denied UAV systems | **Saturated.** 13 sources logged across academic / open-source / commercial / defense-program / Ukraine-practitioner. Closest peer system: Twist Robotics OSCAR (deployed in Ukraine). Closest open-source pipeline-match: snktshrma/ngps_flight (NGPS, ArduPilot GSoC 2024 — LightGlue+SuperPoint+UKF+VISION_POSITION_ESTIMATE). Closest deployed commercial: Auterion Artemis (Skynode N + Visual Navigation, Ukraine-tested, 1000-mile range). | See `../02_fact_cards/SQ1_existing_systems.md` cluster + working summary. |
+| SQ2 — Canonical pipeline decomposition | **Saturated.** 5 surveys/benchmarks logged (Skoltech aerial VPR, U.Maine cross-view, OrthoLoC 2.5D geodata, AnyVisLoc low-altitude multi-view, NUDT 2026 sciopen survey). All converge on **`retrieval → matching → pose-estimation`** hierarchical framework with VIO/IMU as auxiliary. Two new architectural facts added to C1–C10: (a) **AdHoP-style perspective-refinement loop** between matching and PnP (+63% translation accuracy, method-agnostic), (b) **DSM 2.5D dependency** for full 6-DoF on aerial-to-satellite (must be resolved with the Suite Sat Service or accepted as a 3-DoF degraded mode). Practitioner runtime evidence: AnyLoc on RTX 3090 = 0.63s/descriptor, SuperGlue re-rank = 17–25s; on Jetson Orin Nano these are non-viable for our 400 ms p95 budget — must restrict to lightweight VPR (e.g., MixVPR / SALAD class) + LightGlue/XFeat-class matchers. See `../02_fact_cards/SQ2_canonical_pipeline.md` "SQ2 Conclusions". |
+| SQ3+SQ4 — Per-component candidates (C1–C10) | **In progress** — C1 (VIO) **CLOSED** at documentary level (Sources #43–#56). C2 (VPR) — **mandatory pre-screen COMPLETE at documentary level (5 of 5 candidates)**: MixVPR (Sources #57+#58), SALAD (Sources #59+#60+#61), SelaVPR (Sources #62+#63), NetVLAD (Sources #64+#65+#66), **EigenPlaces (Sources #67+#68 — closure 2026-05-08)**. All five mandatory candidates have per-mode API capability verification ✅, per-numbered-Restriction × per-numbered-AC sub-matrix written, and `../06_component_fit_matrix/C2_vpr.md` rows populated. **Conditional pre-screen candidates (AnyLoc / BoQ / DINOv2-VLAD)** are GATED on a prerequisite **INT8 quantization survey** before they can be added to per-mode rows (per Fact #26 pre-screen rule). C3 closed at documentary level (Sources #69–#81). C4 closed at 3/N (Sources #82–#87). **C5 CLOSED at 2/N — batch 1 closed 2026-05-08** (mandatory simple-baseline = Manual ESKF Solà 2017 [Sources #88–#89]; modern-competitive-lead-factor-graph = GTSAM iSAM2 + ImuFactor + smart factors + Marginals [Sources #90–#91]). **C6 CLOSED at 2/N — batch 1 closed 2026-05-08** (Cand 1 RECOMMENDED PRIMARY = mirror-of-suite-satellite-provider pattern: PostgreSQL btree + bytea + FAISS HNSW + filesystem [Sources #92+#96+#97+#98]; Cand 2 DEFERRED secondary = PostGIS GiST + pgvector HNSW + filesystem [Sources #94+#95]; Source #93 = PostgreSQL btree multicolumn-indexes docs cross-cite). **C7 CLOSED at 3/N — batch 1 closed 2026-05-08** (Cand 1 RECOMMENDED PRIMARY = TensorRT native [Sources #99+#104+#105]; Cand 2 modern-competitive-lead-cross-architecture-portability = ONNX Runtime + TRT EP [Source #100 + #103]; Cand 3 mandatory simple-baseline = pure PyTorch FP16 [Source #101]; Source #102 = YOLO26 Jetson Orin Nano Super benchmark; Source #103 = LightGlue+TRT+FP8 quantization-sensitivity finding driving D-C7-6 cross-component precision policy). **C8 CLOSED at 3/N — batch 1 closed 2026-05-08** (Cand 1 RECOMMENDED PRIMARY for ArduPilot = pymavlink → MAVLink GPS_INPUT msg 232 cooperative-path [Sources #106+#107 + cross-cite SQ6 Source #4 AP_GPS_MAV.cpp ingestion-path]; Cand 2 RECOMMENDED PRIMARY for iNav = MSP2_SENSOR_GPS id 7939 / 0x1F03 via Python MSP V2 implementation [Sources #111+#112+#113 + cross-cite SQ6 Source #12+#13]; Cand 3 DEFERRED secondary for iNav = UBX impersonation via pyubx2 NAV-PVT [Sources #108+#109+#110 + cross-cite SQ6 Fact #10] with comparative-improvement verdict that does NOT clear user's "significant-improvement-only" bar over Cand 2; mid-batch correction via c8_inav_recovery=B preserved locked SQ6 + AC-4.3 + restrictions.md verdicts). **C9 DROPPED** from research scope per 2026-05-08 SQ7/C9 restructure (datasets/SITL/replay deferred to Test Spec greenfield Step 5). **C10 CLOSED at 2/N — batch 1 closed 2026-05-08** under CROSS-COUPLING MINIMAL scope per 2026-05-08 user choice C (operator CLI/desktop tooling, sector classification, freshness pipeline deferred to Plan-phase): D-C6-3 confirmation = direct `faiss.write_index`/`faiss.read_index` Python API + `python-atomicwrites` + content-hash (SHA-256) verification gate at takeoff load + `IO_FLAG_MMAP_IFC` mmap [Sources #114+#115+#116]; D-C7-7 confirmation = hybrid Polygraphy CLI primary for INT8-calibrating builds + `trtexec` for cache-reuse fast rebuilds + direct `IBuilderConfig` Python API escape hatch [Sources #117+#118+#119+#120+#121]; **no further C10 batches required at the research layer** — operator tooling design enters at Plan-phase. | See `../02_fact_cards/C1_vio.md` + `../02_fact_cards/C2_vpr.md` + `../02_fact_cards/C3_matchers.md` + `../02_fact_cards/C4_pose_estimation.md` + `../02_fact_cards/C5_state_estimator.md` + `../02_fact_cards/C6_tile_cache_spatial_index.md` + `../02_fact_cards/C7_inference_runtime.md` clusters; `../06_component_fit_matrix/C{1..7}_*.md` rows. |
+| SQ5 — Failure modes / deployment lessons | Not started (interleaved with SQ3/SQ4) | |
+| SQ7 — Datasets, SITL, replay environments | **Deferred to Test Spec (greenfield Step 5)** per 2026-05-08 C9 / SQ7 restructure | Fixture-class / test-infra-class — not researched in this Mode A run. Carryforward payload preserved in `../00_question_decomposition.md` → "C9 / SQ7 Restructure" section. |
+| SQ8 — Safety considerations (AC-NEW-4 / AC-NEW-7) | Not started | Carries the AP_GPS spoofing-signal probe deferred from SQ6. |
+| SQ9 — End-to-end synthesis | Step 8 of engine (deferred) | |
+
+---
+
+## Source Summary Table
+
+Compact one-line index across all 121 sources. For full per-source description, follow the **File** link.
+
+| # | Title | Tier | File |
+|---|---|---|---|
+| 1 | Non-GPS Navigation — Plane documentation | L1 | [SQ6](SQ6_external_positioning.md) |
+| 2 | GPS / Non-GPS Transitions — Plane documentation | L1 | [SQ6](SQ6_external_positioning.md) |
+| 3 | EKF Source Selection and Switching — Plane documentation | L1 | [SQ6](SQ6_external_positioning.md) |
+| 4 | ArduPilot AP_GPS_MAV.cpp (master) | L1 | [SQ6](SQ6_external_positioning.md) |
+| 5 | ArduPilot PR #28750 — AP_NavEKF3 EK3_OPTION bits (GPS-denied testing) | L2 | [SQ6](SQ6_external_positioning.md) |
+| 6 | ArduPilot Issue #15859 — EKF3 source switching (GPS↔NonGPS) | L4 | [SQ6](SQ6_external_positioning.md) |
+| 7 | ArduPilot Issue #27193 — EK3 Source Switching wrong frame for GUIDED | L4 | [SQ6](SQ6_external_positioning.md) |
+| 8 | ArduPilot Issue #23485 — fuse only External Nav Velocities | L4 | [SQ6](SQ6_external_positioning.md) |
+| 9 | iNavFlight/inav telemetry/mavlink.c (master inbound switch) | L1 | [SQ6](SQ6_external_positioning.md) |
+| 10 | iNav Wiki — MAVLink (frogmane edited 2025-12-11) | L1 | [SQ6](SQ6_external_positioning.md) |
+| 11 | iNav Wiki — GPS and Compass setup | L1 | [SQ6](SQ6_external_positioning.md) |
+| 12 | iNavFlight/inav docs/development/msp/README.md (MSP message reference) | L1 | [SQ6](SQ6_external_positioning.md) |
+| 13 | iNavFlight/inav src/main/io/gps.c + target/common.h (master) | L1 | [SQ6](SQ6_external_positioning.md) |
+| 14 | iNav Issue #10141 — dual GPS support | L4 | [SQ6](SQ6_external_positioning.md) |
+| 15 | iNav docs/GPS_fix_estimation.md (master) | L1 | [SQ6](SQ6_external_positioning.md) |
+| 16 | iNav docs/Settings.md (master) | L1 | [SQ6](SQ6_external_positioning.md) |
+| 17 | iNav Issue #10588 — DeadReckoning weird behaviour during GPS outage | L4 | [SQ6](SQ6_external_positioning.md) |
+| 18 | iNav Release 8.0.0 (highlights, Dec 2024) | L1 | [SQ6](SQ6_external_positioning.md) |
+| 19 | iNav Release 9.0.0 / 9.0.1 + Release Notes wiki | L1 | [SQ6](SQ6_external_positioning.md) |
+| 20 | MAVLink common message set — GPS_RAW_INT (24) | L1 | [SQ6](SQ6_external_positioning.md) |
+| 21 | MAVLink PR #2110 — gps: add status and integrity information | L2 | [SQ6](SQ6_external_positioning.md) |
+| 22 | AirDroper — GNSS Spoofing Filter companion device | L3 | [SQ6](SQ6_external_positioning.md) |
+| 23 | ArduPilot PR #24135 — EKF3 robust to bad IMU and lane-switching | L2 | [SQ6](SQ6_external_positioning.md) |
+| 24 | ArduPilot AP_NavEKF3 — VehicleStatus.cpp + AP_NavEKF3.cpp (master) | L1 | [SQ6](SQ6_external_positioning.md) |
+| 25 | Twist Robotics OSCAR — visual navigation system (Ukraine deployment) | L2 | [SQ1](SQ1_existing_systems.md) |
+| 26 | Ukraine Drones with Vision-Based Navigation Past Heavy Jamming (TWZ) | L2 | [SQ1](SQ1_existing_systems.md) |
+| 27 | Ukraine's Ruta Missile Drone EW-Immune Navigation (Defense Express) | L2 | [SQ1](SQ1_existing_systems.md) |
+| 28 | Kilometer-Scale GNSS-Denied UAV Navigation via Heightmap Gradients | L1 | [SQ1](SQ1_existing_systems.md) |
+| 29 | Hierarchical Image Matching for UAV Absolute Visual Localization | L1 | [SQ1](SQ1_existing_systems.md) |
+| 30 | Raptor — GPS-Denied UAV Navigation & Coordinate Extraction (Vantor) | L2 | [SQ1](SQ1_existing_systems.md) |
+| 31 | Auterion Artemis program — long-range deep-strike completion | L1 | [SQ1](SQ1_existing_systems.md) |
+| 32 | Auterion Skynode N — AI/CV for small autonomous systems | L2 | [SQ1](SQ1_existing_systems.md) |
+| 33 | snktshrma/ngps_flight — NGPS for ArduPilot (GSoC 2024) | L1 | [SQ1](SQ1_existing_systems.md) |
+| 34 | AerialExtreMatch — benchmark for extreme-view image matching/localization | L1 | [SQ1](SQ1_existing_systems.md) |
+| 35 | DARPA Fast Lightweight Autonomy (FLA) program page + T&E review | L1 | [SQ1](SQ1_existing_systems.md) |
+| 36 | DSMAC / TERCOM lineage — DTIC ADA315439 | L1 | [SQ1](SQ1_existing_systems.md) |
+| 37 | Electronic Warfare in Ukraine — Ukraine War Analytics | L3 | [SQ1](SQ1_existing_systems.md) |
+| 38 | VPR for Aerial Imagery: A Survey (Skoltech, Moskalenko et al.) | L1 | [SQ2](SQ2_canonical_pipeline.md) |
+| 39 | Cross-View Geo-Localization: A Survey (U. Maine) | L1 | [SQ2](SQ2_canonical_pipeline.md) |
+| 40 | OrthoLoC: UAV 6-DoF Localization with Orthographic Geodata | L1 | [SQ2](SQ2_canonical_pipeline.md) |
+| 41 | AnyVisLoc — UAV visual localization, low-altitude multi-view | L1 | [SQ2](SQ2_canonical_pipeline.md) |
+| 42 | NUDT 2026 — survey on absolute visual localization for low-altitude UAV | L1 | [SQ2](SQ2_canonical_pipeline.md) |
+| 43 | VINS-Mono — robust monocular visual-inertial state estimator | L1 | [C1](C1_vio.md) |
+| 44 | VINS-Fusion — optimization-based multi-sensor state estimator | L1 | [C1](C1_vio.md) |
+| 45 | OpenVINS — open-source VI navigation research platform | L1 | [C1](C1_vio.md) |
+| 46 | Run VIO on NVIDIA Jetson — KAIST benchmark | L1 | [C1](C1_vio.md) |
+| 47 | OKVIS2 — realtime scalable VI-SLAM with loop closure | L1 | [C1](C1_vio.md) |
+| 48 | OKVIS2-X — open keyframe VI-SLAM with dense depth | L1 | [C1](C1_vio.md) |
+| 49 | Kimera-VIO — VIO with SLAM + 3D mesh (MIT-SPARK, BSD) | L1 | [C1](C1_vio.md) |
+| 50 | DROID-SLAM — deep visual SLAM (princeton-vl) | L1 | [C1](C1_vio.md) |
+| 51 | DPVO / DPV-SLAM — deep patch visual odometry | L1 | [C1](C1_vio.md) |
+| 52 | DPVO-QAT++ — heterogeneous QAT + CUDA kernel fusion for DPVO | L2 | [C1](C1_vio.md) |
+| 53 | Pure-VO baseline — KLT optical flow + 5-point/homography RANSAC (OpenCV) | L1 | [C1](C1_vio.md) |
+| 54 | OpenVINS — context7 per-mode capability lookup (`/rpng/open_vins`) | L1 | [C1](C1_vio.md) |
+| 55 | VINS-Mono README + VINS-Fusion context7 per-mode lookup | L1 | [C1](C1_vio.md) |
+| 56 | OKVIS2 — official README (`smartroboticslab/okvis2`, main) | L1 | [C1](C1_vio.md) |
+| 57 | OpenVPRLab — open-source VPR framework (MixVPR / BoQ / NetVLAD / GeM) | L1 | [C2](C2_vpr.md) |
+| 58 | MixVPR canonical paper (WACV 2023, arXiv:2303.02190) | L1 | [C2](C2_vpr.md) |
+| 59 | SALAD canonical implementation (`serizba/salad`, GPL-3.0) | L1 | [C2](C2_vpr.md) |
+| 60 | SALAD canonical paper — Optimal Transport Aggregation (CVPR 2024) | L1 | [C2](C2_vpr.md) |
+| 61 | OpenVPRLab DinoV2 backbone — context7 cross-source for ViT-B/14 | L1 | [C2](C2_vpr.md) |
+| 62 | SelaVPR canonical implementation (`Lu-Feng/SelaVPR`, MIT) | L1 | [C2](C2_vpr.md) |
+| 63 | SelaVPR canonical paper (ICLR 2024, arXiv:2402.14505) | L1 | [C2](C2_vpr.md) |
+| 64 | NetVLAD canonical implementation `Relja/netvlad` v1.03 (MIT) | L1 | [C2](C2_vpr.md) |
+| 65 | NetVLAD modern PyTorch reproduction `Nanne/pytorch-NetVlad` | L2 | [C2](C2_vpr.md) |
+| 66 | NetVLAD canonical paper (CVPR 2016 / TPAMI 2018, arXiv:1511.07247) | L1 | [C2](C2_vpr.md) |
+| 67 | EigenPlaces canonical implementation (`gmberton/EigenPlaces`, MIT) | L1 | [C2](C2_vpr.md) |
+| 68 | EigenPlaces canonical paper (ICCV 2023, arXiv:2308.10832) | L1 | [C2](C2_vpr.md) |
+| 69 | LightGlue — context7 per-mode capability lookup (`/cvg/lightglue`) | L1 | [C3](C3_matchers.md) |
+| 70 | LightGlue canonical implementation (`cvg/LightGlue`) | L1 | [C3](C3_matchers.md) |
+| 71 | LightGlue canonical paper (ICCV 2023, arXiv:2306.13643) | L1 | [C3](C3_matchers.md) |
+| 72 | LightGlue HuggingFace Transformers integration | L1 | [C3](C3_matchers.md) |
+| 73 | LightGlue-ONNX — `fabio-sim/LightGlue-ONNX` (Jetson TensorRT path) | L2 | [C3](C3_matchers.md) |
+| 74 | ALIKED canonical implementation (`Shiaoming/ALIKED`) | L1 | [C3](C3_matchers.md) |
+| 75 | ALIKED canonical paper (TIM 2023, arXiv:2304.03608) | L1 | [C3](C3_matchers.md) |
+| 76 | DISK canonical implementation (`cvlab-epfl/disk`, Apache-2.0) | L1 | [C3](C3_matchers.md) |
+| 77 | DISK canonical paper — RL-trained local features (NeurIPS 2020) | L1 | [C3](C3_matchers.md) |
+| 78 | SuperGlue canonical implementation (`magicleap/SuperGluePretrainedNetwork`) | L1 | [C3](C3_matchers.md) |
+| 79 | SuperGlue canonical paper — graph-NN feature matching (CVPR 2020) | L1 | [C3](C3_matchers.md) |
+| 80 | XFeat canonical implementation (`verlab/accelerated_features`, Apache-2.0) | L1 | [C3](C3_matchers.md) |
+| 81 | XFeat canonical paper — accelerated features (CVPR 2024) | L1 | [C3](C3_matchers.md) |
+| 82 | OpenCV canonical implementation — `opencv/opencv` (calib3d module) | L1 | [C4](C4_pose_estimation.md) |
+| 83 | OpenCV 4.x calib3d module canonical documentation | L1 | [C4](C4_pose_estimation.md) |
+| 84 | OpenGV canonical implementation (`laurentkneip/opengv`) | L1 | [C4](C4_pose_estimation.md) |
+| 85 | OpenGV canonical Doxygen documentation portal | L1 | [C4](C4_pose_estimation.md) |
+| 86 | GTSAM canonical implementation (`borglab/gtsam`, BSD-3) | L1 | [C4](C4_pose_estimation.md) |
+| 87 | GTSAM canonical Python documentation via context7 | L1 | [C4](C4_pose_estimation.md) |
+| 88 | Solà 2017 — "Quaternion kinematics for the error-state Kalman filter" (arXiv:1711.02508) | L1 | [C5](C5_state_estimator.md) |
+| 89 | Reference open-source ESKF implementations (canonical-paper-derived) | L2 | [C5](C5_state_estimator.md) |
+| 90 | GTSAM `ImuFactor` / `CombinedImuFactor` / `PreintegratedImuMeasurements` / `PreintegratedCombinedMeasurements` (context7 indexed) | L1 | [C5](C5_state_estimator.md) |
+| 91 | GTSAM `ISAM2` / `IncrementalFixedLagSmoother` / `Marginals` with iSAM2 results (context7 indexed) | L1 | [C5](C5_state_estimator.md) |
+| 92 | Parent-suite `satellite-provider` existing pattern (PostgreSQL + Dapper + filesystem tile storage; verified directly) | L1 | [C6](C6_tile_cache_spatial_index.md) |
+| 93 | PostgreSQL 16 official documentation — Multicolumn Indexes + btree access method | L1 | [C6](C6_tile_cache_spatial_index.md) |
+| 94 | PostGIS official documentation — GiST + KNN distance ordering + ST_DWithin | L1 | [C6](C6_tile_cache_spatial_index.md) |
+| 95 | pgvector official documentation — HNSW index API (context7 + canonical README) | L1 | [C6](C6_tile_cache_spatial_index.md) |
+| 96 | FAISS official documentation — IndexFlatL2 / IndexHNSWFlat / IndexIVFFlat (context7 indexed) | L1 | [C6](C6_tile_cache_spatial_index.md) |
+| 97 | Postgres on NVIDIA Jetson Orin Nano — March 2026 Medium article + Coding Steve minimal-config guide | L2 | [C6](C6_tile_cache_spatial_index.md) |
+| 98 | Slippy Map Tilenames — OpenStreetMap canonical specification (Web Mercator XYZ) | L1 | [C6](C6_tile_cache_spatial_index.md) |
+| 99 | NVIDIA TensorRT 10.x official documentation portal (context7-indexed `/nvidia/tensorrt`) | L1 | [C7](C7_inference_runtime.md) |
+| 100 | Microsoft ONNX Runtime official documentation (context7-indexed `/microsoft/onnxruntime`) + Jetson AI Lab community wheel index | L1 | [C7](C7_inference_runtime.md) |
+| 101 | PyTorch official documentation (context7-indexed `/pytorch/pytorch`) + Jetson AI Lab PyTorch wheel availability for JetPack 6 | L1 | [C7](C7_inference_runtime.md) |
+| 102 | Ultralytics YOLO26 benchmark suite on Jetson Orin Nano Super (April 2026) | L2 | [C7](C7_inference_runtime.md) |
+| 103 | LightGlue ONNX Runtime + TensorRT acceleration + FP8 ModelOpt quantization findings (Fabio Sim's Journal) | L2 | [C7](C7_inference_runtime.md) |
+| 104 | JetPack SDK release notes (NVIDIA official) — JetPack 6.0 / 6.1 / 6.2 version matrix | L1 | [C7](C7_inference_runtime.md) |
+| 105 | TensorRT-on-Jetson canonical install constraints (Ultralytics issue reports + NVIDIA forum) | L2 | [C7](C7_inference_runtime.md) |
+| 106 | ArduPilot Pymavlink (context7-indexed `/ardupilot/pymavlink`) — canonical Python MAVLink stack | L1 | [C8](C8_fc_adapter.md) |
+| 107 | ArduPilot Plane Non-GPS Position Estimation + MAVProxy GPS Input module dev docs (`GPS1_TYPE=14`, `EK3_SRC1_POSXY=3`) | L1 | [C8](C8_fc_adapter.md) |
+| 108 | pyubx2 (context7-indexed `/semuconsulting/pyubx2`) — canonical Python UBX/NMEA/RTCM3 parser | L1 | [C8](C8_fc_adapter.md) |
+| 109 | u-blox NEO-M9N Integration Manual (UBX-19014286) + u-blox 8/M8 Receiver Description (UBX-13003221) — UBX-NAV-PVT canonical specification | L1 | [C8](C8_fc_adapter.md) |
+| 110 | iNav `gps_ublox.c` source (master) — UBX validation gates `gpsMapFixType()` requires `flags & 0x01 = 1` AND `fixType ∈ {2,3}` | L1 | [C8](C8_fc_adapter.md) |
+| 111 | iNav `docs/development/msp/README.md` (master) — `MSP2_SENSOR_GPS (7939 / 0x1F03)` canonical 36-byte payload spec | L1 | [C8](C8_fc_adapter.md) |
+| 112 | Python MSP2 implementations: YAMSPy + INAV-Toolkit `inav_msp.py` (MSP V2 `msp_v2_encode` with CRC-8 DVB-S2) | L2 | [C8](C8_fc_adapter.md) |
+| 113 | iNav `src/main/msp/msp_protocol_v2_sensor.h` (master) — MSP V2 sensor command-ID range (0x1F00-0x1FFF) | L1 | [C8](C8_fc_adapter.md) |
+| 114 | FAISS `write_index` / `read_index` Python API + on-disk format + security warning (canonical wiki + context7) | L1 | [C10](C10_preflight_provisioning.md) |
+| 115 | FAISS IndexHNSWFlat per-vector memory + on-disk file size formula (Discussions #3953 + C++ API docs) | L2 | [C10](C10_preflight_provisioning.md) |
+| 116 | Python atomic file write pattern (gocept blog + python-atomicwrites docs + Python Issue 8604) | L2 | [C10](C10_preflight_provisioning.md) |
+| 117 | Polygraphy `polygraphy convert` CLI for TensorRT INT8 engine build with calibration cache reuse (NVIDIA TensorRT repo + context7) | L1 | [C10](C10_preflight_provisioning.md) |
+| 118 | Polygraphy `Calibrator` class API — algo defaults + dynamic-shapes calibration profile + warning behavior (NVIDIA TRT/Polygraphy SDK docs) | L1 | [C10](C10_preflight_provisioning.md) |
+| 119 | `trtexec` CLI for one-off engine builds — INT8/FP16 flags + calibration cache support (NVIDIA TRT SDK docs) | L1 | [C10](C10_preflight_provisioning.md) |
+| 120 | TensorRT INT8 calibration corpus size guidance (~500-1000 images) — Jetson AGX Orin (vendor engineering guide) | L2 | [C10](C10_preflight_provisioning.md) |
+| 121 | Direct TensorRT `IBuilderConfig` + `IInt8EntropyCalibrator2` Python API (NVIDIA TRT Python API docs, cross-cite from C7 #105) | L1 | [C10](C10_preflight_provisioning.md) |
@@ -0,0 +1,119 @@
+# Source Registry — C10: Pre-flight cache provisioning (cross-coupling minimal scope)
+
+> Mode A Phase 2 — engine Step 2 (Source Tiering & Exhaustive Web Investigation). Sources for C10 batch 1 (cross-coupling minimal: D-C6-3 descriptor-cache rebuild trigger pipeline + D-C7-7 TensorRT engine-build pipeline). Sibling registries: [SQ1](SQ1_existing_systems.md), [SQ2](SQ2_canonical_pipeline.md), [SQ6](SQ6_external_positioning.md), [C1](C1_vio.md), [C2](C2_vpr.md), [C3](C3_matchers.md), [C4](C4_pose_estimation.md), [C5](C5_state_estimator.md), [C6](C6_tile_cache_spatial_index.md), [C7](C7_inference_runtime.md), [C8](C8_fc_adapter.md). Index: [`00_summary.md`](00_summary.md).
+>
+> Source-tier definitions per `references/source-tiering.md`: L1 = official primary docs / source code / canonical specs; L2 = official blog posts, vendor SDK docs, peer-reviewed papers; L3 = community Q&A, tutorial sites, secondary commentary; L4 = forum posts, mailing-list threads, single-author blog posts.
+
+---
+
+## Source #114 — FAISS `write_index` / `read_index` Python API + on-disk format + security warning (L1 official)
+
+**URL**: <https://github.com/facebookresearch/faiss/wiki/Index-IO,-cloning-and-hyper-parameter-tuning> + context7 indexed at `/facebookresearch/faiss` (Benchmark Score consistent with C6 batch 1 Source #96 lookup)
+
+**Date accessed**: 2026-05-08
+
+**Tier**: **L1** — canonical FAISS GitHub Wiki + canonical context7-indexed documentation
+
+**Relevance**: Confirms `faiss.write_index(index, path)` + `faiss.read_index(path)` Python API for serializing IndexHNSWFlat to disk and loading it back; confirms `IO_FLAG_MMAP_IFC` enables memory-mapped loading for HNSW + IndexFlatCodes-derived classes (zero-copy load — important for the project's <5 s takeoff load budget); documents the explicit security warning "No attempt is made to check the correctness of loaded data. A faulty or malicious file could lead to out-of-memory errors or code execution. Users are responsible for verifying that files loaded with `read_index` have not been altered since being written by `write_index`." This warning binds directly to AC-NEW-7 (cache-poisoning safety) and motivates the project-side content-hash verification gate before takeoff load. Confirms FAISS C++ signature: `void write_index(Index* index, const char* filename)` / `Index* read_index(const char* filename)`.
+
+**Evidence quality**: ✅ High — L1 canonical FAISS docs. Direct API verification.
+
+---
+
+## Source #115 — FAISS IndexHNSWFlat per-vector memory + on-disk file size formula (L2 community + L1 cross-cite)
+
+**URL**: <https://github.com/facebookresearch/faiss/discussions/3953> + cross-cite <https://faiss.ai/cpp_api/struct/structfaiss_1_1IndexHNSWFlat.html>
+
+**Date accessed**: 2026-05-08
+
+**Tier**: **L2** — FAISS GitHub Discussions thread (maintainer-confirmed answer) + L1 canonical FAISS C++ API docs cross-cite
+
+**Relevance**: Confirms IndexHNSWFlat per-vector on-disk + RAM cost formula: `(vector_dim × 4 bytes) + (M × 4 bytes × 2) + overhead from graph layers and geometric reallocation`. For project's pinned VPR descriptor candidates (per D-C2-9 / D-C2-10 / D-C2-6 / D-C6-1 = halfvec): at 2048-D float32 + M=32 → 8192 + 256 = **8448 bytes/vector** (~845 MB on disk for 100K tiles); at 2048-D halfvec (2-byte storage per descriptor element) → 4096 + 256 = **4352 bytes/vector** (~430 MB on disk for 100K tiles); at 512-D halfvec + M=32 → 1024 + 256 = **1280 bytes/vector** (~130 MB on disk for 100K tiles); at 256-D halfvec + M=32 → 512 + 256 = **768 bytes/vector** (~80 MB on disk for 100K tiles). All variants well within AC-8.3 10 GB cache budget (assuming D-C2-10 EigenPlaces 512-D path or D-C6-1 halfvec mitigation). Supplementary cross-cite to C6 Fact #92 evidence base. **Load latency**: Issue #622 confirms post-load search performance is "slightly slower initially due to memory layout and cache effects" but identical results — implies a warmup-search-pass at takeoff after `read_index` would smooth p99 latency; aligns with the <5 s takeoff load budget (pure file read at ~430 MB / SATA SSD ~500 MB/s = <1 s; mmap path eliminates the read entirely).
+
+**Evidence quality**: ✅ High — formula matches FAISS source code in `IndexHNSW.cpp`; multiple maintainer-confirmed reproductions; conservative for project's pinned descriptor dimensions per D-C2-9/10/6 closures.
+
+---
+
+## Source #116 — Python atomic file write pattern: write-to-temp + fsync + atomic rename (L2 reference + L1 POSIX standard cross-cite)
+
+**URL**: <https://blog.gocept.com/2013/07/15/reliable-file-updates-with-python/> + <https://python-atomicwrites.readthedocs.io/en/stable> + Python tracker Issue 8604 <https://bugs.python.org/issue8604>
+
+**Date accessed**: 2026-05-08
+
+**Tier**: **L2** — well-known engineering blog reference + canonical Python package docs + Python core developer issue tracker
+
+**Relevance**: Documents the canonical Python crash-safe atomic file write pattern required for the project's pre-flight FAISS index file write (and TensorRT engine file write). The pattern is: (1) write to a temporary file in the same directory as target (ensures same filesystem so `os.rename` is atomic), (2) call `fsync(temp_fd)` to flush content + metadata to disk, (3) atomically rename via `os.rename(temp_path, target_path)`, (4) call `fsync` on the parent directory to flush the filename change to disk. Without this pattern, a power loss or process kill mid-write leaves a truncated/partial file that `faiss.read_index` will load successfully (no internal integrity check per Source #114 warning) and produce silently-wrong descriptor matches at takeoff — direct violation of AC-NEW-7 (cache-poisoning safety) + AC-3.3 (re-localization stability). The `python-atomicwrites` package provides this pattern with a simple API: `with atomic_write(path, overwrite=True) as f: ...`; pure-Python; trivially auditable; cross-platform (Windows + POSIX + macOS). On macOS specifically, must use `fcntl.fcntl(fd, fcntl.F_FULLFSYNC)` instead of `os.fsync()` to handle Apple's user-space write buffers — not relevant for the Jetson deployment target (Linux/JetPack). Project-side wrapper around `faiss.write_index` should use this pattern to safely write the FAISS cache file alongside content-hash verification.
+
+**Evidence quality**: ✅ High — pattern matches POSIX `rename(2)` atomicity guarantee; extensively documented; multiple production Python packages (atomicwrites, ruamel-yaml, etc.) implement it.
+
+---
+
+## Source #117 — Polygraphy `polygraphy convert` CLI for TensorRT INT8 engine build with calibration cache reuse (L1 official)
+
+**URL**: <https://github.com/NVIDIA/TensorRT/blob/main/tools/Polygraphy/examples/cli/convert/01_int8_calibration_in_tensorrt/README.md> + context7 indexed at `/websites/nvidia_deeplearning_tensorrt_static_polygraphy` (1041 code snippets, Benchmark Score 67.2, Source Reputation High)
+
+**Date accessed**: 2026-05-08
+
+**Tier**: **L1** — official NVIDIA TensorRT source repository documentation + canonical Polygraphy docs
+
+**Relevance**: Confirms Polygraphy as the canonical NVIDIA-blessed orchestration wrapper around TensorRT's engine build pipeline. Documents the canonical INT8 calibration workflow: first build with `--data-loader-script ./data_loader.py --calibration-cache identity_calib.cache` (computes scales + writes cache); subsequent builds with `--calibration-cache identity_calib.cache` (skips calibration step entirely — cache contains scales). Confirms Polygraphy's `Calibrator` class API: `data_loader` parameter (generator/iterable yielding `{input_name: numpy.ndarray}` dicts), `cache` parameter (calibration cache file path), `BaseClass` parameter (defaults to `trt.IInt8EntropyCalibrator2` — matches project's D-C7-2 + D-C7-6 lock), `algo` parameter (defaults to `trt.CalibrationAlgoType.MINMAX_CALIBRATION`). CLI supports `--int8 --fp16` mixed precision flags directly per project's D-C7-2 = (b) per-family precision policy. The full CLI invocation pattern for project: `polygraphy convert <model>.onnx --int8 --fp16 --data-loader-script ./calib_data_loader.py --calibration-cache <model>_calib.cache -o <model>_sm87_jp62_trt103_int8fp16.engine`. Polygraphy is bundled inside the TensorRT distribution (no separate install on Jetson — `pip install nvidia-pyindex && pip install polygraphy` or via TensorRT installer). Production-mature and cross-referenced from canonical TensorRT documentation.
+
+**Evidence quality**: ✅ High — official NVIDIA repository docs, multi-snippet context7 coverage, production-mature tooling.
+
+---
+
+## Source #118 — Polygraphy `Calibrator` class API — algo defaults + dynamic-shapes calibration profile + warning behavior (L1 official)
+
+**URL**: <https://docs.nvidia.com/deeplearning/tensorrt/latest/_static/polygraphy/backend/trt/calibrator.html> + <https://docs.nvidia.com/deeplearning/tensorrt/latest/_static/polygraphy/backend/trt/config.html>
+
+**Date accessed**: 2026-05-08
+
+**Tier**: **L1** — canonical NVIDIA TensorRT/Polygraphy SDK documentation
+
+**Relevance**: Confirms `Calibrator(data_loader, cache=None, BaseClass=IInt8EntropyCalibrator2, algo=CalibrationAlgoType.MINMAX_CALIBRATION, batch_size=None, quantile=None, regression_cutoff=None)` full signature. Documents two algorithm choices: `IInt8EntropyCalibrator2` (entropy-based; project D-C7-2 default; Polygraphy default) vs `IInt8MinMaxCalibrator` (min-max scaling). Documents dynamic-shapes behavior: "if calibration is run and the model has dynamic shapes, the last optimization profile will be used as the calibration profile" — relevant for project's matchers if any of them export with dynamic input shapes (D-C3-2 LightGlue ONNX export pathway). Documents `--data-loader-script` / `--data-loader-func-name` CLI flags for supplying custom calibration data. Documents the "Int8 Calibration is using randomly generated input data" warning that fires when `--int8` is set but neither `--data-loader-script` nor an existing `--calibration-cache` is supplied — operationalizes the D-C7-1 closure (real UAV nadir flight footage corpus) as a pre-flight build prerequisite. CLI also supports `--load-tactics` / `--save-tactics` for replaying tactic-search results across multiple builds (faster than re-running tactic profiling each build) — useful for the reference-Jetson-prebuilt-engine fallback path per D-C7-7.
+
+**Evidence quality**: ✅ High — canonical NVIDIA documentation, directly cited from polygraphy/tools/args/backend/trt/config source code.
+
+---
+
+## Source #119 — `trtexec` CLI for one-off engine builds — INT8/FP16 flags + calibration cache support (L1 official)
+
+**URL**: <https://docs.nvidia.com/deeplearning/tensorrt/latest/getting-started/quick-start-guide.html> + <https://docs.nvidia.com/deeplearning/tensorrt/latest/reference/command-line-programs.html>
+
+**Date accessed**: 2026-05-08
+
+**Tier**: **L1** — canonical NVIDIA TensorRT SDK documentation
+
+**Relevance**: Confirms `trtexec` as the simpler-but-less-flexible TensorRT engine build CLI bundled with every TensorRT installation. Canonical invocation: `trtexec --onnx=model.onnx --saveEngine=model.engine --fp16 --int8 --calib=calibration.cache --shapes=input:1x3x224x224`. Supports `--int8 --fp16` mixed precision (matches project's D-C7-2). Supports `--calib=<cache_path>` for INT8 calibration cache reuse (cache file format identical to Polygraphy's; the two tools are interoperable on the calibration cache layer). **Critical limitation vs Polygraphy**: `trtexec --int8` without `--calib` causes TRT to use random data for calibration (per TRT docs warning) — this collapses INT8 accuracy by ~5-15%. **Strength**: single-binary; no Python imports; no calibration data loader script required; perfect for emergency rebuilds when an existing calibration cache is available; perfect for ad-hoc benchmarking via `--iterations=N --useCudaGraph --noDataTransfers`. **Recommended role for project**: fallback orchestration tool when Polygraphy is unavailable OR when calibration cache is already shipped from a reference build (e.g., the prebuilt-engine fallback per D-C7-7).
+
+**Evidence quality**: ✅ High — canonical NVIDIA documentation; trtexec is bundled with TensorRT distributions and has been the canonical TensorRT CLI since TensorRT 5.x.
+
+---
+
+## Source #120 — TensorRT INT8 INT8 calibration corpus size guidance (~500-1000 images) — Jetson AGX Orin specific (L2 vendor)
+
+**URL**: <https://nvnexus.com/tensorrt-jetson-agx-orin-optimization-guide/>
+
+**Date accessed**: 2026-05-08
+
+**Tier**: **L2** — vendor-aligned engineering guide (TensorRT-on-Jetson specialist content), cross-cited from official NVIDIA Developer Forum patterns
+
+**Relevance**: Independent confirmation of the project's D-C7-1 closure: "INT8 optimization can double inference throughput on Jetson AGX Orin with minimal accuracy loss; calibration on representative input data (500-1000 images recommended)". Aligns with project's pinned 500-1500 sample range from C7 batch 1 Fact #94. Cross-cite to AGX Orin (server-class Jetson) — the project's deployment target is Orin Nano Super (smaller class), but the calibration-corpus-size guidance is governed by the model + INT8 entropy-statistics requirement, not by the Jetson SKU. **Conservative confirmation**: project's calibration corpus target of 500-1500 samples per D-C7-1 closure is sufficient by community-confirmed benchmarks.
+
+**Evidence quality**: ⚠️ Medium-High — L2 vendor-aligned source; aligns with multiple independent confirmations including NVIDIA Developer Forum threads and the canonical TensorRT INT8 calibration documentation; project's D-C7-1 closure already pinned this range from L1 sources.
+
+---
+
+## Source #121 — Direct TensorRT `IBuilderConfig` + `IInt8EntropyCalibrator2` Python API (L1 official, cross-cite from C7 Source #105)
+
+**URL**: <https://docs.nvidia.com/deeplearning/tensorrt/latest/_static/python/api/infer/Core/BuilderConfig.html> (cross-cite from C7 batch 1 Source #105 + Source #102)
+
+**Date accessed**: 2026-05-08 (cross-cite)
+
+**Tier**: **L1** — canonical NVIDIA TensorRT Python API documentation
+
+**Relevance**: Already cited in C7 batch 1 Source #102 + Source #105 (mode pinning for D-C7-2). Re-cited here for the C10 D-C7-7 confirmation context: confirms direct `IBuilderConfig` + `IInt8EntropyCalibrator2` Python API as the most-flexible-but-most-engineering-cost orchestration option. Pattern: instantiate `trt.Builder(logger)` → `builder.create_network(...)` → parse ONNX via `trt.OnnxParser` → instantiate `builder.create_builder_config()` → `config.set_flag(trt.BuilderFlag.INT8)` + `config.set_flag(trt.BuilderFlag.FP16)` → assign custom `Int8EntropyCalibrator2` subclass instance to `config.int8_calibrator` → `config.max_workspace_size = 1 << 30` (1 GB per D-C7-8) → `serialized_engine = builder.build_serialized_network(network, config)` → `with open(path, 'wb') as f: f.write(serialized_engine)`. **Used in C10 only as the per-model fallback path for the reference-Jetson-prebuilt-engine generation** (D-C7-7 fallback) when Polygraphy's data-loader-script abstraction is too rigid for an unusual model (e.g., LightGlue with dynamic-shape inputs requiring a custom calibration profile).
+
+**Evidence quality**: ✅ High — canonical NVIDIA Python API; cross-cite from existing C7 Source #105 reduces redundancy.
+
+---
@@ -0,0 +1,192 @@
+# 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)
@@ -0,0 +1,88 @@
+# Source Registry — C4 — Pose estimation (PnP + RANSAC + LM) 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 #82
+- **Title**: OpenCV canonical implementation — `opencv/opencv` (Open Source Computer Vision Library) GitHub repository metadata via GitHub API + LICENSE — **Apache-2.0** (`license.spdx_id: "Apache-2.0"`); 87385 stars + 56554 forks + 2606 subscribers + 2732 open issues; created 2012-07-19; **last pushed 2026-05-08T07:00:03Z = TODAY at access time** (daily-active maintenance); default branch `4.x`; size 555 GB; topics include `c-plus-plus, computer-vision, deep-learning, image-processing, opencv`
+- **Link**: GitHub API metadata https://api.github.com/repos/opencv/opencv (accessed 2026-05-08; `license.spdx_id: "Apache-2.0"` confirmed); canonical repo https://github.com/opencv/opencv ; canonical website https://opencv.org ; LICENSE file https://raw.githubusercontent.com/opencv/opencv/4.x/LICENSE (Apache License 2.0 standard text)
+- **Tier**: L1 (project-official codebase by the OpenCV organization; canonical reference computer-vision library used by every modern computer-vision deployment as the de-facto industry-standard classical-CV foundation; cited by every C-row component's deployment guide; canonical solvePnPRansac is the industry-standard reference RANSAC-PnP implementation that every modern alternative [OpenGV, GTSAM-PnP, Theia, Ceres-only] compares against in its own documentation)
+- **Publication Date**: original 2000 (Intel) → open-source release 2006 (Willow Garage) → OpenCV.org foundation 2020 → canonical 4.x branch active continuous development; access date 2026-05-08; daily commits to `4.x` branch
+- **Timeliness Status**: ✅ Within Established-baseline-reference window (2000+ — established competitive ground for classical computer-vision + RANSAC-PnP reference; Established-competitive-mandatory-baseline exemption applies — `cv::solvePnPRansac` is the **canonical RANSAC-PnP reference baseline** that defines the mandatory-simple-baseline role for the C4 row per the engine Component Option Breadth rule, structurally analogous to NetVLAD's role in C2 row + SuperGlue+SuperPoint's role in C3 row)
+- **Version Info**: 4.14.0-pre at access time (default branch `4.x` = next-major-release rolling-development branch; current stable release 4.10.0 from late 2025 at access date — 4.x is the project's pinned major version per Source #83 documentation footer "Generated on Fri May 8 2026 04:21:44 for OpenCV by 1.12.0"); JetPack 6 ships canonical `libopencv_calib3d.so` for ARM Cortex-A78AE = the project's pinned Jetson Orin Nano Super deployment runtime
+- **Target Audience**: System architects + C4 implementer + Step-7.5 reviewer + license-posture decision-maker (D-C1-1 — clean Apache-2.0) + C7 (Jetson runtime) implementer (canonical OpenCV is shipped with JetPack 6 distribution)
+- **Research Boundary Match**: **Full match** for the project's pinned C4 mandatory-simple-baseline mode (per-frame pose-from-correspondences via classical RANSAC-PnP with paired Levenberg-Marquardt refinement). The canonical `opencv/opencv` library ships everything needed for C4 deployment: `cv::solvePnPRansac` two function signatures (classical + USAC variant), nine `SolvePnPMethod` enum values, paired `cv::solvePnPRefineLM` LM refinement + alternate `cv::solvePnPRefineVVS` Gauss-Newton SO(3) refinement, paired `cv::solvePnPGeneric` for multi-solution + per-solution reprojection-error reporting, `cv::projectPoints` Jacobian for D-C4-2 post-hoc covariance recovery. **N/A for the project's domain caveat** — OpenCV solvePnPRansac is a classical algorithm with no training data; D-C2-1 retrain decision is irrelevant for OpenCV solvePnPRansac
+- **Summary**: OpenCV is the canonical industry-standard open-source computer vision library; the calib3d module ships `cv::solvePnPRansac` as the canonical RANSAC-PnP reference implementation. **CRITICAL LICENSE FINDING**: Apache-2.0 (`license.spdx_id: "Apache-2.0"`) — permissive, BSD/permissive license track on the C4 mandatory-simple-baseline; **deployment-ready under every D-C1-1 license-posture choice** with the cleanest license-compliance story tied with cvg/LightGlue + DISK + XFeat. **Daily-active maintenance**: last pushed 2026-05-08 (TODAY at access time) — among the most actively-maintained C-row references across all components evaluated. **Industry-standard reference status**: 87385 stars + 56554 forks + 2606 subscribers — the dominant industry-standard reference implementation that every modern C4 alternative (OpenGV, GTSAM-PnP, Theia, Ceres-only) compares against in its own documentation. **JetPack 6 canonical distribution**: canonical OpenCV is shipped with JetPack 6 distribution, providing zero-effort deployment for the project's pinned Jetson Orin Nano Super runtime
+- **Related Sub-question**: SQ3+SQ4 / C4 — OpenCV solvePnPRansac per-mode API capability verification (Mandatory `context7` lookup MCP-validation-error + WebFetch fallback PASS per Per-Mode rule item 2; cross-validated against canonical GitHub API license metadata WebFetch + canonical OpenCV calib3d module documentation [Source #83]); **D-C1-1 license-posture compliance**: clean Apache-2.0 throughout; **Mandatory-simple-baseline role per engine Component Option Breadth rule** confirmed; **JetPack 6 canonical distribution** documented
+
+
+### Source #83
+- **Title**: OpenCV 4.x calib3d module canonical documentation — group `cv::calib3d` (Camera Calibration and 3D Reconstruction) at `https://docs.opencv.org/4.x/d9/d0c/group__calib3d.html` + Perspective-n-Point (PnP) pose computation tutorial at `https://docs.opencv.org/4.x/d5/d1f/calib3d_solvePnP.html`; `cv::solvePnPRansac` two function signatures (classical with `iterationsCount=100, reprojectionError=8.0, confidence=0.99, flags=SOLVEPNP_ITERATIVE` defaults + USAC variant with `UsacParams` and `cameraMatrix` as `InputOutputArray` for focal-length refinement); Python bindings; `cv::SolvePnPMethod` enum 9 values; `cv::solvePnPRefineLM` + alternate `cv::solvePnPRefineVVS`; `cv::solvePnPGeneric` for multi-solution + per-solution reprojection-error reporting; USAC RANSAC-method enum 7 modern variants
+- **Link**: calib3d module documentation https://docs.opencv.org/4.x/d9/d0c/group__calib3d.html (accessed 2026-05-08); PnP tutorial page https://docs.opencv.org/4.x/d5/d1f/calib3d_solvePnP.html (accessed 2026-05-08); both pages footer-stamped "Generated on Fri May 8 2026 04:21:44 for OpenCV by 1.12.0" — fresh canonical documentation at the project's evaluation time
+- **Tier**: L1 (canonical project-official documentation by the OpenCV organization; the canonical reference for the `cv::solvePnPRansac` function signature, parameter defaults, paired refinement variants, minimal-solver enum values, and structural caveats; auto-generated by Doxygen 1.12.0 from canonical opencv/opencv source code at `4.x` branch)
+- **Publication Date**: rolling Doxygen documentation auto-regenerated on every push to `4.x` branch; access date 2026-05-08 04:21:44 page-generation timestamp
+- **Timeliness Status**: ✅ Within Established-baseline-reference window (rolling Doxygen documentation; the canonical reference for `cv::solvePnPRansac` API surface at the project's evaluation time)
+- **Version Info**: 4.14.0-pre at access time (default branch `4.x` = next-major-release rolling-development branch). **Mode-enumeration query (1/3) — context7 MCP-validation-error + WebFetch fallback PASS** — `context7 resolve-library-id` returned MCP validation errors (parameter schema mismatch on both `query` and `libraryName` argument names — context7 server expects different argument shape than provided); per Per-Mode API Capability Verification rule item 2, fall-back to official-docs WebFetch on the canonical OpenCV calib3d module documentation + PnP tutorial page was used (this Source #83). **Nine `SolvePnPMethod` enum values documented** at line 243 of the calib3d.html: `SOLVEPNP_ITERATIVE=0` (default; iterative LM-based on top of EPNP minimal-solver result), `SOLVEPNP_EPNP=1` (Efficient Perspective-n-Point [Lepetit et al. IJCV 2009]; canonical default for ≥4 non-planar correspondences), `SOLVEPNP_P3P=2` (Revisiting the P3P Problem [Ding et al. 2023]; minimal-solver for exactly-3 correspondences with up to 4 solutions), `SOLVEPNP_DLS=3` (**BROKEN per explicit docstring "Broken implementation. Using this flag will fallback to EPnP"** — Direct Least-Squares method [Hesch & Roumeliotis 2011] originally), `SOLVEPNP_UPNP=4` (**BROKEN per explicit docstring "Broken implementation. Using this flag will fallback to EPnP"** — Exhaustive Linearization for Robust Camera Pose and Focal Length Estimation [Penate-Sanchez et al. 2013] originally), `SOLVEPNP_AP3P=5` (Algebraic P3P [Ke & Roumeliotis CVPR 2017]), `SOLVEPNP_IPPE=6` (Infinitesimal Plane-Based Pose Estimation [Collins & Bartoli ECCV 2014]; **planar-only — object points must be coplanar — directly relevant to project's D-C4-1 = 4-DoF flat-earth lift recommendation**), `SOLVEPNP_IPPE_SQUARE=7` (special-case IPPE for marker pose with 4 fixed-pattern points), `SOLVEPNP_SQPNP=8` (SQPnP: A Consistently Fast and Globally Optimal Solution [Terzakis & Lourakis ECCV 2020]; **modern globally-optimal alternate without planarity restriction — second-recommended fallback if D-C4-1 chooses 6-DoF DSM lift**). **`cv::solvePnPRansac` classical signature** at line 3211 of calib3d.html: `bool solvePnPRansac(InputArray objectPoints, InputArray imagePoints, InputArray cameraMatrix, InputArray distCoeffs, OutputArray rvec, OutputArray tvec, bool useExtrinsicGuess=false, int iterationsCount=100, float reprojectionError=8.0, double confidence=0.99, OutputArray inliers=noArray(), int flags=SOLVEPNP_ITERATIVE)` — Python `cv.solvePnPRansac(objectPoints, imagePoints, cameraMatrix, distCoeffs[, rvec[, tvec[, useExtrinsicGuess[, iterationsCount[, reprojectionError[, confidence[, inliers[, flags]]]]]]]]) -> retval, rvec, tvec, inliers`. **`cv::solvePnPRansac` USAC variant signature** at line 3261: `bool solvePnPRansac(InputArray objectPoints, InputArray imagePoints, InputOutputArray cameraMatrix, InputArray distCoeffs, OutputArray rvec, OutputArray tvec, OutputArray inliers, const UsacParams& params=UsacParams())` — Python `cv.solvePnPRansac(objectPoints, imagePoints, cameraMatrix, distCoeffs[, rvec[, tvec[, inliers[, params]]]]) -> retval, cameraMatrix, rvec, tvec, inliers`; note `cameraMatrix` is `InputOutputArray` in the USAC variant, allowing focal-length refinement during the RANSAC loop. **`cv::solvePnPRefineLM`** at line 3268: canonical default `TermCriteria(EPS+COUNT, 20, FLT_EPSILON)`. **CRITICAL CAVEAT** documented at the PnP-tutorial page: "the current implementation computes the rotation update as a perturbation and not on SO(3)" — minor structural caveat; alternate `cv::solvePnPRefineVVS` at line 3289 uses Gauss-Newton with rotation update via exponential map on SO(3) (preferred for high-accuracy aerial pose-from-correspondences). **`cv::solvePnPGeneric`** at line 370: returns multiple candidate solutions sorted by reprojection error + an `OutputArray reprojectionError` per-solution. **Default minimal-sample-set method** at line 3256: "The default method used to estimate the camera pose for the Minimal Sample Sets step is `SOLVEPNP_EPNP`. Exceptions are: if you choose `SOLVEPNP_P3P` or `SOLVEPNP_AP3P`, these methods will be used; if the number of input points is equal to 4, `SOLVEPNP_P3P` is used." **USAC RANSAC-method enumeration** at the calib3d.html anonymous-enum block: canonical RANSAC, LMEDS, RHO, **USAC_DEFAULT, USAC_PARALLEL, USAC_FM_8PTS, USAC_FAST, USAC_ACCURATE, USAC_PROSAC, USAC_MAGSAC** — modern USAC variants (Barath et al. CVPR 2019 + ICCV 2019 MAGSAC++) provide higher inlier-recovery rate than vanilla RANSAC at the same iteration budget; **USAC_MAGSAC is the canonical sigma-consensus modern alternative to vanilla RANSAC** with no fixed inlier threshold
+- **Target Audience**: System architects + C4 implementer + Step-7.5 reviewer + Plan-phase architect (mandatory-simple-baseline role documentation for engine Component Option Breadth rule compliance + D-C4-1 2D-3D-lift architectural decision carry-forward + D-C4-2 NEW covariance-recovery-strategy gate)
+- **Research Boundary Match**: **Full match** for the C4 row's pinned mode (per-frame pose-from-correspondences contract on Jetson Orin Nano Super; inputs = up to 1024 3D-2D correspondences from C3's 2D-2D + D-C4-1's 2D→3D lift + camera intrinsic + distortion; outputs = 6-DoF camera pose + per-correspondence inlier mask + reprojection error + RANSAC iter count + 6×6 covariance via D-C4-2). The canonical OpenCV calib3d module documentation provides the complete API surface for the project's pinned mode: two function signatures, nine minimal-solver enum values, paired LM + Gauss-Newton SO(3) refinement, paired multi-solution reporting with reprojection error, USAC RANSAC-method enumeration with 7 modern variants. **CRITICAL contract finding**: the documented signature requires `objectPoints` Nx3 1-channel + `imagePoints` Nx2 1-channel — **3D-2D, not 2D-2D**; the project must perform a 2D→3D lift on C3's satellite-tile-side 2D pixels via D-C4-1's 4-DoF flat-earth lift recommendation (project default) before calling solvePnPRansac. **CRITICAL covariance finding**: the documented signature returns `retval, rvec, tvec, inliers` only — **NO direct 6×6 covariance output**; AC-NEW-4 covariance-honesty contract requires D-C4-2 NEW Plan-phase decision for covariance-recovery-strategy
+- **Summary**: The canonical OpenCV 4.x calib3d module documentation is the definitive reference for `cv::solvePnPRansac` API surface, parameter defaults, paired refinement variants, minimal-solver enum values, and structural caveats. Two function signatures (classical + USAC variant), nine `SolvePnPMethod` enum values (4 valid for general project use + 2 special-case + 1 ITERATIVE default + 2 BROKEN-fallback-to-EPNP), paired `cv::solvePnPRefineLM` (LM with rotation update as perturbation, NOT on SO(3)) + alternate `cv::solvePnPRefineVVS` (Gauss-Newton on SO(3) via exponential map) refinement, paired `cv::solvePnPGeneric` for multi-solution + per-solution reprojection-error reporting, USAC RANSAC-method enumeration with 7 modern variants (USAC_DEFAULT, USAC_PARALLEL, USAC_FM_8PTS, USAC_FAST, USAC_ACCURATE, USAC_PROSAC, USAC_MAGSAC). **CRITICAL findings for the C4 row**: (i) **3D-2D INPUT CONTRACT, NOT 2D-2D** — solvePnPRansac requires Nx3 objectPoints + Nx2 imagePoints; project must perform 2D→3D lift via D-C4-1's locked-in 4-DoF flat-earth lift recommendation before invocation; (ii) **NO DIRECT 6×6 COVARIANCE OUTPUT** — AC-NEW-4 covariance-honesty contract requires D-C4-2 NEW Plan-phase decision for covariance-recovery-strategy; (iii) **TWO MINIMAL-SOLVER ENUM VALUES BROKEN** — SOLVEPNP_DLS + SOLVEPNP_UPNP fall back to EPNP per explicit docstring; valid set is `EPNP / AP3P / IPPE / SQPNP` plus 2 special-case (`P3P` for exactly-3; `IPPE_SQUARE` for 4-fixed-pattern markers) plus `ITERATIVE` default; (iv) **`cv::solvePnPRefineLM` ROTATION UPDATE NOT ON SO(3)** — minor caveat; alternate `cv::solvePnPRefineVVS` is the SO(3)-correct refiner. Canonical default minimal-sample-set method is `SOLVEPNP_EPNP`; recommended pairing for D-C4-1 = 4-DoF flat-earth lift is `SOLVEPNP_IPPE` (planar-scene minimal-solver designed for coplanar object points) with `SOLVEPNP_SQPNP` as the modern globally-optimal fallback
+- **Related Sub-question**: SQ3+SQ4 / C4 — OpenCV solvePnPRansac per-mode API capability verification (cross-source verification of canonical API documentation + structural caveats + minimal-solver enum + paired refinement variants); **D-C4-2 NEW Plan-phase decision raised** for covariance-recovery-strategy; **D-C4-1 carry-forward REINFORCED** by the 3D-2D-input-contract finding (applies to all C4 candidates, not unique to OpenCV); cross-cite to Fact #20 + #21 closures from C2 row (canonical PnP+RANSAC+LM reference pipeline shape feeds AC-NEW-4 covariance-honesty contract)
+
+
+### Source #84
+- **Title**: OpenGV canonical implementation — `laurentkneip/opengv` (A library for solving calibrated central and non-central geometric vision problems) GitHub repository metadata via GitHub API + License.txt — **BSD-3-Clause-equivalent boilerplate** ("Author: Laurent Kneip, ANU. All rights reserved." with three numbered redistribution conditions including non-endorsement clause; **GitHub API license SPDX detector reports `license.spdx_id: "NOASSERTION"`** because the License.txt file does NOT use the canonical Open Source Initiative BSD-3-Clause boilerplate text — verified by direct WebFetch of `https://raw.githubusercontent.com/laurentkneip/opengv/master/License.txt`); 1109 stars + 358 forks + 66 subscribers + 58 open issues; created 2013-08-10; **last pushed 2023-06-07T18:14:14Z = ~2 years 11 months stale at access time 2026-05-08** (CRITICAL maintenance finding); default branch `master`; size 7790 KB; description "OpenGV is a collection of computer vision methods for solving geometric vision problems. It is hosted and maintained by the Mobile Perception Lab of ShanghaiTech."
+- **Link**: GitHub API metadata https://api.github.com/repos/laurentkneip/opengv (accessed 2026-05-08); canonical repo https://github.com/laurentkneip/opengv ; License.txt https://raw.githubusercontent.com/laurentkneip/opengv/master/License.txt (BSD-3-Clause-equivalent boilerplate verified via WebFetch); canonical Doxygen documentation portal https://laurentkneip.github.io/opengv/
+- **Tier**: L1 (project-official codebase by Laurent Kneip + ShanghaiTech Mobile Perception Lab; canonical reference for non-OpenCV PnP solvers including p3p_kneip [Kneip et al. CVPR 2011], p3p_gao [Gao et al. PAMI 2003], UPnP [Kneip et al. ECCV 2014], gpnp [Kneip 2014 generalized PnP], gp3p [generalized 3-point]; cited by every modern multi-camera + central-camera + relative-pose paper since 2014; field-standard for non-trivial PnP variants beyond OpenCV's `cv::solvePnPRansac` coverage)
+- **Publication Date**: original 2013-08-10 → continuous development 2013-2018 → maintenance gap 2018-2023 → last pushed 2023-06-07; access date 2026-05-08; **Doxygen documentation portal generation timestamp "Generated on Mon Jan 8 2018 21:43:04 for OpenGV by 1.8.11" — documentation page is 8.3 years old at access time**
+- **Timeliness Status**: ⚠️ Within Established-baseline-reference window (2013+ — established competitive ground for non-OpenCV PnP minimal solvers + generalized-camera support) but **with CRITICAL ~3-year maintenance staleness caveat** — Established-competitive-mandatory-baseline exemption applies (OpenGV is the canonical reference for non-trivial PnP variants beyond OpenCV) but Plan-phase decision-maker MUST account for: (i) no security patches since 2023; (ii) no Eigen 3.4+ compatibility patches; (iii) no JetPack 6 + ARM Cortex-A78AE compilation testing in upstream CI; (iv) ShanghaiTech Mobile Perception Lab's claim of active maintenance is contradicted by the GitHub commit history at access time
+- **Version Info**: master branch at git commit ea7c66f5e (last commit 2023-06-07T18:14:14Z); no version tags, no releases. **Mode-enumeration query (1/3) — context7 NOT INDEXED + WebFetch fallback PASS** — `context7 resolve-library-id` returned only OpenCV variants for the OpenGV query (top-5 results were `/websites/opencv_4_x` + `/websites/opencv_4_6_0` + `/opencv/opencv` + `/opencv/opencv-python` + `/websites/opencv_5_0_0-alpha` — all unrelated to OpenGV); per Per-Mode API Capability Verification rule item 2, fall-back to official-docs WebFetch on canonical Doxygen portal `laurentkneip.github.io/opengv/page_how_to_use.html` was used (this Source #85 below + License.txt verification on this Source #84). **Absolute pose minimal solvers documented** via Source #85 §"Central absolute pose": `absolute_pose::p2p` (with known rotation), `absolute_pose::p3p_kneip` [Kneip CVPR 2011], `absolute_pose::p3p_gao` [Gao PAMI 2003], `absolute_pose::upnp` [Kneip ECCV 2014]. **Absolute pose non-minimal solvers documented**: `absolute_pose::epnp` [Lepetit IJCV 2009 — same algorithm as OpenCV's SOLVEPNP_EPNP], `absolute_pose::upnp` (also valid for non-minimal). **Generalized/multi-camera absolute pose solvers documented** via Source #85 §"Non-central absolute pose": `absolute_pose::gp3p` (Kneip 3-point generalized), `absolute_pose::gpnp` [Kneip 2014]. **Non-linear LM optimizer documented**: `absolute_pose::optimize_nonlinear(adapter)` — handles both central + non-central cases; canonical refinement after RANSAC. **RANSAC documented**: `sac::Ransac` + `sac_problems::absolute_pose::AbsolutePoseSacProblem(adapter, algorithm)` with **algorithm parameter selectable from {KNEIP, GAO, EPNP, GP3P}** — richer minimal-solver selection than OpenCV's effectively-4-valid SolvePnPMethod enum (EPNP/AP3P/IPPE/SQPNP after 2 BROKEN entries removed). **CRITICAL input-contract finding**: OpenGV uses **bearing vectors (3D unit vectors)** as input, NOT 2D pixel coordinates — adapters (`AbsoluteAdapterBase`, `RelativeAdapterBase`, `PointCloudAdapterBase`) convert from user data format to OpenGV bearing-vector representation; project must implement adapter or use `CentralAbsoluteAdapter(bearingVectors, points)` constructor where bearingVectors are pre-computed unit vectors via inverse camera-intrinsic projection from C3's pixel correspondences. **CRITICAL threshold-structure finding**: RANSAC threshold is a **3D angle (radians)** between bearing vectors, NOT a 2D pixel reprojection error — Source #85 documents the conversion `ransac.threshold_ = 1.0 - cos(atan(sqrt(2.0)*0.5/800.0))` for a focal length of 800 px and 0.5*sqrt(2.0) pixel reprojection-error-equivalent
+- **Target Audience**: System architects + C4 implementer + Step-7.5 reviewer + license-posture decision-maker (D-C1-1 — BSD-3-Clause-equivalent contingent on Plan-phase license-clearance verification due to NOASSERTION SPDX-detector status) + C7 (Jetson runtime) implementer (canonical OpenGV requires custom build on JetPack 6 ARM Cortex-A78AE — no canonical Jetson distribution; Plan-phase MVE prerequisite)
+- **Research Boundary Match**: **Partial match** for the project's pinned C4 mode (per-frame pose-from-correspondences via classical RANSAC-PnP with paired LM refinement) — algorithm coverage is RICHER than OpenCV at the minimal-solver axis (UPnP for both minimal+non-minimal, GP3P for generalized cameras, 2 P3P variants [Kneip + Gao] vs OpenCV's 1 P3P variant [Ke & Roumeliotis 2017 AP3P]) BUT the input contract (bearing vectors, not pixels) + threshold contract (3D angle, not pixels) + maintenance status (~3 years stale) require Plan-phase mitigation work. **N/A for the project's domain caveat** — OpenGV is a classical algorithm library with no training data; D-C2-1 retrain decision is irrelevant for OpenGV
+- **Summary**: OpenGV is the canonical reference for non-OpenCV PnP minimal solvers + generalized-camera support. **CRITICAL LICENSE FINDING**: License.txt content matches BSD-3-Clause boilerplate (three numbered redistribution conditions including non-endorsement clause) — eligible on every D-C1-1 license-posture choice CONTINGENT on Plan-phase license-clearance verification gate (because GitHub API SPDX detector reports `NOASSERTION`, indicating the License.txt file uses non-standard boilerplate that didn't match the OSI BSD-3-Clause template detection — recommend Plan-phase counsel-review of the License.txt text to confirm BSD-3-Clause-equivalent dual-use compatibility). **CRITICAL MAINTENANCE FINDING**: ~3 years stale at access time (last pushed 2023-06-07; Doxygen documentation portal generated 2018-01-08); ShanghaiTech Mobile Perception Lab's claimed maintenance is contradicted by commit history. **POSITIVE structural findings**: (i) richer minimal-solver coverage than OpenCV (UPnP minimal+non-minimal, GP3P generalized, 2 P3P variants); (ii) canonical reference for non-trivial PnP variants every modern paper compares against; (iii) generalized-camera support (multi-camera rig, non-central absolute pose) — not directly applicable to project's pinned 1× ADTi 20MP nav frame but architecturally cleaner if the project later adds a side-looking camera. **NEGATIVE structural findings**: (iv) bearing-vector input contract requires adapter or pre-computed unit-vector conversion from pixel correspondences (additional engineering vs OpenCV's direct pixel input); (v) 3D-angle RANSAC threshold requires conversion from project's pixel-reprojection-error budget; (vi) NO direct 6×6 covariance output from `optimize_nonlinear` (same finding as OpenCV — D-C4-2 covariance-recovery-strategy applies identically to OpenGV)
+- **Related Sub-question**: SQ3+SQ4 / C4 — OpenGV per-mode API capability verification (Mandatory `context7` lookup NOT-INDEXED + WebFetch fallback PASS per Per-Mode rule item 2; cross-validated against canonical GitHub API metadata WebFetch + canonical License.txt WebFetch + canonical Doxygen documentation portal [Source #85]); **D-C1-1 license-posture compliance**: BSD-3-Clause-equivalent CONTINGENT on Plan-phase license-clearance verification gate (NOASSERTION SPDX-detector caveat); **D-C4-1 carry-forward REINFORCED** (bearing-vector input contract still requires 2D→3D lift on satellite-tile-side from pixel correspondences); **D-C4-2 NEW gate APPLIES IDENTICALLY** to OpenGV (`optimize_nonlinear` returns no covariance — same Plan-phase mitigation strategies as OpenCV); **D-C4-3 NEW gate raised by OpenGV closure** — license-clearance verification due to NOASSERTION SPDX status; **D-C4-4 NEW gate raised by OpenGV closure** — maintenance-staleness mitigation (Plan-phase decision: accept-as-is + freeze upstream / fork into project-controlled branch + apply Eigen-3.4+ + JetPack-6 patches in-house / migrate to Ceres-only as fallback if patches not feasible)
+
+
+### Source #85
+- **Title**: OpenGV canonical Doxygen documentation portal — `laurentkneip.github.io/opengv/page_how_to_use.html` (How to use OpenGV: vocabulary, library organization, adapter pattern interface, conventions, problem types and examples) + `namespaceopengv.html` (top-level namespace) + `namespaceopengv_1_1absolute__pose.html` (absolute-pose methods reference) + `namespaceopengv_1_1relative__pose.html` (relative-pose methods reference) + `namespaceopengv_1_1sac.html` + `namespaceopengv_1_1sac__problems_1_1absolute__pose.html`
+- **Link**: documentation portal entry https://laurentkneip.github.io/opengv/ (accessed 2026-05-08); how-to-use page https://laurentkneip.github.io/opengv/page_how_to_use.html (accessed 2026-05-08; **Doxygen-generated 2018-01-08 21:43:04 by Doxygen 1.8.11 = 8.3 years old at access time**)
+- **Tier**: L1 (canonical project-official Doxygen-generated documentation; the canonical reference for OpenGV's adapter pattern, function signatures, RANSAC integration, and threshold-structure conventions)
+- **Publication Date**: page-generation 2018-01-08; access date 2026-05-08
+- **Timeliness Status**: ⚠️ Established-baseline-reference window with **8.3-year-old documentation** — Plan-phase architect MUST cross-check actual `master` branch source (`opengv/include/opengv/absolute_pose/methods.hpp` + `opengv/include/opengv/sac/Ransac.hpp` + `opengv/include/opengv/sac_problems/absolute_pose/AbsolutePoseSacProblem.hpp`) for any signature drift between 2018 documentation and 2023-06-07 master branch HEAD. The documentation portal is structurally complete for the canonical 2013-2018 published API surface; subsequent commits (2018-2023) appear to be primarily fix commits + ShanghaiTech-era additions
+- **Version Info**: master branch at git commit ea7c66f5e (last commit 2023-06-07). **Pinned-mode runnable example query (2/3) — WebFetch PASS**: Source #85 §"Central absolute pose" provides the canonical OpenGV runnable example: `absolute_pose::CentralAbsoluteAdapter adapter(bearingVectors, points); std::shared_ptr<sac_problems::absolute_pose::AbsolutePoseSacProblem> absposeproblem_ptr(new sac_problems::absolute_pose::AbsolutePoseSacProblem(adapter, sac_problems::absolute_pose::AbsolutePoseSacProblem::KNEIP)); sac::Ransac<sac_problems::absolute_pose::AbsolutePoseSacProblem> ransac; ransac.sac_model_ = absposeproblem_ptr; ransac.threshold_ = 1.0 - cos(atan(sqrt(2.0)*0.5/800.0)); ransac.max_iterations_ = maxIterations; ransac.computeModel(); ransac.model_coefficients_;` followed by optional `absolute_pose::optimize_nonlinear(adapter)` LM refinement on the inlier set with `adapter.sett(initial_translation); adapter.setR(initial_rotation);`. **Disqualifier-probe query (3/3) — FOUR FINDINGS (1 negative-but-mitigable structural + 3 caveats)**: (i) **CRITICAL contract finding — OpenGV uses bearing vectors (3D unit vectors) as input, NOT 2D pixel coordinates** (Source #85 explicit "OpenGV assumes to be in the calibrated case, and landmark measurements are always given in form of bearing vectors in a camera frame"); the project must implement a `CentralAbsoluteAdapter` constructor or pre-compute unit-vector conversion from C3's pixel correspondences via inverse camera-intrinsic projection — additional engineering vs OpenCV's direct pixel input contract; this is an API-level structural difference, not a fundamental algorithmic limitation; (ii) **CRITICAL covariance finding — `optimize_nonlinear` does NOT directly emit a 6×6 pose covariance** (Source #85 documentation does not document a covariance output API; D-C4-2 covariance-recovery-strategy applies identically to OpenGV — Plan-phase mitigation strategies (a) post-hoc Jacobian-based via custom Jacobian propagation through `optimize_nonlinear` residuals OR (b) wrap OpenGV result in GTSAM `Marginals` posterior OR (c) heuristic scaling = AC-NEW-4 REJECT family); (iii) **CRITICAL threshold-structure finding — RANSAC threshold is a 3D angle (radians) between bearing vectors, NOT a 2D pixel reprojection error** (Source #85 §"Ransac threshold" canonical conversion `ransac.threshold_ = 1.0 - cos(atan(sqrt(2.0)*0.5/800.0))` for focal length 800 px and reprojection-error-equivalent 0.5*sqrt(2.0) pixels); project must convert from pixel-reprojection-error budget at runtime; (iv) **CRITICAL maintenance staleness — Doxygen portal generated 2018-01-08 + last commit 2023-06-07 = ~8.3 years documentation staleness + ~3 years code staleness** at access time 2026-05-08; D-C4-4 NEW Plan-phase mitigation strategy required; (v) **License-clearance contingency** — License.txt is BSD-3-Clause-equivalent but GitHub SPDX detector reports NOASSERTION; D-C4-3 NEW Plan-phase license-clearance verification gate required for dual-use deployment compliance
+- **Target Audience**: System architects + C4 implementer + Step-7.5 reviewer + license-posture decision-maker (D-C1-1 + D-C4-3 NEW) + Plan-phase architect (richer-minimal-solver-coverage role documentation for engine Component Option Breadth rule compliance + bearing-vector adapter engineering work + 3D-angle threshold conversion engineering work + D-C4-4 NEW maintenance-staleness mitigation gate)
+- **Research Boundary Match**: Documents the OpenGV library's complete absolute-pose API surface (4 minimal solvers + 2 non-minimal solvers + 1 LM optimizer + 1 RANSAC integration + 4 algorithm-selectable RANSAC enum values) at the structural detail required for Plan-phase decision-making; runnable examples for both central + non-central + relative + multi-camera cases. **N/A for the project's domain caveat** — same as Source #84
+- **Summary**: Canonical Doxygen documentation portal for OpenGV's adapter-pattern interface and method signatures. Documents richer minimal-solver coverage than OpenCV (UPnP for both minimal+non-minimal, GP3P for generalized cameras, 2 P3P variants [Kneip + Gao] vs OpenCV's 1 [AP3P Ke & Roumeliotis 2017]). **CRITICAL contract differences vs OpenCV**: (i) bearing-vector input (3D unit vectors) instead of 2D pixels — adapter required; (ii) 3D-angle RANSAC threshold instead of pixel reprojection — conversion required; (iii) `optimize_nonlinear` LM refinement does not emit covariance — D-C4-2 still applies. **Documentation staleness**: page generated 2018-01-08 by Doxygen 1.8.11 (8.3 years old). **Maintenance staleness**: master branch last pushed 2023-06-07 (~3 years stale). **Recommended pinned mode**: `CentralAbsoluteAdapter` + `AbsolutePoseSacProblem::KNEIP` (Kneip's P3P inside RANSAC) + `optimize_nonlinear` LM refinement — Kneip's P3P is the canonical OpenGV-distinctive minimal solver and is the closest structural analog to OpenCV's `flags=SOLVEPNP_AP3P` (both are P3P variants but Kneip's is the original 2011 method while AP3P is Ke & Roumeliotis 2017 algebraic alternate); for project's planar-scene D-C4-1 = 4-DoF flat-earth lift case, OpenGV does NOT have a dedicated planar-scene minimal solver equivalent to OpenCV's `flags=SOLVEPNP_IPPE` — project would need to use Kneip's P3P or EPNP without the planar-scene specialization advantage. For project's 6-DoF DSM-lift case, OpenGV's UPnP is the modern globally-optimal alternate (analogous structural role to OpenCV's `flags=SOLVEPNP_SQPNP`)
+- **Related Sub-question**: SQ3+SQ4 / C4 — OpenGV per-mode API capability verification (cross-source verification with Source #84 GitHub API + License.txt; runnable example documented; structural caveats documented including bearing-vector contract + 3D-angle threshold + LM-no-covariance findings); **D-C4-2 NEW gate APPLIES IDENTICALLY**; **D-C4-3 NEW gate raised** (license-clearance contingency); **D-C4-4 NEW gate raised** (maintenance-staleness mitigation)
+
+
+### Source #86
+- **Title**: GTSAM canonical implementation — `borglab/gtsam` (Georgia Tech Smoothing and Mapping library; C++ classes for smoothing and mapping in robotics and vision using factor graphs and Bayes networks) GitHub repository metadata via GitHub API + LICENSE + LICENSE.BSD — **BSD-3-Clause** (LICENSE.BSD file contains 3 numbered redistribution conditions including non-endorsement clause; **GitHub API license SPDX detector reports `license.spdx_id: "NOASSERTION"`** because the wrapper LICENSE file at the repo root references `LICENSE.BSD` indirectly + bundles third-party license declarations rather than directly containing OSI canonical BSD-3-Clause boilerplate text; verified BSD-3-Clause via direct WebFetch of `https://raw.githubusercontent.com/borglab/gtsam/develop/LICENSE.BSD`); 3424 stars + 927 forks + 60 subscribers + 140 open issues; created 2017-03-27; **last pushed 2026-05-08T13:00:22Z = TODAY at access time** (daily-active maintenance — fresher than OpenCV); default branch `develop`; size 109374 KB; topics include `estimation, perception, robotics, sensorfusion`; canonical website https://gtsam.org and Doxygen portal https://borglab.github.io/gtsam/. **Bundled third-party libraries** (per LICENSE wrapper file): CCOLAMD 2.9.6 (BSD-3, gtsam/3rdparty/CCOLAMD), Ceres auto-diff/jet code only (BSD-3, modified, gtsam/3rdparty), Eigen 3.3.7 (MPL2 file-level copyleft, gtsam/3rdparty/Eigen), METIS 5.1.0 (Apache-2.0, gtsam/3rdparty/metis), Spectra v0.9.0 (MPL2, externally referenced) — **all clean for project's dual-use deployment** (MPL2 is file-level copyleft only, doesn't propagate to project product code; Apache-2.0 + BSD-3 are permissive)
+- **Link**: GitHub API metadata https://api.github.com/repos/borglab/gtsam (accessed 2026-05-08); canonical repo https://github.com/borglab/gtsam ; LICENSE wrapper https://raw.githubusercontent.com/borglab/gtsam/develop/LICENSE (top-level documents bundled-library licensing); LICENSE.BSD https://raw.githubusercontent.com/borglab/gtsam/develop/LICENSE.BSD (BSD-3-Clause canonical boilerplate "Copyright (c) 2010, Georgia Tech Research Corporation, Atlanta, Georgia 30332-0415, All Rights Reserved" with three numbered redistribution conditions); canonical website https://gtsam.org ; Doxygen portal https://borglab.github.io/gtsam/
+- **Tier**: L1 (project-official codebase by Georgia Tech Research Corporation Borg Lab; canonical reference factor-graph SLAM library used by every modern multi-frame state-estimation deployment as the de-facto industry-standard factor-graph foundation; cited by every C-row component's deployment guide; canonical `LevenbergMarquardtOptimizer` + `Marginals` posterior is the **industry-standard reference for covariance-honest pose estimation**)
+- **Publication Date**: original GTSAM C++ library 2010 (Frank Dellaert + Borg Lab Georgia Tech) → open-source release 2010-12 → migration to GitHub 2017-03-27 → version 4.3a1 indexed in context7 at access time (next-major-release rolling-development branch `develop`); access date 2026-05-08; daily commits to `develop` branch
+- **Timeliness Status**: ✅ Within Established-baseline-reference window (2010+ — established competitive ground for factor-graph SLAM + covariance-honest pose estimation; Established-competitive-mandatory-baseline exemption applies — `LevenbergMarquardtOptimizer` + `Marginals` is the **canonical covariance-honest factor-graph reference** for the C4 row's modern-competitive-lead role and **directly addresses AC-NEW-4 covariance-honesty contract** without D-C4-2 mitigation work)
+- **Version Info**: 4.3a1 at access time (default branch `develop` = next-major-release rolling-development branch; current stable release 4.2 from 2024). **`LevenbergMarquardtOptimizer` + `Marginals` posterior covariance recovery API surface** — see Source #87 below for full documentation and runnable examples
+- **Target Audience**: System architects + C4 implementer + Step-7.5 reviewer + license-posture decision-maker (D-C1-1 — BSD-3-Clause; bundled deps clean) + C5 (state estimator) implementer (GTSAM iSAM2 + factor-graph fusion is the canonical incremental-multi-frame-fusion pathway that scales naturally from C4 single-frame PnP to C5 multi-frame state estimation) + Plan-phase architect (D-C4-2 option (b) Plan-phase pathway candidate)
+- **Research Boundary Match**: **Full match** for the project's pinned C4 mode (per-frame pose-from-correspondences contract on Jetson Orin Nano Super) AT THE COVARIANCE-HONESTY AXIS — GTSAM is the **only C4 candidate evaluated to date that emits 6×6 pose covariance NATIVELY via `Marginals(graph, result).marginalCovariance(pose_key)`** without custom Jacobian engineering. **Architectural extension match**: GTSAM's factor-graph paradigm extends naturally from C4 single-frame PnP to C5 multi-frame state estimation via iSAM2 + `BetweenFactor<Pose3>` + `PriorFactorPose3` — would simplify C5 implementation if both C4 and C5 are GTSAM-based. **N/A for the project's domain caveat** — GTSAM is a classical factor-graph library with no training data; D-C2-1 retrain decision is irrelevant for GTSAM
+- **Summary**: GTSAM is the canonical industry-standard factor-graph SLAM library by Georgia Tech Borg Lab (Frank Dellaert et al.); the `gtsam::slam` module ships `GenericProjectionFactor<Pose3, Point3, CALIBRATION>` as the canonical per-correspondence projection factor for PnP-class problems. **CRITICAL POSITIVE LICENSE FINDING**: BSD-3-Clause via LICENSE.BSD (`Copyright (c) 2010, Georgia Tech Research Corporation`) — permissive, BSD/permissive license track on the C4 modern-competitive-lead axis; **deployment-ready under every D-C1-1 license-posture choice** with the cleanest license-compliance story tied with cvg/LightGlue + DISK + XFeat + OpenCV; bundled dependencies are clean (BSD-3/Apache-2.0/MPL2 file-level — all dual-use compatible). **Daily-active maintenance**: last pushed 2026-05-08 (TODAY at access time) — among the most actively-maintained C-row references; **fresher than OpenCV's last-pushed 2026-05-08T07:00:03Z by 6 hours at access time**. **CRITICAL POSITIVE COVARIANCE FINDING**: `Marginals(graph, result).marginalCovariance(pose_key)` emits a **direct 6×6 pose covariance** with no custom engineering — **the only C4 candidate evaluated to date that satisfies AC-NEW-4 covariance-honesty contract NATIVELY without D-C4-2 mitigation work**; this is the canonical Plan-phase pathway for D-C4-2 = (b) wrap-OpenCV-result-in-GTSAM-Marginals OR full-GTSAM-as-primary
+- **Related Sub-question**: SQ3+SQ4 / C4 — GTSAM per-mode API capability verification (Mandatory `context7` lookup INDEXED at `/borglab/gtsam` with **1121 code snippets at version 4.3a1** — best context7 indexing of any C4 candidate evaluated; full per-mode API documentation accessible via `query-docs` tool); **D-C1-1 license-posture compliance**: BSD-3-Clause with clean bundled deps; **D-C4-2 NATIVELY SATISFIED** via `Marginals` posterior covariance recovery — GTSAM is the canonical Plan-phase pathway for D-C4-2 = (b) wrap-OpenCV-result-in-GTSAM-Marginals OR full-GTSAM-as-primary; **NO new D-C4-N gates raised** by GTSAM closure (D-C4-1 carry-forward applies identically, D-C4-2 natively satisfied)
+
+
+### Source #87
+- **Title**: GTSAM canonical Python documentation via context7-indexed library `/borglab/gtsam` at version 4.3a1 (1121 code snippets) — `python/gtsam/examples/CameraResectioning.ipynb` (canonical PnP example with `LevenbergMarquardtOptimizer`) + `gtsam/slam/doc/ProjectionFactor.ipynb` (`GenericProjectionFactorCal3_S2` API documentation) + `python/gtsam/examples/Pose2SLAMExample.ipynb` + `python/gtsam/examples/PlanarSLAMExample.ipynb` (`Marginals.marginalCovariance` posterior covariance recovery) + `gtsam/inference/doc/FactorGraph.ipynb` (`NonlinearFactorGraph` API documentation)
+- **Link**: context7 library ID `/borglab/gtsam` at version 4.3a1; canonical docs portal https://borglab.github.io/gtsam/ ; canonical Python examples directory https://github.com/borglab/gtsam/tree/develop/python/gtsam/examples (accessed 2026-05-08 via context7 query-docs MCP integration); CameraResectioning canonical example https://github.com/borglab/gtsam/blob/develop/python/gtsam/examples/CameraResectioning.ipynb ; ProjectionFactor canonical documentation https://github.com/borglab/gtsam/blob/develop/gtsam/slam/doc/ProjectionFactor.ipynb
+- **Tier**: L1 (canonical project-official documentation via context7-indexed library; the canonical reference for GTSAM's `GenericProjectionFactorCal3_S2`, `LevenbergMarquardtOptimizer`, `Marginals.marginalCovariance`, `NonlinearFactorGraph`, `Cal3_S2` calibration, `Pose3` 6-DoF pose, and `noiseModel.Diagonal.Sigmas` API surface)
+- **Publication Date**: rolling Jupyter notebook documentation auto-updated on every push to `develop` branch; access date 2026-05-08; canonical PnP example `CameraResectioning.ipynb` has been part of the GTSAM Python distribution since version 4.0 (~2019); access via context7 query at version 4.3a1
+- **Timeliness Status**: ✅ Within Established-baseline-reference window (rolling Jupyter notebook documentation; the canonical reference for GTSAM's PnP + covariance API surface at the project's evaluation time)
+- **Version Info**: 4.3a1 at access time (default branch `develop`). **Mode-enumeration query (1/3) — context7 INDEXED PASS**: `context7 resolve-library-id` returned `/borglab/gtsam` at version 4.3a1 with 1121 code snippets + High source reputation. **Pinned-mode runnable example query (2/3) — context7 query-docs PASS**: canonical PnP runnable Python example from `CameraResectioning.ipynb`: `calibration = Cal3_S2(1, 1, 0, 50, 50)` → `graph = NonlinearFactorGraph()` → per-correspondence factor add via `graph.add(resectioning_factor(measurement_noise, X(1), calibration, Point2(image_pixel), Point3(world_landmark)))` for each 2D-3D correspondence → `initial = Values(); initial.insert(X(1), Pose3(Rot3(...), Point3(...)))` → `result = LevenbergMarquardtOptimizer(graph, initial).optimize()`. **`GenericProjectionFactorCal3_S2` canonical API**: `GenericProjectionFactorCal3_S2(measured_pt2: Point2, pixel_noise: gtsam.noiseModel, pose_key: Symbol, landmark_key: Symbol, calibration: Cal3_S2, body_P_sensor: Pose3=identity)` — per-correspondence projection factor with optional sensor-body offset for IMU-camera extrinsic. **CRITICAL POSITIVE 6×6 covariance recovery API**: `marginals = gtsam.Marginals(graph, result); pose_covariance = marginals.marginalCovariance(pose_key)` — direct 6×6 posterior covariance with NO custom Jacobian engineering required; this is the **DIRECT AC-NEW-4 covariance-honesty contract satisfaction pathway** that no other C4 candidate evaluated to date provides natively. **Disqualifier-probe query (3/3) — TWO FINDINGS (1 negative-but-mitigable structural + 1 caveat)**: (i) **CRITICAL contract finding — GTSAM has NO native RANSAC algorithm** — canonical pattern is to run RANSAC externally (e.g., via OpenCV `cv::solvePnPRansac` for the inlier mask) THEN build the factor graph from inliers only with `GenericProjectionFactorCal3_S2`; alternative is in-graph robust outlier rejection via `gtsam.noiseModel.Robust.Create(gtsam.noiseModel.mEstimator.Huber.Create(1.0), gaussian_noise)` (Huber/Tukey/Cauchy M-estimator robust kernels) OR `GncOptimizer` (Graduated Non-Convexity, Yang et al. RAL 2020) for globally-convergent RANSAC alternative; this couples C4 = GTSAM-as-primary with C5 = OpenCV-RANSAC-as-inlier-detector OR full-GTSAM-with-robust-noise-model OR full-GTSAM-with-GncOptimizer; (ii) **Memory + binary-size CAVEAT — GTSAM library footprint is ~50-200 MB at runtime depending on factor-graph size and bundled-dependency build configuration** (vs OpenCV's ~10-50 MB calib3d module); on Jetson Orin Nano Super 8 GB shared memory budget, GTSAM is the **heaviest C4 candidate evaluated to date** but still well within AC-4.2 budget when co-resident with C1/C2/C3/C5/C6
+- **Target Audience**: System architects + C4 implementer + Step-7.5 reviewer + Plan-phase architect (modern-competitive-lead role documentation for engine Component Option Breadth rule compliance + D-C4-2 NATIVELY SATISFIED + D-C5-N forward-looking carry-forward for state estimator factor-graph extension)
+- **Research Boundary Match**: **Full match** for the C4 row's pinned mode AT THE COVARIANCE-HONESTY AXIS (GTSAM `Marginals.marginalCovariance` is the only C4 candidate evaluated to date that emits 6×6 pose covariance natively; canonical PnP runnable example provided via `CameraResectioning.ipynb`; complete API surface for `LevenbergMarquardtOptimizer` + `GenericProjectionFactorCal3_S2` + `Cal3_S2` + `Pose3` + `noiseModel.Diagonal.Sigmas` documented in canonical Python notebooks); **Architectural-extension match**: GTSAM's factor-graph paradigm extends naturally from C4 single-frame PnP to C5 multi-frame state estimation via iSAM2 + `BetweenFactor<Pose3>` — would simplify C5 implementation if both C4 and C5 are GTSAM-based
+- **Summary**: The canonical GTSAM Python documentation (via context7 at version 4.3a1 with 1121 code snippets) is the definitive reference for `GenericProjectionFactorCal3_S2`, `LevenbergMarquardtOptimizer`, `Marginals.marginalCovariance`, and `NonlinearFactorGraph` API surface. **CRITICAL POSITIVE FINDING for the C4 row**: `Marginals(graph, result).marginalCovariance(pose_key)` emits a **direct 6×6 pose covariance NATIVELY** with no custom Jacobian engineering — **the only C4 candidate evaluated to date that satisfies AC-NEW-4 covariance-honesty contract without D-C4-2 mitigation work**. **NO native RANSAC** — canonical pattern is external RANSAC (via OpenCV solvePnPRansac for inliers) then GTSAM factor-graph from inliers, OR in-graph robust noise model (`gtsam.noiseModel.Robust.Create` + Huber/Tukey/Cauchy), OR `GncOptimizer` (Yang et al. RAL 2020 Graduated Non-Convexity). **Heavier library footprint** than OpenCV (~50-200 MB at runtime) but still well within AC-4.2 8 GB shared memory budget. **Architectural extension to C5**: factor-graph paradigm scales naturally to multi-frame state estimation via iSAM2 + `BetweenFactor<Pose3>` + `PriorFactorPose3` — would simplify C5 implementation
+- **Related Sub-question**: SQ3+SQ4 / C4 — GTSAM per-mode API capability verification (cross-source verification of canonical Python examples + ProjectionFactor API + Marginals posterior + LevenbergMarquardtOptimizer + NonlinearFactorGraph); **D-C4-2 NATIVELY SATISFIED** via `Marginals.marginalCovariance` — GTSAM is the canonical Plan-phase pathway for D-C4-2 = (b); cross-cite to Fact #20 + #21 closures from C2 row (canonical PnP+RANSAC+LM reference pipeline shape feeds AC-NEW-4 covariance-honesty contract); forward-cite to C5 row (factor-graph paradigm extension to multi-frame state estimation via iSAM2)
@@ -0,0 +1,95 @@
+# Source Registry — C5: State estimator / sensor fusion
+
+> Mode A Phase 2 — engine Step 2 (Source Tiering & Exhaustive Web Investigation). Sources for C5 (state estimator / sensor fusion) candidates.
+>
+> Index: [`00_summary.md`](00_summary.md). Sibling categories: [SQ6](SQ6_external_positioning.md), [SQ1](SQ1_existing_systems.md), [SQ2](SQ2_canonical_pipeline.md), [C1](C1_vio.md), [C2](C2_vpr.md), [C3](C3_matchers.md), [C4](C4_pose_estimation.md). Backing fact cards: [`../02_fact_cards/C5_state_estimator.md`](../02_fact_cards/C5_state_estimator.md). Component fit matrix row: [`../06_component_fit_matrix/C5_state_estimator.md`](../06_component_fit_matrix/C5_state_estimator.md).
+
+---
+
+## Source #88 — Solà 2017 "Quaternion kinematics for the error-state Kalman filter" (canonical aerial/quaternion ESKF tutorial)
+
+**Title**: "Quaternion kinematics for the error-state Kalman filter"
+**Author**: Joan Solà
+**Venue**: arXiv preprint cs.RO 1711.02508 (HAL hal-01122406; Semantic Scholar 12412090e46d1b21eecc59d1326edb8e47e9640e)
+**Submitted**: 2017-11-03 (revision v5 hosted on HAL); originally drafted earlier and continually revised since 2014
+**URL**: <https://arxiv.org/abs/1711.02508> (canonical) + <https://hal.science/hal-01122406v5> (HAL mirror)
+**Tier**: L1 (canonical authoritative tutorial; 592 citations per Semantic Scholar; the de-facto industry reference for ESKF + quaternion algebra in robotics + aerospace + UAV applications since 2017; open-access public-domain academic preprint)
+**Length**: 73 sections including 9 main parts (§1 quaternion definition + §2 rotations + §3 conventions + §4 perturbations/derivatives/integrals + §5 error-state kinematics for IMU-driven systems + §6 fusing IMU with complementary sensory data + §7 ESKF using global angular errors + §8 high-order integration variants + §9 references + §10 appendix)
+**Date Accessed**: 2026-05-08
+
+**Why it matters for C5**:
+- §5.1 lists the THREE structural advantages of ESKF over standard EKF that drive its dominance for UAV applications: (i) minimal orientation error-state (no over-parametrization, no covariance singularity), (ii) error-state always near origin (linearization always valid), (iii) error-state always small (Jacobians fast and often constant).
+- §5.4 provides discrete-time error-state Jacobians directly usable for project's IMU integration.
+- §6 (sub-divided into §6.1 measurement update + §6.2 injection + §6.3 covariance reset) is the canonical recipe for fusing IMU with complementary sensors (project's case = C1 VIO + C4 satellite anchors + FC IMU).
+- §6 explicitly states (line 2013 of the paper text): "At the arrival of other kind of information than IMU, such as GPS or vision, we proceed to correct the ESKF. ... These vision + IMU setups are very interesting for use in **GPS-denied environments**, and can be implemented on mobile devices ... but also on **UAVs and other small, agile platforms**." — a direct project-relevant endorsement from the canonical tutorial.
+- §1675-1677 of the paper text frames the project's exact problem statement: "Integrating IMU readings leads to dead-reckoning positioning systems, which drift with time. Avoiding drift is a matter of fusing this information with absolute position readings such as GPS or vision."
+- §6.3 explicitly notes that the canonical reset Jacobian G can be approximated as `G = I_18` in most implementations, "but the expression here provided should produce more precise results, which might be of interest for reducing long-term error drift in odometry systems" — relevant for project's 8-hour fixed-wing flights where long-term drift is a binding concern.
+- §7 provides an alternate formulation using global angular errors (vs §5's local angular errors); both are valid; project must pick one and stick with it.
+
+---
+
+## Source #89 — Reference open-source ESKF implementations (canonical-paper-derived)
+
+**Repositories examined**:
+
+| # | Repo | Language | License | Sensors fused | Project relevance |
+|---|---|---|---|---|---|
+| 89.a | `ludvigls/ESKF` | Python | (LICENSE not declared in front-page README — Plan-phase verification gate **D-C5-1 NEW** required if adoption) | IMU + GNSS for fixed-wing UAVs | **DIRECTLY MATCHES project hardware family (fixed-wing UAV + IMU + GNSS-replacement)** — closest documentary template; tested on simulated + real datasets per author description |
+| 89.b | `cggos/imu_x_fusion` | C++/ROS | (Plan-phase verification gate **D-C5-1 NEW** required if adoption) | IMU + GNSS + 6DoF-Odom (loosely-coupled) — also IEKF, UKF (UKF/SPKF, JUKF, SVD-UKF), MAP variants | **MATCHES project pattern** — multi-source loosely-coupled fusion (IMU + GNSS-as-satellite_anchor + Odom-as-VIO) |
+| 89.c | `EliaTarasov/ESKF` | C++/ROS | (Plan-phase verification gate **D-C5-1 NEW** required if adoption) | GPS + Magnetometer + Vision Pose + Optical Flow + Range Finder fused with IMU (ROS Error-State Kalman Filter based on PX4/ecl) | **CLOSE MATCH but PX4-derived** — license-clear if PX4/ecl BSD-3-Clause, but verify that the derived code is BSD-3-Clause (PX4 is dual BSD/Apache, ecl is BSD-3-Clause) |
+| 89.d | `koledickarlo/ESKF-ESP32` | C++ | (LICENSE not declared in front-page README — Plan-phase verification gate **D-C5-1 NEW** required if adoption) | Accelerometer + Gyroscope + Optical Flow + Time-of-Flight (microcontroller-class, ESP32) | NOT MATCH — microcontroller-class targets (ESP32) not Jetson; useful only as small-state ESKF reference (Solà 2017 paper explicit citation) |
+| 89.e | `joansola/slamtb` | MATLAB | (LICENSE not declared in front-page README) | EKF-SLAM (full visual-inertial SLAM toolbox) | Author Joan Solà's own SLAM Toolbox in MATLAB — the most authoritative reference for the canonical paper but MATLAB-only, NOT deployable on JetPack 6 |
+
+**Interpretation**: For Fact #88, project does NOT directly reuse any of the above repositories at the source-code level (license verification gates D-C5-1 NEW + cross-domain adaptation costs). Instead, the project implements ESKF following Solà 2017 §5+§6 equations directly in Python (NumPy/SciPy) or C++17 (Eigen3), using ludvigls/ESKF (89.a) as the closest documentary reference template for fixed-wing UAV ESKF structure. The reference implementations serve as evidence that Solà 2017 ESKF is implementable + deployable on UAV-class platforms with multi-sensor fusion patterns identical to the project's pinned configuration.
+
+**URLs accessed (full canonical README pages)**:
+- <https://github.com/ludvigls/ESKF>
+- <https://github.com/cggos/imu_x_fusion>
+- <https://github.com/EliaTarasov/ESKF>
+- <https://github.com/koledickarlo/ESKF-ESP32>
+- <https://github.com/joansola/slamtb>
+
+**Tier**: L1 (canonical project repositories; multiple independent reproductions of Solà 2017 paper across Python, C++/ROS, MATLAB, and microcontroller-class) + L2 (reference template only; project does NOT directly reuse).
+**Date Accessed**: 2026-05-08
+
+---
+
+## Source #90 — GTSAM `ImuFactor` / `CombinedImuFactor` / `PreintegratedImuMeasurements` / `PreintegratedCombinedMeasurements` (context7 query-docs at `/borglab/gtsam` — IMU pre-integration sub-API)
+
+**Title**: GTSAM canonical `ImuFactor` and `CombinedImuFactor` API reference + canonical Python runnable examples
+**Source**: context7 query-docs at `/borglab/gtsam` version 4.3a1 with 1121 code snippets (cross-cite to Source #87 from C4 Fact #54 — same library, different sub-API surface; queried 2026-05-08 for IMU + state-estimation extension to C5)
+**Returned canonical Python notebooks**:
+- `gtsam/navigation/doc/ImuFactor.ipynb` — basic `ImuFactor(X(0), V(0), X(1), V(1), B(0), pim)` 5-key factor + canonical `PreintegrationParams.MakeSharedU(9.81)` setup + `PreintegratedImuMeasurements(params, bias_hat)` + `pim.integrateMeasurement(acc_meas, gyro_meas, dt)` + `pim.predict(initial_state, current_best_bias)` + `imu_factor.evaluateError(pose_i, vel_i, pose_j, vel_j, bias_i)`
+- `gtsam/navigation/doc/CombinedImuFactor.ipynb` — modern `CombinedImuFactor(X(0), V(0), X(1), V(1), B(0), B(1), pim)` 6-key factor with bias evolution per random walk via `PreintegrationCombinedParams.MakeSharedU(9.81)` + `params.setBiasAccCovariance(np.eye(3) * bias_acc_rw_sigma**2)` + `params.setBiasOmegaCovariance(np.eye(3) * bias_gyro_rw_sigma**2)` + `params.setBiasAccOmegaInit(initial_bias_cov)` + `PreintegratedCombinedMeasurements(params, bias_hat)`
+- `gtsam/navigation/doc/PreintegratedImuMeasurements.ipynb` — full PIM workflow: `pim.integrateMeasurement(acc, gyro, dt)` × N → `pim.deltaTij()` / `pim.deltaRij().matrix()` / `pim.deltaPij()` / `pim.deltaVij()` / `pim.biasHat()` / `pim.preintMeasCov()` 9×9 covariance + `pim.predict(initial_state, current_best_bias)` for IMU-only state extrapolation
+- `gtsam/navigation/doc/GPSFactor.ipynb` — `GPSFactor(pose_key, gps_measurement_enu, gps_noise_model)` for 3-DoF GPS prior + `GPSFactorArmCalib(pose_key, lever_arm_key, gps_measurement_enu, gps_noise_model)` for GPS with unknown lever-arm calibration
+
+**Tier**: L1 (canonical context7-indexed library documentation at version 4.3a1; cross-validated against canonical Doxygen portal `borglab.github.io/gtsam/`).
+**URL**: context7 indexing of <https://github.com/borglab/gtsam/tree/develop/gtsam/navigation/doc/> (canonical Borg Lab navigation documentation; access via context7 server at queried-date 2026-05-08)
+**Cross-cite**: Source #86 (canonical `borglab/gtsam` GitHub repo + LICENSE.BSD direct WebFetch — BSD-3-Clause throughout per C4 Fact #54), Source #87 (canonical GTSAM Python examples via context7 query-docs at version 4.3a1 — `CameraResectioning.ipynb` + `Pose2SLAMExample.ipynb` + `PlanarSLAMExample.ipynb` per C4 Fact #54)
+
+**Date Accessed**: 2026-05-08 (~13:00 UTC, immediately after C4 Fact #54 closure — same daily-active GTSAM master branch state)
+
+---
+
+## Source #91 — GTSAM `ISAM2` / `IncrementalFixedLagSmoother` / `Marginals` with iSAM2 results (context7 query-docs at `/borglab/gtsam` — incremental smoothing sub-API)
+
+**Title**: GTSAM canonical `ISAM2` and `IncrementalFixedLagSmoother` incremental smoothing API + `Marginals` posterior recovery for iSAM2 results
+**Source**: context7 query-docs at `/borglab/gtsam` version 4.3a1 with 1121 code snippets (queried 2026-05-08 for incremental smoothing sub-API)
+**Returned canonical Python notebooks**:
+- `gtsam/inference/doc/ISAM.ipynb` — `GaussianISAM(initial_bayes_tree)` constructor + `isam.update(new_factors)` incremental graph modification + `isam.print()` introspection (legacy linear `GaussianISAM`; modern nonlinear `ISAM2` follows the same API pattern with additional `ISAM2Params(relinearizeThreshold, relinearizeSkip, factorization, evaluateNonlinearError, cacheLinearizedFactors, ...)` configuration)
+- `python/gtsam/examples/PlanarSLAMExample.ipynb` — `Marginals(graph, result).marginalCovariance(key)` 6×6 posterior covariance recovery (works with both batch `LevenbergMarquardtOptimizer` results and `ISAM2.calculateEstimate()` results)
+- `python/gtsam/examples/Pose2SLAMExample.ipynb` — same canonical `PriorFactorPose2(1, Pose2(0, 0, 0), PRIOR_NOISE)` initial-pose anchor pattern; reusable for Pose3 (`PriorFactorPose3(X(0), Pose3(...), prior_noise)`) for project's 3D state estimation
+- `gtsam/slam/doc/lago.ipynb` — `lago.initialize(graph)` linear-and-iterative-pose-graph initialization (good for cold-start pose initialization from FC GPS-extrapolated pose at boot per AC-NEW-1)
+- `gtsam/slam/doc/InitializePose3.ipynb` — `InitializePose3.initialize(graph)` chordal-relaxation 3D initialization (modern alternative for Pose3 cold-start)
+- `gtsam/inference/doc/FactorGraph.ipynb` — `NonlinearFactorGraph()` + `BetweenFactorPose2(X(0), X(1), Pose2(1, 0, 0), odometry_noise)` + `PriorFactorPose2(X(0), Pose2(0, 0, 0), prior_noise)` core factor-graph patterns (project applies Pose3 variants: `BetweenFactorPose3` + `PriorFactorPose3` + `GenericProjectionFactorCal3DS2`)
+
+**Note on `IncrementalFixedLagSmoother`**: context7 query-docs at /borglab/gtsam returned ISAM (legacy GaussianISAM) examples but did NOT return a top-3 `IncrementalFixedLagSmoother` snippet on the queried search. The IncrementalFixedLagSmoother class is documented in the canonical GTSAM source tree at `gtsam_unstable/nonlinear/IncrementalFixedLagSmoother.h` (not in the `develop` branch's stable area; in the `gtsam_unstable` namespace, requiring user to opt-in to unstable APIs). Project must verify at Plan-phase Jetson MVE that IncrementalFixedLagSmoother is the correct sliding-window primitive vs writing custom marginalization on top of `ISAM2.marginalizeLeaves(keys_to_marginalize)`.
+
+**Tier**: L1 (canonical context7-indexed library documentation at version 4.3a1) + L2 (IncrementalFixedLagSmoother — gtsam_unstable namespace, verification at Plan phase required).
+**URL**: context7 indexing of <https://github.com/borglab/gtsam/tree/develop/gtsam/inference/doc/> + <https://github.com/borglab/gtsam/tree/develop/python/gtsam/examples/> (canonical Borg Lab inference + examples documentation; access via context7 server at queried-date 2026-05-08)
+**Cross-cite**: Source #86 + Source #87 + Source #90 (all GTSAM library; same daily-active master branch state)
+
+**Date Accessed**: 2026-05-08
+
+---
@@ -0,0 +1,142 @@
+# Source Registry — C6: Tile cache + spatial index
+
+> Mode A Phase 2 — engine Step 2 (Source Tiering & Exhaustive Web Investigation). Sources backing the C6 component candidates ([`../06_component_fit_matrix/C6_tile_cache_spatial_index.md`](../06_component_fit_matrix/C6_tile_cache_spatial_index.md)) and C6 fact cards ([`../02_fact_cards/C6_tile_cache_spatial_index.md`](../02_fact_cards/C6_tile_cache_spatial_index.md)).
+>
+> Index: [`00_summary.md`](00_summary.md). Sibling component sources: [C1 VIO](C1_vio.md), [C2 VPR](C2_vpr.md), [C3 Matchers](C3_matchers.md), [C4 Pose](C4_pose_estimation.md), [C5 State estimator](C5_state_estimator.md). Sub-question sources: [SQ6 external positioning](SQ6_external_positioning.md), [SQ1 existing systems](SQ1_existing_systems.md), [SQ2 canonical pipeline](SQ2_canonical_pipeline.md).
+
+---
+
+## Scope summary
+
+C6 candidates evaluated documentary level: **Cand 1 (mandatory simple-baseline)** mirrors the parent-suite `satellite-provider` pattern (PostgreSQL + pure btree composite on slippy-map `(tile_zoom, tile_x, tile_y, version)` + filesystem tile storage at `./tiles/{zoom}/{x}/{y}.jpg`); **Cand 2 (modern-competitive-lead-spatial-extension)** = PostGIS GiST on `geography(POINT,4326)` for geographic side + pgvector HNSW for descriptor ANN side + same filesystem tile storage. Both candidates share the same Postgres-as-runtime-DB substrate per user-pinned scope (Postgres on Jetson at runtime, c6_postgres_locus = A). The user explicitly stated the satellite-provider pattern is NOT carved in stone — Cand 2 may cascade changes back to the satellite-provider IF research reveals a MATERIAL improvement (small improvements stay with Cand 1).
+
+---
+
+## Sources
+
+### Source #92 — Parent-suite `satellite-provider` existing pattern (verified directly via filesystem read at /Users/obezdienie001/dev/azaion/suite/satellite-provider/)
+
+**Title**: `azaion/suite/satellite-provider` .NET 8.0 microservice (PostgreSQL + Dapper + filesystem tile storage)
+**Tier**: L1 — primary code in the same multi-repo project workspace
+**URL**: file:///Users/obezdienie001/dev/azaion/suite/satellite-provider/
+**Access date**: 2026-05-08
+**Direct verification**:
+- README at `satellite-provider/README.md` — confirms PostgreSQL backend, .NET 8.0 microservice, Dapper-based DataAccess layer, filesystem tile storage at `./tiles/{zoomLevel}/{x}/{y}.jpg`, NO PostGIS extension declared.
+- Migration `001_CreateTilesTable.sql` — `tiles` table with `(id UUID PK, zoom_level INT, latitude DOUBLE PRECISION, longitude DOUBLE PRECISION, tile_size_meters DOUBLE PRECISION, tile_size_pixels INT, image_type VARCHAR(10), maps_version VARCHAR(50), file_path VARCHAR(500), created_at, updated_at)`.
+- Migration `003_CreateIndexes.sql` — `CREATE INDEX idx_tiles_composite ON tiles(latitude, longitude, tile_size_meters)` + `CREATE INDEX idx_tiles_zoom ON tiles(zoom_level)` + `CREATE INDEX idx_regions_status ON regions(status)`. **Pure btree composite indexes; NO GiST, NO PostGIS, NO spatial extension.**
+- Migration `011_AddTileCoordinates.sql` — RENAME `zoom_level` → `tile_zoom`; ADD `tile_x INT NOT NULL` + `tile_y INT NOT NULL` derived via slippy-map Web Mercator math (`tile_x = FLOOR((longitude + 180.0) / 360.0 * POWER(2, tile_zoom))::INT` + `tile_y = FLOOR((1.0 - LN(TAN(RADIANS(latitude)) + 1.0 / COS(RADIANS(latitude))) / PI()) / 2.0 * POWER(2, tile_zoom))::INT`); CREATE UNIQUE INDEX `idx_tiles_unique_location ON tiles(latitude, longitude, tile_zoom, tile_size_meters, version)` + `CREATE INDEX idx_tiles_coordinates ON tiles(tile_zoom, tile_x, tile_y, version)`. **Confirms: existing pattern uses btree on slippy-map (zoom, x, y) integer-coordinate columns for spatial-grid range queries.**
+
+**Key facts extracted**:
+- DB engine: PostgreSQL (vanilla, no extensions).
+- Spatial index strategy: pure btree composite on slippy-map integer coordinates `(tile_zoom, tile_x, tile_y, version)` for spatial-grid range queries; secondary btree on lat/lon for inverse-geocode lookups.
+- Tile bytes: filesystem at canonical slippy-map path `./tiles/{zoom}/{x}/{y}.jpg`.
+- DB ↔ filesystem coupling: `file_path VARCHAR(500)` pointer in DB.
+- Migration mechanism: numbered SQL files as `EmbeddedResource`, run automatically on startup via `DatabaseMigrator.cs`.
+- App layer: .NET 8.0 + Dapper + raw SQL repos.
+
+**Implication**: For the on-Jetson C6 (which is Python/C++, not .NET), the equivalent stack is `psycopg[binary]` or `asyncpg` Python driver + raw SQL queries against the same schema pattern.
+
+---
+
+### Source #93 — PostgreSQL official documentation: btree multi-column index ordering and range query optimization
+
+**Title**: PostgreSQL 16 documentation — "Multicolumn Indexes" + "Indexes and ORDER BY" + "EXPLAIN" + "btree access method"
+**Tier**: L1 — official authoritative docs
+**URL**: <https://www.postgresql.org/docs/current/indexes-multicolumn.html> + <https://www.postgresql.org/docs/current/btree.html>
+**Access date**: 2026-05-08
+**Direct verification**: pending WebFetch
+**Key facts to extract**:
+- Btree multicolumn index supports range queries on the leading prefix (i.e., `WHERE tile_zoom = ? AND tile_x BETWEEN ? AND ?` uses the index optimally).
+- Btree composite index access time: O(log N) where N = total rows.
+- Storage overhead: typically ~50-100 bytes per index entry depending on column types.
+
+**Use**: backs Fact #92 sub-matrix entries on AC-4.1 (latency) and AC-4.2 (memory) for Cand 1.
+
+---
+
+### Source #94 — PostGIS official documentation: GiST spatial index on geography type + KNN distance ordering
+
+**Title**: PostGIS 3.4 documentation — "GiST Indexes" + "geography Type" + "PostGIS Special Functions Index" + "ST_DWithin" + "<-> KNN operator"
+**Tier**: L1 — official authoritative docs (OGC SFS-compliant canonical extension)
+**URL**: <https://postgis.net/docs/using_postgis_dbmanagement.html#idx-spgist> + <https://postgis.net/docs/geography.html> + <https://postgis.net/workshops/postgis-intro/knn.html>
+**Access date**: 2026-05-08
+**Direct verification**: pending WebFetch
+**Key facts to extract**:
+- GiST index access time on `geography(POINT,4326)`: O(log N) for bounding-box pre-filter; full geographic distance check is exact (not approximate).
+- KNN ordering via `ORDER BY position <-> ST_MakePoint(?, ?)::geography LIMIT K` is index-optimized in PostGIS 2.0+.
+- `ST_DWithin(position::geography, ST_MakePoint(?, ?)::geography, radius_m)` supports radius queries with native great-circle distance.
+- PostGIS extension installed footprint: typically ~30-50 MB shared libraries + ~10-20 MB SRID/projection metadata catalog.
+
+**Use**: backs Fact #93 sub-matrix entries on AC-4.1 (latency) and AC-4.2 (memory) for Cand 2 + comparative-improvement-vs-Cand-1 analysis.
+
+---
+
+### Source #95 — pgvector official documentation: HNSW index for vector similarity search
+
+**Title**: pgvector — "Open-source vector similarity search for Postgres" (`pgvector/pgvector`)
+**Tier**: L1 — canonical implementation by Andrew Kane
+**URL**: <https://github.com/pgvector/pgvector> + context7 indexed via `/pgvector/pgvector`
+**Access date**: 2026-05-08
+**Direct verification**: pending context7 + WebFetch
+**Key facts to extract**:
+- HNSW index API: `CREATE INDEX ON items USING hnsw (embedding vector_l2_ops)` + `CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops)` + `CREATE INDEX ON items USING hnsw (embedding vector_ip_ops)`.
+- Default tunable parameters: `m=16` (max connections per layer) + `ef_construction=64` (build-time candidate list size); query-time `ef_search` (default 40).
+- Vector dimension limits: pgvector 0.7+ supports up to 16,000 dimensions for HNSW; 2,000 dimensions for IVFFlat.
+- Memory footprint: extension itself ~5-10 MB shared library; per-vector storage = 4 bytes × dimensions (so 2048-D = 8 KB/vec, 1024-D = 4 KB/vec, 512-D = 2 KB/vec, 256-D = 1 KB/vec).
+
+**Use**: backs Fact #93 sub-matrix on descriptor ANN side for Cand 2 + comparative cache footprint analysis.
+
+---
+
+### Source #96 — FAISS official documentation: in-memory ANN library + Python bindings
+
+**Title**: FAISS — "A library for efficient similarity search and clustering of dense vectors" (`facebookresearch/faiss`)
+**Tier**: L1 — canonical implementation by Meta AI Research
+**URL**: <https://github.com/facebookresearch/faiss> + <https://faiss.ai/>
+**Access date**: 2026-05-08
+**Direct verification**: pending WebFetch + context7
+**Key facts to extract**:
+- Index types relevant to C6 descriptor ANN: `IndexFlatL2` (brute-force, exact), `IndexHNSWFlat` (HNSW graph, approximate), `IndexIVFFlat` (Inverted File, approximate w/ training).
+- Memory: in-memory only at query time; loaded from disk via `faiss.read_index(path)` at startup.
+- License: MIT.
+- Python API: `faiss.IndexFlatL2(d)` / `faiss.IndexHNSWFlat(d, m)` / `index.add(xb)` / `D, I = index.search(xq, k)`.
+
+**Use**: backs Fact #92 sub-matrix on descriptor ANN side for Cand 1 (app-side FAISS in-memory loaded at takeoff from Postgres bytea blobs).
+
+---
+
+### Source #97 — Postgres on NVIDIA Jetson Orin Nano memory footprint and JetPack 6 deployment
+
+**Title**: PostgreSQL on ARM64 / Ubuntu 22.04 (JetPack 6 base) — official packaging + Docker images
+**Tier**: L1 — official Postgres ARM64 packages + Docker `postgres:16-alpine` image documentation
+**URL**: <https://hub.docker.com/_/postgres> + <https://www.postgresql.org/download/linux/ubuntu/>
+**Access date**: 2026-05-08
+**Direct verification**: pending WebFetch
+**Key facts to extract**:
+- ARM64 packages available for Postgres 16 on Ubuntu 22.04 (JetPack 6 base).
+- Default `shared_buffers=128MB` + `work_mem=4MB` resident footprint ~80-150 MB on idle; ~200-400 MB under modest load.
+- Docker `postgres:16-alpine` image size: ~250 MB compressed.
+- PostGIS Docker image `postgis/postgis:16-3.4-alpine` adds ~50-80 MB to base postgres image.
+
+**Use**: backs both Fact #92 + Fact #93 sub-matrix entries on AC-4.2 (8 GB shared memory budget) for the Postgres-on-Jetson deployment.
+
+---
+
+### Source #98 — Slippy Map Tilenames specification (OpenStreetMap canonical reference)
+
+**Title**: Slippy Map Tilenames — XYZ tile coordinate system + Web Mercator projection
+**Tier**: L1 — canonical convention documented by OpenStreetMap Foundation
+**URL**: <https://wiki.openstreetmap.org/wiki/Slippy_map_tilenames>
+**Access date**: 2026-05-08
+**Direct verification**: pending WebFetch
+**Key facts to extract**:
+- Tile X/Y math: `xtile = floor((lon + 180) / 360 * 2^zoom)` + `ytile = floor((1 - asinh(tan(lat * π/180)) / π) / 2 * 2^zoom)` — matches satellite-provider migration 011 exactly.
+- Tile coverage: at zoom Z, world divided into 2^Z × 2^Z tiles; each tile covers `360/2^Z` longitude × variable-latitude.
+- Project zoom: ZoomLevel 18 (per satellite-provider README default) covers ~38m × 38m at equator (cited as "tileSizeMeters: 38.2" in README sample response).
+- Cache budget per AC-8.3 (10 GB): at typical JPEG ~30 KB/tile, fits ~330,000 tiles = roughly an area of 50 km × 50 km × 9 zoom levels OR a single mission corridor at zoom 18 of ~1000 km × 12 m.
+
+**Use**: backs both Fact #92 + Fact #93 sub-matrix entries on AC-8.3 (10 GB cache budget) + AC-3.x (mission corridor coverage).
+
+---
+
+(Subsequent sources #99+ added during fact extraction below as candidate-specific evidence is gathered.)
@@ -0,0 +1,190 @@
+# Source Registry — C7: On-Jetson inference runtime
+
+> Mode A Phase 2 — engine Step 2 (Source Tiering & Exhaustive Web Investigation). Sources backing the C7 cross-cutting integration row ([`../06_component_fit_matrix/C7_inference_runtime.md`](../06_component_fit_matrix/C7_inference_runtime.md)) and C7 fact cards ([`../02_fact_cards/C7_inference_runtime.md`](../02_fact_cards/C7_inference_runtime.md)).
+>
+> Index: [`00_summary.md`](00_summary.md). Sibling component sources: [C1 VIO](C1_vio.md), [C2 VPR](C2_vpr.md), [C3 Matchers](C3_matchers.md), [C4 Pose](C4_pose_estimation.md), [C5 State estimator](C5_state_estimator.md), [C6 Tile cache](C6_tile_cache_spatial_index.md). Sub-question sources: [SQ6 external positioning](SQ6_external_positioning.md), [SQ1 existing systems](SQ1_existing_systems.md), [SQ2 canonical pipeline](SQ2_canonical_pipeline.md).
+
+---
+
+## Scope summary
+
+C7 is a **cross-cutting integration row** rather than a per-component candidate row: it pins how the C1 VIO learned-frontend (if any), C2 VPR backbone, and C3 matcher actually run on the Jetson Orin Nano Super under JetPack 6 — TensorRT vs ONNX Runtime+TRT EP vs pure PyTorch FP16. Per the user-pinned scope (locked via `/autodev` AskQuestion 2026-05-08 — see `_docs/_autodev_state.md` `c7_breadth=B`, `c7_quantization=A`, `c7_overkill_options=A`), three documentary candidate rows are evaluated: **TensorRT native primary** + **ONNX Runtime + TensorRT EP interop alternate** + **pure PyTorch FP16 mandatory simple-baseline**. INT8 primary + FP16 fallback per candidate; INT8-only candidates Experimental until calibration data exists. Triton / DeepStream / CUDA-Python custom kernels noted-and-rejected in one sentence (server/video-pipeline class or out-of-budget for embedded 8 h mission). Cand-row candidates inherit and propagate Plan-phase gates already opened by C2 (D-C2-5 DINOv2 ViT-export to TensorRT FP16/INT8) and C3 (D-C3-2 LightGlue inference runtime path).
+
+---
+
+## Sources
+
+### Source #99 — NVIDIA TensorRT 10.x official documentation portal (context7-indexed)
+
+**Title**: NVIDIA TensorRT — SDK for optimizing and accelerating deep learning inference on NVIDIA GPUs (mixed precision, dynamic shapes, transformer optimizations)
+**Tier**: L1 — official authoritative SDK documentation (NVIDIA primary)
+**URL**: <https://docs.nvidia.com/deeplearning/tensorrt/latest/> + context7 indexed at `/websites/nvidia_deeplearning_tensorrt`
+**Access date**: 2026-05-08
+**Direct verification**: ✅ context7 query "INT8 calibration EntropyCalibrator2 ICudaEngine deserialize Jetson Orin Nano FP16 mixed precision deployment workflow Python builder" returned 9371 code snippets at Source Reputation High + Benchmark Score 75.25.
+
+**Key APIs verified**:
+- **INT8 calibrator hierarchy**: `nvinfer1::IInt8Calibrator` (abstract base) + `nvinfer1::IInt8EntropyCalibrator` (deprecated) + `nvinfer1::IInt8EntropyCalibrator2` (current canonical) + `nvinfer1::IInt8MinMaxCalibrator`. Each defines `getBatchSize()` + `getBatch(void* bindings[], const char* names[], int32_t nbBindings)` + `readCalibrationCache(size_t& length)` + `writeCalibrationCache(const void* ptr, size_t length)` + `getAlgorithm()` returning `kENTROPY_CALIBRATION_2` for the canonical path.
+- **Python builder INT8 enable pattern** (canonical TensorRT 10.x):
+  ```python
+  config.set_flag(trt.BuilderFlag.INT8)
+  config.int8_calibrator = Int8_calibrator
+  Int8_calibrator = EntropyCalibrator(["input_node_name"], batchstream)
+  ```
+- **Mixed-precision flag pattern**: `config.set_flag(trt.BuilderFlag.FP16)` + `config.set_flag(trt.BuilderFlag.INT8)` for combined FP16+INT8 mixed precision (TensorRT auto-selects per-layer precision based on calibration data).
+
+**Use**: backs Fact #94 (TensorRT native primary candidate) per-mode API verification block + Plan-phase D-C7-1 calibration-dataset-strategy + D-C7-2 mixed-precision flag matrix.
+
+---
+
+### Source #100 — Microsoft ONNX Runtime official documentation (context7-indexed) + Jetson AI Lab community wheel index
+
+**Title**: Microsoft ONNX Runtime — cross-platform ML inference and training accelerator with TensorRT execution provider; Jetson-specific install path via Jetson AI Lab community PyPI index
+**Tier**: L1 — official authoritative SDK documentation (Microsoft primary) + L2 community-maintained Jetson wheel index
+**URL**: <https://onnxruntime.ai/> + context7 indexed at `/microsoft/onnxruntime` (v1.25.0) + <https://pypi.jetson-ai-lab.io/jp6/cu126/> + <https://github.com/dusty-nv/jetson-containers/issues/1283> + <https://github.com/microsoft/onnxruntime/issues/20503> + <https://github.com/microsoft/onnxruntime/issues/27562>
+**Access date**: 2026-05-08
+**Direct verification**: ✅ context7 query "TensorRT execution provider TrtFp16Enable TrtInt8Enable TrtCachePath onnxruntime-gpu Jetson ARM64 inference session options" returned 1462 code snippets at Source Reputation High + Benchmark Score 82.23 (highest of the 3 C7 candidate context7 lookups).
+
+**Key APIs verified**:
+- **Provider enumeration + config pattern** (canonical Python API):
+  ```python
+  import onnxruntime as ort
+  print(ort.get_available_providers())
+  tensorrt_options = {'device_id': 0, 'trt_max_workspace_size': 2147483648, 'trt_fp16_enable': True}
+  cuda_options = {'device_id': 0, 'arena_extend_strategy': 'kNextPowerOfTwo', 'gpu_mem_limit': 2 * 1024 * 1024 * 1024}
+  session_trt = ort.InferenceSession(
+      "model.onnx",
+      providers=[('TensorrtExecutionProvider', tensorrt_options), ('CUDAExecutionProvider', cuda_options), 'CPUExecutionProvider']
+  )
+  ```
+- **Provider-cascade behavior**: ORT TRT EP attempts to optimize each subgraph via TensorRT; falls back to CUDA EP for unsupported ops; falls back to CPU EP if neither GPU EP applies. Subgraph fallback is automatic and per-op transparent.
+
+**Jetson install constraints (CRITICAL)**:
+- **Standard `pip install onnxruntime-gpu` does NOT work on Jetson Tegra** — Microsoft does not publish prebuilt aarch64 wheels with CUDA/TensorRT EPs (per Issue #20503: "NVIDIA does not have CI infrastructure to publish them").
+- **Canonical install path (JetPack 6 + CUDA 12.6 + Ubuntu 22.04)**: `pip3 install onnxruntime-gpu --index-url https://pypi.jetson-ai-lab.io/jp6/cu126`.
+- **Alternate index (CUDA 12.9 + Ubuntu 24.04)**: `pip3 install onnxruntime-gpu --index-url https://pypi.jetson-ai-lab.io/jp6/cu129`.
+- **Known incompatibility**: onnxruntime-gpu v1.23.0 wheels for JetPack 6 were built against `numpy<2.0.0`; importing under `numpy>=2.0.0` raises a compatibility error per Issue #27562. Pin numpy<2 in project requirements until upstream rebuild is published.
+- **Standard pip install `onnxruntime` (CPU-only) succeeds but exposes only `CPUExecutionProvider` and `AzureExecutionProvider`** — does NOT include CUDA EP or TensorRT EP.
+
+**Use**: backs Fact #95 (ONNX Runtime + TensorRT EP interop alternate candidate) per-mode API verification block + Plan-phase D-C7-3 ORT-Jetson-wheel-pin + D-C7-4 numpy-version-pin.
+
+---
+
+### Source #101 — PyTorch official documentation (context7-indexed) + Jetson AI Lab PyTorch wheel availability for JetPack 6
+
+**Title**: PyTorch — open-source machine learning framework (tensor computation with strong GPU acceleration; tape-based autograd); Jetson-specific wheels available via Jetson AI Lab + NVIDIA forums
+**Tier**: L1 — official authoritative SDK documentation (PyTorch Foundation primary) + L1 NVIDIA Developer Forums (canonical Jetson PyTorch distribution channel)
+**URL**: <https://pytorch.org/docs/stable/amp.html> + context7 indexed at `/pytorch/pytorch` (v2.5.1, v2.8.0, v2.9.1, v2.11.0) + <https://forums.developer.nvidia.com/t/installing-pytorch-for-jetpack-6-2/349519> + <https://forums.developer.nvidia.com/t/jetpack-6-2-and-pytorch-2-6-0-on-jetson-nano-orin/331972>
+**Access date**: 2026-05-08
+**Direct verification**: ✅ context7 query "torch.cuda.amp.autocast half precision FP16 inference mode no_grad CUDA Jetson Orin ARM64 model.half() torch.compile inference deployment" returned 4866 code snippets at Source Reputation High + Benchmark Score 76.69.
+
+**Key APIs verified**:
+- **`torch.amp.autocast(device_type, dtype, enabled, cache_enabled)`** — canonical AMP context manager (since PyTorch 1.10). Replaces deprecated `torch.cuda.amp.autocast`. Inference pattern:
+  ```python
+  with torch.no_grad():
+      with torch.autocast(device_type='cuda', dtype=torch.float16, enabled=True):
+          output = model(input)
+  ```
+- **`torch.compile(model, backend='inductor')`** — graph-mode optimization for further speedup; tradeoff is cold-start compile cost (~10-60 sec depending on model complexity).
+- **`model.half()`** — eager-mode FP16 weight conversion (full-precision FP16 throughout, vs autocast's per-op precision selection).
+
+**Jetson install constraints**:
+- **Standard `pip install torch` does NOT include CUDA support on Jetson** — must use NVIDIA-published or Jetson AI Lab community wheels.
+- **JetPack 6.2 + CUDA 12.6 + Ubuntu 22.04 + Python 3.10 canonical wheel**: `torch-2.9.0-cp310-cp310-linux_aarch64.whl` from Jetson AI Lab (per NVIDIA forum recommendation). Earlier stable combination: PyTorch 2.5 + torchvision 0.20.
+- **Known dependency issues**: missing `libcudss.so.0` and `libnvdla_runtime.so` on PyTorch 2.9 cu129 wheel under JetPack 6.2 (CUDA 12.6) — version mismatch between wheel build target and installed JetPack CUDA. Mitigation: prefer the cu126 variant for JetPack 6.2.
+- **CUDA capability**: Jetson Orin Nano Super GPU = compute capability **SM 87** (Ampere class).
+
+**Use**: backs Fact #96 (pure PyTorch FP16 mandatory simple-baseline candidate) per-mode API verification block + D-C7-5 PyTorch-Jetson-wheel-pin.
+
+---
+
+### Source #102 — Ultralytics YOLO26 benchmark suite on Jetson Orin Nano Super (April 2026)
+
+**Title**: Update NVIDIA Jetson Orin Nano Super benchmarks with YOLO26 (Ultralytics 8.4.33; commit 8d4e6e8 April 2026)
+**Tier**: L1 — official authoritative benchmark suite (Ultralytics is the canonical YOLO maintainer)
+**URL**: <https://github.com/ultralytics/ultralytics/pull/24097> + <https://github.com/ultralytics/ultralytics/commit/8d4e6e841c89f6598b322695cb2bc816eeba8b93>
+**Access date**: 2026-05-08
+**Direct verification**: ✅ Web search results explicitly cite the per-export-format inference times measured on Jetson Orin Nano Super.
+
+**Key data extracted (YOLO26n on Jetson Orin Nano Super, April 2026 measurement)**:
+
+| Export format | Inference time (ms) | mAP50-95 | Speedup vs FP32 | Accuracy delta vs FP16 |
+|---|---|---|---|---|
+| TensorRT FP32 | 7.53 | 0.4770 | 1.00× | — |
+| TensorRT FP16 | 4.57 | 0.4800 | 1.65× | baseline (slightly higher than FP32 due to noise) |
+| TensorRT INT8 | 3.80 | 0.4490 | 1.98× | **-6.5% mAP50-95** |
+
+**Key data extracted (YOLOv8s on Jetson Orin Nano, NVIDIA forum)**:
+- **INT8**: ~157 QPS (~6.4 ms/inference)
+- **FP16**: ~103 QPS (~9.7 ms/inference)
+- **INT8 vs FP16 speedup**: ~1.5× (vs ~1.20× on YOLO26n — model architecture and memory bandwidth dependent)
+
+**Use**: backs Fact #94 (TensorRT) latency claims for object-detection-class CNN backbones on Jetson Orin Nano Super; provides empirical anchor for the engine's "INT8 primary + FP16 fallback" precision strategy. Caveat: YOLO is a detection network; feature-matching networks (LightGlue / DISK / XFeat) are known to be more quantization-sensitive (see Source #103).
+
+---
+
+### Source #103 — LightGlue ONNX Runtime + TensorRT acceleration (canonical reference) + FP8 ModelOpt quantization findings (Fabio Sim's Journal)
+
+**Title**: Accelerating LightGlue Inference with ONNX Runtime and TensorRT (Fabio Sim's Journal, canonical author of `fabio-sim/LightGlue-ONNX`) + FP8 Quantized LightGlue in TensorRT with NVIDIA Model Optimizer (subsequent post)
+**Tier**: L1 — canonical author of the canonical LightGlue ONNX/TensorRT export pathway (already cited as Source #73 in C3 row)
+**URL**: <https://fabio-sim.github.io/blog/accelerating-lightglue-inference-onnx-runtime-tensorrt/> + <https://fabio-sim.github.io/blog/fp8-quantized-lightglue-tensorrt-nvidia-model-optimizer/> + <https://github.com/qdLMF/LightGlue-with-FlashAttentionV2-TensorRT> (community Jetson Orin NX TensorRT 8.5.2 + FlashAttentionV2 plugin reference implementation)
+**Access date**: 2026-05-08
+**Direct verification**: ✅ Web search results explicitly cite the 2-4× ONNX Runtime + TensorRT speedup over compiled PyTorch and the FP8 5.97× / 0.32× engine-size results.
+
+**Key data extracted**:
+- **LightGlue (transformer-based feature matcher) — ONNX Runtime + TensorRT inference**: 2-4× speedup over compiled PyTorch across various batch sizes and sequence lengths.
+- **FP8 quantized LightGlue (NVIDIA ModelOpt) on Hopper/Ada/Blackwell**:
+  - Engine size ~0.32× of FP32 (~68% smaller).
+  - Up to 5.97× speedup vs FP32.
+  - **Material accuracy degradation**: "match counts dropped. Sometimes they dropped hard." This is qualitatively different from YOLO-class detection networks where INT8 is well-tolerated.
+  - **FP8 hardware support**: requires Hopper / Ada / Blackwell architecture. **Jetson Orin Nano Super is Ampere (SM 87) — NOT FP8-native**. FP8 ModelOpt path applies only via INT8 emulation fallback on Ampere.
+- **Two FP8 formats**: E4M3 (4 exponent bits + 3 mantissa bits, better precision for activations) + E5M2 (5 exponent bits + 2 mantissa bits, better dynamic range for gradients).
+- **Community Jetson reference implementation**: `qdLMF/LightGlue-with-FlashAttentionV2-TensorRT` deploys on Jetson Orin NX 8 GB with TensorRT 8.5.2 + custom FlashAttentionV2 plugin.
+
+**Use**: backs Fact #94 (TensorRT) feature-matching-network INT8 caveat; backs the "INT8-only candidates Experimental until calibration data exists" engine ruling per user-pinned `c7_quantization=A` scope; raises Plan-phase gate D-C7-6 INT8-vs-FP16-per-model-family-precision-policy.
+
+---
+
+### Source #104 — JetPack SDK release notes (NVIDIA official) — JetPack 6.0 / 6.1 / 6.2 version matrix
+
+**Title**: NVIDIA JetPack 6.x SDK Release Notes — TensorRT/CUDA/cuDNN versions per release; Super Mode introduction in JetPack 6.2 (January 2025)
+**Tier**: L1 — official authoritative release notes (NVIDIA Developer)
+**URL**: <https://developer.nvidia.com/embedded/jetpack-sdk-60> + <https://developer.nvidia.com/embedded/jetpack-sdk-61> + <https://developer.nvidia.com/embedded/jetpack-sdk-62> + <https://developer.nvidia.com/blog/nvidia-jetpack-6-2-brings-super-mode-to-nvidia-jetson-orin-nano-and-jetson-orin-nx-modules/>
+**Access date**: 2026-05-08
+**Direct verification**: ✅ Web search results explicitly enumerate TensorRT / CUDA / cuDNN per JetPack release.
+
+**Key data extracted**:
+
+| JetPack | CUDA | TensorRT | cuDNN | Super Mode | Released |
+|---|---|---|---|---|---|
+| 6.0 | 12.2 | 8.6 | 8.9 | No | early 2024 |
+| 6.1 | 12.6 | 10.3 | 9.3 | MAXN mode (dev kit only) | mid-2024 |
+| **6.2** | **12.6** | **10.3** | **9.3** | **YES — Orin Nano Super + Orin NX production modules** | **2025-01-16** |
+
+- **Super Mode performance gains** (vs base Orin Nano): up to 2× higher generative AI inference performance, 70% AI TOPS increase, 50% memory bandwidth boost.
+- **TensorRT 10.3** is the canonical inference runtime version for JetPack 6.1 / 6.2 deployments. Major API upgrade from TensorRT 8.x → 10.x — `IInt8EntropyCalibrator2` API surface is preserved; `INetworkDefinition` and `IBuilderConfig` semantics unchanged.
+
+**Use**: pins the project's target software stack to **JetPack 6.2 + CUDA 12.6 + TensorRT 10.3 + cuDNN 9.3 + Super Mode enabled** for the Jetson Orin Nano Super target hardware. Backs Facts #94, #95, #96 deployability claims.
+
+---
+
+### Source #105 — TensorRT-on-Jetson canonical install constraints (Ultralytics issue reports + NVIDIA forum)
+
+**Title**: TensorRT 10.x on Jetson Orin Nano — install path, hardware-specificity, memory-pressure-during-build constraints
+**Tier**: L2 — community-reported issues with NVIDIA-acknowledged root causes (high signal-to-noise on canonical constraints)
+**URL**: <https://github.com/ultralytics/ultralytics/issues/18882> ("TensorRT does not currently build wheels for Tegra systems") + <https://forums.developer.nvidia.com/t/tensorrt-10-7-0-on-orin-nano/364236> (SM 87 compute-capability mismatch) + <https://github.com/ultralytics/ultralytics/issues/18730> (laptop-GPU-built engine cannot load on Jetson) + <https://github.com/ultralytics/ultralytics/issues/21281> (TensorRT export memory pressure on Orin AGX)
+**Access date**: 2026-05-08
+**Direct verification**: ✅ Web search returned direct issue links with NVIDIA-confirmed root causes.
+
+**Key constraints extracted** (CRITICAL for C7 deployment design):
+
+1. **TensorRT Python wheels are NOT installed via pip on Jetson Tegra**. Standard `pip install tensorrt` raises: `RuntimeError: TensorRT does not currently build wheels for Tegra systems`. The canonical install path is the JetPack-bundled TensorRT (already present after `apt install nvidia-jetpack`), accessed via the system Python at `/usr/lib/python3.10/dist-packages/tensorrt`.
+2. **TensorRT engines are hardware-specific** — engines built against a laptop / dev-machine GPU CANNOT be loaded on the Jetson at runtime. **Engines must be built directly on the Jetson target**.
+3. **GPU compute capability mismatch is silent at build-time, fatal at load-time**: laptop GPUs (e.g., RTX 4090 = SM 89) and Jetson Orin Nano Super (SM 87) produce incompatible engines; the build emits no error, the load logs `Target GPU SM 87 is not supported by this TensorRT release` — version-and-SM-compatibility matrix must be respected.
+4. **TensorRT engine builds on Jetson under memory pressure can segfault during tactic profiling** (8 GB shared CPU+GPU is tight; a rich layer-fusion search consumes peak RAM during `tactic.profile` phase). Mitigation: limit `config.max_workspace_size` to a fraction of the budget (e.g., 1-2 GB) and avoid concurrent inference / Postgres / FAISS during builds.
+5. **JetPack 6.x ships the canonical TensorRT version** (TensorRT 10.3 for JP 6.1/6.2 per Source #104); upgrading TensorRT independently of JetPack is not officially supported.
+
+**Use**: drives D-C7-7 build-on-Jetson-vs-prebuilt-engine-shipping-strategy + D-C7-8 max-workspace-size-cap-for-build-stability + D-C7-9 SM-compatibility-version-pin.
+
+---
+
+(Subsequent sources #106+ added during fact extraction below as candidate-specific evidence is gathered. Closure target: 3 candidate rows + 1 cross-cutting integration matrix.)
@@ -0,0 +1,97 @@
+# Source Registry — C8: MAVLink / MSP2 FC adapter
+
+> Mode A Phase 2 — engine Step 2 (Source Tiering & Exhaustive Web Investigation). C8 batch 1 sources for the FC adapter (per-FC adapter pattern verified at SQ6 closure: ArduPilot Plane via MAVLink `GPS_INPUT`, iNav via `MSP2_SENSOR_GPS` primary OR UBX-impersonation alternate). Confidence labels per `references/source-tiering.md`. Cross-references back to SQ6 fact card sources (#4, #9, #10, #12, #13, #15) where the iNav inbound-handler reality and MSP2/UBX transport options were originally established.
+>
+> Index: [`00_summary.md`](00_summary.md). Sibling component categories: [C1 VIO](C1_vio.md), [C2 VPR](C2_vpr.md), [C3 Matchers](C3_matchers.md), [C4 Pose](C4_pose_estimation.md), [C5 State estimator](C5_state_estimator.md), [C6 Tile cache](C6_tile_cache_spatial_index.md), [C7 Inference runtime](C7_inference_runtime.md). Cross-cuts: [SQ6 external positioning](SQ6_external_positioning.md).
+
+## Sources
+
+### Source #106 — ArduPilot Pymavlink (context7-indexed `/ardupilot/pymavlink`)
+- **Tier**: L1 (canonical Python MAVLink implementation maintained by ArduPilot)
+- **Found via**: context7 `resolve-library-id` → `/ardupilot/pymavlink` → `query-docs` for GPS_INPUT send patterns
+- **Library posture**: 32 code snippets indexed in context7 (Source Reputation: High); coverage emphasizes the JavaScript MAVLink generator output, with thinner Python-side examples in context7 — supplementary primary sources (canonical pymavlink GitHub README + ArduPilot GPS_INPUT dev docs Source #107) carry the canonical Python `master.mav.gps_input_send(...)` send pattern.
+- **License**: LGPL v3 (pymavlink itself); MAVLink generated dialects are MIT — the project's runtime dependency is on the LGPL pymavlink Python package. **Compatible with project's Apache-2.0 dual-use track**: LGPL allows linking from a non-LGPL application without "infecting" application license; the only obligation is to publish/redistribute any modifications to pymavlink itself (project does not modify pymavlink), and to allow users to relink against an updated pymavlink (trivially satisfied for an open-source / company-internal deployment with published `requirements.txt`).
+- **Critical-novelty-sensitivity**: Established baseline; no time window — pymavlink has been the canonical Python MAVLink stack since 2010+, and `GPS_INPUT` (msg 232) has been in `common.xml` since 2017 ArduPilot dev iteration.
+- **Per-mode capability verification (context7 + SQ6 Source #4 AP_GPS_MAV.cpp cross-cite)**: ✅ `GPS_INPUT` decoder confirmed in AP_GPS_MAV.cpp master per SQ6 Fact #1; Python sender uses `master = mavutil.mavlink_connection(...)` + `master.mav.gps_input_send(time_usec, gps_id, ignore_flags, time_week_ms, time_week, fix_type, lat, lon, alt, hdop, vdop, vn, ve, vd, speed_accuracy, horiz_accuracy, vert_accuracy, satellites_visible, yaw)` per pymavlink generated dialect.
+- **Used to support**: Fact #97 (ArduPilot Plane FC adapter primary candidate).
+
+### Source #107 — ArduPilot Plane Non-GPS Position Estimation + MAVProxy GPS Input module documentation
+- **Tier**: L1 (official ArduPilot dev docs portal; documented configuration + canonical injection example)
+- **Found via**: web search for `pymavlink GPS_INPUT msg 232 example ArduPilot Plane non-GPS external positioning companion computer 2025`
+- **Date accessed**: 2026-05-08
+- **URLs**:
+  - https://ardupilot.org/dev/docs/mavlink-nongps-position-estimation.html
+  - https://ardupilot.org/plane/docs/common-non-gps-navigation-landing-page.html
+  - https://ardupilot.org/mavproxy/docs/modules/GPSInput.html
+  - https://ardupilot.org/plane/docs/common-companion-computers.html
+- **Critical configuration captured**: `GPS1_TYPE = 14` (MAVLink) is required on the FC for `GPS_INPUT` ingestion. Without this parameter set, AP_GPS will not accept the message. `EK3_SRC1_POSXY = 3` (GPS) selects the GPS_INPUT-fed virtual GPS as the primary horizontal-position source. Per ArduPilot dev docs, the **preferred method** for non-GPS navigation is `ODOMETRY` or `VISION_POSITION_ESTIMATE` at ≥4 Hz — but `GPS_INPUT` remains supported and is the right choice when the project's outcome contract is "WGS84 coordinates as a real-GPS replacement" (AC-4.3 wording aligns with GPS_INPUT semantics, not ODOMETRY semantics).
+- **Cross-cite**: SQ6 Fact #1 (AP_GPS_MAV.cpp ingestion path) + SQ6 Fact #4 (`ODOMETRY`-velocity-only NOT supported) — together these pin `GPS_INPUT` as the right transport for the project's `{satellite_anchored, visual_propagated, dead_reckoned}` source-label scheme.
+- **Per-mode capability verification**: ✅ All required ACs (AC-4.3 / AC-NEW-2 / AC-NEW-4 / AC-NEW-8) map directly into GPS_INPUT field semantics per SQ6 working summary table.
+
+### Source #108 — pyubx2 (context7-indexed `/semuconsulting/pyubx2` + canonical GitHub README)
+- **Tier**: L1 (canonical Python UBX/NMEA/RTCM3 parser; benchmark score 86.8 in context7; 139 code snippets)
+- **Found via**: context7 `resolve-library-id` → `/semuconsulting/pyubx2` → `query-docs` for UBX-NAV-PVT message construction with full attribute control + serialize-to-bytes pattern for UART transmission
+- **Library posture**: BSD-3-Clause license (clean, dual-use compatible); semuconsulting publishes both the canonical GitHub repo + comprehensive readthedocs.io documentation also indexed in context7 as `/websites/semuconsulting_pyubx2` (239 additional code snippets, benchmark 85.2). The library supports `UBXMessage(ubxClass, ubxID, mode, **kwargs)` constructor with three modes: `GET (0x00)` for output from the receiver, `SET (0x01)` for command input, `POLL (0x02)` for query input. NAV-PVT belongs to the GET output set.
+- **Critical-novelty-sensitivity**: Library/SDK API behaviour — must reflect currently shipped version; semuconsulting/pyubx2 is daily-active (last released 2025).
+- **Per-mode capability verification (context7-confirmed)**: ✅ NAV-PVT message construction with all UBX-NAV-PVT fields supported as keyword arguments per `UBXMessage('NAV', 'NAV-PVT', GET, iTOW=..., year=..., lon=..., lat=..., height=..., hMSL=..., hAcc=..., vAcc=..., velN=..., velE=..., velD=..., gSpeed=..., headMot=..., sAcc=..., headAcc=..., pDOP=..., fixType=..., flags=..., numSV=..., valid=...)`. ✅ `serialize()` method returns the full UBX wire-format bytestring (sync-bytes 0xB5 0x62 + class + ID + length + payload + 8-bit Fletcher checksum). ✅ `parsebitfield=1` mode allows individual bit attributes for `flags` (e.g., `gnssFixOK`, `diffSoln`, `psmState`) and `valid` (e.g., `validDate`, `validTime`, `fullyResolved`, `validMag`) — required for the impersonation path to set the `gnssFixOK` bit that iNav's `gpsMapFixType()` validates.
+- **Used to support**: Fact #98 (iNav UBX impersonation alternate candidate).
+
+### Source #109 — u-blox NEO-M9N Integration Manual (UBX-19014286) + u-blox 8/M8 Receiver Description (UBX-13003221) — UBX-NAV-PVT canonical specification
+- **Tier**: L1 (vendor-authoritative protocol specification PDFs)
+- **Found via**: web search for `UBX-NAV-PVT frame structure spec u-blox protocol M8 M9 fix type fabricate inject iNav 2025`
+- **Date accessed**: 2026-05-08
+- **URLs**:
+  - https://content.u-blox.com/sites/default/files/NEO-M9N_Integrationmanual_UBX-19014286.pdf
+  - https://content.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_UBX-13003221.pdf
+- **Frame structure captured**: NAV-PVT (class=0x01, ID=0x07) carries 92-byte payload — `iTOW (u32 ms)` + `year (u16)` + `month/day/hour/min/sec (u8 each)` + `valid (u8 bitmask)` + `tAcc (u32 ns)` + `nano (i32 ns)` + `fixType (u8 enum: 0=NoFix, 1=DeadReck, 2=2D, 3=3D, 4=GNSS+DR, 5=TimeOnly)` + `flags (u8 bitmask incl. gnssFixOK bit 0)` + `flags2 (u8)` + `numSV (u8)` + `lon (i32 deg×1e-7)` + `lat (i32 deg×1e-7)` + `height (i32 mm above ellipsoid)` + `hMSL (i32 mm above mean sea level)` + `hAcc (u32 mm)` + `vAcc (u32 mm)` + `velN/velE/velD (i32 each mm/s)` + `gSpeed (i32 mm/s)` + `headMot (i32 deg×1e-5)` + `sAcc (u32 mm/s)` + `headAcc (u32 deg×1e-5)` + `pDOP (u16 ×0.01)` + reserved bytes + `headVeh (i32)` + `magDec (i16)` + `magAcc (u16)`. M9N supersedes M8 with refined NAV-PVT semantics; both are accepted by iNav 9.0 (per Source #11 in SQ6 — UBX ≥ 15.00 protocol version).
+- **Critical-novelty-sensitivity**: Established baseline + library/SDK API behaviour — u-blox NAV-PVT is a stable protocol surface since u-blox 8 (2014); minor field semantics evolve across vendor protocol versions, so exact wire format must be checked against the iNav-target version (iNav 9.0 expects ≥ 15.00).
+- **Per-mode capability verification**: ✅ NAV-PVT contains all fields needed for iNav's `gpsMapFixType()` validation (Source #110 cross-cite): `flags` byte bit 0 `gnssFixOK` + `fixType` enum + `numSV` + `hAcc/vAcc` for AC-NEW-4 covariance honesty.
+- **Used to support**: Fact #98 (iNav UBX impersonation alternate candidate) NAV-PVT frame fabrication spec.
+
+### Source #110 — iNav `gps_ublox.c` source (master, GitHub) — UBX validation gates that the impersonation must pass
+- **Tier**: L1 (canonical iNav firmware source, master branch, accessed via cached web fetch)
+- **Found via**: web search for `iNav GPS UBX validation fixType numSat hDOP threshold reject GNSS spoofing companion computer 2025`
+- **URL**: https://github.com/iNavFlight/inav/blob/master/src/main/io/gps_ublox.c
+- **Date accessed**: 2026-05-08
+- **Critical-novelty-sensitivity**: Library/SDK API behaviour — must reflect current shipped iNav version. iNav 9.0 master (post-2025-12-11 wiki update per SQ6 Source #10) confirmed via direct file read.
+- **Validation logic captured (line-numbered evidence)**:
+  - **Line 215-220**: `gpsMapFixType(fixValid, ubloxFixType)` returns `GPS_FIX_2D` if `fixValid && ubloxFixType == FIX_2D`, returns `GPS_FIX_3D` if `fixValid && ubloxFixType == FIX_3D`, otherwise `GPS_NO_FIX`. **THIS IS THE GATE** the impersonation must pass.
+  - **Line 654**: NAV-PVT path computes `next_fix_type = gpsMapFixType(_buffer.pvt.fix_status & NAV_STATUS_FIX_VALID, _buffer.pvt.fix_type)`. The `fix_status & NAV_STATUS_FIX_VALID` masks the lowest bit of NAV-PVT's `flags` byte (bit 0 = `gnssFixOK`).
+  - **Lines 656-683**: NAV-PVT-driven full state population including `lon (1e-7 deg)`, `lat (1e-7 deg)`, `altitude_msl (mm)`, NED velocity (mm/s converted to cm/s), `speed_2d (mm/s)`, `heading_2d (deg×1e-5 → deg×10)`, `satellites`, `horizontal_accuracy (mm)`, `vertical_accuracy (mm)`, `position_DOP`, valid date/time bits.
+  - **Lines 1024-1060**: Configuration logic — for u-blox version ≥ 15.0 (iNav 9.0+), iNav configures NAV-PVT-only via `configureMSG(MSG_CLASS_UBX, MSG_PVT, 1)`. For older receivers, configures the legacy NAV-POSLLH + NAV-SOL + NAV-VELNED + NAV-TIMEUTC quad. **Implication**: companion impersonator should advertise version ≥ 15.0 via NAV-VER (CLASS=0x0A, ID=0x04) to drive iNav into the simpler NAV-PVT-only protocol.
+- **Per-mode capability verification**: ✅ Validation gate fully decoded; impersonation viability confirmed at the firmware-source level (no opaque downstream filter discovered).
+- **Used to support**: Fact #98 — provides the iNav-firmware-side validation contract that the UBX impersonation must satisfy.
+
+### Source #111 — iNav `docs/development/msp/README.md` (master, GitHub) — MSP2_SENSOR_GPS canonical payload specification
+- **Tier**: L1 (canonical iNav protocol-reference documentation, master branch, accessed via cached web fetch)
+- **Found via**: web search for `MSP2_SENSOR_GPS Python library iNav msp2 protocol companion computer external GPS injection 2025 2026`
+- **URL**: https://github.com/iNavFlight/inav/blob/master/docs/development/msp/README.md
+- **Date accessed**: 2026-05-08
+- **Payload structure captured (line 2999-3031 of the master README)**: `MSP2_SENSOR_GPS (7939 / 0x1F03)` — request payload 36 bytes containing `instance (u8)` + `gpsWeek (u16)` + `msTOW (u32 ms)` + `fixType (u8 = gpsFixType_e)` + `satellitesInView (u8)` + `hPosAccuracy (u16 mm)` + `vPosAccuracy (u16 mm)` + `hVelAccuracy (u16 cm/s)` + `hdop (u16 ×0.01)` + `longitude (i32 deg×1e7)` + `latitude (i32 deg×1e7)` + `mslAltitude (i32 cm)` + `nedVelNorth (i32 cm/s)` + `nedVelEast (i32 cm/s)` + `nedVelDown (i32 cm/s)` + `groundCourse (u16 deg×100)` + `trueYaw (u16 deg×100, 65535 = unavailable)` + `year (u16)` + `month/day/hour/min/sec (u8 each)`. **Reply payload: None.** **Notes: Requires `USE_GPS_PROTO_MSP`. Calls `mspGPSReceiveNewData()`.**
+- **Critical-novelty-sensitivity**: Library/SDK API behaviour — verified against iNav master (post-9.0).
+- **Per-mode capability verification**: ✅ Full payload spec covers all AC-NEW-4 covariance honesty fields (`hPosAccuracy`, `vPosAccuracy`, `hVelAccuracy`); ✅ AC-NEW-8 graceful-degrade signal carried via `fixType` enum (`gpsFixType_e`) — companion can emit `GPS_NO_FIX` (0) or `GPS_FIX_2D` (1) for the "covariance >100 m" / "covariance >500 m" thresholds; ✅ AC-1.4 95% covariance proxy carried in `hPosAccuracy`.
+- **Used to support**: Fact #99 (iNav MSP2_SENSOR_GPS primary candidate).
+
+### Source #112 — Python MSP2 implementations: YAMSPy + INAV-Toolkit `inav_msp.py`
+- **Tier**: L2 (community implementations; NOT vendor-canonical but actively maintained)
+- **Found via**: web search for Python MSP2_SENSOR_GPS libraries; iNav Issue #4465 confirms YAMSPy as community-recommended; agoliveira/INAV-Toolkit confirmed via direct GitHub source read
+- **URLs**:
+  - YAMSPy mention: https://github.com/iNavFlight/inav/issues/4465
+  - INAV-Toolkit `inav_msp.py`: https://github.com/agoliveira/INAV-Toolkit/blob/5c4ef789068399b4dc7461b71c6f71c25aef5e4e/inav_msp.py
+- **Date accessed**: 2026-05-08
+- **Library posture**:
+  - **YAMSPy** (`thecognifly/YAMSPy`): MIT-licensed Python library with explicit MSP V2 support; community-blessed for iNav external-device communication per the iNav issue thread.
+  - **INAV-Toolkit `inav_msp.py`**: 951-line MIT-licensed module implementing `msp_v2_encode(cmd, payload)` + `msp_v2_decode(buffer)` with CRC-8 DVB-S2 checksumming + serial transport. Direct primary-source implementation reference for MSP V2 frame construction.
+- **Critical-novelty-sensitivity**: Library/SDK API behaviour — both libraries are recent (post-2024 commits). **Risk**: community libraries may lag the iNav protocol surface (e.g., MSP V2 sensor message range 0x1F00-0x1FFF was added later than the original MSP V2 baseline). The project may need to either (a) extend the chosen community library with MSP2_SENSOR_GPS-specific encoding helpers, or (b) implement a thin custom encoder using the canonical msp_v2_encode primitive — both paths verified feasible from primary sources.
+- **License notes**: MIT throughout — clean dual-use compatible.
+- **Per-mode capability verification**: ⚠️ MSP V2 frame envelope (0x24 + 'X' + 0x3C + flag + cmd_lo + cmd_hi + len_lo + len_hi + payload + CRC8-DVB-S2) confirmed via INAV-Toolkit primary source; ✅ MSP2_SENSOR_GPS payload structure confirmed via Source #111. Combining the two yields a complete companion-side encoder for the iNav primary path.
+- **Used to support**: Fact #99 (iNav MSP2_SENSOR_GPS primary candidate, Python implementation path).
+
+### Source #113 — iNav `src/main/msp/msp_protocol_v2_sensor.h` (master, GitHub) — MSP2 sensor command-ID range
+- **Tier**: L1 (canonical iNav firmware source, master branch)
+- **Found via**: web search co-result with Source #112; opens via the `msp_protocol_v2_sensor.h` direct link
+- **URL**: https://github.com/iNavFlight/inav/blob/master/src/main/msp/msp_protocol_v2_sensor.h
+- **Date accessed**: 2026-05-08
+- **Critical fact captured**: `MSP2_SENSOR_GPS = 0x1F03` (= 7939 decimal); MSP V2 sensor-message range `0x1F00-0x1FFF` is reserved for sensor injection plugins. iNav 9.0 master expectation: MSP2 frame must use the MSP V2 envelope (sync = 0x24 0x58 0x3C; flag = 0x00; cmd = LE 16-bit; len = LE 16-bit; CRC = CRC-8 DVB-S2 over flag through end of payload).
+- **Per-mode capability verification**: ✅ MSP2_SENSOR_GPS = 0x1F03 confirmed at source; ✅ MSP V2 envelope spec confirmed.
+- **Used to support**: Fact #99 — provides the canonical MSP V2 sensor-message-range definition.
@@ -0,0 +1,179 @@
+# Source Registry — SQ1 — Existing / competitor GPS-denied UAV navigation systems
+
+> 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 #25
+- **Title**: Twist Robotics develops OSCAR — a GPS-independent visual navigation system for drones resistant to electronic warfare equipment
+- **Link**: https://www.pravda.com.ua/eng/news/2026/01/28/8018266/
+- **Tier**: L2 (national newspaper of record reporting on a Technology Forces of Ukraine release; primary press is the Technology Forces of Ukraine FB post)
+- **Publication Date**: 2026-01-28 (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid (within 6-month critical-novelty window)
+- **Target Audience**: Ukraine-deployment practitioners; UAV companion-system designers
+- **Research Boundary Match**: **Full match** — Ukrainian fixed-wing-class UAV, GPS-denied, vision-based, deployed in active conflict
+- **Summary**: Twist Robotics (UA) deployed OSCAR ("Optical System of Coordinates with Automatic Relocalisation") — camera + landmark-matching + map → autopilot ingests as a "reliable GPS signal". Vendor claims: 20 m accuracy without cumulative error, day/night/fog operation, 500,000 km logged across 25,000 combat missions over 24 months development, AI-augmented + Obrii proprietary simulator for training. Note: hardware photo shows active cooling on the module — implies non-trivial compute (probably Jetson-class). **No public independent benchmark.** Closest deployed peer system to this project.
+- **Related Sub-question**: SQ1 (closest peer); also informs SQ8 (anti-spoofing claims), SQ9 (synthesis)
+
+
+### Source #26
+- **Title**: Ukraine Gives Drones Vision-Based Navigation to Push Past Heavy Jamming — The Defense Post
+- **Link**: https://thedefensepost.com/2026/01/29/ukraine-drones-vision-navigation/
+- **Tier**: L2 (defense-trade publication; corroborates Source #25 with a second-party byline)
+- **Publication Date**: 2026-01-29 (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Target Audience**: Defense-policy / procurement readership
+- **Research Boundary Match**: Full match
+- **Summary**: Confirms OSCAR is operational, terrain-imagery-against-mapped-landmarks pattern, autopilot-ingestion. Adds "live imagery" framing. No new technical detail beyond Source #25.
+- **Related Sub-question**: SQ1
+
+
+### Source #27
+- **Title**: Ukraine's Ruta Missile Drone Will Get an EW-Immune Navigation System — Defense Express
+- **Link**: https://en.defence-ua.com/weapon_and_tech/ukraines_ruta_missile_drone_will_get_an_ew_immune_navigation_system-14541.html
+- **Tier**: L2 (defense-trade publication, Ukraine-domestic)
+- **Publication Date**: 2025-05-17 (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid (within 18-month authority window)
+- **Target Audience**: Defense-procurement / industry analysts
+- **Research Boundary Match**: Partial — operational profile (cruise-missile-class, terminal guidance) differs from our 8-h fixed-wing surveillance/strike profile; technique class is closely related (DSMAC pattern)
+- **Summary**: Destinus Ruta (Ukrainian-Swiss origin; ~300 km strike range, miniature cruise missile) will integrate a navigation system from UAV Navigation (Spanish, Grupo Oesía). Defense Express infers DSMAC-style operating principle: "takes images of surface mid-flight, identifies location through comparison with reference". Vendor announcement notes validation in Ukrainian combat conditions including GNSS-denied / jamming / spoofing. Establishes that the cruise-missile-tier vision-nav pattern is now being miniaturised for ~300 km strike drones.
+- **Related Sub-question**: SQ1 (commercial/military landscape)
+
+
+### Source #28
+- **Title**: Kilometer-Scale GNSS-Denied UAV Navigation via Heightmap Gradients: A Winning System from the SPRIN-D Challenge
+- **Link**: https://arxiv.org/abs/2510.01348
+- **Tier**: L1 (peer-style preprint, full system description, real flight data, competition results)
+- **Publication Date**: October 2025 (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: arXiv v1 (2510.01348v1)
+- **Target Audience**: GNSS-denied UAV system designers (academic + practitioner)
+- **Research Boundary Match**: **Partial — different regime.** Multirotor (≤25 kg), <25 m AGL, LiDAR-equipped, no satellite-tile basemap; 9 km waypoint mission. Our project is fixed-wing, ~1 km AGL, no LiDAR, monocular + sat-tile basemap. **Architectural pattern transfers; specific algorithm does NOT** (heightmap gradients require LiDAR).
+- **Summary**: CTU Prague team won SPRIN-D Funke Fully Autonomous Flight Challenge with: VIO (OpenVINS) + LiDAR-derived local heightmap + gradient template matching against open-data DEM + clustered K-means particle filter, all on Intel NUC i7 16 GB CPU-only (no GPU). Achieved RMSE <11 m over kilometer-scale flights vs ≤53 m for raw odometry. Critical observations explicitly stated:
+  - **RTAB-Map and ORB-SLAM3 both fail** beyond 1 km / above 2 m/s flight (compute/memory) and ORB-SLAM3 loses tracking in textureless areas — directly applicable to our 17 m/s cruise over agricultural steppe.
+  - **"Some teams used RGB satellite image-based matching, but this has proved to be highly unreliable at such low altitudes."** This is a low-altitude (<25 m AGL) finding; our 1 km AGL operates in the high-altitude regime where the same paper notes RGB sat-matching "works reasonably well" (refs [5][6]).
+  - Lesson: "ability to recover from periods of high uncertainty and re-localize is more critical than maintaining consistently low instantaneous RMSE." Direct architectural input for AC-NEW-2 / AC-NEW-8.
+  - Lesson: IMU-from-airframe vibration isolation is mission-critical for VIO usability.
+  - Lesson: magnetometer is unreliable near steel-reinforced structures; sensor-fusion is essential for heading robustness.
+- **Related Sub-question**: SQ1 + SQ5 (failure modes for VIO/SLAM at speed) + SQ2 (canonical pipeline)
+
+
+### Source #29
+- **Title**: Hierarchical Image Matching for UAV Absolute Visual Localization via Semantic and Structural Constraints
+- **Link**: https://arxiv.org/abs/2506.09748 (PDF: https://arxiv.org/pdf/2506.09748)
+- **Tier**: L1 (peer-submitted preprint, IEEE-bound, with public CS-UAV dataset)
+- **Publication Date**: June 2025 (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid (within 6-month critical-novelty window for SOTA claims)
+- **Version Info**: arXiv v1 (2506.09748v1)
+- **Target Audience**: Academic SOTA researchers + UAV-localization implementers
+- **Research Boundary Match**: **Full match** — exact same problem (UAV absolute visual localization in GNSS-denied conditions, downward-facing camera, satellite reference)
+- **Summary**: 2025 SOTA pipeline: (1) image retrieval module (off-the-shelf, optimal-transport feature aggregation), (2) Semantic-Aware and Structure-Constrained Matching Module using **DINOv2** features + 4D correlation tensor + SoftMNN + 4D conv, (3) lightweight fine-grained module for pixel-level. Constructs UAV absolute visual-loc pipeline **without VIO/relative-loc dependence** (retrieval-and-matching only). Evaluation on AerialVL + their own CS-UAV. **Direct relevance**: this is a candidate template for our C2 (VPR) + C3 (cross-domain registration) components, but DINOv2 is a heavyweight foundation model — must be benchmarked under our 25 W / 8 GB Jetson Orin Nano envelope before selection (handed off to SQ3/SQ4 + SQ5 for that component).
+- **Related Sub-question**: SQ1 (academic SOTA), SQ3+SQ4 (C2/C3 candidates), SQ5 (Jetson-on-Foundation-Model failure mode)
+
+
+### Source #30
+- **Title**: Raptor — GPS-Denied UAV Navigation & Coordinate Extraction (Vantor product page; Guide / Sync / Ace suite)
+- **Link**: https://www.vantor.com/product/mission-solutions/raptor/
+- **Tier**: L2 (vendor product spec; primary for the product itself, not for independent benchmark numbers)
+- **Publication Date**: live (accessed 2026-05-07; references Mar 2026 + Dec 2025 + Sep 2025 partner blog posts indicating active product line)
+- **Timeliness Status**: Currently valid
+- **Target Audience**: Defense / commercial / industrial UAV integrators
+- **Research Boundary Match**: **Full match** — vision-based aerial position software using existing camera + 3D terrain data, deployable on commodity hardware
+- **Summary**: Vantor Raptor product family: **Guide** (on-drone vision-based positioning, demonstrated <7 m absolute accuracy in all dimensions, day/night/low-altitude, runs on commodity HW); **Sync** (georegisters live drone video against 3D terrain in real time, <3 m coordinate extraction); **Ace** (laptop-side coordinate extraction at <3 m). Backbone: Vantor's "100 million-plus sq km of highly accurate 3D terrain data, regularly updated" (Vivid Terrain, 3 m accuracy). Inertial Labs partnership (VINS-integrated Raptor Guide). Use cases include joint multi-domain ops, large-scale autonomous delivery, search-and-rescue. **This is the closest production-grade commercial peer to the project's architecture (sat-basemap-as-service + on-drone vision).**
+- **Related Sub-question**: SQ1 (commercial), SQ3+SQ4 (commercial alternatives to building C2/C3 ourselves), SQ8 (basemap as a service vs offline cache)
+
+
+### Source #31
+- **Title**: Auterion successfully completes Artemis program to deliver long-range deep strike drone (press release)
+- **Link**: https://auterion.com/auterion-successfully-completes-artemis-program-to-deliver-long-range-deep-strike-drone/
+- **Tier**: L1 (official vendor press release)
+- **Publication Date**: 2025-10-15 (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Target Audience**: Defense-procurement; UAV-integration architects
+- **Research Boundary Match**: **Full match** — fixed-wing-class one-way attack drone with Ukraine-validated GPS-denied navigation; the system architecture is directly comparable
+- **Summary**: Auterion Artemis (DIU project, completed Oct 2025) = Shahed-style design developed in Ukraine; up to 1,000-mile range; up to 40 kg warhead; runs on Auterion Skynode N mission computer + Auterion Visual Navigation system + built-in terminal guidance. Government evaluators signed off after operational flight tests in Ukraine including ground launch, GPS and GPS-denied navigation, long-range transit, and terminal engagement. **Establishes that the integration pattern (companion-class autopilot + visual navigation + terminal guidance) is shipping at production scale to a US defense customer.** Open architecture, manufacturing in US/UA/DE.
+- **Related Sub-question**: SQ1
+
+
+### Source #32
+- **Title**: Bring AI and computer vision to small autonomous systems — Auterion Skynode S product page
+- **Link**: https://auterion.com/product/skynode-s
+- **Tier**: L2 (vendor product spec)
+- **Publication Date**: live (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Target Audience**: Small-UAS integrators
+- **Research Boundary Match**: Full match (companion-class autopilot with NPU)
+- **Summary**: Auterion Skynode S = compact mission computer with **dedicated Neural Processing Unit** for AI / computer-vision applications on small UAS systems. Architecturally the same niche our Jetson Orin Nano Super sits in (companion compute + autopilot integration), but with Auterion's PX4 fork pre-integrated. Hardware/runtime envelope is comparable; the product establishes that this is a product category, not a one-off integration.
+- **Related Sub-question**: SQ1, SQ7 (alternate companion HW for adjacent context)
+
+
+### Source #33
+- **Title**: snktshrma/ngps_flight — Next-Generation Positioning System for ArduPilot (GSoC 2024)
+- **Link**: https://github.com/snktshrma/ngps_flight (sibling: https://github.com/snktshrma/ap_nongps)
+- **Tier**: L1 (open-source code repository, published GSoC project under ArduPilot organisation)
+- **Publication Date**: GSoC 2024 timeframe (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: GSoC 2024 prototype (research-grade, not production firmware)
+- **Target Audience**: ArduPilot integrators building visual-positioning companion stacks
+- **Research Boundary Match**: **Full match — closest open-source peer to our exact pipeline.** ArduPilot, downward-facing camera, satellite-image reference, deep-learning matching, fused with VIO, fed back to autopilot.
+- **Summary**: NGPS = ROS 2 + ArduPilot pipeline composed of three packages: **`ap_ngps_ros2`** (visual geo-localization at 1–2 Hz by matching live camera frames to georeferenced satellite imagery using **LightGlue + SuperPoint**); **`ap_ukf`** (Unscented Kalman Filter fusing NGPS absolute positions with VIO estimates); **`ap_vips`** (VIO providing relative pose). Output is fused odometry to ArduPilot's EKF via `VISION_POSITION_ESTIMATE` (per the related issue #23471 framing). **This is the architectural template** the project should explicitly compare against — same component split as our C1+C2+C3+C5+C8 stack.
+  - Caveats: (a) GSoC prototype, not production-hardened; (b) uses `VISION_POSITION_ESTIMATE` which on AP requires EKF source set 2/3 with EK3_SRC*_POSXY=Vision; our SQ6 conclusion picked `GPS_INPUT` as primary AP path because it carries `horiz_accuracy` directly and supports source-set switching via `MAV_CMD_SET_EKF_SOURCE_SET` — must compare the trade-off in design phase; (c) no documented spoofing-defence integration; (d) no documented covariance-honesty contract.
+- **Related Sub-question**: SQ1 (closest open-source peer), SQ2 (canonical-pipeline confirmation), SQ3+SQ4 (architectural template for component selection), SQ6 (alternate AP transport: `VISION_POSITION_ESTIMATE` vs `GPS_INPUT`)
+
+
+### Source #34
+- **Title**: AerialExtreMatch — A Benchmark for Extreme-View Image Matching and Localization (project page + GitHub + Hugging Face dataset)
+- **Link**: https://xecades.github.io/AerialExtreMatch/ ; https://github.com/Xecades/AerialExtreMatch ; https://huggingface.co/datasets/Xecades/AerialExtreMatch-Localization
+- **Tier**: L1 (peer-reviewed benchmark with public dataset, code, model checkpoints; OpenReview submission)
+- **Publication Date**: 2025 (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Target Audience**: Academic + practitioner image-matching evaluators
+- **Research Boundary Match**: **Full match** for cross-source UAV-satellite image matching evaluation
+- **Summary**: 2025 benchmark with: 1.5 M synthetic train pairs (RGB+depth, diverse UAV/satellite viewpoints); ~30,000 evaluation pairs in 32 difficulty levels stratified by overlap (4 bins: <20/20-40/40-60/>60%), pitch difference (4 bins: 50–55, 55–60, 60–65, 65–70°), and scale (2 bins: 1-2×, >2×); a real-world UAV-localization split captured with DJI M300 RTK + H20T against UAV-derived orthomosaic/DSM AND lower-quality satellite maps. Evaluates 16 representative detector-based + detector-free image matching methods. **This is the academic benchmark our C2+C3 candidate selection must publish numbers against.**
+- **Related Sub-question**: SQ1 (academic landscape), SQ7 (datasets)
+
+
+### Source #35
+- **Title**: DARPA Fast Lightweight Autonomy (FLA) program page + Test-and-Evaluation review (arXiv 2504.08122)
+- **Link**: https://www.darpa.mil/research/programs/fast-lightweight-autonomy ; https://arxiv.org/abs/2504.08122
+- **Tier**: L1 (DARPA program page + 2025 academic review of program results)
+- **Publication Date**: program 2015–2018 (concluded); review 2025-04 (accessed 2026-05-07)
+- **Timeliness Status**: Foundational reference; review is current (within 18-month authority window)
+- **Target Audience**: Defense-program historians + indoor-low-altitude GPS-denied autonomy researchers
+- **Research Boundary Match**: **Partial — different regime.** FLA = small quadcopters at ≤20 m/s in cluttered indoor/outdoor with onboard sensing only, no satellite-tile basemap. Our project is fixed-wing, ~17 m/s, 1 km AGL, with sat-tile basemap.
+- **Summary**: Foundational US-defense lineage for GPS-denied autonomy (2015–2018, complete). Set the template for "small UAV + onboard sensors + onboard compute → autonomous obstacle-avoidance + navigation without datalink/GPS". Phase 1 in Florida 2017; Phase 2 in Georgia 2018. The 2025 retrospective (arXiv 2504.08122) reviews FLA's testing methodology and Phase 1 results. Companion 2025 USAF SBIR Phase II solicitation (Sweetspot ID `7946c818-409f-5b31-8f06-554466071d83`) is requesting visual-position-and-navigation capability for sUAS in GPS-denied environments — the regulatory tailwind is now active.
+- **Related Sub-question**: SQ1 (defense-program lineage)
+
+
+### Source #36
+- **Title**: DSMAC / TERCOM lineage — DTIC ADA315439 (Scene Matching Missile Guidance Technologies) + Wikipedia / SPIE references
+- **Link**: https://apps.dtic.mil/sti/tr/pdf/ADA315439.pdf ; https://en.wikipedia.org/wiki/DSMAC ; https://www.spiedigitallibrary.org/conference-proceedings-of-spie/0238/1/Terrain-Contour-Matching-TERCOM-A-Cruise-Missile-Guidance-Aid/10.1117/12.959127.short
+- **Tier**: L1 (DTIC unclassified technical report) + L2 (encyclopedia/SPIE proceedings)
+- **Publication Date**: DTIC: 1996; SPIE: 1980; Wikipedia: live
+- **Timeliness Status**: Foundational baseline (no time window per Step 0.5 — established classical algorithms)
+- **Target Audience**: Cruise-missile-class designers; analogues for downward-vision navigation
+- **Research Boundary Match**: **Partial — different regime** (cruise missile, terminal guidance). Architectural pattern (pre-cached scene reference + downward camera + correlation matching) is the direct ancestor of our C3 pipeline.
+- **Summary**: DSMAC = electro-optical camera correlated against pre-stored reference scenes (often from satellite reconnaissance), achieving 3–10 m terminal accuracy. Tomahawk: TERCOM (radar altimeter + DEM) for mid-flight; DSMAC for terminal. CEP without DSMAC: ~30 m; with DSMAC: "only meters". Gulf War 1991: >80% of 280 launched Tomahawks hit target. **Establishes that downward-vision-against-pre-stored-imagery is a 40+ year-old well-characterised technique class with documented accuracy bounds; our project's claim of <500 m / 99.9% reliability is achievable in the same technique class.**
+- **Related Sub-question**: SQ1 (lineage), SQ8 (baseline accuracy expectations)
+
+
+### Source #37
+- **Title**: Electronic Warfare in Ukraine: The Invisible Battle — Ukraine War Analytics
+- **Link**: https://ukraine-war-analytics.com/analysis/electronic-warfare-ukraine.html
+- **Tier**: L3 (analytical aggregator; primary-source numbers cite vendor / OSINT reports)
+- **Publication Date**: live (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid (operational-context reference)
+- **Target Audience**: Ukraine-deployment practitioners
+- **Research Boundary Match**: Full match (operational geography, threat environment)
+- **Summary**: Operational-context anchor: Russian EW systems including Pole-21 GPS jammers (25+ km range) plus spoofing capabilities have driven ~70% of small-tactical-UAV losses to EW across the conflict. Twist Robotics' OSCAR cites the same approximate number (~75% of small tactical UAV losses to EW at the front per Source #25). **Confirms the demand-side number is consistent across two independent reporting chains.**
+- **Related Sub-question**: SQ1 (Ukraine practitioner perspective)
+
+---
+
+## SQ2 — Canonical pipeline decomposition
@@ -0,0 +1,74 @@
+# Source Registry — SQ2 — Canonical pipeline decomposition
+
+> 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 #38
+- **Title**: Visual Place Recognition for Aerial Imagery: A Survey (Moskalenko, Kornilova, Ferrer — Skoltech)
+- **Link**: https://arxiv.org/abs/2406.00885 (v2)
+- **Tier**: L1 (peer-reviewed survey, accepted in Robotics and Autonomous Systems; companion benchmark code: https://github.com/prime-slam/aero-vloc)
+- **Publication Date**: arXiv 2024-06; v2 update through 2024
+- **Timeliness Status**: Currently valid (within 18-month authority window for established surveys; specific candidate latency numbers will need cross-validation against newer Jetson-class hardware reports)
+- **Target Audience**: Aerial-VPR practitioners + UAV navigation system architects
+- **Research Boundary Match**: **Full match** for the offline-cache visual geo-localization decomposition (aerial-nadir UAV vs. satellite tile basemap)
+- **Summary**: Authoritative two-stage pipeline definition (verbatim): "Visual geolocalization can be implemented through various methods, typically relying on a pre-built database of images with known locations. This approach generally involves two stages: **global localization (or Visual Place Recognition, VPR) and local alignment**. Global localization involves identifying the nearest frame from the database (Image Retrieval), while local alignment determines the precise position using the selected frame." Re-ranking is treated as an integral sub-stage of VPR for aerial data because of agricultural/urban grid repetition. Local alignment = SuperPoint/keypoint detector → LightGlue/SuperGlue/SelaVPR matcher → cv2.findHomography → cv2.perspectiveTransform → Web-Mercator coordinate conversion. **Practitioner-critical runtime numbers (RTX 3090, NOT Jetson)**: AnyLoc descriptor calculation = 0.37–0.84 s/frame (huge ViT-G DINOv2); MixVPR / SALAD = 0.05–0.20 s; SelaVPR = 0.04 s; SuperGlue re-rank = 15–25 s on top-100 candidates; LightGlue re-rank = ~1 s; SelaVPR re-rank = <0.1 s. Memory: AnyLoc descriptors = 2.3–13.9 GB for 4–7k tiles; SelaVPR = <0.2 GB. Final commentary: "While our methodology alone may not provide comprehensive robustness, it can be effectively augmented with additional sensors, such as inertial measurement units (IMUs). This integration enhances its utility for Visual Inertial Odometry (VIO) and Simultaneous Localization and Mapping (SLAM) systems, particularly for periodic location refinement and loop closure tasks. Additionally, our methodology could serve as a dependable emergency localization fallback in the event of an unexpected GNSS signal loss." → **Validates the project's IMU/VIO + sat-anchor architecture as the canonical extension of the survey's two-stage core.**
+- **Related Sub-question**: SQ2 (canonical decomposition), SQ3+SQ4 (C2/C3 candidate latency budgets), SQ5 (foundation-model-on-Jetson failure mode)
+
+
+### Source #39
+- **Title**: Cross-View Geo-Localization: A Survey (Durgam, Paheding, Dhiman, Devabhaktuni — U. Maine / Fairfield / ISU)
+- **Link**: https://arxiv.org/abs/2406.09722 (v1)
+- **Tier**: L1 (peer-style preprint, journal-bound — Expert Systems with Applications)
+- **Publication Date**: arXiv 2024-06
+- **Timeliness Status**: Currently valid (≤18 months for survey-of-deep-learning architectures)
+- **Target Audience**: Cross-view (ground↔aerial) geo-localization researchers; partial overlap with our aerial↔satellite pipeline
+- **Research Boundary Match**: **Partial — different cross-view setup** (the survey focuses on ground panorama → aerial overhead; ours is aerial nadir → satellite ortho). The pipeline-shape lessons transfer; the polar-transform / Siamese-network / GAN-based view-synthesis lessons do NOT directly apply because our two views are both top-down.
+- **Summary**: Confirms the canonical pipeline decomposition (feature extraction → cross-view matching → similarity-driven retrieval) is the dominant pattern across 2015–2024 SOTA. Establishes the historical lineage: pixel-wise (Sheikh 2003) → feature-based (Lin 2013) → CNN/triplet-loss (Tian 2017) → Siamese+GAN (Hu 2018) → polar-transform (Shi 2019) → CosPlace/EigenPlaces (2022–2023) → DINOv2-class (AnyLoc 2023) → Transformer-only (TransGeo 2022, MGTL 2022) → multi-method fusion (2023+). Backbone comparison table establishes that ViT/DINOv2 is the current SOTA backbone; ResNet-class is the established production baseline; SIFT/SURF/PHOW remain the handcrafted baseline. **Confirms our component-area split (C2 VPR + C3 cross-domain matching) is canonical and matches the survey's two-axis organization (backbone × matching strategy).**
+- **Related Sub-question**: SQ2 (decomposition lineage), SQ3+SQ4 (C2 candidate landscape)
+
+
+### Source #40
+- **Title**: OrthoLoC: UAV 6-DoF Localization and Calibration Using Orthographic Geodata (Dhaouadi, Marin, Meier, Kaiser, Cremers — DeepScenario / TU Munich / MCML)
+- **Link**: https://arxiv.org/abs/2509.18350 ; project page https://deepscenario.github.io/OrthoLoC
+- **Tier**: L1 (peer-style preprint with public dataset, code, model checkpoints; 16,425 UAV images Germany+US, full 6-DoF ground truth)
+- **Publication Date**: arXiv 2025-09 (within 6-month critical-novelty window)
+- **Timeliness Status**: Currently valid (within 6-month critical-novelty window for SOTA aerial-localization claims)
+- **Target Audience**: UAV-localization implementers + system architects building on Digital Orthophotos (DOP) + Digital Surface Models (DSM)
+- **Research Boundary Match**: **Full match — direct paradigm match** to our project: "lightweight orthographic representations" instead of 3D meshes; "increasingly accessible through free releases by governmental authorities"; "no internet connection or GNSS/GPS support" — exactly the project's constraint envelope.
+- **Summary**: **Most directly applicable SQ2 source.** Defines the 6-DoF localization pipeline using 2.5D geodata: (1) match query UAV image against DOP (orthophoto raster) using state-of-the-art matchers; (2) lift each 2D match in the DOP to 3D using the corresponding DSM elevation; (3) PnP+RANSAC (RANSAC-EPnP, 5-pixel inlier threshold) → initial pose; (4) Levenberg-Marquardt joint refinement of intrinsics + extrinsics; (5) **AdHoP refinement**: estimate homography from initial 2D-2D correspondences via DLT+RANSAC, warp the DOP to better match the query's perspective, re-match, map back via H⁻¹, lift to 3D, refine pose; accept refinement only if reprojection error decreases. **Quantitative results** on 16.4k images, 47 locations: best matcher = GIM+DKM achieves 75.4% recall at 1m-1° threshold (sparse SP+SG = 64.4%, sparse SP+LG = 64.2%, MASt3R = 63.5%, RoMa+AdHoP = 54.6%, XFeat*+AdHoP = 59.8%; LoFTR / eLoFTR / XoFTR all <23% recall). AdHoP yields ~30% average matching improvement, ~20% translation/rotation error reduction; for previously-underperforming methods (XFeat* → 95% matching improvement; DKM → 63% translation reduction; RoMa → 1m-1° recall +23%). **Performance factors** explicitly characterized: (a) **cross-domain DOPs (visual gap only) cause ~3× translation error increase** even on best method; (b) **cross-domain DOPs+DSMs (visual + structural gap) cause ~7× translation error increase** (0.16 m → 1.12 m for GIM+DKM+AdHoP) — **this is exactly the war-zone scene-change scenario AC-3.x covers**; (c) **20% covisibility floor** between query and reference; below it localization fails; (d) **Calibration is fundamentally ambiguous** between focal length and translation → camera intrinsics MUST be calibrated upstream, not jointly optimized in flight. (e) Resolution: scaling images to 30% of original (~300 px) still works; geodata at 13 m/pixel is the floor, with degradation below.
+- **Related Sub-question**: SQ2 (canonical pipeline + AdHoP refinement loop), SQ3+SQ4 (C3 matcher candidate ranks), SQ5 (war-zone scene-change failure mode), SQ8 (covisibility safety gate)
+
+
+### Source #41
+- **Title**: Exploring the best way for UAV visual localization under Low-altitude Multi-view Observation Condition: a Benchmark — AnyVisLoc (Ye, Teng, Chen, Li, Liu, Yu, Tan — NUDT / Macao Polytechnic)
+- **Link**: https://arxiv.org/abs/2503.10692 ; benchmark code https://github.com/UAV-AVL/Benchmark
+- **Tier**: L1 (peer-style preprint with public 18,000-image dataset across 15 Chinese cities, multi-pitch / multi-altitude / multi-scene, with both aerial-photogrammetry AND satellite reference maps)
+- **Publication Date**: arXiv 2025-03 (within 6-month critical-novelty window)
+- **Timeliness Status**: Currently valid
+- **Target Audience**: Aerial AVL practitioners; UAV-system designers facing pitch/altitude/yaw uncertainty
+- **Research Boundary Match**: **Partial — different altitude regime** (the benchmark covers 30–300 m AGL, ours is ~1 km AGL); pitch range is 20–90° (ours is mostly nadir, ~80–90°). Lessons on the **pipeline structure, retrieval-vs-matching trade-offs, sensor-prior noise tolerance, and aerial-vs-satellite reference-map gap** transfer directly.
+- **Summary**: Independently confirms the SAME pipeline as Source #40: image retrieval (rough position) → image matching (2D-2D) → DSM-lift to 3D → PnP+RANSAC. Best baseline = CAMP (retrieval) + RoMa (dense matcher) + Top-N re-rank → 74.1% A@5m on aerial photogrammetry map, 18.5% A@5m on satellite map (ALOS 30m DSM). **Critical AC-quantitative findings**: (a) **Aerial map vs satellite map**: 4× accuracy gap at A@5m (74.1% vs 18.5%) — driven by satellite-DSM coarseness (ALOS 30m vs aerial 0.94m) and modality difference. **Direct relevance**: project's offline cache is satellite tiles ≥0.5 m/px without DSM; this places us between the two data points (better than ALOS 30m, worse than aerial photogrammetry) — exact accuracy must be re-established once tile resolution is pinned. (b) **Yaw prior noise**: σ ≤ 5° → no impact; σ = 10° → 1.9% A@5m drop; σ = 30° → 4.1% drop; σ = 50° → 13.7% drop; σ = 60° → 25.7% drop. **Implication for project's C1+C5+IMU**: companion-side yaw estimate must hold σ < 10°. (c) **Pitch prior noise**: σ < 5° → no impact; σ ≥ 7° causes ~1–5% drops. (d) **Pitch angle**: smaller pitch (more oblique) → lower accuracy; nadir is best. Project's nadir-fixed camera at 1 km AGL is consistent with the benchmark's most-favourable regime. (e) **Sparse vs dense matchers**: SP+LightGlue+GIM+k2s = 75.4% A@10m at 105 ms/frame; RoMa = 81.3% A@10m at 659 ms/frame. **Implication for project's C7 Jetson runtime**: dense matchers ~6× more accurate but ~6× slower → SP+LightGlue-class is the production sweet spot under our 400 ms budget. (f) **Re-ranking strategy**: Top-N re-rank by inlier count = best accuracy/cost trade-off (62.2% A@5m at 0.8 s/frame on RTX 3090). Match-without-retrieval = catastrophic (34.3% A@5m, search-space too large).
+- **Related Sub-question**: SQ2 (pipeline + sensor-prior tolerance), SQ3+SQ4 (C2 retrieval-vs-matcher trade-offs, C5 IMU prior contract), SQ5 (war-zone reference-map staleness failure mode), SQ7 (aerial-vs-satellite reference benchmarks)
+
+
+### Source #42
+- **Title**: Survey on absolute visual localization techniques for low-altitude unmanned aerial vehicles (Ye, Chen, Teng, Li, Yang, Song, Yu — NUDT, College of Aerospace Science)
+- **Link**: https://www.sciopen.com/article/10.11887/j.issn.1001-2486.25120033 ; DOI 10.11887/j.issn.1001-2486.25120033
+- **Tier**: L1 (peer-reviewed Chinese journal — Journal of National University of Defense Technology, vol 48 issue 2, 2026; same lab as Source #41 with overlapping authorship — confirmed cross-validation, not duplicative)
+- **Publication Date**: 2026-04-01 (within 6-month critical-novelty window)
+- **Timeliness Status**: Currently valid
+- **Target Audience**: UAV-system architects + Chinese-defense-research community
+- **Research Boundary Match**: **Full match** (low-altitude UAV AVL is the survey's exact subject)
+- **Summary**: Survey-level confirmation of the canonical "**retrieval-matching-pose estimation**" hierarchical framework. Verbatim claim: "the hierarchical framework balances search efficiency, positioning accuracy, and scene generalization, becoming a robust technical path for low-altitude long-endurance absolute localization." Compares the framework against alternatives that are explicitly rejected: (a) relative visual localization (cumulative errors — VIO/SLAM only); (b) end-to-end direct localization (poor generalization); (c) map-free localization (scene-dependent). Sub-component evolution per stage: (a) retrieval = template-matching (SAD/SSD/NCC) → BoW/VLAD → deep-learning (annular/dense feature segmentation, contrastive InfoNCE, self-supervised); (b) matching = SIFT/SURF/ORB → SuperPoint+LightGlue/RoMa (sparse / semi-dense / dense); (c) pose estimation = PnP variants + RANSAC + IMU prior fusion. **Identifies four open challenges** that align with project risks: (i) cross-domain generalization (war-zone scene change); (ii) real-time inference on edge platforms (Jetson); (iii) robustness to complex environments (cropland, snow, low texture); (iv) high-quality datasets (the same gap our project's AC-NEW-7 / cache provisioning works around). **Lightweight-model-design-for-edge-deployment is named as a primary future-research direction** — directly validates project's Jetson Orin Nano constraint as a recognized field-level challenge, not a project-specific oddity.
+- **Related Sub-question**: SQ2 (framework canonicalness), SQ3+SQ4 (per-component evolution), SQ5 (named open challenges align with project risks)
+
+---
+
+## SQ3+SQ4 / C1 (Visual / Visual-Inertial Odometry) — Candidate enumeration
@@ -0,0 +1,320 @@
+# Source Registry — SQ6 — ArduPilot Plane vs iNav external positioning
+
+> 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 #1
+- **Title**: Non-GPS Navigation — Plane documentation
+- **Link**: https://ardupilot.org/plane/docs/common-non-gps-navigation-landing-page.html
+- **Tier**: L1
+- **Publication Date**: live docs (current ArduPilot stable, accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: ArduPilot 4.7+ (persistent origin storage); applies to current Plane stable
+- **Target Audience**: ArduPilot Plane operators / developers
+- **Research Boundary Match**: Full match (fixed-wing, ArduPilot Plane is in scope)
+- **Summary**: Lists supported non-GPS navigation systems for Plane. Notes that boards <1MB flash still support `GPS_INPUT` even when they cannot run other non-GPS messages. Notes that Plane (non-VTOL) is generally not applicable for low-altitude non-GPS — but `GPS_INPUT` as an external GPS replacement is not constrained by that note.
+- **Related Sub-question**: SQ6
+
+
+### Source #2
+- **Title**: GPS / Non-GPS Transitions — Plane documentation
+- **Link**: https://ardupilot.org/plane/docs/common-non-gps-to-gps.html
+- **Tier**: L1
+- **Publication Date**: live docs (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: EKF3 (default since AP 4.0+)
+- **Target Audience**: ArduPilot operators using mixed GPS / non-GPS sources
+- **Research Boundary Match**: Full match
+- **Summary**: Documents the EKF3 source-set mechanism (`EK3_SRC1..3_POSXY/VELXY/POSZ/VELZ/YAW`), three source sets, RC aux switch (option 90 "EKF Pos Source"), `MAV_CMD_SET_EKF_SOURCE_SET`, Lua-script driven switching. Explicitly named messages for non-GPS path: ExternalNav (option 6). GPS_INPUT is treated as a GPS source (set 1).
+- **Related Sub-question**: SQ6
+
+
+### Source #3
+- **Title**: EKF Source Selection and Switching — Plane documentation
+- **Link**: https://ardupilot.org/plane/docs/common-ekf-sources.html
+- **Tier**: L1
+- **Publication Date**: live docs (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: EKF3 stable
+- **Target Audience**: ArduPilot operators / developers
+- **Research Boundary Match**: Full match
+- **Summary**: Authoritative parameter reference for `EK3_SRCx_*` (POSXY/VELXY/POSZ/VELZ/YAW). Important caveat: "Ground stations or companion computers may set the source by sending a `MAV_CMD_SET_EKF_SOURCE_SET` mavlink command **but no GCSs are currently known to implement this**." Source-set switching from companion is supported by AP, not by stock GCS UI. Mentions ExternalNAV/OpticalFlow transition options via `EK3_SRC_OPTIONS` bit 1.
+- **Related Sub-question**: SQ6
+
+
+### Source #4
+- **Title**: ArduPilot AP_GPS_MAV.cpp (master)
+- **Link**: https://raw.githubusercontent.com/ArduPilot/ardupilot/master/libraries/AP_GPS/AP_GPS_MAV.cpp
+- **Tier**: L1 (source code)
+- **Publication Date**: master HEAD (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: master branch
+- **Target Audience**: ArduPilot developers, integrators of external GPS via MAVLink
+- **Research Boundary Match**: Full match
+- **Summary**: Authoritative implementation of `MAVLINK_MSG_ID_GPS_INPUT` ingestion into AP_GPS state. Decodes lat/lon/alt, hdop/vdop, velocity (vn/ve/vd), speed/horizontal/vertical accuracy, yaw. Honors `gps_id` (multi-GPS instance), `ignore_flags` bitmask (ALT, HDOP, VDOP, VEL_HORIZ, VEL_VERT, SPEED_ACCURACY, HORIZONTAL_ACCURACY, VERTICAL_ACCURACY). Requires `fix_type ≥ 3` and `time_week > 0` for jitter-corrected timestamping. Yaw uses `0` as "not provided" sentinel. Only `GPS_INPUT` is handled by this driver — `VISION_POSITION_ESTIMATE` / `ODOMETRY` go via the external-nav driver, not AP_GPS_MAV.
+- **Related Sub-question**: SQ6
+
+
+### Source #5
+- **Title**: ArduPilot PR #28750 — AP_NavEKF3: added two more EK3_OPTION bits (GPS-denied testing)
+- **Link**: https://github.com/ArduPilot/ardupilot/pull/28750
+- **Tier**: L2 (development PR, ArduPilot core team)
+- **Publication Date**: 2024 (accessed via search 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: master / pending stable branch propagation
+- **Target Audience**: ArduPilot developers
+- **Research Boundary Match**: Full match
+- **Summary**: Adds new `EK3_OPTION` bits to allow easier GPS-denied testing of EKF3, including an aux-switch / MAVLink command path to disable GPS use. Confirms ongoing 2024-2025 work on GPS-denied robustness.
+- **Related Sub-question**: SQ6
+
+
+### Source #6
+- **Title**: ArduPilot Issue #15859 — EKF3: improve source switching (GPS<->NonGPS)
+- **Link**: https://github.com/ArduPilot/ardupilot/issues/15859
+- **Tier**: L4 (issue tracker — open enhancement list)
+- **Publication Date**: ongoing (long-running issue, accessed 2026-05-07)
+- **Timeliness Status**: Currently valid (still open per dev docs reference)
+- **Target Audience**: ArduPilot developers
+- **Research Boundary Match**: Full match
+- **Summary**: Authoritative list of planned improvements for source-switching. Linked from the L1 GPS-Non-GPS Transitions page. Indicates current source switching has known rough edges acknowledged by the core team.
+- **Related Sub-question**: SQ6
+
+
+### Source #7
+- **Title**: ArduPilot Issue #27193 — EK3 Source Switching wrong frame for GUIDED commands SOLVED
+- **Link**: https://github.com/ArduPilot/ardupilot/issues/27193
+- **Tier**: L4 (issue tracker, resolved)
+- **Publication Date**: 2024 (accessed 2026-05-07)
+- **Timeliness Status**: Reference only (resolved as user-config)
+- **Target Audience**: ArduPilot operators using GPS↔Vision source switching
+- **Research Boundary Match**: Partial overlap (Copter context but the bug was in shared SET_POSITION_TARGET_GLOBAL_INT path)
+- **Summary**: Documented frame-interpretation issue when companion switches source set 1 (GPS) → set 3 (VISION_POSITION_ESTIMATES) and back. Resolved as configuration not code, but illustrates the kind of edge case to validate in SITL for AC-NEW-2 promotion.
+- **Related Sub-question**: SQ6
+
+
+### Source #8
+- **Title**: ArduPilot Issue #23485 — AP_NavEKF3: support fusing only External Nav Velocities (without position)
+- **Link**: https://github.com/ArduPilot/ardupilot/issues/23485
+- **Tier**: L4 (open enhancement)
+- **Publication Date**: ongoing (open as of accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Target Audience**: ArduPilot developers
+- **Research Boundary Match**: Full match
+- **Summary**: Confirms current limitation: ODOMETRY without position causes position-estimate timeout / failsafe. Implies the project's `visual_propagated` path (VO without satellite anchor) cannot be expressed as ODOMETRY-velocity-only on current AP — must be sent as full GPS_INPUT with widened covariance.
+- **Related Sub-question**: SQ6
+
+
+### Source #9
+- **Title**: iNavFlight/inav — telemetry/mavlink.c (master, processMAVLinkIncomingTelemetry)
+- **Link**: https://github.com/iNavFlight/inav/blob/master/src/main/telemetry/mavlink.c
+- **Tier**: L1 (source code, authoritative)
+- **Publication Date**: master HEAD (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: iNav master (post-9.0)
+- **Target Audience**: iNav developers
+- **Research Boundary Match**: Full match
+- **Summary**: Authoritative inbound MAVLink switch (lines ~1334–1390). Handles only: HEARTBEAT, PARAM_REQUEST_LIST (stub), MISSION_CLEAR_ALL, MISSION_COUNT, MISSION_ITEM, MISSION_REQUEST_LIST, MISSION_REQUEST, COMMAND_INT (only `MAV_CMD_DO_REPOSITION`), RC_CHANNELS_OVERRIDE, ADSB_VEHICLE, RADIO_STATUS. **No `GPS_INPUT`, no `VISION_POSITION_ESTIMATE`, no `ODOMETRY`, no `GLOBAL_POSITION_INT`, no `GPS_RAW_INT`** are accepted as inputs. Wiki page (Source #10) confirms.
+- **Related Sub-question**: SQ6
+
+
+### Source #10
+- **Title**: iNav Wiki — MAVLink (frogmane edited 2025-12-11)
+- **Link**: https://github.com/iNavFlight/inav/wiki/Mavlink
+- **Tier**: L1 (project wiki)
+- **Publication Date**: 2025-12-11
+- **Timeliness Status**: Currently valid
+- **Version Info**: iNav 8.0 / 9.0 era
+- **Target Audience**: iNav users / integrators
+- **Research Boundary Match**: Full match
+- **Summary**: Authoritative inbound/outbound MAVLink message lists. "Limited command support: Commands that are not implemented are ignored." Explicitly enumerates the supported incoming list (matches Source #9). Confirms iNav MAVLink is "intended primarily for simple telemetry and operation" and "not 100% compatible".
+- **Related Sub-question**: SQ6
+
+
+### Source #11
+- **Title**: iNav Wiki — GPS and Compass setup
+- **Link**: https://github.com/iNavFlight/inav/wiki/GPS-and-Compass-setup
+- **Tier**: L1
+- **Publication Date**: live wiki (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: iNav 7.0+ (UBX-only); 9.0 requires UBX protocol ≥15.00
+- **Target Audience**: iNav operators
+- **Research Boundary Match**: Full match
+- **Summary**: From iNav 7.0 NMEA was removed; only UBX is supported. Recommends u-blox M8/M9/M10 with protocol ≥15.00. Sets up the constraint for any UBX-emulation path the companion would take.
+- **Related Sub-question**: SQ6
+
+
+### Source #12
+- **Title**: iNavFlight/inav docs/development/msp/README.md (MSP message reference)
+- **Link**: https://github.com/iNavFlight/inav/blob/master/docs/development/msp/README.md
+- **Tier**: L1 (project docs)
+- **Publication Date**: live (master, accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: iNav master
+- **Target Audience**: iNav developers / integrators
+- **Research Boundary Match**: Full match
+- **Summary**: Authoritative spec for `MSP_SET_RAW_GPS (201)` and `MSP2_SENSOR_GPS (7939)`. `MSP_SET_RAW_GPS` is 14-byte, lossy (no covariance, no per-axis velocity, altitude in meters with cm internal mismatch — bug fixed in 5.0.0 per issue #8336). `MSP2_SENSOR_GPS` is the newer plugin-style message with `hPosAccuracy`/`vPosAccuracy`/`hVelAccuracy` (mm and cm/s), `hdop`, NED velocity components, `trueYaw`, GPS week + time-of-week, fix type, satellite count. Requires `USE_GPS_PROTO_MSP` build flag and routes through `mspGPSReceiveNewData()` (the GPS_PROVIDER_MSP driver path).
+- **Related Sub-question**: SQ6
+
+
+### Source #13
+- **Title**: iNavFlight/inav src/main/io/gps.c + src/main/target/common.h (master)
+- **Link**: https://github.com/iNavFlight/inav/blob/master/src/main/target/common.h
+- **Tier**: L1 (source code)
+- **Publication Date**: master (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: master
+- **Target Audience**: iNav developers
+- **Research Boundary Match**: Full match
+- **Summary**: `USE_GPS_PROTO_MSP` is enabled by default in the common target configuration; on default builds the MSP GPS provider (`GPS_PROVIDER_MSP`) is registered with `gpsRestartMSP` / `gpsHandleMSP`. Confirms the MSP2_SENSOR_GPS path is reachable on stock iNav firmware without custom builds.
+- **Related Sub-question**: SQ6
+
+
+### Source #14
+- **Title**: iNav Issue #10141 — dual GPS support
+- **Link**: https://github.com/iNavFlight/inav/issues/10141
+- **Tier**: L4 (open feature request)
+- **Publication Date**: ongoing (open as of accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Target Audience**: iNav users
+- **Research Boundary Match**: Full match
+- **Summary**: Confirms iNav does **not** support dual-GPS / primary-secondary failover. Open enhancement; no implementation in 8.0 / 9.0. Architectural implication: companion must be the sole GPS source for iNav (not a backup to a real GPS connected directly to FC).
+- **Related Sub-question**: SQ6
+
+
+### Source #15
+- **Title**: iNav docs/GPS_fix_estimation.md (master)
+- **Link**: https://github.com/iNavFlight/inav/blob/master/docs/GPS_fix_estimation.md
+- **Tier**: L1
+- **Publication Date**: live (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: iNav 8.0+
+- **Target Audience**: iNav fixed-wing operators
+- **Research Boundary Match**: Full match
+- **Summary**: iNav's internal dead-reckoning ("GPS fix estimation") for fixed-wing. Uses gyro/accel/baro/(mag/pitot). RTH-only intent. **Explicitly states: "Not a solution for GPS spoofing (GPS output is not validated in INAV)"** — iNav has no internal anti-spoofing, so anti-spoofing is fully the companion's responsibility. Two settings: `inav_allow_gps_fix_estimation` (RTH-with-no-GPS) and `inav_allow_dead_reckoning` (short-outage tolerance) — both default OFF. `failsafe_gps_fix_estimation_delay` controls mission-vs-RTH tradeoff (default 7 s).
+- **Related Sub-question**: SQ6 (dead-reckoning fallback) + SQ8 (anti-spoofing implication)
+
+
+### Source #16
+- **Title**: iNav docs/Settings.md (master)
+- **Link**: https://github.com/iNavFlight/inav/blob/master/docs/Settings.md
+- **Tier**: L1
+- **Publication Date**: master (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: iNav master
+- **Target Audience**: iNav operators
+- **Research Boundary Match**: Full match
+- **Summary**: Authoritative parameter list. Confirms `inav_allow_dead_reckoning` (line 2081, default OFF) ≠ `inav_allow_gps_fix_estimation` (line 2091, default OFF). The two settings address different scenarios. `failsafe_gps_fix_estimation_delay` (line 1041, default 7 s) governs mission-abort timing.
+- **Related Sub-question**: SQ6
+
+
+### Source #17
+- **Title**: iNav Issue #10588 — Weird behaviour in DeadReckoning mode while GPS outage is not constant
+- **Link**: https://github.com/iNavFlight/inav/issues/10588
+- **Tier**: L4 (open issue, 2025)
+- **Publication Date**: 2025
+- **Timeliness Status**: Currently valid (open)
+- **Target Audience**: iNav operators
+- **Research Boundary Match**: Full match
+- **Summary**: Documented stability bug: intermittent GPS outages cause porpoising and motor bursts in dead-reckoning. Cited recommendation: "GPS should be rejected if providing erroneous coordinates rather than no fix." Risk for AC-NEW-8 (visual blackout + spoofed GPS) on iNav: do NOT rely on iNav's dead-reckoning for the spoof-active failsafe path; companion must actively suppress its own MSP feed and accept that iNav may misbehave during the gap. Better: continue feeding companion-IMU-propagated position with growing covariance via MSP2_SENSOR_GPS so iNav never enters its dead-reckoning state.
+- **Related Sub-question**: SQ6 + AC-NEW-8 design implication
+
+
+### Source #18
+- **Title**: iNav Release 8.0.0 (highlights, Dec 2024)
+- **Link**: https://github.com/iNavFlight/inav/releases/tag/8.0.0
+- **Tier**: L1 (project release notes)
+- **Publication Date**: late 2024 / early 2025
+- **Timeliness Status**: Currently valid
+- **Version Info**: iNav 8.0
+- **Target Audience**: iNav users
+- **Research Boundary Match**: Full match
+- **Summary**: Introduces fixed-wing GPS fix estimation (dead reckoning RTH-only) — the milestone for #8347. No new external-positioning inbound MAVLink in 8.0. Confirms iNav's 2024–2025 trajectory has not added a `GPS_INPUT`-equivalent inbound interface.
+- **Related Sub-question**: SQ6
+
+
+### Source #19
+- **Title**: iNav Release 9.0.0 / 9.0.1 + 9.0.0 Release Notes wiki
+- **Link**: https://github.com/iNavFlight/inav/wiki/9.0.0-Release-Notes
+- **Tier**: L1
+- **Publication Date**: 2025-2026
+- **Timeliness Status**: Currently valid
+- **Version Info**: iNav 9.0.x
+- **Target Audience**: iNav users
+- **Research Boundary Match**: Full match
+- **Summary**: New in 9.0: pitot APA/TPA, position estimator improvements, MSP_REBOOT DFU, GCS NAV via `COMMAND_INT` `MAV_CMD_DO_REPOSITION`. **No** new external-positioning inbound MAVLink. UBX <15.00 dropped. Confirms iNav 9.x continues the same external-positioning architecture as 8.x.
+- **Related Sub-question**: SQ6
+
+
+### Source #20
+- **Title**: MAVLink common message set — GPS_RAW_INT (24)
+- **Link**: https://mavlink.io/en/messages/common.html
+- **Tier**: L1 (MAVLink spec, live)
+- **Publication Date**: live (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: MAVLink common, current
+- **Target Audience**: MAVLink integrators
+- **Research Boundary Match**: Full match
+- **Summary**: Current published `GPS_RAW_INT` extension fields: `alt_ellipsoid`, `h_acc` (mm), `v_acc` (mm), `vel_acc` (mm/s), `hdg_acc` (degE5), `yaw` (cdeg). **No spoofing/jamming/integrity bitfield is present in `GPS_RAW_INT` at the time of access**, despite PR #2110 having been merged for spoofing/integrity reporting. Spoofing/integrity may live in a separate message (`GPS_INTEGRITY` or similar — to be verified in SQ8). For now, spoof-detection signals available to companion from FC are limited at the message-shape level; FC-side textual signals (`STATUSTEXT`) and `NAMED_VALUE_INT` are the documented practical path.
+- **Related Sub-question**: SQ6 + SQ8
+
+
+### Source #21
+- **Title**: MAVLink PR #2110 — gps: add status and integrity information
+- **Link**: https://github.com/mavlink/mavlink/pull/2110
+- **Tier**: L2 (protocol PR with cross-project sign-off)
+- **Publication Date**: merged (accessed via search 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: MAVLink common
+- **Target Audience**: MAVLink integrators across PX4 / ArduPilot / QGC / Mission Planner
+- **Research Boundary Match**: Full match
+- **Summary**: Adds GNSS status / integrity reporting (jamming/spoofing/error) at the protocol level. Cross-project sign-off across PX4, ArduPilot, QGC, Mission Planner. Field-level breakdown to be cross-checked in SQ8 against the dialect XML — current `common.html` does not show those fields inside `GPS_RAW_INT` itself, suggesting they live in a sibling message (likely `GPS_INTEGRITY` or `GPS_STATUS_EXT`).
+- **Related Sub-question**: SQ6 → defer to SQ8 for the precise message name and field set ArduPilot uses to expose spoofing.
+
+
+### Source #22
+- **Title**: AirDroper — GNSS Spoofing Filter (companion device, MAVLink2 NAMED_VALUE_INT pattern)
+- **Link**: https://gps.airdroper.org/
+- **Tier**: L3 (vendor product page; design pattern reference, not protocol authority)
+- **Publication Date**: live (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Target Audience**: ArduPilot integrators considering anti-spoofing
+- **Research Boundary Match**: Reference only (vendor's specific algorithm not relevant; the integration pattern is)
+- **Summary**: Establishes a precedent that "companion-runs-spoofing-detection → publishes confidence to GCS as MAVLink2 `NAMED_VALUE_INT`, logged to dataflash" is a real-world integration pattern with ArduPilot, not novel to this project. Useful for SQ8.
+- **Related Sub-question**: SQ8 (referenced from SQ6)
+
+
+### Source #23
+- **Title**: ArduPilot PR #24135 — Add option to make EKF3 more robust to bad IMU and lagged GPS data
+- **Link**: https://github.com/ArduPilot/ardupilot/pull/24135
+- **Tier**: L2 (development PR)
+- **Publication Date**: 2023-2024 (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: master / propagated to stable
+- **Target Audience**: ArduPilot developers
+- **Research Boundary Match**: Full match
+- **Summary**: Introduces `EK3_GLITCH_RADIUS` parameter — soft outlier rejection: instead of dropping a GPS measurement that fails innovation gating, the EKF inflates innovation variance to the minimum that just passes, effectively de-weighting the measurement. Implication for AC-NEW-4 (false-position safety): the project's covariance honesty contract on `GPS_INPUT.horiz_accuracy` is the ONLY way for AP's EKF to detect and de-weight a bad estimate; under-reporting collapses this safety net.
+- **Related Sub-question**: SQ6 + AC-NEW-4 design implication
+
+
+### Source #24
+- **Title**: ArduPilot AP_NavEKF3 — VehicleStatus.cpp + AP_NavEKF3.cpp (master)
+- **Link**: https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_NavEKF3/AP_NavEKF3_VehicleStatus.cpp ; https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_NavEKF3/AP_NavEKF3.cpp
+- **Tier**: L1 (source code)
+- **Publication Date**: master HEAD (accessed 2026-05-07)
+- **Timeliness Status**: Currently valid
+- **Version Info**: master
+- **Target Audience**: ArduPilot EKF3 developers
+- **Research Boundary Match**: Full match
+- **Summary**: EKF3 quality control: (a) ground-stationary GPS drift check ≤ 3 m (gated by `_gpsCheckScaler`); (b) innovation gating per `POS_I_GATE` / `VEL_I_GATE`; (c) soft de-weighting via `EK3_GLITCH_RADIUS` (Source #23). Confirms AP's covariance-driven quality path actually exists; companion-supplied `horiz_accuracy` flows into this chain.
+- **Related Sub-question**: SQ6 (full file analysis deferred to design phase)
+
+---
+
+## SQ1 — Existing / competitor GPS-denied UAV navigation systems