ROS 2 Primer — Safely Distributing Robot Control Across Nodes, Topics, and DDS

ROS 2 is not the robot itself. It's a foundation for running a camera driver, self-localization, path planning, and motor control as separate programs (nodes) and combining them through standardized messaging and communication. You can get started with a single Python file at the prototype stage, and scale up to C++, real-time execution, multiple computers, and safety monitoring for a product. What matters isn't memorizing the API — it's designing who owns the data, timing, reliability, and the safe state on shutdown.

ROS 2

Image: Robot Operating System logo, Wikimedia Commons (CC BY-SA 4.0). The logo identifies the middleware and does not guarantee a particular distribution or DDS configuration.

30-Second Summary

• A node is a process with one responsibility, a topic represents a continuous stream, a service represents a short request/response, and an action represents a long task with intermediate feedback.
• ROS 2's communication runs on DDS, and QoS (reliability, history, depth, durability, deadline) can be chosen per endpoint. Sensors and control don't need to use the same settings.
• TF2 manages a tree of coordinate frames along with time. Mix up map, odom, base_link, and sensor frames, and the robot will drive to the wrong place even if perception is correct.
• On real hardware, add lifecycle management, watchdogs, privilege separation, logging, and failsafes for network dropout. Working in simulation is not proof of safety.
• Fix a long-term-support release like ROS 2 Jazzy, along with a matching DDS, OS, and driver combination, from the start, and build a reproducible workspace.

1. The Big Picture of ROS 2

Figure 1 — In ROS 2, nodes discover and communicate with each other via DDS. Not just topic names, but QoS, type, time, and coordinate frame are all treated as part of the contract.

A ROS 2 graph can be configured at runtime. A camera node publishes images, a perception node subscribes to them, and a control node takes the results plus self-localization and publishes velocity commands. Even if you move a node to a different computer, the same graph holds as long as DDS discovery and serialization work correctly.

2. Choosing the Right Communication Primitive

A topic message should carry not just the value but header.stamp and frame_id. If the image timestamp and the IMU timestamp are out of sync, the algorithm can still compute a result, but it will misestimate the motion. Resending camera images with reliability can flood the bandwidth, so choose QoS to match each sensor's character.

3. QoS as a "Communication Contract"

The minimum QoS settings to check in ROS 2 are Reliability (Best Effort/Reliable), Durability (Volatile/Transient Local), History (Keep Last/Keep All), Depth, Deadline, and Liveliness. A high-rate LiDAR may be well suited to Best Effort, which drops stale packets, while velocity commands, which can't tolerate dropped messages, should use Reliable with a short Deadline.

If the Publisher's and Subscriber's QoS aren't compatible, they won't communicate even under the same topic name. Check the actual settings with ros2 topic info -v /scan rather than trusting a sensor driver's preset blindly. When crossing a network, test MTU, Wi-Fi retransmission, multicast restrictions, and time synchronization together.

4. TF2 and Time

A robot's pose is expressed as a transform between coordinate frames. A typical tree looks like

map ──(SLAM/Localization)──> odom ──(odometry)──> base_link
                                                        ├── base_laser
                                                        ├── imu_link
                                                        └── camera_link

map is the long-term world frame, odom is smooth short-term odometry, and base_link is the vehicle reference frame. SLAM corrects map→odom, while wheel/IMU estimation updates odom→base_link at high rate. TF2 holds transforms with timestamps and interpolates them to each sensor's acquisition time.

Standardize coordinate frames as right-handed, and make explicit the difference between the optical frame (z forward, x right, y down) and the vehicle frame (x forward, y left, z up). Fix static transforms with static_transform_publisher, and don't publish a dynamic transform as static. A cycle or multiple parents in the TF tree is a design error.

5. Packages and the Implementation Flow

A minimal ROS 2 Python node looks like this.

import rclpy
from rclpy.node import Node
from std_msgs.msg import Float32

class Speed(Node):
    def __init__(self):
        super().__init__('speed_node')
        self.pub = self.create_publisher(Float32, '/speed', 10)
        self.timer = self.create_timer(0.02, self.tick)  # 50 Hz
    def tick(self):
        msg = Float32(); msg.data = 0.2
        self.pub.publish(msg)

rclpy.init(); node = Speed(); rclpy.spin(node)

On real hardware, don't send velocity commands straight to the motor — put an upstream node, speed limiting, an emergency stop, and hardware monitoring in between. Even when using C++'s rclcpp, check callback groups, the Executor, memory allocation, and real-time behavior.

Separate the workspace into src, build, install, and log, and resolve dependencies with rosdep. Pin the OS, DDS, and compiler with Docker or a devcontainer, and build ros2 doctor, ros2 node list, ros2 topic hz, and tf2_tools into both CI and field diagnostics.

6. Lifecycle and Safety

Sensors and actuators shouldn't necessarily accept commands the instant they power on. The Lifecycle Node's state transitions — Unconfigured → Inactive → Active → Finalized — separate driver initialization, calibration, communication checks, and output authorization. When a watchdog loses its heartbeat, zero out the velocity command and also open the brake or relay on the hardware side.

On the safety side, ROS 2's message communication by itself does not satisfy functional-safety standards. Check the applicable scope of IEC 61508/ISO 26262/ISO 13849 and similar standards, and separate safety functions into a monitoring system, a certified MCU, and a physical emergency stop. When connecting to a network, adopt SROS 2 keys and certificates, DDS Security, access control, and log auditing.

7. Current Ecosystem and Research

Nav2 integrates self-localization, mapping, path planning, and control through actions and lifecycle management, and ros2_control standardizes the boundary between hardware and controllers. MoveIt 2 handles a manipulator's kinematics, collision checking, and trajectory planning. Simulating in Gazebo or Webots and replaying sensor logs with rosbag2 enables regression testing without stopping the real robot.

Research is advancing on zero-copy communication, typed image pipelines that use GPUs/NPUs, deterministic executors, distributed learning, and cloud robotics that goes beyond DDS. When adopting a new feature, test not just benchmarks but network dropout, time skew, process restarts, sensor dropouts, and malformed message length.

Summary

ROS 2 turns a robot from a collection of parts into a reusable distributed system. Design node responsibilities, topic QoS, TF2's coordinates and timing, lifecycle, and safe states up front, and the whole system stays robust even as you swap out algorithms.

References

• ROS 2 Official Documentation
• ROS 2 Quality of Service settings
• ROS 2 tf2
• DDS Foundation
• Nav2 Documentation
• ros2_control