ROS (Robot Operating System) Explained: Architecture, ROS 1, and ROS 2

Robots combine sensors, controllers, planning software, and hardware from different vendors. The Robot Operating System (ROS) gives those parts shared interfaces and tools so developers can build a robot as cooperating software components instead of one monolithic program. This guide explains what ROS provides, how the ROS 1 and ROS 2 generations differ, and how to start a small ROS 2 project.

What Is ROS (Robot Operating System)?

ROS is an open-source robotics software ecosystem: middleware, libraries, tools, conventions, and reusable packages for building robot applications. It is not an operating system like Linux or Windows. ROS runs on a host operating system and helps processes exchange data, expose capabilities, and be built, launched, inspected, and tested in a consistent way.

The name covers two major generations. ROS 1 is the original framework; its final distribution, Noetic, has reached end of life. ROS 2 is the actively developed generation. Its distributions package compatible versions of core software, and the current ROS 2 distribution and platform matrix lists Lyrical Luth as the latest long-term-support release. Check that matrix when choosing a distribution because supported operating systems and package availability differ.

ROS does not provide a robot’s mechanics, perception algorithms, navigation strategy, or safety case. It supplies common software infrastructure that applications and packages use to implement them.

Why Does ROS Exist?

A robot often brings together components with different owners, programming languages, data rates, and hardware. Without shared interfaces, teams repeatedly build custom communication protocols, configuration formats, launch scripts, visualizers, and log-replay tools. Changing one sensor or testing a new planner can then require changes throughout the application.

ROS standardizes much of this integration. A camera driver can publish a typed image message, a perception node can subscribe to it, and a planner can consume the resulting detections without either component being tightly coupled to the other’s implementation. Reusable packages and common command-line tools make it easier to replace components and reproduce tests.

The framework is not a guarantee of interoperability by itself: packages must agree on message definitions, coordinate frames, timing, and behavior. Network reachability, middleware configuration, and quality-of-service policies also matter in a distributed robot.

How ROS Works: Architecture

A simplified ROS 2 data path is sensor driver -> node -> typed message -> middleware and transport -> receiving node -> application callback. Nodes may run in one process, across multiple processes, or on separate computers.

• Nodes and executors: A node is a unit of computation, such as a camera driver or motion planner. It creates communication endpoints and timers. An executor schedules the node’s callbacks using operating-system threads; callback scheduling and the host OS affect timing. The ROS 2 node documentation describes nodes as participants in the ROS graph.
• Interfaces: A message defines typed data. Topics carry continuing streams, such as images or odometry. Services are request-and-response calls for short operations. Actions represent longer tasks, such as navigating to a goal, and can report feedback and accept cancellation.
• Client libraries and packages: rclcpp and rclpy let C++ and Python programs use ROS concepts. Packages group code, interfaces, configuration, and launch files; colcon builds workspaces containing packages.
• Middleware and discovery: ROS 2 client libraries use the ROS Middleware Interface (RMW). Common RMW implementations use DDS, which handles participant discovery and data transport. ROS 2 does not need a ROS 1-style central master, but discovery still depends on compatible settings and a working network.
• Quality of Service (QoS): Endpoint policies control behavior such as reliability, queue history, durability, and timing expectations. A publisher and subscriber with incompatible policies may not connect. The ROS 2 QoS guide explains policy compatibility and common profiles.

Tools are part of the workflow too: launch files start and configure nodes; ros2 commands inspect the graph; RViz visualizes robot data; and rosbag2 records and replays messages. These tools help with development and diagnosis, but they do not make a robot safe or satisfy a real-time deadline automatically.

ROS Components and Variants

ROS 1 and ROS 2 share concepts such as nodes, topics, services, and packages, but they differ in architecture, APIs, and supported lifecycle:

The ROS 1 bridge project documents a migration and interoperability option, not automatic compatibility. The bridge must be built with the message and service types it needs to translate, and compatible ROS 1 and ROS 2 environments must be available.

