ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Looking for feedback on ros2_tracing and use-cases/needs for performance analysis & visualization

ros2_tracing has been around for more than a year now. It provides:

  • tracing instrumentation for ROS 2 (included starting from Eloquent, but still a WIP)
  • tools for setting up (LTTng) tracing easily through launch files and a ros2 trace command
  • tools for reading traces
    • used by tracetools_analysis to provide a simple Python API to analyze trace data using Jupyter notebooks

We are now looking for feedback from both current & potential users of ros2_tracing. I’m more specifically looking for feature suggestions and challenges users are facing, but this could be about anything as well.

If you’d like to suggest new features (including support for more instrumentation), I recently opened a 2021 roadmap issue to collect items from current & potential users for development in 2021 for both ros2_tracing and tracetools_analysis. This is for more concrete suggestions.

I’d also like to hear about challenges that people out there are facing and which might benefit from performance analysis and, more specifically, visualization. See my previous work with ROS (1) and tracing to see an example of what could be done regarding visualization: Message Flow Analysis for ROS Through Tracing.

I’m asking in part because I’m starting a master’s and, of course, I’d like to work on real problems and potentially (it’s research after all!) end up with something that is actually going to be useful to the ROS 2 community. I’m most likely going to be using Trace Compass for the implementation. Now that Trace Compass is moving from an Eclipse-based tool to a cloud-based IDE plugin (current support for the Theia IDE and planned support for VS Code), I think this should be interesting for a lot of people.

Some potential ideas I’m currently considering:

  • analysis of the critical path of a message across ROS nodes
    • the critical path is the path that, if decreased, can decrease the duration of the application, or, in this case, any relevant latency for a given message (e.g. internal executor/processing latency, or simply end-to-end latency)
    • building off of Trace Compass’ built-in critical path analysis, e.g. adding a ROS 2 message-aware layer on top
    • this is kind of a follow-up to my previous work, but with ROS 2
  • visualization of the executor(s)
    • to see what it’s doing at any given time, e.g. building/processing/iterating over wait set(s), waiting on DDS, executing a specific callback, etc.
    • not sure what specific executor(s) to study here yet; comments are welcome

You can either share your specific use-cases/needs/comments here, or you can send me an email (available on my profile).

2 Likes

Christophe, I’m just getting started with ros-tracing and Trace Compass but plan to use them to analyze and optimize the performance of a stereo imaging pipeline and perhaps more of the system if that goes well. I think the two ideas you’ve listed cover my intended use cases for now.

1 Like