Phase 2c attaches VLM scene labels to SLAM grid cells "at current pose." This requires knowing the precise spatial transform between the camera's optical axis and the lidar's coordinate frame. Without calibration, a label generated by the camera at angle A lands on a lidar cell at angle B — semantic labels drift from the obstacles they describe. The research never mentions this. Calibration requires a checkerboard target, multiple capture poses, and a solver (e.g., Kalibr). It is a multi-hour process that must be repeated if the camera or lidar is physically moved. See also Lens 03 (the llama-server embedding blocker is a similar hidden prerequisite — a dependency that blocks a phase without being named as a prerequisite).

The research mentions EMA filtering for single-frame noise but never addresses systematic hallucination — when the VLM confidently and persistently reports something false (e.g., "door CENTER LARGE" for a wall). Confidence accumulation makes this worse: after 5 consistent wrong frames the system goes faster toward the obstacle. There is no detection mechanism (e.g., VLM says forward-clear, lidar says blocked at 200mm → flag as hallucination), no recovery protocol, and no degraded-mode fallback. This is the most dangerous gap in the design. See also Lens 10 ("we built the fast path, forgot the slow path") — hallucination recovery IS the slow path for VLM navigation.

The 4-tier architecture requires Panda (VLM, Tier 2) to be reachable from the Pi (Tier 3/4) over WiFi. Lens 04 identified the WiFi cliff edge at 100ms latency — above that, nav decisions arrive stale. This research never described what happens when WiFi degrades: Does the robot stop? Fall back to lidar-only reactive nav? Continue on the last valid VLM command? Update (2026-04-16, session 119 hardware audit): The gap is now partially closable at zero hardware cost. The Pi 5 already carries a Hailo-8 AI HAT+ (26 TOPS) that is currently idle for navigation. Running YOLOv8n locally on the Hailo delivers ~430 FPS of obstacle detection with <10 ms latency and zero WiFi dependency — exactly the "fast safety layer" the degradation protocol needs. An IROS paper (arXiv 2601.21506) validates the dual-process pattern (fast local reactive + slow semantic remote) and reports a 66% latency reduction vs. continuous-VLM. Status transitions from "open / no mitigation" to "mitigation path identified; integration work pending." The residual gap is no longer "what happens when WiFi drops" — it is Gap 3a below.

This is the specific closable work implied by Gap 3's mitigation path. The Hailo-8 AI HAT+ sits on the Pi 5's PCIe lane at 26 TOPS, drawing power and occupying physical space, and contributes nothing to navigation today. Activating it requires: HailoRT/TAPPAS runtime install on the Pi, a YOLOv8n HEF model compiled for Hailo-8, a ROS2/zenoh publisher that emits bounding boxes + class IDs, a fusion node that combines Hailo detections with lidar ESTOP (lidar still wins on transparent-surface false positives), and a WiFi-down regression test that verifies the robot can still avoid a chair with Panda unreachable. This is not a research gap — it is a prioritization gap: a 26 TOPS accelerator on-robot is orders of magnitude more capable than the lidar-only fallback that was implicitly assumed for WiFi outages. See also Lens 04 (WiFi cliff-edge) and Lens 25 (process gap — owned-hardware audit was skipped).

Already present on the robot. YOLOv8n reference throughput: 430 FPS local, <10 ms, zero WiFi dependency. Closes Gap 3 if integrated (see Gap 3a). The fact that this accelerator was not considered in the original 4-tier architecture is itself the finding — the research specified a Pi tier and a Panda tier without auditing what the Pi was already capable of.

A second DGX Spark node with 128 GB of unified memory is powered on 24/7 and carries no production workload following the single-machine consolidation onto Titan. Potentially suitable for: offline benchmark sweeps, a dedicated SLAM/perception compute node, an alternate-region replica for resilience, or a dedicated training surface for vision models (YOLOv8n distillation for Hailo, Gemma LoRA). The research proposed new workloads without first checking what existing compute was unused — a dormant 128 GB node is a larger capacity reservoir than the entire Pi+Panda stack combined.

