Handle external maps
Maintainers usually reply within 15 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
No implementation files or tests are named. Start by reviewing the rmf_site data model and the planner trait, then compare direct continuous planning with deterministic grid compilation and the proposed obstacle-observation flow. Done means the community has agreed on the map representation, conversion boundary, mutation and invalidation API, and replanning granularity.
Written by the indexing model from the issue text.
Description
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?
- Dominant language
- Python
- Stars
- 10
- Forks
- 9
- Avg merge
- 3h 21m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-rmf/next_gen_prototype
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 8/100
open-rmf/next_gen_prototype#81 ·
Maintainers usually reply within 15 days
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
open-rmf/next_gen_prototype#80 ·
Maintainers usually reply within 15 days
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 35/100
open-rmf/next_gen_prototype#66 ·
Maintainers usually reply within 15 days
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 15/100
open-rmf/next_gen_prototype#65 · 2 comments ·
Maintainers usually reply within 15 days
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 42/100
open-rmf/next_gen_prototype#57 ·
Maintainers usually reply within 15 days
All issues in open-rmf/next_gen_prototype
Similar issues
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
JheysonJhordyHuarauyaRiquelme/sprocguard#18 ·
Maintainers usually reply within 1 day
-
enhancement good first issue help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
dlq/synthpopcan#59 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
mdn/translated-content#40220 ·
Maintainers usually reply within 4 days
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
ETSInitiative/PETSIRD#243 ·
Maintainers usually reply within 1 day
-
deferred p2
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
cuadrao-ai/argus#2160 ·
Maintainers usually reply within 1 day