Revision history [back]

Based on understanding from gvdhoorn's answer, my answer to this question is that topics can be multi-channel or single-channel. My question describes single-channel topics -- that is, topics that describe the state of exactly one thing. I think any message type that doesn't have a channel-differentiating field nor a message-prioritizing field must constitute a single-channel topic, and I don't think multiple latched messages makes any sense in this situation.

For instance, consider a small LCD that subscribes to topic /status_msg which carries std_msgs/String. Whenever it receives a message, it prints that message on the LCD. There's no space for multiple messages; any new message erases the previous one. If two publishers latch messages to this topic, when the LCD subscribes, we get undefined and undesirable behavior -- the desired behavior would be for only the most recent message to be delivered to the LCD upon subscription.

This can mostly be resolved by adding a message-prioritizing field such as a timestamp. If the /status_msg topic above carried a message containing both a string field and time field, then the LCD could discard the older of the two latched messages even if it happened to arrive after the newer message upon subscription.

If topics were only single-channel, I think that's an ugly solution -- we potentially have multiple zombie publishers consuming resources yet producing messages (to new subscribers) that will never be useful, and it makes many message types essentially invalid (in the general case) for use in topics.

But, topics are not only single-channel. A single topic may contain many channels, each channel representing the state of exactly one thing. A good, simple example is gvdhoorn's where the topic /temperatures carries a message type that contains an id field, describing the source of the temperature measurement ("ambient", "intake", "engine", etc), and a float field for temperature. In that case, different publishers have current information for different channels so it makes sense for multiple publishers to latch messages simultaneously. A more complicated example is how TF works on /tf_static.

One alternative to multi-channel topics might have been (prior to when ROS was actually implemented) to make all topics single-channel, and then have more sophisticated subscription rules (like subscribing to /temperatures/*, which would listen for messages from /temperatures/sensor1, /temperatures/sensor2, etc). But, that just trades topic content complexity for subscription complexity. And, it limits the channel identifiers to strings (sections of topic address), which the actual implementation does not limit. So, I think I see the design philosophy now and it seems pretty reasonable given those considerations. I happen to work nearly exclusively with single-channel topics so I miss some capabilities and constraints that would exist if not for multi-channel topics, but at least now I think I understand.