Meta-Ticket for Next-Generation Prototype Traffic Management

[arjo129]

Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

Description

As part of our initiative to transition towards a more “horizontal” architecture in open-rmf, @mxgrey has proposed a six-stage roadmap:
https://discourse.openrobotics.org/t/next-generation-open-rmf-roadmap/53820

Implementation Considerations

This ticket specifically addresses the first phase of this development cycle.

A comprehensive specification for the next-generation prototype is detailed in the following posts:

1. https://discourse.openrobotics.org/t/taxonomy-of-interfaces-for-the-next-generation/44310
2. https://discourse.openrobotics.org/t/traffic-management-interfaces-for-the-next-generation/44414

These posts provide a rigorous specification for next-generation interfaces, sufficient to serve as a baseline for implementing an instance of open-rmf.

Furthermore, several technology demonstrations are available across various repositories:

• CCBS-based MAPF planner: https://github.com/open-rmf/mapf
• PIBT-based high-throughput homogenous planning: https://github.com/arjo129/pibt_rs
• Algorithms for spatio-temporal allocation: https://github.com/arjo129/mapf_post and the associated demo: https://github.com/arjo129/spatio_temporal_partitioning
• Crossflow workflows for Nav2 integration: https://github.com/xiyuoh/next_gen_nav2_traffic
  Additionally, we maintain a mature visualization tool: https://github.com/open-rmf/rmf_site

The objective of this ticket is to establish a concrete action plan for a reference implementation of the open-rmf message specification and Nav2 integration. The next-generation traffic interfaces comprise three primary components:

• Destination Server: Functionally equivalent to RMF’s reservation_node.
• Plan Server: Functionally equivalent to RMF’s rmf_traffic.
• Plan Executor: Previously integrated within rmf_fleet_adapter.

A Minimum Viable Product (MVP) will implement these three layers. For clarity, I have decomposed each component into discrete milestones.

Pass 1

This initial phase prioritizes establishing the core software components; fault tolerance and session_refresh components will be excluded from this scope.

Destination Server

• Implement a basic ROS 2 Rust node that validates incoming destinations and returns an error if occupied. This will utilize the Region message option (graph-based options will be supported in future iterations). See Add reservation destination system #25
• Establish launch testing infrastructure to validate MS1 results. See Add reservation destination system #25
• Implement rerouting logic derived from rmf_reservation_node and update tests accordingly. #9
• Command line tools for calling destination server #10

Plan Server

• Develop a generalized path planning server that processes destination requests and generates map plans, focusing on the Plan.msg message format (See feat: Core MAPF Path Server, Plan Executor, and Visual Tooling #17).
• Integrate a MAPF algorithm within the new interface structure. (See feat: Core MAPF Path Server, Plan Executor, and Visual Tooling #17).
• Deploy basic launch testing infrastructure. (See feat: Core MAPF Path Server, Plan Executor, and Visual Tooling #17 ).
• Command line tools for calling path server #11
• Handle external maps #12

Plan Executor

• Implement PlanRelease.msg support. (See feat: Core MAPF Path Server, Plan Executor, and Visual Tooling #17)
• Implement SafeZone.msg support. (See feat: Core MAPF Path Server, Plan Executor, and Visual Tooling #17)
• Develop a mock Python-based agent to simulate ideal behavior. (See feat: Core MAPF Path Server, Plan Executor, and Visual Tooling #17)

Visualization

• Develop a simple visualization for robots by streaming over http
• launch file with simple end-to-end demo in an open space

Developer Infrastructure

• Develop a docker container pipeline to build core experiences (see chore: Add CI configuration #20)
• Add CI (see chore: Add CI configuration #20)

At the end of Pass 1 we will have a simple playground with swappable algorithms for MAPF and a simple destination server. This will by no means be within parity of the old open-rmf.

Pass 2

The focus of this pass will be on handling failures and edge cases for robots within a free-space

Across All Nodes

• ~session_refresh logic.
• Develop participant registration/deregistration logic.

Path Server/Path Executor

• Implement odometry Time-to-Live (TTL).
• Implement the fleet stalling framework.
• Crossflow integration (figure out what plugins will look like)
• Nav2 integration
  • Introduce nav2 traffic for next gen #21
  • Implement a layered global occupancy map #27
  • [Feature request]: Handle failure to plan given unforseen constraints at a local planning level #37

Visualization

• Develop a simple visualization for robots by streaming over http with rmf_site.

Pass 3

The focus of this pass will be to build out more complex logic

Destination Server

• Develop Graph based approach. Figure out mapping between graph and free-space.