Understanding ROS 2

Getting into the world of Isaac Sim and ROS 2 can be confusing. Probably the most confusing part is: What is ROS 2? I recently wrapped my head around it and would like to share my understanding.

At the root of it, ROS 2 is a set of software libraries and tools designed for building robotic applications. It provides a structured framework for communication, hardware abstraction, lifecycle management, and more.

I will mainly focus on the communication aspect here, as it is the first part in the journey of using ROS 2. However, as mentioned above, one should note that ROS 2 is more than that.

ROS stands for Robot Operating System. It is built on top of another communication protocol, the Data Distribution Service (DDS). DDS is a publisher-subscriber protocol, very much similar to MQTT (if you are not familiar with this protocol, I’ll use some more general analogies later). ROS adds an abstraction layer over the DDS protocol, providing number of features and controls that makes it useful for robotics.

Some analogies

Sometimes the best way to understand something is by analogy. I’ll go through a few, some of which explain certain aspects of ROS 2 better than others.

Similarity to Reddit

One way to view a publisher-subscriber protocol is to look at like Reddit. Reddit has subreddits. Users can subscribe to these subreddits to get updates. There can be multiple users posting and reading a subreddit. Posts appear in real-time for subscribers (via notifications).

Similarly in ROS 2, communication is via topics. ROS 2 nodes (akin to users) are publishers and/or subscribers to topics. Posts to topics are distributed through the network in real-time.

However, where the analogy breaks down is in three parts. First, ROS 2 messages don’t persist. They only exist in real-time, unless saved by a node. So, a Snapchat version of Reddit would be more accurate. Second, ROS 2 is only peer-to-peer. Nodes discover each other themselves via DDS and communicate directly. There is no central place to go to get messages. In other words, Reddit is centralized while ROS 2 is decentralized. Third, all ROS 2 communication is anonymous. So, it’s like reading a post from an anonymous user. However, nodes can find information on which node the message came from with extra steps, but it’s not the intent of the protocol.

Comparison to CAN Bus

For those familiar with CAN Bus, this may help you understand ROS 2 better. For those that do not, CAN Bus is a popular communication protocol in automotive applications. It is a wired digital protocol, where bytes are sent over 2 wires. All devices tap into this 2-wire transmission bus to send and receive signals. Devices send messages with IDs without knowing who will receive them. In other words, there is some anonymity. There is non central controller, which means that CAN is also decentralized. Albeit, there is a way to prioritize messages.

However, where the analogy breaks down is in four parts. First, CAN Bus devices have fixed ID’s and must be hardcoded into the devices. In ROS 2, topics are dynamic and nodes can create new topics at runtime. Second, CAN bus has a limited bandwidth, while ROS 2 supports large data streams—part of its appeal. Third, CAN Bus is real-time deterministic, where strict timing guidelines are followed. ROS 2, on the other can be considered “Soft Real-Time” in that reliability is ensured but strict timing of messages is not always guaranteed (nor expected). Fourth, CAN Bus data types are limited, whereas ROS 2 datatypes can be simple to complex.

What ROS 2 is and where it fits

From these analogies, we can gather not only what ROS 2 is but also where it may sit in the software architecture.

ROS 2 nodes communicate using topics. When a node starts, it announces its available topics, and DDS handles the discovery process (Figure 1)—helping matching publishers and subscribers connect. Nodes with the same topics then connect to one another (Figure 2). As information is published by nodes, subscriber nodes on the same topic will receive the information.

Figure 2: During runtime, ROS 2 nodes directly communicate with one another. Subscribers get information directly from publishers on matching topics. Three (3) nodes are shown as circles. Various topics are shown under /turtle1, based on the ROS 2 tutorial. Actions and services will be discussed in an another post. Also, nodes will regularly announce their presence (or destruction) to DDS middleware throughout runtime, which is not shown here.

Now, that you hopefully understand how ROS 2 nodes communicate, it's worth while thinking about where it can be used. In the analogy of CAN Bus, we noted that ROS 2 is “Soft Real-Time”. This hints at that signals requiring well-timed responses may pose a problem. For example, driving a stepper motor with feedback. In such a situation, signals must be precisely timed in the millisecond range.

This suggests that ROS 2 sits above these lower-level controls in a robotic system. Possibly, well suited for communicating between subsystems. For example, tell the motor system to go to position X. Or, what is the status of the subsystem? Should it continue or be stopped? That being said, it can still be used at various levels of robotic control, depending on the situation. It’s just that if you need precise timing and minimal latency, it may be better to choose a lower-level protocol.

Diving Deeper

This just scratches the surface of what ROS 2 is. However, we have covered the very basic idea. However, it should be said that ROS 2 is more than just a DDS communication network. It is a set of software tools built around DDS that make it useful in robotics.

In following posts, we’ll go into the message types, other than topics. These messages can be simple messages like described, service messages, or action messages.