Robot Software Architecture with R.O.S. (Robot Operating System)

This article is the 3rd in a series of intermediate-level documents for those interested in building robots.

As robotics projects grow more complex, managing sensor reading, motion planning, and hardware control from a single monolithic code file stops being sustainable. This is where ROS (Robot Operating System) comes in — a software framework that organizes robotics software into modular, reusable, and distributed components. In this article, we cover ROS’s core architectural concepts, its messaging system, and how to use it in an intermediate-level robotics project.

What Is ROS and Why Use It?

Despite its name, ROS is not an operating system, but a middleware framework that runs on top of Linux (or other operating systems). ROS’s core value proposition is that it provides ready-made, community-tested solutions to problems that come up repeatedly in robotic systems — inter-process communication, hardware abstraction, visualization, and debugging tools.

Instead of writing a messaging protocol from scratch, a developer can use the standard communication mechanisms ROS provides to quickly connect sensor drivers, control algorithms, and visualization tools. This modularity also makes it easier to reuse a component (such as a camera driver) in a different project.

The Basic Architectural Unit: The Node

The fundamental building block of the ROS architecture is the node. Each node is an independent process that performs a specific task; for example, one node might only read images from a camera, another might process that image to perform object detection, and a third might generate motor commands based on the detection result. Because nodes run as independent processes, if one node crashes, only that node is affected rather than the entire system, which makes debugging and system stability much easier. Tools such as rosnode and rqt_graph are used in ROS to monitor which nodes are running and which connections have been established.

Messaging Mechanisms: Topics, Services, and Actions

Communication between nodes in ROS takes place through three basic mechanisms. Topic-based communication is based on the publish-subscribe model; a node continuously publishes data to a specific topic, while one or more nodes that need this data subscribe to the same topic to receive it. This model is ideal for situations such as sensor data that involve a continuous, one-directional flow of information.

For example, an IMU node can continuously publish orientation data to a topic. Service-based communication, on the other hand, is based on the request-response model and is used when a node needs a one-time, synchronous result from another node — for example, retrieving an instantaneous snapshot of a map.

The action mechanism is designed for long-running tasks that require feedback; for example, a robot’s task of navigating to a specific point can periodically report back its progress until it reaches the target, and can be cancelled if needed.

Message Types and Package Structure

Data transferred between nodes in ROS is structured through predefined message types. Standard message types include ready-made definitions such as geometry_msgs/Pose for position data and sensor_msgs/LaserScan for sensor data, though developers can also define their own custom message types specific to their projects.

ROS projects are organized into units called packages; each package generally bundles together the related nodes, message definitions, configuration files, and launch files.

This package structure allows the different components of a robotics project (for example, a navigation package, a perception package, and a control package) to be developed and tested independently of each other and then combined later.

Coordinate Frames and the TF System

A robotic system generally has multiple coordinate frames existing simultaneously (for example, the robot body, the camera, the laser sensor, and the world frame), and the transformations between these frames need to be continuously tracked.

ROS’s TF (Transform) system provides a central mechanism that tracks these coordinate transformations over time and makes them queryable. For example, the position of an obstacle detected by a laser sensor can be automatically transformed from the sensor frame to the world frame through the TF system, eliminating the need for the developer to manually calculate coordinate transformations every time.

Key Differences Between ROS 1 and ROS 2

The first generation of ROS (ROS 1) has a large user base in academic and hobbyist projects, but it has limitations such as its dependency on a central roscore process and its lack of real-time guarantees. ROS 2 was developed to address these limitations and is based on the DDS (Data Distribution Service) protocol, which does not require a central broker for communication between nodes.

This architectural change allows ROS 2 to operate more reliably in multi-robot systems and in industrial applications requiring real-time control. For new intermediate and advanced projects, ROS 2 is now generally recommended, since official support for ROS 1 has ended.

Visualization and Debugging Tools

The ROS ecosystem comes with a variety of visual tools that streamline the development process. RViz allows the robot’s sensor data, coordinate frames, and planned trajectories to be visualized in three dimensions, while simulation environments such as Gazebo make it possible to test software on a realistic physics engine without a physical robot. rqt_graphpresents all running nodes and the topic connections between them as a visual graph, making it easier to understand data flow in a complex system.

Conclusion

ROS is a widely adopted software framework in the field of robotics that allows robotics software to be organized modularly through standard building blocks such as nodes, topics, services, and actions.

The TF system and its rich set of visualization tools significantly ease the development and debugging of complex robotic systems. In the final installment of the series, we will cover the image processing and computer vision techniques that run on top of this software architecture and how a robot visually perceives its surroundings.

---

Frequently Asked Questions