Support tracepoints for complex message flow annotation used by ROS 2 plugin of Eclipse Trace Compass

[RaphvK]

Description

The ros2_tracing README refers to Christoph Bédards paper "Message Flow Analysis with Complex Causal Links for Distributed ROS 2 Systems", which demonstrates how to trace complex ROS message flows, e.g., if one published message depends on two input messages. As shown in his example repository, this is achieved by adding TRACEPOINT(message_link_* ...) calls to the source code to define the input/output relationships.

The ROS 2 Incubator plugin, which is released with Eclipse Trace Compass already supports this type of tracepoints. However, they are not integrated in the released versions of ros2_tracing. Therefore, I rebased the old branch message-link-instrumentation-iron on the current jazzy branch and added necessary changes. Additionally, I added the message_link_* tracepoints to the default events handled by the tracetools_launch.action.Trace() ROS action.

Is this user-facing behavior change?

Did you use Generative AI?

No

Additional Information

I implemented a test setup to verify that the changes work with ROS 2 Jazzy: https://github.com/RaphvK/ros2-message-flow-test

[christophebedard]

Thanks for the PR! I never really intended for these tracepoints to be merged here (as weird as that sounds 😆), since they're kind of experimental. Also, there aren't any user-facing tracepoints in tracetools at the moment; they're all internal to ROS 2.

However, this is pretty small and self-contained, so if someone wants to use these tracepoints, I think we could add them. Are you using them in your application along with the Trace Compass Incubator ROS 2 plugin?

We usually merge features into rolling and then backport them to older distros (if applicable), so it would be preferable to target Rolling. You may just be able to rebase your branch on rolling and change the PR target branch.

[RaphvK]

Thanks for the PR! I never really intended for these tracepoints to be merged here (as weird as that sounds 😆), since they're kind of experimental. Also, there aren't any user-facing tracepoints in tracetools at the moment; they're all internal to ROS 2.

However, this is pretty small and self-contained, so if someone wants to use these tracepoints, I think we could add them. Are you using them in your application along with the Trace Compass Incubator ROS 2 plugin?

We usually merge features into rolling and then backport them to older distros (if applicable), so it would be preferable to target Rolling. You may just be able to rebase your branch on rolling and change the PR target branch.

Thanks for your feedback! Exactly, we are using it at @ika-rwth-aachen along with the Trace Compass Incubator ROS 2 plugin to trace the message flow in the automated driving stack running in our research vehicles and are also planning to integrate this into our CARLA-based simulation and testing toolchain named CARLOS. We find it very useful and it would be nice to have it included in the released versions of ros2_tracing.

I created another PR for the changes on the rolling branch: #233