ROS Fundamentals
What Is ROS?
ROS is not an operating system. Find out what it really is: a middleware, a build system and a huge ecosystem, plus the problem it exists to solve.
intermediate · 13 min read
Lesson content
Let us clear up the name first, because it confuses everyone.
ROS stands for Robot Operating System. It is not an operating system. It runs on top of Linux, like any other program.
What it actually is, is three things in one bundle:
A communication layer, so separately written programs can talk to each other.
A build and packaging system, so those programs can be shared.
And a very large collection of ready-made robot software you did not have to write.
What problem does ROS actually solve?
Every robot needs the same handful of parts. Something reading sensors. Something estimating state. Something planning. Something driving motors. Something logging it all.
Write that as one program and the pieces grow into each other. A change to the camera code can break motor control. Swapping a LiDAR means editing the navigation code.
ROS's answer is to make each piece a separate process that talks only through typed messages on named channels.
Now the camera driver can come from a vendor, the navigation stack from a research group, and the application from you. All three work together without knowing anything about each other.
That decoupling is the whole idea. Everything else in ROS follows from it.
The three things ROS gives you
1 · A communication middleware
Nodes, topics, services, actions and parameters: a standard way for processes to exchange typed data, whether they sit on the same machine or across a network.
2 · A build and packaging system
colcon,ament,package.xml. A standard project layout, dependency declaration and build process, so anyone's package builds the same way as anyone else's.3 · An ecosystem
Thousands of packages: drivers for most sensors, Nav2 for navigation, MoveIt for manipulation, RViz for visualisation, Gazebo integration, rosbag for recording. This is the part that saves years and the reason ROS won.
Along with those come a set of standard tools that are as much a part of daily work as the libraries.
| Tool | What it does | Why it matters |
|---|---|---|
| ros2 CLI | Inspect and interact with a running system | List topics, echo messages, call services. The debugger of first resort |
| RViz2 | 3D visualisation of robot state and sensor data | See what the robot thinks the world looks like |
| rqt | Plugin-based GUI: graphs, plots, parameter editing | Node graph inspection and live plotting |
| rosbag2 | Record and replay all message traffic | Debug a field failure at your desk and test against real data |
| tf2 | Track every coordinate frame over time | Ask "where was the camera when this image was taken?" and get an answer |
| launch | Start many nodes with configuration, as one command | A robot is dozens of nodes; nobody starts them by hand |
Definition
Computation graph
The network of running nodes and the connections between them. It exists at runtime; there is no master file describing it.
Formal definition
The peer-to-peer network of ROS 2 processes, discovered dynamically via DDS, in which nodes exchange data over topics, services and actions.
Example
A minimal real robot's graph
A LiDAR driver publishes /scan. A motor driver subscribes to /cmd_vel and publishes /odom. slam_toolbox subscribes to /scan and /odom, then publishes /map and a transform. Nav2 subscribes to all of those and publishes /cmd_vel. RViz subscribes to everything and draws it.
Five processes. Not one of them imports another. Swap the LiDAR for a different model and only the driver changes. Because the message type is the same, nothing downstream notices. That substitutability is why ROS is worth its overhead.
ROS is genuinely not always the right answer, and it is worth being clear about when it is not.
When to use
- A robot with several sensors and subsystems that must be developed independently
- You want to reuse existing navigation, manipulation or perception stacks
- Multiple people or teams are working on the same robot
- Simulation, visualisation and data recording matter, which on a research or product robot they do
- Distributed computing: an onboard computer plus a workstation
When to avoid
- A single microcontroller with one loop, where ROS does not run at all (micro-ROS aside)
- A hard real-time control loop, which belongs below ROS, not inside it
- A tiny project where the ROS learning curve exceeds the whole task
- Safety-certified systems, where the certification burden of the whole stack is prohibitive
ROS is not real-time, and that is by design
The ROS executor makes no timing guarantee at all. Messages arrive when they arrive.
A garbage collection pause, or a logger having a busy moment, can delay a callback by milliseconds.
For planning and perception, that is completely fine. For a 1 kHz current loop, it is fatal.
So the standard architecture puts hard real-time control below ROS, in a motor drive, a microcontroller or a real-time thread managed by ros2_control. ROS then handles everything above that line.
Trying to close a fast loop inside an ordinary ROS node is one of the most common architectural mistakes newcomers make.
- Distribution
A named, versioned release of ROS 2: Humble, Iron, Jazzy, Kilted.
Packages are built for a distribution. Mixing them does not work, and LTS distributions are what production uses.
- Workspace
A directory where you build your own packages against an installed distribution.
Your code lives here; the distribution stays untouched. Sourcing the workspace overlays yours on top.
- Package
The unit of ROS software: a directory with a package.xml declaring its dependencies.
Everything ships as packages, and the manifest is what lets the build system order them correctly.
- REP
ROS Enhancement Proposal, the standards documents.
REP 103 (units and conventions) and REP 105 (coordinate frames) are why anyone's package works with anyone else's.
Expecting ROS to be an operating system.
It is middleware plus tooling plus an ecosystem, running on Linux. Knowing that sets the right expectations about what it does and does not manage.
Writing one large node that does everything.
That throws away the entire point. Separate processes are what make the pieces testable, replaceable and reusable.
Ignoring the conventions in REP 103 and 105.
Metres, radians, x-forward, right-handed frames. Deviate and no off-the-shelf package will work with your robot.
Key takeaway
- ROS is not an operating system. It is middleware, a build system and an ecosystem, running on top of Linux.
- Its core idea is separate processes exchanging typed messages, so pieces can be written and swapped independently.
- The tooling (CLI, RViz, rqt, rosbag, tf2, launch) is as valuable as the libraries.
- ROS is not real-time; hard control loops belong below it, in a drive, a microcontroller or ros2_control.
- Follow REP 103 and 105 conventions, or nothing off the shelf will interoperate with your robot.
Finished this lesson?
Guest progress is saved on this device.