[Bug]: Battery estimation not recalculated after charging task cancellation

[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

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 robot is charging and a future task is assigned, OpenRMF estimates the battery level after the charging task finishes and uses that value for feasibility checks. If the charging task is later cancelled before completion, the robot still proceeds with the next task using the outdated battery estimate that assumed the robot would be fully charged.

Steps to reproduce the bug

1. Send the robot to charge (charging task).
2. While charging, assign a new task that will start after charging is expected to complete.
3. This task is accepted because the estimated battery after charging is high enough.
4. Cancel the charging task before it finishes (robot is still below full charge).
5. The robot begins the previously scheduled task using the original estimated battery instead of the actual current battery.

Expected behavior

1. When a charging task is cancelled, OpenRMF should recalculate the available battery for any pending tasks.
2. Tasks that are no longer feasible due to insufficient battery should be cancelled or rescheduled.

Actual behavior

The robot starts the next task as if it had the full battery it was expected to have after charging.
In reality, the battery is much lower (often only the charging threshold).
If the task requires more energy than is available, the robot can run out of battery before completion.

Additional information or screenshots

No response

[mxgrey]

One thing that can help mitigate this problem is #423 which I believe is ready to be merged now.

I think the only other approach we could take is to trigger a replan for the robot after a charging task is cancelled. That would also raise the question of whether we should replan a robot's tasks after every task cancellation or only after a charging task is cancelled?

Tasks that are no longer feasible due to insufficient battery should be cancelled or rescheduled.

As of right now we have a policy to not automatically cancel tasks from the core Open-RMF nodes. We want any decisions about task cancellation to come from system integrator. But automatic rescheduling does fit within our current policies.