ROS software architecture

Hello everybody :slight_smile: ,

I’m new to ROS and I would like to ask a “first glance” question.

Coming from a computer science background (and being interested in software architecture), I read ROS technical overview. Since ROS terminology uses words like “publisher” and “subscriber” I was expecting a broker centric architecture, but this is not the case.

In an event driven architecture - like ROS programs - message brokers simplify the overall structure. Furthermore, they allow horizontal scalability, high availability and decoupling (in the documentation page it is written that publisher and subscriber are decoupled, but this is inaccurate).

Why didn’t ROS adopt this solution? Am I missing out something?

Thank you in advance!


1 Like


In fact, ROS1 is based on a central broker but they dropped it in ROS2 !
In my opinion, the reason is that they want to avoid having a single point of failure.

I have the same background than you and in fact you will see that in robotics you have to change your architectural mindsets… There is a lot of differences between Software dev and robotics at the architectural level.

Hi! ROS1 architecture is built following a publication-subscription scheme, so you have a “master” node whose tasks are to create the communication between the different nodes taking into account the topics where they publish or subscribe. In this way, it is similar to a DNS architecture (master-slave). Of course, ROS master node represents a single point of failure but, also, a pontentialy security problem.

On the other hand, ROS2 uses a DDS implementation making its architecture more distributed in order to not having a master node. However, from a conceptual point of view, the publication-subscription architecture doesn’t change.

In addition, it’s importat to say that one of the main pillars of ROS is the standarization. ROS1 uses a custom communication protocol based on TCP, named TCPROS, but ROS2 uses a DDS middleware like FastDDS, RMW, etc…


Similar questions have been posted to ROS Answers a few times as well.

See ROS Nodes and topics - are nodes really decoupled? for one such Q&A.

We probably have a different understanding of the word broker, but IIUC, ROS 1 does not really have a broker (at least not in the way @ludobar describes them). The master is not involved in communication between nodes, other than providing “match making” services.

The architectural pattern might imply the presence of a broker, but at the implementation level one might not be needed.

Even though the documentation always refers to events, I’ve always considered the service- and action-side of ROS to be closer to RPC (with a timeout/cancellation facility) than a purely event-based approach.


Correct indeed ! That’s not really a broker ! But still a single point of failure.