Revision history [back]

Sure there is, but it depends on what you really want to do: is this in your own node (read: own code), are you trying to throttle an existing node, or something else?

Please update your question with some more information.

Sure there is, but it depends on what you really want to do: is this in your own node (read: own code), are you trying to throttle an existing node, or something else?

Please update your question with some more information.

Sure there is, but it depends on what you really want to do: is this in your own node (read: own code), are you trying to throttle an existing node, or something else?

Please update your question with some more information.

Edit:

1 . How to throttle the topic via roslaunch

Your statement is a bit ambiguous (what should roslaunch do in your opinion?), but if starting another node is acceptable, then I think the throttle or drop nodes from topic_tools should work for you.

2 . via command line ROS commands

Afaik, no such thing exists. That would probably have to rely on a built-in throttling capability, which doesn't exist at the moment.

3 . via ROS api

Personally, I always think of topics & services as the ROS API, but I think you're referring to the functionality exposed by the c++/python/X client libraries. See my comment on your 2nd bullet. There is no direct support for expressing don't-publish-this-at-more-than-X-hz.

[..] E.g nothing that does (if loop_count % 5) -> Publish(msg)

Do these options fall into that category?

1. use a ros::Rate with an appropriate period, see C++/Time - Sleeping and Rates. This obviously only works if your node is a source, or if you can somehow coalesce all messages received during r.sleep(), and base your own publications on that coalesced state.
2. use ros::Timer with an appropriate period, see C++/Timers. You'll have to deal with similar issues as with ros::Rate though.

Finally, throttling / rate limiting / any kind of QoS will be much easier to achieve in ROS2.0: one of the fundamental properties of DDS middleware is their support for QoS policies, and any system built on top of such a middleware should be able to exploit that.

Sure there is, but it depends on what you really want to do: is this in your own node (read: own code), are you trying to throttle an existing node, or something else?

Please update your question with some more information.

Edit:

1 . How to throttle the topic via roslaunch

Your statement is a bit ambiguous (what should roslaunch do in your opinion?), but if starting another node is acceptable, then I think the throttle or drop nodes from topic_tools should work for you.

2 . via command line ROS commands

Afaik, no such thing exists. That would probably have to rely on a built-in throttling capability, which doesn't exist at the moment.

3 . via ROS api

Personally, I always think of topics & services as the ROS API, but I think you're referring to the functionality exposed by the c++/python/X C++/Python/X client libraries. See my comment on your 2nd bullet. There is no direct support for expressing don't-publish-this-at-more-than-X-hz.don't-publish-this-at-more-than-X-hz right now.

[..] E.g nothing that does (if loop_count % 5) -> Publish(msg)

Do these options fall into that category?

1. use a ros::Rate with an appropriate period, see C++/Time - Sleeping and Rates. This obviously only works if your node is a source, or if you can somehow coalesce all messages received during r.sleep(), and base your own publications on that coalesced state.
2. use ros::Timer with an appropriate period, see C++/Timers. You'll have to deal with similar issues as with ros::Rate though.
3. use if ((now() - previous_) > desired_): admittedly primitive, but at least time-based (in contrast to your counting example) and the ROS C++ API supports it easily.

Finally, throttling / rate limiting / any kind of QoS will be much easier to achieve in ROS2.0: one of the fundamental properties of DDS middleware is their support for QoS policies, and any system built on top of such a middleware should be able to exploit that.

PS: this has been asked before, see (for instance):

• Creating a throttle node
• Throttle message rate for subscribers