DDS：数据分发服务在机器人通信中的应用

引言

在机器人技术快速发展的今天，分布式系统的实时通信能力直接影响着机器人应用的性能和可靠性。无论是多机器人协作、传感器数据融合，还是复杂的控制系统，都需要高效、可靠、实时的数据交换机制。传统的通信方案，如 TCP/IP、UDP 或简单的消息队列，往往难以同时满足实时性、可靠性和可扩展性的要求，限制了复杂机器人系统的发展。

DDS（Data Distribution Service，数据分发服务）的出现，为这一挑战提供了一个工业级的解决方案。作为由 OMG（Object Management Group）制定的实时数据分发中间件标准，DDS 不仅提供了高效的发布-订阅通信模式，还通过丰富的 QoS（Quality of Service）策略，使得开发者可以根据应用需求精确控制通信行为。这种设计使得 DDS 在航空航天、自动驾驶、机器人等对实时性要求极高的领域得到了广泛应用。

DDS 的核心价值在于其以数据为中心的架构设计。与传统的以节点为中心的通信模型不同，DDS 将数据作为系统的核心，通过主题（Topic）和 QoS 策略，实现了发布者和订阅者的完全解耦。这种设计不仅提高了系统的灵活性，还支持动态发现、自动连接和智能路由，使得分布式系统的构建和维护变得更加简单。

从技术角度来看，DDS 基于 RTPS（Real-Time Publish-Subscribe）协议，提供了去中心化的发现机制和高效的数据传输能力。它支持多种 QoS 策略，包括可靠性、持久性、历史记录、期限、延迟预算和存活性等，使得开发者可以根据不同的应用场景选择最合适的配置。更重要的是，DDS 的标准化设计确保了不同实现之间的互操作性，使得系统可以灵活地选择最适合的 DDS 实现。

在机器人领域，DDS 的应用尤为广泛。ROS2 将 DDS 作为其默认的通信中间件，通过 DDS 实现了去中心化的节点通信，摆脱了 ROS1 中依赖中央节点的限制。Unitree SDK2 采用 DDS 作为其通信基础，为机器人控制提供了低延迟、高可靠性的通信保障。在自动驾驶领域，超过 200 个车型项目采用了 DDS，用于传输传感器数据和控制命令。这些应用充分证明了 DDS 在机器人通信中的价值和重要性。

本文将带您全面深入地了解 DDS 的方方面面，从基础概念到技术架构，从 QoS 策略到实际应用，从安装配置到最佳实践。无论您是刚开始接触分布式通信的新手，还是希望深入了解 DDS 技术细节的资深开发者，都能从本文中获得有价值的知识和实践指导。我们将重点关注实用操作，提供详细的技术分析、代码示例和使用案例，帮助您在实际项目中快速应用 DDS 的强大功能。

第一部分：DDS 基础概念

什么是 DDS

DDS（Data Distribution Service，数据分发服务）是由 OMG（Object Management Group）制定的分布式实时通信中间件标准，旨在通过发布-订阅（Publish-Subscribe）模式实现高性能、可扩展的数据交换。DDS 的核心目标是提供一个标准化的、高性能的、可靠的实时数据分发平台，满足各种分布式应用对实时通信的需求。

DDS 的历史发展

DDS 标准的开发始于 2001 年，OMG 于 2004 年发布了 DDS 1.0 版本。随后，DDS 标准经历了多次更新和完善：

DDS 1.0（2004 年）：首次发布，定义了核心的 DCPS（Data-Centric Publish-Subscribe）模型
DDS 1.1（2005 年 12 月）：增加了对 C++ 和 Java 的 API 支持
DDS 1.2（2007 年 1 月）：引入了更多的 QoS 策略和扩展功能
DDS 1.4（2015 4 月）：进一步完善了 QoS 策略和互操作性

DDS 标准主要由四个部分组成：

核心标准：定义了数据中心的发布-订阅（DCPS）模型，确保信息高效传递给正确的接收者
扩展标准：提供了额外的功能和服务，以满足特定应用需求
网关标准：确保不同 DDS 实现之间的互操作性，允许跨供应商的系统进行通信
API 标准：定义了应用程序接口，方便开发者集成和使用 DDS 服务

DDS 的定位

在分布式通信生态系统中，DDS 占据了一个独特的位置。它既不是简单的消息队列（如 RabbitMQ、Kafka），也不是传统的 RPC 框架（如 gRPC、Thrift），而是一个专门为实时、可靠、可扩展的数据分发而设计的中间件标准。DDS 特别适合以下应用场景：

实时性要求高：需要低延迟、可预测的通信性能
可靠性要求高：需要保证数据不丢失、按顺序传输
可扩展性强：需要支持动态添加和移除节点
分布式系统：需要在多个节点之间进行数据交换

DDS 的应用领域

DDS 在多个领域得到了广泛应用：

航空航天：用于飞机系统、卫星通信、地面控制系统
自动驾驶：用于传感器数据分发、控制命令传输、多 ECU 通信
机器人：用于机器人控制、传感器融合、多机器人协作
国防：用于军事系统、指挥控制系统
医疗设备：用于医疗设备之间的数据交换
工业自动化：用于工业控制系统、SCADA 系统
能源管理：用于智能电网、能源监控系统

DDS 的核心设计理念

DDS 遵循几个核心设计理念，这些理念指导了其架构设计和功能实现：

1. 以数据为中心（Data-Centric）

DDS 采用以数据为中心的架构，将数据作为系统的核心，而不是以节点或服务为中心。在这种架构中，发布者发布数据到主题（Topic），订阅者订阅感兴趣的主题并接收数据。这种设计使得发布者和订阅者完全解耦，提高了系统的灵活性和可扩展性。

2. 发布-订阅模式（Publish-Subscribe）

DDS 采用发布-订阅通信模式，这是一种异步的、多对多的通信模式。发布者不需要知道订阅者的存在，订阅者也不需要知道发布者的位置，它们通过主题进行连接。这种模式非常适合分布式系统，因为它支持：

一对多通信：一个发布者可以向多个订阅者发送数据
动态发现：节点可以自动发现和连接
解耦设计：发布者和订阅者相互独立

3. 服务质量保证（Quality of Service）

DDS 提供了丰富的 QoS 策略，允许开发者根据应用需求精确控制通信行为。这些 QoS 策略包括：

可靠性（Reliability）：控制数据传输的可靠性
持久性（Durability）：控制数据的持久化级别
历史记录（History）：控制历史数据的保留策略
期限（Deadline）：控制数据发布的期限要求
延迟预算（LatencyBudget）：控制数据传输的延迟要求
存活性（Liveliness）：监控节点的活跃状态

4. 实时性优先（Real-Time First）

DDS 的设计优先考虑实时性，通过优化的协议栈和 QoS 机制，确保数据传输的低延迟和可预测性。这对于对实时性要求极高的应用（如机器人控制、自动驾驶）至关重要。

5. 标准化与互操作性

DDS 是一个开放的标准，确保了不同实现之间的互操作性。这意味着使用不同 DDS 实现的系统可以相互通信，提高了系统的灵活性和可移植性。

DDS 与相关技术的关系

理解 DDS，需要理解它与相关技术的关系和区别：

DDS vs ROS1

架构差异：ROS1 基于节点和话题的架构，使用 TCP/UDP 通信，依赖中央节点（roscore）；DDS 采用去中心化的发布-订阅架构，不需要中央节点
实时性：DDS 提供了更好的实时性保证，通过 QoS 策略可以精确控制通信行为；ROS1 的实时性相对较弱
可靠性：DDS 通过 QoS 策略提供了灵活的可靠性配置；ROS1 的可靠性主要依赖于 TCP 协议
适用场景：ROS1 适合复杂的机器人系统集成，有丰富的生态系统；DDS 适合对实时性和可靠性要求高的应用

DDS vs MQTT

通信模式：MQTT 采用客户端-服务器模式，需要消息代理（Broker）；DDS 采用去中心化的发布-订阅模式，不需要中央代理
实时性：DDS 提供了更好的实时性，延迟更低；MQTT 的延迟相对较高
QoS 支持：MQTT 提供了简单的 QoS 级别（0、1、2）；DDS 提供了更丰富的 QoS 策略
适用场景：MQTT 适合 IoT 应用，资源受限的环境；DDS 适合高性能的实时应用

DDS vs gRPC

通信模式：gRPC 采用客户端-服务器模式，基于 HTTP/2；DDS 采用发布-订阅模式
数据交换：gRPC 适合请求-响应交互；DDS 适合持续的数据流
实时性：DDS 提供了更好的实时性；gRPC 的实时性相对较弱
适用场景：gRPC 适合微服务架构、API 调用；DDS 适合实时数据分发

DDS 在 ROS2 中的作用

ROS2 将 DDS 作为其默认的通信中间件，这是 ROS2 相对于 ROS1 的重要改进之一。在 ROS2 中：

DDS 提供了底层的通信能力，实现了节点之间的数据交换
ROS2 的节点、话题、服务等概念都建立在 DDS 的基础上
ROS2 支持多种 DDS 实现，包括 Fast DDS、Cyclone DDS、RTI Connext DDS 等
DDS 的 QoS 策略可以通过 ROS2 的 QoS 配置进行设置

第二部分：DDS 技术架构

DCPS（Data-Centric Publish-Subscribe）是 DDS 的核心模型，定义了数据分发的抽象接口。理解 DCPS 模型是理解 DDS 的关键。

DCPS 的核心实体

DCPS 模型定义了以下核心实体：

域参与者（DomainParticipant）
- 域参与者是应用程序进入 DDS 域的入口点
- 每个应用程序必须创建一个域参与者才能使用 DDS
- 域参与者管理发布者、订阅者、主题等实体
- 域参与者属于特定的域（Domain），不同域的参与者不能直接通信
发布者（Publisher）
- 发布者负责创建和管理数据写入者（DataWriter）
- 一个域参与者可以创建多个发布者
- 发布者可以配置 QoS 策略，这些策略会应用到其创建的所有数据写入者
订阅者（Subscriber）
- 订阅者负责创建和管理数据读取者（DataReader）
- 一个域参与者可以创建多个订阅者
- 订阅者可以配置 QoS 策略，这些策略会应用到其创建的所有数据读取者
主题（Topic）
- 主题是发布者和订阅者之间的连接桥梁
- 主题定义了数据的类型和名称
- 发布者将数据发布到主题，订阅者订阅主题并接收数据
- 主题必须与数据类型关联，数据类型定义了数据的结构
数据写入者（DataWriter）
- 数据写入者负责将数据写入到主题
- 每个数据写入者关联一个主题
- 数据写入者可以配置 QoS 策略，控制数据的发布行为
数据读取者（DataReader）
- 数据读取者负责从主题读取数据
- 每个数据读取者关联一个主题
- 数据读取者可以配置 QoS 策略，控制数据的接收行为

DCPS 的数据流

DCPS 模型的数据流如下：

发布流程：
- 应用程序创建域参与者
- 创建发布者和数据写入者
- 注册数据类型
- 创建主题
- 将数据写入者关联到主题
- 应用程序调用 write() 方法发布数据
订阅流程：
- 应用程序创建域参与者
- 创建订阅者和数据读取者
- 注册数据类型
- 创建主题（或使用已存在的主题）
- 将数据读取者关联到主题
- 应用程序调用 read() 或 take() 方法接收数据
发现流程：
- DDS 自动发现机制会检测匹配的发布者和订阅者
- 当发布者和订阅者的主题名称和数据类型匹配时，它们会自动建立连接
- 发现过程是去中心化的，不需要中央节点

RTPS（Real-Time Publish-Subscribe Protocol）是 DDS 的有线互操作协议，定义了数据在网络上传输的格式和行为。RTPS 协议确保了不同 DDS 实现之间的互操作性。

RTPS 协议栈

RTPS 协议栈包括以下层次：

应用层：DDS API 和应用程序
RTPS 层：RTPS 协议实现，包括发现、数据传输、可靠性等
传输层：UDP/IP、TCP/IP 等网络协议
物理层：以太网、WiFi 等物理网络

RTPS 发现机制

RTPS 提供了去中心化的发现机制，使得节点可以自动发现和连接。发现机制包括两个阶段：

参与者发现（Participant Discovery）
- 使用 SPDP（Simple Participant Discovery Protocol）协议
- 每个域参与者定期发送 SPDP 消息，声明自己的存在
- SPDP 消息包含域参与者的唯一标识符、IP 地址、端口等信息
- 域参与者通过接收 SPDP 消息发现其他参与者
端点发现（Endpoint Discovery）
- 使用 SEDP（Simple Endpoint Discovery Protocol）协议
- 在参与者发现后，使用 SEDP 交换数据写入者和数据读取者的信息
- SEDP 消息包含主题名称、数据类型、QoS 策略等信息
- 当数据写入者和数据读取者匹配时，它们建立连接

RTPS 数据传输

RTPS 定义了数据传输的格式和流程：

数据包格式：RTPS 定义了标准的数据包格式，包括头部、子消息、数据负载等
可靠性传输：对于可靠 QoS，RTPS 使用确认和重传机制确保数据可靠传输
多播和单播：RTPS 支持多播和单播传输，可以根据需要选择最合适的传输方式
流控制：RTPS 提供了流控制机制，防止数据发送过快导致接收方溢出

DDS 域（Domain）与域参与者（DomainParticipant）

域（Domain）的概念

DDS 域是一个逻辑上的通信边界，属于不同域的参与者不能直接通信。域的概念使得多个独立的 DDS 应用可以在同一个物理网络上运行，而不会相互干扰。

域 ID：每个域有一个唯一的域 ID（通常是一个整数），域 ID 范围是 0-230
域隔离：不同域的参与者完全隔离，即使它们在同一物理网络上
域内通信：只有属于同一域的参与者才能相互通信

域参与者（DomainParticipant）

域参与者是应用程序进入 DDS 域的入口点，是 DDS 应用程序的基础实体。

域参与者的作用：

管理发布者、订阅者、主题等实体
注册数据类型
参与发现过程
配置域级别的 QoS 策略

创建域参与者：

#include <fastdds/dds/domain/DomainParticipantFactory.hpp>

using namespace eprosima::fastdds::dds;

// 创建域参与者，域 ID 为 0
DomainParticipant* participant =
    DomainParticipantFactory::get_instance()->create_participant(
        0,  // 域 ID
        PARTICIPANT_QOS_DEFAULT,  // QoS 策略
        nullptr  // 监听器
    );

多域通信

虽然不同域的参与者不能直接通信，但可以通过以下方式实现跨域通信：

网关（Gateway）：使用 DDS 网关在不同域之间转发数据
多域参与者：一个应用程序可以创建多个域参与者，分别属于不同的域
桥接服务：使用桥接服务在不同域之间建立连接

第三部分：QoS 服务质量策略

QoS 策略概述

QoS（Quality of Service）是 DDS 的核心特性之一，它允许开发者根据应用需求精确控制通信行为。DDS 提供了丰富的 QoS 策略，每个策略都可以独立配置，使得系统可以针对不同的应用场景进行优化。

QoS 的重要性

QoS 策略的重要性体现在：

性能优化：通过合理配置 QoS，可以优化系统的性能，减少延迟，提高吞吐量
可靠性保证：通过可靠性 QoS，可以确保关键数据不丢失
资源管理：通过资源限制 QoS，可以防止系统资源耗尽
实时性保证：通过延迟预算和期限 QoS，可以保证实时性要求

QoS 策略的分类

DDS 的 QoS 策略可以分为以下几类：

数据可用性 QoS：控制数据的可用性和持久性
数据传输 QoS：控制数据传输的方式和可靠性
资源 QoS：控制资源的分配和使用
时间 QoS：控制时间相关的行为和约束
所有权 QoS：控制数据的所有权和访问权限

QoS 策略的作用范围

QoS 策略可以在多个层次配置：

域参与者 QoS：影响域参与者的行为
发布者/订阅者 QoS：影响发布者/订阅者及其创建的所有数据写入者/数据读取者
主题 QoS：影响主题的行为
数据写入者/数据读取者 QoS：影响具体的数据写入者/数据读取者

QoS 策略的匹配

DDS 使用 QoS 策略匹配来决定发布者和订阅者是否可以建立连接。只有当发布者和订阅者的 QoS 策略兼容时，它们才能建立连接。QoS 策略的匹配规则：

请求 vs 提供：订阅者请求的 QoS 必须被发布者提供的 QoS 满足
兼容性检查：DDS 会自动检查 QoS 策略的兼容性
不匹配处理：如果 QoS 不匹配，连接将无法建立

可靠性策略（Reliability）

可靠性 QoS 策略控制数据传输的可靠性，决定数据是否保证被成功传输。

可靠性模式

DDS 提供了两种可靠性模式：

BEST_EFFORT（尽力而为）
- 不保证数据成功传输，可能会出现数据丢失
- 性能更好，延迟更低
- 适用于对数据完整性要求不高，但对实时性要求较高的场景
- 例如：传感器数据流、视频流、状态更新
RELIABLE（可靠）
- 保证数据成功传输，如果出现数据丢失，系统会进行重传
- 性能相对较低，延迟可能较高
- 适用于对数据完整性要求高的应用场景
- 例如：控制命令、配置信息、关键状态

可靠性配置

#include <fastdds/dds/publisher/DataWriter.hpp>
#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 创建数据写入者 QoS
DataWriterQos writer_qos;
writer_qos.reliability().kind = RELIABLE_RELIABILITY_QOS;

// 创建数据写入者
DataWriter* writer = publisher->create_datawriter(
    topic,
    writer_qos,
    nullptr
);

可靠性匹配规则

发布者和订阅者的可靠性 QoS 必须匹配
如果发布者使用 RELIABLE，订阅者必须使用 RELIABLE
如果发布者使用 BEST_EFFORT，订阅者可以使用 BEST_EFFORT 或 RELIABLE（但实际效果是 BEST_EFFORT）

持久性策略（Durability）

持久性 QoS 策略控制数据的持久化级别，决定新加入的订阅者是否能够接收到历史数据。

持久性模式

DDS 提供了四种持久性模式：

VOLATILE（易失）
- 数据仅在发布者和订阅者都在线时传输
- 新订阅者无法接收到发布者之前发送的历史数据
- 内存占用最少
- 适用于实时数据流，不需要历史数据
TRANSIENT_LOCAL（瞬态本地）
- 发布者在本地存储数据
- 新订阅者可以接收到发布者之前发送的历史数据（直到订阅者连接）
- 数据存储在内存中，进程退出后数据丢失
- 适用于需要最新状态数据的场景
TRANSIENT（瞬态）
- 数据存储在 DDS 服务中
- 新订阅者可以接收到所有历史数据
- 数据存储在内存中，服务重启后数据丢失
- 适用于需要完整历史数据的场景
PERSISTENT（持久）
- 数据持久化到磁盘
- 新订阅者可以接收到所有历史数据
- 即使服务重启，数据也不会丢失
- 适用于需要长期保存数据的场景

持久性配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 配置为瞬态本地持久性
DataWriterQos writer_qos;
writer_qos.durability().kind = TRANSIENT_LOCAL_DURABILITY_QOS;

// 配置历史记录深度（保留最新的 10 个样本）
writer_qos.history().kind = KEEP_LAST_HISTORY_QOS;
writer_qos.history().depth = 10;

持久性匹配规则

订阅者的持久性 QoS 必须大于或等于发布者的持久性 QoS
例如：如果发布者使用 VOLATILE，订阅者可以使用任何持久性级别
如果发布者使用 TRANSIENT_LOCAL，订阅者必须使用 TRANSIENT_LOCAL、TRANSIENT 或 PERSISTENT

历史记录策略（History）

历史记录 QoS 策略控制 DDS 缓存保留多少历史样本。

历史记录模式

DDS 提供了两种历史记录模式：

KEEP_LAST（保留最新的 N 个）
- 只保留最新的 N 个样本
- 需要配置深度（depth）参数
- 内存占用可控
- 适用于只需要最新数据的场景
KEEP_ALL（保留所有）
- 保留所有样本，直到资源限制
- 需要配置资源限制 QoS
- 内存占用可能很大
- 适用于需要完整历史数据的场景

历史记录配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 配置历史记录策略
DataWriterQos writer_qos;

// 保留最新的 10 个样本
writer_qos.history().kind = KEEP_LAST_HISTORY_QOS;
writer_qos.history().depth = 10;

// 或者保留所有样本
writer_qos.history().kind = KEEP_ALL_HISTORY_QOS;

历史记录与持久性的关系

历史记录策略控制缓存中保留多少样本
持久性策略控制新订阅者能否访问历史数据
两者结合使用可以实现不同的数据访问策略

期限策略（Deadline）

期限 QoS 策略规定发布者发布数据的周期，订阅者可以监控发布者是否按期发布数据。

期限的作用

实时性保证：确保数据按预期频率发布
故障检测：订阅者可以检测发布者是否正常工作
系统监控：可以监控系统的实时性性能

期限配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>
#include <fastrtps/utils/Time.hpp>

using namespace eprosima::fastdds::dds;
using namespace eprosima::fastrtps;

// 配置期限为 100 毫秒
DataWriterQos writer_qos;
writer_qos.deadline().period.seconds = 0;
writer_qos.deadline().period.nanosec = 100000000;  // 100ms

期限监控

订阅者可以监听期限违约事件：

#include <fastdds/dds/subscriber/DataReaderListener.hpp>

class MyListener : public DataReaderListener {
public:
    void on_requested_deadline_missed(
        DataReader* reader,
        const RequestedDeadlineMissedStatus& status) override {
        // 处理期限违约
        std::cout << "Deadline missed!" << std::endl;
    }
};

延迟预算策略（LatencyBudget）

延迟预算 QoS 策略提示数据传输的期望延迟，有助于中间件进行优化。

延迟预算的作用

性能优化：中间件可以根据延迟预算优化传输路径
资源分配：可以根据延迟要求分配资源
系统设计：帮助开发者理解系统的延迟要求

延迟预算配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 配置延迟预算为 50 毫秒
DataWriterQos writer_qos;
writer_qos.latency_budget().duration.seconds = 0;
writer_qos.latency_budget().duration.nanosec = 50000000;  // 50ms

存活性策略（Liveliness）

存活性 QoS 策略用于监测发布者或订阅者的活跃状态，确保通信双方的存活性。

存活性模式

DDS 提供了三种存活性模式：

AUTOMATIC（自动）
- 由 DDS 中间件自动管理
- 当数据写入者写入数据或数据读取者读取数据时，自动更新存活性
- 适用于大多数场景
MANUAL_BY_PARTICIPANT（按参与者手动）
- 由域参与者手动声明存活性
- 所有属于该参与者的数据写入者/数据读取者共享存活性
- 适用于需要统一管理存活性的场景
MANUAL_BY_TOPIC（按主题手动）
- 由数据写入者/数据读取者手动声明存活性
- 每个数据写入者/数据读取者独立管理存活性
- 适用于需要精细控制存活性的场景

存活性配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 配置存活性策略
DataWriterQos writer_qos;
writer_qos.liveliness().kind = AUTOMATIC_LIVELINESS_QOS;
writer_qos.liveliness().lease_duration.seconds = 5;  // 5 秒租约

存活性监控

订阅者可以监听存活性变化事件：

#include <fastdds/dds/subscriber/DataReaderListener.hpp>

class MyListener : public DataReaderListener {
public:
    void on_liveliness_changed(
        DataReader* reader,
        const LivelinessChangedStatus& status) override {
        // 处理存活性变化
        std::cout << "Liveliness changed!" << std::endl;
    }
};

其他 QoS 策略

除了上述 QoS 策略，DDS 还提供了其他重要的 QoS 策略：

资源限制（ResourceLimits）

控制资源的分配和使用：

DataWriterQos writer_qos;
writer_qos.resource_limits().max_samples = 1000;
writer_qos.resource_limits().max_instances = 10;
writer_qos.resource_limits().max_samples_per_instance = 100;

所有权（Ownership）

控制数据的所有权：

DataWriterQos writer_qos;
writer_qos.ownership().kind = EXCLUSIVE_OWNERSHIP_QOS;
writer_qos.ownership_strength().value = 10;

时间过滤（TimeBasedFilter）

根据时间过滤数据：

DataReaderQos reader_qos;
reader_qos.time_based_filter().minimum_separation.seconds = 1;
reader_qos.time_based_filter().minimum_separation.nanosec = 0;

第四部分：DDS 在机器人领域的应用

DDS 在 ROS2 中的应用

ROS2（Robot Operating System 2）将 DDS 作为其默认的通信中间件，这是 ROS2 相对于 ROS1 的重要改进之一。

ROS2 的 DDS 中间件

ROS2 支持多种 DDS 实现，开发者可以根据需求选择合适的实现：

Fast DDS（eProsima）
- ROS2 的默认 DDS 实现
- 开源、高性能
- 支持 C++ 和 Python
- 适合大多数应用场景
Cyclone DDS（Eclipse）
- 轻量级、高性能
- 完全符合 DDS 标准
- 适合资源受限的环境
RTI Connext DDS
- 商业实现，功能最完整
- 提供丰富的工具和文档
- 适合商业应用
OpenSplice DDS
- 另一个商业实现
- 提供高性能和可靠性

ROS2 与 DDS 的集成

在 ROS2 中，DDS 提供了底层的通信能力：

节点通信：ROS2 节点通过 DDS 进行通信
话题通信：ROS2 话题对应 DDS 主题
服务通信：ROS2 服务使用 DDS 的请求-响应模式
QoS 配置：ROS2 的 QoS 配置直接映射到 DDS 的 QoS 策略

ROS2 QoS 配置示例

#include <rclcpp/rclcpp.hpp>
#include <std_msgs/msg/string.hpp>

using namespace std::chrono_literals;

class PublisherNode : public rclcpp::Node {
public:
    PublisherNode() : Node("publisher_node") {
        // 配置 QoS
        rclcpp::QoS qos(10);
        qos.reliability(RMW_QOS_POLICY_RELIABILITY_RELIABLE);
        qos.durability(RMW_QOS_POLICY_DURABILITY_TRANSIENT_LOCAL);

        // 创建发布者
        publisher_ = this->create_publisher<std_msgs::msg::String>(
            "topic", qos);

        // 定时发布
        timer_ = this->create_wall_timer(
            500ms, std::bind(&PublisherNode::timer_callback, this));
    }

private:
    void timer_callback() {
        auto message = std_msgs::msg::String();
        message.data = "Hello, ROS2!";
        publisher_->publish(message);
    }

    rclcpp::Publisher<std_msgs::msg::String>::SharedPtr publisher_;
    rclcpp::TimerBase::SharedPtr timer_;
};

ROS2 DDS 的优势

去中心化：不需要中央节点（roscore），提高了系统的可靠性
实时性：DDS 提供了更好的实时性保证
可靠性：通过 QoS 策略可以精确控制通信行为
互操作性：不同 DDS 实现之间可以互操作

DDS 在 Unitree SDK2 中的应用

Unitree SDK2 采用 DDS 作为其通信基础，为机器人控制提供了低延迟、高可靠性的通信保障。

SDK2 的 DDS 通信架构

Unitree SDK2 使用 DDS 实现以下通信模式：

发布-订阅模式：用于实时数据交换，如传感器数据、控制命令等
客户端-服务器模式：用于处理高级服务请求，如配置管理、任务执行等

SDK2 的 DDS 实现

SDK2 基于 DDS 实现了分层的 API：

高级语义 API：提供面向任务的抽象接口
通信系统：基于 DDS 的实时通信架构
控制接口：提供对机器人硬件的直接访问能力

SDK2 DDS 通信示例

#include <unitree/robot/channel/channel_publisher.hpp>
#include <unitree/common/time/time_tool.hpp>

int main() {
    // 创建发布者
    unitree::robot::ChannelPublisher<MyDataType> publisher;
    publisher.Init("my_topic_name");

    // 准备数据
    MyDataType data;
    data.value = 123;
    data.timestamp = unitree::common::TimeTool::GetCurrentTime();

    // 发布数据
    publisher.Write(data);

    return 0;
}

SDK2 DDS 的优势

实时性：DDS 架构提供了优秀的实时性能
可靠性：QoS 机制保证了通信的可靠性
跨平台：支持 x86_64 和 aarch64 架构
易用性：高级 API 使得开发变得简单

DDS 在自动驾驶中的应用

在自动驾驶领域，DDS 被广泛应用于传感器数据分发、控制命令传输和多 ECU 通信。

传感器数据分发

自动驾驶系统需要处理来自多种传感器的数据：

视觉传感器：摄像头数据
激光雷达：点云数据
毫米波雷达：目标检测数据
GPS/IMU：定位和姿态数据

DDS 通过发布-订阅模式，使得这些传感器数据可以在不同的 ECU 之间高效分发。

控制命令传输

自动驾驶系统需要将控制命令传输到执行器：

转向控制：方向盘角度
制动控制：制动力
加速控制：油门开度

DDS 的可靠性 QoS 确保了这些关键控制命令的可靠传输。

多 ECU 通信

自动驾驶系统包含多个 ECU（Electronic Control Unit），DDS 提供了高效的跨 ECU 通信能力：

实时性：低延迟的通信保证了控制的实时性
可靠性：可靠的传输保证了系统的安全性
可扩展性：可以方便地添加新的 ECU

自动驾驶 DDS 应用案例

超过 200 个车型项目采用了 DDS，包括：

丰田（Toyota）
通用（General Motors）
大众（Volkswagen）
奥迪（Audi）
奔驰（Mercedes-Benz）

DDS 在其他机器人系统中的应用

工业机器人

在工业机器人系统中，DDS 用于：

机器人控制：控制命令的实时传输
传感器融合：多传感器数据的融合
安全监控：安全状态的实时监控

无人机系统

在无人机系统中，DDS 用于：

飞行控制：控制命令的传输
传感器数据：GPS、IMU、摄像头等传感器数据的分发
地面站通信：无人机与地面站的通信

多机器人协作

在多机器人协作系统中，DDS 用于：

任务协调：机器人之间的任务协调
状态共享：机器人状态的共享
冲突避免：机器人之间的冲突避免

第五部分：DDS 实践指南

DDS 实现选择

DDS 是一个标准，有多种实现可供选择。选择合适的实现对于项目的成功至关重要。

主要 DDS 实现对比

Fast DDS（eProsima）
- 许可证：Apache 2.0（开源）
- 语言支持：C++、Python
- 性能：高性能，适合大多数应用
- 社区：活跃的开源社区
- 适用场景：ROS2、机器人应用、研究项目
- 优势：开源、免费、性能好、文档完善
- 劣势：商业支持有限
Cyclone DDS（Eclipse）
- 许可证：Eclipse Public License 2.0（开源）
- 语言支持：C、C++
- 性能：轻量级、高性能
- 社区：Eclipse 基金会支持
- 适用场景：资源受限的环境、嵌入式系统
- 优势：轻量级、完全符合标准、性能好
- 劣势：功能相对较少
RTI Connext DDS
- 许可证：商业许可证
- 语言支持：C、C++、Java、C#、Python 等
- 性能：高性能、功能完整
- 社区：商业支持
- 适用场景：商业应用、关键系统
- 优势：功能最完整、工具丰富、商业支持
- 劣势：需要商业许可证
OpenSplice DDS
- 许可证：商业许可证
- 语言支持：C、C++、Java
- 性能：高性能
- 社区：商业支持
- 适用场景：商业应用
- 优势：高性能、可靠性高
- 劣势：需要商业许可证

选择建议

开源项目：推荐 Fast DDS 或 Cyclone DDS
商业项目：可以考虑 RTI Connext DDS
资源受限：推荐 Cyclone DDS
ROS2 应用：推荐 Fast DDS（ROS2 默认）

Fast DDS 安装与配置

系统要求

操作系统：Linux（Ubuntu 20.04+ 推荐）、Windows、macOS
编译器：GCC 7+、Clang 5+、MSVC 2017+
CMake：3.10+
依赖库：asio、tinyxml2、foonathan_memory 等

Ubuntu 安装

# 安装依赖
sudo apt update
sudo apt install -y \
    cmake \
    g++ \
    libasio-dev \
    libtinyxml2-dev \
    libssl-dev \
    libp11-kit-dev \
    libengine-pkcs11-openssl

# 从源码编译安装
git clone https://github.com/eProsima/Fast-DDS.git
cd Fast-DDS
mkdir build && cd build
cmake ..
make -j$(nproc)
sudo make install

ROS2 中的 Fast DDS

如果使用 ROS2，Fast DDS 通常已经包含在 ROS2 安装中：

# 安装 ROS2（包含 Fast DDS）
sudo apt install ros-humble-desktop

# 设置环境变量使用 Fast DDS
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp

配置文件

Fast DDS 使用 XML 配置文件进行配置：

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <participant profile_name="default">
        <rtps>
            <builtin>
                <discovery_config>
                    <discoveryProtocol>SIMPLE</discoveryProtocol>
                </discovery_config>
            </builtin>
        </rtps>
    </participant>
</profiles>

基础代码示例

C++ 发布者示例

#include <fastdds/dds/domain/DomainParticipantFactory.hpp>
#include <fastdds/dds/publisher/Publisher.hpp>
#include <fastdds/dds/publisher/DataWriter.hpp>
#include <fastdds/dds/topic/Topic.hpp>
#include <iostream>
#include <thread>
#include <chrono>

using namespace eprosima::fastdds::dds;

// 定义数据类型
struct HelloWorld {
    uint32_t index;
    std::string message;

    HelloWorld() : index(0) {}
    HelloWorld(uint32_t i, const std::string& msg)
        : index(i), message(msg) {}
};

int main() {
    // 创建域参与者
    DomainParticipant* participant =
        DomainParticipantFactory::get_instance()->create_participant(
            0, PARTICIPANT_QOS_DEFAULT);

    if (participant == nullptr) {
        std::cerr << "Failed to create participant" << std::endl;
        return 1;
    }

    // 注册数据类型（简化示例，实际需要使用 IDL 生成类型支持）
    // TypeSupport type(new HelloWorldPubSubType());
    // type.register_type(participant);

    // 创建发布者
    Publisher* publisher = participant->create_publisher(
        PUBLISHER_QOS_DEFAULT, nullptr);

    if (publisher == nullptr) {
        std::cerr << "Failed to create publisher" << std::endl;
        return 1;
    }

    // 创建主题
    Topic* topic = participant->create_topic(
        "HelloWorldTopic",
        "HelloWorld",
        TOPIC_QOS_DEFAULT);

    if (topic == nullptr) {
        std::cerr << "Failed to create topic" << std::endl;
        return 1;
    }

    // 创建数据写入者
    DataWriter* writer = publisher->create_datawriter(
        topic,
        DATAWRITER_QOS_DEFAULT,
        nullptr);

    if (writer == nullptr) {
        std::cerr << "Failed to create datawriter" << std::endl;
        return 1;
    }

    // 发布数据
    for (uint32_t i = 0; i < 10; ++i) {
        HelloWorld msg(i, "Hello, DDS!");

        // 写入数据（实际需要使用类型支持）
        // writer->write(&msg);

        std::cout << "Published: index=" << msg.index
                  << ", message=" << msg.message << std::endl;

        std::this_thread::sleep_for(std::chrono::milliseconds(500));
    }

    // 清理资源
    publisher->delete_datawriter(writer);
    participant->delete_publisher(publisher);
    participant->delete_topic(topic);
    DomainParticipantFactory::get_instance()->delete_participant(participant);

    return 0;
}

C++ 订阅者示例

#include <fastdds/dds/domain/DomainParticipantFactory.hpp>
#include <fastdds/dds/subscriber/Subscriber.hpp>
#include <fastdds/dds/subscriber/DataReader.hpp>
#include <fastdds/dds/topic/Topic.hpp>
#include <iostream>
#include <thread>
#include <chrono>

using namespace eprosima::fastdds::dds;

// 定义数据类型（与发布者相同）
struct HelloWorld {
    uint32_t index;
    std::string message;
};

int main() {
    // 创建域参与者
    DomainParticipant* participant =
        DomainParticipantFactory::get_instance()->create_participant(
            0, PARTICIPANT_QOS_DEFAULT);

    // 创建订阅者
    Subscriber* subscriber = participant->create_subscriber(
        SUBSCRIBER_QOS_DEFAULT, nullptr);

    // 创建主题
    Topic* topic = participant->create_topic(
        "HelloWorldTopic",
        "HelloWorld",
        TOPIC_QOS_DEFAULT);

    // 创建数据读取者
    DataReader* reader = subscriber->create_datareader(
        topic,
        DATAREADER_QOS_DEFAULT,
        nullptr);

    // 读取数据
    for (int i = 0; i < 10; ++i) {
        // 实际需要使用类型支持读取数据
        // HelloWorld msg;
        // if (reader->take_next_sample(&msg, &info) == ReturnCode_t::RETCODE_OK) {
        //     std::cout << "Received: index=" << msg.index
        //               << ", message=" << msg.message << std::endl;
        // }

        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }

    // 清理资源
    subscriber->delete_datareader(reader);
    participant->delete_subscriber(subscriber);
    participant->delete_topic(topic);
    DomainParticipantFactory::get_instance()->delete_participant(participant);

    return 0;
}

Python 示例

import fastdds
import time

# 创建域参与者
factory = fastdds.DomainParticipantFactory.get_instance()
participant = factory.create_participant(0, fastdds.PARTICIPANT_QOS_DEFAULT)

# 创建发布者
publisher = participant.create_publisher(fastdds.PUBLISHER_QOS_DEFAULT)

# 创建主题
topic = participant.create_topic(
    "HelloWorldTopic",
    "HelloWorld",
    fastdds.TOPIC_QOS_DEFAULT)

# 创建数据写入者
writer = publisher.create_datawriter(topic, fastdds.DATAWRITER_QOS_DEFAULT)

# 发布数据
for i in range(10):
    # 实际需要使用 IDL 生成的数据类型
    # msg = HelloWorld()
    # msg.index = i
    # msg.message = "Hello, DDS!"
    # writer.write(msg)

    print(f"Published: index={i}")
    time.sleep(0.5)

# 清理资源
publisher.delete_datawriter(writer)
participant.delete_publisher(publisher)
participant.delete_topic(topic)
factory.delete_participant(participant)

高级应用示例

自定义 QoS 配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 创建自定义 QoS
DataWriterQos writer_qos;

// 配置可靠性
writer_qos.reliability().kind = RELIABLE_RELIABILITY_QOS;

// 配置持久性
writer_qos.durability().kind = TRANSIENT_LOCAL_DURABILITY_QOS;

// 配置历史记录
writer_qos.history().kind = KEEP_LAST_HISTORY_QOS;
writer_qos.history().depth = 10;

// 配置期限
writer_qos.deadline().period.seconds = 0;
writer_qos.deadline().period.nanosec = 100000000;  // 100ms

// 使用自定义 QoS 创建数据写入者
DataWriter* writer = publisher->create_datawriter(
    topic,
    writer_qos,
    nullptr);

多主题通信

// 创建多个主题
Topic* topic1 = participant->create_topic("Topic1", "Type1", TOPIC_QOS_DEFAULT);
Topic* topic2 = participant->create_topic("Topic2", "Type2", TOPIC_QOS_DEFAULT);

// 为每个主题创建数据写入者
DataWriter* writer1 = publisher->create_datawriter(topic1, DATAWRITER_QOS_DEFAULT, nullptr);
DataWriter* writer2 = publisher->create_datawriter(topic2, DATAWRITER_QOS_DEFAULT, nullptr);

// 发布到不同主题
// writer1->write(&data1);
// writer2->write(&data2);

错误处理

#include <fastdds/dds/core/status/StatusMask.hpp>

// 创建监听器处理错误
class MyListener : public DataWriterListener {
public:
    void on_offered_deadline_missed(
        DataWriter* writer,
        const OfferedDeadlineMissedStatus& status) override {
        std::cerr << "Deadline missed!" << std::endl;
    }

    void on_offered_incompatible_qos(
        DataWriter* writer,
        const OfferedIncompatibleQosStatus& status) override {
        std::cerr << "Incompatible QoS!" << std::endl;
    }
};

// 使用监听器
MyListener listener;
DataWriter* writer = publisher->create_datawriter(
    topic,
    DATAWRITER_QOS_DEFAULT,
    &listener);

第六部分：DDS 与其他通信方案对比

DDS vs ROS1

架构对比

特性	ROS1	DDS
通信模式	节点-话题	发布-订阅
中央节点	需要 roscore	不需要
发现机制	中央注册	去中心化自动发现
实时性	中等	高
可靠性	TCP/UDP	可配置 QoS
跨语言	有限	广泛支持

性能对比

延迟：DDS 通常具有更低的延迟，特别是在高负载情况下
吞吐量：DDS 的吞吐量通常更高
可扩展性：DDS 的去中心化架构提供了更好的可扩展性

适用场景

ROS1：适合复杂的机器人系统集成，有丰富的生态系统和工具
DDS：适合对实时性和可靠性要求高的应用，如机器人控制、自动驾驶

互操作性

ROS2 基于 DDS，可以通过桥接节点实现 ROS1 和 ROS2 之间的通信。

DDS vs MQTT

协议对比

特性	MQTT	DDS
通信模式	客户端-服务器	发布-订阅（去中心化）
消息代理	需要 Broker	不需要
QoS 级别	3 个简单级别	丰富的 QoS 策略
实时性	中等	高
资源消耗	低	中等
适用场景	IoT、轻量级应用	高性能实时应用

QoS 对比

MQTT：提供 3 个简单的 QoS 级别（0、1、2）
DDS：提供丰富的 QoS 策略，可以精确控制通信行为

适用场景

MQTT：适合 IoT 应用、资源受限的环境、需要消息代理的场景
DDS：适合高性能的实时应用、不需要消息代理的场景、对 QoS 要求高的应用

DDS vs gRPC

通信模式对比

特性	gRPC	DDS
通信模式	客户端-服务器	发布-订阅
数据交换	请求-响应	持续数据流
协议	HTTP/2	RTPS
实时性	中等	高
适用场景	微服务、API 调用	实时数据分发

性能对比

延迟：DDS 通常具有更低的延迟
吞吐量：对于持续数据流，DDS 的吞吐量通常更高
资源消耗：gRPC 的资源消耗相对较低

适用场景

gRPC：适合微服务架构、API 调用、请求-响应交互
DDS：适合实时数据分发、传感器数据流、控制命令传输

DDS vs ZeroMQ

消息模式对比

特性	ZeroMQ	DDS
消息模式	多种模式	发布-订阅
发现机制	手动配置	自动发现
QoS 支持	有限	丰富
标准化	非标准	OMG 标准
适用场景	通用消息传递	实时数据分发

性能对比

延迟：两者都具有低延迟
吞吐量：DDS 的吞吐量通常更高
易用性：ZeroMQ 的 API 更简单

适用场景

ZeroMQ：适合通用消息传递、简单的发布-订阅场景
DDS：适合需要丰富 QoS 策略、标准化、互操作性的场景

第七部分：DDS 最佳实践

QoS 策略选择指南

不同应用场景的 QoS 配置

实时传感器数据流

DataWriterQos qos;
qos.reliability().kind = BEST_EFFORT_RELIABILITY_QOS;
qos.durability().kind = VOLATILE_DURABILITY_QOS;
qos.history().kind = KEEP_LAST_HISTORY_QOS;
qos.history().depth = 1;

控制命令

DataWriterQos qos;
qos.reliability().kind = RELIABLE_RELIABILITY_QOS;
qos.durability().kind = TRANSIENT_LOCAL_DURABILITY_QOS;
qos.history().kind = KEEP_LAST_HISTORY_QOS;
qos.history().depth = 10;

状态信息

DataWriterQos qos;
qos.reliability().kind = RELIABLE_RELIABILITY_QOS;
qos.durability().kind = TRANSIENT_LOCAL_DURABILITY_QOS;
qos.history().kind = KEEP_LAST_HISTORY_QOS;
qos.history().depth = 1;

配置数据

DataWriterQos qos;
qos.reliability().kind = RELIABLE_RELIABILITY_QOS;
qos.durability().kind = PERSISTENT_DURABILITY_QOS;
qos.history().kind = KEEP_ALL_HISTORY_QOS;

QoS 匹配原则

订阅者的 QoS 必须满足发布者的 QoS 要求
可靠性：如果发布者使用 RELIABLE，订阅者必须使用 RELIABLE
持久性：订阅者的持久性级别必须大于或等于发布者
其他 QoS：根据具体策略的匹配规则

性能优化技巧

减少延迟

使用 BEST_EFFORT 可靠性：对于不需要可靠传输的数据
减少历史记录深度：只保留必要的历史数据
优化网络配置：使用低延迟网络，减少网络跳数
使用共享内存传输：对于同一机器上的通信

提高吞吐量

批量写入：一次写入多个样本
减少 QoS 检查：使用简单的 QoS 配置
优化数据类型：使用紧凑的数据结构
使用多播：对于一对多通信

资源管理

限制历史记录：使用 KEEP_LAST 而不是 KEEP_ALL
设置资源限制：防止资源耗尽
及时清理：删除不再使用的实体
监控资源使用：定期检查资源使用情况

调试与故障排除

常见问题

连接失败
- 检查域 ID 是否匹配
- 检查主题名称和数据类型是否匹配
- 检查 QoS 策略是否兼容
- 检查网络连接
数据丢失
- 检查可靠性 QoS 配置
- 检查历史记录深度
- 检查资源限制
延迟过高
- 检查网络延迟
- 检查 QoS 配置
- 检查系统负载

调试工具

Fast DDS 工具：fastdds discovery、fastdds shm 等
Wireshark：网络包分析工具
日志：启用 DDS 日志输出
性能分析工具：使用性能分析工具分析瓶颈

性能分析

// 启用统计信息
DataWriterQos qos;
qos.publish_mode().kind = ASYNCHRONOUS_PUBLISH_MODE;
qos.writer_data_lifecycle().autodispose_unregistered_instances = false;

// 获取统计信息
PublicationMatchedStatus status;
writer->get_publication_matched_status(status);
std::cout << "Matched subscribers: " << status.current_count << std::endl;

安全考虑

DDS 安全扩展

DDS 提供了安全扩展（DDS Security），包括：

身份认证：验证参与者的身份
访问控制：控制数据的访问权限
加密：加密数据传输
日志：记录安全事件

网络安全

使用 VPN：在公共网络上使用 VPN
防火墙配置：正确配置防火墙规则
网络隔离：将 DDS 流量隔离到专用网络

数据加密

// 配置加密（需要 DDS Security）
DataWriterQos qos;
// 配置安全属性
// qos.properties().properties().push_back(...);

第八部分：总结与展望

DDS 的优势总结

DDS 作为工业级的实时数据分发标准，具有以下主要优势：

1. 标准化

DDS 是 OMG 制定的开放标准，确保了不同实现之间的互操作性。这使得系统可以灵活地选择最适合的 DDS 实现，也可以在不同实现之间切换。

2. 高性能

DDS 通过优化的协议栈和 QoS 机制，提供了低延迟、高吞吐量的通信性能。这对于对实时性要求极高的应用（如机器人控制、自动驾驶）至关重要。

3. 丰富的 QoS 策略

DDS 提供了丰富的 QoS 策略，允许开发者根据应用需求精确控制通信行为。这些 QoS 策略包括可靠性、持久性、历史记录、期限、延迟预算、存活性等。

4. 去中心化架构

DDS 采用去中心化的发布-订阅架构，不需要中央节点。这种设计提高了系统的可靠性和可扩展性，也简化了系统的部署和维护。

5. 自动发现

DDS 提供了自动发现机制，节点可以自动发现和连接，不需要手动配置。这简化了分布式系统的构建和维护。

6. 跨平台支持

DDS 支持多种操作系统和编程语言，包括 Linux、Windows、macOS 和 C++、Java、Python、C# 等。

DDS 的局限性

尽管 DDS 具有许多优势，但也存在一些局限性：

1. 复杂性

DDS 的概念和 API 相对复杂，学习曲线较陡。特别是 QoS 策略的配置和理解需要一定的经验。

2. 资源消耗

DDS 的资源消耗相对较高，特别是在使用可靠性和持久性 QoS 时。这对于资源受限的环境可能不太适合。

3. 生态系统

虽然 DDS 在特定领域（如机器人、自动驾驶）有广泛应用，但相比一些更通用的消息中间件（如 MQTT），DDS 的生态系统相对较小。

4. 文档和社区

虽然主要的 DDS 实现都有文档和社区支持，但相比一些更成熟的技术，DDS 的文档和社区资源相对较少。

DDS 的未来发展

DDS 技术正在不断发展，未来的发展方向包括：

1. 性能优化

DDS 实现正在不断优化性能，包括减少延迟、提高吞吐量、降低资源消耗等。

2. 功能扩展

DDS 标准正在扩展新的功能，包括更好的安全支持、更多的 QoS 策略、更好的工具支持等。

3. 易用性改进

DDS 实现正在改进易用性，包括更简单的 API、更好的文档、更多的示例代码等。

4. 云原生支持

DDS 正在向云原生方向发展，支持容器化部署、微服务架构等。

5. 边缘计算

DDS 在边缘计算领域的应用正在增加，包括 IoT、工业 4.0 等。

学习资源推荐

官方文档

OMG DDS 标准：https://www.omg.org/spec/DDS/
Fast DDS 文档：https://fast-dds.docs.eprosima.com/
Cyclone DDS 文档：https://github.com/eclipse-cyclonedds/cyclonedds
RTI Connext DDS 文档：https://www.rti.com/products/connext-dds

教程和示例

Fast DDS 示例：https://github.com/eProsima/Fast-DDS/tree/main/examples
ROS2 DDS 教程：https://docs.ros.org/en/humble/Tutorials.html
DDS 最佳实践：各种 DDS 实现的文档和博客

