open-rmf/fleet_adapter_template

RMF sends an extra follow path request after successfully activating the docking charger

Closed this issue · 3 comments

Hi, so I have an adapter taken from this template that successfully calls the charging server of my robot. However, a lot of the times the RMF commands the robot to go to the nearest node right after completing the docking, so the robot will not actually charge, and RMF will stay waiting forever for the battery to recharge.

I believe this can be solved in RobotCommandHandle.py, but I'm not sure how or where. I tried using the self.clear() method that is included but that causes the whole RMF core to crash so I can't send new tasks after that.

Does this ring a bell to anyone?

You are most likely right to conclude that it is related to RobotCommandHandle.py. My guess is that your _dock method does not block until the charge is completed (i.e. loop until self.api.charge_completed() or whatever you have programmed to call returns true). In addition, make sure to set/clear certain flags that indicate that the robot has completed the charge, so RMF can make it do something else.

In any case, you might find some actual implementations of the fleet_adapter useful as well (see link to awesome_adapters).

It sounds like your adapter is not tracking the state of your robot during the docking and further not calling the correct update_*() function.

As a result, the fleet adapter thinks the robot is at a different waypoint and is commanding it to a different waypoint. @LKSeng had the right suggestion which is to check whether your dock() impl is setting the right flags to let the update callback know which update_*() function to call

I believe whats happening here is the same as: #19 (comment)

Please ensure your _dock() cb is implemented and blocks till the docking is completed. Else it will trigger once and then dock_finished_cb() will execute informing RMF that your robot has finished docking. Hence RMF will continue sending it new paths with two waypoints each which is the intended behavior of the Responsive Wait feature.