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

rcl_send_response returns TIMEOUT #390

Open
fujitatomoya opened this issue Aug 18, 2023 · 1 comment · May be fixed by #408
Open

rcl_send_response returns TIMEOUT #390

fujitatomoya opened this issue Aug 18, 2023 · 1 comment · May be fixed by #408

Comments

@fujitatomoya
Copy link
Contributor

Background

Since ros2/rcl#1048 has been merged, rcl_send_response would return TIMEOUT.
Because of the racy condition to establish the service topics between client and service server, there is time window that server cannot find the concerned client yet when server tries to send out the response. (This is well known issue, since ROS 2 service is constructed with 2 topics for Request and Response, not bidirectional transport socket like TCP.)

For rclcpp and rclpy, instead of generating exception, it proceeds the process with printing the warning message, so that executor can go on the process.

related fixes for rclcpp and rclpy.

Discussion

So the question is what we should do with rclc?

We can see executor returns error with rclc once this TIMEOUT happens via rcl_send_request. (e.g. rclc_executor_spin)
That seems to be fine cz application can check the return code to re-enter the execution, but not exactly the same behavior with rclcpp and rclpy.
We would probably want to the print warning just like rclcpp and then executor process should go on w/o returning to the application?

If above suggestion is okay, i am happy to create PR for that.

@fujitatomoya
Copy link
Contributor Author

@JanStaschulat what do you think?

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 a pull request may close this issue.

1 participant