Handling Overlapping Navigation Commands in RMF: Expected Client API Behavior #565
-
|
I am wondering what the expected behavior is that RMF anticipates from the client API when a new navigation command is sent while a previous command is still in progress. Should the previous command be automatically canceled in favor of the new one, or is another approach expected? Currently, my API is pending the new request until the ongoing one is completed. The RMF does not send a stop command between the two navigation requests, RMF often exhibits this behavior during negotiation. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Yes, dropping the last command and beginning the new one as soon as possible is the intended behavior. Whatever last command RMF sent is the one that it wants you to follow right away, if possible. However there are some situations where it is not feasible to have the robot immediately stop what it's doing. Certain actions like docking with a payload or entering a lift are sensitive operations which cannot be stopped once they start. In those cases, you should let the action finish and then trigger a |
Beta Was this translation helpful? Give feedback.
Yes, dropping the last command and beginning the new one as soon as possible is the intended behavior. Whatever last command RMF sent is the one that it wants you to follow right away, if possible.
However there are some situations where it is not feasible to have the robot immediately stop what it's doing. Certain actions like docking with a payload or entering a lift are sensitive operations which cannot be stopped once they start. In those cases, you should let the action finish and then trigger a
replanon theRobotUpdateHandleif you received a request during the uninterruptible action.