Posted by @b-Tomas:
In a full control fleet adapter based on full control fleet adapter template, the RobotCommandHandle::dock() is never called.
Using traffic-editor a waypoint was set as is_charger and was given a dock_name
In adapter.config.yaml, that waypoint was set as start waypoint and as charger waypoint for the robot. finishing_request in task_capabilities of the fleet configuration is set to charge, and both recharge_threshold and recharge_soc are set, as well as account_for_battery_drain.
In the RobotAPI I can see that the battery level is being retrieved correctly.
The observed behavior is:
- The robot moves to the charger waypoint at start, as it was set in the config
- After a task, it goes back to that point, as expected
- When the battery level is below
recharge_thresholdthe robot does not get any tasks assigned, but also doesn’t dock - the
dockmethod ofRobotCommandHandleis never called
The dock method implementation is irrelevant, because it doesn’t get executed anyways.
Seeing the example configs in rmf_demos I don’t see any relevant difference in the configuration files, but I might be missing something important.
In what situations is rmf supposed to order the robot to charge?
For reference, this is the vertex definition of the dock in my *.building.yaml file, from traffic-editor:
- [76.448999999999998, 279.62799999999999, 0, dock, {dock_name: [1, dock], is_charger: [4, true]}]
And in my nav_graph.yaml:
- {dock_name: dock, is_charger: true, name: dock}
Thanks in advance.
Edited by @b-Tomas at 2023-02-15T15:54:31Z
Chosen answer
Answer chosen by @b-Tomas at 2023-02-17T14:30:55Z.
Answered by @mxgrey:
Just to clarify your description: After finishing a task, the robot returns to its charging point on the graph, but it sits there idle because it does not need to charge yet? Then some time later, while it is still sitting at its charging point, it does need to charge (because the battery gradually drains, even while doing nothing), but nothing happens?
I think the issue here might be that Open-RMF is currently making an assumption that any time the robot is ordered to go to its charging waypoint, it will connect with its charger and immediately begin charging.
The current implementation of the “charging task” is to tell the robot to go to its charging waypoint on the graph and then wait there until its battery level is high enough. There isn’t an explicit command to “begin charging now”. Instead it’s assumed that the dock method for the charging waypoint will take care of connecting the robot to its charger.
Now, the reason it’s not working in your specific case: The dock command is only triggered when the robot is moving to the charger waypoint from another waypoint. If the robot reports itself as already being on its charging point then the planner believes there is no reason to tell the robot to dock.
All that being said, I would expect the dock command to be triggered when the robot is returning to its charging point after performing a task. Is that not the case? If not, then maybe there’s something else wrong that I’m not thinking of.
If it’s possible, I would recommend having the robot connect to its charger every time it returns to its charging point. That will allow your system to align with the current assumptions of Open-RMF and should fix this issue immediately. If that’s not possible or acceptable for some reason, we could consider adding a step to the Charging task that explicitly triggers a signal to command the robot to connect to a charger once it arrives at its charging point. This would be separate from the docking procedure, since docking is meant to happen when moving from one point to another on the nav graph. Do you think that would help your situation?
