You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, an action server's handle_cancel can only return ACCEPT and move the state to CANCELING. If the server has no cleanup to wait for, it still has to cancel the goal asynchronously, which is inconvenient.
This could be improved by adding a new return value, ACCEPT_AND_CANCEL, that would have similar behavior to returning ACCEPT_AND_EXECUTE from handle_goal.
The text was updated successfully, but these errors were encountered:
I am not sure the original design, but it looks like canceled is expected to be called on user application with progress report since it is likely that action is in progress when it tries to cancel. on the other hand, it can be up to user application if it returns ACCEPT_AND_CANCEL and then call _canceled internally? but what if _canceled failed after _cancel_goal? probably we need to change cancel service interface to return the response that says it is now canceling, but could not be canceled. may be i am missing something...
You're right, I forgot handle_cancel needs to return a result. This probably can't be done without big API changes.
I guess I can get the behavior I want by creating a timer with a callback that will call canceled with the correct result.
Feature request
Feature description
Currently, an action server's
handle_cancel
can only return ACCEPT and move the state to CANCELING. If the server has no cleanup to wait for, it still has to cancel the goal asynchronously, which is inconvenient.This could be improved by adding a new return value, ACCEPT_AND_CANCEL, that would have similar behavior to returning ACCEPT_AND_EXECUTE from
handle_goal
.The text was updated successfully, but these errors were encountered: