2、DDS基础概念：DCPS模型、全局数据空间、发布-订阅范式、QoS策略、RTPS协议、DDS与ROS1通信对比

DDS（Data Distribution Service，数据分发服务）是由OMG（Object Management Group）组织制定的分布式实时数据分发中间件标准。在ROS2的架构中，DDS取代了ROS1中自研的TCPROS/UDPROS通信层，成为机器人系统中所有节点间通信的基石。要真正理解ROS2为何选择DDS、以及如何在实际工程中用好DDS，首先必须透彻理解其核心抽象模型——DCPS（Data-Centric Publish-Subscribe，以数据为中心的发布-订阅）模型、全局数据空间（Global Data Space）的概念、QoS（Quality of Service，服务质量）策略以及RTPS（Real-Time Publish-Subscribe，实时发布订阅）线协议。本章将从这些基础概念出发，系统梳理DDS的设计哲学，并与ROS1的通信机制进行深度对比。

2.1 DCPS模型：以数据为中心的发布-订阅架构

核心原理

DCPS（Data-Centric Publish-Subscribe）是DDS规范中定义的核心数据分发模型。与传统的以服务为中心（如CORBA、SOAP）或消息队列（如AMQP）不同，DCPS将数据本身作为通信的中心实体。在这个模型中，存在三个核心角色：发布端（Publisher）、订阅端（Subscriber）和主题（Topic）。发布端通过DataWriter将数据样本写入某个Topic，订阅端通过DataReader从该Topic读取数据。发布端和订阅端完全解耦——它们不需要知道彼此的地址、端口或存在状态，只需要共同约定一个Topic名称和匹配的数据类型即可。

DCPS模型的关键设计在于全局数据空间（Global Data Space）的概念。这是一个逻辑上的虚拟数据容器，所有发布端写入的数据都进入这个空间，所有订阅端从这个空间读取数据。全局数据空间并非一个物理集中式存储，而是通过DDS中间件在分布式节点间实现的逻辑抽象。每个节点上的DDS实现维护本地缓存，并通过RTPS协议与其他节点同步数据，从而在逻辑上形成一个统一的、全局可访问的数据视图。

判断方法或操作流程

在实际的ROS2工程中，判断一个通信设计是否符合DCPS模型，可以从以下三个维度进行验证：

1. 数据是否通过Topic解耦：发布端和订阅端是否只通过Topic名称和数据类型进行交互，而不直接引用对方的节点名或服务地址。
2. QoS是否作为匹配条件：发布端和订阅端的QoS策略是否在发现阶段进行兼容性校验，不兼容的QoS会导致通信建立失败。
3. 数据是否以样本（Sample）为单位：每次写入的数据是否被视为一个独立的数据样本，带有时间戳和序列号，而不是一个持续的数据流。

常见误区或总结复盘

2.2 发布-订阅范式与QoS策略

核心原理

发布-订阅（Publish-Subscribe）范式是DDS通信的基本模式。在这个范式中，数据生产者（发布者）将数据样本发布到Topic，数据消费者（订阅者）从Topic接收数据。这种模式的核心优势在于空间解耦（双方不需要知道对方的存在）、时间解耦（双方不需要同时在线）和流量解耦（发布速率和订阅速率可以不同，由中间件缓冲）。

QoS（Quality of Service）策略是DDS区别于其他通信中间件的核心特性。QoS策略是一组可配置的参数，用于控制数据分发的行为。常用的QoS策略包括：

QoS策略	作用	典型配置	ROS2映射
RELIABILITY	控制数据传输的可靠性	RELIABLE（可靠）/ BEST_EFFORT（尽力而为）	可靠传输保证不丢数据，适合指令、状态；尽力而为适合传感器高频数据
DURABILITY	控制数据是否对后加入的订阅者保留	VOLATILE（不保留）/ TRANSIENT_LOCAL（保留最后状态）	用于late joiner场景，如地图数据、静态配置
HISTORY	控制缓存的历史样本数量	KEEP_LAST（保留最近N个）/ KEEP_ALL（保留全部）	与DURABILITY配合使用，depth参数控制缓存深度
DEADLINE	设置数据更新的最大时间间隔	例如100ms	用于检测数据超时，如心跳信号
LIVELINESS	检测节点是否存活	AUTOMATIC（自动）/ MANUAL（手动）	用于故障检测，如节点崩溃检测

判断方法或操作流程

在ROS2中配置QoS策略时，需要遵循以下操作流程：

1. 分析数据特性：确定数据是高频传感器数据（如激光雷达点云）还是低频控制指令（如导航目标点）。
2. 选择可靠性策略：传感器数据通常使用BEST_EFFORT以减少延迟和丢包重传开销；控制指令使用RELIABLE确保不丢失。
3. 配置历史深度：对于需要回放的数据，设置KEEP_LAST并指定depth值（如10）；对于实时性要求极高的数据，设置KEEP_LAST depth=1。
4. 设置期限和活性：对于需要监控的数据，设置DEADLINE和LIVELINESS策略。
5. 验证QoS兼容性：发布端和订阅端的QoS必须兼容，否则通信无法建立。ROS2中可以通过rclcpp::QoS类进行配置，并在运行时通过qos_check工具验证兼容性。

