Posted by @alex-roba:
Currently, the system applies a safety factor (e.g., 1.2x the threshold) to trigger a retreat to the charger. However, this behavior only seems to work when the robot is idle. During continuous tasks, the robot may operate until its battery drains to a critical level, as the working area it too far from the charger.
I would like to ensure the safety factor is applied during continuous tasks as well, so that the robot can preemptively retreat to the charger without risking battery depletion.
Posted by @mxgrey:
It won’t be feasible in the current generation to support automatic charging intermissions during an active task. There are many tasks where a robot will be carrying a payload that makes it physically impossible to dock with a charger or tasks where it’s crucial for the robot to follow a series of steps without disruption.
In the next generation of Open-RMF we’ll support workflows which will make it much easier to express when a robot should pause a task in order to charge.
Theoretically in the current generation we could support a new type of phase that users can explicitly add to their task description which would check the current battery level and go charge if it falls below a certain threshold. However we are directing all new development efforts towards rolling out the next generation framework. Work on the current generation by the core development team is now limited to bug fixes. I’d be open to reviewing a pull request from an external contributor to add this feature, but I’ll note that the C++ code where it would need to be implemented is a wild jungle, especially with the use of rxcpp.
If you can elaborate more on the nature of your “continuous tasks” I might be able to recommend a workaround. Most likely what will help you the most is to break the one long continuous task apart into a stream of smaller tasks, which creates opportunities for the task planner to insert charging periods.
Posted by @alex-roba:
Hi @mxgrey, thank you for your reply!
I believe there’s a slight misunderstanding. From your implementation, I see that there are two ways a robot can initiate a charging task:
- When the robot is idle using the safety factor mechanism (1.2x threshold) rmf_ros2/rmf_fleet_adapter/src/rmf_fleet_adapter/TaskManager.cpp at 8c26ec48ce798fa176705e55e32a0abd0920cb33 · open-rmf/rmf_ros2 · GitHub.
- In between tasks by rmf_task/rmf_task/src/rmf_task/TaskPlanner.cpp at main · open-rmf/rmf_task · GitHub.
In my implementation, the tasks are small but continuous — I dynamically assign a new task as soon as the current one finishes. As a result, the robot does not enter the “idle” state where it would check the battery threshold every 10 seconds. The only time the robot triggers a charging task is when the task planner detects that the battery is insufficient to accommodate the next task. However, in this scenario, the safety factor (1.2x) is not applied.
This becomes problematic for my setup because my chargers are located far from the working area. Without the safety factor, the robot’s battery level can get too low for it to retreat to the charger in time. When the task planner attempts to insert a charging task, the battery is often already close to the critical threshold, making it risky or impossible for the robot to reach the charger safely.
I’ve found it challenging to add the 1.2x safety factor directly to the task planner, as the implementation is not entirely clear to me. Could you point me to the specific part of the codebase where this modification can be made? Your guidance would be greatly appreciated.
Thanks!
Edited by @alex-roba at 2024-12-03T12:08:37Z
Posted by @mxgrey:
Got it, totally understand now.
I agree that there should be a safety threshold that gets checked before starting the next task, and we should retreat to the charger if we estimate that the next task will bring us below that threshold, even if the planner didn’t expect it to.
I’ve opened Retreat to charger in between tasks if the next task will bring the robot below the safety threshold · Issue #397 · open-rmf/rmf_ros2 · GitHub to track this problem. I’d recommend moving further discussion to that issue ticket.