Skip to main content

Section 10.1 Asynchronous Communication & Mechanics

Now that you understand the high-level ROS 2 architecture and graph concepts from Chapter 9, it is time to write code that makes robots move and react.
In this chapter, we will focus on the most fundamental communication dynamic in robotics: the Publisher/Subscriber (Pub/Sub) pattern. We will explore how nodes communicate asynchronously, how to construct publishers and subscribers in Python using rclpy, how callback functions process data streams, and how to control simulations like TurtleSim.

Subsection 10.1.1 What is Asynchronous Communication?

In computer science, communication can be synchronous or asynchronous:
  • Synchronous: A process sends a request and blocks (stops and waits) until it gets a response before moving on. Think of a phone callβ€”you ask a question and wait on the line until the other person answers.
  • Asynchronous: A process broadcasts data or sets up a listener, then immediately continues executing its own work without waiting. Think of sending a text message or posting a tweetβ€”you post the information and go about your day. When someone replies, your phone alerts you.
In a synchronous exchange, a Publisher sends data and then waits for a response before resuming. In an asynchronous exchange, the Publisher instead fires the data off and immediately continues its own execution, with no waiting involved at all.
Robotics systems rely heavily on asynchronous communication. If an autonomous vehicle’s steering controller had to pause and block execution every time it sent a wheel command, the robot couldn’t process safety-critical LiDAR data simultaneously!

Subsection 10.1.2 The Pub/Sub Model in Real-World Robotics

In a ROS 2 Pub/Sub pipeline:
  1. Publishers send data updates periodically or on events (e.g., publishing camera images at 30 Hz).
  2. Subscribers register interest in a topic and execute a callback function whenever a new message arrives.
  3. Publishers and subscribers are decoupled: they do not need to know where the data comes from or where it is going.
Real-World Example: Consider a Boston Dynamics Spot robot navigating an uneven outdoor environment.
  • An IMU (Inertial Measurement Unit) driver node continuously publishes orientation data to /imu/data at 200 Hz.
  • A balance controller node subscribes to /imu/data to continuously adjust leg joints.
  • A logging node also subscribes to /imu/data to record telemetry for engineers.
The IMU node simply broadcasts readings without caring how many subscribers exist or what they do with the data.
Figure 10.1.1. Asynchronous communication lets a robot continue processing safety-critical sensor data instead of blocking while it waits for an actuator response.

Reading Questions 10.1.3 Reading Questions

Check your understanding

1. Exercise 10.1.1: Asynchronous Communication Conceptual Check.

Why is asynchronous communication preferred over synchronous communication for high-rate sensor streams (like LiDAR or IMU) in robotics?
  • Asynchronous communication guarantees that no messages will ever be lost over Wi-Fi.
  • Incorrect. Asynchronous communication does not guarantee delivery over an unreliable network; it simply avoids blocking execution while waiting.
  • Asynchronous communication allows nodes to publish and process sensor data concurrently without stalling execution.
  • Correct! Because a publisher does not wait for a response, it can keep publishing new sensor readings while subscribers process earlier messages at their own pace.
  • Asynchronous communication eliminates the need to specify topic message types.
  • Incorrect. Every ROS 2 topic still requires a defined message type, whether communication is synchronous or asynchronous.
  • Synchronous communication consumes less memory than asynchronous communication.
  • Incorrect. Memory usage is not the deciding factor; the key difference is whether execution blocks while waiting for a response.
You have attempted of activities on this page.