# Question Decomposition

## Original Question

Design a GPS-denied onboard system for a fixed-wing UAV that estimates the WGS84 coordinate of each navigation-camera frame center, estimates object coordinates from a separate AI camera, and emits replacement GPS data to ArduPilot using only onboard sensors and a preloaded satellite imagery cache.

## Active Mode

- **Mode**: Mode B — solution assessment of `_docs/01_solution/solution_draft01.md`.
- **Question type**: Problem Diagnosis with Decision Support.
- **Rationale**: The first draft has a plausible architecture, but several component choices need stricter exact-fit checks against licensing, memory, cache-size, validation-data, and ArduPilot integration constraints before planning.

## Problem Context Summary

- Fixed-wing UAV, roughly 60 km/h cruise, 8-hour missions, up to 400 km² persistent satellite cache.
- Navigation camera is fixed and nadir-facing; v1 target is ADTi 20MP 20L V1 with a lens selected for roughly 10-20 cm/px at <=1 km AGL.
- AI camera is separate, gimbaled/zoomed, and only gimbal angle + zoom are available to the GPS-denied system.
- IMU and attitude data arrive from the flight controller over MAVLink.
- Onboard platform is Jetson Orin Nano Super, 8 GB shared memory, 25 W.
- Satellite imagery is preloaded before flight by Azaion Suite Satellite Service; no in-flight network dependency.
- Output to flight controller is v1 `GPS_INPUT` only, with `ODOMETRY` deferred until release/version-specific SITL validation.

## Research Subject Boundary

| Dimension | Boundary |
|-----------|----------|
| Population | Fixed-wing UAVs with downward navigation camera, not multicopter-only or indoor robot-only systems. |
| Geography | Eastern/southern Ukraine style steppe/agricultural terrain, sparse landmarks, active-conflict freshness risk. |
| Timeframe | Current practical open-source/commercial CV stack as of 2024-2026. |
| Level | Onboard production architecture and validation plan, not only offline academic benchmark. |
| Operating context | Real-time edge inference, GPS denied/spoofed, no in-flight satellite fetch, 8-hour thermal duty cycle. |
| Required interfaces | Nav-camera frames, FC IMU/attitude/altitude over MAVLink, offline tile cache, local API, MAVLink `GPS_INPUT`. |
| Non-functional envelope | <400 ms p95 output latency, <8 GB memory, 10 GB cache cap, 64 GB FDR cap, calibrated false-position budget. |

## Project Constraint Matrix Summary

| Constraint Area | Binding Constraint | Hard Disqualifiers |
|-----------------|-------------------|--------------------|
| Camera/VO | Fixed nadir monocular navigation camera, high-res frames, flight attitude from FC. | VO requiring stereo/depth as a mandatory input for v1. |
| Absolute localization | Must anchor to offline satellite cache and handle sparse terrain. | Pure VO/SLAM with no global relocalization. |
| Runtime | Jetson Orin Nano Super, 8 GB shared memory, 25 W. | Per-frame heavy VPR or models that exceed memory/thermal budgets. |
| Safety | Must report covariance and avoid confident false positions. | Matchers that output positions without calibrated uncertainty and outlier rejection. |
| Autopilot | ArduPilot v1, `GPS_INPUT` primary. | PX4-only or ODOMETRY-only integration for v1. |
| Storage | No raw frame persistence; tiles and FDR only. | Architectures depending on raw photo archive during normal flight. |
| Satellite cache | 0.5 m/px min, 0.3 m/px ideal; freshness metadata required. | Untimestamped/stale reference tiles treated as equally trustworthy. |

## Decomposed Sub-Questions

1. Which assumptions in `solution_draft01.md` are weak, under-evidenced, or contradicted by project constraints?
2. Does the selected local matcher have a product-safe licensing path and a realistic Jetson performance path?
3. Does the AnyLoc/DINOv2-VLAD VPR proposal fit the 8 GB memory and 10 GB cache budgets after descriptor/index sizing?
4. Is the 400 km² satellite cache budget plausible when 0.3-0.5 m/px imagery, overviews, manifests, descriptors, and generated tiles are included?
5. Are the public validation datasets sufficient, or does final acceptance require project-specific IMU/camera timing traces?
6. Does v1 `GPS_INPUT`-only ArduPilot integration remain safer than dual `GPS_INPUT` + `ODOMETRY` emission?
7. Are any selected components still only experimental and therefore blocked by the exact-fit gate?

## Chosen Perspectives

