# Reasoning Chain

## Dimension 1: SuperPoint+LightGlue for Visual Odometry

### Fact Confirmation
cuVSLAM achieves 116fps (~8.6ms/frame) on Orin Nano 8GB at 720p (Fact #1). SP+LG achieves ~10fps on KITTI on desktop GPU (Fact #2). SuperPoint alone takes ~40ms on Jetson for 200 keypoints (Fact #3). LightGlue matching on desktop GPU takes ~20-34ms for 274 keypoints (Fact #2).

### Extrapolation to Orin Nano Super
On Orin Nano Super, estimating SP+LG pipeline:
- SuperPoint extraction (1024 keypoints, 720p): ~50-80ms (based on Fact #3, scaled for more keypoints)
- LightGlue matching (TensorRT FP16, 1024 keypoints): ~80-200ms (based on Fact #11 — 2-4x speedup over PyTorch, but Orin Nano is ~4-6x slower than RTX 4080)
- Total SP+LG: ~130-280ms per frame

cuVSLAM: ~8.6ms per frame.

SP+LG would be **15-33x slower** than cuVSLAM for visual odometry on Orin Nano Super.

### Additional Considerations
cuVSLAM includes native IMU integration, loop closure, and auto-fallback. SP+LG provides none of these — they would need custom implementation, adding both development time and latency.

### Conclusion
**SP+LG is not viable as a cuVSLAM replacement for VO on Orin Nano Super.** cuVSLAM is purpose-built for Jetson and 15-33x faster. SP+LG's value lies in its accuracy for feature matching tasks, not real-time VO on edge hardware.

### Confidence
✅ High — performance gap is enormous and well-supported by multiple sources.

---

## Dimension 2: LiteSAM Speed vs Image Resolution (1280px question)

### Fact Confirmation
LiteSAM (opt) achieves 497ms on AGX Orin at 1184px (Fact #5). AGX Orin is ~3-4x more powerful than Orin Nano Super (Fact #6). LiteSAM processes at 1/8 scale internally — coarse matching is O(N²) where N is proportional to resolution² (Fact #7).

### Resolution Scaling Analysis

**1280px vs 1184px**: Token count increases from ~21,904 to ~25,600 (+17%). Compute increases ~17-37% (linear to quadratic depending on bottleneck). This makes the problem WORSE, not better.

**The user's intuition is likely**: "If 6252×4168 camera images are huge, maybe LiteSAM is slow because we feed it those big images. What if we use 1280px?" But the solution draft already specifies resizing to 480-640px before feeding LiteSAM. The 497ms benchmark on AGX Orin was already at 1184px (the UAV-VisLoc benchmark resolution).

**The real bottleneck is hardware, not image size:**
- At 1184px on AGX Orin: 497ms → on Orin Nano Super: est. **~1.5-2.0s**
- At 1280px on Orin Nano Super: est. **~1.7-2.3s** (WORSE — more tokens)
- At 640px on Orin Nano Super: est. **~450-600ms** (borderline)
- At 480px on Orin Nano Super: est. **~270-360ms** (possibly within 400ms budget)

### Conclusion
**1280px would make LiteSAM SLOWER, not faster.** The paper benchmarked at 1184px. The bottleneck is the hardware gap (AGX Orin 275 TOPS → Orin Nano Super 67 TOPS). To make LiteSAM fit the 400ms budget, resolution must drop to ~480px, which may significantly degrade cross-view matching accuracy. The original solution draft's approach (benchmark at 480px, abandon if too slow) remains correct.

### Confidence
✅ High — paper benchmarks + hardware specs provide strong basis.

---

## Dimension 3: SP+LG for Satellite Matching (alternative to LiteSAM)

### Fact Confirmation
LiteSAM paper explicitly states "SP+LG achieves the fastest inference speed but at the expense of accuracy" on satellite-aerial benchmarks (Fact #9). SP+LG is a sparse matcher; the paper notes sparse matchers "lack sufficient accuracy" for cross-view UAV-satellite matching due to texture-scarce regions (Fact #13). LiteSAM achieves RMSE@30 = 17.86m; SP+LG is worse (Fact #10).

### Speed Advantage of SP+LG
On Orin Nano Super, SP+LG satellite matching pipeline:
- SuperPoint extraction (both images): ~50-80ms × 2 images
- LightGlue matching: ~80-200ms
- Total: ~180-360ms

This is competitive with the 400ms budget. But accuracy is worse than LiteSAM.

### Comparison with XFeat
XFeat semi-dense: ~50-100ms on Orin Nano Super (from existing draft). XFeat is 2-4x faster than SP+LG and also handles semi-dense matching. For the satellite matching role, XFeat is a better "fast fallback" than SP+LG.

### Conclusion
**SP+LG is not recommended for satellite matching.** It's slower than XFeat and less accurate than LiteSAM for cross-view matching. XFeat remains the better fallback. SP+LG could serve as a third-tier fallback, but the added complexity isn't justified given XFeat's advantages.

### Confidence
✅ High — direct comparison from the LiteSAM paper.

---

## Dimension 4: Other Weak Points in solution_draft01

### cuVSLAM Nadir Camera Concern
The solution correctly flags cuVSLAM's "nadir-only camera" as untested. cuVSLAM was designed for robotics (forward-facing cameras). Nadir UAV camera looking straight down at terrain has different motion characteristics. However, cuVSLAM supports arbitrary camera configurations and IMU mode should compensate. **Risk is MEDIUM, mitigation is adequate** (XFeat fallback).

### Memory Budget Gap
The solution estimates ~1.9-2.4GB total. This looks optimistic if cuVSLAM needs to maintain a map for loop closure. The cuVSLAM map grows over time. For a 3000-frame flight (~16 min at 3fps), map memory could grow to 500MB-1GB. **Risk: memory pressure late in flight.** Mitigation: configure cuVSLAM map pruning, limit map size.

### Tile Search Strategy Underspecified
The solution mentions GeoHash-indexed tiles but doesn't detail how the system determines which tile to match against when ESKF position has high uncertainty (e.g., after VO failure). The expanded search (±1km) could require loading 10-20 tiles, which is slow from storage.

### Confidence
⚠️ Medium — these are analytical observations, not empirically verified.
