Note
You're reading the documentation for a development version. For the latest released version, please have a look at Lyrical.
Interfaces (topics, services, actions)
Interfaces in ROS define how nodes exchange data, helping you design communication between different parts of a robotic application. This article explains topics, services, and actions, and helps you choose the right interface type for different communication patterns.
Interfaces in ROS define how nodes exchange data. This article explains the different types of ROS interface and the differences between them. With this information, you’ll be able to select the right interfaces for your purposes.
Summary
ROS nodes typically communicate through the following three types of interfaces:
Topics: For continuous data streams.
Services: For synchronous request/response interactions (short tasks which happen immediately).
Actions: For long-running tasks with feedback (tasks that may take some time to complete).
For consistent communication, each interface uses definitions provided in .msg, .srv, or .action files.
Topics
The topic interface is meant for continuous data streams, for example, streaming sensor data or the status of your robot.
Topic definitions are stored in .msg files.
Topics implement a publish/subscribe pattern.
A node publishes data to a topic, and other nodes subscribe to receive that data.
This interface type has the following main characteristics:
Asynchronous, one-way communication
Multiple publishers and subscribers can share the same topic
flowchart LR
P[Publisher node] -->|Publishes messages| T[Topic]
T -->|Delivers messages| S1[Subscriber node]
T -->|Delivers messages| S2[Subscriber node]
Topic keys identify individual publishers on a topic so nodes and tools can distinguish where messages come from. Each topic key makes it easier to track data sources when several publishers share the same topic.
Services
The service interface is meant for synchronous request/response interactions, for example, when you want to send a query requesting the configuration of a specific robot.
Service definitions are stored in .srv files.
Services implement a request/response pattern.
A client sends a request, and a server replies with a response.
This interface type has the following main characteristics:
Synchronous communication
Ideal for short-lived operations that require confirmation, or provide a result in response to a request
sequenceDiagram
participant Service client
participant Service server
Service client->>Service server: Request
Service server-->>Service client: Response
Actions
The action interface is meant for long-running tasks with feedback, for example, moving a robot to a specific position, or asking the robot to perform a complex motion.
Action definitions are stored in .action files.
Actions allow clients to send goals, receive feedback during the execution, cancel if needed, and return a result if available.
This interface type has the following main characteristics:
Asynchronous, with feedback and result
Suitable for operations that take time
sequenceDiagram
participant c as Action client
participant s as Action server
c->>s: Sends a goal
s-->>c: Provides feedback (periodic)
s-->>c: Sends a result
Key differences between ROS interfaces
All three interfaces enable communication between nodes, but each serves a different purpose. The table below summarizes the differences between ROS interface types:
Pattern |
Direction |
Provided result |
Typical use case |
Cancellation |
|
|---|---|---|---|---|---|
Topics |
Publish/Subscribe |
One-way |
No |
Continuous data |
Not supported |
Services |
Request/Response |
Two-way |
Yes |
Quick queries |
Not supported |
Actions |
Goal/Feedback/Result |
Two-way with feedback |
Yes |
Long-running tasks |
Supported |