ROS 2: Why are there so many Topics?

ROS 2 is designed as an everything-included framework for robotics. It generally maintains alignment with the architecture and philosophy of the original ROS.

Carried-over from ROS to ROS 2 was its topic naming convention, and the inclusion of the 'Parameter' system for every application.
These two details work together to create large numbers of 'parameter' topics, even in systems that do not use the ROS 2 parameter feature.
Here's how that happens:

ROS 2 Topic Naming Convention
'Topics' are named data flows in a DDS system.  They might carry sensor data, actuator commands, video streams, etc., but they need to be uniquely identified to ensure that the data goes where it is needed.

With DDS this is typically done using a keyed topic, which adds a 'key' element to the data topic to uniquely identify its source.  This enables a single topic for 'Temperature' to support large numbers of individual sources of temperature data.  In other words: thousands of temperature sensors can share a single topic, which results in faster discovery and greater flexibility.  Keyed topics are a crucial enabler for scalability.

ROS uses a different approach: assign uniquely-named topics for each unique source.   This means that a system with a thousand temperature sensors would need 1000 uniquely-named topics.   Each unique topic name adds to the overhead of discovery, where the publishers and subscribers announce their needs to find a suitable match.

ROS 2 Parameter System
ROS 2 'Parameters' are a means of listing, reading and writing variables within the application, from outside the application.  Parameters are a convenient way to make adjustments to the system during development.  Every application node in ROS 2 is automatically configured with the Parameter system, and it includes a set of 14 uniquely-named topics to support it, even if the application does not use Parameters.

The combination of the ROS 2 topic naming convention and the auto-included parameter system results in a large number of topics, which adds to the discovery burden and affects scalability.

A Small Example
Consider a small "Hello World" pub-sub pair of ROS 2 applications: Ideally, this would use only 1 topic to send the 'Hello' message.
ROS 2 includes 2 other visible topics for parameter events and logging, as shown using the ros2 topic list command:

RTI Admin Console can show a more complete picture of the topics created by ROS 2:

Note that this 2-node ROS 2 system has a total of 32 topics, when at a minimum it only requires 1 topic.
ROS 2 systems may be composed of hundreds of nodes, resulting in thousands of parameter topics, which affects discovery performance and limits scalability.

To create a scalable DDS system with fast discovery times, the number of uniquely-named topics should be limited as possible.
This is frequently done in DDS systems by:

• Using fewer topics to accomplish a goal (such as having a parameter system).
• Using keys on shared topics that have many unique publishers.

 Furthermore, the scalability of ROS 2 systems can be improved through the use of topic gateway applications to pass only the required topics and block the unnecessary ones.   Contact RTI for more information.