Handling docking request in fleet adapter (#238)

Open-RMF Open-RMF General
1

Posted by @cwrx777:

How should docking request be handled by the fleet adapter when the robot fails to dock due to any reasons, such as the waypoint is blocked, or occupied by another robot, etc. Should the docking_finished_callback be called? will the core re-issue the docking request command again?

2

Posted by @Yadunund:

I think you asked a very similar question previously and the answer is the same.

3

Posted by @cwrx777:

@Yadunund ,

Specifically for docking request, what does the core expect after requesting it? if docking request failed, should docking_finished_callback be called by the fleet adapter? who is responsible to reissue the docking request command?

4

Posted by @mxgrey:

This really depends on your robot and what kind of behavior/workflow makes sense for it.

If you identify that an error has happened with docking, you could create an issue to display to the human operators and provide the operators with platform-specific tools to correct the problem, e.g. a teleoperation interface.

If you want something more automated then you could choose to command the robot back to the docking maneuver start location and re-issue the docking command to the robot. Then you could trigger the docking_finished_callback when this second/third/etc attempt is successful.

If it would be helpful to have RMF generate a new plan for the robot you could use the replan API. That could prompt RMF to send the docking command a second time depending on what position you are reporting for your robot.

Should the docking_finished_callback be called?

No, that callback should only be triggered when the robot has successfully finished the docking procedure. After you’ve triggered that callback, RMF will proceed with whatever has been planned for the robot as if the docking were successful.

As I mentioned in this comment error handling is far too specific to each platform, task, and situation for RMF to provide out of the box solutions. System integrators are ultimately responsible for identifying the operating envelope of their system, including what errors could occur and what the recovery strategies should be for each of those possible errors. RMF provides APIs for interrupting, canceling, replanning, and informing operators about issues, but it’s up to system integrators to determine how those capabilities should be used and what decisions should be automated versus manual.

Edited by @mxgrey at 2022-09-27T02:33:15Z

5

Posted by @cwrx777:

will the core interrupt docking process? just like how follow_new_path is interrupted after max_delay.

6

Posted by @mxgrey:

Yes, it’s possible for docking to be interrupted, however you don’t need to obey it. If your docking procedure is sensitive, you can use the following strategy:

  • When a sensitive docking begins, activate a bool flag, e.g. non_interruptible_action_happening.
  • When a new command comes in while non_interruptible_action_happening is active, ignore the new command (do not trigger the finished callback) and instead activate a second flag replan_after_non_interruptible_action.
  • When the sensitive docking mission is finished, check the replan_after_non_interruptible_action flag and if it’s active then trigger a replan for the robot. Reset both flags at this time. I recommend ensuring that at least one post-mission state update is provided before you trigger the replan to make sure that RMF is planning from the most accurate location.

In general, RMF will not particularly care that you’re not following a command that you were given as long as

  1. You don’t deviate very far from where you’re supposed to be
  2. You don’t trigger the finished callback when you’re not actually obeying the command
  3. You trigger a replan when you’re ready to resume following commands

Edited by @mxgrey at 2024-04-26T12:56:06Z