🤖 ROS (Robot Operating System) for Engineers: Nodes, Topics, and Getting Started

What ROS Actually Is (and Isn't)

Despite the name, ROS is not an operating system in the sense that Linux or Windows are. It does not manage CPU scheduling, memory, or file systems. ROS is an open-source middleware framework that runs on top of a real operating system — almost always Linux, with Ubuntu as the officially supported platform — and provides the plumbing that robot software needs: message-passing between processes, hardware abstraction layers, device drivers, build tooling, simulation integration, and a large ecosystem of reusable packages for navigation, perception, and manipulation.

There are two major generations in active use. ROS 1 is the original framework, first released in 2007; it is now in maintenance mode, with its final long-term-support release (Noetic Ninjemys) reaching end-of-life and no further ROS 1 releases planned. ROS 2 is the actively developed successor, built from the ground up on top of DDS (Data Distribution Service), an industrial pub/sub standard that gives ROS 2 better real-time performance, no single point of failure (ROS 1 required a central roscore process; ROS 2 does not), and native support for multi-robot systems. Nearly all new robotics work — industrial, research, and commercial — targets ROS 2 today.

Core Concepts: Nodes, Topics, Messages, Services, and Actions

Nodes

A node is a single-purpose process that performs one job in the robot's software stack: a camera driver node reads frames from a sensor, a motor controller node sends velocity commands to wheel hardware, a path-planning node computes a route. Splitting a robot's software into many small nodes rather than one monolithic program is the central design philosophy of ROS — it makes each piece independently testable, replaceable, and reusable across different robots.

Topics and Messages

A topic is a named, typed communication bus that nodes use to exchange data asynchronously via a publish/subscribe pattern. A node that produces data publishes to a topic (for example, a camera node publishing frames to /camera/image_raw); any number of other nodes can subscribe to that same topic to receive the data (a perception node subscribing to /camera/image_raw to run object detection). Publishers and subscribers don't know about each other directly — they only need to agree on the topic name and the message type. A message is the strongly-typed data structure sent over a topic, defined in a .msg file with fixed fields (an Image message has fields for width, height, encoding, and pixel data; a Twist message has linear and angular velocity fields). Because topics are asynchronous and one-to-many, they're the right tool for continuous data streams: sensor readings, odometry, velocity commands.

Services

A service provides synchronous request/response communication, unlike the fire-and-forget nature of topics. A client node sends a request and blocks (or waits on a callback) until the server node returns a response. Services are appropriate when a node needs an immediate answer to a specific query — for example, calling a service to ask "what is the current battery percentage?" or to trigger a one-shot action like "reset the odometry to zero." Services are not suited to long-running tasks because the caller is expected to get a response quickly.

Actions

An action is designed for tasks that take a long time to complete, may need to report incremental feedback, and may need to be canceled partway through. A classic example is "navigate to this waypoint": the client sends a goal (the target pose), the server periodically publishes feedback (current distance remaining, percentage complete), and the client can send a preempt/cancel request if it needs to abort — for instance, if an obstacle appears. Actions are built on top of topics and services internally, but they exist as a first-class concept because goal/feedback/cancel semantics come up constantly in robotics (navigation, arm trajectory execution, gripper control).

A Minimal Publish/Subscribe Example

The snippet below sketches the shape of a ROS 2 (rclpy) publisher and subscriber pair. It is illustrative, not a complete runnable program, but the structure — create a node, create a publisher or subscription bound to a topic name and message type, and either publish on a timer or react in a callback — is exactly how real ROS 2 nodes are written.

class ImagePublisher(Node):
    def __init__(self):
        super().__init__('camera_node')
        self.pub = self.create_publisher(Image, '/camera/image_raw', 10)
        self.timer = self.create_timer(0.033, self.publish_frame)

    def publish_frame(self):
        msg = capture_frame_as_image_msg()
        self.pub.publish(msg)

class PerceptionNode(Node):
    def __init__(self):
        super().__init__('perception_node')
        self.create_subscription(Image, '/camera/image_raw', self.on_frame, 10)

    def on_frame(self, msg):
        detections = run_object_detector(msg)

Note that ImagePublisher and PerceptionNode never reference each other directly. They only share the topic name /camera/image_raw and the Image message type. That decoupling is what lets teams develop the camera driver and the perception stack independently, and swap either one out without touching the other.

Why ROS Matters for Robotics Engineers

The practical value of ROS is reuse and interoperability. Building SLAM (simultaneous localization and mapping), a full arm motion-planning pipeline, or a mobile-robot navigation stack from scratch is months to years of specialized work. ROS gives engineers mature, widely tested packages for exactly these problems: Nav2 for mobile robot navigation (path planning, obstacle avoidance, recovery behaviors), MoveIt for robotic arm motion planning and collision-aware manipulation, and multiple production-grade SLAM packages for building maps and localizing within them. Instead of reinventing these subsystems, an engineer configures and integrates existing ones.

Just as important is the standardization ROS imposes on how components talk to each other. Because topics, services, and message types are well-defined interfaces, a perception module built by one team, a planning module built by a second team, and a hardware driver built by a third team can be developed independently and still interoperate correctly, as long as everyone agrees on the message contracts. This is the same reason software engineers value well-defined APIs: it lets large, multi-person or multi-organization robotics projects scale.

Limitations and Tradeoffs

ROS is not free complexity to take on lightly. It has a genuine learning curve — understanding the build system (colcon in ROS 2), package structure, launch files, the DDS discovery and QoS (quality of service) model, and debugging tools (rqt, ros2 bag, rviz) takes real time. It remains substantially Linux-centric; ROS 2 has improved Windows and macOS support compared to ROS 1, but Ubuntu is still where the ecosystem is most mature and best documented. And ROS is overkill for simple, single-purpose embedded projects: a basic Arduino-controlled line-following robot or a single-sensor, single-actuator device does not need a pub/sub middleware, a package manager, and a message-typing system — a straightforward embedded control loop is simpler, lighter, and easier to debug.

ROS earns its complexity on genuinely multi-component systems: autonomous mobile robots coordinating sensors, planners, and drive controllers; robotic manipulation research combining perception, planning, and grasping; and multi-sensor fusion pipelines where several independent data streams need to be combined in real time. If a project has more than a couple of interacting software components, or needs to support swapping hardware or algorithms without a rewrite, ROS is usually the right investment.