# Validation Log

## Validation Scenario 1: Normal Straight Flight (Happy Path)

### Expected Based on Conclusions
UAV flies straight at 70 km/h, 600m altitude. ADTI captures at 0.7fps. cuVSLAM processes each frame (~9ms), ESKF fuses VO + IMU. Every 5-10 frames, satellite matching provides absolute correction. GPS_INPUT sent at 5-10Hz.

### Actual Validation Results
The happy path is well-specified in draft05. Time budgets, memory budgets, overlap calculations all valid. The 5-10Hz ESKF IMU prediction fills gaps between 0.7fps camera frames. Satellite matching async on Stream B.

**GAP**: Even on straight flight, the GPS_INPUT message field population is undefined. Where does velocity come from? What fix_type is sent? What accuracy values?

---

## Validation Scenario 2: Sharp Turn with No Overlap

### Expected Based on Conclusions
UAV makes a 90° turn. Next frame has zero overlap with previous. cuVSLAM loses tracking. System falls back to IMU. ESKF uncertainty grows rapidly. Satellite matching on next frame provides re-localization.

### Actual Validation Results
**CRITICAL GAP**: No algorithm defined for this scenario. Questions:
1. How does the system detect cuVSLAM tracking loss? (cuVSLAM API presumably returns a tracking state)
2. During IMU-only phase, what is the ESKF prediction uncertainty growth rate? (~1-2m/s drift with consumer IMU)
3. When satellite match succeeds after the turn, how is ESKF re-initialized? (measurement update with very high innovation? or state reset?)
4. How is cuVSLAM re-initialized on the new heading? (new track from scratch? or cuVSLAM loop closure if it sees previous terrain?)
5. If the turn area is over featureless terrain (farmland), satellite matching may also fail — then what?

The AC says "sharp-turn frames should be within 200m drift and angle <70 degrees" — this bounds the problem but the solution doesn't address it algorithmically.

---

## Validation Scenario 3: Long Flight Over Uniform Terrain

### Expected Based on Conclusions
UAV flies 50km straight over large agricultural fields. cuVSLAM may struggle with low-texture terrain. Satellite matching is the only absolute correction source.

### Actual Validation Results
This scenario tests the limits of the design:
- cuVSLAM at 600m altitude sees ~577m × 870m footprint. If it's a single wheat field, features may be sparse. cuVSLAM falls back to IMU (~1s acceptable, then tracking lost).
- Satellite matching must carry the entire position estimation burden.
- At 0.7fps with keyframe every 5-10 frames: satellite match every 7-14s.
- Between matches, IMU-only drift at 70 km/h: ~14m/s × time × drift_rate. With consumer IMU: ~1-5m drift per second.
- Over 14s between matches: ~14-70m potential drift. AC requires <100m between anchors.

**GAP**: The system's behavior in this degraded mode needs explicit specification. Is this VO-failed + satellite-only + IMU acceptable? What's the accuracy?

---

## Validation Scenario 4: First Frame After GPS Denial

### Expected Based on Conclusions
GPS was working. Now it's denied/spoofed. System takes over.

### Actual Validation Results
**GAP**: No handoff protocol defined. Questions:
1. How does the system detect GPS denial? (it doesn't — it's assumed the operator knows)
2. The initial ESKF state comes from GLOBAL_POSITION_INT — but this might be the spoofed GPS. How to validate?
3. If GPS is being spoofed rather than denied, the initial position could be wrong by kilometers.
4. Draft05 assumes clean initial GPS. This is reasonable for the first version but should be acknowledged as a limitation.

---

## Validation Scenario 5: Mid-Flight Companion Computer Reboot

### Expected Based on Conclusions
Companion computer crashes and reboots. Flight controller continues flying on IMU dead reckoning.

### Actual Validation Results
**GAP**: AC requires recovery. Draft05 doesn't address it. Sequence should be:
1. Jetson boots (~30-60s depending on boot time)
2. GPS-Denied service starts (systemd)
3. Connect to FC, get current position (IMU-extrapolated, may have significant drift)
4. Load TRT engines (~1-3s each, total ~2-6s)
5. Start cuVSLAM (no prior map, fresh start)
6. Immediate satellite match to get absolute position
7. Total recovery time: ~35-70s. During this time, FC uses IMU-only. At 70 km/h: ~700-1400m of uncontrolled drift.

This is a real operational concern and should be documented even if the solution is "acknowledge the limitation."

---

## Counterexamples
- **NaviLoc achieves 19.5m at lower altitude**: Our system operates at 600-1000m with larger footprints and coarser GSD. The accuracy requirement (50m for 80%, 20m for 60%) is less demanding. The simpler ESKF approach may be adequate.
- **SatLoc-Fusion uses DinoV2 for place recognition**: Our system uses feature matching (LiteSAM/XFeat) which is more precise but less robust to appearance changes. DinoV2 is more robust to seasonal changes but gives coarser position.

## Review Checklist
- [x] Draft conclusions consistent with fact cards
- [x] No important dimensions missed
- [x] No over-extrapolation
- [ ] Issue: ESKF specification is too underspecified to validate accuracy claims
- [ ] Issue: Disconnected segment handling is critical AC and has no algorithm
- [ ] Issue: GPS_INPUT field mapping undocumented
- [ ] Issue: Object localization API undefined

## Conclusions Requiring Revision
None requiring reversal. All identified gaps are genuine and supported by facts.
