ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Best practices for topics design

Hi a newbie here

I am wondering what is the best practice regarding the design of data flow through topics. Is it preferable to have a single topic containing all or many of the information provided by a component or rather to have each information its own topic. I will give two examples:

First example: an ambient sensor with temperature, dew point temperature, relative humidity and lots more. Would it preferable to have a single topic with all of them or to use the sensor_msgs defined messages and publish each measure on its own topic?

Second example: a peltier element with hot/cold temperature, current and voltage and device status. Same question.

On the one hand more topics is writing more code and more DDS traffic, on the other hand consumers can listen only to what they are interested in.

Generally, ROS is built so that you use the standard messages, i.e. sensor_msgs in this case, and have the smallest relevant pieces of data each on it own topic. As each sensor_msgs message has a header field with timestamp, subscribers that are interested in receiving multiple types of data all at once can use message filters to synchronize the message reception. This design allows you to easily share data to and connect to 3rd-party code that only knows the publicly available standard messages and has no means of parsing your custom messages.


Thanks @peci1 for your response!

As I understand it then, the more likely the project is to interact with 3rd party code, the more it could profit from granular topics, being the more boiler-plate code the small price to pay for it.

1 Like