How to change the publishing rate of robot's topics?

[arielc-brillianetor]

Hi,
Is there a way to change the publishing rate of the different topics that are published by the robot, such as:
/blue_bot/odom
/blue_bot/cmd_vel
/blue_bot/dock
in some scenarios I may want the topics to be published faster, and in some I may want them to be slower.
Thanks a lot,

[alsora]

Hi @arielc-brillianetor, currently there isn't an option for changing the publish rate of topics on the robot.

Note that the robot only subscribes to cmd_vel and does not publish on this topic. It is expected that the your application publishes here if you want to control the robot.
Moreover, in the vast majority of situations, it is not useful to slow down a topic and there are better solutions to achieve the same outcome.

What's your use-case?
Can you describe why you may want to change the publish rate?
This may help us providing you an appropriate solution for your situation.

[arielc-brillianetor]

I have an API which receives messages via tcpip/websocket, translates the messages and publishes them to the robot. And at the same time, in parallel, I need to take the messages published by the robot and send them back using the same tcpip/websocket channel. The problem is that even if I use multiple threads the robot publishes too fast and the thread which receives the incoming messages via tcpip doesn't get a chance to handle the messages. I also have a main thread which doesn't get a chance to print to the terminal or do other work which may be caught up by the ROS node.
That's my use case.
Thanks for your help

[alsora]

IMO, the best approach to slow down topics for your use-case is to throttle them.
For example, in your application that sends tcpip messages, you could just "ignore" some messages if they are coming in too fast: you could add a check to send over tcpip only if the last message was sent more than X seconds ago.
Another approach consists in creating a republisher ROS node: this node would subscribe to the topic published at a high rate and republish the data on a topic with different name at a slower rate.

The first approach is equivalent to if the robot was publishing slower.
The second approach allows for more control on the messages: for example you could "fuse" together batches of messages.

I think that throttling this specific subscription is better than reducing the publish rate.
You may have other applications (e.g. a localization system) that requires these fast rates.

Having said that, I would recommend you to look in details at how your application is implemented.
I'm very surprised that it can't keep up with the current rates considering it's only two topics and that they are relatively slow.
The odom topic is published every ~15 milliseconds and the dock topic is published every ~1 second.