社区和论坛

Fast DDS 论坛：https://github.com/eProsima/Fast-DDS/discussions
ROS2 社区：https://discourse.ros.org/
DDS 用户组：各种 DDS 实现的用户组和邮件列表

书籍

《Real-Time Systems Development with RTI Connext DDS》
《Data Distribution Service (DDS) - A Practical Approach》

结语

DDS 作为工业级的实时数据分发标准，在机器人、自动驾驶、航空航天等领域发挥着重要作用。通过本文的全面介绍，我们希望您能够深入理解 DDS 的核心概念、技术架构、QoS 策略和实际应用。

无论您是刚开始接触 DDS 的新手，还是希望深入了解 DDS 技术细节的资深开发者，DDS 都为您提供了一个强大、灵活、可靠的实时通信平台。通过合理使用 DDS 的 QoS 策略和最佳实践，您可以构建出高性能、高可靠性的分布式实时系统。

随着 DDS 技术的不断发展和完善，我们相信 DDS 将在更多领域得到应用，为分布式实时系统的发展做出更大的贡献。希望本文能够帮助您在 DDS 的学习和应用中取得成功。

引言

第一部分：DDS 基础概念

什么是 DDS

DDS 的历史发展

DDS 标准的开发始于 2001 年，OMG 于 2004 年发布了 DDS 1.0 版本。随后，DDS 标准经历了多次更新和完善：

DDS 1.0（2004 年）：首次发布，定义了核心的 DCPS（Data-Centric Publish-Subscribe）模型
DDS 1.1（2005 年 12 月）：增加了对 C++ 和 Java 的 API 支持
DDS 1.2（2007 年 1 月）：引入了更多的 QoS 策略和扩展功能
DDS 1.4（2015 4 月）：进一步完善了 QoS 策略和互操作性

DDS 标准主要由四个部分组成：

核心标准：定义了数据中心的发布-订阅（DCPS）模型，确保信息高效传递给正确的接收者
扩展标准：提供了额外的功能和服务，以满足特定应用需求
网关标准：确保不同 DDS 实现之间的互操作性，允许跨供应商的系统进行通信
API 标准：定义了应用程序接口，方便开发者集成和使用 DDS 服务

DDS 的定位

实时性要求高：需要低延迟、可预测的通信性能
可靠性要求高：需要保证数据不丢失、按顺序传输
可扩展性强：需要支持动态添加和移除节点
分布式系统：需要在多个节点之间进行数据交换

DDS 的应用领域

DDS 在多个领域得到了广泛应用：

航空航天：用于飞机系统、卫星通信、地面控制系统
自动驾驶：用于传感器数据分发、控制命令传输、多 ECU 通信
机器人：用于机器人控制、传感器融合、多机器人协作
国防：用于军事系统、指挥控制系统
医疗设备：用于医疗设备之间的数据交换
工业自动化：用于工业控制系统、SCADA 系统
能源管理：用于智能电网、能源监控系统

DDS 的核心设计理念

DDS 遵循几个核心设计理念，这些理念指导了其架构设计和功能实现：

1. 以数据为中心（Data-Centric）

2. 发布-订阅模式（Publish-Subscribe）

一对多通信：一个发布者可以向多个订阅者发送数据
动态发现：节点可以自动发现和连接
解耦设计：发布者和订阅者相互独立

3. 服务质量保证（Quality of Service）

DDS 提供了丰富的 QoS 策略，允许开发者根据应用需求精确控制通信行为。这些 QoS 策略包括：

可靠性（Reliability）：控制数据传输的可靠性
持久性（Durability）：控制数据的持久化级别
历史记录（History）：控制历史数据的保留策略
期限（Deadline）：控制数据发布的期限要求
延迟预算（LatencyBudget）：控制数据传输的延迟要求
存活性（Liveliness）：监控节点的活跃状态

4. 实时性优先（Real-Time First）

5. 标准化与互操作性

DDS 是一个开放的标准，确保了不同实现之间的互操作性。这意味着使用不同 DDS 实现的系统可以相互通信，提高了系统的灵活性和可移植性。

DDS 与相关技术的关系

理解 DDS，需要理解它与相关技术的关系和区别：

DDS vs ROS1

架构差异：ROS1 基于节点和话题的架构，使用 TCP/UDP 通信，依赖中央节点（roscore）；DDS 采用去中心化的发布-订阅架构，不需要中央节点
实时性：DDS 提供了更好的实时性保证，通过 QoS 策略可以精确控制通信行为；ROS1 的实时性相对较弱
可靠性：DDS 通过 QoS 策略提供了灵活的可靠性配置；ROS1 的可靠性主要依赖于 TCP 协议
适用场景：ROS1 适合复杂的机器人系统集成，有丰富的生态系统；DDS 适合对实时性和可靠性要求高的应用

DDS vs MQTT

通信模式：MQTT 采用客户端-服务器模式，需要消息代理（Broker）；DDS 采用去中心化的发布-订阅模式，不需要中央代理
实时性：DDS 提供了更好的实时性，延迟更低；MQTT 的延迟相对较高
QoS 支持：MQTT 提供了简单的 QoS 级别（0、1、2）；DDS 提供了更丰富的 QoS 策略
适用场景：MQTT 适合 IoT 应用，资源受限的环境；DDS 适合高性能的实时应用

DDS vs gRPC

通信模式：gRPC 采用客户端-服务器模式，基于 HTTP/2；DDS 采用发布-订阅模式
数据交换：gRPC 适合请求-响应交互；DDS 适合持续的数据流
实时性：DDS 提供了更好的实时性；gRPC 的实时性相对较弱
适用场景：gRPC 适合微服务架构、API 调用；DDS 适合实时数据分发

DDS 在 ROS2 中的作用

ROS2 将 DDS 作为其默认的通信中间件，这是 ROS2 相对于 ROS1 的重要改进之一。在 ROS2 中：

DDS 提供了底层的通信能力，实现了节点之间的数据交换
ROS2 的节点、话题、服务等概念都建立在 DDS 的基础上
ROS2 支持多种 DDS 实现，包括 Fast DDS、Cyclone DDS、RTI Connext DDS 等
DDS 的 QoS 策略可以通过 ROS2 的 QoS 配置进行设置

第二部分：DDS 技术架构

DCPS（Data-Centric Publish-Subscribe）是 DDS 的核心模型，定义了数据分发的抽象接口。理解 DCPS 模型是理解 DDS 的关键。

DCPS 的核心实体

DCPS 模型定义了以下核心实体：

域参与者（DomainParticipant）
- 域参与者是应用程序进入 DDS 域的入口点
- 每个应用程序必须创建一个域参与者才能使用 DDS
- 域参与者管理发布者、订阅者、主题等实体
- 域参与者属于特定的域（Domain），不同域的参与者不能直接通信
发布者（Publisher）
- 发布者负责创建和管理数据写入者（DataWriter）
- 一个域参与者可以创建多个发布者
- 发布者可以配置 QoS 策略，这些策略会应用到其创建的所有数据写入者
订阅者（Subscriber）
- 订阅者负责创建和管理数据读取者（DataReader）
- 一个域参与者可以创建多个订阅者
- 订阅者可以配置 QoS 策略，这些策略会应用到其创建的所有数据读取者
主题（Topic）
- 主题是发布者和订阅者之间的连接桥梁
- 主题定义了数据的类型和名称
- 发布者将数据发布到主题，订阅者订阅主题并接收数据
- 主题必须与数据类型关联，数据类型定义了数据的结构
数据写入者（DataWriter）
- 数据写入者负责将数据写入到主题
- 每个数据写入者关联一个主题
- 数据写入者可以配置 QoS 策略，控制数据的发布行为
数据读取者（DataReader）
- 数据读取者负责从主题读取数据
- 每个数据读取者关联一个主题
- 数据读取者可以配置 QoS 策略，控制数据的接收行为

DCPS 的数据流

DCPS 模型的数据流如下：

发布流程：
- 应用程序创建域参与者
- 创建发布者和数据写入者
- 注册数据类型
- 创建主题
- 将数据写入者关联到主题
- 应用程序调用 write() 方法发布数据
订阅流程：
- 应用程序创建域参与者
- 创建订阅者和数据读取者
- 注册数据类型
- 创建主题（或使用已存在的主题）
- 将数据读取者关联到主题
- 应用程序调用 read() 或 take() 方法接收数据
发现流程：
- DDS 自动发现机制会检测匹配的发布者和订阅者
- 当发布者和订阅者的主题名称和数据类型匹配时，它们会自动建立连接
- 发现过程是去中心化的，不需要中央节点

RTPS（Real-Time Publish-Subscribe Protocol）是 DDS 的有线互操作协议，定义了数据在网络上传输的格式和行为。RTPS 协议确保了不同 DDS 实现之间的互操作性。

RTPS 协议栈

RTPS 协议栈包括以下层次：

应用层：DDS API 和应用程序
RTPS 层：RTPS 协议实现，包括发现、数据传输、可靠性等
传输层：UDP/IP、TCP/IP 等网络协议
物理层：以太网、WiFi 等物理网络

RTPS 发现机制

RTPS 提供了去中心化的发现机制，使得节点可以自动发现和连接。发现机制包括两个阶段：

参与者发现（Participant Discovery）
- 使用 SPDP（Simple Participant Discovery Protocol）协议
- 每个域参与者定期发送 SPDP 消息，声明自己的存在
- SPDP 消息包含域参与者的唯一标识符、IP 地址、端口等信息
- 域参与者通过接收 SPDP 消息发现其他参与者
端点发现（Endpoint Discovery）
- 使用 SEDP（Simple Endpoint Discovery Protocol）协议
- 在参与者发现后，使用 SEDP 交换数据写入者和数据读取者的信息
- SEDP 消息包含主题名称、数据类型、QoS 策略等信息
- 当数据写入者和数据读取者匹配时，它们建立连接

RTPS 数据传输

RTPS 定义了数据传输的格式和流程：

数据包格式：RTPS 定义了标准的数据包格式，包括头部、子消息、数据负载等
可靠性传输：对于可靠 QoS，RTPS 使用确认和重传机制确保数据可靠传输
多播和单播：RTPS 支持多播和单播传输，可以根据需要选择最合适的传输方式
流控制：RTPS 提供了流控制机制，防止数据发送过快导致接收方溢出

DDS 域（Domain）与域参与者（DomainParticipant）

域（Domain）的概念

域 ID：每个域有一个唯一的域 ID（通常是一个整数），域 ID 范围是 0-230
域隔离：不同域的参与者完全隔离，即使它们在同一物理网络上
域内通信：只有属于同一域的参与者才能相互通信

域参与者（DomainParticipant）

域参与者是应用程序进入 DDS 域的入口点，是 DDS 应用程序的基础实体。

域参与者的作用：

管理发布者、订阅者、主题等实体
注册数据类型
参与发现过程
配置域级别的 QoS 策略

创建域参与者：

#include <fastdds/dds/domain/DomainParticipantFactory.hpp>

using namespace eprosima::fastdds::dds;

// 创建域参与者，域 ID 为 0
DomainParticipant* participant =
    DomainParticipantFactory::get_instance()->create_participant(
        0,  // 域 ID
        PARTICIPANT_QOS_DEFAULT,  // QoS 策略
        nullptr  // 监听器
    );

多域通信

虽然不同域的参与者不能直接通信，但可以通过以下方式实现跨域通信：

网关（Gateway）：使用 DDS 网关在不同域之间转发数据
多域参与者：一个应用程序可以创建多个域参与者，分别属于不同的域
桥接服务：使用桥接服务在不同域之间建立连接

第三部分：QoS 服务质量策略

QoS 策略概述

QoS 的重要性

QoS 策略的重要性体现在：

性能优化：通过合理配置 QoS，可以优化系统的性能，减少延迟，提高吞吐量
可靠性保证：通过可靠性 QoS，可以确保关键数据不丢失
资源管理：通过资源限制 QoS，可以防止系统资源耗尽
实时性保证：通过延迟预算和期限 QoS，可以保证实时性要求

QoS 策略的分类

DDS 的 QoS 策略可以分为以下几类：

数据可用性 QoS：控制数据的可用性和持久性
数据传输 QoS：控制数据传输的方式和可靠性
资源 QoS：控制资源的分配和使用
时间 QoS：控制时间相关的行为和约束
所有权 QoS：控制数据的所有权和访问权限

QoS 策略的作用范围

QoS 策略可以在多个层次配置：