micro-ROS is a related option for resource-constrained microcontrollers. It uses an embedded client and an Agent on a more capable host to connect firmware to a ROS 2 system; it is not a separate ROS distribution. See the micro-ROS architecture guide for its client-Agent design.

Real-World Use Cases

• Mobile robots: Drivers publish laser scans and odometry; localization estimates position; navigation plans a route; controllers command the base. Navigation is a natural action because it takes time and benefits from progress feedback.
• Robot arms: Vision, motion-planning, and controller nodes can be developed and tested as separate components, with services for quick configuration and actions for longer motions.
• Research and industrial prototypes: Shared message definitions and logging tools help teams swap sensors, record repeatable experiments, and compare algorithms without rebuilding every connected component.
• Embedded and multi-robot systems: ROS 2 can connect host computers and embedded controllers, while middleware and network settings determine how data moves between robots or machines.

For hardware work, simulation can help test robot models and software before connecting actuators. The robotics simulation guide covers simulator choices and sim-to-real limits.

Practical Guide: Choose a Distribution and Try ROS 2

Choose a ROS 2 distribution that supports your operating system and architecture, then use the matching installation instructions. Lyrical Luth is the latest LTS listed in the official release matrix; the Lyrical Ubuntu installation guide lists its supported platform and repository setup. The commands below assume the official ROS package source has already been configured on that Ubuntu system:

sudo apt update
sudo apt install ros-lyrical-desktop ros-dev-tools
source /opt/ros/lyrical/setup.bash

In one sourced terminal, start a sample publisher:

ros2 run demo_nodes_cpp talker

Open a second terminal, source the same installation, and start a subscriber:

source /opt/ros/lyrical/setup.bash
ros2 run demo_nodes_py listener

The subscriber should print messages published on /chatter. Inspect the graph and endpoint settings from another sourced terminal:

ros2 node list
ros2 topic list
ros2 topic echo /chatter
ros2 topic info /chatter --verbose

To create a starter Python package with an executable entry point, create a workspace and build it with colcon:

mkdir -p ~/ros2_ws/src
cd ~/ros2_ws/src
ros2 pkg create --build-type ament_python --dependencies rclpy std_msgs --node-name minimal_publisher my_robot_pkg
cd ~/ros2_ws
colcon build --symlink-install
source install/setup.bash
ros2 run my_robot_pkg minimal_publisher

The official ROS learning path introduces nodes, topics, services, actions, launch files, and recording. For a Windows machine, follow the platform guidance rather than assuming every ROS package is available natively; WSL setup on Windows is one way to prepare a Linux development environment.

When adapting a demo to a robot, check that publishers and subscribers use compatible QoS, confirm the ROS domain and network interfaces, and measure latency under representative load. DDS discovery may not cross network boundaries without deliberate configuration. Use simulation and recorded data before testing on hardware, and keep safety-critical behavior independent of best-effort network communication.

Common Misconceptions About ROS

• “ROS is an operating system.” ROS is a robotics software ecosystem that runs on a host operating system.
• “ROS 2 is just a new release of ROS 1.” ROS 2 is a separate generation with different APIs, build tooling, and middleware architecture; most ROS 1 packages need migration.
• “DDS makes every robot real-time.” Middleware is only one part of timing. Executors, the operating system, application code, hardware, and network must all meet the required timing budget.
• “No master means networking needs no setup.” Discovery still depends on reachable interfaces, domain configuration, middleware behavior, and network policy.
• “Reliable QoS guarantees a successful robot action.” QoS affects message delivery between endpoints; it cannot ensure a callback runs on time or that an actuator safely performs a command.
• “A ROS package is automatically production-ready.” Packages need review for platform support, maintenance, security, interface compatibility, and the application’s safety requirements.

Related Articles

• ROS 2 architecture, DDS, and setup
• micro-ROS for embedded robots
• Robotics simulation environments and testing workflows
• Bluetooth Low Energy for IoT devices
• Kubernetes architecture for cloud-native applications