Auto-recharge task dispatched to decommissioned robot with `idle_behavior=false`

Open-RMF Open-RMF General
1

Hi,

I noticed that when a robot is decommissioned with allow_idle_behavior=false and its current task is cancelled, the system still automatically dispatches a charging task to the robot if the battery is below recharge_threshold.

I tested this with the office demo on ROS2 Jazzy with the following configuration:

# tinyRobot_config.yaml
recharge_threshold: 0.50
recharge_soc: 1.0
finishing_request: "charge"
account_for_battery_drain: True

Here is what I did:

  1. Dispatched a long patrol task to tinyRobot2
  2. Waited until the battery dropped below recharge_threshold (50%)
  3. Decommissioned the robot with idle_behavior=false:
    POST /fleets/tinyRobot/decommission?robot_name=tinyRobot2&reassign_tasks=false&allow_idle_behavior=false
  4. Cancelled the patrol task:
    POST /tasks/cancel_task
{"type": "cancel_task_request", "task_id": "<TASK_ID>"}

After this, a new charging task was automatically dispatched to the robot, and it moved to the charger and began charging — even though the robot was decommissioned (dispatch_tasks=false, direct_tasks=false, idle_behavior=false).

I assumed that decommissioning with idle_behavior=false would prevent all autonomous behaviors including auto-recharge, but the charging task triggered by recharge_threshold was still dispatched.

I have two questions:

  1. Is the auto-recharge task (triggered by recharge_threshold) intentionally treated differently from idle behavior (finishing_request)? Is this a safety mechanism to prevent battery depletion regardless of commission state?
  2. If we want to fully stop a robot (no tasks, no charging, no movement) via the API, what is the recommended approach?

Thanks in advance.

2

Hi @Akio-Ki ! Good questions,

Is the auto-recharge task (triggered by recharge_threshold) intentionally treated differently from idle behavior (finishing_request)? Is this a safety mechanism to prevent battery depletion regardless of commission state?

Yes, this is most likely the emergency charging task triggered here, which is before any consideration of the commissioning state of the robot here.

It is an emergency state where it will almost have not enough battery to head back to its charger, which may require manual charging by an operator. (We’ve encountered this concern by operators in deployments before).

If we want to fully stop a robot (no tasks, no charging, no movement) via the API, what is the recommended approach?

We don’t have a mechanism to handle that at the moment. However depending on consensus, the current behavior might not be ideal, especially if the robot needs to be manually operated or repaired and should remain still, but decides to start heading back to the charger.

I’ve opened these two PRs, and verified that it should resolve your situation, please take a look.

In the meantime, I’ll see if I get buy-in from the other maintainers that this is the ideal behavior in this edge case.

edit:@Akio-Ki it’s been merged now, so it will be accessible through main