Closed clalancette closed 4 months ago
@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 async
code, but this looks to me like a single threaded process with one node, and one outstanding request. So even if you only intermittently "spin" that node, you would expect a result, right?
In other words, I have some difficulty seeing how this
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 is spin_once, that event, and that event alone, is continually returned. We never make it to handling the other events, including the client response event.
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:
ros2 run demo_nodes_cpp talker
*** buffer overflow detected ***: terminated
WHen listing topics:
ros2 topic list
*** buffer overflow detected ***: terminated
Aborted (core dumped)
My solution was to compile CycloneDDS from source. Just for reference, the steps I used to compile it from source are described at:
https://github.com/eclipse-cyclonedds/cyclonedds/issues/2043
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 https://github.com/ros2/examples/pull/382 (and was ultimately found by https://github.com/osrf/ros2_test_cases/issues/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