| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
Hey there, I was wondering for a fairly number of publishers and subscribers (~50 each), would it be better to put the publishers in one node and the subscribers in another, or is it okay to add all of them in one node?
Hi @mandymandymandy,
At the end of the day the only thing you will have will be a set of thread executing publishing tasks or subscribing ones so technically it does not matter. On the other hand, there are important things like keeping the code clean, adjust to ROS standards and organizing properly your project.
If you are OK dealing with the set of subscribers and publishers in the same node go ahead, but take into account that if you split this two sets in two different nodes, technically you will have the same set up but better understanding of your package structure and code.
At least is how I see it, if someone in this community wants to add more background on this kind of problems I will be glad to hear it.
When a publisher and subscriber use the same topic both exist inside the same node
This statement is incorrect. Topics and nodes are two completely separate concepts. Publishers and subscribers of the same topic can existing in the same node as well as in separate nodes.
Also take into consideration that more nodes -> bigger system. Going from one node to two nodes does not matter much. Going from one node to 10 or 100 nodes will have significant impact. This impact will be bigger in older versions of ROS2 because of this issue https://discourse.ros.org/t/reconside... . Future releases will probably deal with this better.
I mention this to clarify that although you won't see a difference at network level (same amount of publishers, subscribers, same rates, same data) the underlying DDS setup and system will be very different and this will have a performance impact.
Asked: 2020-03-01 07:03:41 -0500
Seen: 1,139 times
Last updated: Mar 02 '20
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
