The radar reveals a striking asymmetry: Annie's VLM-primary approach and the traditional SLAM-primary approach are almost perfectly complementary anti-profiles. Where one peaks, the other troughs. Annie scores 85–90 on Perception Depth and Semantic Richness but only 30–35 on Spatial Accuracy and Robustness. SLAM-primary scores 88–92 on Spatial Accuracy and Robustness but collapses to 20–30 on any axis requiring understanding of what things are. This complementarity is exactly the premise for a hybrid — but it also means each approach fails on exactly the axes where the other excels, and the failure modes are not graceful. An SLAM-only robot gets permanently lost when a room rearranges. A VLM-only robot drives confidently into the leg of a chair because it cannot distinguish "the chair is at 250mm" from "the chair is at 600mm".

The tradeoff that researchers consistently decline to acknowledge is the robustness axis as a network reliability question. Every benchmark in the literature — VLMaps, OK-Robot, NaVid, text2nav — measures VLM accuracy assuming an always-on GPU. None of them measure what happens when the WiFi hop between the robot and its inference node drops for 80ms, or when the Panda llama-server process restarts mid-navigation (session 83: Annie's IMU became REPL-blocked, requiring a soft-reboot Ctrl-D). The research community treats inference latency as the latency problem; the actual production latency problem is network jitter. A 58 Hz VLM pipeline that hiccups for 300ms every 45 seconds due to a 2.4GHz congestion burst is not a 58 Hz system — it is a system that produces bursts of stale commands. The radar's "Robustness" axis score of 35 for Annie captures this honestly: the failure mode is not algorithmic, it is infrastructural and invisible in papers.

The cyan dashed polygon shows the single largest structural move available on this radar: activating the idle Hailo-8 AI HAT+ on the Pi 5 as an L1 safety layer (26 TOPS, YOLOv8n at 430 FPS, <10ms local inference, zero WiFi dependency). The Robustness axis jumps from ~35 to ~65 — the biggest single-axis delta any non-hardware-swap move produces on this chart. Why? Safety-critical obstacle detection no longer rides the same WiFi hop as semantic reasoning. The semantic path (Gemma 4 E2B on Panda for "where is the kitchen?") still depends on WiFi, so the robustness ceiling doesn't reach SLAM-primary's 88 — but the compound failure mode collapses: a WiFi brownout no longer simultaneously silences obstacle avoidance and goal reasoning. The IROS dual-process paper (arXiv 2601.21506) measured this exact pattern yielding 66% latency reduction and 67.5% success vs 5.83% VLM-only. The trade is visible on the Implementation Simplicity axis, which edges down from 40 to ~32: HailoRT, TAPPAS, and model compilation add real cognitive load, but the learning curve is days, with working Pi 5 examples at github.com/hailo-ai/hailo-rpi5-examples. This is the cheapest robustness move available on Annie's current hardware, because the hardware is already on the robot.

Two tradeoffs are movable by a fundamentally different approach, not just by tuning along the existing frontier. First: the spatial accuracy deficit (Annie: 30) can be largely eliminated without touching the VLM at all, by using lidar sectors as a pre-filter before the VLM command is issued — the existing NavController already does this via ESTOP gates. The VLM never needs metric precision; it only needs directional intent. Metric precision is the job of the lidar ESTOP. This reframes the tradeoff: Annie does not sacrifice spatial accuracy to gain semantics — it delegates spatial accuracy to a different component. Second: the VRAM efficiency gap (Annie: 45 vs SLAM: 80) is addressable by the embedding-only path described in Part 2 of the research. Running SigLIP 2 ViT-SO400M (~800MB VRAM) for place recognition instead of the full E2B model for embedding extraction changes the cost structure substantially. These are not points on the same frontier — they are structural moves that open new parts of the design space.

The user's actual priority ordering diverges from the researcher's in one specific place: Implementation Complexity. The research literature treats complexity as a constant ("one-time engineering cost") and optimizes for runtime metrics. In practice, session 89 shows that a single Zenoh version mismatch (apt package at 0.2.9, source build at 1.7.1) consumed an entire development session. The radar gives SLAM-primary a score of 30 on Implementation Simplicity — not 70 — because "simple in theory" and "simple to deploy on ARM64 with rmw_zenoh_cpp from source" are not the same axis. For a single-developer project, implementation complexity IS a first-class runtime constraint: a system you cannot debug in-field is effectively unavailable. The implicit researcher assumption — that deployment effort amortizes to zero over many robots — does not apply here.