The Two Core Communication Patterns in ROS

At the heart of every ROS system are two fundamental ways that nodes exchange information: topics and services. Understanding the difference between them is essential before you can effectively use rosserial, because both patterns are supported over a serial link — but each suits different situations.

ROS Topics: Publish/Subscribe Messaging

A topic is a named channel over which nodes stream messages continuously. The pattern is publish/subscribe:

  • A publisher node broadcasts messages on a topic without knowing who (if anyone) is listening.
  • A subscriber node registers its interest in a topic and receives every message that arrives, without knowing who sent it.

This is a one-way, asynchronous communication style. The publisher doesn't wait for a response — it just keeps sending data.

When to Use Topics

Topics are ideal for continuous data streams — any time you have information that is produced regularly and needs to be consumed by one or more nodes:

  • Sensor readings (IMU data, encoder ticks, sonar range)
  • Motor velocity commands from a navigation planner
  • Camera image feeds
  • Robot pose estimates from odometry

Topics in rosserial

In a rosserial sketch, declaring a publisher is straightforward:

ros::Publisher range_pub("ultrasonic_range", &range_msg);
nh.advertise(range_pub);

And subscribing to a topic from ROS (e.g., to receive a motor command):

void cmdCallback(const std_msgs::Int16& msg) {
  setMotorSpeed(msg.data);
}
ros::Subscriber<std_msgs::Int16> sub("motor_cmd", cmdCallback);
nh.subscribe(sub);

The rosserial server transparently relays these messages between the serial link and the ROS network.

ROS Services: Request/Response Communication

A service implements a request/response pattern, similar to a function call. One node sends a request and waits for the other node to process it and send back a response.

Services are synchronous and bidirectional. Unlike topics, a service call blocks until the response is received (or a timeout occurs).

When to Use Services

Services are appropriate for one-time or on-demand actions where you need a confirmation or result:

  • Triggering a calibration routine and waiting for completion
  • Requesting the current battery voltage reading
  • Commanding a servo to move to a specific angle and confirming it reached position
  • Resetting encoder counts

Services in rosserial

rosserial supports both acting as a service server (microcontroller handles the request) and calling services hosted on the ROS network. Here's an example of a simple service server:

#include <rosserial_arduino/Test.h>
using rosserial_arduino::Test;

void serviceCallback(const Test::Request &req, Test::Response &res) {
  res.output = "Received: " + String(req.input);
}
ros::ServiceServer<Test::Request, Test::Response> server("test_srv", serviceCallback);

Key Differences at a Glance

Aspect Topics Services
Pattern Publish / Subscribe Request / Response
Direction One-way Bidirectional
Timing Asynchronous Synchronous (blocking)
Best for Continuous streams On-demand actions
rosserial support Full (pub + sub) Partial (server recommended)

Important Considerations for rosserial

Running topics and services over a serial link has some practical implications you should keep in mind:

  • Buffer limits: rosserial has strict memory constraints on the microcontroller. Keep message sizes small and limit the number of simultaneous publishers/subscribers.
  • Latency: Service calls are more sensitive to serial latency than topics. Avoid using services for time-critical operations.
  • Bandwidth: A typical USB serial connection at 57600 baud can handle moderate data rates, but high-frequency topics (e.g., IMU at 200 Hz) can saturate the link. Choose your publish rates carefully.

Summary

Topics and services are the two pillars of ROS communication, and both work over rosserial — each with nuances tied to the constraints of a serial link. Use topics for streaming sensor data and ongoing commands; use services for discrete, on-demand interactions. Understanding which pattern to apply in each situation will make your rosserial projects more robust and efficient.