`throttle`: multiple input topics through a single terminal command

[abhishek47kashyap]

Description

Currently throttle takes only one input topic (intopic in the readme). Able being to pass in multiple intopic's can be a useful enhancement.

Possible use case: through a single terminal command, throttle RGB and depth data coming in from an RGBD camera.

Related Issues

None.

Completion Criteria

• Can throttle n input topics in parallel and publish on n output topics.

Implementation Notes / Suggestions

Spinning n threads, one for each intopic-outtopic pair. n should probably have a cap but not entirely sure what's a good way to decide on the number.

Testing Notes / Suggestions

• Units tests that can verify throttling of n >= 1 topics.

[christophebedard]

Since most topic_tools nodes share the same base node class (which has an input topic and output topic) and support providing input/output topic names as parameters through the CLI (e.g., ros2 run topic_tools throttle messages --ros-args -p input_topic:=my_topic -p msgs_per_sec:=2.0), this might be tricky to implement. How would you do it?

[abhishek47kashyap]

In the readme, I see mux "subscribes to a set of incoming topics".

mux deals with the multiple input topics by having std::vector<std::string> input_topics_ in the derived class MuxNode. Perhaps we could do a similar thing for throttle's input topics in ThrottleNode, and further extend that for output topics?

With multiple intopic-outtopic pairs, some of the member variables of ThrottleNode like period_ and last_time_ would require topic-wise bookkeeping. And it seems ToolBaseNode::make_subscribe_unsubscribe_decisions() would need to be modified too.

What would be your thoughts on how to approach this? Making changes to ToolBaseNode would most likely require changes to the other derived classes as well.

[christophebedard]

You're right, mux does subscribe to multiple input topics.

Changing ToolBaseNode to support N input topics and M output topics is worth a try. Since ToolBaseNode currently only creates an input topic subscription if a subscription to the output topic exists (if "lazy"), it may need some kind of "N input to 1 output" vs "N-M input-output pairs" flag. Just give it a shot and we'll see!