域参与者 QoS：影响域参与者的行为
发布者/订阅者 QoS：影响发布者/订阅者及其创建的所有数据写入者/数据读取者
主题 QoS：影响主题的行为
数据写入者/数据读取者 QoS：影响具体的数据写入者/数据读取者

QoS 策略的匹配

DDS 使用 QoS 策略匹配来决定发布者和订阅者是否可以建立连接。只有当发布者和订阅者的 QoS 策略兼容时，它们才能建立连接。QoS 策略的匹配规则：

请求 vs 提供：订阅者请求的 QoS 必须被发布者提供的 QoS 满足
兼容性检查：DDS 会自动检查 QoS 策略的兼容性
不匹配处理：如果 QoS 不匹配，连接将无法建立

可靠性策略（Reliability）

可靠性 QoS 策略控制数据传输的可靠性，决定数据是否保证被成功传输。

可靠性模式

DDS 提供了两种可靠性模式：

BEST_EFFORT（尽力而为）
- 不保证数据成功传输，可能会出现数据丢失
- 性能更好，延迟更低
- 适用于对数据完整性要求不高，但对实时性要求较高的场景
- 例如：传感器数据流、视频流、状态更新
RELIABLE（可靠）
- 保证数据成功传输，如果出现数据丢失，系统会进行重传
- 性能相对较低，延迟可能较高
- 适用于对数据完整性要求高的应用场景
- 例如：控制命令、配置信息、关键状态

可靠性配置

#include <fastdds/dds/publisher/DataWriter.hpp>
#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 创建数据写入者 QoS
DataWriterQos writer_qos;
writer_qos.reliability().kind = RELIABLE_RELIABILITY_QOS;

// 创建数据写入者
DataWriter* writer = publisher->create_datawriter(
    topic,
    writer_qos,
    nullptr
);

可靠性匹配规则

发布者和订阅者的可靠性 QoS 必须匹配
如果发布者使用 RELIABLE，订阅者必须使用 RELIABLE
如果发布者使用 BEST_EFFORT，订阅者可以使用 BEST_EFFORT 或 RELIABLE（但实际效果是 BEST_EFFORT）

持久性策略（Durability）

持久性 QoS 策略控制数据的持久化级别，决定新加入的订阅者是否能够接收到历史数据。

持久性模式

DDS 提供了四种持久性模式：

VOLATILE（易失）
- 数据仅在发布者和订阅者都在线时传输
- 新订阅者无法接收到发布者之前发送的历史数据
- 内存占用最少
- 适用于实时数据流，不需要历史数据
TRANSIENT_LOCAL（瞬态本地）
- 发布者在本地存储数据
- 新订阅者可以接收到发布者之前发送的历史数据（直到订阅者连接）
- 数据存储在内存中，进程退出后数据丢失
- 适用于需要最新状态数据的场景
TRANSIENT（瞬态）
- 数据存储在 DDS 服务中
- 新订阅者可以接收到所有历史数据
- 数据存储在内存中，服务重启后数据丢失
- 适用于需要完整历史数据的场景
PERSISTENT（持久）
- 数据持久化到磁盘
- 新订阅者可以接收到所有历史数据
- 即使服务重启，数据也不会丢失
- 适用于需要长期保存数据的场景

持久性配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 配置为瞬态本地持久性
DataWriterQos writer_qos;
writer_qos.durability().kind = TRANSIENT_LOCAL_DURABILITY_QOS;

// 配置历史记录深度（保留最新的 10 个样本）
writer_qos.history().kind = KEEP_LAST_HISTORY_QOS;
writer_qos.history().depth = 10;

持久性匹配规则

订阅者的持久性 QoS 必须大于或等于发布者的持久性 QoS
例如：如果发布者使用 VOLATILE，订阅者可以使用任何持久性级别
如果发布者使用 TRANSIENT_LOCAL，订阅者必须使用 TRANSIENT_LOCAL、TRANSIENT 或 PERSISTENT

历史记录策略（History）

历史记录 QoS 策略控制 DDS 缓存保留多少历史样本。

历史记录模式

DDS 提供了两种历史记录模式：

KEEP_LAST（保留最新的 N 个）
- 只保留最新的 N 个样本
- 需要配置深度（depth）参数
- 内存占用可控
- 适用于只需要最新数据的场景
KEEP_ALL（保留所有）
- 保留所有样本，直到资源限制
- 需要配置资源限制 QoS
- 内存占用可能很大
- 适用于需要完整历史数据的场景

历史记录配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 配置历史记录策略
DataWriterQos writer_qos;

// 保留最新的 10 个样本
writer_qos.history().kind = KEEP_LAST_HISTORY_QOS;
writer_qos.history().depth = 10;

// 或者保留所有样本
writer_qos.history().kind = KEEP_ALL_HISTORY_QOS;

历史记录与持久性的关系

历史记录策略控制缓存中保留多少样本
持久性策略控制新订阅者能否访问历史数据
两者结合使用可以实现不同的数据访问策略

期限策略（Deadline）

期限 QoS 策略规定发布者发布数据的周期，订阅者可以监控发布者是否按期发布数据。

期限的作用

实时性保证：确保数据按预期频率发布
故障检测：订阅者可以检测发布者是否正常工作
系统监控：可以监控系统的实时性性能

期限配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>
#include <fastrtps/utils/Time.hpp>

using namespace eprosima::fastdds::dds;
using namespace eprosima::fastrtps;

// 配置期限为 100 毫秒
DataWriterQos writer_qos;
writer_qos.deadline().period.seconds = 0;
writer_qos.deadline().period.nanosec = 100000000;  // 100ms

期限监控

订阅者可以监听期限违约事件：

#include <fastdds/dds/subscriber/DataReaderListener.hpp>

class MyListener : public DataReaderListener {
public:
    void on_requested_deadline_missed(
        DataReader* reader,
        const RequestedDeadlineMissedStatus& status) override {
        // 处理期限违约
        std::cout << "Deadline missed!" << std::endl;
    }
};

延迟预算策略（LatencyBudget）

延迟预算 QoS 策略提示数据传输的期望延迟，有助于中间件进行优化。

延迟预算的作用

性能优化：中间件可以根据延迟预算优化传输路径
资源分配：可以根据延迟要求分配资源
系统设计：帮助开发者理解系统的延迟要求

延迟预算配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 配置延迟预算为 50 毫秒
DataWriterQos writer_qos;
writer_qos.latency_budget().duration.seconds = 0;
writer_qos.latency_budget().duration.nanosec = 50000000;  // 50ms

存活性策略（Liveliness）

存活性 QoS 策略用于监测发布者或订阅者的活跃状态，确保通信双方的存活性。

存活性模式

DDS 提供了三种存活性模式：

AUTOMATIC（自动）
- 由 DDS 中间件自动管理
- 当数据写入者写入数据或数据读取者读取数据时，自动更新存活性
- 适用于大多数场景
MANUAL_BY_PARTICIPANT（按参与者手动）
- 由域参与者手动声明存活性
- 所有属于该参与者的数据写入者/数据读取者共享存活性
- 适用于需要统一管理存活性的场景
MANUAL_BY_TOPIC（按主题手动）
- 由数据写入者/数据读取者手动声明存活性
- 每个数据写入者/数据读取者独立管理存活性
- 适用于需要精细控制存活性的场景

存活性配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 配置存活性策略
DataWriterQos writer_qos;
writer_qos.liveliness().kind = AUTOMATIC_LIVELINESS_QOS;
writer_qos.liveliness().lease_duration.seconds = 5;  // 5 秒租约

存活性监控

订阅者可以监听存活性变化事件：

#include <fastdds/dds/subscriber/DataReaderListener.hpp>

class MyListener : public DataReaderListener {
public:
    void on_liveliness_changed(
        DataReader* reader,
        const LivelinessChangedStatus& status) override {
        // 处理存活性变化
        std::cout << "Liveliness changed!" << std::endl;
    }
};

其他 QoS 策略

除了上述 QoS 策略，DDS 还提供了其他重要的 QoS 策略：

资源限制（ResourceLimits）

控制资源的分配和使用：

DataWriterQos writer_qos;
writer_qos.resource_limits().max_samples = 1000;
writer_qos.resource_limits().max_instances = 10;
writer_qos.resource_limits().max_samples_per_instance = 100;

所有权（Ownership）

控制数据的所有权：

DataWriterQos writer_qos;
writer_qos.ownership().kind = EXCLUSIVE_OWNERSHIP_QOS;
writer_qos.ownership_strength().value = 10;

时间过滤（TimeBasedFilter）

根据时间过滤数据：

DataReaderQos reader_qos;
reader_qos.time_based_filter().minimum_separation.seconds = 1;
reader_qos.time_based_filter().minimum_separation.nanosec = 0;

第四部分：DDS 在机器人领域的应用

DDS 在 ROS2 中的应用

ROS2（Robot Operating System 2）将 DDS 作为其默认的通信中间件，这是 ROS2 相对于 ROS1 的重要改进之一。

ROS2 的 DDS 中间件

ROS2 支持多种 DDS 实现，开发者可以根据需求选择合适的实现：

Fast DDS（eProsima）
- ROS2 的默认 DDS 实现
- 开源、高性能
- 支持 C++ 和 Python
- 适合大多数应用场景
Cyclone DDS（Eclipse）
- 轻量级、高性能
- 完全符合 DDS 标准
- 适合资源受限的环境
RTI Connext DDS
- 商业实现，功能最完整
- 提供丰富的工具和文档
- 适合商业应用
OpenSplice DDS
- 另一个商业实现
- 提供高性能和可靠性

ROS2 与 DDS 的集成

在 ROS2 中，DDS 提供了底层的通信能力：

节点通信：ROS2 节点通过 DDS 进行通信
话题通信：ROS2 话题对应 DDS 主题
服务通信：ROS2 服务使用 DDS 的请求-响应模式
QoS 配置：ROS2 的 QoS 配置直接映射到 DDS 的 QoS 策略

ROS2 QoS 配置示例

#include <rclcpp/rclcpp.hpp>
#include <std_msgs/msg/string.hpp>

using namespace std::chrono_literals;

class PublisherNode : public rclcpp::Node {
public:
    PublisherNode() : Node("publisher_node") {
        // 配置 QoS
        rclcpp::QoS qos(10);
        qos.reliability(RMW_QOS_POLICY_RELIABILITY_RELIABLE);
        qos.durability(RMW_QOS_POLICY_DURABILITY_TRANSIENT_LOCAL);

        // 创建发布者
        publisher_ = this->create_publisher<std_msgs::msg::String>(
            "topic", qos);

        // 定时发布
        timer_ = this->create_wall_timer(
            500ms, std::bind(&PublisherNode::timer_callback, this));
    }

private:
    void timer_callback() {
        auto message = std_msgs::msg::String();
        message.data = "Hello, ROS2!";
        publisher_->publish(message);
    }

    rclcpp::Publisher<std_msgs::msg::String>::SharedPtr publisher_;
    rclcpp::TimerBase::SharedPtr timer_;
};

ROS2 DDS 的优势

去中心化：不需要中央节点（roscore），提高了系统的可靠性
实时性：DDS 提供了更好的实时性保证
可靠性：通过 QoS 策略可以精确控制通信行为
互操作性：不同 DDS 实现之间可以互操作

DDS 在 Unitree SDK2 中的应用

Unitree SDK2 采用 DDS 作为其通信基础，为机器人控制提供了低延迟、高可靠性的通信保障。

SDK2 的 DDS 通信架构

Unitree SDK2 使用 DDS 实现以下通信模式：

发布-订阅模式：用于实时数据交换，如传感器数据、控制命令等
客户端-服务器模式：用于处理高级服务请求，如配置管理、任务执行等

SDK2 的 DDS 实现

SDK2 基于 DDS 实现了分层的 API：

高级语义 API：提供面向任务的抽象接口
通信系统：基于 DDS 的实时通信架构
控制接口：提供对机器人硬件的直接访问能力

SDK2 DDS 通信示例

#include <unitree/robot/channel/channel_publisher.hpp>
#include <unitree/common/time/time_tool.hpp>

int main() {
    // 创建发布者
    unitree::robot::ChannelPublisher<MyDataType> publisher;
    publisher.Init("my_topic_name");

    // 准备数据
    MyDataType data;
    data.value = 123;
    data.timestamp = unitree::common::TimeTool::GetCurrentTime();

    // 发布数据
    publisher.Write(data);

    return 0;
}

SDK2 DDS 的优势

实时性：DDS 架构提供了优秀的实时性能
可靠性：QoS 机制保证了通信的可靠性
跨平台：支持 x86_64 和 aarch64 架构
易用性：高级 API 使得开发变得简单

DDS 在自动驾驶中的应用

