azaion/gps-denied-onboard
1
0
Fork 0
mirror of https://github.com/azaion/gps-denied-onboard.git synced 2026-06-22 14:31:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update autodev skill documentation and acceptance criteria

Browse Source 
Enhanced the SKILL.md file to enforce conciseness rules for the state file, specifying acceptable content and file size limits. Updated the autodev state to reflect the transition to the planning phase, including changes to the current step and sub-step details. Revised acceptance criteria to clarify validation requirements and external dependencies, ensuring alignment with the latest research findings. Added a new overlay for Mode B revisions to track changes and decisions made during the assessment process.
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-05-09 03:10:57 +03:00
parent 846670a5c5
commit c19c76481c
21 changed files with 2354 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
_docs/00_research/01_source_registry/00_summary.md
+1
View File
@@ -26,6 +26,7 @@
| 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) |
| **Mode B addendum (2026-05-08)** — solution_draft01 assessment | [`MODEB_addendum.md`](MODEB_addendum.md) | **#122–#131** (10 sources) | New sources gathered for Mode B findings F1–F20: VINS-Mono GPL-3.0 LICENCE confirmation (#122), MegaLoc + UltraVPR + AirZoo aerial-VPR successor candidates (#123, #124, #125), CVE-2026-1579 MAVLink no-default-auth + CVE-2025-53644 OpenCV crafted-JPEG (#126, #127), ArduPilot MAVLink2 message-signing + iNav signing-gap (#128, #129), ArduPilot `MAV_CMD_SET_EKF_SOURCE_SET` no-deployed-GCS-implementer re-verification (#130), XoFTR + 2026 SAR-optical 24-matcher benchmark (#131). |
## Investigation Status
_docs/00_research/01_source_registry/MODEB_addendum.md
+37
View File
@@ -0,0 +1,37 @@
# Source Registry — Mode B Addendum (2026-05-08)
> Mode B Solution Assessment of `_docs/01_solution/solution_draft01.md`. New sources gathered for findings F1–F20; Mode A sources #1–#121 remain canonical and are not duplicated.
>
> Index: [`00_summary.md`](00_summary.md). Mode B fact cards: [`../02_fact_cards/MODEB_addendum.md`](../02_fact_cards/MODEB_addendum.md). Mode B fit-matrix revisions: [`../06_component_fit_matrix/MODEB_revisions.md`](../06_component_fit_matrix/MODEB_revisions.md). Mode B output: [`../../01_solution/solution_draft02.md`](../../01_solution/solution_draft02.md).
## New Sources
| # | Title | Tier | Binding |
|---|-------|------|---------|
| 122 | HKUST-Aerial-Robotics/VINS-Mono LICENCE file (canonical, master branch) — GNU GPL Version 3 | L1 (verified raw LICENCE on github.com) | C1 candidate-table license-correction (F11/F15). Confirms VINS-Mono is **GPL-3.0**, not BSD-permissive as draft01 claims. Cross-confirms Mode A C1 Fact #28 against Mode A draft01 deliverable. |
| 123 | MegaLoc — "One Retrieval to Place Them All" (Berton & Masone, arXiv:2502.17237; CVPR 2025 Image Matching workshop; gmberton/megaloc repo, MIT) | L1 | C2 D-C2-11 candidate (F16). torch.hub install path; MIT license; SOTA on multiple VPR datasets; combines existing methods + training techniques + datasets into a unified retrieval model. |
| 124 | UltraVPR — "Unsupervised Lightweight Rotation-Invariant Aerial VPR" (cbbhuxx/UltraVPR repo, MIT; published RAL 2025; ICRA 2026) | L1 | C2 D-C2-11 alternative (F17). MIT license; **44 Hz on Jetson Orin NX (close cousin of Orin Nano Super)** via ONNX export; rotation-invariant; specifically designed for UAV; validated on VPAir + UAV-VisLoc datasets — directly relevant to the project's pinned operating context. |
| 125 | AirZoo — "Unified Large-Scale Dataset for Grounding Aerial Geometric 3D Vision" (arXiv:2604.26567v1, 2026) | L1 | C2 evidence base for MegaLoc on aerial domain (F16). Demonstrates that fine-tuning MegaLoc on aerial data yields substantial performance gains for aerial image retrieval and cross-view matching. |
| 126 | NVD CVE-2026-1579 — MAVLink protocol Missing Authentication for Critical Function (CVSS 9.8 CRITICAL) | L1 | New cross-cutting security gate (F18). MAVLink lacks cryptographic authentication by default; an unauthenticated party with MAVLink interface access can send arbitrary commands including SERIAL_CONTROL for interactive shell. **Mitigation: enable MAVLink 2.0 message signing.** Affects ArduPilot Plane and PX4; iNav has only partial MAVLink support and does not implement message signing. |
| 127 | NVD CVE-2025-53644 — OpenCV uninitialized variable on stack reading crafted JPEG (CVSS 9.8 CRITICAL) | L1 | C4 OpenCV pin update (F19). Affects 4.10.0 / 4.11.0; **fixed in 4.12.0**. Draft01 says "OpenCV 4.x" — must pin **≥4.12.0**. Triggers heap-buffer-write via crafted JPEG file load — relevant if any image format reaching OpenCV originates from uncertain provenance (e.g., tile cache import, FDR thumbnail re-load). |
| 128 | ArduPilot MAVLink2 Signing — Plane documentation (`ardupilot.org/plane/docs/common-MAVLink2-signing.html`) + Issue #28736 channel-specific signing PR #29546 (March 2025) | L1 | F18 mitigation evidence. Confirms ArduPilot supports MAVLink2 signing via Mission Planner SETUP > Advanced > "Mavlink Signing" menu; non-USB serial ports can be configured to only respond to MAVLink commands carrying the correct passkey; PR #29546 adds bitmask parameter to enable/disable signing per channel for wired companion-computer connections. |
| 129 | iNav MAVLink Wiki (`iNavFlight/inav/wiki/Mavlink`) | L1 | F18 cross-FC asymmetry (verified 2026-05-08 via web search). iNav has partial MAVLink support and **does NOT implement MAVLink message signing**. Companion-FC inbound on iNav is MSP2 (not MAVLink) so signing-gap is on the outbound MAVLink telemetry side, not the inbound external-positioning path — but cross-FC asymmetry is still material for AC-NEW-7 and the GCS link. |
| 130 | ArduPilot common-ekf-sources.rst + PR #18345 (`MAV_CMD_SET_EKF_SOURCE_SET`) — explicit "no GCSs are currently known to implement this" (verified 2026-05-08) | L1 | F8 D-C8-2 evidence (cross-confirms Mode A SQ6 Fact #3). Re-verifies on 2026-05-08 web search that ArduPilot supports the command at firmware level (since August 2021) but **no production-deployed GCS or companion is documented as implementing the companion-driven switch pattern** the project plans to use. Pattern is therefore **novel for a deployed production system** — confirms Mode A characterization but elevates to risk-graded selection. |
| 131 | XoFTR — "Cross-modal Feature Matching Transformer" (arXiv:2404.09692) + 2026 SAR-optical satellite registration benchmark (arXiv:2604.10217) | L2 | F20 contrarian-evidence reference. Cross-modal matcher; achieved lowest mean error (3.0 px) on SpaceNet9 SAR-optical training scenes among 24 pretrained matcher families benchmarked. **Important contrarian finding: matchers without explicit cross-modal training sometimes performed comparably**, suggesting foundation-model features (like DINOv2) provide modality invariance — reinforces SelaVPR (DINOv2-L) over MixVPR (CNN-only) on the BSD/permissive C2 axis when cross-domain UAV→satellite registration is the binding stress test. |
---
## Verification audit-trail (mandatory per `00_question_decomposition.md` Step 0.5 cross-validation rule)
| Source | Independent corroboration |
|---|---|
| #122 (VINS-Mono GPL-3.0) | Cross-confirms Mode A C1 Fact #28 (`02_fact_cards/C1_vio.md`) which already classified VINS-Mono as GPL-3.0; the discrepancy was inside the deliverable layer (`solution_draft01.md` C1 candidate table), not the evidence layer. Both Mode A C1 Fact #28 and Source #122 agree. |
| #123 (MegaLoc) | arXiv preprint + CVPR 2025 workshop + GitHub repo + Hugging Face — three-independent-source confirmation per Critical-novelty cross-validation rule. |
| #124 (UltraVPR) | RAL 2025 IEEE journal publication + ICRA 2026 + GitHub repo with pre-trained ONNX weights — three independent sources. |
| #125 (AirZoo) | arXiv preprint April 2026 — single source; treated as ⚠️ Medium confidence pending second cross-validation. |
| #126 (CVE-2026-1579) | NVD official entry + CISA ICS Advisory ICSA-26-090-02 + PX4 GHSA-fh32-qxj9-x32f — three-source confirmation; Critical CVSS. |
| #127 (CVE-2025-53644) | NVD official entry; OpenCV release notes confirming 4.12.0 fix — two-source confirmation. |
| #128 (ArduPilot MAVLink2 signing) | Official Plane documentation + Issue #28736 + PR #29546 — three-source confirmation. |
| #129 (iNav no signing) | iNav wiki (frogmane edited 2025-12-11) — single authoritative source per project convention; iNav wiki is the canonical iNav reference per Mode A SQ6 source #10. |
| #130 (companion-driven EKF source switch) | ArduPilot official ekf-sources doc + PR #18345 + cross-confirms SQ6 Mode A Source #3 already-documented "no GCSs known to implement". Three-source confirmation. |
| #131 (XoFTR cross-modal) | arXiv preprint + 2026 SAR-optical benchmark study (arXiv:2604.10217) — two-source confirmation. |
_docs/00_research/02_fact_cards/00_summary.md
+1
View File
@@ -23,6 +23,7 @@ This folder replaces the previous monolithic `02_fact_cards.md` (1480 lines, too
| [`C6_tile_cache_spatial_index.md`](C6_tile_cache_spatial_index.md) | **C6** — Tile cache + spatial index | #92–#93 (2 facts, **batch 1 closed at 2/N 2026-05-08**) | **Cand 1 RECOMMENDED PRIMARY**: Manual mirror of existing parent-suite `satellite-provider` pattern (verified directly via Source #92 filesystem read at /Users/obezdienie001/dev/azaion/suite/satellite-provider/) — PostgreSQL btree composite on slippy-map `(tile_zoom, tile_x, tile_y, version)` for geographic spatial-grid range queries + `bytea` descriptor blobs + app-side FAISS `IndexHNSWFlat(d, M=32)` loaded at takeoff via `faiss.read_index` for descriptor ANN + filesystem tile storage at `./tiles/{zoom}/{x}/{y}.{image_type}` slippy-map convention; clean PostgreSQL License + MIT + LGPL/MIT-Apache; trivial dependency footprint (no Postgres extensions); empirically-confirmed Postgres-on-Jetson viability per Source #97 March 2026 article (CPU cores limiting, NOT memory); ~6-54 ms per cache hit comfortably within AC-4.1 400 ms p95 budget; ~700 MB-1.5 GB total memory footprint within AC-4.2 8 GB budget. **Cand 2 DEFERRED secondary**: PostgreSQL + PostGIS 3.4 GiST on `geography(POINT,4326)` with KNN distance ordering (`<->`) + pgvector 0.7+ HNSW for descriptor ANN + same filesystem tile storage; native KNN + radius + combined-SQL capabilities are real improvements BUT 5-10× slower geographic lookup than Cand 1 + heavier dependency (~50-100 MB additional memory + ~50-200 MB additional disk install) + PostGIS GPL-2.0-or-later license-complexity (CONTINGENT REJECT under D-C1-1 = (b) BSD/permissive-only-track) + DIVERGENT from suite pattern + improvements marginal-to-negative in project's pinned 3 Hz spatial-grid query operating context. **Comparative-improvement-vs-Cand-1 verdict**: per user's session-start "significant-improvement-only" bar, no material justification to deviate from existing satellite-provider pattern. Decisions: D-C6-1 (NEW) descriptor-storage-format choice (halfvec recommended); D-C6-2 (NEW Cand-1-only) FAISS index variant choice (IndexHNSWFlat M=32 recommended); D-C6-3 (NEW Cand-1-only CROSS-COMPONENT with C10) descriptor-cache-rebuild-trigger strategy (periodic-during-C10-pre-flight recommended); D-C6-4 (NEW Cand-1-only) geographic-spatial-grid radius (dynamic recommended); D-C6-5 (NEW Cand-2-only contingent) Jetson PostGIS+pgvector co-installation Plan-phase verification (verify-on-Jetson-MVE recommended); D-C6-6 (NEW Cand-2-only contingent) pgvector descriptor-storage-type choice (halfvec recommended); D-C6-7 (NEW CROSS-COMPONENT affects parent-suite satellite-provider) cascade-changes-back-to-suite strategy (leave-unchanged recommended given Cand 1 closure verdict). |
| [`C7_inference_runtime.md`](C7_inference_runtime.md) | **C7** — On-Jetson inference runtime | #94–#96 (3 facts, **batch 1 closed at 3/N 2026-05-08**) | **Cand 1 RECOMMENDED PRIMARY**: TensorRT native — JetPack 6.2 bundled TensorRT 10.3 + `IInt8EntropyCalibrator2` + `BuilderFlag.FP16+INT8` mixed-precision + engines built directly on Jetson Orin Nano Super SM 87 (Apache-2.0 in TensorRT 10.x; ships with JetPack so zero-effort install; lowest-latency primary path; 2-3× speedup at INT8 vs FP16 per Source #102 YOLO26 benchmark; engines tied to SM 87 hardware-specific per Source #105 — must be built on deployed Jetson via D-C7-7); **Cand 2 modern-competitive-lead-cross-architecture-portability**: ONNX Runtime + TensorRT EP — `onnxruntime-gpu` via Jetson AI Lab JP6/CU126 wheel index + `TensorrtExecutionProvider` config + automatic CUDA EP / CPU EP subgraph fallback (MIT throughout; cross-architecture portability for replay/SITL on x86 dev hosts; `pip install onnxruntime-gpu` does NOT work on Jetson — needs Jetson AI Lab community wheel via D-C7-3 + numpy<2.0.0 pin via D-C7-4); **Cand 3 mandatory simple-baseline**: pure PyTorch FP16 — `torch.amp.autocast` + `model.half()` + Jetson AI Lab PyTorch 2.5 ARM64 wheel (BSD-3-Clause throughout; zero-conversion regression baseline; reference-correctness oracle for accuracy validation of TRT-built engines; standard `pip install torch` lacks CUDA on Jetson — needs Jetson AI Lab wheel via D-C7-5). **Cross-cutting precision policy** (D-C7-6 NEW CROSS-COMPONENT, affects C2+C3+C1+C7): VPR backbones (CNN-class MixVPR/EigenPlaces/NetVLAD) → INT8+FP16 mixed; ViT-class VPR (SelaVPR DINOv2-L; conditional AnyLoc/BoQ/DINOv2-VLAD) → FP16-only initially, INT8 deferred to Jetson MVE per D-C2-5; matchers (LightGlue with SP/DISK/ALIKED, XFeat, XFeat+LighterGlue) → **FP16-only — NO INT8** per Source #103 quantization-sensitivity finding (LightGlue FP8 ModelOpt collapsed match counts); learned VIO frontends → FP16-only initially. **Triton/DeepStream/CUDA-Python custom kernels considered-and-rejected** (server/video-pipeline class + out-of-budget for embedded 8 h mission) per c7_overkill_options scope choice. Decisions: D-C7-1 (NEW Cand-1-only CROSS-COMPONENT with C9) calibration-dataset-strategy (AerialVL S03 + AerialExtreMatch recommended); D-C7-2 (NEW Cand-1-only) TensorRT mixed-precision flag matrix (per-family policy per D-C7-6 recommended); D-C7-3 (NEW Cand-2-only) ORT-Jetson-wheel-index-pin (mirror to project artifact registry + cu126 recommended); D-C7-4 (NEW Cand-2-only) numpy-version-pin (`numpy<2.0.0` recommended); D-C7-5 (NEW Cand-3-only) PyTorch-Jetson-wheel-pin (PyTorch 2.5 + torchvision 0.20 recommended); D-C7-6 (NEW CROSS-COMPONENT C2+C3+C1+C7) INT8-vs-FP16-per-model-family-precision-policy (per-family policy recommended); D-C7-7 (NEW Cand-1-only CROSS-COMPONENT with C10) engine-build-on-Jetson-vs-prebuilt strategy (primary build-on-target + reference-Jetson fallback recommended); D-C7-8 (NEW Cand-1-only) `config.max_workspace_size` cap (1 GB safe default recommended); D-C7-9 (NEW Cand-1-only) TensorRT version pin within JetPack lifecycle (JetPack 6.2 + TensorRT 10.3 recommended). |
| [`C10_preflight_provisioning.md`](C10_preflight_provisioning.md) | **C10** — Pre-flight cache provisioning (CROSS-COUPLING MINIMAL scope per 2026-05-08 user choice C; only D-C6-3 + D-C7-7 confirmation pipelines researched here, operator tooling design deferred to Plan-phase) | #100–#101 (2 facts, **batch 1 closed at 2/N 2026-05-08**) | **D-C6-3 confirmation (Fact #100)**: descriptor-cache rebuild trigger + atomic-write strategy via direct `faiss.write_index`/`faiss.read_index` Python API + `python-atomicwrites` (write-temp + `fsync` + atomic rename) + content-hash (SHA-256) verification gate at takeoff load + `IO_FLAG_MMAP_IFC` mmap load with `madvise(MADV_WILLNEED)` pre-fault + manifest-hash-driven rebuild trigger; FAISS MIT + atomicwrites MIT throughout; FAISS warns "no internal integrity check, expects validated input" — MITIGATED by content-hash gate at takeoff (binds AC-NEW-7 cache-poisoning safety); rebuild-while-not-flying constraint per restrictions.md. **D-C7-7 confirmation (Fact #101)**: hybrid TensorRT engine-build orchestration — Polygraphy CLI primary for INT8-calibrating builds (`polygraphy convert --int8 --calib-cache=<path> ...` Apache-2.0 + Calibrator API replaces hand-written `IInt8EntropyCalibrator2`) + `trtexec` for fast cache-reuse rebuilds (`--fp16 --int8 --calib=<existing_cache>`) + direct `IBuilderConfig` Python API as escape hatch for unusual models (LightGlue dynamic-shape profiles); calibration cache binary-blob reuse keyed by `SHA-256(calib_corpus)` per D-C10-6; engines tied to SM 87 hardware-specific per Source #105 → must be built on deployed Jetson per D-C7-7 closure (D-C10-8 reference-Jetson-at-HQ + deployed-Jetson-copy-to-archive prebuilt-fallback venue); self-describing filename schema `<model>_sm<SM>_jp<JP>_trt<TRT>_<precision>.engine` per D-C10-7; binds AC-4.1/4.2 latency+memory budgets via D-C7-2 mixed-precision flag matrix + D-C7-1 calibration corpus closure. |
| [`MODEB_addendum.md`](MODEB_addendum.md) | **Mode B addendum** — solution_draft01 assessment (2026-05-08) | #102–#113 (12 facts) | Documentary-audit findings (Facts #102–#108): VINS-Mono BSD/GPL deliverable-formatting error (#102), AC-4.1 latency budget overrun (#103), camera calibration unspecified (#104), Suite Sat Service voting-layer contract gap (#105), `00_ac_assessment.md` BLOCKING-gate skip acknowledged (#106), AC-4.5 FC-consumption pathway scope clarification (#107), SQ2 AdHoP + Top-N re-rank sub-stage absence in solution_draft01 architecture (#108). Web-research findings (Facts #109–#113): MAVLink no-default-auth + MAVLink-2.0 message-signing per FC (#109), MegaLoc + UltraVPR D-C2-11 deferred-evaluation revision (#110), `MAV_CMD_SET_EKF_SOURCE_SET` no-deployed-GCS-implementer re-confirmation (#111), OpenCV ≥4.12.0 CVE pin (#112), XoFTR + DINOv2-features cross-modal contrarian evidence (#113). |
| [`C8_fc_adapter.md`](C8_fc_adapter.md) | **C8** — MAVLink / MSP2 FC adapter | #97–#99 (3 facts, **batch 1 closed at 3/N 2026-05-08**) | **Cand 1 RECOMMENDED PRIMARY for ArduPilot**: pymavlink → MAVLink `GPS_INPUT` (msg 232) cooperative-path; `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)` periodic injection at 5 Hz over MAVLink (UART/USB/UDP per D-C8-1); FC-side `GPS1_TYPE=14` MAVLink + `EK3_SRC1_POSXY=3` GPS source-set drives EKF3 ingestion via `AP_GPS_MAV` (verified Source #4 SQ6 + Source #106 + Source #107); pymavlink LGPL-3.0 linkable from Apache-2.0 app per LGPL §6 (D-C8-3 mitigation). **Cand 2 RECOMMENDED PRIMARY for iNav**: `MSP2_SENSOR_GPS` (id 7939 / 0x1F03) via Python MSP V2 (YAMSPy or INAV-Toolkit `msp_v2_encode`); `mspGPSReceiveNewData()` direct passthrough (no validation gate beyond data parse); covariance fields `hPosAccuracy`/`vPosAccuracy`/`hVelAccuracy` align directly with AP `GPS_INPUT.horiz_accuracy`/`vert_accuracy`/`speed_accuracy`; YAMSPy + INAV-Toolkit MIT throughout; `USE_GPS_PROTO_MSP` enabled by default in iNav target/common.h (verified Source #111 + #112 + #113); locked SQ6 + AC-4.3 + restrictions.md transport. **Cand 3 DEFERRED secondary for iNav**: UBX impersonation via pyubx2 NAV-PVT — forging u-blox NAV-PVT frames through standard GPS pipeline; iNav-side `gpsMapFixType()` validation gate requires `flags & 0x01 = 1` (gnssFixOK) AND `fixType ∈ {2,3}` per Source #110 `gps_ublox.c` lines 215-220 + 654; pyubx2 BSD-3-Clause clean dual-use; **does NOT clear user's "significant-improvement-only" bar over Cand 2** — richer protocol surface (NAV-PVT periodic + NAV-VER startup + CFG-MSG/CFG-RATE ACK behaviour) + AC-NEW-7 forgery posture + stricter validation gate + AP-path field-name divergence outweigh pyubx2 library-maturity advantage. **Mid-batch correction**: I caught a contradiction between my own initial AskQuestion phrasing ("UBX impersonation as ONLY iNav path") and locked SQ6 + AC-4.3 + restrictions.md verdicts; user re-locked scope via `c8_inav_recovery=B` to evaluate both as parallel candidates. Decisions: D-C8-1 (NEW Cand-1-only) pymavlink connection-string transport choice (env-driven default-UART recommended); D-C8-2 (NEW Cand-1-only CROSS-COMPONENT with AC-NEW-2) `MAV_CMD_SET_EKF_SOURCE_SET` companion-driven switch ownership pattern (companion publishes to source-set 2 + auto-switches FC recommended); D-C8-3 (NEW Cand-1-only) pymavlink LGPL-3.0 license-posture verification (bundle-unmodified-with-version-pin recommended); D-C8-4 (NEW Cand-2-only) Python MSP V2 implementation choice (YAMSPy primary + thin custom encoder fallback recommended); D-C8-5 (NEW Cand-2-only) MSP2_SENSOR_GPS injection rate (5 Hz periodic recommended); D-C8-6 (NEW Cand-3-only contingent) UBX-version-advertisement strategy (advertise version ≥ 15.0 recommended); D-C8-7 (NEW Cand-3-only contingent CROSS-COMPONENT with AC-NEW-7) AC-NEW-7 audit-trail posture for UBX impersonation (explicit FDR audit entry recommended); D-C8-8 (NEW CROSS-COMPONENT C5+C8) covariance-honesty cross-FC enforcement strategy (per-FC unit conversion recommended via 95% confidence ellipse semi-major axis from C5 GTSAM `Marginals.marginalCovariance`). |
**Cross-cutting consumers** (do not duplicate facts here, just point in):
_docs/00_research/02_fact_cards/MODEB_addendum.md
+111
View File
@@ -0,0 +1,111 @@
# Fact Cards — Mode B Addendum (2026-05-08)
> Mode B Solution Assessment of `_docs/01_solution/solution_draft01.md`. New facts gathered for findings F1–F20; Mode A facts #1–#101 remain canonical and are not duplicated.
>
> Index: [`00_summary.md`](00_summary.md). Mode B sources: [`../01_source_registry/MODEB_addendum.md`](../01_source_registry/MODEB_addendum.md). Mode B fit-matrix revisions: [`../06_component_fit_matrix/MODEB_revisions.md`](../06_component_fit_matrix/MODEB_revisions.md). Mode B output: [`../../01_solution/solution_draft02.md`](../../01_solution/solution_draft02.md).
>
> Confidence labels and schema match `00_summary.md` legend.
---
## Documentary-audit findings (no new web evidence required)
### Fact #102 — solution_draft01 C1 candidate table mis-licenses VINS-Mono as "BSD permissive clean"; the underlying Mode A C1 Fact #28 correctly classifies it as GPL-3.0 (deliverable-formatting error)
- **Statement**: `solution_draft01.md` § "Component: C1" lists VINS-Mono with the cell "Security: BSD permissive clean" and "Selected (mandatory simple-baseline) — fallback if OKVIS2 fails Jetson MVE". The Mode A C1 fact card #28 (`02_fact_cards/C1_vio.md`) explicitly states VINS-Mono is "GPL-3.0 (copyleft viral) — distribution of the onboard binary requires source disclosure for the entire linked binary and triggers GPL-3 anti-tivoization clauses for embedded firmware" — and the cross-component-gates D-C1-1 license-track decision exists precisely because VINS-Mono / VINS-Fusion / OpenVINS are on the GPL-3.0 axis. Source #122 (raw VINS-Mono LICENCE on github.com) confirms canonical GPL-3.0. The discrepancy is inside Mode A Step 8 (Deliverable Formatting); the Mode A evidence layer is correct.
- **Source**: Mode A C1 Fact #28; Source #122 (canonical LICENCE)
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: SQ3+SQ4 / C1
- **Implication**: solution_draft02 must (a) correct the C1 candidate table cell to "GPL-3.0 contingent on D-C1-1 = (a) or (c) license track", (b) demote VINS-Mono from "Selected (mandatory simple-baseline)" status because under D-C1-1 = (b) BSD/permissive-only track it would be **Rejected** by license, (c) elevate KLT+RANSAC homemade fallback to **the** mandatory simple-baseline (matches Mode A C1 Fact #35), and (d) name the actual BSD/permissive-track lead as OKVIS2 (matches C1 Fact #31). No change to the cross-component decision graph — D-C1-1 already exists as the gate that resolves this.
### Fact #103 — solution_draft01 latency math (~140-420 ms p95 at K=3 + adaptive LightGlue depth) crosses AC-4.1's 400 ms p95 budget at the upper end with no documented slack for FC-side IMU pre-integration, MAVLink/MSP serialization, OS scheduling jitter, or thermal-throttle backoff
- **Statement**: solution_draft01 § "Component-interaction diagram (pre-flight + runtime)" labels the runtime stack: "C1 OKVIS2 VIO ~30-50 ms + C2 MixVPR query ~25 ms + C3 DISK+LightGlue × K pairs ~90-180 ms FP16 + C4 OpenCV solvePnPRansac ~5-15 ms + GTSAM Marginals ~30-90 ms + C5 GTSAM iSAM2 ~2-5 ms per update at D-C5-5 = (c) + C8 per-FC pymavlink GPS_INPUT / MSP2_SENSOR_GPS 5 Hz periodic", and says total is "~140-420 ms p95 at K=3 + adaptive LightGlue depth". The upper end **420 ms exceeds AC-4.1's 400 ms p95** at the documented Jetson Orin Nano Super extrapolation. There is no reserved slack for: (i) MAVLink/MSP serialization + UART/USB transmission to FC (~5-20 ms typical), (ii) OS scheduling jitter under shared-CPU+GPU contention (~10-30 ms typical at 90th-99th percentile per Source #97 Postgres-on-Jetson observations), (iii) thermal-throttle backoff at +50 °C ambient per AC-NEW-5 (Jetson backs off from 25 W to 15 W, collapsing throughput by ~40%), (iv) FC-side IMU pre-integration interpolation latency for the timestamp the GPS_INPUT/MSP2_SENSOR_GPS frame is targeted at, (v) FAISS HNSW index search variance at p99 (~1-3 ms typical → up to ~10-15 ms at p99 per Source #115). A defensible AC-4.1 latency partition would carve a project-side worst-case ≤300 ms p95 budget with explicit per-stage deadlines + slack reservation; current draft01 budgets up to 420 ms with implicit assumption-of-best-case stack behavior.
- **Source**: solution_draft01.md self-citation; AC-4.1; Mode A Sources #97 + #115; AC-NEW-5
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High (math is internal to draft01)
- **Sub-Question Binding**: SQ3+SQ4 / C1+C2+C3+C4+C5+C7+C8 cross-cutting NFR
- **Implication**: solution_draft02 must add a NEW Plan-phase decision **D-CROSS-LATENCY-1: AC-4.1 latency budget partition strategy** with options (a) tighten K=3 to K=2 to recover ~30-60 ms of headroom, (b) drop GTSAM `Marginals` covariance recovery from RUNTIME path and use adaptive Jacobian-based covariance per D-C4-2 = (a) to recover ~20-60 ms, (c) accept the budget overrun and validate at Jetson MVE that p95 lands under 400 ms in steady-state (i.e. trust the math is conservative and adaptive-LightGlue-depth in practice will land closer to 140 ms than 420 ms), (d) hybrid: K=3 default + auto-degrade to K=2 + Jacobian-covariance under thermal throttle. Recommendation: **(d) hybrid** — preserves AC-4.1 satisfaction across the operating envelope without permanently sacrificing accuracy. **NEW cross-component gate: requires Jetson MVE measurement of full p95+p99 distribution under hot-soak NFT-3 conditions before lock.**
### Fact #104 — Camera intrinsics + camera-to-body calibration are PROJECT-LEVEL OPEN ITEMS per `_docs/00_problem/problem.md` last sentence and `flight_derkachi/README.md`; solution_draft01 does NOT inventory this as a Plan-phase decision
- **Statement**: `_docs/00_problem/problem.md` last sentence: "Camera intrinsics, lens distortion, raw camera feed parameters, and exact camera-to-body calibration are still pending, so final production accuracy claims remain gated on calibration data or a separately surveyed representative dataset." `_docs/00_problem/input_data/flight_derkachi/README.md`: "Camera intrinsics, lens distortion, raw camera resolution, and exact camera-to-body calibration are still unknown, so this fixture is not sufficient by itself for final production camera calibration or satellite-anchor accuracy claims." `_docs/00_problem/input_data/expected_results/results_report.md` § Known Gaps: "Final production acceptance requires camera calibration and representative datasets with synchronized camera/IMU plus ground-truth trajectory." solution_draft01 cites Sources #82+#83 (OpenCV solvePnPRansac signature requires `K` intrinsic matrix + `dist` distortion coefficients) but does not flag that **K and dist are not yet known** for the deployed ADTi 20MP 20L V1 nav camera. Without intrinsics + camera-to-body extrinsic calibration, the entire C4 pose-estimation pipeline cannot run on real production frames; the Jetson MVE results will be calibration-acquisition-dependent.
- **Source**: `_docs/00_problem/problem.md` line 1; `_docs/00_problem/input_data/flight_derkachi/README.md` line 12; `_docs/00_problem/input_data/expected_results/results_report.md` § Known Gaps; OpenCV Sources #82+#83
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: PCM (Project Constraint Matrix) input availability dimension
- **Implication**: solution_draft02 must add a NEW project-level decision **D-PROJ-1: Camera calibration acquisition strategy** with options (a) checkerboard calibration on a pre-deployment ADTi 20MP 20L V1 nav-camera unit (canonical OpenCV calibration workflow ~1-2 days engineering + lab access), (b) photogrammetric self-calibration from the first ~50 deployment frames over known landmarks (~2-3 days plus runtime support code; produces production-correct calibration but degrades first-mission accuracy), (c) request manufacturer's factory-calibration data sheet from ADTi (low cost if available; risk: vendor may not publish per-unit calibration), (d) hybrid: factory data sheet + ground-truth checkerboard refinement on each deployed unit. Recommendation: **(d) hybrid**. **CRITICAL Plan-phase gate**: this is a hard prerequisite for AC-1.1/1.2 frame-center-accuracy validation; Test Spec (greenfield Step 5) cannot lock end-to-end accuracy fixtures without it.
### Fact #105 — AC-NEW-7 cache-poisoning safety budget explicitly depends on a Suite Sat Service-side voting layer that solution_draft01 does NOT audit for existence, contract, or build status
- **Statement**: `_docs/00_problem/acceptance_criteria.md` § AC-NEW-7 External-dependency note: "The Suite Satellite Service is expected to operate a multi-flight ingest-side voting layer that gates onboard-tile promotion to 'trusted basemap' until multiple independent flights agree on geo-alignment. Voting algorithm is the Service's concern; onboard's job (AC-8.4) is to publish per-tile quality metadata sufficient for that layer. End-to-end AC-NEW-7 evidence depends on this Service contract." solution_draft01 § Architecture lists C6 + C10 as covering the onboard half (publish per-tile quality metadata, content-hash gate at takeoff, atomic-write descriptor cache) but does NOT verify that the Suite Service voting layer (a) has a documented contract, (b) has been implemented, (c) is on the parent-suite roadmap, or (d) has a fallback if not yet built. Without the Service-side voting, a single bad onboard pose with optimistic covariance writes a misaligned tile that becomes the next flight's anchor — cross-flight error compounding that NFT-5 (in solution_draft01) explicitly tries to test but cannot validate end-to-end without the Service contract.
- **Source**: AC-NEW-7 verbatim; solution_draft01 § Architecture C6+C10; solution_draft01 § Testing Strategy NFT-5
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: PCM cross-component external-dependency dimension; SQ8 (security)
- **Implication**: solution_draft02 must add a NEW project-level decision **D-PROJ-2: Suite Sat Service voting-layer contract verification** with options (a) verify Suite Service voting layer is documented + scheduled for the deployment timeframe; (b) draft the contract from the onboard side and propose to the Suite Service team; (c) build a project-internal multi-flight aggregator as a stop-gap until Suite Service ships the layer (~2-3 weeks engineering, but cross-flight aggregator means onboard now owns suite-component scope creep); (d) accept that AC-NEW-7 Service-side validation is best-effort and document the gap explicitly. Recommendation: **(a) verify + (b) draft** in parallel — the contract definition is small (per-tile quality metadata schema + voting threshold spec) and propagating it back to the Suite Service team de-risks the entire AC-NEW-7 obligation. **CRITICAL cross-suite gate**: requires coordination with the parent-suite Satellite Service team before AC-NEW-7 NFT-5 can pass with end-to-end evidence.
### Fact #106 — Mode A Phase 1 BLOCKING gate (`00_ac_assessment.md`) was not produced as a standalone artifact in the Mode A run per solution_draft01's own self-disclosure
- **Statement**: solution_draft01 § Note on AC assessment (lines 17-18): "Mode A Phase 1 (`00_ac_assessment.md` BLOCKING gate per the research SKILL.md) was not executed as a standalone artifact in this run. Per-AC binding evidence is instead distributed across the per-component fact cards and the Restrictions × Candidate-Modes sub-matrix sections in `06_component_fit_matrix/Cx_*.md`. This is acknowledged as a process deviation and is recoverable by extracting an `00_ac_assessment.md` summary file from the existing per-AC binding evidence on demand. No AC has been silently dropped or unverified." Per `_docs/00_research/00_question_decomposition.md` line 4 the Phase 1 skip was a **prior user decision** after a cleanup pass that stripped implementation details from `acceptance_criteria.md` and `restrictions.md`; "AC/restrictions are treated as fixed inputs". Mode B can either (a) extract the standalone artifact retroactively from the distributed evidence, (b) confirm the deviation as accepted by the user, or (c) leave it as-is for Plan-phase to either resolve or carry forward. The risk is small (per-AC binding IS in the per-component fact cards) but the canonical research methodology says a BLOCKING gate cannot simply be skipped.
- **Source**: solution_draft01.md "Note on AC assessment"; `_docs/00_research/00_question_decomposition.md` line 4; research SKILL.md Mode A Phase 1 BLOCKING-gate spec
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: Process compliance with research SKILL.md
- **Implication**: solution_draft02 acknowledges the deviation and recommends extraction of `00_ac_assessment.md` IF user wants the canonical artifact; otherwise the deviation is treated as accepted (per `00_question_decomposition.md` line 4 prior-user decision) and recorded explicitly in `_docs/_process_leftovers/`.
### Fact #107 — AC-4.5 (system may refine prior estimates and emit corrections) FC-consumption pathway is unspecified; neither MAVLink `GPS_INPUT` nor MSP2 `MSP2_SENSOR_GPS` support "correct prior frame N+ago" semantics; GTSAM iSAM2's NATIVE look-back refinement is therefore internal-only and does not reach the FC
- **Statement**: AC-4.5 ("System may refine prior estimates and emit corrections") is satisfied by GTSAM iSAM2's incremental smoothing per Mode A Fact #89 — the estimator can revise past keyframe poses when new measurements arrive. solution_draft01 § Component C5 + § Testing Strategy IT-10 cite this as a key benefit of D-C5-5 = (c) GTSAM-shared-substrate. However: ArduPilot's `AP_GPS_MAV` (Source #4) and iNav's `mspGPSReceiveNewData()` (Source #110) both consume the **latest** received GPS frame as the current best estimate; neither supports retroactive correction of a frame N steps in the past. So GTSAM iSAM2's look-back refinement value is **internal-only** — it improves the current best pose estimate after smoothing the past, but the FC sees only the current frame after smoothing, not corrections to past frames. AC-4.5 is therefore satisfied as "internal estimator refines past + emits the corrected current estimate", not as "FC retroactively corrects past flight log". Draft01 does not make this scoping explicit; IT-10 in particular does not validate AC-4.5 — it validates per-FC unit conversion of covariance.
- **Source**: AC-4.5 verbatim; Mode A Fact #89 (GTSAM iSAM2); Mode A SQ6 Source #4 (`AP_GPS_MAV.cpp`); Mode A C8 Source #110 (`gps_ublox.c`)
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: SQ3+SQ4 / C5; SQ6 / C8
- **Implication**: solution_draft02 § Architecture C5 must clarify "AC-4.5 satisfied as internal smoothing + corrected current-frame emission; FC log is forward-time only". solution_draft02 § Testing Strategy must add a new **IT-11 — Smoothing-loop look-back accuracy** test that validates GTSAM iSAM2's smoothed past-keyframe poses against ground-truth at smoothing convergence (independent of FC-side consumption). FDR (AC-NEW-3) MUST log smoothed past-frame estimates so post-mission analysis can verify AC-4.5.
### Fact #108 — SQ2 architectural decisions promoted "AdHoP refinement loop" + "Top-N inlier-based re-rank" to explicit named sub-stages in the runtime pipeline (per `_docs/00_research/00_question_decomposition.md` lines 175-178), but solution_draft01 § Architecture has neither a candidate row nor a named sub-stage for either
- **Statement**: `_docs/00_research/00_question_decomposition.md` § "SQ2 — Architectural decisions" — Decision 2: "AdHoP refinement loop (Fact #22) → (b) Conditional — only invoked when initial reprojection error exceeds a threshold. C3 (matcher) latency budget = base (single-pass) + AdHoP-conditional overhead (worst-case 2× when triggered)." Decision 3: "Top-N re-rank promotion (Fact #25) → (a) Promote to an explicit named sub-stage between C2 and C3. SQ3+SQ4 will hyperparameter-sweep N ∈ {5, 10, 15, 20}; C2 candidates evaluated jointly with re-rank cost. Top-N re-rank by inlier-count is now a hard pipeline component, not implicit." solution_draft01 § Architecture lists candidate tables for C1+C2+C3+C4+C5+C6+C7+C8+C10. The component-interaction diagram shows "C2 MixVPR query → top-K=3 satellite tile retrieval → C3 DISK+LightGlue × K pairs" — the K=3 retrieval IS the top-K from C2, but the **re-rank by inlier count** sub-stage promised by SQ2 Decision 3 is not represented. Similarly, no AdHoP-conditional refinement candidate appears in the C3 row, despite SQ2 Decision 2 carving its latency budget.
- **Source**: `_docs/00_research/00_question_decomposition.md` lines 175-178; solution_draft01 § Architecture C1-C10; solution_draft01 § Component-interaction diagram
- **Phase**: Mode B documentary audit
- **Confidence**: ✅ High
- **Sub-Question Binding**: SQ2 closure
- **Implication**: solution_draft02 must either (a) populate the architecture with new candidate rows for "Top-N re-rank by inlier count" (likely a thin wrapper around the C3 matcher's RANSAC inlier counter) and "AdHoP-conditional refinement" (per Source #40 OrthoLoC AdHoP method-agnostic preconditioning); or (b) explicitly close SQ2 Decisions 2+3 as "implicit inside C3" — but in that case the "promote to explicit named sub-stage" wording from question_decomposition must be revisited and the user notified that the architecture deviated. Recommendation: **(a) populate** — both are well-scoped sub-components with cited Sources (#22+#25 in the original SQ2 closure) and the latency budgets are already carved. solution_draft02 § Architecture adds a "Re-rank" sub-stage between C2 and C3 plus an "AdHoP-conditional" sub-stage between C3 and C4.
---
## Web-research findings (2026-05-08)
### Fact #109 — MAVLink protocol lacks cryptographic authentication by default (CVE-2026-1579, CVSS 9.8 CRITICAL); ArduPilot supports MAVLink 2.0 message signing as the canonical mitigation; iNav has only partial MAVLink support and does NOT implement message signing — cross-FC asymmetry on the GCS / telemetry link is material for AC-NEW-7 + AC-NEW-2
- **Statement**: Per Source #126 (NVD CVE-2026-1579, CVSS 9.8 CRITICAL): "The MAVLink communication protocol lacks cryptographic authentication by default. Unauthenticated parties with MAVLink interface access can send arbitrary messages including SERIAL_CONTROL commands for interactive shell access." Affected named: PX4 Autopilot v1.16.0_SITL_latest_stable. **Mitigation: enable MAVLink 2.0 message signing.** Per Source #128 (ArduPilot Plane MAVLink2 Signing docs): ArduPilot supports MAVLink2 signing via Mission Planner SETUP > Advanced > "Mavlink Signing"; non-USB serial ports can be configured to only respond to MAVLink commands carrying the correct passkey; a 13-byte signature includes link ID (8 bits), timestamp (48 bits in 10-microsecond units since 2015-01-01), and 48-bit SHA-256 hash signature based on packet + timestamp + secret key (Source #128 + canonical mavlink.io/en/guide/message_signing.html). Issue #28736 + PR #29546 (March 2025) add channel-specific signing for separate MAVLink ports — direct relevance to companion-computer wired connections per Source #128. Per Source #129 (iNav MAVLink wiki, frogmane edited 2025-12-11): "iNav has partial MAVLink support and does not implement message signing. It lacks parameter API support and has limited command compatibility." Companion-FC inbound on iNav is MSP2 (not MAVLink) so the signing-gap is on the OUTBOUND MAVLink telemetry side from iNav to the GCS, not on the inbound external-positioning path — but cross-FC asymmetry is still material because the GCS link itself carries `STATUSTEXT` and operator commands per AC-6.1 + AC-6.2.
- **Source**: Source #126 (CVE-2026-1579), Source #128 (ArduPilot Plane MAVLink2 Signing docs + PR #29546), Source #129 (iNav MAVLink wiki), canonical mavlink.io/en/guide/message_signing.html (Source #128 cross-cite)
- **Phase**: Mode B web research
- **Confidence**: ✅ High (NVD official + ArduPilot official + iNav official wiki)
- **Sub-Question Binding**: SQ6 (FC adapter security posture) + SQ8 (AC-NEW-7 + AC-NEW-2 security)
- **Implication**: solution_draft02 must add a NEW Plan-phase decision **D-C8-9: MAVLink 2.0 message signing posture per FC** with options (a) require MAVLink 2.0 signing on ALL MAVLink channels (companion ↔ ArduPilot, FC ↔ GCS, companion ↔ GCS); (b) require signing only on the companion ↔ ArduPilot wired channel (the inbound external-positioning path on AP); (c) accept the unsigned-by-default posture and document it as an external-attack-surface risk; (d) hybrid: signing on companion ↔ AP wired channel + key rotation on every flight. iNav has no signing option per Source #129 — explicit cross-FC asymmetry must be documented. Recommendation: **(d) hybrid for AP**. Cross-FC asymmetry: iNav GCS link is unsigned by design — document explicitly under AC-NEW-7 and propose iNav firmware feature-request as Plan-phase carryforward. **NEW NFT-8 — MAVLink message-signing verification**: SBOM dump confirms passkey configuration for AP signing channel; iNav side documents the unsignable-link as accepted residual risk.
### Fact #110 — MegaLoc (Berton & Masone, CVPR 2025) and UltraVPR (RAL 2025 / ICRA 2026) are MIT-licensed aerial-validated VPR candidates that materially change the D-C2-11 deferred-evaluation recommendation; UltraVPR specifically targets UAV with documented 44 Hz throughput on Jetson Orin NX (Orin-Nano-Super-class)
- **Statement**: Per Source #123 (MegaLoc): MIT-licensed; February 2025 release; SOTA on multiple VPR benchmarks (indoor + outdoor); validated on aerial datasets via the AirZoo benchmark (Source #125) which "demonstrates that fine-tuning MegaLoc on aerial data yields substantial performance gains for aerial image retrieval and cross-view matching tasks". Distributed via torch.hub for easy installation. Per Source #124 (UltraVPR): MIT-licensed; RAL 2025 + ICRA 2026; "unsupervised lightweight rotation-invariant aerial VPR system designed for UAV applications"; **ONNX model runs at approximately 44 Hz on Jetson Orin NX** (Orin Nano Super is in the same Ampere family; expected to land in the same throughput band ±20%); validated on VPAir + UAV-VisLoc datasets — directly relevant to the project's pinned aerial UAV operating context. solution_draft01 § "Open decisions for Plan-phase" line 322 explicitly defers D-C2-11 (MegaLoc successor evaluation) to "post-research session" because Mode A had not gathered sufficient evidence on MegaLoc's aerial applicability or Jetson runtime. Mode B research closes both gaps: MegaLoc is aerial-validated (AirZoo); UltraVPR is aerial-pretrained + Jetson-throughput-documented. The D-C2-11 recommendation should be revised from "(c) skip and rely on closed mandatory pre-screen" to "(a) treat both MegaLoc AND UltraVPR as new Documentary Lead candidates on the BSD/permissive C2 axis at next session, with mandatory Jetson MVE under D-C1-2 / D-C2-4".
- **Source**: Source #123 (MegaLoc), Source #124 (UltraVPR), Source #125 (AirZoo aerial validation)
- **Phase**: Mode B web research
- **Confidence**: ✅ High (peer-reviewed publications + official repos with pretrained weights)
- **Sub-Question Binding**: SQ3+SQ4 / C2 D-C2-11
- **Implication**: solution_draft02 § Architecture C2 must add MegaLoc + UltraVPR as Documentary Lead candidates on the BSD/permissive C2 axis. UltraVPR is potentially the strongest candidate by the project's specific operating-context scoring: rotation-invariant (multi-heading aerial flights), unsupervised (no aerial-retrain cost — closes D-C2-1), Jetson-Orin-NX-runtime-documented at 44 Hz (substantially exceeds 3 Hz nav-camera rate with massive headroom), and MIT-licensed (BSD/permissive track clean). MegaLoc is the broader-applicability primary if SOTA across non-aerial datasets is also wanted (e.g., for cross-domain generalization). **D-C2-11 revised**: (a) elevate UltraVPR to Documentary Lead PRIMARY recommendation on BSD/permissive C2 axis, with MixVPR / EigenPlaces / SelaVPR as siblings; (b) add MegaLoc as Documentary Lead SECONDARY with broader-applicability tag; (c) preserve the closed pre-screen (5/5: MixVPR + SALAD + SelaVPR + NetVLAD + EigenPlaces) as fallback. Mandatory Jetson MVE per D-C1-2 / D-C2-4 expanded scope to cover both UltraVPR + MegaLoc + the existing five.
### Fact #111 — D-C8-2 = (b) companion-driven `MAV_CMD_SET_EKF_SOURCE_SET` switch pattern is supported by ArduPilot at firmware level since August 2021 (PR #18345 → SITL-tested) but no production-deployed GCS or companion implementation is publicly documented; the project will be establishing the canonical pattern itself
- **Statement**: Per Source #130 (ArduPilot common-ekf-sources.rst + PR #18345): ArduPilot supports `MAV_CMD_SET_EKF_SOURCE_SET` (MAVLink command id 42007) since merge in August 2021; the command accepts source set values in 1-3 range; tested in SITL. Source #130 explicitly states: "no GCSs are currently known to implement this" and "The results do not provide specific information about Auterion, NGPS, or production deployment status." This re-confirms Mode A SQ6 Fact #3 from a fresh search at access time 2026-05-08. solution_draft01 § Open decisions D-C8-2 = (b) "companion publishes to source-set 2 + auto-switches FC to set 2 on first valid fix + switches back to set 1 when companion is unavailable (RECOMMENDED ~mirrors NGPS/Auterion pattern)" cites NGPS/Auterion deployment pattern but Mode A SQ1 Sources #25–#37 do not provide direct evidence of either NGPS or Auterion using the companion-driven switch — they document the existence of those deployed systems but not their internal source-set switching mechanism. This is a gap: the project is committing to a pattern that is **architecturally supported but not production-deployed**.
- **Source**: Source #130 (ArduPilot common-ekf-sources.rst + PR #18345 verified 2026-05-08); Mode A SQ6 Fact #3
- **Phase**: Mode B web research (verification re-run)
- **Confidence**: ✅ High (ArduPilot official documentation)
- **Sub-Question Binding**: SQ6 / C8 D-C8-2
- **Implication**: solution_draft02 must downgrade D-C8-2 fit status from `Selected` to **`Selected with runtime gate`** per Step 7.5.3 carve-out wording, with the runtime gate being "validated end-to-end on ArduPilot Plane SITL by IT-3 (Spoofing-promotion latency) before lock". Add NEW Plan-phase decision **D-C8-2-FALLBACK: companion-driven switch fallback strategy if SITL validation fails** with options (a) switch to operator-manual source-set flip via RC aux switch option 90 per draft01's existing D-C8-2 = (c), accepting AC-NEW-2 ≤3s latency would now require operator response time; (b) implement operator-warning STATUSTEXT instead of automated switch, deferring authority to operator; (c) escalate to ArduPilot dev community to characterize firmware-side switch latency before lock. Recommendation: **defer to Test Spec greenfield Step 5** which owns SITL fixture acquisition.
### Fact #112 — OpenCV 4.x must be pinned to ≥4.12.0 per CVE-2025-53644 (CVSS 9.8 CRITICAL heap buffer write via crafted JPEG); affects 4.10.0 / 4.11.0; OpenCV is C4's primary `solvePnPRansac` runtime + KLT fallback in C1 + ortho warp in C4
- **Statement**: Per Source #127 (NVD CVE-2025-53644, CVSS 9.8 CRITICAL): "Uninitialized pointer variable on stack when reading crafted JPEG images. Affects versions 4.10.0 and 4.11.0. Fixed in version 4.12.0." Related weakness: CWE-457 (Use of Uninitialized Variable). solution_draft01 § Component C4 cites "OpenCV 4.x calib3d module"; § Component C1 KLT fallback uses "OpenCV pure-Python"; FDR thumbnail re-load + tile cache import paths potentially feed crafted JPEG bytes into OpenCV's `imread` / `imdecode`. The exposure is small (most JPEG inputs are trusted internal nav-camera stream) but FDR thumbnail re-load AND ortho-tile imports from the Suite Sat Service path could be hostile-input vectors per AC-NEW-7. Pinning OpenCV to ≥4.12.0 is a single-line change with no API-break exposure (4.12 is a minor release on the 4.x line).
- **Source**: Source #127 (NVD CVE-2025-53644)
- **Phase**: Mode B web research
- **Confidence**: ✅ High (NVD official)
- **Sub-Question Binding**: SQ8 (security) + SQ3+SQ4 / C1+C4 dependency pinning
- **Implication**: solution_draft02 must pin OpenCV to **≥4.12.0** in all C1+C4 candidate rows; add NEW Plan-phase decision **D-CROSS-CVE-1: dependency security pinning posture** with options (a) lock to specific patched versions of all CVE-affected dependencies (OpenCV ≥4.12.0; FAISS Apache-2.0 throughout — no CVEs; GTSAM clean — no CVEs; TensorRT 10.3 in JetPack 6.2 — no CVE-applicable since not using TRT-LLM 0.x); (b) maintain a project SBOM with monthly CVE re-scan; (c) automate pinning via dependabot or equivalent. Recommendation: **(a) + (b)** — minimal cost, maximum AC-NEW-7 audit-trail coverage.
### Fact #113 — XoFTR (cross-modal) achieves SOTA cross-modal matching but a 2026 SAR-optical benchmark (24-matcher comparison) found foundation-model features (DINOv2) provide modality invariance even WITHOUT explicit cross-modal training — reinforces SelaVPR (DINOv2-L) preference over MixVPR (CNN-only) when cross-domain UAV→satellite registration is the binding stress test
- **Statement**: Per Source #131 (XoFTR + 2026 SAR-optical benchmark): XoFTR achieved the lowest reported mean error at 3.0 pixels on SpaceNet9 cross-modal training scenes among 24 pretrained matcher families. **Critical finding**: "matchers without explicit cross-modal training sometimes performed comparably, suggesting that foundation-model features (like DINOv2) may provide modality invariance." This is direct contrarian evidence on the project's "DISK+LightGlue retrain on aerial-domain corpus closes cross-domain UAV→satellite gap" architectural bet (D-C3-1 = (a) RECOMMENDED-PRIMARY-MITIGATION). The contrarian implication: a DINOv2-backboned VPR (SelaVPR per Mode A C2 fact card) AND a DINOv2-backboned matcher (a hypothetical DINOv2-backed feature extractor + LightGlue) might close the cross-domain gap WITHOUT needing the D-C2-1 ~1-2-week aerial retrain that draft01 baselines. This does not invalidate the existing D-C3-1 = (a) recommendation but it strengthens the case for keeping SelaVPR (DINOv2-L) as a serious candidate alongside MixVPR (CNN) in the BSD/permissive C2 axis, and it suggests MegaLoc (which also uses foundation-model features per Source #123) is similarly attractive without retrain cost.
- **Source**: Source #131 (XoFTR + 2026 SAR-optical benchmark, two-source confirmation per Critical-novelty rule)
- **Phase**: Mode B web research
- **Confidence**: ⚠️ Medium (the "comparable performance without cross-modal training" finding is from one benchmark on SAR-optical, not UAV→satellite — extrapolation to project's exact operating context is plausible but unverified)
- **Sub-Question Binding**: SQ3+SQ4 / C2+C3
- **Implication**: solution_draft02 § Architecture C2 keeps SelaVPR (DINOv2-L two-stage) as **strong secondary** alongside UltraVPR primary on the BSD/permissive C2 axis (per Fact #110 promotion). solution_draft02 § Open decisions adds **D-C2-12: DINOv2-backbone feature-extractor evaluation for cross-domain matching** as carryforward research item — could potentially close D-C3-1 retrain cost via DINOv2-feature-based matcher (e.g., DINOv2 + LightGlue or DINOv2 + paired matcher) without requiring D-C2-1 aerial retrain. Defer to Plan-phase Jetson MVE.
_docs/00_research/06_component_fit_matrix/00_summary.md
+1
View File
@@ -33,6 +33,7 @@ This folder replaces the previous monolithic `06_component_fit_matrix.md` (284 l
| [`C7_inference_runtime.md`](C7_inference_runtime.md) | **C7** — On-Jetson inference runtime | **CLOSED at 3/N (batch 1 closed 2026-05-08)** — top-2 documentary leads + mandatory simple-baseline COMPLETE; **Cand 1 RECOMMENDED PRIMARY** | **Cand 1 (RECOMMENDED PRIMARY)**: TensorRT native — JetPack 6.2 bundled TensorRT 10.3 + `IInt8EntropyCalibrator2` + `BuilderFlag.FP16+INT8` mixed-precision + engines built directly on Jetson Orin Nano Super SM 87 (clean Apache-2.0 in TensorRT 10.x; ships with JetPack so zero-effort install; lowest-latency primary path; 2-3× speedup at INT8 vs FP16 per Source #102 YOLO26 evidence); **Cand 2 (interop alternate)**: ONNX Runtime + TensorRT EP — `onnxruntime-gpu` via Jetson AI Lab JP6/CU126 wheel index + `TensorrtExecutionProvider` config + automatic CUDA EP / CPU EP subgraph fallback (clean MIT throughout; cross-architecture portability for replay/SITL on x86 dev hosts; modern-competitive-lead-cross-architecture-portability); **Cand 3 (mandatory simple-baseline)**: pure PyTorch FP16 — `torch.amp.autocast` + `model.half()` + Jetson AI Lab PyTorch 2.5 ARM64 wheel (clean BSD-3-Clause throughout; zero-conversion regression baseline; reference-correctness oracle for accuracy validation of TRT-built engines) | INT8-only candidates marked Experimental until D-C7-1 calibration dataset materializes; matchers (LightGlue, XFeat, XFeat+LighterGlue) are FP16-only — NO INT8 — per D-C7-6 cross-component model-family precision policy due to Source #103 quantization-sensitivity finding |
| [`C8_fc_adapter.md`](C8_fc_adapter.md) | **C8** — MAVLink / MSP2 FC adapter | **CLOSED at 3/N (batch 1 closed 2026-05-08)** — top-1 per FC for ArduPilot + parallel-evaluation per FC for iNav after mid-batch contradiction recovery COMPLETE; **Cand 1 RECOMMENDED PRIMARY for AP, Cand 2 RECOMMENDED PRIMARY for iNav** | **Cand 1 (RECOMMENDED PRIMARY for ArduPilot)**: pymavlink → MAVLink `GPS_INPUT` (msg 232) cooperative-path; `master.mav.gps_input_send(...)` periodic injection at 5 Hz over MAVLink (UART/USB/UDP); FC-side `GPS1_TYPE=14` MAVLink + `EK3_SRC1_POSXY=3` GPS source-set drives EKF3 ingestion via `AP_GPS_MAV` (LGPL-3.0 pymavlink linkable from Apache-2.0 app per LGPL §6; canonical ArduPilot stack); **Cand 2 (RECOMMENDED PRIMARY for iNav)**: `MSP2_SENSOR_GPS` (id 7939 / 0x1F03) via Python MSP V2 implementation YAMSPy or INAV-Toolkit `msp_v2_encode`; `mspGPSReceiveNewData()` direct passthrough; covariance fields `hPosAccuracy/vPosAccuracy/hVelAccuracy` align directly with AP `GPS_INPUT.horiz_accuracy/vert_accuracy/speed_accuracy` (MIT throughout; clean dual-use compatible; locked SQ6 + AC-4.3 transport); **Cand 3 (DEFERRED secondary for iNav)**: UBX impersonation via pyubx2 NAV-PVT — forging u-blox NAV-PVT frames through standard GPS pipeline; iNav-side `gpsMapFixType()` validation gate requires `flags & 0x01 = 1` (gnssFixOK) AND `fixType ∈ {2,3}`; pyubx2 BSD-3-Clause; **does NOT clear user's "significant-improvement-only" bar over Cand 2** (richer protocol surface + AC-NEW-7 forgery posture + stricter validation gate + AP-path field-name divergence outweigh pyubx2 library-maturity advantage). **Mid-batch correction**: I caught a contradiction between my own initial AskQuestion phrasing ("UBX impersonation as ONLY iNav path") and locked SQ6 + AC-4.3 + restrictions.md verdicts (MSP2_SENSOR_GPS as iNav primary); user re-locked scope via `c8_inav_recovery=B` to evaluate both as parallel candidates | (none yet — pymavlink LGPL-3.0 license posture handled via D-C8-3 = (a) bundle-unmodified-with-version-pin per LGPL §6 standard compliance) |
| [`C10_preflight_provisioning.md`](C10_preflight_provisioning.md) | **C10** — Pre-flight cache provisioning (CROSS-COUPLING MINIMAL scope per 2026-05-08 user choice C; operator CLI/desktop tooling, sector classification, freshness schema deferred to Plan-phase) | **CLOSED at 2/N (batch 1 closed 2026-05-08)** — D-C6-3 + D-C7-7 cross-component gates closed; no further C10 batches required at research layer | **D-C6-3 confirmation**: direct `faiss.write_index` / `faiss.read_index` Python API + `python-atomicwrites` + content-hash verification gate at takeoff + manifest-hash-driven rebuild trigger + `IO_FLAG_MMAP_IFC` mmap load (FAISS MIT, atomicwrites MIT throughout); **D-C7-7 confirmation**: hybrid Polygraphy CLI primary for INT8-calibrating builds + `trtexec` for cache-reuse fast rebuilds + direct `IBuilderConfig` Python API for unusual models (LightGlue dynamic shapes) — Polygraphy + TensorRT 10.x Apache-2.0 throughout, calibration corpus per D-C7-1 closure | (none — both candidates Apache-2.0/MIT clean; FAISS "no internal integrity check" warning mitigated by content-hash gate; `trtexec --int8` random-data caveat mitigated by project-side wrapper enforcing `--calib=<existing_cache>` non-empty precondition) |
| [`MODEB_revisions.md`](MODEB_revisions.md) | **Mode B revisions overlay (2026-05-08)** — solution_draft01 assessment | Overlay file with revised candidate-row statuses + new D-Cx-y gates surfaced by Mode B findings F1–F20 (Facts #102–#113). VINS-Mono license-track-only on D-C1-1 = (a)/(c); KLT+RANSAC re-labelled mandatory simple-baseline (per Mode A C1 Fact #35); UltraVPR Documentary-Lead PRIMARY + MegaLoc Documentary-Lead SECONDARY on BSD/permissive C2 axis (D-C2-11 revised); D-C8-2 downgraded to `Selected with runtime gate` (SITL validation gate before lock); OpenCV pin tightened to ≥4.12.0; new sub-stages added (Top-N inlier re-rank between C2 and C3; AdHoP-conditional refinement between C3 and C4); new gates D-C2-12 (DINOv2-feature matcher), D-C8-9 (MAVLink-2.0 message-signing per FC), D-CROSS-LATENCY-1 (AC-4.1 budget partition), D-CROSS-CVE-1 (dependency security pinning), D-PROJ-1 (camera calibration acquisition), D-PROJ-2 (Suite Sat Service voting-layer contract verification); new tests IT-11 (smoothing-loop look-back), NFT-8 (signing verification), NFT-9 (hot-soak latency distribution). | n/a |
| [`99_cross_component_gates.md`](99_cross_component_gates.md) | **Cross-component process gates** | Open — Plan-phase Choose blocks raised by C1+C2+C3+C4+C5+C6+C7+C8+C10 closures | D-C1-1 license posture, D-C1-2 Jetson MVE, D-C2-1..11 (VPR retrain/cache/dim), D-C3-1..6 (matcher mitigation/runtime/K-pairs/ALIKED-mode/DISK-weights/XFeat-mode), D-C4-1..4, **D-C5-1..5 (Manual ESKF + GTSAM iSAM2)**, **D-C6-1..7**, **D-C7-1..9**, **D-C8-1..8**, **D-C10-1 (descriptor-cache rebuild trigger — manifest-hash-driven recommended, NEW from Fact #100)**, **D-C10-2 (descriptor-cache atomic-write strategy — `python-atomicwrites` recommended, NEW from Fact #100)**, **D-C10-3 (content-hash verification gate at takeoff load — reject + STATUSTEXT + refuse takeoff recommended, NEW from Fact #100, CROSS-COMPONENT with AC-NEW-7)**, **D-C10-4 (descriptor-cache load path — mmap with `madvise(MADV_WILLNEED)` pre-fault recommended, NEW from Fact #100)**, **D-C10-5 (TensorRT engine-build orchestration tool — hybrid Polygraphy + trtexec + direct API recommended, NEW from Fact #101, CROSS-COMPONENT with C7)**, **D-C10-6 (TensorRT calibration-cache reuse strategy — rebuild-on-calib-corpus-SHA-256-change recommended, NEW from Fact #101, CROSS-COMPONENT with D-C7-1)**, **D-C10-7 (TensorRT engine on-disk filename schema — self-describing `<model>_sm<SM>_jp<JP>_trt<TRT>_<precision>.engine` recommended, NEW from Fact #101)**, **D-C10-8 (TensorRT prebuilt-fallback engine generation venue — reference Jetson at HQ + deployed-Jetson-copy-to-archive recommended, NEW from Fact #101)**, Fact #40 dual-rate camera pipeline | n/a |
---
_docs/00_research/06_component_fit_matrix/99_cross_component_gates.md
+2
View File
@@ -3,6 +3,8 @@
> Mode A Phase 2 — engine Step 7.5 (Component Applicability Gate). Plan-phase Choose blocks raised by C1, C2, C3, C4, C5, C6, C7, C8, and C10 closures. Each gate names its owner and the resolution path. Backing fact cards live in [`../02_fact_cards/`](../02_fact_cards/) by component.
>
> Index: [`00_summary.md`](00_summary.md). Per-component rows: [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), [C10](C10_preflight_provisioning.md). C9 dropped per 2026-05-08 restructure — see `../00_question_decomposition.md`.
>
> **Mode B overlay (2026-05-08)**: this file preserves the Mode A audit trail. NEW gates raised by Mode B Solution Assessment of `_docs/01_solution/solution_draft01.md` are catalogued in [`MODEB_revisions.md`](MODEB_revisions.md) — specifically D-C2-12 (DINOv2-feature matcher evaluation), D-C8-2-FALLBACK (companion-driven EKF source switch fallback if SITL validation fails), D-C8-9 (MAVLink-2.0 message-signing per FC), D-CROSS-LATENCY-1 (AC-4.1 latency budget partition strategy), D-CROSS-CVE-1 (dependency security pinning posture), D-PROJ-1 (camera calibration acquisition strategy), D-PROJ-2 (Suite Sat Service voting-layer contract verification). REVISED gates with Mode B evidence: D-C1-1 (VINS-Mono license re-confirmed GPL-3.0 — see Mode B Fact #102), D-C2-11 (UltraVPR + MegaLoc elevated from "deferred to post-research" to "Documentary Lead PRIMARY + SECONDARY" — see Mode B Fact #110), D-C8-2 (downgraded to `Selected with runtime gate` — see Mode B Fact #111). Read [`MODEB_revisions.md`](MODEB_revisions.md) alongside this file for the current gate state.
---
_docs/00_research/06_component_fit_matrix/MODEB_revisions.md
+72
View File
@@ -0,0 +1,72 @@
# Component Fit Matrix — Mode B Revisions (2026-05-08)
> Mode B Solution Assessment of `_docs/01_solution/solution_draft01.md`. Revisions to specific candidate-row statuses + new D-Cx-y gates surfaced by Mode B findings F1–F20.
>
> Index: [`00_summary.md`](00_summary.md). Mode B fact cards: [`../02_fact_cards/MODEB_addendum.md`](../02_fact_cards/MODEB_addendum.md). Mode B sources: [`../01_source_registry/MODEB_addendum.md`](../01_source_registry/MODEB_addendum.md). Mode B output: [`../../01_solution/solution_draft02.md`](../../01_solution/solution_draft02.md).
>
> The original Mode A row files [`C1_vio.md`](C1_vio.md) ... [`C10_preflight_provisioning.md`](C10_preflight_provisioning.md) + [`99_cross_component_gates.md`](99_cross_component_gates.md) remain canonical. This file overlays revisions; where this file disagrees with the originals, this file wins (the original Mode A files are not retroactively edited so the audit trail is preserved).
---
## Status changes per candidate row
| Component | Candidate | Mode A status (verbatim from row file) | Mode B revised status | Reason |
|---|---|---|---|---|
| **C1** | VINS-Mono | "Selected (mandatory simple-baseline) — fallback if OKVIS2 fails Jetson MVE" + "Security: BSD permissive clean" | **`Selected via VioStrategy interface for comparative study + research/dev builds`**; production-deployed only if D-C1-1-SUB-A resolves to non-(a) AND IT-12 confirms VINS-Mono outperforms OKVIS2; **license corrected from "BSD permissive clean" to "GPL-3.0 (copyleft viral)"** | Fact #102 + 2026-05-08 user directive — Mode A C1 Fact #28 already correctly classified VINS-Mono as GPL-3.0; the BSD label was a Step-8 deliverable-formatting error in solution_draft01. User directive elevates VINS-Mono into the production design as a comparative-study sibling behind a `VioStrategy` interface. Source #122 confirms canonical GPL-3.0; see new D-C1-1-SUB-A below for viral-linkage containment policy. |
| **C1** | KLT+RANSAC homemade fallback | "Selected (project-internal homemade fallback) — used when OKVIS2/VINS-Mono unavailable" | **`Selected (mandatory simple-baseline) — wrapped as `KltRansacVioStrategy` behind VioStrategy interface`** | Mode A C1 Fact #35 + 2026-05-08 user directive: KLT+RANSAC is the engine-required mandatory simple-baseline AND is wrapped as a third `VioStrategy` so the comparative study (IT-12) covers the engine-required baseline alongside OKVIS2 + VINS-Mono. |
| **C1** | (NEW interface) `VioStrategy` interface | n/a | **`Selected (NEW architectural component per 2026-05-08 user directive on A1)`** | NEW: pluggable Strategy/Adapter pattern hosting `Okvis2VioStrategy`, `VinsMonoVioStrategy`, `KltRansacVioStrategy`. Selection is config-driven at startup; FDR (AC-NEW-3) records active strategy `name()` + `license()` per flight. Interface owns "produce `VioOutput` from frame + IMU window per the strategy's algorithm"; per-strategy concerns live in concrete implementations per coderule SRP rule. |
| **C2** | (NEW) UltraVPR (cbbhuxx/UltraVPR, MIT) | n/a (D-C2-11 deferred to post-research) | **`Documentary lead PRIMARY on BSD/permissive C2 axis`**; mandatory Jetson MVE under D-C1-2 / D-C2-4 expanded scope | Fact #110 — RAL 2025 / ICRA 2026 publication; MIT license; **44 Hz on Jetson Orin NX (Orin-Nano-Super-class)**; rotation-invariant (multi-heading aerial flights); unsupervised aerial pretrain (closes D-C2-1 retrain cost); validated on VPAir + UAV-VisLoc datasets. Sources #124. |
| **C2** | (NEW) MegaLoc (gmberton/megaloc, MIT) | n/a (D-C2-11 deferred to post-research) | **`Documentary lead SECONDARY (broader-applicability)`** on BSD/permissive C2 axis; mandatory Jetson MVE | Fact #110 — CVPR 2025 publication; MIT license; SOTA on multiple VPR benchmarks; aerial-validated via AirZoo benchmark (Source #125). Distributed via torch.hub. |
| **C2** | MixVPR | "Selected (mandatory simple-baseline + recommended primary on BSD/permissive track)" | **`Selected (mandatory simple-baseline)`**; demoted from "recommended primary" to "mandatory baseline" — UltraVPR is the new BSD/permissive PRIMARY recommendation | Fact #110 — MixVPR remains valid candidate but UltraVPR's UAV-pretrain + Jetson-runtime evidence dominates on the project's pinned operating context. MixVPR retained as mandatory baseline per Component Option Breadth rule. |
| **C2** | SelaVPR | "Selected (modern-competitive-lead BSD/permissive two-stage) — eligible if D-C2-7 re-rank strategy chosen" | **`Selected (modern-competitive-lead BSD/permissive secondary)` STRENGTHENED** | Fact #113 — XoFTR / SAR-optical benchmark contrarian evidence reinforces foundation-model (DINOv2) backbone preference for cross-domain registration; SelaVPR's DINOv2-L backbone is well-positioned even without aerial retrain. |
| **C8** | pymavlink → MAVLink GPS_INPUT (AP) | "Selected (recommended-primary) for ArduPilot Plane" | **`Selected (recommended-primary) for ArduPilot Plane` + NEW security mitigation requirement: D-C8-9 MAVLink 2.0 message signing on companion ↔ AP wired channel** | Fact #109 — CVE-2026-1579 CVSS 9.8 CRITICAL. ArduPilot supports MAVLink 2.0 message signing (Source #128). Draft01 had no signing-posture decision; Mode B raises D-C8-9 as new gate. |
| **C8** | D-C8-2 = (b) companion-driven `MAV_CMD_SET_EKF_SOURCE_SET` switch | (Recommendation: implicit `Selected` via D-C8-2 = (b) being the recommended pattern) | **`Selected with runtime gate`** per Step 7.5.3 carve-out — runtime gate = SITL validation by IT-3 before lock | Fact #111 — pattern is firmware-supported but no production-deployed precedent; the project will be establishing the canonical pattern itself. Carve-out is for runtime-quality validation, not API capability. |
| **C4** | OpenCV `cv::solvePnPRansac` + GTSAM `Marginals` (D-C4-2 = (b)) | "Selected (mandatory simple-baseline + recommended-primary covariance recovery via GTSAM)" + "OpenCV 4.x" | **`Selected` + dependency pin updated to `OpenCV ≥4.12.0`** per CVE-2025-53644 mitigation | Fact #112 — OpenCV CVE-2025-53644 CVSS 9.8 CRITICAL on 4.10.0 / 4.11.0; fixed in 4.12.0. Single-line pin change with no API break. |
| **C5** | GTSAM iSAM2 (AC-4.5 internal smoothing) | "Selected (modern-competitive-lead-factor-graph + recommended primary path) — couples NATIVELY with C4 GTSAM Marginals via D-C5-5 = (c)" | **`Selected` + AC-4.5 scope clarification: internal smoothing only, NOT FC retroactive correction** | Fact #107 — GTSAM iSAM2 NATIVE look-back refinement value is internal-only; ArduPilot `AP_GPS_MAV` and iNav `mspGPSReceiveNewData()` consume only the latest frame; FC log is forward-time only. AC-4.5 satisfied as "internal estimator refines past + emits corrected current estimate", not as "FC retroactively corrects past flight log". |
| **All C-rows** | (cross-cutting) | (no AC-4.1 latency partition) | **NEW cross-cutting D-CROSS-LATENCY-1: AC-4.1 latency budget partition strategy** | Fact #103 — draft01's own runtime math (~140-420 ms p95) exceeds AC-4.1 (400 ms) at upper end with no slack reservation. Recommendation: hybrid K=3 default + auto-degrade to K=2 + Jacobian-covariance under thermal throttle. |
---
## Architecture-level additions (new sub-stages absent from solution_draft01)
| Sub-stage | Position in pipeline | Recommended candidate | Source |
|---|---|---|---|
| **Top-N inlier-based re-rank** (was promised by SQ2 Decision 3 but absent from solution_draft01) | Between C2 (VPR top-K) and C3 (matcher) | Thin wrapper around C3 matcher's RANSAC inlier counter; rank top-K candidates by inlier count from a single-pair LightGlue / XFeat invocation per candidate; output top-N ⊆ top-K for full-depth C3 matching | Fact #108; SQ2 Decision 3; Mode A SQ2 Source #38–#42 |
| **AdHoP-conditional refinement** (was promised by SQ2 Decision 2 but absent from solution_draft01) | Between C3 (matcher) and C4 (PnP) | OrthoLoC AdHoP method-agnostic perspective preconditioning per Mode A SQ2 Source #40; invoked only when initial reprojection error exceeds a threshold; worst-case 2× C3 latency when triggered | Fact #108; SQ2 Decision 2; Mode A SQ2 Source #40 |
---
## New cross-component / project-level Plan-phase gates (overlay onto `99_cross_component_gates.md`)
| Gate | Owner | Resolution path |
|---|---|---|
| **D-C1-1 (REVISED with Fact #102 evidence)** license-track posture | User | No change to gate; evidence updated — VINS-Mono is GPL-3.0 (not BSD as draft01 listed); C1 BSD/permissive-track lead remains OKVIS2 (per Mode A C1 Fact #31 unchanged) |
| **D-C1-1-SUB-A (LOCKED 2026-05-08 by User to option (a)) — VINS-Mono GPL-3.0 viral-linkage containment policy** | User (locked); Plan-phase implements | Production binary built with `BUILD_VINS_MONO=OFF` → only `Okvis2VioStrategy` + `KltRansacVioStrategy` linked → BSD-clean. Research/dev binary built with `BUILD_VINS_MONO=ON` → all three strategies linked → enables IT-12 comparative study + docs report. CI publishes both binaries; production CI job verifies via SBOM dump that no `vins_mono` GPL-3.0 symbol is present. CMake spec: `option(BUILD_VINS_MONO "Include VINS-Mono GPL-3.0 VioStrategy implementation; production builds MUST set OFF" OFF)`. Plan-phase scope: CMake flag + CI pipeline split (~1 day engineering). Options (b) process-isolation IPC and (c) accept D-C1-1 = (a) GPL-3.0 entire binary considered and rejected — see solution_draft02 § C1 D-C1-1-SUB-A locked-verdict table for trade-off rationale. |
| **D-C2-11 (REVISED with Fact #110 evidence)** UltraVPR + MegaLoc evaluation as Documentary Lead candidates | User + Plan-phase architect | (a) elevate UltraVPR to Documentary Lead PRIMARY on BSD/permissive C2 axis; (b) elevate MegaLoc to Documentary Lead SECONDARY (broader-applicability); (c) preserve closed pre-screen (5/5: MixVPR + SALAD + SelaVPR + NetVLAD + EigenPlaces) as fallback. Mandatory Jetson MVE under D-C1-2 / D-C2-4 expanded scope. |
| **D-C2-12 (NEW from Mode B Fact #113)** DINOv2-backbone feature-extractor evaluation for cross-domain matching | Plan-phase architect + C3 owner | Plan-phase decision: defer to Jetson MVE phase; potentially closes D-C3-1 retrain cost via DINOv2-feature-based matcher (e.g., DINOv2 + LightGlue or DINOv2 + paired matcher) without requiring D-C2-1 aerial retrain. Carryforward research item. |
| **D-C8-2 (REVISED with Fact #111)** companion-driven `MAV_CMD_SET_EKF_SOURCE_SET` ownership pattern | Plan-phase architect + AC-NEW-2 owner | Recommendation unchanged ((b) companion publishes to source-set 2 + auto-switches FC), but **status downgraded to `Selected with runtime gate`** per Step 7.5.3 carve-out — runtime gate = ArduPilot Plane SITL validation by IT-3 (Spoofing-promotion latency) before lock. NEW sub-decision **D-C8-2-FALLBACK** if SITL validation fails: (a) operator-manual RC aux switch option 90 with relaxed AC-NEW-2 wording; (b) operator-warning STATUSTEXT instead of automated switch; (c) escalate to ArduPilot dev community. |
| **D-C8-9 (NEW from Mode B Fact #109)** MAVLink 2.0 message signing posture per FC | Plan-phase architect + security owner | Plan-phase decision: (a) signing on ALL MAVLink channels (over-engineered for the wired companion link); (b) signing on companion ↔ AP wired channel only; (c) accept unsigned default (rejected per CVE-2026-1579 Critical CVSS); (d) **(RECOMMENDED) hybrid: signing on companion ↔ AP wired channel + per-flight key rotation**. Cross-FC asymmetry: iNav has no signing option (Source #129) — explicit residual risk; propose iNav firmware feature-request as Plan-phase carryforward. NEW NFT-8 — MAVLink message-signing verification: SBOM dump confirms passkey configuration for AP signing channel. |
| **D-CROSS-LATENCY-1 (NEW from Mode B Fact #103)** AC-4.1 latency budget partition strategy | Plan-phase architect + project bring-up team | Plan-phase decision: (a) tighten K=3 to K=2 to recover ~30-60 ms; (b) drop GTSAM `Marginals` from RUNTIME path and use Jacobian-covariance per D-C4-2 = (a) to recover ~20-60 ms; (c) accept budget overrun and validate at Jetson MVE that p95 lands under 400 ms in practice; (d) **(RECOMMENDED) hybrid: K=3 default + auto-degrade to K=2 + Jacobian-covariance under thermal throttle**. **Validation gate**: Jetson MVE measurement of full p95+p99 distribution under hot-soak NFT-3 conditions (25 W @ +50 °C for 8 h) before lock. |
| **D-CROSS-CVE-1 (NEW from Mode B Fact #112)** dependency security pinning posture | Plan-phase architect + security owner | Plan-phase decision: (a) **(RECOMMENDED)** lock to specific patched versions of all CVE-affected dependencies (OpenCV ≥4.12.0; FAISS — no CVEs; GTSAM — no CVEs; TensorRT 10.3 in JetPack 6.2 — no CVE-applicable since not using TRT-LLM 0.x; pymavlink — no CVEs published in repo at access time 2026-05-08); (b) maintain a project SBOM with monthly CVE re-scan; (c) automate pinning via dependabot or equivalent. Recommendation: (a) + (b). |
| **D-PROJ-1 (NEW from Mode B Fact #104)** Camera calibration acquisition strategy | User + project bring-up team | Plan-phase decision: (a) checkerboard calibration on a pre-deployment ADTi 20MP 20L V1 nav-camera unit (~1-2 days engineering + lab access); (b) photogrammetric self-calibration from first ~50 deployment frames over known landmarks (~2-3 days plus runtime support code; degrades first-mission accuracy); (c) request manufacturer's factory-calibration data sheet from ADTi (low cost if available; risk: vendor may not publish per-unit calibration); (d) **(RECOMMENDED) hybrid**: factory data sheet + ground-truth checkerboard refinement on each deployed unit. **CRITICAL Plan-phase gate**: hard prerequisite for AC-1.1/1.2 frame-center-accuracy validation; Test Spec greenfield Step 5 cannot lock end-to-end accuracy fixtures without it. |
| **D-PROJ-2 (NEW from Mode B Fact #105)** Suite Sat Service voting-layer contract verification | User + parent-suite Satellite Service team | Plan-phase decision: (a) verify Suite Service voting layer is documented + scheduled for the deployment timeframe; (b) draft the contract from the onboard side and propose to the Suite Service team; (c) build a project-internal multi-flight aggregator as stop-gap (~2-3 weeks engineering, cross-suite scope creep); (d) accept that AC-NEW-7 Service-side validation is best-effort and document the gap. **(RECOMMENDED) (a) verify + (b) draft in parallel** — contract definition is small (per-tile quality metadata schema + voting threshold spec). **CRITICAL cross-suite gate**: requires coordination with parent-suite Satellite Service team before AC-NEW-7 NFT-5 can pass with end-to-end evidence. |
---
## Testing Strategy additions
| Test ID | Purpose | New for Mode B? |
|---|---|---|
| **IT-11 — Smoothing-loop look-back accuracy** | Validate GTSAM iSAM2's smoothed past-keyframe poses against ground-truth at smoothing convergence (independent of FC-side consumption). FDR (AC-NEW-3) MUST log smoothed past-frame estimates so post-mission analysis can verify AC-4.5. | NEW (Fact #107) |
| **NFT-8 — MAVLink message-signing verification** | SBOM dump confirms passkey configuration for AP signing channel; iNav side documents the unsignable-link as accepted residual risk per D-C8-9. | NEW (Fact #109) |
| **NFT-9 — Hot-soak latency distribution** (extends NFT-3) | Measure end-to-end p95 + p99 latency distribution under hot-soak NFT-3 conditions (25 W @ +50 °C for 8 h); validate D-CROSS-LATENCY-1 hybrid degradation behaves correctly (K=3 → K=2 + Jacobian-covariance under thermal throttle). | NEW (Fact #103) |
| **IT-1 (revised)** | Pipeline smoke now must clarify which datasets exercise which AC subsets per `_docs/00_problem/input_data/expected_results/results_report.md` § Known Gaps: still-image set is for AC-1.1/1.2 frame-center geolocation accuracy ONLY; Derkachi video is for runtime cadence + VIO + replay; neither is sufficient by itself for end-to-end AC-4.1 latency validation under production cadence + altitude + calibration. | Revised (clarify dataset purpose mapping) |
| **IT-12 — VIO comparative study** | Replay same flight footage through all three `VioStrategy` implementations (`Okvis2VioStrategy`, `VinsMonoVioStrategy`, `KltRansacVioStrategy`) in the research/dev build; emit side-by-side AC-1.3 / AC-2.1a / AC-NEW-4 / AC-4.1 / AC-4.2 / SBOM table; published to `_docs/02_document/vio-comparative-study.md`; production-selection gate for D-C1-1-SUB-A. | NEW (2026-05-08 user directive on A1) |
---
## Editing rules (preservation of audit trail)
1. The original Mode A row files (`C1_vio.md` through `C10_preflight_provisioning.md`) and `99_cross_component_gates.md` are NOT retroactively edited — they preserve the Mode A audit trail.
2. Where this Mode B revisions file disagrees with the originals, this file wins. Future Mode B / Plan-phase consumers should read this overlay file alongside the original row files.
3. New Plan-phase decisions raised by Mode B (D-C2-12, D-C8-9, D-CROSS-LATENCY-1, D-CROSS-CVE-1, D-PROJ-1, D-PROJ-2) are catalogued here and in `solution_draft02.md` § Open decisions. Future Mode B / Plan-phase invocations should append to either this file or its sibling `99_cross_component_gates.md` (preferred for Plan-phase consumption) — not modify entries written here.