ROS is an acronym for Robot Operating System, but contrary to the name it is not an operating system. Instead, ROS is an open-source framework for building software for Robots. I got introduced to ROS in my current company which is a Cloud Robotics startup. In this article, I’ll give a general introduction to ROS based on what I learned.
Whenever I learn something new, I try to get the answer for “Why?” first. Why do we need a framework for building Robot software?
Robotics is an umbrella term that encompasses a lot of different problems and their solutions. For instance, Navigation is a general problem for Robots that can move. Now some researchers might come up with a solution for the navigation problem. But, how will a Robot developer use their solution? That’s where ROS comes into the picture. ROS provides a standardised framework to use composable building blocks like Navigation and build increasingly complex Robots.
Little note of the ROS versions
ROS has two Major versions:
- ROS 1: Until ROS Noetic Ninjemys
- ROS 2: ROS Foxy Fitzroy onwards
The two versions have significant differences that I’m not aware of, so I cannot talk about ROS 2. I’ll be talking only about ROS 1 because that’s what we use (and support) currently. I’ll write about ROS 2 in future posts once I learn about it.
ROS Master very broadly is responsible for the peer discovery among the ROS Nodes. So, ROS Master plays a central role. It is necessary to run the ROS Master before the ROS Nodes can start communicating. It is important to note that after peer discovery, the Nodes communicate in a peer-to-peer fashion.
The Parameter Server also runs as part of the ROS Master process. The Parameter Server is a local key-value store that is accessible by all the ROS Nodes under the same ROS Master. The key-value store is commonly used by the ROS Nodes to store the configuration.
ROS Nodes are the building blocks in the ROS Ecosystem. Each ROS Node runs in its own process. Node uses the ROS Master for discovering other Nodes. It can then communicate with other Nodes directly using any of the ROS communication strategies.
ROS provides client libraries for implementing the ROS Nodes. It has primary support for C++ and Python, but there is no limitation, and Nodes can (at least in theory) be implemented in any programming language provided it adheres to the API contracts of ROS.
ROS implements two basic forms of communication, ROS Services, and ROS Topics.
ROS Service is an RPC-like or request-response-based communication strategy. The ROS Nodes can provide arbitrary services by registering them to the ROS Master. Nodes can also invoke services provided by other Nodes by first doing the lookup of providers on the ROS Master, then directly calling the Service URI of the provider Node.
ROS Topic is a publish-subscribe-based communication strategy. This can be used for many-to-many one-way communication. ROS Nodes can publish messages to arbitrary topics by registering the publishers with the ROS Master. Other Nodes can then perform the lookup for publishers of the topics and subscribe to them directly.
ROS is a flexible framework to build composable software. In this article, I discussed some of the ROS primitives. I’ll be writing more articles on specific ROS concepts and some of its quirks as I continue to learn and explore more things.