在自动驾驶领域，DDS 被广泛应用于传感器数据分发、控制命令传输和多 ECU 通信。

传感器数据分发

自动驾驶系统需要处理来自多种传感器的数据：

视觉传感器：摄像头数据
激光雷达：点云数据
毫米波雷达：目标检测数据
GPS/IMU：定位和姿态数据

DDS 通过发布-订阅模式，使得这些传感器数据可以在不同的 ECU 之间高效分发。

控制命令传输

自动驾驶系统需要将控制命令传输到执行器：

转向控制：方向盘角度
制动控制：制动力
加速控制：油门开度

DDS 的可靠性 QoS 确保了这些关键控制命令的可靠传输。

多 ECU 通信

自动驾驶系统包含多个 ECU（Electronic Control Unit），DDS 提供了高效的跨 ECU 通信能力：

实时性：低延迟的通信保证了控制的实时性
可靠性：可靠的传输保证了系统的安全性
可扩展性：可以方便地添加新的 ECU

自动驾驶 DDS 应用案例

超过 200 个车型项目采用了 DDS，包括：

丰田（Toyota）
通用（General Motors）
大众（Volkswagen）
奥迪（Audi）
奔驰（Mercedes-Benz）

DDS 在其他机器人系统中的应用

工业机器人

在工业机器人系统中，DDS 用于：

机器人控制：控制命令的实时传输
传感器融合：多传感器数据的融合
安全监控：安全状态的实时监控

无人机系统

在无人机系统中，DDS 用于：

飞行控制：控制命令的传输
传感器数据：GPS、IMU、摄像头等传感器数据的分发
地面站通信：无人机与地面站的通信

多机器人协作

在多机器人协作系统中，DDS 用于：

任务协调：机器人之间的任务协调
状态共享：机器人状态的共享
冲突避免：机器人之间的冲突避免

第五部分：DDS 实践指南

DDS 实现选择

DDS 是一个标准，有多种实现可供选择。选择合适的实现对于项目的成功至关重要。

主要 DDS 实现对比

Fast DDS（eProsima）
- 许可证：Apache 2.0（开源）
- 语言支持：C++、Python
- 性能：高性能，适合大多数应用
- 社区：活跃的开源社区
- 适用场景：ROS2、机器人应用、研究项目
- 优势：开源、免费、性能好、文档完善
- 劣势：商业支持有限
Cyclone DDS（Eclipse）
- 许可证：Eclipse Public License 2.0（开源）
- 语言支持：C、C++
- 性能：轻量级、高性能
- 社区：Eclipse 基金会支持
- 适用场景：资源受限的环境、嵌入式系统
- 优势：轻量级、完全符合标准、性能好
- 劣势：功能相对较少
RTI Connext DDS
- 许可证：商业许可证
- 语言支持：C、C++、Java、C#、Python 等
- 性能：高性能、功能完整
- 社区：商业支持
- 适用场景：商业应用、关键系统
- 优势：功能最完整、工具丰富、商业支持
- 劣势：需要商业许可证
OpenSplice DDS
- 许可证：商业许可证
- 语言支持：C、C++、Java
- 性能：高性能
- 社区：商业支持
- 适用场景：商业应用
- 优势：高性能、可靠性高
- 劣势：需要商业许可证

选择建议

开源项目：推荐 Fast DDS 或 Cyclone DDS
商业项目：可以考虑 RTI Connext DDS
资源受限：推荐 Cyclone DDS
ROS2 应用：推荐 Fast DDS（ROS2 默认）

Fast DDS 安装与配置

系统要求

操作系统：Linux（Ubuntu 20.04+ 推荐）、Windows、macOS
编译器：GCC 7+、Clang 5+、MSVC 2017+
CMake：3.10+
依赖库：asio、tinyxml2、foonathan_memory 等

Ubuntu 安装

# 安装依赖
sudo apt update
sudo apt install -y \
    cmake \
    g++ \
    libasio-dev \
    libtinyxml2-dev \
    libssl-dev \
    libp11-kit-dev \
    libengine-pkcs11-openssl

# 从源码编译安装
git clone https://github.com/eProsima/Fast-DDS.git
cd Fast-DDS
mkdir build && cd build
cmake ..
make -j$(nproc)
sudo make install

ROS2 中的 Fast DDS

如果使用 ROS2，Fast DDS 通常已经包含在 ROS2 安装中：

# 安装 ROS2（包含 Fast DDS）
sudo apt install ros-humble-desktop

# 设置环境变量使用 Fast DDS
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp

配置文件

Fast DDS 使用 XML 配置文件进行配置：

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
    <participant profile_name="default">
        <rtps>
            <builtin>
                <discovery_config>
                    <discoveryProtocol>SIMPLE</discoveryProtocol>
                </discovery_config>
            </builtin>
        </rtps>
    </participant>
</profiles>

基础代码示例

C++ 发布者示例

#include <fastdds/dds/domain/DomainParticipantFactory.hpp>
#include <fastdds/dds/publisher/Publisher.hpp>
#include <fastdds/dds/publisher/DataWriter.hpp>
#include <fastdds/dds/topic/Topic.hpp>
#include <iostream>
#include <thread>
#include <chrono>

using namespace eprosima::fastdds::dds;

// 定义数据类型
struct HelloWorld {
    uint32_t index;
    std::string message;

    HelloWorld() : index(0) {}
    HelloWorld(uint32_t i, const std::string& msg)
        : index(i), message(msg) {}
};

int main() {
    // 创建域参与者
    DomainParticipant* participant =
        DomainParticipantFactory::get_instance()->create_participant(
            0, PARTICIPANT_QOS_DEFAULT);

    if (participant == nullptr) {
        std::cerr << "Failed to create participant" << std::endl;
        return 1;
    }

    // 注册数据类型（简化示例，实际需要使用 IDL 生成类型支持）
    // TypeSupport type(new HelloWorldPubSubType());
    // type.register_type(participant);

    // 创建发布者
    Publisher* publisher = participant->create_publisher(
        PUBLISHER_QOS_DEFAULT, nullptr);

    if (publisher == nullptr) {
        std::cerr << "Failed to create publisher" << std::endl;
        return 1;
    }

    // 创建主题
    Topic* topic = participant->create_topic(
        "HelloWorldTopic",
        "HelloWorld",
        TOPIC_QOS_DEFAULT);

    if (topic == nullptr) {
        std::cerr << "Failed to create topic" << std::endl;
        return 1;
    }

    // 创建数据写入者
    DataWriter* writer = publisher->create_datawriter(
        topic,
        DATAWRITER_QOS_DEFAULT,
        nullptr);

    if (writer == nullptr) {
        std::cerr << "Failed to create datawriter" << std::endl;
        return 1;
    }

    // 发布数据
    for (uint32_t i = 0; i < 10; ++i) {
        HelloWorld msg(i, "Hello, DDS!");

        // 写入数据（实际需要使用类型支持）
        // writer->write(&msg);

        std::cout << "Published: index=" << msg.index
                  << ", message=" << msg.message << std::endl;

        std::this_thread::sleep_for(std::chrono::milliseconds(500));
    }

    // 清理资源
    publisher->delete_datawriter(writer);
    participant->delete_publisher(publisher);
    participant->delete_topic(topic);
    DomainParticipantFactory::get_instance()->delete_participant(participant);

    return 0;
}

C++ 订阅者示例

#include <fastdds/dds/domain/DomainParticipantFactory.hpp>
#include <fastdds/dds/subscriber/Subscriber.hpp>
#include <fastdds/dds/subscriber/DataReader.hpp>
#include <fastdds/dds/topic/Topic.hpp>
#include <iostream>
#include <thread>
#include <chrono>

using namespace eprosima::fastdds::dds;

// 定义数据类型（与发布者相同）
struct HelloWorld {
    uint32_t index;
    std::string message;
};

int main() {
    // 创建域参与者
    DomainParticipant* participant =
        DomainParticipantFactory::get_instance()->create_participant(
            0, PARTICIPANT_QOS_DEFAULT);

    // 创建订阅者
    Subscriber* subscriber = participant->create_subscriber(
        SUBSCRIBER_QOS_DEFAULT, nullptr);

    // 创建主题
    Topic* topic = participant->create_topic(
        "HelloWorldTopic",
        "HelloWorld",
        TOPIC_QOS_DEFAULT);

    // 创建数据读取者
    DataReader* reader = subscriber->create_datareader(
        topic,
        DATAREADER_QOS_DEFAULT,
        nullptr);

    // 读取数据
    for (int i = 0; i < 10; ++i) {
        // 实际需要使用类型支持读取数据
        // HelloWorld msg;
        // if (reader->take_next_sample(&msg, &info) == ReturnCode_t::RETCODE_OK) {
        //     std::cout << "Received: index=" << msg.index
        //               << ", message=" << msg.message << std::endl;
        // }

        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }

    // 清理资源
    subscriber->delete_datareader(reader);
    participant->delete_subscriber(subscriber);
    participant->delete_topic(topic);
    DomainParticipantFactory::get_instance()->delete_participant(participant);

    return 0;
}

Python 示例

import fastdds
import time

# 创建域参与者
factory = fastdds.DomainParticipantFactory.get_instance()
participant = factory.create_participant(0, fastdds.PARTICIPANT_QOS_DEFAULT)

# 创建发布者
publisher = participant.create_publisher(fastdds.PUBLISHER_QOS_DEFAULT)

# 创建主题
topic = participant.create_topic(
    "HelloWorldTopic",
    "HelloWorld",
    fastdds.TOPIC_QOS_DEFAULT)

# 创建数据写入者
writer = publisher.create_datawriter(topic, fastdds.DATAWRITER_QOS_DEFAULT)

# 发布数据
for i in range(10):
    # 实际需要使用 IDL 生成的数据类型
    # msg = HelloWorld()
    # msg.index = i
    # msg.message = "Hello, DDS!"
    # writer.write(msg)

    print(f"Published: index={i}")
    time.sleep(0.5)

# 清理资源
publisher.delete_datawriter(writer)
participant.delete_publisher(publisher)
participant.delete_topic(topic)
factory.delete_participant(participant)

高级应用示例

自定义 QoS 配置

#include <fastdds/dds/publisher/qos/DataWriterQos.hpp>

using namespace eprosima::fastdds::dds;

// 创建自定义 QoS
DataWriterQos writer_qos;

// 配置可靠性
writer_qos.reliability().kind = RELIABLE_RELIABILITY_QOS;

// 配置持久性
writer_qos.durability().kind = TRANSIENT_LOCAL_DURABILITY_QOS;

// 配置历史记录
writer_qos.history().kind = KEEP_LAST_HISTORY_QOS;
writer_qos.history().depth = 10;

// 配置期限
writer_qos.deadline().period.seconds = 0;
writer_qos.deadline().period.nanosec = 100000000;  // 100ms

// 使用自定义 QoS 创建数据写入者
DataWriter* writer = publisher->create_datawriter(
    topic,
    writer_qos,
    nullptr);

多主题通信

// 创建多个主题
Topic* topic1 = participant->create_topic("Topic1", "Type1", TOPIC_QOS_DEFAULT);
Topic* topic2 = participant->create_topic("Topic2", "Type2", TOPIC_QOS_DEFAULT);

// 为每个主题创建数据写入者
DataWriter* writer1 = publisher->create_datawriter(topic1, DATAWRITER_QOS_DEFAULT, nullptr);
DataWriter* writer2 = publisher->create_datawriter(topic2, DATAWRITER_QOS_DEFAULT, nullptr);

// 发布到不同主题
// writer1->write(&data1);
// writer2->write(&data2);

错误处理

#include <fastdds/dds/core/status/StatusMask.hpp>

// 创建监听器处理错误
class MyListener : public DataWriterListener {
public:
    void on_offered_deadline_missed(
        DataWriter* writer,
        const OfferedDeadlineMissedStatus& status) override {
        std::cerr << "Deadline missed!" << std::endl;
    }

    void on_offered_incompatible_qos(
        DataWriter* writer,
        const OfferedIncompatibleQosStatus& status) override {
        std::cerr << "Incompatible QoS!" << std::endl;
    }
};

// 使用监听器
MyListener listener;
DataWriter* writer = publisher->create_datawriter(
    topic,
    DATAWRITER_QOS_DEFAULT,
    &listener);

第六部分：DDS 与其他通信方案对比

DDS vs ROS1

架构对比

特性	ROS1	DDS
通信模式	节点-话题	发布-订阅
中央节点	需要 roscore	不需要
发现机制	中央注册	去中心化自动发现
实时性	中等	高
可靠性	TCP/UDP	可配置 QoS
跨语言	有限	广泛支持

