Hi,
I was wondering if it’s bad in terms of resources to have a great amount of publishers and subscriptions to the same topic in a single application / node or does ROS2/DDS manage them in the background ? Would it be better to have some kind of TopicManager that returns / manages instances of publishers/subscription inside an application. (And all classes that want to use a publisher ask the TopicManager for an instance of this publisher)
Also do I have to worry about a large amount of different topics in the system? Is the amount of topics somehow related to a increase in cpu / memory usage or do I just pay cpu/memory if I’m sending/recieving messages on a topic?
I would say that is bad to have many instances of publishers or subscriptions on the same topic in the same node, if you can avoid it and you don’t mind them sharing queues.
In ROS 1, at least publishers, and I think subscribers, for topics were singletons. I know that if you created a publisher on topic foo in one place, and in another part of the code you created a publisher on the same topic foo then you’d get a handle to the same publisher. This is bad, for example, when you wanted to specify a different queue size for each, see:
But is was good, on the other hand, for avoiding duplication of resources when you didn’t mean to do so.
If it the same is true for subscribers in ROS 1 (I didn’t check yet), then it could also be bad that they would share the same queue. Consider a subscriber with a queue size of 10 and the user creates two subscribers, each with a different callback but on the same topic. When a new message is received on the topic, does the message get delivered to both callbacks or just one? If it is delivered to both, what happens when one callback is really slow, does it keep the messages in the queue until all callbacks are done with each message?
In ROS 2 we wanted to make sure that each instance of a publisher or a subscription had the option to have their own queue. That makes the semantics clearer and it makes it possible to write code that cannot be interfered with from other code in the same process (which can be a concern when using the ROS API’s from within a library or when making nodelets). The trade-off is that each time a user creates a publisher in ROS 2, there will a queue and any other associated overhead generated as well.
That all being said, I think that we make users aware of this, then making a singleton for your publishers and subscriptions is something the user can do on their own.
I don’t think you need to worry about it too much. I’m not 100% certain about the overhead on the network, but you could expect some overhead in memory/cpu usage and possibly some overhead on network due to introspection and discovery processes. However, it would always be better to only create new publisher and subscription instances when you explicitly need a unique one with it’s own settings and resources.
Not currently. Right now this publisher is always created:
We’ve often talked about adding an option to the node constructor which would avoid this, but we’ve always stopped short because we wanted to implement a proper way to pass lots of options to a node constructor other than lots of arguments, i.e. some sort of rclcpp specific node options struct.
However, if you proposed a new argument to the node constructor which disabled this topic, then I’d consider it for merge in the meantime.
Not right now, but we also would like to do that at some point. You can implement it trivially though, by creating a single callback for the subscription which then iterates over a list of callbacks, calling each in turn.
We thought about multiple callbacks for single subscriber in the context of multi threading and executors and callback groups but that’s quite a bit more complicated and needs some more thought I think.
You can have one callback per subscription, I don’t know why you’d have a callback for a publisher. We might have callbacks for events like when a subscription is matched on a publisher or something like that, but in typical use cases you’d never have a callback on a publisher…
No, but as I said above, you can have your own list of callbacks which you call in your subscriptions single callback.