案例拆解或实战场景

场景：在一个多机器人协同系统中，机器人A需要向机器人B发送实时位置信息（10Hz），同时机器人B需要接收来自调度中心的路径规划指令（低频，但要求可靠）。

分析：位置信息属于高频实时数据，允许偶尔丢帧，使用BEST_EFFORT + KEEP_LAST(depth=1)即可；路径规划指令属于关键控制数据，必须可靠到达，使用RELIABLE + KEEP_LAST(depth=10)确保指令不丢失且可回放。

操作：在ROS2中分别创建两个发布者，配置不同的QoS策略。订阅端根据数据特性选择对应的QoS进行订阅。通过ros2 topic info --verbose命令可以查看当前Topic的QoS兼容性状态。

结果：位置信息传输延迟降低约30%（相比RELIABLE模式），路径规划指令零丢失，系统整体稳定性显著提升。

2.3 RTPS协议：DDS的线协议标准

核心原理

RTPS（Real-Time Publish-Subscribe Protocol）是DDS规范中定义的线协议（Wire Protocol），它规定了DDS数据在网络上传输时的字节格式、消息类型和交互流程。RTPS协议基于UDP/IP传输层，支持多播和单播通信，并定义了以下核心机制：

• 发现（Discovery）：包括SPDP（Simple Participant Discovery Protocol）用于发现参与者（Participant），SEDP（Simple Endpoint Discovery Protocol）用于发现端点（DataWriter/DataReader）。
• 数据交换：定义了数据样本的序列化格式和传输方式，支持分片（Fragmentation）和重组。
• 可靠性机制：通过Heartbeat（心跳）和NACK（Negative Acknowledgment）消息实现可靠传输，发送方发送Heartbeat告知接收方数据范围，接收方通过NACK请求缺失的数据。
• 多通道传输：支持将数据分发到多个订阅者，通过多播地址实现高效分发。

判断方法或操作流程

在实际网络环境中，可以通过以下方法验证RTPS协议的工作状态：

1. 抓包分析：使用Wireshark抓取UDP端口7400-7500范围内的数据包，观察SPDP/SEDP发现消息和DATA消息。
2. 检查发现流程：在ROS2中启动节点时，观察终端日志中的发现过程，确认参与者（Participant）和端点（Endpoint）是否成功发现。
3. 监控可靠性状态：使用ros2 doctor命令检查DDS通信的健康状态，包括丢包率、延迟等指标。

常见误区或总结复盘

2.4 DDS与ROS1通信对比

核心原理

ROS1使用自研的TCPROS/UDPROS通信机制，基于TCP/IP或UDP/IP协议，采用中心化的Master节点进行名称解析和连接建立。ROS2则完全基于DDS，去除了Master节点，实现了真正的去中心化分布式通信。两者的核心差异如下：

对比维度	ROS1（TCPROS/UDPROS）	ROS2（DDS/RTPS）
架构模式	中心化（依赖Master节点）	去中心化（P2P发现）
通信协议	TCP/UDP自定义协议	RTPS标准协议（UDP/IP）
数据序列化	自定义序列化（rosmsg）	CDR（Common Data Representation）标准
QoS支持	无（仅TCP可靠/UDP尽力）	丰富的QoS策略（可靠性、时效性、历史深度等）
实时性	无实时性保证	支持实时通信（配合实时操作系统）
跨语言支持	C++/Python（通过roscpp/rospy）	C++/Python/Rust/Java等（通过DDS实现）
安全性	无内置安全机制	支持DDS Security（认证、加密、访问控制）
动态发现	需要Master节点，节点启动顺序敏感	自动发现，节点可随时加入/退出

判断方法或操作流程

在从ROS1迁移到ROS2时，需要关注以下关键变化：

1. 节点发现机制：ROS1中节点启动时必须先启动Master；ROS2中节点自动发现，无需中心节点。
2. 消息传递语义：ROS1中Topic消息默认是TCP可靠传输；ROS2中需要显式配置QoS策略。
3. API变化：ROS2的rclcpp/rclpy API与ROS1的roscpp/rospy有较大差异，需要重新编写代码。
4. 工具链变化：rosnode、rostopic等命令替换为ros2 node、ros2 topic等。

案例拆解或实战场景

场景：一个移动机器人项目从ROS1迁移到ROS2，原系统包含10个节点，通过Master节点管理。迁移后，系统需要支持多机器人协同，且要求节点可以动态加入/退出。

分析：ROS1的中心化架构在单机器人场景下工作良好，但在多机器人协同中，Master节点成为单点故障，且跨机器人通信需要额外配置。ROS2的去中心化架构天然支持多机器人场景。

操作：迁移过程中，将原有的Topic通信改为ROS2的Topic通信，并根据数据特性配置QoS策略。对于传感器数据（如激光雷达）使用BEST_EFFORT，对于控制指令使用RELIABLE。同时，将原有的Master节点相关代码（如ros::init、ros::NodeHandle）替换为ROS2的rclcpp::init和rclcpp::Node。

结果：迁移后系统支持多机器人动态组网，节点故障不影响整体通信，通信延迟在局域网内保持在1ms以内，满足实时控制需求。

常见误区或总结复盘