ROS 2 Concepts

Before running any commands, it helps to have the vocabulary straight. ROS 2 (Robot Operating System 2) is a set of software libraries and conventions for building robot applications out of many small, communicating processes. This page defines the core building blocks and, more importantly, explains when to use each one.

Overview

A ROS 2 system is a graph of independent programs, called nodes, that exchange data over a small number of well-defined communication patterns: topics, services, and actions. Nodes can also be configured at runtime through parameters. Everything that flows between nodes is typed using interfaces (message, service, and action definitions).

Node A --topic--> Node B
Node C <--service--> Node D
Node E <--action (goal/feedback/result)--> Node F
Parameters live inside a node and configure its behavior

Why It Matters

Choosing the wrong communication pattern is one of the most common design mistakes in ROS 2 projects. A sensor stream modeled as repeated service calls forces request/response semantics onto continuously produced data and can unnecessarily stall the client; a long robot-arm motion modeled as a topic has no way to report completion or be cancelled. Understanding the intended use of each primitive up front avoids rework later, especially once you get to Mobility and Manipulation, which combine all of them.

Core Concepts

Nodes

A node is a logical unit of computation that performs one logical piece of work — for example, reading a camera, running a controller, or aggregating diagnostics. Nodes are the unit of composition in ROS 2: a real system is built from many small nodes rather than one large program.

• Each node has a name, which should be unique within the graph.
• Nodes can be composed into a single OS process (composition) for performance, or run as separate processes for isolation — this is a deployment choice, not a change in the programming model.

Use a node when: you are structuring a distinct unit of computation or responsibility (a driver, an algorithm, a coordinator).

Topics

Topics implement a publish/subscribe pattern. A publisher sends messages on a named topic without knowing who (if anyone) is listening; any number of subscribers can receive them. Communication is asynchronous and typically continuous.

• Best for streaming data: sensor readings, robot state, continuous commands.
• No built-in acknowledgement — a publisher does not know if a message was received or processed.
• Many publishers and many subscribers can share the same topic, as long as the message type matches.

Use a topic when: data is produced continuously or periodically and there is no need for a per-message reply (e.g., /scan, /joint_states, /cmd_vel).

Services

Services implement a synchronous request/response pattern. A client sends a request and waits (or asynchronously waits) for exactly one response from a server.

• Good for short, quick operations: "give me a value," "toggle a mode," "compute this once."
• A service call blocks conceptually until the response arrives (or times out) — it is not designed for operations that take a long time or need progress feedback.
• A ROS 2 service is normally designed with one server for a given service name. Running multiple servers with the same service name should be avoided because request handling may become nondeterministic.

Use a service when: you need a single request and a single, fairly quick answer (e.g., "clear the costmap," "get current parameters," "trigger a calibration routine").

Actions

Actions implement an asynchronous, goal-oriented pattern designed for tasks that take a noticeable amount of time and may need progress updates or cancellation. An action interaction has four parts:

Part	Purpose
Goal	The client's request describing what should be done
Feedback	Periodic progress updates published while the goal is executing
Result	The final outcome, delivered once when the goal finishes
Cancel request	A request from the client to stop an active goal early

Internally, an action is built out of topics and services, but you should think of it as its own primitive with its own client/server API.

Use an action when: the operation is long-running, needs progress feedback, or must be cancellable — for example, navigating to a pose, or following a joint trajectory.

tip

ROS 2 Actions vs. "Arm Action" in Manipulation The Manipulation section's Arm Action page uses "arm action" to describe a workflow stage — the part of a manipulation pipeline that sends a trajectory to the robot and monitors execution. It is not a synonym for the ROS 2 action communication primitive described above, even though that stage typically uses a ROS 2 action such as control_msgs/action/FollowJointTrajectory internally. Keep the two meanings separate: one is a communication pattern, the other is a pipeline stage that happens to be implemented with it.

Parameters

Parameters are named, typed values that live inside a node and configure its behavior at runtime, without changing code. Examples include a sensor's frame ID, a control loop's update rate, or a threshold value.

• Can be set at startup (command line, YAML file, or launch file) or changed while the node is running (where the node supports it).
• Are local to the node that declares them — there is no global parameter server in ROS 2 (unlike ROS 1).

Use a parameter when: a value should be configurable without editing or recompiling source code. See Parameters and Launch for hands-on examples.

Interfaces (Messages, Services, Actions)

An interface defines the data structure exchanged over a topic, service, or action. ROS 2 ships interface packages such as std_msgs, sensor_msgs, geometry_msgs, and action_msgs, and any package can define its own .msg, .srv, or .action files.

• A message interface (.msg) describes topic data.
• A service interface (.srv) describes a request and a response.
• An action interface (.action) describes a goal, a result, and feedback.

Both ends of a communication must agree on the exact interface type (package and name), or they will not be able to talk to each other — see Troubleshooting for how this fails.

The ROS 2 Graph

The graph is the runtime picture of everything currently running: which nodes exist, which topics/services/actions they use, and how they connect. The graph is dynamic — nodes can join and leave at any time, and there is no central registry you must configure by hand. Discovery is handled automatically by the underlying middleware (DDS or an equivalent RMW implementation).

You inspect the graph with the ros2 CLI (covered in CLI Basics) or visually with rqt_graph.

Choosing the Right Primitive — Quick Reference

Need	Use
Stream continuous data with no reply needed	Topic
One quick request, one quick answer	Service
Long-running task with progress and cancellation	Action
Runtime-configurable value	Parameter
Define the shape of data exchanged	Interface (msg/srv/action)

Hands-on Steps

This page is conceptual by design. To see these ideas in a running system:

1. Continue to CLI Basics and list the nodes, topics, services, and actions in a live system.
2. Build the minimal example in Publisher/Subscriber to see a topic in action.
3. Call a service and send an action goal in Services and Actions.

Expected Result

You can describe, without hesitation, why a given piece of robot data should be a topic, a service, or an action, and you know that parameters configure a node rather than exchange data between nodes.

Useful Commands

# See the whole graph at a glance
ros2 node list
ros2 topic list -t
ros2 service list -t
ros2 action list -t
ros2 param list

Common Problems

• "Should this be a topic or a service?" — if you find yourself needing an acknowledgement or return value for every message, it is probably a service, not a topic.
• "My action never completes." — actions require an active goal handle and a result; a client that only reads feedback and never awaits the result will appear to hang. See Services and Actions.
• "Two nodes with the same interface name won't talk." — matching names is not enough; the package and type must match exactly. See Troubleshooting.

Key Takeaways

• Nodes are the unit of computation; topics, services, and actions are the ways they communicate.
• Topics: continuous, no reply. Services: quick, single request/response. Actions: long-running, with feedback and cancellation.
• Parameters configure a node; they are not a communication channel between nodes.
• Interfaces define the exact data shape and must match exactly on both ends of a connection.
• "ROS 2 action" (a communication primitive) and "Arm Action" (a manipulation workflow stage) are related but distinct terms.

Next

Continue to CLI Basics to start inspecting a running ROS 2 system.