ros2: support client/service instrumentation #127
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds support for the new client/service (i.e., RPC) instrumentation in ROS 2, see ros2/ros2_tracing#145. 1. In the objects analysis, create client and service objects 2. In the messages analysis, create the following instances: 1. Request publication 2. Request take and callback 3. Response publication 4. Response take 5. Message transport for requests and responses 3. In the messages dataprovider, display the above instances There is one limitation. Normal message publications and message takes have instrumentation that provides a "start time." For example, for message publications, the `ros2:rclcpp_publish` tracepoint is the start and the `ros2:rmw_publish` tracepoint is the end of a message publication. This allows us to attribute a duration to the publication and therefore display a time graph state. However, we only have a single tracepoint for client/service-related publication/take instances, so we do not have any duration data. For now, just hardcode a 5000 ns duration so that time graph states are visible enough. Signed-off-by: Christophe Bedard <[email protected]>
Member
Author
|
I have to say that the ROS 2 plugin (especially the main analysis/view: messages) could use some serious refactoring/improvements, even before this PR. I'll try to find some time to do some cleanup in a separate PR. |
Contributor
|
Uh... @christophebedard want to merge this? You're a committer after all :) |
Member
Author
|
I was waiting for the new ROS 2 instrumentation to be reviewed just in case, but it's taking a bit longer than anticipated. Hopefully this week! |
Member
Author
|
Alright, the new instrumentation has been merged into ROS 2, so I'm merging this! |
christophebedard
merged commit 4a683e8
into
eclipse-tracecompass-incubator:master
2 checks passed
christophebedard
deleted the
christophebedard/ros-2-services-end-to-end
branch
bhufmann
pushed a commit
to bhufmann/org.eclipse.tracecompass.incubator
that referenced
this pull request
Jan 27, 2025
…cubator#127) This adds support for the new client/service (i.e., RPC) instrumentation in ROS 2, see ros2/ros2_tracing#145. 1. In the objects analysis, create client and service objects 2. In the messages analysis, create the following instances: 1. Request publication 2. Request take and callback 3. Response publication 4. Response take 5. Message transport for requests and responses 3. In the messages dataprovider, display the above instances There is one limitation. Normal message publications and message takes have instrumentation that provides a "start time." For example, for message publications, the `ros2:rclcpp_publish` tracepoint is the start and the `ros2:rmw_publish` tracepoint is the end of a message publication. This allows us to attribute a duration to the publication and therefore display a time graph state. However, we only have a single tracepoint for client/service-related publication/take instances, so we do not have any duration data. For now, just hardcode a 5000 ns duration so that time graph states are visible enough. Signed-off-by: Christophe Bedard <[email protected]>
bhufmann
pushed a commit
that referenced
this pull request
Jan 28, 2025
This adds support for the new client/service (i.e., RPC) instrumentation in ROS 2, see ros2/ros2_tracing#145. 1. In the objects analysis, create client and service objects 2. In the messages analysis, create the following instances: 1. Request publication 2. Request take and callback 3. Response publication 4. Response take 5. Message transport for requests and responses 3. In the messages dataprovider, display the above instances There is one limitation. Normal message publications and message takes have instrumentation that provides a "start time." For example, for message publications, the `ros2:rclcpp_publish` tracepoint is the start and the `ros2:rmw_publish` tracepoint is the end of a message publication. This allows us to attribute a duration to the publication and therefore display a time graph state. However, we only have a single tracepoint for client/service-related publication/take instances, so we do not have any duration data. For now, just hardcode a 5000 ns duration so that time graph states are visible enough. Signed-off-by: Christophe Bedard <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds support for the new client/service (i.e., RPC) instrumentation in ROS 2, see ros2/ros2_tracing#145.
There is one limitation. Normal message publications and message takes have instrumentation that provides a "start time." For example, for message publications, the
ros2:rclcpp_publishtracepoint is the start and theros2:rmw_publishtracepoint is the end of a message publication. This allows us to attribute a duration to the publication and therefore display a time graph state. However, we only have a single tracepoint for client/service-related publication/take instances, so we do not have any duration data. For now, just hardcode a 5000 ns duration so that time graph states are visible enough.Example:
(trace: 2024-11-23__test_tracetools__test_service_pingpong__service-e2e.zip)
Clients (S↗️ ) and services (S↘️ ) are displayed under nodes (🔲) on the left. Chronological explanation:
/pingclient under the/test_service_pingnode sends a request (short-ish time graph state from which the outgoing arrow starts)/pingservice under the/test_service_pongnode receives (takes) the request (thinner time graph state that the incoming arrow points to, right before the long time graph state)/pingservice calls executes a callback for the request (long time graph state)/pingservice sends a response inside the request callback (time at which the outgoing arrow starts)/pingclient receives (takes) the request (thinner time graph state that the incoming arrow points to)