Add tracing to image_pipeline and instrument two ROS 2 components

[vmayoral]

• Fork tracetools and shape it as tracetools_image_pipeline to avoid external dependencies.
• Tracing first examples: image_proc::RectifyNode and image_proc::ResizeNode

[vmayoral]

Ping @christophebedard, I'd like you to confirm you're fine with this.

Note that I've forked tracetools and instead, this PR proposes to create a new ROS 2 package tracetools_image_pipeline which includes only the TRACEPOINTS for this meta-package and which can be maintained more easily (instead of having to send PRs to tracetools and iterate in longer cycles).

The rationale behind this comes from the the experience of having worked for a few months with the ROS 2 tracing infrastructure. To me, it eventually become rather cumbersome to have to maintain a single tracetools repo with all tracepoints (I experienced this directly with an extension of tracetools_acceleration we keep internally). Altogether this led me to realize that it might be better to simply add a tracetools_<whatever-ros2-stack/package>.

@vrabaud and @JWhitleyWork, note that this contribution adds the new package proposed as a REQUIRED dependency, if LTTng is not installed into the system, it should nicely inform that tracing is disabled but packages should build still fine. For now only image_proc::RectifyNode and image_proc::ResizeNode have been instrumented but if this approach receives a 👍, happy to instrument a few more components of the pipeline.

A simple launch file to test it:

"""Launch a raw image publisher, pipelined with rectify and resize"""

import os
import rclpy
import launch
from rclpy.node import Node
from std_msgs.msg import String
from sensor_msgs.msg import CameraInfo, Image
from launch_ros.actions import ComposableNodeContainer, Node
from launch_ros.descriptions import ComposableNode
from tracetools_launch.action import Trace
from tracetools_trace.tools.names import DEFAULT_EVENTS_ROS


def generate_launch_description():
    """Generate launch description with multiple components."""

    # # An image_raw publisher
    # image_raw_publisher = Node(
    #     package="perception_2nodes",
    #     executable="image_raw_publisher",
    #     name="image_raw_publisher",
    #     remappings=[("image_raw", "image")],
    # )

    # Trace
    trace = Trace(
        session_name="raw_rectify_resize_pipeline",
        events_ust=[
            "ros2_image_pipeline:*",
        ]
        + DEFAULT_EVENTS_ROS,
    )

    perception_container = ComposableNodeContainer(
        name="perception_container",
        namespace="",
        package="rclcpp_components",
        executable="component_container",
        composable_node_descriptions=[
            ComposableNode(
                package="image_proc",
                plugin="image_proc::RectifyNode",
                name="rectify_node",
            ),
            ComposableNode(
                namespace="resize",
                package="image_proc",
                plugin="image_proc::ResizeNode",
                name="resize_node",
                remappings=[
                    ("camera_info", "/camera_info"),
                    ("image", "/image_rect"),
                    ("resize", "resize"),
                ],
                parameters=[
                    {
                        "scale_height": 2.0,
                        "scale_width": 2.0,
                    }
                ],
            ),
        ],
        output="screen",
    )
    # return launch.LaunchDescription([image_raw_publisher, perception_container, trace])
    return launch.LaunchDescription([perception_container, trace])

[christophebedard]

Ping @christophebedard, I'd like you to confirm you're fine with this.

Note that I've forked tracetools and instead, this PR proposes to create a new ROS 2 package tracetools_image_pipeline which includes only the TRACEPOINTS for this meta-package and which can be maintained more easily (instead of having to send PRs to tracetools and iterate in longer cycles).

The rationale behind this comes from the the experience of having worked for a few months with the ROS 2 tracing infrastructure. To me, it eventually become rather cumbersome to have to maintain a single tracetools repo with all tracepoints (I experienced this directly with an extension of tracetools_acceleration we keep internally). Altogether this led me to realize that it might be better to simply add a tracetools_<whatever-ros2-stack/package>.

Happy to see people extending/building on top of this @vmayoral! 😃

This looks good to me. For reference, a similar rationale wrt the ROS 2 core itself was brought up a few months ago here: ros2/rclcpp#1738 (comment). If these were tracepoints for the ROS 2 core (i.e., currently rclcpp* and below), I'd prefer to avoid forking tracetools/putting the tracepoints in other packages to avoid the usual fragmentation of open source code, but this isn't really the case. It's more of an extension, i.e., additional instrumentation for application-level layers above the core, so I think this is the way to go for these use-cases. Besides, there is nothing about LTTng that requires instrumentation (or, rather, tracepoints) to be centralized like it is currently for the ROS 2 core, and the interactions with the Trace action are not really affected by this choice.

I'm not entirely sure whether or not these "instrumentation extension" packages should use the same TRACETOOLS_* CMake options, but I think it does make sense to use the same option name for all of them and have globals options. Besides, a package-specific option can always be added later on.

[vmayoral]

Happy new year folks!

I'm bumping this ticket so that it doesn't get stalled. @vrabaud and @JWhitleyWork, you guys are listed as maintainers, @jacobperron you seem to have contributed recently as well, anything else needed from our side on this PR? With it, we should be able to add additional probes.

[jacobperron]

Looks okay to me. I didn't test it, but I think @JWhitleyWork should give the final approval.

[JWhitleyWork]

Please address the 3 changes above (mine and @jacobperron's) and then I'm good to merge.

[vmayoral]

All done from my side @jacobperron and @JWhitleyWork, back to you.

[vmayoral]

Friendly ping @JWhitleyWork