性能对比

延迟：DDS 通常具有更低的延迟，特别是在高负载情况下
吞吐量：DDS 的吞吐量通常更高
可扩展性：DDS 的去中心化架构提供了更好的可扩展性

适用场景

ROS1：适合复杂的机器人系统集成，有丰富的生态系统和工具
DDS：适合对实时性和可靠性要求高的应用，如机器人控制、自动驾驶

互操作性

ROS2 基于 DDS，可以通过桥接节点实现 ROS1 和 ROS2 之间的通信。

DDS vs MQTT

协议对比

特性	MQTT	DDS
通信模式	客户端-服务器	发布-订阅（去中心化）
消息代理	需要 Broker	不需要
QoS 级别	3 个简单级别	丰富的 QoS 策略
实时性	中等	高
资源消耗	低	中等
适用场景	IoT、轻量级应用	高性能实时应用

QoS 对比

MQTT：提供 3 个简单的 QoS 级别（0、1、2）
DDS：提供丰富的 QoS 策略，可以精确控制通信行为

适用场景

MQTT：适合 IoT 应用、资源受限的环境、需要消息代理的场景
DDS：适合高性能的实时应用、不需要消息代理的场景、对 QoS 要求高的应用

DDS vs gRPC

通信模式对比

特性	gRPC	DDS
通信模式	客户端-服务器	发布-订阅
数据交换	请求-响应	持续数据流
协议	HTTP/2	RTPS
实时性	中等	高
适用场景	微服务、API 调用	实时数据分发

性能对比

延迟：DDS 通常具有更低的延迟
吞吐量：对于持续数据流，DDS 的吞吐量通常更高
资源消耗：gRPC 的资源消耗相对较低

适用场景

gRPC：适合微服务架构、API 调用、请求-响应交互
DDS：适合实时数据分发、传感器数据流、控制命令传输

DDS vs ZeroMQ

消息模式对比

特性	ZeroMQ	DDS
消息模式	多种模式	发布-订阅
发现机制	手动配置	自动发现
QoS 支持	有限	丰富
标准化	非标准	OMG 标准
适用场景	通用消息传递	实时数据分发

性能对比

延迟：两者都具有低延迟
吞吐量：DDS 的吞吐量通常更高
易用性：ZeroMQ 的 API 更简单

适用场景

ZeroMQ：适合通用消息传递、简单的发布-订阅场景
DDS：适合需要丰富 QoS 策略、标准化、互操作性的场景

第七部分：DDS 最佳实践

QoS 策略选择指南

不同应用场景的 QoS 配置

实时传感器数据流

DataWriterQos qos;
qos.reliability().kind = BEST_EFFORT_RELIABILITY_QOS;
qos.durability().kind = VOLATILE_DURABILITY_QOS;
qos.history().kind = KEEP_LAST_HISTORY_QOS;
qos.history().depth = 1;

控制命令

DataWriterQos qos;
qos.reliability().kind = RELIABLE_RELIABILITY_QOS;
qos.durability().kind = TRANSIENT_LOCAL_DURABILITY_QOS;
qos.history().kind = KEEP_LAST_HISTORY_QOS;
qos.history().depth = 10;

状态信息

DataWriterQos qos;
qos.reliability().kind = RELIABLE_RELIABILITY_QOS;
qos.durability().kind = TRANSIENT_LOCAL_DURABILITY_QOS;
qos.history().kind = KEEP_LAST_HISTORY_QOS;
qos.history().depth = 1;

配置数据

DataWriterQos qos;
qos.reliability().kind = RELIABLE_RELIABILITY_QOS;
qos.durability().kind = PERSISTENT_DURABILITY_QOS;
qos.history().kind = KEEP_ALL_HISTORY_QOS;

QoS 匹配原则

订阅者的 QoS 必须满足发布者的 QoS 要求
可靠性：如果发布者使用 RELIABLE，订阅者必须使用 RELIABLE
持久性：订阅者的持久性级别必须大于或等于发布者
其他 QoS：根据具体策略的匹配规则

性能优化技巧

减少延迟

使用 BEST_EFFORT 可靠性：对于不需要可靠传输的数据
减少历史记录深度：只保留必要的历史数据
优化网络配置：使用低延迟网络，减少网络跳数
使用共享内存传输：对于同一机器上的通信

提高吞吐量

批量写入：一次写入多个样本
减少 QoS 检查：使用简单的 QoS 配置
优化数据类型：使用紧凑的数据结构
使用多播：对于一对多通信

资源管理

限制历史记录：使用 KEEP_LAST 而不是 KEEP_ALL
设置资源限制：防止资源耗尽
及时清理：删除不再使用的实体
监控资源使用：定期检查资源使用情况

调试与故障排除

常见问题

连接失败
- 检查域 ID 是否匹配
- 检查主题名称和数据类型是否匹配
- 检查 QoS 策略是否兼容
- 检查网络连接
数据丢失
- 检查可靠性 QoS 配置
- 检查历史记录深度
- 检查资源限制
延迟过高
- 检查网络延迟
- 检查 QoS 配置
- 检查系统负载

调试工具

Fast DDS 工具：fastdds discovery、fastdds shm 等
Wireshark：网络包分析工具
日志：启用 DDS 日志输出
性能分析工具：使用性能分析工具分析瓶颈

性能分析

// 启用统计信息
DataWriterQos qos;
qos.publish_mode().kind = ASYNCHRONOUS_PUBLISH_MODE;
qos.writer_data_lifecycle().autodispose_unregistered_instances = false;

// 获取统计信息
PublicationMatchedStatus status;
writer->get_publication_matched_status(status);
std::cout << "Matched subscribers: " << status.current_count << std::endl;

安全考虑

DDS 安全扩展

DDS 提供了安全扩展（DDS Security），包括：

身份认证：验证参与者的身份
访问控制：控制数据的访问权限
加密：加密数据传输
日志：记录安全事件

网络安全

使用 VPN：在公共网络上使用 VPN
防火墙配置：正确配置防火墙规则
网络隔离：将 DDS 流量隔离到专用网络

数据加密

// 配置加密（需要 DDS Security）
DataWriterQos qos;
// 配置安全属性
// qos.properties().properties().push_back(...);

第八部分：总结与展望

DDS 的优势总结

DDS 作为工业级的实时数据分发标准，具有以下主要优势：

1. 标准化

DDS 是 OMG 制定的开放标准，确保了不同实现之间的互操作性。这使得系统可以灵活地选择最适合的 DDS 实现，也可以在不同实现之间切换。

2. 高性能

DDS 通过优化的协议栈和 QoS 机制，提供了低延迟、高吞吐量的通信性能。这对于对实时性要求极高的应用（如机器人控制、自动驾驶）至关重要。

3. 丰富的 QoS 策略

DDS 提供了丰富的 QoS 策略，允许开发者根据应用需求精确控制通信行为。这些 QoS 策略包括可靠性、持久性、历史记录、期限、延迟预算、存活性等。

4. 去中心化架构

DDS 采用去中心化的发布-订阅架构，不需要中央节点。这种设计提高了系统的可靠性和可扩展性，也简化了系统的部署和维护。

5. 自动发现

DDS 提供了自动发现机制，节点可以自动发现和连接，不需要手动配置。这简化了分布式系统的构建和维护。

6. 跨平台支持

DDS 支持多种操作系统和编程语言，包括 Linux、Windows、macOS 和 C++、Java、Python、C# 等。

DDS 的局限性

尽管 DDS 具有许多优势，但也存在一些局限性：

1. 复杂性

DDS 的概念和 API 相对复杂，学习曲线较陡。特别是 QoS 策略的配置和理解需要一定的经验。

2. 资源消耗

DDS 的资源消耗相对较高，特别是在使用可靠性和持久性 QoS 时。这对于资源受限的环境可能不太适合。

3. 生态系统

虽然 DDS 在特定领域（如机器人、自动驾驶）有广泛应用，但相比一些更通用的消息中间件（如 MQTT），DDS 的生态系统相对较小。

4. 文档和社区

虽然主要的 DDS 实现都有文档和社区支持，但相比一些更成熟的技术，DDS 的文档和社区资源相对较少。

DDS 的未来发展

DDS 技术正在不断发展，未来的发展方向包括：

1. 性能优化

DDS 实现正在不断优化性能，包括减少延迟、提高吞吐量、降低资源消耗等。

2. 功能扩展

DDS 标准正在扩展新的功能，包括更好的安全支持、更多的 QoS 策略、更好的工具支持等。

3. 易用性改进

DDS 实现正在改进易用性，包括更简单的 API、更好的文档、更多的示例代码等。

4. 云原生支持

DDS 正在向云原生方向发展，支持容器化部署、微服务架构等。

5. 边缘计算

DDS 在边缘计算领域的应用正在增加，包括 IoT、工业 4.0 等。

学习资源推荐

官方文档

OMG DDS 标准：https://www.omg.org/spec/DDS/
Fast DDS 文档：https://fast-dds.docs.eprosima.com/
Cyclone DDS 文档：https://github.com/eclipse-cyclonedds/cyclonedds
RTI Connext DDS 文档：https://www.rti.com/products/connext-dds

教程和示例

Fast DDS 示例：https://github.com/eProsima/Fast-DDS/tree/main/examples
ROS2 DDS 教程：https://docs.ros.org/en/humble/Tutorials.html
DDS 最佳实践：各种 DDS 实现的文档和博客

社区和论坛

Fast DDS 论坛：https://github.com/eProsima/Fast-DDS/discussions
ROS2 社区：https://discourse.ros.org/
DDS 用户组：各种 DDS 实现的用户组和邮件列表

书籍

《Real-Time Systems Development with RTI Connext DDS》
《Data Distribution Service (DDS) - A Practical Approach》

文章

GMR：通用动作重映射器

使用 Dotfile 同步配置

编码器正交编码方法

多摩川编码器协议

具身智能面试题（20题）

Pinocchio机器人库详解

TWIST算法深度研究：从图像重建到机器人路径规划

TWIST2算法：二阶滑模控制的革命性进展

TWIST算法技术补充：数学推导与实现细节

Pi0深度解析：Physical Intelligence的机器人基础模型

Pi0.5深度解析：开放式世界泛化的VLA模型

Pi0.6深度解析：体验学习与知识隔离的前沿VLA模型

Diffusion Policy深度解析：基于扩散模型的机器人动作生成策略

cuBLAS深度解析：GPU加速的线性代数库

深入理解CUDA：统一计算设备架构

引言

第一部分：DDS 基础概念

什么是 DDS

DDS 的核心设计理念

DDS 与相关技术的关系

第二部分：DDS 技术架构

DCPS 模型（Data-Centric Publish-Subscribe）

RTPS 协议（Real-Time Publish-Subscribe）

DDS 域（Domain）与域参与者（DomainParticipant）

第三部分：QoS 服务质量策略

QoS 策略概述

可靠性策略（Reliability）

持久性策略（Durability）

历史记录策略（History）

期限策略（Deadline）

延迟预算策略（LatencyBudget）

存活性策略（Liveliness）

其他 QoS 策略

第四部分：DDS 在机器人领域的应用

DDS 在 ROS2 中的应用

DDS 在 Unitree SDK2 中的应用

DDS 在自动驾驶中的应用

DDS 在其他机器人系统中的应用

第五部分：DDS 实践指南

DDS 实现选择

Fast DDS 安装与配置

基础代码示例

高级应用示例

第六部分：DDS 与其他通信方案对比

DDS vs ROS1

DDS vs MQTT

DDS vs gRPC

DDS vs ZeroMQ

第七部分：DDS 最佳实践

QoS 策略选择指南

性能优化技巧

调试与故障排除

安全考虑

第八部分：总结与展望

DDS 的优势总结

DDS 的局限性

DDS 的未来发展

学习资源推荐

结语

发表评论

评论 (0)

文章

GMR：通用动作重映射器

使用 Dotfile 同步配置

编码器正交编码方法

多摩川编码器协议

具身智能面试题（20题）

Pinocchio机器人库详解

TWIST算法深度研究：从图像重建到机器人路径规划

TWIST2算法：二阶滑模控制的革命性进展

TWIST算法技术补充：数学推导与实现细节

Pi0深度解析：Physical Intelligence的机器人基础模型

Pi0.5深度解析：开放式世界泛化的VLA模型

Pi0.6深度解析：体验学习与知识隔离的前沿VLA模型

Diffusion Policy深度解析：基于扩散模型的机器人动作生成策略

cuBLAS深度解析：GPU加速的线性代数库

深入理解CUDA：统一计算设备架构

引言

第一部分：DDS 基础概念