-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Retreat to charger in between tasks if the next task will bring the robot below the safety threshold #397
Comments
Hi @mxgrey, here's an update regarding the issue: I have only one robot in one of the fleets, and I wrote an automated script to continuously check for running and queued tasks. The script ensures that there is always at least one running task and one queued task. In this scenario, the TaskPlanner will never create a charging task, and the robot will continue performing tasks until the battery is completely drained. |
If you're able to share that script with us, it would be super helpful for us to validate any fix that we come up with. Due to a combination of end-of-year administrative housekeeping and folks going on holiday, we might not be able to produce a fix until mid-January, but any community contributions that help with the testing and validation will speed up our ability to fix the problem. |
Not sure if this is the right location, but maybe we can add in a condition check here? rmf_ros2/rmf_fleet_adapter/src/rmf_fleet_adapter/TaskManager.cpp Lines 1459 to 1470 in bee9778
The TaskManager can check if the SoC has dropped below the threshold and queue a charging task. |
A naive and straightforward way to fix this is to just add in a battery check check prior to running each next task. But there are two concerns I have:
|
Do you think it is right to take references from existing fleet management systems? For example, Mir Fleet has a few settings that dictate such conditions (reference to doc) We can add these to the fleet configuration file and pass it downstream to the task manager. Following this will solve some of our problems, like how long should the robot be charging for, and how much charge the robot needs before leaving the charger. But that also brings us to a potential situation of a robot being held at the charger station with a queue task and another idle robot with sufficient charge to finish the mission. |
@mxgrey here the script
|
Reported in open-rmf/rmf#566 there are situations where a robot's battery can be brought dangerously low if it is given a long series of small tasks.
The task planner will only insert charging tasks if it estimates that the robot will become unable to make it back to the charger without the charging. However the real battery usage may be greater than the task planner estimates, so the robot's battery may become critical if the robot keeps performing tasks.
Each time before beginning a new task we should estimate if doing the next task would bring the battery level below the threshold and redirect the robot to the charger if it would. We could also consider doing a replan of all tasks since the charging would disrupt the schedule, but this should probably be opt-in behavior.
The text was updated successfully, but these errors were encountered: