Posted by @tonydangct:
Hi,
How exactly does recharge_threshold work? I’m using the current value at this moment:
<!-- Battery level at which the robot ceases to operate -->
<arg name="recharge_threshold" value="0.1"/>
Despite finishing_request being set to nothing, I still expect my robot not to perform any tasks anymore whenever the battery crosses this threshold. However, when the battery drains to a value lower than 10%, my robots are still participating in the bidding procedure for new tasks (when /tasks/dispatch_task is used), and hence still performing tasks. What is the reason behind this behavior, and is there any way to have the desired behavior?
Gist link to my fleet_adapter.launch.xml. Also note that I am still on the galactic-devel branch.
Thanks in advance.
Edited by @tonydangct at 2023-01-30T15:35:59Z
Posted by @Yadunund:
The recharge_threshold is used in a couple of ways. First, during task allocation planning, if the robot’s predicted battery drain after a set of tasks is below this value, the TaskPlanner will automatically include ChargeBattery tasks in between the task schedule such that the robot can go back to the charger to recharge its batteries. Second, while a robot is idle and not at it’s charger waypoint, the fleet adapter periodically checks if the battery drain incurred from moving the robot from its current location to its charger will result in the battery dropped below the recharge_threshold. If so, it will automatically send the robot to its charging station. This is to ensure a robot always has sufficient battery to return to its charging station.
The behavior you described where a robot’s battery level is below the threshold and yet the fleet adapter assigns it a task to perform, sounds like a bug. We do not actively maintain the galactic-devel branch so could you try to create a minimal reproducible scenario with the latest main?
Posted by @tonydangct:
Thanks for the response! After further investigation, I noticed that my statement “that robots with a battery percentage lower than recharge_threshold still participate in the bidding process” is wrong. They don’t directly participate in the bidding process, so the dispatched task always gets assigned to a robot with sufficient battery (if there is one).
However, when a new task is assigned, it seems that the fleet_adapter does a reassignment of the queued tasks:
[start:rmf] [full_control-13] [INFO] [1675166193.991577860] [proto_fleet_adapter]: Assignments updated for robots in fleet [proto] to accommodate task_id [compose.dispatch-11]
which causes the possibility of a queued task to be reassigned to a robot with low battery (even though it never attempted to bid for that specific task). This faulty replanning behavior is definitely present in galactic-devel, I need to check if it is also the case on the main branch.
Posted by @Yadunund:
Sorry to nitpick but to get terminology right, a single robot does not bid for a task itself. Its fleet adapter does this. When a BidNotice is received by the fleet adapter, it first validates whether the fleet is capable of performing such a task. If so, it solves a task allocation problem where it takes all the tasks currently queued across all the robots, adds the new task into the mixture and finds the optimal assignments such that all tasks are completed in the shortest amount of time wrt to their requested start times.
Given this, its hard for me to think of an explanation of the behavior you just shared, ie the planner correctly determines that the robot with battery level below the recharge_threshold can’t perform the task.
so the dispatched task always gets assigned to a robot with sufficient battery (if there is one)
But when replanning after a new task submission, it assigns a task the said robot.
which causes the possibility of a queued task to be reassigned to a robot with low battery
Is there a possibility that the battery level of the robot was incorrectly updated to a value above this threshold between these two planning instances? This could happen within the fleet adapter if you called RobotUpdateHandle::update_battery_soc() for the wrong robot.
Also it looks like you’re submitted a composed task. Are you able to share the contents of this task description? We did recently discover a bug with certain composable activities Fix battery drain estimation in other rmf_task_sequence activites · Issue #78 · open-rmf/rmf_task · GitHub
It would be great if you can reproduce this bug by adding a new test case to our unit test file for composed tasks. You can set the initial_soc to a value below the recharge_threshold to see if you can reproduce the error.