Handle external maps

[arjo129]

Context & Problem Statement

The next-generation Open-RMF core intentionally leaves map representation abstract to preserve framework pluggability. However, to build out a robust reference implementation, we must establish a concrete baseline format.
This issue addresses how the next-gen core should ingest, represent, alter, and expose spatial data to multi-agent path finding (MAPF) planners and fleet adapters.

Core Architectural Pillars

The Source of Truth: Semantic Lanelets via rmf_site

Instead of inventing a new map format, the reference implementation should natively rely on rmf_site (.site.ron) as its primary structural data model. It provides precise geometric primitives (points, lanes, polygons) along with critical semantic anchors (lifts, doors, speed zones).

The MAPF Gap: Bridge to Grid-World Topologies

Most state-of-the-art MAPF research (e.g., CBS, PBS) operates natively on uniform 2D grid worlds with discretized timesteps. Since Open-RMF natively uses rich, non-lattice lane networks via rmf_site, we face an optimization trade-off:

• Path A (Direct Continuous Planning): Adapt continuous-time, graph-based variants of MAPF (like SIPP/CCBS extensions) directly onto the parsed topological lanes.
• Path B (Deterministic Discretization): Implement a compilation layer that projects the topological rmf_site lanes onto a high-resolution grid world. The planner solves on the grid, and the resulting paths are mapped back to continuous fleet trajectories.

Ideally, our planner trait should be able to consume a generic Map object and depending on the user's choice of algorithm we should be able to re-cast

Dynamic Feedback Loop: Observation-Driven Replanning

Maps are rarely static. The reference architecture must support real-time map mutations driven by fleet observations (e.g., a robot's LiDAR detecting an unmapped obstacle or a localized costmap blockage). When an obstacle is reported, the architecture must support:

• Map Mutation: Dynamically introducing a temporary block or cost penalty to the specific region/grid cells.
• Planner Invalidation: A trigger mechanism that instantly signals the MAPF planner that the map topology has changed.

Proposed Technical Scope & Questions for the Community

• Map Compiler Architecture: Should the reference implementation ingest .site.ron directly into the core scheduler, or should map conversion (to grids or sparse routing graphs) live behind a modular plugin interface?

• Observation Ingestion API: How should fleet adapters broadcast obstacle observations? Do we introduce a standardized ObstacleObservation message that carries a geometry payload (bounding box/point cloud) and an estimated time-to-clear?

• Replanning Granularity: When a map update occurs, how do we avoid a costly global replan for all 100+ robots? Can we leverage incremental MAPF techniques or sub-graph replanning?

[arjo129]

For the initial iteration, I propose using Occupancy Grids. The primary rationale is that we can already export occupancy grids directly from rmf_site. Furthermore, integrating Occupancy Grids into MAPF planners is straightforward and ensures seamless compatibility with existing tools. This coupling between a robot's local costmap and a global costmap is particularly critical for processing live observation updates, making it central to future nav2_native implementations.

Currently, the MapfPlanner trait does not accept any map input. To address this at the implementation level, we could introduce a WorldMap struct to encapsulate the data. An algorithm requiring an occupancy grid or a navigation graph could then simply call an occupancy_grid() or nav_graph() method, respectively. However, I would caution against framing this design as a 'standard'; it should be treated strictly as an implementation detail of our reference path_server.

[Briancbn]

Sorry I haven't fully read through your implementation yet, so apologies if the following suggestion doesn't match well with the current or it's already implemented.

Map Compiler Architecture: Should the reference implementation ingest .site.ron directly into the core scheduler, or should map conversion (to grids or sparse routing graphs) live behind a modular plugin interface?

Path A (Direct Continuous Planning): Adapt continuous-time, graph-based variants of MAPF (like SIPP/CCBS extensions) directly onto the parsed topological lanes.
Path B (Deterministic Discretization): Implement a compilation layer that projects the topological rmf_site lanes onto a high-resolution grid world. The planner solves on the grid, and the resulting paths are mapped back to continuous fleet trajectories.

The compilation layer and map conversion can be opted-in so that it can work with both.

"Path B" + "Compilation Layer" = Path A

• In Path B + Compilation Layer, the map conversion is needed, but the map conversion can be generated by rmf_site separately.
• In Path A, the map conversion and compilation layer will not be needed.

I also think that we should NOT aim for 1 solver / planner instance will solve all the robots in every area, instead different solvers can be used based on regions or run in parallel for the same region.

In our use case, some areas

• warehouse with 100 amrs and shelves (more path B)
• manufacturing line with 2 amrs interacting with machines (more path A or even solvable by exist planner)

For the reference implementation, we can also have the existing RMF solver (CBS like with velocity) as a Path A example to provide OpenRMF user a realistic way to migrate to next gen.

Replanning Granularity: When a map update occurs, how do we avoid a costly global replan for all 100+ robots? Can we leverage incremental MAPF techniques or sub-graph replanning?

MapfPlanner can have different implementation, we just provide the event and reason that is triggering the replanning, whether MapfPlanner will do subgraph or global is up to the implementation.

The specific sub-graph or incremental techniques, can be implemented later and provided as opt-in.

For the working system, we can provide a simple planner that plans fast for 100 to provide a good enough implementation first.

[Briancbn]

For the initial iteration, I propose using Occupancy Grids. The primary rationale is that we can already export occupancy grids directly from rmf_site.

I agree with this, another benefit is that occupancy grid is also compatible with RViz, providing the nav2 user an out of box way to visualize the mapf solution against the robot movement.

My concern is that occupancy grids might be relatively difficult to modify on file, it might be hard for people that just want to test out the solver.

Just a thought on alternative formats like .csv files 😂. It can be easily edit and modify on Excel.
name.csv

P1,P2,P3,P4
P5,P6,P7,P8
P9,P10,P11,P12

ostacles.csv

0,0,0,1
1,0,0,0
0,0,0,0

More...

[arjo129]

I also think that we should NOT aim for 1 solver / planner will solve all the robots in every area, instead different solvers can be used based on regions or run in parallel.

This is a good idea. The current architecture allows for MAPFPlanner to implement any underlying trait. For fast prototyping I started with PIBT, but it is very much possible to implement your own custom planner by simply implementing the trait.

This ticket specifically is about Map representation. It is not about MAPF planners. The Map representation would be passed into MAPF planners.

I agree with this, another benefit is that occupancy grid is also compatible with RViz, providing the nav2 user an out of box way to visualize the mapf solution against the robot movement.

I was not really thinking of ROS interfaces. I was thinking more along the lines of the API we feed the MAPFPlanner trait. But yes, we would subscribe to an occupancy grid topic.

Just a thought on alternative formats like .csv files 😂. It can be easily edit and modify on Excel.

I think the current interface architecture provides a nice way to log and capture incoming mapf problems. We can open a ticket about logging incoming and replaying potential mapf "scenarios".