Skip to main content

ROS 2 Communication: Nodes, Topics, and Services

Understanding how different parts of a robot communicate is fundamental to building complex robotic systems. ROS 2 provides robust and flexible mechanisms for this, primarily through Nodes, Topics, and Services.

Nodes​

In ROS 2, a Node is an executable process that performs a specific computation. Think of nodes as individual programs or modules within your robot's software architecture. Each node should ideally be responsible for a single, well-defined task, promoting modularity and reusability.

Examples of nodes in a humanoid robot:

  • A camera_driver node that publishes image data.
  • a motion_controller node that receives commands and controls actuators.
  • a humanoid_state_publisher node that publishes the robot's joint states.
  • an ai_decision_maker node that processes sensor data and sends high-level commands.

Nodes communicate with each other using various mechanisms, primarily topics and services.

Topics: Asynchronous Data Streaming​

Topics are the most common way for nodes to exchange asynchronous, continuous streams of data. When a node wants to share information, it publishes messages to a topic. Any other node interested in that information can subscribe to the same topic to receive those messages. This is a many-to-many communication model.

Key Characteristics of Topics:​

  • Publisher/Subscriber Model: One or more nodes can publish to a topic, and one or more nodes can subscribe to it.
  • Asynchronous: Publishers don't wait for subscribers to receive messages.
  • Continuous Data: Ideal for sensor data (e.g., camera feeds, lidar scans), joint states, odometry, etc.
  • Anonymous Communication: Publishers and subscribers don't need to know about each other directly. They only need to agree on the topic name and message type.

Services: Synchronous Request/Reply​

Services provide a synchronous request/reply communication pattern. Unlike topics, which are for continuous data streams, services are used when a node needs to request a specific task from another node and wait for a response. This is a one-to-one communication model (a client requests from a server).

Key Characteristics of Services:​

  • Client/Server Model: A service client sends a request to a service server and waits for a response.
  • Synchronous: The client blocks until it receives a response from the server.
  • Discrete Tasks: Ideal for actions that are executed once and provide a result, such as "get robot status," "trigger a specific motion," or "reset a sensor."
  • Defined Request and Response Types: Each service has a clearly defined message structure for both the request and the response.

Actions: Long-Running Goal-Oriented Tasks​

While topics are good for streaming data and services for single request/reply, sometimes you need to command a robot to perform a complex, long-running task that provides feedback along the way and can be cancelled. This is where Actions come in.

Key Characteristics of Actions:​

  • Goal/Feedback/Result Model:
    • A client sends a goal (e.g., "move to position X").
    • The action server provides continuous feedback (e.g., "robot is 50% there").
    • Upon completion, the action server sends a result (e.g., "reached position X successfully").
  • Preemptable: Clients can request to cancel an ongoing action.
  • Asynchronous (Client side): While the action execution might be synchronous on the server, the client typically doesn't block, allowing it to do other things while waiting for feedback/result.

Understanding these communication primitives is crucial for designing and implementing effective robot behaviors in ROS 2. In the next sections, we'll see how to implement these using Python.