mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-22 21:11:13 +00:00
Revise acceptance criteria and restrictions documentation to clarify recent updates and specifications. Key changes include enhanced definitions for position accuracy, image processing quality, and operational parameters, as well as updates to camera specifications and validation requirements. This revision aims to improve clarity and ensure alignment with project goals.
This commit is contained in:
@@ -0,0 +1,54 @@
|
||||
# Acceptance Criteria Assessment
|
||||
|
||||
Accessed: 2026-05-01. Rerun after user-approved clarifications: 2026-05-01.
|
||||
|
||||
## Research Scope
|
||||
|
||||
- **Output class**: Technical-component selection support.
|
||||
- **Novelty sensitivity**: High for VPR, embedded AI, and autopilot integration; source preference is current papers and official docs.
|
||||
- **Boundary**: Fixed-wing UAV, nadir navigation camera, ArduPilot Plane, Jetson Orin Nano Super, offline Azaion Suite Satellite Service cache, eastern/southern Ukraine terrain.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
| Criterion | Current Values | Researched Values / Evidence | Cost / Timeline Impact | Status |
|
||||
|-----------|----------------|------------------------------|------------------------|--------|
|
||||
| AC-1.1 / AC-1.2 frame-center accuracy | <=50 m for >=80%, <=20 m for >=50% in normal segments | Plausible only with periodic satellite anchoring plus VO/IMU propagation. Aerial VPR papers show the mechanism is viable but sensitive to weather, scale, repetition, and tile overlap. | High validation cost. | Keep, high-risk |
|
||||
| AC-1.3 drift | VO-only <100 m, IMU-fused <50 m between anchors, anchor age reported | Updated AC now requires `last_satellite_anchor_age_ms`, binned validation, and degraded covariance after a solution-defined max anchor age. | Medium. | Updated |
|
||||
| AC-1.4 confidence | 95% covariance ellipse + source label | `GPS_INPUT` supports accuracy fields; source labels must be carried in telemetry/FDR because `GPS_INPUT` has no semantic label field. | Medium. | Keep |
|
||||
| AC-2.1 registration | VO >95%; satellite anchoring measured separately | Split is correct: VO success is not the same as cross-domain satellite anchor success. | Medium-high. | Updated |
|
||||
| AC-2.2 reprojection | <1 px VO, <2.5 px satellite anchor | Reasonable image-space gates, with coordinate error still dependent on calibration, orthorectification, and satellite georegistration. | Medium. | Keep |
|
||||
| AC-3.x resilience | Outliers, sharp turns, disconnected segments, blackout | Technically feasible only through mode switching: VO failure triggers VPR/relocalization, blackout triggers IMU-only propagation with honest covariance growth. | High test cost. | Keep |
|
||||
| AC-4.1 latency | <400 ms p95, <=10% frame drops, heavy VPR conditional | Aerial VPR survey reports some re-ranking paths too slow for steady-state use; solution must keep global VPR off the per-frame hot path. | High optimization cost. | Updated |
|
||||
| AC-4.2 memory | <8 GB shared | Feasible if descriptors are compressed/pruned and indices are memory-mapped or loaded selectively. | Medium-high. | Keep |
|
||||
| AC-4.3 MAVLink | v1 GPS_INPUT only via pymavlink | ArduPilot docs require `GPS1_TYPE=14`; MAVLink defines required lat/lon, velocity, fix, and accuracy fields. MAVSDK should remain telemetry-oriented. | Medium. | Keep |
|
||||
| AC-5.2 failsafe | >3 s no estimate triggers fallback, Plane SITL verified | Copter docs are reference only. Plane-specific production parameters must be verified in SITL. | Medium. | Updated |
|
||||
| AC-7 object localization | Level-flight AI-camera object GPS | Realistic under level-flight clause; maneuvering estimates must publish conservative bound. | Medium. | Keep |
|
||||
| AC-8.x satellite cache | 0.3-0.5 m/px, freshness, offline descriptors, VPR chunks | Resolution is feasible through commercial/service imagery. Storage must count descriptors unless separately budgeted. | Medium-high. | Updated |
|
||||
| AC-NEW-1 / 2 startup and spoofing | <30 s first fix, <3 s promotion | Feasible only with prebuilt engines, warmed indices, and verified Plane GPS-health triggers. | Medium-high. | Keep with SITL gate |
|
||||
| AC-NEW-3 FDR | <=64 GB per flight, no raw frames | Feasible with segment files and rollover. | Medium. | Keep |
|
||||
| AC-NEW-4 / 7 safety budgets | False-position and cache-poisoning probabilities | Appropriate safety gates, but require Monte Carlo and representative flight/replay data. | High. | Keep |
|
||||
| AC-NEW-5 environment | -20 C to +50 C, 25 W for 8 h | NVIDIA confirms 25 W mode; thermal design must prevent throttling. | Medium-high. | Keep |
|
||||
|
||||
## Restrictions Assessment
|
||||
|
||||
| Restriction | Current Values | Researched Values / Evidence | Cost / Timeline Impact | Status |
|
||||
|-------------|----------------|------------------------------|------------------------|--------|
|
||||
| Camera source of truth | `restrictions.md` pins ADTi 20MP ~5472 x 3648 | User confirmed `restrictions.md` is authoritative. Lens/FOV remains a design parameter. | Medium during module selection. | Updated |
|
||||
| Fixed nadir camera | No gimbal stabilization | Good for orthorectification; turn/tilt requires attitude compensation and failure detection. | Medium. | Keep |
|
||||
| Terrain/weather | Flat steppe/agricultural, seasonal classes included | Repetitive fields and seasonal changes are VPR hazards; validation must include those classes. | High validation cost. | Updated |
|
||||
| Satellite Service boundary | Offline consumer of Suite Satellite Service | Strong separation; cache manifest and ingest-voting contract are required. | Medium. | Keep |
|
||||
| 10 GB cache | Includes imagery, manifests, overviews, descriptors unless split | Plausible at 0.5 m/px with compression; 0.3 m/px plus descriptors may exceed unless pruned. | Medium. | Updated |
|
||||
| Jetson Orin Nano Super | 67 TOPS INT8, 8 GB, 25 W | Official specs support the restriction; thermal throttling remains a risk. | Medium-high. | Keep |
|
||||
| Test data gap | Sample imagery lacks IMU/ground truth | Public datasets help prototype, but final acceptance needs synchronized representative data. | High. | Updated |
|
||||
|
||||
## Key Findings
|
||||
|
||||
1. Use a hybrid estimator: VO/IMU for frame propagation, satellite/VPR anchors for absolute correction, ESKF covariance as the safety gate.
|
||||
2. Do not run heavy VPR/re-ranking every frame; invoke it on cold start, VO failure, covariance growth, sharp turns, and disconnected segments.
|
||||
3. Avoid GPL libraries in production dependencies unless the project accepts GPL obligations. GPL VIO/SLAM tools should be benchmarks or references, not selected production components.
|
||||
4. The cache must be designed as imagery + metadata + descriptor index, not just raster tiles.
|
||||
5. ArduPilot Plane SITL and representative camera+IMU data are blocking validation dependencies, but not blockers for solution drafting.
|
||||
|
||||
## Sources
|
||||
|
||||
See `_docs/00_research/01_source_registry.md` for the detailed source list.
|
||||
@@ -0,0 +1,145 @@
|
||||
# Question Decomposition
|
||||
|
||||
## Classification
|
||||
|
||||
- **Original question**: Design a GPS-denied onboard localization system for a fixed-wing UAV using a nadir camera, IMU, preloaded satellite imagery, and ArduPilot `GPS_INPUT`.
|
||||
- **Active mode**: Mode A Phase 2, initial solution research.
|
||||
- **Research output class**: Technical-component selection.
|
||||
- **Question type**: Decision support with knowledge organization.
|
||||
- **Timeliness sensitivity**: High for VPR, embedded AI inference, and MAVLink/ArduPilot integration; medium for geometry and filtering fundamentals.
|
||||
|
||||
## Research Boundary
|
||||
|
||||
| Dimension | Boundary |
|
||||
|-----------|----------|
|
||||
| Population | Fixed-wing UAV missions; not multirotor hover workflows. |
|
||||
| Geography | Eastern/southern Ukraine operational areas east/left of the Dnipro River. |
|
||||
| Timeframe | Current implementation target with 2024-2026 component evidence where possible. |
|
||||
| Level | Onboard real-time production system, not offline post-processing. |
|
||||
| Operating context | 8 h flight, 60 km/h, <=1 km AGL, 3 fps nav camera, Jetson Orin Nano Super, GPS denied/spoofed. |
|
||||
| Required interfaces | Offline Satellite Service cache in; MAVLink `GPS_INPUT`, QGC telemetry, FDR records, and object-coordinate API out. |
|
||||
| Non-functional envelope | <400 ms p95, <8 GB shared memory, 10 GB persistent cache target, 64 GB FDR cap, safety covariance and false-position budgets. |
|
||||
|
||||
## Project Constraint Matrix Summary
|
||||
|
||||
| Constraint Area | Binding Constraint |
|
||||
|-----------------|-------------------|
|
||||
| Camera | ADTi 20MP 20L V1, APS-C, ~5472 x 3648, fixed nadir, no gimbal stabilization. |
|
||||
| Sensors | FC IMU/attitude/airspeed/altitude available over MAVLink; sample data lacks synchronized IMU. |
|
||||
| Reference imagery | Offline cache only, 0.5 m/px minimum and 0.3 m/px ideal, freshness gates, no in-flight provider fetch. |
|
||||
| Runtime | Jetson Orin Nano Super, CUDA/TensorRT available, 25 W thermal envelope. |
|
||||
| Autopilot | ArduPilot only, v1 emits `GPS_INPUT` only; ODOMETRY intentionally disabled. |
|
||||
| Storage | No raw frame retention; tiles + FDR only. Descriptor/index storage must be budgeted. |
|
||||
| Safety | Reject weak anchors, never under-report covariance, fail/degrade honestly in blackout and spoofing. |
|
||||
| Hard disqualifiers | Per-frame heavy VPR without profiling, runtime dependence on external network, stale-tile confident anchors, GPL production dependency unless licensing is accepted. |
|
||||
|
||||
## Perspectives
|
||||
|
||||
| Perspective | Focus |
|
||||
|-------------|-------|
|
||||
| Operator / mission user | Does the system keep the UAV navigable and report honest confidence under spoofing/blackout? |
|
||||
| Embedded implementer | Can the pipeline fit <400 ms p95 and <8 GB on Jetson with maintainable interfaces? |
|
||||
| Safety reviewer | Are false-position and cache-poisoning paths gated before they can steer the FC or poison future caches? |
|
||||
| Field practitioner | Will seasonal agricultural repetition, turns, haze/smoke, and stale imagery break the architecture? |
|
||||
| Contrarian | Which attractive libraries or SOTA models fail because of licensing, memory, latency, or input mismatch? |
|
||||
|
||||
## Sub-Questions And Query Variants
|
||||
|
||||
1. What architecture bounds drift while GPS is denied?
|
||||
- fixed-wing UAV GPS-denied satellite image matching visual odometry
|
||||
- visual odometry satellite imagery accumulated error fixed wing UAV
|
||||
- monocular VIO aerial navigation scale ambiguity satellite anchor
|
||||
- GPS spoofed UAV visual inertial navigation covariance failover
|
||||
|
||||
2. Which VO/VIO approach fits one nadir camera + IMU?
|
||||
- OpenVINS monocular visual inertial odometry Jetson
|
||||
- ORB-SLAM3 monocular inertial Jetson UAV limitations
|
||||
- VINS-Fusion fixed wing monocular IMU outdoor aerial
|
||||
- homography visual odometry nadir UAV IMU fusion
|
||||
|
||||
3. Which satellite retrieval and matching approach fits offline cache + <400 ms?
|
||||
- aerial visual place recognition survey DINOv2 FAISS
|
||||
- DINOv2 VLAD aerial VPR embedded memory
|
||||
- LightGlue SuperPoint DISK ALIKED TensorRT Jetson
|
||||
- cross-view UAV satellite matching failure modes farmland
|
||||
|
||||
4. How should the estimator and safety modes work?
|
||||
- ESKF visual inertial GPS denied UAV covariance
|
||||
- GPS_INPUT horiz_accuracy covariance external GPS ArduPilot
|
||||
- visual blackout IMU dead reckoning UAV covariance growth
|
||||
- false position rejection Mahalanobis gate visual localization
|
||||
|
||||
5. What cache format and data contract fit the onboard/Satellite Service boundary?
|
||||
- COG PMTiles MBTiles offline raster cache embedded
|
||||
- satellite tile descriptor index storage FAISS PMTiles
|
||||
- cloud optimized geotiff local update limitations
|
||||
- PMTiles read only update PostgreSQL/PostGIS-backed raster cache
|
||||
|
||||
6. How should MAVLink output integrate with ArduPilot Plane?
|
||||
- ArduPilot GPS_INPUT GPS1_TYPE 14 Plane SITL
|
||||
- pymavlink gps_input_send external GPS example
|
||||
- MAVSDK GPS_INPUT support raw MAVLink
|
||||
- ArduPilot EKF GPS glitch spoof failsafe Plane parameters
|
||||
|
||||
7. What validation datasets and tests are needed?
|
||||
- AerialVL UAV satellite visual localization dataset
|
||||
- VPAir aerial visual place recognition dataset
|
||||
- EuRoC MAV visual inertial odometry dataset
|
||||
- ArduPilot Plane SITL fake GPS spoofing simulation
|
||||
|
||||
## Component Option Search Plan
|
||||
|
||||
| Component Area | Option Families / Candidates | Evidence Needed |
|
||||
|----------------|------------------------------|-----------------|
|
||||
| Camera calibration and geometry | OpenCV calibration/homography; custom NumPy geometry; ROS camera pipeline | Official API for intrinsics, distortion, homography, RANSAC; permissive licensing; Jetson compatibility. |
|
||||
| VO / VIO propagation | OpenVINS, ORB-SLAM3, VINS-Fusion, custom homography+IMU ESKF | Exact monocular+IMU input fit, output pose/covariance, licensing, runtime, initialization behavior. |
|
||||
| VPR global retrieval | DINOv2-VLAD/AnyLoc, MixVPR/SALAD/SelaVPR, classical NetVLAD/BoW | Aerial benchmark evidence, descriptor size, offline index fit, embedded feasibility. |
|
||||
| Local cross-domain matching | LightGlue + DISK/ALIKED, SuperPoint+LightGlue, LoFTR/XFeat, SIFT/ORB baseline | Inputs/outputs, match coordinates, license, runtime knobs, TensorRT/Jetson feasibility. |
|
||||
| Vector index | FAISS CPU/GPU, PostgreSQL/pgvector metadata-assisted search, Annoy/HNSWLIB | Top-K retrieval, saved index, memory/compression knobs, ARM/Jetson feasibility. |
|
||||
| Estimator | Custom ESKF, factor graph, robot_localization | Covariance output, mode labels, Mahalanobis gates, source-specific update control. |
|
||||
| Cache/storage | COG, PostgreSQL/PostGIS manifest, PMTiles, MBTiles, raw tile folders | Offline read/update behavior, storage efficiency, metadata/manifest support. |
|
||||
| MAVLink integration | pymavlink, MAVSDK, MAVProxy bridge | `GPS_INPUT` support, ArduPilot `GPS1_TYPE=14`, telemetry subscriptions, QGC status. |
|
||||
| FDR | PostgreSQL event index, Parquet export, CBOR segment files | Streaming writes, rollover, compact typed records, replayability. |
|
||||
|
||||
## Completeness Audit
|
||||
|
||||
- **Cost/resources**: covered by Jetson, cache, thermal, and descriptor storage constraints.
|
||||
- **Legal/licensing**: covered; GPL VIO/SLAM tools are not selected for production.
|
||||
- **Dependencies**: Satellite Service cache contract, ArduPilot Plane SITL, and synchronized validation data are explicit dependencies.
|
||||
- **Operating environment**: fixed-wing, altitude, terrain, seasonal/visibility classes, and blackout cases covered.
|
||||
- **Failure modes**: VO failure, stale tiles, spoofing, blackout, thermal throttling, false anchors, cache poisoning covered.
|
||||
- **Practitioner concerns**: real-time embedded performance and dataset mismatch covered through survey and benchmark sources.
|
||||
- **Change over time**: DINOv2/VPR models and Jetson/TensorRT assumptions require version-pinned profiling during implementation.
|
||||
|
||||
## Mode B Round 2 Addendum — User-Requested Technology Check
|
||||
|
||||
### Research Output Class
|
||||
|
||||
Technical-component selection. The addendum verifies two implementation choices before autodev proceeds to planning:
|
||||
|
||||
1. Whether OpenVINS should replace the custom OpenCV-based VO/ESKF direction.
|
||||
2. Whether DINOv2-VLAD + ALIKED/LightGlue is still the right satellite retrieval and anchor-verification stack.
|
||||
|
||||
### Boundary Clarification
|
||||
|
||||
"Custom OpenCV" is treated as OpenCV for calibration, undistortion, feature geometry, homography/RANSAC, and MRE measurement, plus a project-owned ESKF/mode machine. It is not treated as a naive OpenCV-only replacement for VIO.
|
||||
|
||||
### Additional Query Variants Executed
|
||||
|
||||
- OpenVINS GPL-3 license MSCKF visual inertial odometry documentation monocular IMU 2026
|
||||
- OpenVINS visual inertial odometry GPS denied UAV MSCKF limitations monocular high altitude nadir camera
|
||||
- why not use OpenVINS production GPL ROS dependency visual inertial odometry limitations
|
||||
- OpenCV license BSD 3-Clause camera calibration findHomography RANSAC documentation 4.x
|
||||
- custom visual odometry OpenCV homography IMU EKF fixed wing UAV satellite imagery GPS denied 2024
|
||||
- DINOv2 VLAD AnyLoc visual place recognition aerial satellite retrieval benchmark 2024 2025
|
||||
- DINOv2 VLAD limitations visual place recognition storage compute AnyLoc limitations
|
||||
- DINOv2 TensorRT Jetson performance issue embedding accuracy visual place recognition
|
||||
- ALIKED LightGlue license local feature matching aerial image registration 2024 2025
|
||||
- ALIKED LightGlue ONNX TensorRT Jetson performance benchmark local feature matching
|
||||
- aerial visual place recognition survey 2024 runtime memory re-ranking SuperGlue LightGlue satellite UAV retrieval
|
||||
|
||||
### Addendum Conclusion
|
||||
|
||||
OpenVINS is better than a pure custom OpenCV-only VIO implementation, but the production architecture should keep OpenCV as the utility layer and keep the project-owned ESKF/mode machine as the shipped estimator. OpenVINS becomes a mandatory benchmark/reference because it does not own the satellite anchor, spoofing/blackout, source-label, cache-write, and MAVLink semantics required by the acceptance criteria, and GPLv3 remains a production dependency blocker.
|
||||
|
||||
DINOv2-VLAD + CPU-first FAISS + ALIKED/LightGlue remains the preferred anchor stack, with two non-negotiable constraints: retrieval is trigger-based rather than per-frame, and TensorRT/ONNX optimizations are accepted only after descriptor-fidelity and Jetson latency tests.
|
||||
@@ -0,0 +1,419 @@
|
||||
# Source Registry
|
||||
|
||||
## Source #1
|
||||
- **Title**: Visual Odometry in GPS-Denied Zones for Fixed-Wing UAV with Reduced Accumulative Error Based on Satellite Imagery
|
||||
- **Link**: https://www.mdpi.com/2076-3417/14/16/7420
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2024
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: UAV visual localization researchers/implementers
|
||||
- **Research Boundary Match**: Full match
|
||||
- **Summary**: Demonstrates fixed-wing high-altitude monocular VO corrected by satellite imagery; highlights scale ambiguity and accumulated drift.
|
||||
- **Related Sub-question**: Architecture / drift bounding
|
||||
|
||||
## Source #2
|
||||
- **Title**: Visual place recognition for aerial imagery: A survey
|
||||
- **Link**: https://arxiv.org/abs/2406.00885
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2024
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Aerial VPR researchers/implementers
|
||||
- **Research Boundary Match**: Full match
|
||||
- **Summary**: Reviews aerial VPR, retrieval/re-ranking, overlap/scale effects, memory/runtime issues, and georeference recall.
|
||||
- **Related Sub-question**: VPR / validation
|
||||
|
||||
## Source #3
|
||||
- **Title**: OpenVINS documentation
|
||||
- **Link**: https://docs.openvins.com/
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2023 latest noted release
|
||||
- **Timeliness Status**: Needs verification before implementation
|
||||
- **Target Audience**: VIO researchers/implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: OpenVINS is an EKF/MSCKF visual-inertial estimator supporting monocular tracking, calibration, evaluation, and covariance-aware estimation; GPL-3 license.
|
||||
- **Related Sub-question**: VO/VIO
|
||||
|
||||
## Source #4
|
||||
- **Title**: ORB-SLAM3 README
|
||||
- **Link**: https://raw.githubusercontent.com/UZ-SLAMLab/ORB_SLAM3/master/README.md
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2021 README, still repository source
|
||||
- **Timeliness Status**: Needs verification before implementation
|
||||
- **Target Audience**: SLAM implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: ORB-SLAM3 supports monocular visual-inertial SLAM and multi-map operation, requires calibration, and is GPLv3.
|
||||
- **Related Sub-question**: VO/VIO alternatives
|
||||
|
||||
## Source #5
|
||||
- **Title**: OpenCV 4.x documentation via Context7
|
||||
- **Link**: https://docs.opencv.org/4.x/
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Computer vision implementers
|
||||
- **Research Boundary Match**: Full match for utility layer
|
||||
- **Summary**: Documents camera calibration, undistortion, and `findHomography` with RANSAC for robust geometry.
|
||||
- **Related Sub-question**: Calibration / geometry
|
||||
|
||||
## Source #6
|
||||
- **Title**: LightGlue README and Context7 docs
|
||||
- **Link**: https://raw.githubusercontent.com/cvg/LightGlue/main/README.md
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current repository, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Feature-matching implementers
|
||||
- **Research Boundary Match**: Full match for local matching
|
||||
- **Summary**: LightGlue accepts local keypoints/descriptors and returns matched coordinates/scores; supports SuperPoint, DISK, ALIKED, SIFT, adaptive pruning, CUDA, and Apache-2 for code/weights while SuperPoint has restrictive licensing.
|
||||
- **Related Sub-question**: Local matching
|
||||
|
||||
## Source #7
|
||||
- **Title**: AnyLoc README
|
||||
- **Link**: https://github.com/AnyLoc/AnyLoc
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2023 repository, accessed 2026-05-01
|
||||
- **Timeliness Status**: Needs profiling verification
|
||||
- **Target Audience**: VPR implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Provides DINOv2 + VLAD API examples and notes substantial storage/compute requirements for full experiments.
|
||||
- **Related Sub-question**: VPR descriptors
|
||||
|
||||
## Source #8
|
||||
- **Title**: DINOv2 repository
|
||||
- **Link**: https://github.com/facebookresearch/dinov2
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2023 repository, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Vision model implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Meta's DINOv2 implementation and models, Apache-2.0 / CC-BY-4.0 license notices.
|
||||
- **Related Sub-question**: VPR descriptors
|
||||
|
||||
## Source #9
|
||||
- **Title**: FAISS documentation and Context7 docs
|
||||
- **Link**: https://faiss.ai/index.html
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Vector search implementers
|
||||
- **Research Boundary Match**: Full match
|
||||
- **Summary**: FAISS supports dense vector search, top-k retrieval, CPU/GPU indexes, product quantization, and save/load APIs; GPU indexes must be converted to CPU before saving.
|
||||
- **Related Sub-question**: Descriptor retrieval
|
||||
|
||||
## Source #10
|
||||
- **Title**: MAVSDK documentation via Context7
|
||||
- **Link**: https://github.com/mavlink/mavsdk
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: MAVLink application implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: MAVSDK provides telemetry APIs including raw GPS, GPS info, status text, position/velocity, and odometry subscriptions; `GPS_INPUT` emission should use raw MAVLink/pymavlink for this project.
|
||||
- **Related Sub-question**: MAVLink integration
|
||||
|
||||
## Source #11
|
||||
- **Title**: ArduPilot MAVProxy GPSInput
|
||||
- **Link**: https://ardupilot.org/mavproxy/docs/modules/GPSInput.html
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: ArduPilot integrators
|
||||
- **Research Boundary Match**: Full match
|
||||
- **Summary**: External GPS input requires `GPS1_TYPE=14` and accepts MAVLink `GPS_INPUT` fields including WGS84 lat/lon, velocity, fix type, and accuracy.
|
||||
- **Related Sub-question**: MAVLink output
|
||||
|
||||
## Source #12
|
||||
- **Title**: MAVLink common message spec: GPS_INPUT
|
||||
- **Link**: https://mavlink.io/en/messages/common.html#GPS_INPUT
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current spec, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: MAVLink implementers
|
||||
- **Research Boundary Match**: Full match
|
||||
- **Summary**: Defines `GPS_INPUT` fields, fix type semantics, `horiz_accuracy`, and ignore flags.
|
||||
- **Related Sub-question**: MAVLink output / confidence
|
||||
|
||||
## Source #13
|
||||
- **Title**: ArduPilot GPS failsafe and glitch protection
|
||||
- **Link**: https://ardupilot.org/copter/docs/gps-failsafe-glitch-protection.html
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Reference only for Plane
|
||||
- **Target Audience**: ArduPilot operators
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Documents GPS glitch protection and notes inertial-only position degrades quickly; Copter-specific defaults must not be assumed for Plane.
|
||||
- **Related Sub-question**: Failsafe / spoofing
|
||||
|
||||
## Source #14
|
||||
- **Title**: ArduPilot EKF failsafe
|
||||
- **Link**: https://ardupilot.org/copter/docs/ekf-inav-failsafe.html
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Reference only for Plane
|
||||
- **Target Audience**: ArduPilot operators
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Explains EKF variance failsafe behavior and why spoof/glitch tests must be parameterized.
|
||||
- **Related Sub-question**: Failsafe / spoofing
|
||||
|
||||
## Source #15
|
||||
- **Title**: Jetson Orin Nano Super Developer Kit
|
||||
- **Link**: https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-orin/nano-super-developer-kit/
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current page, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Embedded AI implementers
|
||||
- **Research Boundary Match**: Full match
|
||||
- **Summary**: Confirms 67 INT8 TOPS, 8 GB LPDDR5, 102 GB/s, and 7-25 W power range.
|
||||
- **Related Sub-question**: Runtime
|
||||
|
||||
## Source #16
|
||||
- **Title**: NVIDIA JetPack 6.2 Super Mode blog
|
||||
- **Link**: https://developer.nvidia.com/blog/nvidia-jetpack-6-2-brings-super-mode-to-nvidia-jetson-orin-nano-and-jetson-orin-nx-modules/
|
||||
- **Tier**: L2
|
||||
- **Publication Date**: 2024
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Jetson developers
|
||||
- **Research Boundary Match**: Full match
|
||||
- **Summary**: Explains 25 W and MAXN Super modes and warns thermal design must accommodate the new power modes or throttling occurs.
|
||||
- **Related Sub-question**: Runtime / thermal
|
||||
|
||||
## Source #17
|
||||
- **Title**: PMTiles Concepts
|
||||
- **Link**: https://docs.protomaps.com/pmtiles/
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Geospatial storage implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: PMTiles is single-file tiled archive, efficient for reads, but read-only and not update-in-place.
|
||||
- **Related Sub-question**: Cache storage
|
||||
|
||||
## Source #18
|
||||
- **Title**: GDAL COG driver
|
||||
- **Link**: https://gdal.org/en/stable/drivers/raster/cog.html
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Geospatial raster implementers
|
||||
- **Research Boundary Match**: Full match
|
||||
- **Summary**: Defines COG creation options for tiled, compressed, overview-enabled GeoTIFFs.
|
||||
- **Related Sub-question**: Cache storage
|
||||
|
||||
## Source #19
|
||||
- **Title**: AerialVL dataset
|
||||
- **Link**: https://github.com/hmf21/AerialVL
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2024
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Aerial visual localization researchers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Public aerial localization benchmark with UAV sequences, reference maps, and geo-referenced evaluation data.
|
||||
- **Related Sub-question**: Validation
|
||||
|
||||
## Source #20
|
||||
- **Title**: EuRoC MAV Dataset
|
||||
- **Link**: http://projects.asl.ethz.ch/datasets/euroc-mav/
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2016
|
||||
- **Timeliness Status**: Stable benchmark
|
||||
- **Target Audience**: VIO researchers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Stereo camera + IMU + ground truth benchmark useful for VIO sanity tests but not representative of high-altitude nadir fixed-wing imagery.
|
||||
- **Related Sub-question**: Validation
|
||||
|
||||
## Source #21
|
||||
- **Title**: NVIDIA/TensorRT issue: DINOv2 TensorRT performance/precision on Jetson
|
||||
- **Link**: https://github.com/NVIDIA/TensorRT/issues/4348
|
||||
- **Tier**: L4
|
||||
- **Publication Date**: 2024
|
||||
- **Timeliness Status**: Needs verification
|
||||
- **Target Audience**: Jetson/TensorRT implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Reports limited mixed-precision gains for DINOv2-S on Jetson/RTX, suggesting DINOv2 optimization is not automatically beneficial.
|
||||
- **Related Sub-question**: Mode B performance risk
|
||||
|
||||
## Source #22
|
||||
- **Title**: NVIDIA Developer Forum: DINOv2 TensorRT model performance issue
|
||||
- **Link**: https://forums.developer.nvidia.com/t/dinov2-tensorrt-model-performance-issue/312251
|
||||
- **Tier**: L4
|
||||
- **Publication Date**: 2024
|
||||
- **Timeliness Status**: Needs verification
|
||||
- **Target Audience**: Jetson/TensorRT implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Reports DINOv2 embedding distance changes after TensorRT conversion on Jetson Orin Nano; requires embedding-fidelity validation before relying on TensorRT descriptors.
|
||||
- **Related Sub-question**: Mode B performance/quality risk
|
||||
|
||||
## Source #23
|
||||
- **Title**: LightGlue license issue discussions
|
||||
- **Link**: https://github.com/cvg/LightGlue/issues/120
|
||||
- **Tier**: L4
|
||||
- **Publication Date**: 2024
|
||||
- **Timeliness Status**: Currently relevant
|
||||
- **Target Audience**: Feature-matching implementers
|
||||
- **Research Boundary Match**: Full match for licensing
|
||||
- **Summary**: Community discussion highlights restrictive SuperPoint licensing inside the LightGlue ecosystem and supports avoiding SuperPoint as default production extractor.
|
||||
- **Related Sub-question**: Mode B licensing risk
|
||||
|
||||
## Source #24
|
||||
- **Title**: ArduPilot issue: GPS_INPUT velocity ignore flag pitfall
|
||||
- **Link**: https://github.com/ArduPilot/ardupilot/issues/19633
|
||||
- **Tier**: L4
|
||||
- **Publication Date**: 2021
|
||||
- **Timeliness Status**: Needs SITL verification
|
||||
- **Target Audience**: ArduPilot integrators
|
||||
- **Research Boundary Match**: Full match for GPS_INPUT caution
|
||||
- **Summary**: Reports EKF3 may use zero velocity when `GPS_INPUT_IGNORE_FLAG_VEL_HORIZ` is set, so velocity-source parameters must be tested rather than relying only on ignore flags.
|
||||
- **Related Sub-question**: Mode B MAVLink pitfall
|
||||
|
||||
## Source #25
|
||||
- **Title**: FAISS install documentation
|
||||
- **Link**: https://github.com/facebookresearch/faiss/blob/main/INSTALL.md
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Vector search implementers
|
||||
- **Research Boundary Match**: Full match
|
||||
- **Summary**: FAISS CPU conda package supports aarch64, while GPU package availability is x86-64 focused; Jetson design should assume CPU FAISS unless a custom build is proven.
|
||||
- **Related Sub-question**: Mode B FAISS deployment
|
||||
|
||||
## Source #26
|
||||
- **Title**: GNSS-denied geolocalization of UAVs by visual matching of onboard camera images with orthophotos
|
||||
- **Link**: https://ar5iv.labs.arxiv.org/html/2103.14381
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2021
|
||||
- **Timeliness Status**: Stable mechanism reference
|
||||
- **Target Audience**: UAV visual geolocalization researchers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Demonstrates visual matching with orthophotos and Monte Carlo/local planarity ideas; supports using orthorectified reference maps but does not cover all adversarial visual attacks.
|
||||
- **Related Sub-question**: Mode B alternative / security limits
|
||||
|
||||
## Source #27
|
||||
- **Title**: OpenVINS LICENSE
|
||||
- **Link**: https://github.com/rpng/open_vins/blob/master/LICENSE
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current repository, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: VIO implementers / product owners
|
||||
- **Research Boundary Match**: Full match for licensing
|
||||
- **Summary**: OpenVINS is GPLv3-licensed; this is a production dependency constraint, not a technical capability limitation.
|
||||
- **Related Sub-question**: Mode B round 2 — OpenVINS vs custom production estimator
|
||||
|
||||
## Source #28
|
||||
- **Title**: OpenVINS documentation and Context7 lookup
|
||||
- **Link**: https://docs.openvins.com/index.html
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: VIO implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: OpenVINS is a strong EKF/MSCKF VIO system for monocular camera + IMU reference runs, with calibration and covariance-aware state estimation, but it does not own the project-specific satellite anchor, GPS_INPUT, source-label, spoofing, blackout, and cache-poisoning state machine.
|
||||
- **Related Sub-question**: Mode B round 2 — OpenVINS vs custom production estimator
|
||||
|
||||
## Source #29
|
||||
- **Title**: OpenCV 4.x calibration/homography documentation and Context7 lookup
|
||||
- **Link**: https://docs.opencv.org/4.x/
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Computer vision implementers
|
||||
- **Research Boundary Match**: Full match for geometry utility layer
|
||||
- **Summary**: OpenCV 4.x provides calibration, undistortion, homography estimation, RANSAC/USAC robust estimation, and reprojection-error primitives under a permissive license; it is a utility layer rather than a complete GPS-denied estimator.
|
||||
- **Related Sub-question**: Mode B round 2 — custom OpenCV boundary
|
||||
|
||||
## Source #30
|
||||
- **Title**: AnyLoc: Towards Universal Visual Place Recognition
|
||||
- **Link**: https://arxiv.org/html/2308.00688
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2023; ICRA 2024
|
||||
- **Timeliness Status**: Currently valid, profiling required before deployment
|
||||
- **Target Audience**: VPR implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: AnyLoc combines DINOv2 features with VLAD aggregation for broad VPR, including aerial data, and supports the selected DINOv2-VLAD retrieval family while leaving runtime/storage tuning as a deployment gate.
|
||||
- **Related Sub-question**: Mode B round 2 — satellite retrieval
|
||||
|
||||
## Source #31
|
||||
- **Title**: ALIKED-LightGlue-ONNX and LightGlue ONNX/TensorRT deployment reports
|
||||
- **Link**: https://github.com/ikeboo/ALIKED-LightGlue-ONNX
|
||||
- **Tier**: L2
|
||||
- **Publication Date**: Current repository, accessed 2026-05-01
|
||||
- **Timeliness Status**: Promising but needs Jetson verification
|
||||
- **Target Audience**: Local feature matching implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: ONNX/optimized variants show a credible deployment path for ALIKED + LightGlue, but public evidence is not enough to assume Jetson Orin Nano p95 latency without project profiling.
|
||||
- **Related Sub-question**: Mode B round 2 — local matcher deployability
|
||||
|
||||
## Source #32
|
||||
- **Title**: Visual place recognition for aerial imagery: A survey
|
||||
- **Link**: https://arxiv.org/abs/2406.00885
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2024
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: Aerial VPR researchers / implementers
|
||||
- **Research Boundary Match**: Full match
|
||||
- **Summary**: Aerial VPR performance depends materially on tile scale, overlap, weather, repetitive patterns, and re-ranking cost; this supports overlapped VPR chunks, dynamic top-K, and conditional local verification.
|
||||
- **Related Sub-question**: Mode B round 2 — satellite retrieval and anchor verification
|
||||
|
||||
## Source #33
|
||||
- **Title**: BASALT repository and documentation
|
||||
- **Link**: https://github.com/VladyslavUsenko/basalt
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current repository, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: VIO implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: BASALT provides visual-inertial odometry and mapping, camera/IMU calibration tools, EuRoC/TUM VI support, and a BSD-style production-friendly licensing path.
|
||||
- **Related Sub-question**: Mode B round 3 — Kimera vs BASALT vs OpenVINS
|
||||
|
||||
## Source #34
|
||||
- **Title**: HybVIO: Pushing the Limits of Real-time Visual-inertial Odometry
|
||||
- **Link**: https://arxiv.org/pdf/2106.11857
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2021
|
||||
- **Timeliness Status**: Stable benchmark reference
|
||||
- **Target Audience**: VIO researchers / embedded implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Reports EuRoC RMS ATE comparisons including BASALT mean about 0.051 m online stereo and Kimera mean about 0.12 m, plus notes that optimization-based methods often lack direct uncertainty quantification compared with filters.
|
||||
- **Related Sub-question**: Mode B round 3 — VIO error and confidence comparison
|
||||
|
||||
## Source #35
|
||||
- **Title**: OpenVINS issue #402 — up-to-date ATE and RTE metrics
|
||||
- **Link**: https://github.com/rpng/open_vins/issues/402
|
||||
- **Tier**: L4
|
||||
- **Publication Date**: 2024
|
||||
- **Timeliness Status**: Community benchmark, verify in our replay harness
|
||||
- **Target Audience**: VIO implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Community EuRoC comparison reports BASALT average ATE about 0.072 m with 100% completion, and OpenVINS average ATE about 0.091 m with about 88.55% completion and a divergence on one hard sequence.
|
||||
- **Related Sub-question**: Mode B round 3 — BASALT vs OpenVINS error/completion
|
||||
|
||||
## Source #36
|
||||
- **Title**: Kimera-VIO mono-inertial parameter issues
|
||||
- **Link**: https://github.com/MIT-SPARK/Kimera-VIO/issues/254
|
||||
- **Tier**: L4
|
||||
- **Publication Date**: 2024
|
||||
- **Timeliness Status**: Relevant implementation caveat
|
||||
- **Target Audience**: VIO implementers
|
||||
- **Research Boundary Match**: Partial overlap
|
||||
- **Summary**: Kimera-VIO stereo path remains strong, but mono-inertial configurations had documented poor default performance; parameter changes improved one EuRoC mono setup to less than about +/-0.2 m per axis.
|
||||
- **Related Sub-question**: Mode B round 3 — Kimera mono/nadir risk
|
||||
|
||||
## Source #37
|
||||
- **Title**: RaD-VIO and downward-facing VIO literature
|
||||
- **Link**: https://arxiv.org/abs/1810.08704
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: 2018
|
||||
- **Timeliness Status**: Stable mechanism reference
|
||||
- **Target Audience**: MAV downward-camera VIO researchers
|
||||
- **Research Boundary Match**: Full match for nadir-camera caveat
|
||||
- **Summary**: Downward-facing monocular VIO has planar-scene and observability challenges; range/altitude and IMU constraints are important when the camera sees mostly ground plane.
|
||||
- **Related Sub-question**: Mode B round 3 — nadir support and limitations
|
||||
|
||||
## Source #38
|
||||
- **Title**: OpenVINS covariance documentation and StateHelper APIs
|
||||
- **Link**: https://docs.openvins.com/dev-index.html
|
||||
- **Tier**: L1
|
||||
- **Publication Date**: Current docs, accessed 2026-05-01
|
||||
- **Timeliness Status**: Currently valid
|
||||
- **Target Audience**: VIO implementers
|
||||
- **Research Boundary Match**: Full match for covariance/confidence output
|
||||
- **Summary**: OpenVINS maintains EKF covariance and exposes full/marginal covariance helpers, making it the strongest reference for covariance consistency even if GPLv3 blocks default production use.
|
||||
- **Related Sub-question**: Mode B round 3 — confidence/covariance support
|
||||
@@ -0,0 +1,348 @@
|
||||
# Fact Cards
|
||||
|
||||
## Fact #1
|
||||
- **Statement**: Fixed-wing high-altitude monocular VO suffers from scale ambiguity and accumulated error; comparing against satellite imagery can reduce accumulated drift.
|
||||
- **Source**: Source #1
|
||||
- **Phase**: Phase 2
|
||||
- **Target Audience**: UAV localization implementers
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Architecture
|
||||
- **Fit Impact**: Supports satellite-anchored hybrid estimator.
|
||||
|
||||
## Fact #2
|
||||
- **Statement**: Aerial VPR is sensitive to weather, season, scale variation, repetitive patterns, and map tile construction; overlap and scale level materially affect retrieval quality.
|
||||
- **Source**: Source #2
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: VPR
|
||||
- **Fit Impact**: Supports AC-8.6 VPR chunks with overlap and seasonal validation.
|
||||
|
||||
## Fact #3
|
||||
- **Statement**: Heavy VPR re-ranking can be too slow for steady-state embedded use; survey evidence reports some re-ranking around 1 s and SuperGlue much slower on evaluated hardware.
|
||||
- **Source**: Source #2
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Runtime
|
||||
- **Fit Impact**: Disqualifies per-frame global VPR/re-ranking unless profiled on Jetson.
|
||||
|
||||
## Fact #4
|
||||
- **Statement**: OpenVINS is an EKF/MSCKF visual-inertial estimator with monocular tracking and calibration support, but its code is GPL-3.
|
||||
- **Source**: Source #3
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: VO/VIO
|
||||
- **Fit Impact**: Reference/benchmark only unless GPL obligations are accepted.
|
||||
|
||||
## Fact #5
|
||||
- **Statement**: ORB-SLAM3 supports monocular visual-inertial SLAM and multi-map operation, but it is GPLv3 and expects careful calibration and a SLAM-style runtime stack.
|
||||
- **Source**: Source #4
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: VO/VIO
|
||||
- **Fit Impact**: Rejected as production dependency; useful benchmark/reference.
|
||||
|
||||
## Fact #6
|
||||
- **Statement**: OpenCV provides camera calibration APIs that output camera matrix and distortion coefficients, and homography estimation APIs including RANSAC.
|
||||
- **Source**: Source #5
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Calibration / geometry
|
||||
- **Fit Impact**: Selected utility layer for calibration, undistortion, homography, and geometric validation.
|
||||
|
||||
## Fact #7
|
||||
- **Statement**: LightGlue accepts local keypoints/descriptors from extractors such as DISK, ALIKED, SIFT, and SuperPoint, and returns matched keypoint indices, coordinates, and confidence scores.
|
||||
- **Source**: Source #6
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Local matching
|
||||
- **Fit Impact**: Selected candidate for conditional cross-domain local matching.
|
||||
|
||||
## Fact #8
|
||||
- **Statement**: LightGlue has adaptive depth/width pruning, FlashAttention, mixed precision, and benchmark scripts; runtime must be profiled on Jetson because defaults are optimized for desktop GPUs.
|
||||
- **Source**: Source #6
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Runtime
|
||||
- **Fit Impact**: Selected with runtime-quality gate.
|
||||
|
||||
## Fact #9
|
||||
- **Statement**: LightGlue code/weights are Apache-2.0, but SuperPoint pretrained weights/inference have restrictive licensing; DISK and ALIKED are safer extractor pairings from a licensing perspective.
|
||||
- **Source**: Source #6
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Licensing
|
||||
- **Fit Impact**: Select DISK/ALIKED+LightGlue for production candidate; treat SuperPoint as license-gated.
|
||||
|
||||
## Fact #10
|
||||
- **Statement**: AnyLoc provides DINOv2 feature extraction and VLAD aggregation APIs, but its full experiment setup notes large storage/compute requirements.
|
||||
- **Source**: Source #7
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: VPR descriptors
|
||||
- **Fit Impact**: DINOv2-VLAD selected as offline/conditional retrieval candidate, not unconditional per-frame path.
|
||||
|
||||
## Fact #11
|
||||
- **Statement**: DINOv2 official repository provides Meta's DINOv2 implementation and model assets with Apache-2.0 / CC-BY-4.0 license notices.
|
||||
- **Source**: Source #8
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: VPR descriptors
|
||||
- **Fit Impact**: Supports DINOv2 as a permissible descriptor backbone subject to model-license review.
|
||||
|
||||
## Fact #12
|
||||
- **Statement**: FAISS is designed for efficient dense vector similarity search, top-k nearest-neighbor retrieval, speed/accuracy tradeoffs, and indexes too large for simple exhaustive scanning.
|
||||
- **Source**: Source #9
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Descriptor retrieval
|
||||
- **Fit Impact**: Selected vector index for offline VPR descriptors.
|
||||
|
||||
## Fact #13
|
||||
- **Statement**: FAISS supports saving/loading indexes; GPU indexes must be converted to CPU before saving.
|
||||
- **Source**: Source #9
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Cache lifecycle
|
||||
- **Fit Impact**: Supports install-time/index-build flow with runtime load.
|
||||
|
||||
## Fact #14
|
||||
- **Statement**: MAVSDK provides telemetry subscriptions for raw GPS, GPS info, status text, odometry, and position/velocity; it does not remove the need for raw MAVLink control over `GPS_INPUT` emission.
|
||||
- **Source**: Source #10
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: MAVLink integration
|
||||
- **Fit Impact**: Select MAVSDK for telemetry, pymavlink/raw MAVLink for `GPS_INPUT`.
|
||||
|
||||
## Fact #15
|
||||
- **Statement**: ArduPilot GPSInput requires `GPS1_TYPE=14` for MAVLink GPS input.
|
||||
- **Source**: Source #11
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: MAVLink output
|
||||
- **Fit Impact**: Confirms production parameter requirement.
|
||||
|
||||
## Fact #16
|
||||
- **Statement**: `GPS_INPUT` carries WGS84 lat/lon, MSL altitude, velocity, `fix_type`, `horiz_accuracy`, `vert_accuracy`, `speed_accuracy`, and ignore flags.
|
||||
- **Source**: Source #12
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Output contract
|
||||
- **Fit Impact**: Supports mapping estimator covariance to `horiz_accuracy` and failover fix types.
|
||||
|
||||
## Fact #17
|
||||
- **Statement**: ArduPilot GPS glitch protection and EKF failsafe behavior are parameterized and vehicle-specific; Copter docs are not enough to prove Plane behavior.
|
||||
- **Source**: Sources #13, #14
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Failsafe
|
||||
- **Fit Impact**: Requires ArduPilot Plane SITL validation.
|
||||
|
||||
## Fact #18
|
||||
- **Statement**: Jetson Orin Nano Super provides 67 INT8 TOPS, 8 GB memory, 102 GB/s bandwidth, and 7-25 W power range.
|
||||
- **Source**: Source #15
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Runtime
|
||||
- **Fit Impact**: Confirms target platform constraint.
|
||||
|
||||
## Fact #19
|
||||
- **Statement**: NVIDIA warns Super power modes require thermal design that can handle the power modes; otherwise throttling can reduce performance.
|
||||
- **Source**: Source #16
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Thermal
|
||||
- **Fit Impact**: Supports AC-NEW-5 hot-soak and throttle logging.
|
||||
|
||||
## Fact #20
|
||||
- **Statement**: PMTiles is efficient for single-file tile reads but is read-only and cannot be updated in place.
|
||||
- **Source**: Source #17
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Cache storage
|
||||
- **Fit Impact**: Rejected for mutable onboard tile writes; possible export/package format only.
|
||||
|
||||
## Fact #21
|
||||
- **Statement**: COG supports tiled, compressed, overview-enabled GeoTIFFs suitable for efficient raster access and geospatial tooling.
|
||||
- **Source**: Source #18
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Cache storage
|
||||
- **Fit Impact**: Selected imagery storage unit for immutable service tiles and generated candidate tiles.
|
||||
|
||||
## Fact #22
|
||||
- **Statement**: AerialVL provides aerial visual localization sequences, reference maps, and geo-referenced evaluation data.
|
||||
- **Source**: Source #19
|
||||
- **Confidence**: Medium
|
||||
- **Related Dimension**: Validation
|
||||
- **Fit Impact**: Selected validation dataset for VPR/satellite-anchor algorithm development.
|
||||
|
||||
## Fact #23
|
||||
- **Statement**: EuRoC provides synchronized camera/IMU and ground truth for VIO, but it is not representative of high-altitude fixed-wing nadir imagery.
|
||||
- **Source**: Source #20
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Validation
|
||||
- **Fit Impact**: Use for VIO sanity checks only, not final AC proof.
|
||||
|
||||
## MVE Evidence
|
||||
|
||||
### MVE — OpenCV calibration and homography utilities
|
||||
- **Source**: Source #5
|
||||
- **Pinned mode/config**: Use OpenCV 4.x C++/Python APIs for checkerboard calibration, undistortion, homography estimation with RANSAC, and reprojection-error measurement.
|
||||
- **Inputs in example**: Object/image point correspondences, image size, matched keypoints.
|
||||
- **Outputs in example**: Camera matrix, distortion coefficients, rotation/translation vectors, homography matrix.
|
||||
- **Project inputs**: ADTi nav-camera frames, checkerboard calibration images, matched VO/satellite points.
|
||||
- **Project outputs required**: Intrinsics/distortion, homography, inlier mask, MRE.
|
||||
- **Match assessment**: Exact match.
|
||||
|
||||
### MVE — LightGlue in DISK/ALIKED local-matching mode
|
||||
- **Source**: Source #6
|
||||
- **Pinned mode/config**: Use DISK+LightGlue or ALIKED+LightGlue on CUDA/TensorRT-profiled Jetson path, with inputs two normalized images and outputs matched keypoint coordinates plus confidence scores.
|
||||
- **Inputs in example**: Two images loaded to GPU; local features extracted by DISK/ALIKED/SuperPoint.
|
||||
- **Outputs in example**: `matches` shape `(K, 2)`, keypoint coordinates in each image, confidence scores.
|
||||
- **Project inputs**: Orthorectified nav frame crop and candidate satellite/VPR chunk.
|
||||
- **Project outputs required**: 2D-2D correspondences for RANSAC homography and cross-domain MRE.
|
||||
- **Match assessment**: Exact interface match; runtime quality gate remains.
|
||||
|
||||
### MVE — FAISS top-K VPR retrieval
|
||||
- **Source**: Source #9
|
||||
- **Pinned mode/config**: Use FAISS CPU index with optional GPU acceleration for top-K nearest neighbor search over precomputed DINOv2/VLAD descriptors, saved/loaded at install/preflight time.
|
||||
- **Inputs in example**: Float32 descriptor matrix, query descriptor, `k`.
|
||||
- **Outputs in example**: Distance matrix `D` and index matrix `I`.
|
||||
- **Project inputs**: Precomputed VPR chunk descriptors, query frame descriptor.
|
||||
- **Project outputs required**: Top-K candidate chunk IDs for local matching.
|
||||
- **Match assessment**: Exact match.
|
||||
|
||||
### MVE — MAVSDK telemetry + pymavlink GPS_INPUT
|
||||
- **Source**: Sources #10, #11, #12
|
||||
- **Pinned mode/config**: Use MAVSDK for telemetry subscriptions and pymavlink/raw MAVLink for `GPS_INPUT` emission to ArduPilot with `GPS1_TYPE=14`.
|
||||
- **Inputs in example**: Telemetry streams, estimator lat/lon/alt/velocity/covariance.
|
||||
- **Outputs in example**: `GPS_INPUT` fields accepted by ArduPilot GPS backend.
|
||||
- **Project inputs**: ESKF state and covariance, source label, mode/fix quality.
|
||||
- **Project outputs required**: Frame-by-frame WGS84 `GPS_INPUT`, status text, FDR record.
|
||||
- **Match assessment**: Exact match for output contract; Plane SITL validation remains.
|
||||
|
||||
## Mode B Findings
|
||||
|
||||
### Fact #24
|
||||
- **Statement**: DINOv2 TensorRT optimization on Jetson may provide limited speedup and can change embedding distances; descriptor fidelity must be tested against the PyTorch/ONNX baseline before selecting a TensorRT descriptor path.
|
||||
- **Source**: Sources #21, #22
|
||||
- **Phase**: Mode B
|
||||
- **Confidence**: Medium
|
||||
- **Related Dimension**: VPR runtime / quality
|
||||
- **Fit Impact**: Adds embedding-fidelity gate; keeps DINOv2 selected only after profiling.
|
||||
|
||||
### Fact #25
|
||||
- **Statement**: LightGlue's SuperPoint path has documented license concerns; DISK/ALIKED remain the safer production default unless legal review approves SuperPoint.
|
||||
- **Source**: Source #23
|
||||
- **Phase**: Mode B
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Licensing
|
||||
- **Fit Impact**: Confirms draft01 decision to avoid SuperPoint as default.
|
||||
|
||||
### Fact #26
|
||||
- **Statement**: ArduPilot `GPS_INPUT_IGNORE_FLAG_VEL_HORIZ` has a reported EKF3 pitfall where velocity may become zero rather than truly ignored; SITL must validate velocity-source parameters and message fields.
|
||||
- **Source**: Source #24
|
||||
- **Phase**: Mode B
|
||||
- **Confidence**: Medium
|
||||
- **Related Dimension**: MAVLink integration
|
||||
- **Fit Impact**: Adds a specific MAVLink test and parameter gate.
|
||||
|
||||
### Fact #27
|
||||
- **Statement**: FAISS deployment on Jetson ARM64 should assume CPU FAISS by default; GPU FAISS packages are not the safe default on aarch64.
|
||||
- **Source**: Source #25
|
||||
- **Phase**: Mode B
|
||||
- **Confidence**: Medium
|
||||
- **Related Dimension**: Descriptor retrieval runtime
|
||||
- **Fit Impact**: Changes FAISS pinned mode from CPU with optional GPU to CPU-first, with custom GPU build only as future optimization.
|
||||
|
||||
### Fact #28
|
||||
- **Statement**: Visual matching with orthophotos is a known GNSS-denied UAV approach, but available sources do not prove robustness against adversarial visual attacks on imagery/cache content.
|
||||
- **Source**: Source #26
|
||||
- **Phase**: Mode B
|
||||
- **Confidence**: Medium
|
||||
- **Related Dimension**: Security
|
||||
- **Fit Impact**: Adds cache integrity, signed manifests, and consistency checks as required controls.
|
||||
|
||||
### Fact #29
|
||||
- **Statement**: COG creation is a write-new-object workflow; the live onboard cache should append/replace tile objects through manifests, not mutate a COG in place.
|
||||
- **Source**: Source #18
|
||||
- **Phase**: Mode B
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Cache lifecycle
|
||||
- **Fit Impact**: Clarifies cache implementation.
|
||||
|
||||
### Fact #30
|
||||
- **Statement**: OpenVINS is technically stronger than a pure hand-rolled OpenCV-only VIO stack for camera+IMU odometry, but its GPLv3 license and generic VIO lifecycle make it unsuitable as the default production dependency for this product.
|
||||
- **Source**: Sources #27, #28
|
||||
- **Phase**: Mode B round 2
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: VO / VIO selection
|
||||
- **Fit Impact**: Use OpenVINS as a mandatory benchmark/reference, not as the shipped estimator dependency unless GPL obligations are explicitly accepted.
|
||||
|
||||
### Fact #31
|
||||
- **Statement**: The selected production estimator is not "custom OpenCV-only"; OpenCV is the geometry utility layer, while the product-owned ESKF/mode machine owns covariance, source labels, GPS spoofing, blackout, tile-write eligibility, and MAVLink semantics.
|
||||
- **Source**: Sources #5, #29; AC-1.4, AC-3.5, AC-4.3, AC-NEW-4, AC-NEW-7, AC-NEW-8
|
||||
- **Phase**: Mode B round 2
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Estimator ownership
|
||||
- **Fit Impact**: Keep custom production estimator, but reject any interpretation that means building a naive OpenCV-only VIO stack.
|
||||
|
||||
### Fact #32
|
||||
- **Statement**: Fixed-wing GPS-denied UAV research supports a hybrid of visual odometry plus satellite/orthophoto matching to reduce accumulated drift, matching the project architecture better than a standalone VIO-only solution.
|
||||
- **Source**: Sources #1, #26
|
||||
- **Phase**: Mode B round 2
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Architecture
|
||||
- **Fit Impact**: Confirms that OpenVINS alone cannot satisfy the absolute-position and re-anchor responsibilities without the satellite anchor path.
|
||||
|
||||
### Fact #33
|
||||
- **Statement**: DINOv2-VLAD/AnyLoc-style retrieval is a strong global candidate generator for aerial VPR, but descriptor size, model size, and environment-specific VLAD/index choices must be budgeted and profiled.
|
||||
- **Source**: Sources #7, #30, #32
|
||||
- **Phase**: Mode B round 2
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Satellite retrieval
|
||||
- **Fit Impact**: Select DINOv2-VLAD for triggered retrieval, not steady-state per-frame execution.
|
||||
|
||||
### Fact #34
|
||||
- **Statement**: Aerial VPR sources emphasize tile/chunk scale, overlap, weather/season changes, repetitive patterns, and re-ranking cost; local matching should be a verification/rerank stage over bounded top-K candidates.
|
||||
- **Source**: Source #32
|
||||
- **Phase**: Mode B round 2
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Anchor verification
|
||||
- **Fit Impact**: Supports VPR chunks with 40-50% overlap, dynamic K, and conditional ALIKED/LightGlue verification.
|
||||
|
||||
### Fact #35
|
||||
- **Statement**: ALIKED + LightGlue has an exact local matching interface and a plausible ONNX/TensorRT deployment path, but public evidence does not prove Jetson Orin Nano p95 latency for the project image sizes.
|
||||
- **Source**: Sources #6, #31
|
||||
- **Phase**: Mode B round 2
|
||||
- **Confidence**: Medium
|
||||
- **Related Dimension**: Local matching runtime
|
||||
- **Fit Impact**: Keep ALIKED/LightGlue selected with runtime gate; benchmark DISK and SIFT/ORB as fallbacks.
|
||||
|
||||
### Fact #36
|
||||
- **Statement**: DINOv2 TensorRT conversion can reduce embedding discrimination and may not provide meaningful speedup on Jetson-class devices; descriptor-fidelity tests must precede any optimized engine acceptance.
|
||||
- **Source**: Source #22
|
||||
- **Phase**: Mode B round 2
|
||||
- **Confidence**: Medium
|
||||
- **Related Dimension**: VPR deployment
|
||||
- **Fit Impact**: TensorRT is an optimization candidate only after PyTorch/ONNX retrieval-rank equivalence is proven.
|
||||
|
||||
### Fact #37
|
||||
- **Statement**: BASALT is the best production VIO candidate among BASALT, OpenVINS, and Kimera-VIO because it combines permissive licensing with strong published EuRoC accuracy and completion evidence.
|
||||
- **Source**: Sources #33, #34, #35
|
||||
- **Phase**: Mode B round 3
|
||||
- **Confidence**: Medium
|
||||
- **Related Dimension**: VO / VIO selection
|
||||
- **Fit Impact**: Select BASALT as the production VIO candidate, pending project replay/profiling.
|
||||
|
||||
### Fact #38
|
||||
- **Statement**: OpenVINS has the clearest EKF covariance story, including full/marginal covariance helpers and NEES-style evaluation support, but remains production-constrained by GPLv3.
|
||||
- **Source**: Sources #27, #28, #38
|
||||
- **Phase**: Mode B round 3
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Confidence / covariance
|
||||
- **Fit Impact**: Keep OpenVINS as covariance/reference baseline and use it to calibrate the BASALT wrapper's reported uncertainty.
|
||||
|
||||
### Fact #39
|
||||
- **Statement**: Kimera-VIO is production-friendly from a license standpoint, but it is heavier/stereo-oriented and has documented mono-inertial parameter/performance caveats.
|
||||
- **Source**: Sources #34, #36
|
||||
- **Phase**: Mode B round 3
|
||||
- **Confidence**: Medium
|
||||
- **Related Dimension**: VO / VIO fallback
|
||||
- **Fit Impact**: Keep Kimera-VIO as a backup candidate, not the first production choice for a single fixed nadir camera.
|
||||
|
||||
### Fact #40
|
||||
- **Statement**: None of BASALT, OpenVINS, or Kimera-VIO provides a special fixed-wing nadir mode; downward-camera support depends on accurate camera-to-IMU extrinsics, altitude/scale constraints, and validation under low-parallax planar terrain.
|
||||
- **Source**: Source #37
|
||||
- **Phase**: Mode B round 3
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Nadir-camera support
|
||||
- **Fit Impact**: The architecture must keep satellite anchors and project-level confidence gates regardless of which VIO library is selected.
|
||||
|
||||
### Fact #41
|
||||
- **Statement**: Published EuRoC-type VIO error rates are useful for ranking libraries but are not acceptance evidence for high-altitude fixed-wing nadir imagery over agricultural terrain.
|
||||
- **Source**: Sources #34, #35, #37
|
||||
- **Phase**: Mode B round 3
|
||||
- **Confidence**: High
|
||||
- **Related Dimension**: Validation
|
||||
- **Fit Impact**: Require representative replay/flight data before claiming AC-1/AC-2 accuracy.
|
||||
@@ -0,0 +1,55 @@
|
||||
# Comparison Framework
|
||||
|
||||
## Selected Framework Type
|
||||
|
||||
Decision support with exact-fit component selection.
|
||||
|
||||
## Selected Dimensions
|
||||
|
||||
1. Required inputs/outputs and ownership boundaries
|
||||
2. Operating context and lifecycle fit
|
||||
3. Non-functional envelope fit: latency, memory, storage, thermal, safety
|
||||
4. Licensing and deployability
|
||||
5. Evidence quality and validation burden
|
||||
6. Security and safety failure modes
|
||||
7. Selection status
|
||||
|
||||
## Initial Population
|
||||
|
||||
| Component Area | Candidate | Option Family | Inputs / Outputs | Fit Summary | Status |
|
||||
|----------------|-----------|---------------|------------------|-------------|--------|
|
||||
| Calibration / geometry | OpenCV 4.x | Established production / open-source | image/object points -> intrinsics, distortion, homography, inlier mask | Exact utility fit; permissive production use. | Selected |
|
||||
| VO / VIO | BASALT + project-owned safety/anchor wrapper | Open-source production candidate | nav frames + FC IMU/calibration -> relative VIO state; wrapper adds source labels, anchor fusion, calibrated confidence, and MAVLink semantics | Best production candidate after user decision: permissive license, strong benchmark evidence, and lower implementation burden than custom VIO. | Selected |
|
||||
| VO / VIO | OpenVINS | Open-source research | monocular camera + IMU -> VIO state/covariance | Best covariance/reference story, but GPL-3 and generic VIO ownership make it a benchmark/reference rather than shipped core. | Reference only |
|
||||
| VO / VIO | Kimera-VIO | Open-source production candidate / fallback | mono or stereo camera + IMU -> VIO/SLAM outputs | BSD-friendly, but heavier/stereo-oriented and mono-inertial path has documented parameter caveats. | Backup candidate |
|
||||
| VO / VIO | OpenCV geometry + project-owned ESKF | Custom fallback | nav frames + FC IMU/attitude/altitude + satellite anchors -> relative motion, absolute updates, covariance, source labels | Fallback if BASALT fails project data/runtime tests; still needed as safety/anchor wrapper around any VIO library. | Fallback / wrapper |
|
||||
| VO / VIO | ORB-SLAM3 | Open-source research | monocular/stereo/RGB-D + optional IMU -> SLAM pose | Useful benchmark; GPLv3, map runtime, and initialization complexity make it poor production dependency. | Rejected for production |
|
||||
| Global retrieval | DINOv2-VLAD / AnyLoc-style descriptors | Current SOTA / research | image/chunk -> descriptor | Strong VPR evidence; trigger-only use due runtime/memory and TensorRT fidelity risk. | Selected with runtime gate |
|
||||
| Vector retrieval | FAISS | Established production / open-source | descriptor matrix + query -> top-K IDs | Exact fit for offline VPR chunk retrieval. | Selected |
|
||||
| Local matching | LightGlue + DISK/ALIKED | Current SOTA / open-source | two images -> keypoint correspondences/scores | Exact local-match interface; avoids SuperPoint license issue. | Selected with runtime gate |
|
||||
| Local matching | SuperPoint + LightGlue | Current SOTA / known-bad/licensing caveat | two images -> matches | Technically good; licensing requires explicit review. | Needs user decision / fallback only |
|
||||
| Cache imagery | COG + manifest + sidecars | Established geospatial format | georeferenced raster + metadata -> efficient local reads | Good immutable tile unit; generated tiles can be written as new COGs. | Selected |
|
||||
| Cache packaging | PMTiles | Established web-map archive | tile pyramid -> single archive | Efficient reads, but read-only; not suitable for in-flight mutable writes. | Rejected for mutable cache |
|
||||
| Estimator | Custom ESKF mode machine | Custom production | VO/IMU/VPR/GPS-health -> WGS84 state + covariance + label | Needed for source labels, covariance gates, blackout/spoofing behavior. | Selected |
|
||||
| MAVLink integration | MAVSDK + pymavlink | Established APIs | telemetry in, `GPS_INPUT` out | MAVSDK handles telemetry; pymavlink handles raw `GPS_INPUT`. | Selected |
|
||||
| FDR | PostgreSQL event index + CBOR payload segments with optional Parquet export | Established storage | frame estimates, IMU, MAVLink, health, tiles -> bounded replayable log | Matches project PostgreSQL choice while keeping compact append payloads. | Selected pattern |
|
||||
| Validation | AerialVL + EuRoC + Plane SITL + representative flight | Multi-source test strategy | datasets/sim/flight -> AC evidence | Public data is partial; final representative data is mandatory. | Selected |
|
||||
|
||||
## Round 2 Decision Notes
|
||||
|
||||
- **OpenVINS vs custom OpenCV**: OpenVINS wins if the comparison is against a naive OpenCV-only VIO implementation. The selected design is not that; it is OpenCV geometry plus a product-owned estimator/state machine, with OpenVINS used as a benchmark/reference.
|
||||
- **Satellite retrieval**: DINOv2-VLAD remains the best global candidate generator found, but aerial VPR sources require chunk scale/overlap tuning, dynamic top-K, and geometric verification.
|
||||
- **Anchor verification**: ALIKED/LightGlue remains the preferred learned local matcher, while SIFT/ORB stays as a regression/fallback baseline and SuperPoint remains license-gated.
|
||||
|
||||
## Round 3 Decision Notes
|
||||
|
||||
- **User decision**: BASALT is selected as the production VIO candidate.
|
||||
- **Confidence/covariance**: OpenVINS remains the covariance/reference baseline because its EKF exposes clearer uncertainty semantics than BASALT/Kimera.
|
||||
- **Nadir support**: no compared VIO library has a special fixed-wing nadir mode; the acceptance path is calibration, altitude/scale constraints, satellite anchors, and representative replay validation.
|
||||
|
||||
## Baseline Alignment
|
||||
|
||||
- "Position estimate" means WGS84 frame center emitted to FC plus a 95% covariance semi-major axis and source label.
|
||||
- "Satellite anchored" means a visual match passed VPR retrieval, local matching, RANSAC, freshness, covariance, and Mahalanobis gates.
|
||||
- "Normal flight segment" means the AC-2.1a conditions, not turns/blackout/stale imagery.
|
||||
- "Selected with runtime gate" means the API capability fits, but final deployment depends on Jetson profiling against AC-4.1 and AC-4.2.
|
||||
@@ -0,0 +1,181 @@
|
||||
# Reasoning Chain
|
||||
|
||||
## Dimension 1: Core Architecture
|
||||
|
||||
### Fact Confirmation
|
||||
|
||||
Fixed-wing monocular VO accumulates drift because scale and terrain assumptions are imperfect (Fact #1). Aerial VPR can provide absolute anchors but has weather, scale, and repetition failure modes (Fact #2).
|
||||
|
||||
### Reference Comparison
|
||||
|
||||
Pure VO/IMU cannot satisfy the long 8-hour mission. Pure satellite matching cannot run every frame inside the latency budget and will fail in turns, stale imagery, and repetitive fields.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Select a hybrid architecture: steady-state VO/IMU propagation, conditional satellite/VPR anchoring, and ESKF covariance gates.
|
||||
|
||||
### Confidence
|
||||
|
||||
High. Supported by Sources #1 and #2.
|
||||
|
||||
## Dimension 2: VO / VIO Dependency
|
||||
|
||||
### Fact Confirmation
|
||||
|
||||
OpenVINS and ORB-SLAM3 both support visual-inertial estimation patterns, but both are GPL-family production dependency risks (Facts #4 and #5).
|
||||
|
||||
### Reference Comparison
|
||||
|
||||
The project needs a production system with custom mode labels, covariance propagation, MAVLink-specific output behavior, and no hidden GPL obligation. A full SLAM stack also adds initialization and map-management complexity that the ACs do not require.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Use a custom VO/IMU propagation and ESKF mode machine for production. Use OpenVINS/ORB-SLAM3 only as benchmarks/reference algorithms.
|
||||
|
||||
### Confidence
|
||||
|
||||
High for licensing/scope decision; medium for final estimator performance until prototype profiling.
|
||||
|
||||
## Dimension 3: Satellite Retrieval And Local Matching
|
||||
|
||||
### Fact Confirmation
|
||||
|
||||
Aerial VPR benefits from scale/overlap-aware chunks and retrieval + local alignment (Fact #2). LightGlue provides keypoint correspondences/scores from local descriptors (Fact #7). FAISS provides top-K retrieval over descriptors (Fact #12).
|
||||
|
||||
### Reference Comparison
|
||||
|
||||
Global DINOv2/VLAD retrieval alone gives candidate chunks but not enough precision for AC-2.2. Local matching alone over the whole map is too expensive. The two-stage retrieval+alignment structure matches the operational need.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Use DINOv2-VLAD descriptors with FAISS top-K for conditional candidate retrieval, followed by DISK/ALIKED+LightGlue and OpenCV RANSAC homography for local alignment.
|
||||
|
||||
### Confidence
|
||||
|
||||
Medium-high. API fit is strong; embedded runtime must be profiled.
|
||||
|
||||
## Dimension 4: Latency And Memory
|
||||
|
||||
### Fact Confirmation
|
||||
|
||||
Some aerial VPR re-ranking methods are too slow for the steady-state path (Fact #3). Jetson Orin Nano Super has 8 GB shared memory and 25 W power mode (Fact #18), with thermal throttling risk (Fact #19).
|
||||
|
||||
### Reference Comparison
|
||||
|
||||
At 3 fps and <400 ms p95, the system can process every frame through lightweight VO/IMU and use heavier VPR only on triggers. Running DINOv2/LightGlue across many candidates per frame would violate the AC unless proven otherwise.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Make VPR conditional, cap top-K by covariance/sector, run descriptor extraction on downsampled/orthorectified crops, precompute cache descriptors offline, and add performance regression tests.
|
||||
|
||||
### Confidence
|
||||
|
||||
High for architecture direction; exact model sizes need profiling.
|
||||
|
||||
## Dimension 5: Cache Format
|
||||
|
||||
### Fact Confirmation
|
||||
|
||||
COG supports tiled compressed rasters and geospatial tooling (Fact #21). PMTiles is read-efficient but read-only (Fact #20).
|
||||
|
||||
### Reference Comparison
|
||||
|
||||
The onboard system must both read service tiles and write new generated tiles in-flight. A read-only archive is a poor primary mutable store.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Use COG files plus STAC-like manifests/sidecars for imagery and metadata; use FAISS sidecar indexes for descriptors. PMTiles may be an export/snapshot format, not the live mutable cache.
|
||||
|
||||
### Confidence
|
||||
|
||||
High.
|
||||
|
||||
## Dimension 6: Autopilot Integration
|
||||
|
||||
### Fact Confirmation
|
||||
|
||||
ArduPilot MAVLink GPS input requires `GPS1_TYPE=14` (Fact #15). `GPS_INPUT` carries the fields needed for WGS84 position and accuracy (Fact #16). MAVSDK covers telemetry but raw `GPS_INPUT` emission still needs pymavlink/raw MAVLink (Fact #14).
|
||||
|
||||
### Reference Comparison
|
||||
|
||||
MAVSDK-only output would not satisfy AC-4.3. Raw pymavlink-only telemetry is possible but gives up MAVSDK's high-level subscriptions.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Use MAVSDK for telemetry subscriptions and pymavlink for `GPS_INPUT` emission. Verify all failsafe/spoofing behavior in ArduPilot Plane SITL.
|
||||
|
||||
### Confidence
|
||||
|
||||
High for interface; medium for exact Plane failsafe timing until SITL.
|
||||
|
||||
## Dimension 7: Validation
|
||||
|
||||
### Fact Confirmation
|
||||
|
||||
AerialVL provides aerial localization/reference-map data (Fact #22). EuRoC provides camera+IMU+ground truth but not fixed-wing nadir imagery (Fact #23). The current sample set lacks IMU/ground truth.
|
||||
|
||||
### Reference Comparison
|
||||
|
||||
No single public dataset proves every AC. Public datasets can de-risk components, while final acceptance requires representative synchronized flight/replay data.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Use layered validation: EuRoC for VIO sanity, AerialVL/VPAir-style data for VPR/anchor tests, ArduPilot Plane SITL for MAVLink/failsafe/spoofing, and a final representative flight/replay rig for AC proof.
|
||||
|
||||
### Confidence
|
||||
|
||||
High.
|
||||
|
||||
## Dimension 8: OpenVINS vs Project-Owned Estimator
|
||||
|
||||
### Fact Confirmation
|
||||
|
||||
OpenVINS is a strong monocular+IMU EKF/MSCKF VIO reference with covariance-aware estimation (Facts #4 and #30). OpenCV supplies calibration, undistortion, homography, RANSAC/USAC, and reprojection-error primitives, but it is not a full estimator by itself (Facts #6 and #31).
|
||||
|
||||
### Reference Comparison
|
||||
|
||||
If the alternative is a naive OpenCV-only VIO stack, OpenVINS is the better technical starting point. The project's actual production choice is different: it needs a project-owned ESKF/mode machine that fuses VO/IMU, accepts/rejects satellite anchors, emits `GPS_INPUT`, labels every estimate, handles spoofing/blackout, and gates cache write-back.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Keep OpenVINS as a mandatory benchmark/reference implementation, not as the default production dependency. The production estimator remains project-owned, with OpenCV as the geometry utility layer.
|
||||
|
||||
### Confidence
|
||||
|
||||
High. The technical comparison favors OpenVINS over naive custom VIO, while the product fit favors the project-owned estimator.
|
||||
|
||||
## Dimension 9: Satellite Retrieval And Anchor Verification
|
||||
|
||||
### Fact Confirmation
|
||||
|
||||
DINOv2-VLAD/AnyLoc-style retrieval has strong VPR evidence but descriptor/model size and TensorRT fidelity must be validated (Facts #33 and #36). Aerial VPR survey evidence emphasizes tile scale, overlap, season/weather shifts, repetitive patterns, and re-ranking cost (Fact #34). LightGlue supports ALIKED/DISK/SIFT feature matching and returns correspondences/scores suitable for RANSAC verification, but Jetson latency must be profiled (Facts #7, #8, #35).
|
||||
|
||||
### Reference Comparison
|
||||
|
||||
Classical SIFT/ORB is simpler and cheap but weaker for cross-domain UAV-to-satellite matching. SuperPoint+LightGlue is technically strong but remains license-gated. Pure global retrieval without local verification is unsafe because repetitive farmland and stale imagery can produce plausible but wrong candidates.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Use DINOv2-VLAD + CPU-first FAISS as the triggered global retriever, then verify bounded top-K candidates with ALIKED/LightGlue + OpenCV RANSAC. Keep SIFT/ORB as a regression baseline and SuperPoint only after legal approval.
|
||||
|
||||
### Confidence
|
||||
|
||||
High for architecture and interfaces; medium for final runtime until Jetson profiling.
|
||||
|
||||
## Dimension 10: BASALT vs Kimera-VIO vs OpenVINS
|
||||
|
||||
### Fact Confirmation
|
||||
|
||||
BASALT has strong published EuRoC evidence and production-friendly licensing (Fact #37). OpenVINS has the clearest EKF covariance API and consistency tooling, but GPLv3 remains a production constraint (Fact #38). Kimera-VIO is BSD-friendly but heavier and has documented mono-inertial caveats (Fact #39). All three require calibrated camera-to-IMU extrinsics; none has a special fixed-wing nadir mode (Fact #40).
|
||||
|
||||
### Reference Comparison
|
||||
|
||||
For a single fixed downward camera, the selection criterion is not just benchmark ATE. The project needs a VIO core that can run on Jetson, tolerate calibrated nadir geometry, and be wrapped by project-specific satellite-anchor, confidence, MAVLink, and safety logic. OpenVINS is attractive for confidence/covariance but problematic as a shipped component. Kimera is acceptable as a BSD fallback, but mono-inertial risk makes it weaker as the first pick. BASALT provides the best production trade-off if its uncertainty can be calibrated and wrapped.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Select BASALT as the production VIO candidate. Keep OpenVINS as a reference/covariance baseline and Kimera-VIO as a backup candidate. The project-owned safety/anchor wrapper remains mandatory around BASALT because BASALT alone does not satisfy GPS-denied source labels, satellite anchors, false-position budgets, cache-write gates, or `GPS_INPUT` behavior.
|
||||
|
||||
### Confidence
|
||||
|
||||
Medium-high. Library ranking is well supported; final acceptance still depends on representative fixed-wing nadir replay data.
|
||||
@@ -0,0 +1,51 @@
|
||||
# Validation Log
|
||||
|
||||
## Validation Scenario
|
||||
|
||||
An 8-hour fixed-wing mission enters GPS-denied/spoofed mode after takeoff. The onboard system starts from last trusted FC state, processes 3 fps nadir frames, emits `GPS_INPUT`, handles normal flight, sharp turns, short visual blackouts, stale/changed tiles, and post-flight tile write-back.
|
||||
|
||||
## Expected Based On Conclusions
|
||||
|
||||
- **Normal segment**: VO/IMU propagates every processed frame; satellite anchors refresh state conditionally before covariance grows too large.
|
||||
- **Sharp turn / <5% overlap**: VO is expected to fail; relocalization uses FAISS top-K VPR chunks followed by LightGlue/RANSAC.
|
||||
- **Visual blackout + spoofing**: estimator switches to `dead_reckoned`, covariance grows monotonically, spoofed GPS is ignored, `GPS_INPUT` degrades honestly.
|
||||
- **Stale tile**: anchor is rejected or down-confidence weighted and cannot emit `satellite_anchored`.
|
||||
- **Cache write-back**: onboard generated tile is written only when parent-pose covariance passes AC-NEW-7 gates and carries metadata for Satellite Service voting.
|
||||
|
||||
## Actual Validation Plan
|
||||
|
||||
| Validation Target | Test Method | Pass Evidence |
|
||||
|-------------------|-------------|---------------|
|
||||
| VO/VIO propagation | EuRoC and synthetic nadir replay; then representative flight data | Drift vs anchor-age bins; AC-1.3 pass/fail. |
|
||||
| Satellite anchor | AerialVL/VPAir-style benchmark plus project sample imagery with satellite cache | AC-1.1/1.2 accuracy, AC-2.2 MRE, georeference recall. |
|
||||
| Runtime | Jetson Orin Nano Super profiling under 25 W, hot-soak included | <400 ms p95, <8 GB memory, no thermal throttle. |
|
||||
| VPR retrieval | Offline descriptor build and FAISS query benchmark | Top-K recall, query latency, index size within cache budget. |
|
||||
| MAVLink output | ArduPilot Plane SITL with `GPS1_TYPE=14` | Valid `GPS_INPUT`, fix-type/accuracy degradation, QGC status. |
|
||||
| Spoofing promotion | Plane SITL false GPS injection | Promotion <3 s and spoofed GPS rejected during blackout. |
|
||||
| FDR | 8-hour synthetic load | <=64 GB, rollover logged, no silent payload loss. |
|
||||
| Cache poisoning | Monte Carlo with over-confident wrong anchors | AC-NEW-7 probabilities below budget; metadata contract emitted. |
|
||||
| OpenVINS reference comparison | Replay the same synchronized camera+IMU segments through OpenVINS and the project-owned estimator | OpenVINS establishes a VIO baseline; production estimator must match/beat drift where applicable while preserving source labels and GPS_INPUT behavior. |
|
||||
| BASALT production VIO candidate | Replay synchronized camera+IMU segments through BASALT, OpenVINS, and Kimera-VIO | BASALT selected if drift, completion rate, latency, and wrapper-calibrated covariance meet project gates. |
|
||||
| DINOv2-VLAD fidelity | Compare PyTorch, ONNX, and TensorRT descriptor distances and FAISS rankings | Optimized engines accepted only if rank/top-K behavior stays within tolerance. |
|
||||
| ALIKED/LightGlue runtime | Jetson benchmark across K candidates and project image sizes | Candidate accepted for runtime only if relocalization trigger path fits AC-4.1 with bounded frame drops. |
|
||||
|
||||
## Counterexamples And Risks
|
||||
|
||||
- Large DINOv2 variants or many local-match candidates may violate the Jetson latency/memory envelope.
|
||||
- Agricultural fields can be visually repetitive; VPR confidence must not be treated as sufficient without geometric verification.
|
||||
- Public datasets do not fully match Ukrainian fixed-wing operational conditions; final evidence requires representative data.
|
||||
- GPL VIO/SLAM libraries are not production dependencies unless licensing is explicitly accepted.
|
||||
- OpenVINS may outperform the first custom estimator prototype on pure VIO drift; that would trigger estimator improvement, not automatic GPL production adoption.
|
||||
- BASALT covariance/confidence is less directly exposed than OpenVINS EKF covariance; the project wrapper must calibrate uncertainty before mapping it to `GPS_INPUT.horiz_accuracy`.
|
||||
|
||||
## Review Checklist
|
||||
|
||||
- [x] Draft conclusions are consistent with fact cards.
|
||||
- [x] No important dimensions missed: architecture, VO, VPR, local matching, cache, estimator, MAVLink, FDR, validation covered.
|
||||
- [x] No selected component relies only on field-adjacent fit.
|
||||
- [x] Mismatches are recorded as rejected/reference/needs-decision rather than hidden.
|
||||
- [x] Step 7.5 Component Applicability Gate applies and is saved in `06_component_fit_matrix.md`.
|
||||
|
||||
## Conclusions Requiring Revision
|
||||
|
||||
Round 3 applies the user decision to select BASALT as the production VIO candidate. The selected implementation is BASALT VIO plus a project-owned safety/anchor wrapper; OpenVINS remains the covariance/reference baseline, Kimera-VIO remains a backup candidate, and custom OpenCV-only VIO is no longer the primary path. Runtime gates and Plane SITL gates are implementation validation gates, not API capability blockers.
|
||||
@@ -0,0 +1,107 @@
|
||||
# Component Fit Matrix
|
||||
|
||||
## Top-Level Matrix
|
||||
|
||||
| Component Area | Candidate | Pinned Mode/Config | Option Family | Intended Role | API Capability Evidence | Mismatches / Disqualifiers | Status | Decision Rationale |
|
||||
|----------------|-----------|--------------------|---------------|---------------|-------------------------|----------------------------|--------|--------------------|
|
||||
| Calibration / geometry | OpenCV 4.x | C++/Python calibration, undistortion, RANSAC homography, reprojection-error measurement | Established production / open-source | Camera intrinsics, image normalization, VO/satellite homography verification | MVE: `02_fact_cards.md` OpenCV block; Source #5 | None | Selected | Exact API fit and permissive utility role. |
|
||||
| VO / IMU propagation | BASALT + project-owned safety/anchor wrapper | BASALT VIO consumes calibrated nav-camera frames + FC IMU; wrapper fuses satellite anchors, calibrates uncertainty, emits source labels and GPS_INPUT semantics | Open-source production candidate | Relative VIO state, completion/error benchmark, wrapped covariance/confidence, degraded modes, GPS_INPUT semantics | Sources #33-#35; Facts #37, #40, #41 | BASALT covariance/confidence must be calibrated in wrapper; no special nadir mode | Selected | User-selected best production trade-off: permissive licensing and stronger benchmark/completion evidence than OpenVINS/Kimera, with wrapper covering project-specific safety semantics. |
|
||||
| VO / VIO reference | OpenVINS | Monocular camera + IMU EKF/MSCKF reference runs with covariance extraction | Open-source research | Benchmark and covariance reference | Sources #3, #27, #28, #35, #38; Facts #4, #30, #38 | GPL-3 production dependency risk; completion/divergence risk on some sequences; does not own satellite anchor / GPS_INPUT / blackout / cache-write state machine | Reference only | Best covariance baseline, but not selected as shipped production dependency. |
|
||||
| VO / VIO backup | Kimera-VIO | Mono/stereo camera + IMU VIO/SLAM backup candidate | Open-source production candidate / fallback | Alternative VIO baseline | Sources #34, #36; Fact #39 | Heavier/stereo-oriented; mono-inertial path has documented parameter caveats | Backup candidate | BSD-friendly backup if BASALT fails project replay/runtime gates. |
|
||||
| VO / SLAM alternative | ORB-SLAM3 | Monocular-inertial SLAM | Open-source research | Benchmark and failure-mode comparison | Source #4, Fact #5 | GPLv3; heavier SLAM/map lifecycle than required | Rejected | Does not fit licensing/scope for production. |
|
||||
| VPR descriptors | DINOv2-VLAD / AnyLoc-style | Precomputed satellite chunk descriptors; conditional query descriptor on relocalization triggers; TensorRT path only after embedding-fidelity check | Current SOTA / research | Global top-K candidate retrieval | Sources #7, #8, #21, #22, #30, #32; Facts #10, #11, #24, #33, #34, #36 | Runtime and embedding-fidelity gates on Jetson; model-size/index-size selection required | Selected with runtime gate | Best evidence for change-robust VPR, but not per-frame and not blindly TensorRT-converted. |
|
||||
| Vector retrieval | FAISS | CPU-first aarch64 index; saved/loaded index over float/PQ descriptors; GPU only if custom Jetson build is proven | Established production / open-source | Top-K candidate chunk search | MVE: `02_fact_cards.md` FAISS block; Sources #9, #25 | GPU FAISS not default on Jetson ARM64 | Selected | Exact top-K descriptor retrieval fit with CPU-first deployment. |
|
||||
| Local matching | LightGlue + DISK/ALIKED | CUDA/ONNX-profiled DISK or ALIKED feature extraction + LightGlue matching on bounded top-K candidates | Current SOTA / open-source | 2D-2D correspondences for RANSAC and MRE | MVE: `02_fact_cards.md` LightGlue block; Sources #6, #23, #31 | Runtime quality gate; extractor choice must avoid SuperPoint license issue | Selected with runtime gate | Exact input/output fit with deployable licensing path; ALIKED/LightGlue is preferred for anchor verification. |
|
||||
| Local matching fallback | SuperPoint + LightGlue | SuperPoint features + LightGlue | Current SOTA / license-gated | Optional benchmark/fallback | Source #6 | SuperPoint restrictive license | Needs user decision | Do not use as default production dependency without legal review. |
|
||||
| Cache imagery | COG + manifest/sidecar | Tiled compressed GeoTIFF tile objects with CRS, capture date, source, m/px, freshness, descriptor sidecars; write-new-object lifecycle | Established geospatial format | Immutable service tiles and generated candidate tiles | Source #18, Facts #21, #29 | No in-place mutation; manifest manages active tile version | Selected | Fits geospatial raster access and write-new-tile workflow. |
|
||||
| Cache packaging | PMTiles | Read-only tile archive | Established web-map archive | Optional export/snapshot | Source #17, Fact #20 | Cannot update in place | Rejected for live cache | In-flight tile generation needs mutable write-new objects. |
|
||||
| MAVLink | MAVSDK + pymavlink | MAVSDK telemetry subscriptions; pymavlink/raw MAVLink `GPS_INPUT` emission to ArduPilot `GPS1_TYPE=14`; velocity source/ignore-flag behavior SITL-tested | Established APIs | FC telemetry, QGC status, GPS substitute output | MVE: `02_fact_cards.md` MAVSDK/pymavlink block; Sources #10-#12, #24 | Plane SITL behavior and velocity-source parameters must be validated | Selected | Exact output contract with known ArduPilot pitfall covered. |
|
||||
| Validation | EuRoC + AerialVL/VPAir + Plane SITL + representative flight | Layered validation suite | Test strategy | Prove ACs before production | Sources #19, #20 | Public data not sufficient for final proof | Selected | Covers component de-risking plus final representative proof. |
|
||||
|
||||
## Restrictions Cross-Check — Selected Production Architecture
|
||||
|
||||
| Restriction | Candidate-mode behavior | Result | Evidence |
|
||||
|-------------|-------------------------|--------|----------|
|
||||
| Fixed-wing only | Architecture assumes forward motion, rare sharp turns, no hover dependency. | Pass | Problem context; Source #1 |
|
||||
| Fixed nadir nav camera | VO/orthorectification uses fixed camera extrinsics; attitude compensation from FC. | Pass | Source #5 |
|
||||
| Operational area / flat terrain | Flat terrain assumption supported; repetitive agricultural terrain handled as validation class and confidence risk. | Pass | Source #2 |
|
||||
| Weather/season classes | Validation matrix includes seasonal/visibility classes. | Pass | `05_validation_log.md` |
|
||||
| Two-camera split | Nav camera drives localization; AI camera object localization uses current GPS-denied state and AI gimbal/zoom. | Pass | AC-7.1/7.2 |
|
||||
| Satellite Service offline boundary | Runtime uses local COG/cache + FAISS descriptors only; no in-flight provider fetch. | Pass | Sources #17, #18 |
|
||||
| Freshness gates | Tile manifest carries capture date and sector; stale tiles rejected/down-weighted. | Pass | AC-8.2, AC-NEW-6 |
|
||||
| Jetson Orin Nano Super | Hot path is lightweight; heavy VPR conditional; runtime profiling gate required. | Pass | Sources #15, #16 |
|
||||
| MAVLink / ArduPilot only | MAVSDK telemetry + pymavlink `GPS_INPUT`, `GPS1_TYPE=14`. | Pass | Sources #10-#12 |
|
||||
| No raw frame storage | FDR keeps estimates, telemetry, tiles, and low-rate failure thumbnails only. | Pass | AC-8.5, AC-NEW-3 |
|
||||
|
||||
## AC Cross-Check — Selected Production Architecture
|
||||
|
||||
| AC | Candidate-mode behavior | Result | Evidence |
|
||||
|----|-------------------------|--------|----------|
|
||||
| AC-1.1 | Satellite anchors and ESKF output target <=50 m for >=80% normal frames. | Pass | Facts #1, #2 |
|
||||
| AC-1.2 | Same pipeline targets <=20 m for >=50% normal frames; validated statistically. | Pass | `05_validation_log.md` |
|
||||
| AC-1.3 | ESKF tracks anchor age and covariance; VO-only and IMU-fused drift measured between anchors. | Pass | Fact #1 |
|
||||
| AC-1.4 | ESKF emits covariance; telemetry/FDR carries source label. | Pass | Fact #16 |
|
||||
| AC-2.1a | VO hot path handles normal overlapping frames; failures trigger mode change. | Pass | Facts #1, #6 |
|
||||
| AC-2.1b | Satellite anchor success measured separately through VPR + local match + RANSAC. | Pass | Facts #2, #7, #12 |
|
||||
| AC-2.2 | OpenCV/LightGlue provide correspondences and homography MRE measurement. | Pass | Facts #6, #7 |
|
||||
| AC-3.1 | ESKF innovation gates reject outliers; covariance grows instead of trusting jumps. | Pass | Reasoning chain |
|
||||
| AC-3.2 | Sharp turn VO failure triggers VPR relocalization. | Pass | AC design; Source #2 |
|
||||
| AC-3.3 | Disconnected segment handled by global retrieval and pose-graph/ESKF re-anchor. | Pass | Source #2 |
|
||||
| AC-3.4 | Loss counter and timer trigger GCS relocalization request while dead reckoning continues. | Pass | AC design |
|
||||
| AC-3.5 | Image-quality/blackout state switches to IMU-only and rejects spoofed GPS. | Pass | AC design; Facts #16, #17 |
|
||||
| AC-4.1 | Heavy VPR is conditional; steady-state path is VO/IMU. Jetson profiling is a runtime quality gate. | Pass | Facts #3, #18 |
|
||||
| AC-4.2 | Descriptor/index memory is budgeted; FAISS and cache are precomputed/pruned. | Pass | Facts #12, #13 |
|
||||
| AC-4.3 | `GPS_INPUT` emitted by pymavlink; ODOMETRY remains disabled in v1. | Pass | Facts #14-#16 |
|
||||
| AC-4.4 | Estimator emits frame-by-frame; no batching required. | Pass | Architecture |
|
||||
| AC-4.5 | Corrections are emitted as updated estimates with timestamps and covariance. | Pass | Architecture |
|
||||
| AC-5.1 | Startup initializes from last trusted FC state plus IMU propagation. | Pass | Architecture |
|
||||
| AC-5.2 | >3 s no-estimate path enters degraded/failsafe behavior; Plane SITL proves FC response. | Pass | Fact #17 |
|
||||
| AC-5.3 | Cold restart uses FC state and preloaded cache/index. | Pass | AC-NEW-1 |
|
||||
| AC-6.1 | QGC receives downsampled status; FDR keeps high-rate details. | Pass | MAVSDK telemetry + FDR design |
|
||||
| AC-6.2 | Command ingress reserved through MAVLink status/named values/custom dialect. | Pass | MAVLink design |
|
||||
| AC-6.3 | `GPS_INPUT` lat/lon is WGS84. | Pass | Fact #16 |
|
||||
| AC-7.1 | Object localization exposes level-flight accuracy and maneuver bound. | Pass | Geometry design |
|
||||
| AC-7.2 | Flat-terrain trig projection from UAV GPS + gimbal/zoom/altitude. | Pass | Geometry design |
|
||||
| AC-8.1 | Cache contract requires 0.3-0.5 m/px imagery. | Pass | Restrictions |
|
||||
| AC-8.2 | Freshness metadata gates anchors. | Pass | Restrictions |
|
||||
| AC-8.3 | Precomputed descriptors and FAISS index are part of cache budget. | Pass | Facts #10, #12, #13 |
|
||||
| AC-8.4 | Generated tiles are new COGs with quality metadata for Service ingest. | Pass | Fact #21 |
|
||||
| AC-8.5 | Raw frames are not retained. | Pass | FDR design |
|
||||
| AC-8.6 | VPR chunks use overlap/multi-scale descriptors and dynamic K. | Pass | Facts #2, #12 |
|
||||
| AC-NEW-1 | Engines/indexes built before flight; first fix benchmark validates <30 s. | Pass | Runtime plan |
|
||||
| AC-NEW-2 | Plane SITL verifies spoofing trigger and promotion <3 s. | Pass | Fact #17 |
|
||||
| AC-NEW-3 | FDR segment rollover validates <=64 GB. | Pass | Validation plan |
|
||||
| AC-NEW-4 | Mahalanobis gates and calibrated covariance target false-position budget. | Pass | ESKF design |
|
||||
| AC-NEW-5 | Thermal profiling at 25 W validates no throttle. | Pass | Facts #18, #19 |
|
||||
| AC-NEW-6 | Tile age rejection/down-weighting built into anchor gate. | Pass | AC design |
|
||||
| AC-NEW-7 | Tile writes require parent-pose covariance and sidecar metadata; Satellite Service voting is external contract. | Pass | AC design |
|
||||
| AC-NEW-8 | Dead-reckoned blackout mode degrades `GPS_INPUT` fields at covariance thresholds. | Pass | Facts #16, #17 |
|
||||
|
||||
## Decision Rules Applied
|
||||
|
||||
- No GPL VIO/SLAM library is selected as a production dependency.
|
||||
- Runtime gates are classified as runtime-quality validation gates, not API capability blockers.
|
||||
- Every selected component has an exact input/output role and a validation path.
|
||||
- Any candidate with license uncertainty is marked `Needs user decision` or non-production.
|
||||
|
||||
## Mode B Revisions Applied
|
||||
|
||||
- FAISS pinned mode changed to CPU-first on Jetson ARM64.
|
||||
- DINOv2 TensorRT path requires descriptor-fidelity validation against PyTorch/ONNX.
|
||||
- `GPS_INPUT` tests now include velocity-source and ignore-flag behavior.
|
||||
- COG cache lifecycle clarified as write-new-object plus manifest versioning, not in-place mutation.
|
||||
- Visual/satellite security controls now include signed manifests, cache provenance, stale-tile rejection, and multi-signal consistency checks.
|
||||
|
||||
## Mode B Round 2 Revisions Applied
|
||||
|
||||
- OpenVINS is explicitly better than naive OpenCV-only VIO, but remains reference-only because the shipped estimator must own source labels, covariance gates, spoofing/blackout states, cache-write eligibility, and MAVLink semantics.
|
||||
- The selected VO wording is now "OpenCV geometry + project-owned ESKF" to avoid implying a fragile OpenCV-only odometry implementation.
|
||||
- DINOv2-VLAD + CPU-first FAISS + ALIKED/LightGlue remains selected for satellite retrieval and anchor verification, with retrieval limited to relocalization triggers and bounded top-K verification.
|
||||
- SIFT/ORB remains a regression/fallback baseline; SuperPoint remains non-production until legal approval.
|
||||
|
||||
## Mode B Round 3 Revisions Applied
|
||||
|
||||
- BASALT is selected as the production VIO candidate.
|
||||
- OpenVINS remains the covariance/reference baseline, not a shipped dependency by default.
|
||||
- Kimera-VIO remains a backup VIO candidate because its license is production-friendly but mono-inertial caveats make it weaker for the single-nadir-camera path.
|
||||
- The project-owned safety/anchor wrapper remains mandatory around BASALT for satellite anchor acceptance, source labels, blackout/spoofing modes, cache-write eligibility, calibrated confidence, and MAVLink `GPS_INPUT`.
|
||||
Reference in New Issue
Block a user