ros2: support pub-sub message tracking using rmw layer only #24
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.
The current implementation of the ROS 2 plugin relies on events from the underlying DDS middleware in order to be able to track a message from publication to subscription: it needs to get a timestamp value from DDS when a message is published. This timestamp value is then matched to the same value when the message is received on the other end.
While the ROS 2 instrumentation is available by default on Linux (as of the ROS 2 Iron release in May 2023), instrumentation for the DDS implementation(s) is not available by default; the DDS implementation needs to be built from source. However, some recent changes to the ROS 2 instrumentation (to be available in the ROS 2 Jazzy release in May 2024) mean that DDS instrumentation is not needed anymore in order to track messages from publication to subscription. We just rely on events from the ROS 2
rmw
layer (which is right above DDS in the ROS 2 architecture), specifically theros2:rmw_publish
events, to get the same timestamp. For more information about these changes, see: ros2/ros2_tracing#74.Therefore, note the version of the instrumentation (aka the ROS 2
tracetools
package) used to generate the trace. If the version is greater than or equal to the version that contains the new changes, rely onrmw
for the timestamp value. Otherwise, if an older version is used, rely on DDS for the timestamp value.