mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-27 15:36:42 +00:00
- Introduced a new document detailing the current state of the autodev process, including steps, status, and findings.
- Revised acceptance criteria in the acceptance_criteria.md file to clarify metrics and expectations, including updates to GPS accuracy and image processing quality. - Enhanced restrictions documentation to reflect operational parameters and constraints for UAV flights, including camera specifications and satellite imagery usage. - Added new research documents for acceptance criteria assessment and question decomposition to support ongoing project evaluation and decision-making.
This commit is contained in:
@@ -0,0 +1,94 @@
|
||||
# Mode B — Round 2 Question Decomposition
|
||||
|
||||
**Trigger**: user explicit ask after rolling back from Step 3 (Plan).
|
||||
|
||||
**Mode**: B (Solution Assessment of `solution_draft02.md`).
|
||||
|
||||
**Date**: 2026-04-26.
|
||||
|
||||
**Scope (user-provided)**:
|
||||
|
||||
> "1. For VO — is it the most efficient method SP+LG for jetson? are there better ways? 2. for cross-view matcher — there is LiteSAM (https://github.com/boyagesmile/LiteSAM) and other methods specialized for that. Check and investigate in internet possible options. 3. EKF fusion — isn't it ESKF better? Ortho-tile generator — are there are already existing libs for that? or it is not so difficult and easier just to make it manually by ourselves? All in all, make a thorough investigation regarding each component — what's could be either give better confidence with relatively same resource and time footprint, either can provide roughly same confidence faster or lighter on resources."
|
||||
|
||||
## Question Type Classification
|
||||
|
||||
| # | Sub-Question | Type | Why |
|
||||
|---|--------------|------|-----|
|
||||
| Q-R2-1 | Is the SP+LG-based VO design (custom 2-frame homography) the most efficient & accurate VO on Orin Nano Super, or is there a better one? | Decision Support + Problem Diagnosis | Trade-off (compute vs accuracy vs maturity) + diagnoses whether the draft02 design choice is sound. |
|
||||
| Q-R2-2 | Should LiteSAM (or any specialized satellite-aerial matcher) replace SP+LG / GIM-LG as the inline cross-view matcher? | Decision Support | Trade-off (accuracy vs latency vs role-fit). |
|
||||
| Q-R2-3 | Is ESKF strictly better than EKF for our fusion stage? | Decision Support + Concept Comparison | Comparison + applicability boundary (ArduPilot vs companion). |
|
||||
| Q-R2-4 | Should we use an existing ortho-tile generator library, or DIY? | Decision Support | Build-vs-buy. |
|
||||
| Q-R2-5 | Is there a newer/better option for **every other component** (VPR, tile storage, MAVLink, software platform, DEM, etc.) that could give better confidence at same/lower resource footprint? | Knowledge Organization + Decision Support | Sweep audit of remaining components. |
|
||||
|
||||
Mode-B classification rule: **Problem Diagnosis + Decision Support** — applies to every sub-question above.
|
||||
|
||||
## Research Subject Boundary Definition
|
||||
|
||||
| Dimension | Boundary | Notes |
|
||||
|-----------|----------|-------|
|
||||
| **Population** | Embedded autonomous-flight stack on **Jetson Orin Nano Super (8 GB shared)** companion + **ArduPilot 4.5+** flight controller. Fixed-wing UAV airframe, 1 km AGL nadir nav cam, ADTi 20MP APS-C @ 3 fps. | Same as round 1. |
|
||||
| **Geography** | Eastern-Ukraine theatre (active conflict, season variation). | Same as round 1. |
|
||||
| **Timeframe** | v1 release 2026; v1.1 within 6 months. | Same as round 1. |
|
||||
| **Level** | Software architecture and component selection (no hardware / no airframe / no GCS). | Same as round 1. |
|
||||
|
||||
## Perspectives Used (≥3 required)
|
||||
|
||||
| Perspective | Why this round | Example searches |
|
||||
|-------------|---------------|------------------|
|
||||
| **Implementer / Engineer** | Round 1 missed a few real engineering gotchas (companion-side filter double-fusion bugs, cuVSLAM as drop-in alternative). | "ArduPilot ExtNav GPS_INPUT double fusion", "cuVSLAM Jetson Orin Nano monocular fixed-wing" |
|
||||
| **Practitioner / Field** | Look at production GPS-denied UAV reference designs on the same hardware target. | "ROS 2 Humble Jetson Orin Nano Super JetPack 6 MAVROS ArduPilot integration GPS-denied", "VINS-Fusion OpenVINS BASALT SVO Pro Jetson Orin Nano benchmark monocular fixed-wing 2025" |
|
||||
| **Domain expert / Academic** | Verify SOTA matcher and SLAM landscape post-Mode-A. | "MASt3R-SLAM monocular real-time 2025 Jetson DROID-SLAM MAC-VO", "RoMa DKM dense feature matching aerial satellite UAV-VisLoc 2025" |
|
||||
| **Contrarian** | Actively search for "why not the chosen approach": custom 2-frame VO, SP+LG-only matcher, hybrid GPS_INPUT+ODOMETRY both active. | "ArduPilot ODOMETRY GPS_INPUT companion external visual odometry double-fusion best practice", "fixed-wing UAV high altitude visual odometry 1km AGL accuracy" |
|
||||
|
||||
## Search Query Variants Per Sub-Question
|
||||
|
||||
(Selected; full search log preserved in agent transcript and `01_source_registry.md` round-2 entries.)
|
||||
|
||||
**Q-R2-1 (VO)**:
|
||||
1. `visual odometry Jetson Orin Nano benchmark 2026 fixed-wing UAV monocular DPVO BASALT OpenVINS SVO Pro`
|
||||
2. `DPVO Deep Patch Visual Odometry Jetson real-time inference benchmark FPS 2025`
|
||||
3. `cuVSLAM Jetson Orin Nano monocular fixed-wing aerial visual odometry CUDA Lucas-Kanade`
|
||||
4. `MASt3R-SLAM monocular real-time 2025 Jetson DROID-SLAM MAC-VO benchmark embedded`
|
||||
5. `VINS-Fusion OpenVINS BASALT SVO Pro Jetson Orin Nano benchmark monocular fixed-wing 2025`
|
||||
6. `DPVO Jetson Orin Nano FPS benchmark monocular visual odometry deployment 2025 ARM`
|
||||
7. `fixed-wing UAV high altitude visual odometry 1km AGL monocular accuracy 2025`
|
||||
8. `Isaac ROS visual SLAM cuVSLAM Jetson Orin Nano monocular fixed-wing UAV high altitude integration`
|
||||
9. `DPV-SLAM DPVO real-time Jetson NX Orin port deployment monocular SLAM 2024`
|
||||
|
||||
**Q-R2-2 (cross-view matcher)**:
|
||||
1. `LiteSAM lightweight feature matching satellite aerial imagery 2025 EfficientLoFTR`
|
||||
2. `cross-view UAV satellite image matching benchmark 2025 XoFTR MatchAnything OmniGlue LoFTR LightGlue`
|
||||
3. `MapGlue MapAnything XoFTR cross-modal aerial satellite matching Jetson inference 2025`
|
||||
4. `XFeat lightweight feature matching Jetson Orin TensorRT FPS benchmark 2025`
|
||||
5. `LightGlue ONNX TensorRT Jetson Orin Nano Super fps 2025 SuperPoint inference benchmark`
|
||||
6. `RoMa DKM dense feature matching aerial satellite UAV-VisLoc benchmark accuracy 2025`
|
||||
7. `aerial drone matcher MatchAnything OmniGlue DeDoDe homography benchmark 2025`
|
||||
8. `SuperPoint LightGlue Jetson Orin Nano TensorRT FP16 INT8 ms per frame benchmark`
|
||||
9. `UAV-VisLoc satellite aerial localization SP+LG XFeat LiteSAM RoMa benchmark accuracy meters`
|
||||
|
||||
**Q-R2-3 (EKF / ESKF)**:
|
||||
1. `ESKF error state Kalman filter visual inertial navigation drone vs EKF 2025 advantages`
|
||||
2. `ArduPilot EKF3 error state Kalman external visual odometry GPS_INPUT ODOMETRY fusion architecture`
|
||||
3. `ArduPilot EKF3 vs PX4 EKF2 ESKF visual external odometry companion computer architecture`
|
||||
4. `ArduPilot ODOMETRY GPS_INPUT companion external visual odometry double-fusion IMU EKF3 best practice`
|
||||
|
||||
**Q-R2-4 (ortho-tile generator)**:
|
||||
1. `orthomosaic generation library python aerial drone OpenDroneMap MicMac OpenSfM real-time`
|
||||
2. `single image orthorectification python library DEM gimbal pinhole homography UAV nadir camera`
|
||||
3. `Orthority orthorectification python single image GeoTIFF DEM RPC frame camera benchmark`
|
||||
4. `Orthority simple-ortho per-frame nadir UAV gimbal pitch roll yaw projection latency milliseconds`
|
||||
|
||||
**Q-R2-5 (sweep)**:
|
||||
1. `Cloud Optimized GeoTIFF COG vs MBTiles tile cache embedded UAV onboard storage performance`
|
||||
2. `ROS 2 Humble Jetson Orin Nano Super JetPack 6 MAVROS ArduPilot integration GPS-denied`
|
||||
3. (Plus targeted re-checks of round-1 components: VPR backbones, MAVLink2 signing, free-threaded Python, SRTM 30 m DEM.)
|
||||
|
||||
## Completeness Audit
|
||||
|
||||
| Probe | Coverage |
|
||||
|-------|----------|
|
||||
| **Did we re-check every component the user named?** | ✅ VO (Q-R2-1), matcher (Q-R2-2), EKF (Q-R2-3), ortho (Q-R2-4). |
|
||||
| **Did we sweep every other component for resource/confidence trade-offs?** | ✅ VPR (no new entrants — M-33), tile storage (MBTiles WAL stays — M-28), MAVLink (sysid + signing unchanged — M-31), software platform (CPython + ROS-2-vs-DIY surfaced as open Q — M-29, M-32), DEM (no change), camera (already locked). |
|
||||
| **Did we surface contrarian failure modes per component?** | ✅ Custom-2-frame-VO is wrong (M-22); LiteSAM-on-Orin-Nano-Super is too slow inline (M-24); RoMa v2 / MASt3R-SLAM are GPU-class (M-25, S62); ArduPilot double-fusion is a bug, not a feature (M-26, M-30). |
|
||||
| **Did we identify decisions that need user input vs decisions that are deterministic?** | ✅ ROS 2 vs DIY orchestrator (M-29) — needs user. Channel-split for hybrid (M-30) — recommendation Option A for v1, Option B v1.1+. |
|
||||
| **Did we re-validate locked AC restrictions (camera, zoom, AC-NEW-7)?** | ✅ All lock-ins from round 1 carry forward unchanged. |
|
||||
Reference in New Issue
Block a user