Ask Your Question

# Messages stored on publisher side or on subscriber side (ROS1) ?

Hello,

I don't understand one key point for ROS1: where are the messages stored in a message sent in a topic ? We suppose that publisher is on one computer and subscriber on another one.

Explanation 1: When we create a topic in a publisher, we define the size of the queue. So I think the messages are stored locally where the publisher exists. When a subscriber needs to get the message, the message is sent through network to the subscriber side.

Explanation 2: The publisher store locally messages and send a copy to subscriber side. But we don't define queue size for a subscriber.

What is the good explanation : 1, 2 or none ?

For explanation 1, I don't understand how it works if we have multiple publishers in the same topic. And in that case, we will have latency through network when subscriber needs the message.

For explanation 2, if we have multiple subscribers, we send a copy to all of them ? In the case the publisher produce 100 messages per second, and the subscribers read at 1Hz, 99 messages per second have been sent through network for nothing to all of the subscribers.

Hope someone can help me to understand.

Have a nice day.

Goupil

edit retag close merge delete

## Comments

Iam not 100% sure how ros works under the hood but, - usually we do have a subsrciber queue link text.

• Ros is not meant to have multiple publishers on the same topic, this will mess things up big time. One would have to use some kind of mux node to achieve a similar effect.

• 100hz publisher and 1hz subscriber. Yes that would just be a waste of resources, in most cases, AFAIK. Its the developers job to balance it all. Practically all nodes have some sort of frequency setting for that. Also this is the reason why this forum is full of questions about timeout-errors and similar.

( 2020-12-17 06:09:00 -0600 )edit

Ros is not meant to have multiple publishers on the same topic, this will mess things up big time. One would have to use some kind of mux node to achieve a similar effect.

Could you clarify where you've read that, or how you came to that conclusion?

Having multiple publishers on a single topic is very much supported and also often used.

There are certainly situations where such a setup could have disadvantages, but a general statement such as you post here cannot be made, and seems to be factually incorrect.

( 2020-12-17 06:16:41 -0600 )edit

Yes, I can see how this sentence could be taken as factually incorrect, sorry. As far as I understand ros its idea is to build it up out of the smallest pieces practical. This is said about nodes, and I assume is also true for topics. Why put 3 different IMUs data into a single topic, for example? What I meant to say was more like: "Its not the ros idea to pack things togehter in as little nodes and topics as "possible"."

( 2020-12-18 08:11:09 -0600 )edit

Regarding where I got the mux idea from: I red this on a discussion about cmd_vel publishing. The specific issue was move_base vs teleop, a working , easy solution was mentioned to be a mux node for switching. In this special case there must be a control function to make move_base "shut up" when "higher level" user input (>Zero) is published by the teleop node. As I understood it one would need to have some sort of control over the publishers themself to get a clean predictable data flow, in general. At least when using standard packages and nodes I would assume its easier to mux then implement some control functionality.

( 2020-12-18 08:13:42 -0600 )edit

Hello, Thanks for your replies. However it's not a reply to my question.

Goupil

( 2020-12-19 05:47:45 -0600 )edit

Maybe you could elaborate a bit more?

( 2020-12-19 06:21:24 -0600 )edit

@Dragonslayer wrote:

As far as I understand ros its idea is to build it up out of the smallest pieces practical.

this would be true for all (component based) software engineer I would say. Personally I'd find coherence to be just as important.

Why put 3 different IMUs data into a single topic, for example?

well, because it makes sense to do that in some (many?) cases. Messages have std_msgs/Headers in them, with frame_ids. If you have three IMUs and want to feed them all to a single sensor fusion node, it's perfectly OK to do that over a single topic if the consuming node supports that. Just make sure to set the frame_id to appropriate values.

What I meant to say was more like: "Its not the ros idea to pack things togehter in as little nodes and topics as "possible"."

that I would ...(more)

( 2020-12-20 07:26:48 -0600 )edit

## 1 Answer

Sort by » oldest newest most voted

Hello, Thanks for replies.

I know that publisher/subscriber could work with multiple publishers and multiple subscribers on a single topic. No problem for that.

It seems that my question was imprecise: let me try to explain.

I have a computer A with a publisher and another one B with a subscriber, talking using TCPROS (topic).

When a subscriber read a message from the topic, is-it needed for the computer PC B to read the message on computer A and to get it through the network or is the message already sent when the publisher published it and stored B ?

To explain my problem: the latency of my network is 50ms +/- 20ms (answer of ping command): in worst case, the latency will be 70ms for network. The rate of my publisher is 10Hz (100ms). So if computer A sends the message to queue in computer B as soon as the value is available, the subscriber can read the value after a maximum of 70 ms (on a computer the time to read the queue is negligible). In the other case, if computer B reads the value in queue on computer A, the worst case will be 170 ms after the value was read (worse case: the value was published 99.9ms be'fore + delay of network). It's a huge difference.

Hope someone can help me.

Merry Christmas to everyone !

Goupil

more

## Comments

OK, now I understand. I dont know the answer.

( 2020-12-27 06:36:50 -0600 )edit

## Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

## Stats

Asked: 2020-12-17 03:06:58 -0600

Seen: 126 times

Last updated: Dec 24 '20