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
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.
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.
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"."
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.
Hello, Thanks for your replies. However it's not a reply to my question.
Goupil
Maybe you could elaborate a bit more?
@Dragonslayer wrote:
this would be true for all (component based) software engineer I would say. Personally I'd find coherence to be just as important.
well, because it makes sense to do that in some (many?) cases. Messages have
std_msgs/Headers in them, withframe_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 theframe_idto appropriate values.that I would ...(more)