[Bug]: Support for two consecutive docking waypoints on the same lane (graph rejected due to “duplicate dock” + adapter crash)

[alex-roba]

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

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

OS and version

Ubuntu 24.04

Open-RMF installation type

Source build

Other Open-RMF installation methods

No response

Open-RMF version or commit hash

main

ROS distribution

Jazzy

ROS installation type

Binaries

Other ROS installation methods

No response

Package or library, if applicable

No response

Description of the bug

We have a physical lane where two docking targets are placed back-to-back along the same straight path (see diagram).

When the goal is dock2, and the robot is at wp2, we want RMF to command a dock at dock2.

When the goal is dock1, at the same wp2, we want RMF to command a dock at dock1.
Both docks are consecutive along the same lane segment and cannot be modeled as separate parallel lanes for physical/layout reasons.

I modeled two consecutive docking waypoints on the same lane. Each dock has a distinct name in the UI, but the fleet adapter rejects the graph, reporting a duplicate and then crashes during startup.

[fleet_adapter-17] [ERROR] [1756963940.089569418] [tinyRobot_fleet_adapter]: Graph provided for fleet [tinyRobot] has 1 duplicate lanes:
[fleet_adapter-17] [ERROR] [1756963940.089676273] [tinyRobot_fleet_adapter]: - [dock_13]
[fleet_adapter-17] [ERROR] [1756963940.089687405] [tinyRobot_fleet_adapter]: Each dock name on a graph must be unique, so we cannot add fleet [tinyRobot]
[fleet_adapter-17] Starting fleet adapter...
[fleet_adapter-17] Traceback (most recent call last):
  ...
[fleet_adapter-17]     fleet_handle.more().set_planner_cache_reset_size(2500)
[fleet_adapter-17] AttributeError: 'NoneType' object has no attribute 'more'
[fleet_adapter-17] terminate called after throwing an instance of 'std::system_error'
[fleet_adapter-17]   what():  Resource deadlock avoided
[ERROR] [fleet_adapter-17]: process has died ...

Steps to reproduce the bug

modeled two consecutive docking waypoints on the same lane

Expected behavior

No response

Actual behavior

No response

Additional information or screenshots

No response

[mxgrey]

I completely agree. The main blocker is that the data structures of the traffic editor currently has dock as a vertex property when it should really be a lane property. This originated back in the earliest days of the project when we treated "dock" as a noun describing a location that needs to be docked into, whereas in many deployments it's more useful to think of "dock" as a verb, so it should be a property of a lane.

In fact even rmf_traffic considers Dock to be a lane event, not a vertex property. We go through significant trouble to interpret the vertex property from the traffic editor as a lane event in rmf_traffic. In the site editor, it's natively a lane motion property.

For backwards compatibility reasons, we can't remove dock as a vertex property, but there's nothing to stop us from additionally making it a lane property. Someone would need to make the following PRs:

• Update the data structures in traffic-editor [1][2] to allow dock and reverse_dock as lane properties (we need reverse_dock so that docking along the reverse direction of a lane can be distinct from docking along the forward direction).
• Update parse_graph to account for these new lane properties.
• Update the site editor legacy parser to add the lane property and convert it to the new format.

In the interest of making the next generation available as soon as possible, the core Open-RMF team is not committing time to do feature development for the traffic-editor, but we'd be open to reviewing PRs from interested community members to introduce such a feature.