TL;DR:
ROS (Robot Operating System) is a set of tools and conventions for splitting robot software into small programs that talk to each other.
Programs are nodes, they talk over named topics, and each topic carries one type of message.
Because publishers and subscribers do not know about each other, you can swap or restart one part without touching the rest.
A robot that follows a red ball needs a camera driver, a program that finds the ball, a controller that turns toward it, and a motor driver. You could write that as one giant program. The first time the camera driver crashes, the whole thing goes down with it. ROS exists so you do not have to build it that way.
What ROS does on a robot
Despite the name, ROS is not an operating system. It is middleware: a layer that lets separate programs find each other and exchange data, plus a large collection of tools and ready-made packages. It runs on top of an ordinary operating system, most commonly Linux.
The unit of a ROS program is a node, and each node is best kept to a single task: reading a camera, locating an object, or driving one wheel. Dozens of nodes can be running together on one robot.
Nodes, topics and messages
Nodes pass data through topics. A topic is a named channel such as /camera/image_raw. A node that sends data on it is a publisher, and a node that listens is a subscriber. Many nodes can publish or subscribe to the same topic.
Each topic carries one type of message, a fixed structure of fields. A velocity command has linear and angular parts, an image has a width, height, encoding and pixel bytes. The type is part of the contract, so a subscriber knows exactly what it is getting.
ROS also has services, a request and a reply for one-off questions, and actions, for long jobs that give progress and can be cancelled. Topics are the one to learn first, because streaming sensor data is the bulk of robot software.
Worked example: a camera node publishing to a detector node
Say the camera runs at 30 frames per second and the detector can only process 10 per second. Trace the data.
The camera node captures a frame and publishes it on
/camera/image_rawas an image message.The detector node subscribes to
/camera/image_raw. Each time a message arrives, a callback function runs on it.The detector finds the ball and publishes the result on
/ball/position, a message with an x and y in pixels.A controller node subscribes to
/ball/positionand publishes a turn command on/cmd_vel.The motor driver subscribes to
/cmd_veland spins the wheels.
Notice the rate mismatch. The camera produces 30 frames per second and the detector handles 10, so the detector can only keep up with 10 / 30 of the frames, or one in three. Subscribers have a queue depth, a limit on how many unread messages are kept. With a depth of 1, the detector always works on the newest frame and silently drops the older ones. With a deep queue, it falls further and further behind, and the ball position is out of date by the time it is acted on.
Check the lag: with a queue that fills at 30 − 10 = 20 frames per second of surplus, a queue limit of 100 would hold over 100 / 20 = 5 seconds of delay before it starts dropping. Five seconds is far too stale for steering, which is why control code usually keeps queues shallow.
Why decoupling helps
The camera node has no idea the detector exists. It publishes and moves on. That means you can replace the detector with a better one, start recording the camera topic to a file, or add a second subscriber such as a display window, and the camera code never changes.
It also isolates faults. If the detector crashes, the camera node keeps publishing, and the detector can be restarted on its own. You can even test the detector without a robot by replaying recorded camera messages into the same topic.
Where it goes wrong
Misnamed topics. A typo in a topic name means nothing is connected and nothing errors. Tools that list topics and their connections are the first thing to check.
Mismatched message types. Publisher and subscriber must agree on the type, not only the name.
Latency and drops. Big messages such as images and point clouds cost time to send. Slow subscribers with deep queues build up delay.
Mixed clocks. Messages carry timestamps. If two computers disagree about the time, data from different sensors will not line up.
No safety by default. ROS passes whatever it is given. A buggy velocity publisher will drive a real robot at full speed, so a hardware emergency stop that cuts motor power must exist outside the software.
Safety: Before running new ROS code on a real robot, lift the drive wheels off the ground or limit speed, keep hands clear of joints and wheels, and keep the emergency stop within reach.
How real robots use it
Research labs, university teams and many companies build on ROS, and its second generation, ROS 2, is the one new projects usually start with. A typical mobile robot has nodes for each sensor, a node for estimating its position, a planner, a controller and drivers, all linked by topics. Starting that many nodes by hand is tedious, which is where launch files and parameters come in.
Try it yourself
Install ROS 2 on a Linux machine or in a container, following the official install page for your release. Run the small publisher and subscriber demos that come with it in two terminals, then use the command line tools to list the nodes and topics and print a message as it flows. Stop the publisher with Ctrl+C and watch the subscriber keep waiting instead of crashing.
Frequently asked questions
Do I need ROS to build a robot?
No. A small robot can run one program on a microcontroller. ROS pays off when you have several sensors, several programs, or want to reuse other people's packages.
What language do I write nodes in?
Python and C++ are the two main supported languages. Nodes written in either can talk to each other through topics.
Get started
