[Bug]: Fleet Adapter assigns tasks to robots in disconnected sub-graphs (Invalid Bidding & Partial Execution)

[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

When a navigation graph is separated into two disconnected sub-graphs (e.g., Left Zone and Right Zone with no connecting lanes), the Fleet Adapter incorrectly bids for and assigns tasks to robots that physically cannot reach the target waypoint. This results in robots being assigned tasks they cannot complete, leading to an Error status that requires manual cancellation, rather than the task Failing immediately or being assigned to a capable robot.

Steps to reproduce the bug

Map/Graph: office_demo modified to create two isolated islands (Left Side and Right Side).

Modifications: Connecting lanes between the two sides were removed/closed (see attached image).

Fleet: 2 Robots (tinyRobot1 in Left Zone, tinyRobot2 in Right Zone).

Steps to Reproduce:

1. Configure the map so Lounge is in the Right Zone and COE is in the Left Zone.
2. Ensure there are no navigation lanes connecting these two zones.
3. Submit a Loop/Patrol task: Lounge -> COE.

Expected behavior

The task submission should fail immediately (or return impossible) because no single robot can travel from Lounge to COE. No robot should move.

Actual behavior

1. The Fleet Adapter accepts the task.
2. It assigns the task to tinyRobot2 (located in the Right Zone).
3. tinyRobot2 successfully travels to Lounge.
4. Upon reaching Lounge, the robot attempts to plan to COE.
5. Path planning fails (as expected).

Critical Issue: The task status changes to Error (not Failed), and the robot remains stuck at Lounge holding the task until explicitly canceled by the user.

Additional information or screenshots

[xiyuoh]

Hi @alex-roba ! I've tried this out after setting up a clean workspace with all the latest RMF main branches in Jazzy environment, and I can't seem to recreate this exact issue with Dispatch tasks (i.e. sending the task for fleets to bid on). Attaching my modified map (and rviz) and the patrol command used:

ros2 run rmf_demos_tasks dispatch_patrol -p lounge coe --use_sim_time

The fleet does not accept the task bid, not because "planning failed" but because of insufficient battery. However I suspect its limited capacity takes into account failure to plan when estimating capacity. Later, when I submit a patrol task to lounge only, it gets assigned and executed successfully.

Perhaps you can try running this again with a clean RMF build and let me know how it goes! Also feel free to point out if there's a step I'm missing to reproduce this bug. I'm curious to understand why we're getting different results.

On the other hand, if I submit a Direct task {i.e. specifically allocated to a robot when assigning the task), it does successfully add the task to a robot's queue. I believe this is intentional, but would have to ask @mxgrey to weigh in.

Here's the command I used for Direct task:

ros2 run rmf_demos_tasks dispatch_patrol -p coe -F tinyRobot -R tinyRobot2 --use_sim_time

[xiyuoh]

I just noticed that we might have modified our graphs differently, as yours still has a grey rectangle between your waypoints while mine is completely empty. Correct me if I'm wrong, but I believe that means you used lane closure to remove the lanes rather than removing them from your map completely.

I would say having robots accept tasks that involve navigation over closed lanes (not originally disconnected at startup) allows more flexible traffic management beyond the scope of mutex groups. Something that has been useful in our past deployments is closing lanes based on door or lift statuses to ensure that robots don't enter dangerous zones while other building elements are active, and re-opening lanes only when the area is safe.

We still want the robots to accept dispatched tasks and start executing them, especially since some of these travel take several minutes before reaching the danger zones. The robots would only stop at the waypoints near these doors or lifts and wait until the lanes are made available to continue moving.

[mxgrey]

To add to what @xiyuoh was saying in her last comment, the behavior being reported is "working as intended" because lane closure is a temporary condition that could change at any time. I don't think it would be "right" for Open-RMF to automatically cancel a task just because the goal is cut off due to lane closures. That could create system instability if a goal is only momentarily unreachable.

Making that decision requires more context about why and how long the lane will be closed. The current API doesn't have a way to express that context, and it's not immediately obvious how to introduce it. The lane closure feature is not well aligned with creating long-term islands of activity. Maybe we could allow users to specify an estimated finish time for the lane closure, and we can take that into account when doing task planning, but that will require some significant updates to the traffic planner.