ROS 2 DDS QoS Architecture Note: Building Reliable Intra‑Robot Links

Requirements

ROS 2 applications often need deterministic, low‑latency exchange of typed data between nodes running on the same robot or across a robot fleet. The key requirements are:

• Configurable reliability: critical topics must not lose samples, while best‑effort streams can tolerate occasional drops.
• Durability control: volatile data for real‑time control versus transient‑local durability for late‑joining nodes.
• Deadline and latency bounds: publish/subscribe pairs must meet a maximum end‑to‑end delay.
• Intra‑process zero‑copy: when publisher and subscriber reside in the same process, data should be shared without copying.
• Support for multiple data types and extensible IDL definitions.

These requirements map directly to DDS QoS policies that ROS 2 exposes through its rclcpp/rclpy APIs.

Smallest Suitable Design

The minimal architecture that satisfies the above requirements consists of two ROS 2 nodes:

1. A publisher node that creates a rclcpp::Publisher (or rclpy.Publisher) for a typed topic.
2. A subscriber node that creates a matching rclcpp::Subscription with the same topic name and type.

No extra middleware, bridges, or proxy processes are required. The underlying DDS implementation (e.g., Fast DDS, Cyclone DDS, or Connext) automatically creates a DataWriter in the publisher and a DataReader in the subscriber. When both nodes use the default QoS profile (BEST_EFFORT reliability, VOLATILE durability), the design works for non‑critical data. To meet stricter reliability or durability needs, the QoS is adjusted at creation time:

// C++ example (rclcpp)
auto qos = rclcpp::QoS(10)
    .reliability(rclcpp::ReliabilityPolicy::RELIABLE)
    .durability(rclcpp::DurabilityPolicy::TRANSIENT_LOCAL)
    .deadline(rclcpp::Duration::from_seconds(0.02));
auto pub = node->create_publisher<std_msgs::msg::String>("robot_status", qos);
auto sub = node->create_subscription<std_msgs::msg::String>("robot_status", qos,
    [](const std_msgs::msg::String::SharedPtr msg) { /* handle */ });

The same QoS object must be used on both sides; mismatched policies cause the DDS discovery process to reject the match, and no data will be exchanged.

Trust and Data Boundaries

In the base ROS 2 distribution, each DDS Participant trusts any other participant that appears on the same network segment. Data integrity and confidentiality are therefore dependent on:

• Network‑level protections (VLANs, firewalls, physical isolation).
• Node‑level authentication if SROS2 (ROS 2 Security) is enabled.

Without SROS2, any device that can join the multicast discovery traffic can publish or subscribe to topics, potentially injecting false data or eavesdropping. Enabling SROS2 introduces authentication, access control, and encryption via DDS‑Security, shifting the trust boundary to the security envelope rather than the raw network.

Operational Checks

To verify that the design behaves as intended, administrators can run the following ROS 2 command‑line tools:

• ros2 topic list – confirms that the topic appears in the DDS graph.
• ros2 topic info <topic> – shows the number of publishers/subscribers and the QoS profile in use.
• ros2 topic echo -q <topic> – displays live samples together with the effective QoS (reliability, durability, deadline).
• ros2 daemon stats – reports dropped samples, missed deadlines, and discovery traffic; a rising drop count signals QoS mismatch or network congestion.

These checks are lightweight and can be scripted into health‑monitoring loops.

Failure Modes and Design‑Change Triggers

Understanding how the minimal design can fail helps decide when to evolve the architecture.

Network Partition or Loss

If the network link between publisher and subscriber breaks, DDS will stop delivering samples. With the default BEST_EFFORT reliability, loss is silent. To detect and recover:

• Set reliability to RELIABLE and configure an appropriate deadline (e.g., 20 ms).
• Monitor ros2 daemon stats for increasing deadline_missed counters.
• If deadline misses persist, consider increasing the deadline or adding redundant network paths.

Excessive Bandwidth Usage

High‑frequency topics (e.g., raw LiDAR streams) can saturate the link, causing dropped samples even with RELIABLE QoS. Indicators:

• Rising dropped_samples in ros2 daemon stats.
• Increased latency observed via ros2 topic echo -q.

Design responses:

• Switch to BEST_EFFORT for non‑critical data.
• Reduce publish rate or enable DDS flow‑control (max_blocking_time).
• Apply data compression or decimation at the publisher.

Security Breach

An unauthorized node that can discover topics poses a risk of data injection or sniffing. The appropriate response is to enable SROS2:

• Create an SROS2 policy file that grants the legitimate nodes permission to publish/subscribe on the secured topics.
• Launch the ROS 2 daemon with ROS_SECURITY_ENABLE=1 and point it to the policy directory.
• Verify with ros2 topic info --secure that only authenticated participants appear.

If SROS2 cannot be deployed (e.g., legacy hardware), isolate the ROS 2 network segment with VLANs or physical air‑gaps as a compensatory measure.

When the Design Must Change

The minimal two‑node, single‑topic design remains valid as long as:

• QoS policies match and satisfy reliability, durability, and deadline requirements.
• Network conditions stay within the bandwidth and latency bounds assumed during QoS selection.
• Trust model (plain DDS or SROS2) aligns with the deployment’s security posture.

If any of these conditions change—new safety‑critical topics appear, network topology evolves, or a security audit mandates encryption—the architecture should be revisited. Typical evolutions include adding a QoS‑management layer, introducing a DDS‑based bridge to isolate sub‑networks, or deploying SROS2 with fine‑grained access control.

Verification Checklist

Before promoting the design to a production robot, perform the following steps:

1. Build and run the publisher/subscriber pair using the QoS settings shown in the example.
2. Use ros2 topic echo -q to confirm that the effective QoS matches the intended profile.
3. Introduce controlled network delay or loss with tc qdisc add dev eth0 root netem delay 10ms loss 2% and observe the impact on latency and dropped samples.
4. Adjust QoS (e.g., tighten deadline or switch to RELIABLE) and verify that the system recovers without violating application constraints.
5. If security is required, enable SROS2 with a minimal policy and repeat the checks; ensure that an unknown node cannot subscribe.

These steps provide concrete evidence that the smallest suitable design satisfies the stated requirements and that the team knows how to adapt it when conditions change.