- **Implementer / Engineer**: exact sensor fit, timing, memory, calibration, and integration risks.
- **Domain expert / Academic**: public evidence for UAV-to-satellite localization and VO drift behavior.
- **Contrarian / Safety**: false positive matches, stale tiles, cache poisoning, and EKF double-fusion.
- **Operator / Field**: no in-flight network, QGC visibility, reboot recovery, and failure requests.

## Search Query Variants

| Sub-Question | Query Variants |
|--------------|----------------|
| VO/VIO | `fixed wing UAV visual odometry GPS denied satellite imagery`, `monocular IMU visual inertial odometry UAV`, `cuVSLAM monocular IMU requirements`, `ORB-SLAM3 monocular inertial license`, `VINS-Fusion monocular IMU fixed wing UAV` |
| VPR | `DINOv2 visual place recognition UAV satellite localization`, `AnyLoc DINOv2 visual place recognition license`, `SatLoc dataset GNSS denied UAV`, `NaviLoc trajectory visual localization UAV`, `DINOv2 Jetson Orin latency` |
| Local matching | `SuperPoint LightGlue TensorRT Jetson Orin`, `cross-view geo-localization UAV satellite imagery 2024`, `UAV satellite image local feature matching RANSAC homography`, `SuperPoint license LightGlue license` |
| Fusion | `error state Kalman filter visual inertial GPS denied UAV`, `MAVLink GPS_INPUT horizontal accuracy covariance`, `ArduPilot external navigation GPS double fusion`, `ArduPilot EKF3 GPS_INPUT ODOMETRY` |
| Cache | `Cloud Optimized GeoTIFF offline raster cache`, `MBTiles offline raster tile cache`, `slippy map zoom meters per pixel`, `satellite imagery 30 cm resolution official`, `Maxar Airbus 30 cm CE90` |
| API/FDR | `FastAPI OpenAPI automatic documentation`, `pymavlink GPS_INPUT send message`, `MAVProxy GPS_INPUT GPS1_TYPE 14`, `flight data recorder UAV MAVLink logs` |
| Mode B weak points | `SuperPoint pretrained weights license commercial use`, `LightGlue license extractor weights`, `AnyLoc DINOv2 VLAD descriptor dimension memory`, `COG JPEG compression satellite imagery storage estimate`, `public UAV dataset GPS IMU satellite imagery AerialVL`, `ArduPilot GPS_INPUT external navigation ODOMETRY EKF3 2026` |
| Mode B round 2 weak points | `ALIKED feature extractor license LightGlue`, `DISK local feature extractor license LightGlue`, `DeDoDe local features license TensorRT`, `OpenCV SIFT patent expired commercial use`, `real-time frame queue latency latest frame processing visual odometry` |

## Completeness Audit

| Probe | Result |
|-------|--------|
| Cost / resources | Covered through Jetson, storage, model, and satellite-service constraints. |
| Physical/legal/environmental constraints | Covered through camera, thermal, DO-160-style environment, and imagery provider boundary. |
| Dependencies and assumptions | Covered through Suite Satellite Service, ArduPilot version, TensorRT/JetPack, and model licensing. |
| Operating environment | Covered: daytime, steppe/agricultural terrain, active-conflict freshness, sparse landmarks. |
| Failure modes | Covered: stale tiles, sharp turns, VO loss, false positives, cache poisoning, reboot, EKF fusion bugs. |
| Practitioner lessons | Covered through ArduPilot issue evidence and Jetson/TensorRT deployment constraints. |
| Change over time | Covered through high novelty sensitivity for VPR models, JetPack/TensorRT, and ArduPilot EKF behavior. |
| Mode B exact-fit gaps | Covered through new checks on SuperPoint licensing, LightGlue/extractor separation, AnyLoc descriptor size, COG storage measurement, and dataset realism. |
| Planning specificity | Covered through named local-matcher candidates and a scheduler/drop-policy component for AC-4.1 / AC-4.4. |

## Timeliness Sensitivity Assessment

- **Research topic**: GPS-denied UAV visual localization using VO/IMU, VPR, cross-view matching, Jetson inference, and ArduPilot MAVLink output.
- **Sensitivity level**: High.
- **Rationale**: Hardware, TensorRT, JetPack, VPR foundation models, and ArduPilot EKF behavior change across releases; algorithmic principles are more stable.
- **Source time window**: Prefer 2024-2026 for implementation/tooling; older foundational VO/SLAM papers are acceptable only as background.
- **Priority official sources**: ArduPilot/MAVLink docs, NVIDIA Jetson/TensorRT/Isaac ROS docs, official provider imagery pages, official library repos.