ROS 2 topic

ROS 2 topic – definition

A ROS 2 topic is a named, typed communication channel used for continuous or event-driven data exchange between nodes in a ROS 2 system. A node publishes messages to a topic, while one or more nodes subscribe to that topic and receive messages when they use the same ROS 2 message type and compatible Quality of Service (QoS) policies. Topics implement the publish-subscribe communication model defined by ROS 2 and are commonly transported through an underlying DDS-based middleware layer.

In mobile robotics, topics carry the robot state, sensor observations, control commands, maps, localisation estimates and diagnostic data. A UGV does not require publishers and subscribers to know each other directly. They only need to use the same topic name, ROS 2 message type and compatible Quality of Service (QoS) policies.

For example, a Leo Rover running ROS 2 Humble or a newer distribution can publish wheel odometry on /odom, LiDAR scans on /scan, IMU data on /imu/data and camera images on /camera/image_raw. A navigation stack can subscribe to these streams, while a separate controller node subscribes to velocity commands on /cmd_vel. This separation allows individual hardware drivers and autonomy components to be replaced without redesigning the complete robot application.

How ROS 2 topics work

A ROS 2 topic has a fully qualified name and an interface type. The interface type defines the message fields and field types, while generated ROS 2 type support handles serialization. Standard ROS 2 message packages include sensor_msgs, nav_msgs, geometry_msgs and std_msgs. Custom interfaces can be defined in .msg files and generated with ROS 2 interface tools.

Topic discovery is normally automatic. Nodes using DDS-based ROS 2 middleware discover publishers and subscribers through DDS discovery within the same ROS domain. The ROS_DOMAIN_ID environment variable can isolate independent robot networks that share the same physical Ethernet or Wi-Fi infrastructure.

Publisher: creates and writes messages to a named topic.
Subscriber: receives messages published on a topic with a compatible type and QoS profile.
Message type: defines the data schema, for example sensor_msgs/msg/LaserScan.
QoS profile: defines delivery, durability, history and queue behaviour.
Namespace: scopes topic names for multi-robot deployments, for example /leo_01/scan.

ROS 2 differs from ROS 1 in its middleware architecture. ROS 1 used a central ROS Master for graph registration and XML-RPC negotiation. ROS 2 does not require a ROS Master; its commonly used DDS-based middleware implementations use DDS discovery. The ROS 2 client libraries, including rclcpp and rclpy, expose a common API while allowing different middleware implementations through the ROS Middleware Interface (RMW).

Common UGV topics and message types

Topic naming is not enforced globally, but widely used conventions improve interoperability with packages such as Nav2, robot_localization, SLAM Toolbox and RViz. Frame relationships should be published through /tf and static frame relationships through /tf_static, following REP 105 conventions for coordinate frames.

Typical topic	ROS 2 message type	UGV purpose
`/cmd_vel`	`geometry_msgs/msg/Twist`	Linear and angular velocity commands for a differential-drive base.
`/odom`	`nav_msgs/msg/Odometry`	Wheel-encoder-based pose and velocity estimate.
`/scan`	`sensor_msgs/msg/LaserScan`	Planar LiDAR ranges for mapping, localisation and obstacle detection.
`/imu/data`	`sensor_msgs/msg/Imu`	Angular velocity, linear acceleration and orientation data.
`/map`	`nav_msgs/msg/OccupancyGrid`	2D occupancy map used by navigation and visualisation tools.
`/tf`	`tf2_msgs/msg/TFMessage`	Dynamic transformations between frames such as `odom`, `base_link` and sensor frames.

Quality of Service for sensor and control topics

QoS settings determine whether a ROS 2 publisher and subscriber can communicate and influence delivery behaviour under packet loss, network congestion or late node startup. QoS compatibility is a frequent integration issue on mobile robots because sensor drivers, visualisation tools and autonomy packages may use different policies.

The ROS 2 QoS model includes the following core policies. Their definitions and compatibility rules are specified in the ROS 2 documentation and derive from DDS QoS concepts.

Reliability: RELIABLE requests retransmission of lost samples; BEST_EFFORT prioritises timely delivery over retransmission.
History: KEEP_LAST stores a configured number of recent messages; KEEP_ALL attempts to retain all messages subject to resource limits.
Durability: TRANSIENT_LOCAL makes samples retained in a publisher’s history available to late-joining subscribers; VOLATILE does not.
Deadline and lifespan: define expected publication timing and message validity periods where supported by the selected middleware.

ROS 2 provides predefined profiles such as the sensor data QoS profile. It uses best-effort reliability and a small queue because LiDAR, IMU and camera streams are usually time-sensitive. In contrast, a static map publisher may use transient-local durability so that a navigation node started later can receive the latest map. Source: ROS 2 Quality of Service settings documentation.

ROS 2 topics on Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive mobile platform with an onboard Raspberry Pi compute unit and native ROS 2 support from Humble onward. Its base-control integration typically consumes a velocity topic and publishes odometry, joint state and diagnostic information. The robot requires an additional navigation, localisation and sensor integration stack for autonomous operation.

A practical Leo Rover graph can use a LiDAR driver publishing /scan, an IMU driver publishing /imu/data, the rover driver publishing /odom, and Nav2 publishing /cmd_vel. The transform tree must provide a valid chain from map to odom, base_link and each sensor frame. Incorrect timestamps, missing transforms or inconsistent frame IDs can prevent costmap updates and pose estimation.

Raph Rover follows the same ROS 2 topic model but can accommodate heavier compute and sensor payloads. This is useful when integrating multiple LiDARs, depth cameras, GNSS/RTK receivers or edge computing hardware. Topic namespaces are recommended when several Raph Rover or Leo Rover platforms operate on one network.

# Inspect active ROS 2 topics
ros2 topic list -t

# Display the type and QoS endpoints for a LiDAR topic
ros2 topic info /scan --verbose

# Monitor the observed message reception rate
ros2 topic hz /scan

# Inspect one odometry message
ros2 topic echo /odom --once

Example publisher and subscriber configuration

The following YAML fragment illustrates explicit QoS configuration for a sensor publisher. Actual parameter names depend on the driver package, but the policy values follow ROS 2 QoS terminology.

lidar_driver:
  ros__parameters:
    frame_id: laser
    topic_name: /scan
    qos:
      reliability: best_effort
      durability: volatile
      history: keep_last
      depth: 10

Topic frequency should be verified on the deployed rover rather than assumed from a driver specification. The effective rate depends on the sensor configuration, CPU load, transport, DDS implementation and subscriber processing time. For navigation, the relevant engineering requirement is not only nominal frequency but also timestamp consistency, bounded latency and the absence of queue saturation.

Normative references and technical sources

The following sources define the relevant ROS 2 concepts and conventions. They should be consulted when implementing interoperable UGV software.