Jetson Orin NX 16GB (100 TOPS, Ampere GPU) is user-owned and reserved for a future robot chassis, currently not powered. This is the highest-capacity edge compute unit in the inventory and has no carrier board wired. If a stereo camera were added, the Orin NX becomes the natural on-robot host for nvblox + cuVSLAM — a path the current Pi 5 cannot take. Tracking it here so that Phase 3+ planning starts from "we own a 100 TOPS robotics SOC" rather than re-deriving the hardware budget from scratch.

Phase 1 SLAM builds the occupancy grid that Phase 2c annotates with semantic labels. The research describes building this map but not protecting it. What happens when slam_toolbox's serialized map is corrupted by a power loss mid-write? When the map diverges from reality after furniture rearrangement (Gap 15)? When the robot is carried to a new location and the prior map is now wrong? Map corruption is silent — the robot will navigate confidently into walls. Recovery requires map versioning, integrity checks, and a "map invalid" detection heuristic (e.g., lidar scan consistently disagrees with map prediction).

The research treats obstacles as static ("nearest obstacle? chair/table/wall/door/person/none"). But in a home, a person walks through the frame at 1.5 m/s — 10x the robot's speed. A single-class "person" label tells the robot nothing about trajectory. Should it wait? Predict the path? Follow? The Waymo section explicitly covers MotionLM trajectory prediction for agents, then dismisses it as "not directly applicable (no high-speed agents in a home)." This is the most vulnerable sentence in the research: it is simply wrong. A 2-year-old child or a cat IS a high-speed agent in a home that moves faster than the robot can react at 1-2 Hz planning frequency.

A home robot's most frequent use case is lights-off or dim-light navigation — fetching water at night, patrolling while the family sleeps. The VLM requires adequate illumination for scene classification and goal-finding. Below ~50 lux, VLM confidence drops dramatically and hallucination rate rises. The research never mentions this. Solutions exist (IR illumination, lidar-only fallback mode, ambient light sensor gating VLM trust weight) but none are discussed. This gap means the system described has a usage hours ceiling of roughly 8am–10pm — exactly the opposite of when autonomous home navigation is most useful.

The research describes autonomous exploration for map-building but never addresses the energy budget. The TurboPi with 4 batteries has a runtime of approximately 45–90 minutes under load (motors + Pi 5 + camera + lidar + WiFi). During Phase 2d embedding extraction, the VLM runs continuously on Panda — additional WiFi traffic increases Pi power draw. There is no power-aware path planning (prefer shorter routes when battery low), no return-to-charger trigger, and no low-battery ESTOP. A robot that runs out of power mid-room is worse than one that never moved — it becomes an obstacle itself.

Phase 2c/2d builds a semantically annotated map of the home — every room labeled, every piece of furniture positioned, camera embeddings indexed by location. This is a detailed surveillance record of domestic life. The research never mentions where this data is stored, who can access it, how long it persists, or whether guests consent to being observed and classified ("person" label in the obstacle classifier). For her-os specifically (a personal ambient intelligence system), the spatial memory intersects with conversation memory — the system knows both what was said AND where the robot was when it was said. This combination is more privacy-sensitive than either alone.

The research describes a system that requires Phase 1 SLAM to be deployed before Phase 2 can function. Phase 1 requires the robot to explore the entire home to build the map. Who drives the robot during this exploration? What does the user experience when the map is empty and navigation is impossible? The "evaluation framework" section specifies what data Phase 1 must log — but not how a non-technical user initiates the mapping process, monitors its progress, or recovers from a failed mapping run. The first-run experience determines whether users adopt the system or abandon it after the second session.

A home robot built around Annie's voice capabilities has access to an unused sensor: sound source localization. A person calling "Annie, come here" provides a bearing to the speaker that neither camera nor lidar can match at distance. Sound travels around corners and through walls. The research focuses entirely on visual and geometric perception — the acoustic dimension is completely absent. For her-os specifically, where the robot's primary purpose is conversational companionship, voice-directed navigation ("I'm in the kitchen") is a more natural interaction pattern than visual goal-finding and should be a first-class input to the planner.

SLAM drift is cumulative. After weeks of operation, the occupancy grid will have small errors that compound. slam_toolbox uses scan-matching for loop closure to correct drift, and Phase 2e adds AnyLoc visual confirmation. But neither the research nor the roadmap specifies a drift correction schedule: How often should the robot re-survey the home? What triggers a global re-localization? How are semantic labels migrated when the underlying occupancy grid is updated? The 6-month map becomes less reliable than the 1-week map — and the system has no mechanism to detect or correct this degradation.

Indian homes rearrange furniture frequently — seasonal, guests, festivals, daily prayer setups. The Phase 1 SLAM map bakes in the furniture layout at time of mapping. When a sofa moves 1 meter, the SLAM system will experience localization failures as the scan disagrees with the stored map. The research never describes how the system detects that a map region is stale vs. that the robot is lost. This gap connects directly to the map corruption gap (Gap 4) and the long-term drift gap — they share the same failure mode: the map is wrong and the system doesn't know it.

The TurboPi cannot climb stairs. This gap is correctly implicit — there is no stair-climbing mechanism, so multi-floor navigation is physically impossible. However, the research's silence is still meaningful: it never establishes the single-floor constraint explicitly, meaning a future implementer reading this document might attempt to path-plan across floors without realizing the physical impossibility. Explicit scope declarations matter as much as what is included.

The research is implicitly scoped to indoor home navigation, but never states this boundary. The VLM's scene classifier ("kitchen/hallway/bedroom/bathroom/living/unknown") has no outdoor classes. If the robot is moved outdoors (courtyard, balcony), the SLAM map becomes invalid, the VLM scene labels become "unknown," and the lidar gets confused by vegetation and open space. Like multi-floor, the correct response is to state the boundary explicitly rather than leave it implicit.

The research implicitly assumes a single-robot home. If a household has two Annie units (future), should they share the occupancy grid? Share the semantic annotations? Share place embeddings? Shared maps create a 2x improvement in exploration coverage but require conflict resolution when two robots annotate the same cell with different labels at different times. This gap is low priority now but the architecture choice (centralized vs. per-robot map storage) made in Phase 1 will determine whether this is possible at all.

The research defines ESTOP as "absolute priority over all tiers" for obstacle collisions. But it never defines behavior for whole-home emergencies. If a smoke detector triggers, should the robot navigate to the nearest exit and wait there as a beacon? Alert family members via Telegram? The 4-tier architecture has no emergency tier above the strategic tier. For a home robot with spatial awareness, emergency wayfinding is a natural capability — and its absence means the most high-stakes scenario is also the least specified.

Glass doors, glass dining tables, and glass-fronted cabinets are common in Indian homes and are invisible to lidar (the laser passes through). The research's "fusion rule — VLM proposes, lidar disposes" fails here: lidar says "clear" (the laser returned nothing), VLM says "BLOCKED" (it can see the glass door), and the fusion rule discards the VLM's correct observation in favor of lidar's false negative. Glass surfaces are the one physical scenario where VLM must override lidar, but the research establishes no mechanism for this exception.

The roadmap provides P(success) estimates but no P(worthwhile) estimates. Phase 2c (semantic map annotation) has P(success)=65% and requires 2–3 sessions of implementation. But what does success actually buy? The research never quantifies: How much does semantic map annotation improve navigation success rate? Does it reduce average path length? Reduce collision frequency? The evaluation framework in Part 7 defines metrics but never connects them to phase gates — there is no specification of "if metric X does not reach threshold Y, skip Phase Z." Each phase is treated as inherently worthwhile if it succeeds, which is not the same thing.