-
Notifications
You must be signed in to change notification settings - Fork 89
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
Failure to run certain rclpy code with rmw_cyclonedds_cpp #494
Comments
@mjcarroll pointed out that the ordering in the executors is different in rclpy than rclcpp. |
I don't know how the RMW layer interacts with Python In other words, I have some difficulty seeing how this
relates to the code. Maybe someone can help clear up that confusion for me? Given that this is backlog, it is probably not the highest priority. |
Not an answer to this question, but I also had problems with CycloneDDS on Jazzy. In my case, the problems I had were related to buffer overflow:
WHen listing topics:
My solution was to compile CycloneDDS from source. Just for reference, the steps I used to compile it from source are described at: |
This issue has been mentioned on ROS Discourse. There might be relevant details there: https://discourse.ros.org/t/preparing-for-rolling-sync-2024-07-11/38526/2 |
Bug report
This is split out of ros2/examples#382 (and was ultimately found by osrf/ros2_test_cases#1259 as part of the Jazzy tutorial testing party).
Consider the following code:
If you run in one terminal:
And the code above in a second terminal with
RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
, it hangs forever and never completes.Required Info:
Steps to reproduce issue
See the initial description.
Expected behavior
Example code succeeds and prints a response from the service.
Actual behavior
Example code hangs forever.
Additional information
During debugging of this, I found that part of the problem seems to be in the
rclpy.spin_once
call. In particular, what happens is that for every call there the node is added to the executor, which constitutes an "event". At that point, it seems like because this isspin_once
, that event, and that event alone, is continually returned. We never make it to handling the other events, including the client response event. This is somewhat inherent in the contract ofspin_once
, but it is odd that this works forrmw_fastrtps_cpp
while it fails forrmw_cyclonedds_cpp
The text was updated successfully, but these errors were encountered: