# Reasoning Chain

## Dimension 1: ESKF Sensor Fusion Specification

### Fact Confirmation
Per Fact #3, standard ESKF for UAV VIO uses 15-16 state error vector: δp[3], δv[3], δθ[3], δba[3], δbg[3]. Per Fact #4, monocular VIO cannot observe metric scale during constant-velocity flight (fundamental observability limitation). Per Fact #7, scale requires external constraint (altitude or satellite absolute position).

### Current State
Draft05 says "Custom ESKF (NumPy/SciPy)", "16-state vector", "ESKF measurement update ~1ms", "ESKF IMU prediction at 5-10Hz". But provides zero mathematical detail.

### Conclusion
The ESKF is the **most under-specified critical component**. Without defining:
- State vector and error state vector explicitly
- Process model (how IMU data propagates the state)
- VO measurement model (how cuVSLAM relative pose updates the filter)
- Satellite measurement model (how absolute position corrections are applied)
- How scale is maintained (altitude constraint? satellite corrections only?)
- Q and R matrices (at least initial values and tuning approach)

...the system cannot be implemented. The ESKF is the central hub connecting all sensors — its specification drives the entire data flow.

### Confidence: ✅ High

---

## Dimension 2: Flight Controller Integration (GPS_INPUT)

### Fact Confirmation
Per Fact #1, ArduPilot requires minimum 5Hz GPS_INPUT rate. Per Fact #2, GPS_INPUT has 15+ mandatory fields including velocity, accuracy, fix_type, GPS time. Per Fact #14, confidence scoring that maps internal state to GPS_INPUT accuracy fields is undefined.

### Current State
Draft05 specifies: pymavlink, GPS_INPUT, 5-10Hz, UART. This satisfies the rate requirement. But the message population is unspecified.

### Conclusion
The GPS_INPUT integration has the right architecture (5-10Hz, pymavlink, UART) but is missing the **data mapping layer**:
- `vn, ve, vd` must come from ESKF velocity estimate — requires ESKF to output velocity
- `horiz_accuracy, vert_accuracy` must come from ESKF covariance matrix (sqrt of position covariance diagonal)
- `hdop, vdop` need to be synthesized from accuracy values (hdop ≈ horiz_accuracy / expected_CEP_factor)
- `fix_type` must map from internal confidence (3=3D fix when satellite-anchored, 2=2D when VO-only?)
- `speed_accuracy` from ESKF velocity covariance
- GPS time (time_week, time_week_ms) requires conversion from system time to GPS epoch
- `satellites_visible` should be set to a constant (e.g., 10) to avoid triggering satellite-count failsafes

This is a tractable implementation detail but must be specified before coding.

### Confidence: ✅ High

---

## Dimension 3: Coordinate System & Transformations

### Fact Confirmation
Per Fact #8, the system needs pixel → camera → body → NED → WGS84 chain. Per Fact #9, satellite tiles have different GSD than camera imagery. Per Source #15, similar systems define explicit coordinate transforms with PnP solvers.

### Current State
Draft05 calculates camera footprint and GSD but never defines the transformation chain. Object localization mentions "trigonometric calculation" without math.

### Conclusion
This is a **fundamental architectural gap**. Every position estimate flows through coordinate transforms. Without defining them:
- cuVSLAM outputs relative pose in camera frame — how is this converted to NED displacement?
- Satellite matching outputs pixel correspondences — how does homography → WGS84 position?
- Object localization needs camera ray → ground intersection — impossible without camera-to-body and body-to-NED transforms
- The camera is "not autostabilized" — so body frame attitude matters for ground projection

The fix requires defining: camera intrinsic matrix K, camera-to-body rotation T_cam_body, and the ESKF attitude estimate for body-to-NED.

### Confidence: ✅ High

---

## Dimension 4: Disconnected Route Segments

### Fact Confirmation
Per Fact #7, AC explicitly requires handling disconnected segments as "core to the system." Per Fact #6, cuVSLAM IMU fallback gives ~1s before tracking loss. Per Source #8, trajectory-level optimization can handle segment connections.

### Current State
Draft05 acknowledges this in AC but the solution section says "sharp-turn frames are expected to fail VO and should be handled by satellite-based re-localization." No algorithm is specified.

### Conclusion
The solution needs a concrete **re-localization pipeline**:
1. Detect tracking loss (cuVSLAM returns tracking_lost state)
2. Continue ESKF with IMU-only prediction (high uncertainty growth)
3. Immediately trigger satellite matching on next available frame
4. If satellite match succeeds: reset ESKF position to matched position, reset cuVSLAM (or start new track)
5. If satellite match fails: retry on next frame, increment failure counter
6. If 3 consecutive failures: send re-localization request to ground station
7. When new segment starts: mark as disconnected, continue building trajectory
8. Optionally: if a later satellite match connects two segments to the same reference, merge them

This is not trivial but follows directly from the existing architecture. It's a missing algorithm, not a missing component.

### Confidence: ✅ High

---

## Dimension 5: Startup Bootstrap & Failsafe

### Fact Confirmation
Per Fact #15, the bootstrap sequence has gaps (first satellite match, initial ESKF state, GPS-denied handoff). Per Fact #16, AC requires mid-flight reboot recovery. Per Fact #19, AC requires 3-consecutive-failure re-localization request.

### Current State
Draft05 has a 12-step startup sequence that covers the happy path. The failure paths and special cases are not addressed.

### Conclusion
Three failsafe scenarios need specification:
1. **GPS-denied handoff**: How does the system know to start? Options: (a) always running — takes over when GPS quality degrades, (b) operator command, (c) automatic GPS quality monitoring. The system should probably always be running in parallel and the FC uses the best available source.
2. **Mid-flight reboot**: Read FC position → init ESKF with high uncertainty → start cuVSLAM → immediate satellite match → within ~5s should have a position estimate. TRT engine load (1-3s) is the main startup cost.
3. **3 consecutive failures**: Define "failure" precisely (VO lost + satellite match failed + IMU-only drift > threshold). Send NAMED_VALUE_FLOAT or custom MAVLink message to ground station. Define operator response format.

### Confidence: ✅ High

---

## Dimension 6: Satellite Matching Pipeline Details

### Fact Confirmation
Per Fact #9, camera GSD is ~15.9 cm/pixel at 600m with ADTI+16mm lens. Satellite at zoom 19 is ~0.3 m/pixel. Per Fact #10, Google Maps imagery in Ukraine conflict zone is intentionally >1 year old. Per Fact #14, the solution says "pre-resize" but doesn't specify to what resolution.

### Current State
Draft05 has a solid model selection decision tree (LiteSAM → EfficientLoFTR → XFeat) and TRT conversion workflow. But the actual matching pipeline data flow is incomplete.

### Conclusion
The matching pipeline needs:
- **Input preparation**: Camera frame (5456×3632 at ~15.9 cm/pixel at 600m) → downsample to matcher input resolution (1280px for LiteSAM). Satellite tile at zoom 18 (~0.6 m/pixel) → no resize needed if using 256px tiles, or assemble 5×5 tile mosaic for coverage.
- **GSD matching**: Either downsample camera image to satellite GSD, or specify that the matcher handles multi-scale internally. LiteSAM was designed for satellite-aerial matching so it may handle this. XFeat is general-purpose and may need explicit scale normalization.
- **Tile selection**: Given ESKF position estimate + uncertainty, select the correct satellite tile(s). What if the position estimate has drifted and the wrong tile is selected? Need a search radius based on ESKF covariance.
- **Match → position**: Homography from RANSAC → decompose to get translation in satellite coordinate frame → convert to WGS84 using tile's geo-reference.
- **Seasonal/temporal mismatch**: Tiles could be from different seasons. Feature matching must be robust to appearance changes.

### Confidence: ✅ High

---

## Dimension 7: Operational Maturity

### Fact Confirmation
Per Fact #11, mature systems (Auterion, PX4) define pre-flight checklists, in-flight monitoring, failure response procedures. Per Fact #13, documents are inconsistent (tech_stack.md still says 3fps).

### Current State
Zero operational procedures defined. Documents are partially inconsistent.

### Conclusion
This is expected at this stage of development (architecture/design phase). Operational procedures should come after implementation and initial testing. However, the document inconsistencies should be fixed now to avoid confusion during implementation. The tech_stack.md and solution_draft should be aligned.

### Confidence: ✅ High

---

## Dimension 8: Object Localization

### Fact Confirmation
Per Fact #12, AC requires other AI systems to request GPS coordinates of detected objects. The Viewpro A40 Pro gimbal has configurable angle and zoom.

### Current State
Draft05 says "trigonometric calculation using UAV GPS position, camera angle, zoom, altitude. Flat terrain assumed."

### Conclusion
The math is straightforward but needs specification:
- Input: pixel coordinates (u,v) in Viewpro image, gimbal angles (pan, tilt), zoom level, UAV position (from GPS-denied system), UAV altitude
- Process: (1) pixel → ray in camera frame using intrinsics + zoom, (2) camera frame → body frame using gimbal angles, (3) body frame → NED using UAV attitude, (4) ray-ground intersection assuming flat terrain at known altitude, (5) NED offset → WGS84
- Output: lat, lon of object + accuracy estimate (propagated from UAV position accuracy + gimbal angle uncertainty)
- API: FastAPI endpoint for other onboard systems to call

This is a 2-point complexity task but should be specified in the solution.

### Confidence: ✅ High
