rclcpp "throttle" logging

[IanTheEngineer]

Feature request:

rclcpp logging client library support for throttle loggers.

I found a TODO in the source code, and figured it deserved to be called out in an issue for visibility:

# TODO(dhood): Implement the throttle macro using time sources available in rclcpp
excluded_features = ['named', 'throttle']
def is_supported_feature_combination(feature_combination):
    is_excluded = any([ef in feature_combination for ef in excluded_features])
    return not is_excluded
}@

This is also sort-of captured in a bullet point tucked away in a nearly-completed ticket in the ros2 repo: ros2/ros2#425

A description of the desired functionality can be found in the ROS1 wiki:

Throttle Logger

Throttle

    ROS_DEBUG_THROTTLE(period, ...)

    ROS_DEBUG_STREAM_THROTTLE(period, args)

    ROS_DEBUG_THROTTLE_NAMED(period, name, ...)

    ROS_DEBUG_STREAM_THROTTLE_NAMED(period, name, args) 

Throttled output will print a message at most once per "period".

Delayed throttle

    ROS_DEBUG_DELAYED_THROTTLE(period, ...)

    ROS_DEBUG_STREAM_DELAYED_THROTTLE(period, args)

    ROS_DEBUG_DELAYED_THROTTLE_NAMED(period, name, ...)

    ROS_DEBUG_STREAM_DELAYED_THROTTLE_NAMED(period, name, args) 

Delayed throttled output will print a message at most once per "period" and no message will be printed before one "period" has elapsed.

[BMarchi]

If we remove the throttle key from excluded_features, rclcpp macros are generated which use the rcutils implementation. We can see, from the generated files, the following:
#define RCUTILS_LOG_DEBUG_THROTTLE(time_source_type, duration, ...) . rcutils doesn't have the concept of a time source or a clock. It uses the system time clock for the throttling implementation.

I came up with the following ideas:

1. Forget about the time source concept in rcutils and expect a time point instead (expressed in nanoseconds) and use that in all the throttle macros. We would need to force the user to pass a rcl_clock_t to the RCLCPP throttle macro definition and get a time point from that, or just pass the nanoseconds to it.
2. Create a definition for a clock in rcutils that should be also used in rcl. This implies to change the API, so we can pass a clock to the macro.
3. There's a comment saying that throttle should be enabled using the rclcpp time source, but I guess another option is to just use the system's clock and nothing else.

I personally think the first option is easier to implement and less error prone than the second one.
What do you think about it? @dirk-thomas @hidmic

[dirk-thomas]

How about option 4: passing a function pointer with the same signature as rcutils_steady_time_now for the existing argument time_source_type? From rclcpp such a function can be created which wraps the C++ clock / time source calls.