Skip to content
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

rclcpp_action: take and execute service entities in priority. #2471

Closed
wants to merge 1 commit into from

Conversation

fujitatomoya
Copy link
Collaborator

address #2451 and #1679

Note: more tests need to be done before CI.

@fujitatomoya
Copy link
Collaborator Author

  • IMO, we do not guarantee all feedback messages must be delivered to the client. (if the goal accept response is not yet delivered, that would be dropped. but eventually, feedback messages will be received on the client once goal handle is being tracked.)
  • Service responses should be handled with priority than feedback and status topics because it changes internal action state in the client.

std::make_shared<std::tuple<rcl_ret_t, std::shared_ptr<void>>>(
ret, status_message));
} else if (pimpl_->is_goal_response_ready) {
// Take the service entities 1st to apply to the client
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change looks good, but I'm not sure I understand the meaning of this comment.
What's a "service entity"?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

terms might be wrong. but it was supposed to mean it should take the action service executables 1st before action subscriptions.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest a more verbose comment, for example:

/*
The order of these statements is important when using waitset-based executors because this method
will be called only once per executor iteration, regardless of how many events are ready.
We first check whether the state of the action goal has changed (i.e. whether we received a goal response,
a result response or a cancellation response).
This ensures that secondary events (e.g. feedback messages) won't prevent the goal state from advancing.
*/

@fujitatomoya
Copy link
Collaborator Author

@alsora thanks for the review.

this will change the action client behavior internally so i need to do more verification locally, and i would like to have more feedback for this before further. please keep it open for a while.

@jmachowinski
Copy link
Contributor

Uhm, this implementation is ontop of a racy state...

We should merge #2250 first.

@jmachowinski
Copy link
Contributor

Regarding the issue itself. From my point of view, the design of the action is broken, as it uses multiple communication channels to communicate, thus creating this kind of problems.

Btw you can create the same bug by spamming feedback, and make an action never terminate.

@fujitatomoya
Copy link
Collaborator Author

@jmachowinski thanks for the comment. this one is not in the merge queue yet, i need to take some more time to verify this, since this changes the action behavior, i am expecting that userspace (tests) would break.

@fujitatomoya
Copy link
Collaborator Author

#2612 replaces this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants