docs: add layered map follow-up plan

Signed-off-by: SamuelFoo <fooenzesamuel@gmail.com>

Author: SamuelFoo

discourse/4-layered-global-map-follow-ups.md

@@ -0,0 +1,86 @@
+[Draft for Discourse]
+
+# Layered Global Map Follow-ups
+
+This post collects the next pieces to build after the first layered global occupancy map implementation.
+
+# Quick Summary
+
+* Use an approximately `0.5 m` global planning grid in the demos
+* Downsample local Nav2 costmaps before publishing global map observations
+* Add a Nav2 observation publisher that emits `MapRegionUpdate` messages
+* Visualize replanning behavior in the demo
+* Add active-plan collision checking so paths can be invalidated after publication
+* Keep blocked-path reporting and replan debouncing separate from map composition
+
+# Planning Resolution
+
+Use a global planning map cell size around `0.5 m`. This matches the rough size of the robots used in the current demos and keeps the MAPF problem smaller than a dense local Nav2 costmap.
+
+Downsample local robot costmaps to the global planning resolution before publishing region updates. In practice this means a cluster of fine local costmap cells becomes one or more coarser `Region` updates on `/map/region_updates`.
+
+Keep resampling policy outside the layered map server. The demo and map-loading configuration should use a static map resolution close to the desired MAPF planning resolution, initially `0.5 m`.
+
+# Nav2 Observation Node
+
+Add a node that reads a robot's Nav2 local costmap and publishes `MapRegionUpdate` messages.
+
+The first version should:
+
+1. Subscribe to a local `nav2_msgs/Costmap`, such as `~/local_costmap/costmap_raw`.
+2. Threshold lethal and inflated cells into a binary obstacle mask.
+3. Optionally subtract cells already occupied by the static map.
+4. Downsample to the global planning resolution, initially around `0.5 m`.
+5. Group adjacent cells into connected components.
+6. Publish components as axis-aligned rectangle regions with a short TTL.
+
+Keep the observation interface generic enough for robots with richer perception stacks to publish `MapRegionUpdate` messages without using this Nav2-specific node.
+
+# Replanning
+
+Avoid triggering global replanning directly from every map update. Local observations may arrive frequently, and many will not affect the current traffic plan.
+
+Handle blocked-path reporting separately. The existing `~/plan/error` topic already includes `PlanError.CODE_PATH_BLOCKED`, which can be used by a Nav2 traffic bridge or plan executor when a robot can no longer progress through its current safe zone. That follow-up can debounce replan requests and ask the path server to plan again using the latest composed map.
+
+Add an active-plan collision check after a path has been sent out. The check should compare the robot's current plan or safe zone against the latest composed map and publish `CODE_PATH_BLOCKED` when the remaining path is no longer traversable.
+
+# Testing and Visualization
+
+Make replanning visible before considering the loop complete. A useful test scenario is:
+
+1. Start with the static map from the map-loading work in `open-rmf/next_gen_prototype#22`.
+2. Send two robots through the path server and visualize their published plans.
+3. Publish a temporary obstacle region with a TTL onto `/map/region_updates`.
+4. Confirm in RViz or the web visualizer that the composed `/map` includes the temporary obstacle.
+5. Trigger a blocked-path report for the affected robot and confirm that the next plan avoids the obstacle.
+6. Let the TTL expire and confirm that the obstacle disappears from `/map`.
+
+Add an integration test for the whole loop by publishing an obstacle, reporting a blocked path, and checking that the next path differs from the original path.
+
+# Suggested PR Split
+
+## PR 1: Demo and Path Server Wiring
+
+Update the demo so the static map is remapped to `/map/static`, the layered map server is launched, and the path server continues to consume `/map`.
+
+The acceptance test should use an approximately `0.5 m` planning grid and show that adding a dynamic obstacle changes the next path produced by the path server.
+
+## PR 2: Nav2 Observation Publisher
+
+Add a Rust observation node that converts a local Nav2 costmap into `MapRegionUpdate` messages.
+
+The node should downsample the local costmap to the global planning resolution before publishing regions. The demo should show an obstacle observed by a robot appearing in the layered global map and then expiring when it is no longer refreshed.
+
+## PR 3: Active-plan Collision Checking
+
+Add a check in the plan executor or Nav2 traffic bridge that compares the remaining active plan or safe zone against the latest composed map.
+
+When the remaining route is blocked, the component should publish `PlanError.CODE_PATH_BLOCKED` and let the existing replan flow request a new path.
+
+# Future Extensions
+
+* dense grid or delta-grid update messages
+* voxel or 3D observation components
+* semantic map layers
+* a map revision/status topic for consumers that need to correlate plans with a specific composed map version
+* smarter region compression for irregular obstacle shapes