-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for #57 only works reliably for the very first goal #75
Comments
robin-mueller
changed the title
#57 works only reliably for the very first goal
Fix for #57 works only reliably for the very first goal
May 20, 2024
robin-mueller
changed the title
Fix for #57 works only reliably for the very first goal
Fix for #57 only works reliably for the very first goal
May 22, 2024
Is there any update on this topic? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As I commented after the fix for the original issue #57 ,
cancelGoal()
still doesn't work correctly for pre-response action cancellation. The issue now is, thatgoal_handle_
is not reset after a previous goal has terminated, which causes this condition to always become true after the first goal response. Therefore the function misleadingly assumes for any subsequent goals that the corresponding response has already arrived. As a result, anrclcpp_action::UnkownGoalError
is thrown inaction_client->async_get_result()
ifcancelGoal()
is called when the current goal has not arrived yet, sincegoal_handle_
refers to the previous, already terminated goal.We either have to reset
goal_handle_
appropriately, or refer to the currently relevant goal uuid if we want to verify that the response has arrived.I also suggested an entirely different implementation of
RosActionNode
here, which would prevent this issue from ocurring in the first place (Behavior A: Wait for goal response during initial tick).The text was updated successfully, but these errors were encountered: