2022-01-27
Throughout my career, I've had the opportunity to work with robotics on several occasions, and it has become a passion of mine. This enthusiasm has inspired me to start a new series of articles focused on robotics. In this series, I will primarily concentrate on robotics software and control, rather than the hardware aspects.
To kick off this series, I decided to write an introductory article on the Robot Operating System (ROS). Although there are already many resources available on ROS, I believe that providing an overview will be a fitting way to begin this journey into robotics.
The content of this article will cover the following topics:
What exactly is ROS? Despite what its name might suggest, ROS is not a traditional operating system. While it provides utility functions similar to those of a general-purpose operating system - such as hardware abstraction, low-level hardware control, interprocess message-passing, and package management - it is a middleware suite, not a true operating system.
As a middleware suite, ROS offers developers a collection of software frameworks, libraries, and tools designed to facilitate the development of robust robotics applications that can integrate with diverse hardware and software clusters.ROS Concepts and Design Patterns
This subtitle introduces the reader to the conceptual design patterns within the ROS framework and provides context for the detailed explanations that follow.
In ROS, the fundamental building blocks are called nodes. Each node is responsible for specific tasks, such as controlling devices and sensors or executing computational algorithms. Ideally, each node handles a separate task, whether it's for low-level processes like hardware control or high-level processes like decision-making algorithms. Nodes communicate with each other through topics or services, enabling a modular and distributed architecture.
There are two primary types of nodes: publishers and subscribers. As the names suggest, publishers are responsible for sending messages to topics, while subscribers receive messages from these topics by subscribing to them. This structure allows ROS to efficiently manage and distribute software across different nodes.
Inter-node communication in ROS is facilitated through topics. A topic is a communication channel that describes a data stream used to exchange information between different nodes. Topics are used to send streams of messages of a single type, such as sensor data or camera images. Nodes can publish messages to topics or subscribe to them to receive messages.
The number of nodes that can publish to or subscribe to a topic is generally limited by system resources, particularly RAM. Each topic has a unique name and a defined message type, ensuring that the correct data is routed to the appropriate nodes. In ROS 1, the relationship between nodes and topics is managed by the ROS master, while in ROS 2, this role is handled by the Data Distribution Service (DDS), a management middleware.
Services in ROS provide an alternative communication method between nodes, resembling the server-client architecture model, similar to a remote procedure call (RPC). In this setup, a client node sends a request, and a server node responds to that request. This establishes a bidirectional communication channel between the client and server nodes. However, unlike topics, which allow continuous data streaming, services are designed for one-time communication and are typically used to invoke specific actions.
For tasks that require time-extended operations, ROS introduces the concept of actions. Actions are designed to handle more complex tasks that go beyond the immediate request-response model of services. A ROS action is defined by three key messages: goal, result, and feedback.
In ROS, the robot's environment and runtime variables are stored on the ROS parameter server. These parameters are organized as key-value pairs, similar to dictionary data structures. Since the parameter server is not optimized for high-performance operations, it is best suited for managing configuration parameters, such as static, and non-binary data.
A ROS package is typically developed to perform a specific task, such as control or navigation. A package can contain one or multiple nodes, and it may also include related messages and services. Each package is designed to encapsulate all the necessary components to accomplish its designated task.
In recent years, intensive efforts have been made within the Open Source Robotics Foundation's (OSRF) ROS community to enhance the durability and real-time sensitivity of ROS. These efforts are now bearing fruit, leading to the release of a new generation of ROS, known as ROS 2.
The primary difference between ROS 2 and its predecessor, ROS, lies in the underlying communication architecture. In ROS 2, the publisher/subscriber communication model has shifted from the TCP/UDP multicast-based ROS master to the Data Distribution Service (DDS). DDS provides powerful features that significantly strengthen ROS 2's capabilities, making it more suitable for designing production-grade, real-time robotic systems.
Moreover, ROS 2 offers broader compatibility with operating systems, including Windows, macOS, and Real-Time Operating Systems (RTOS), expanding its usability across different platforms.
Let's consider designing a robot that follows a particular object using its onboard sensors. The system we need to build involves several components:
Using ROS, we might construct this system as follows:
Each subsystem in our robot design can be represented as a ROS node. Therefore, we will have four distinct nodes, each handling a specific executable function:
This concludes the discussion on ROS Conceptual Design Patterns, which is the first article in our robotics series. In my next posts, I plan to delve into the ROS file system and the ROS navigation stack. Stay tuned!