1. Fast DDS 是什么能解决什么问题第一次接触 Fast DDS 是在开发自动驾驶系统时遇到的通信瓶颈问题。当时我们的激光雷达、摄像头和控制系统之间需要实时传输大量数据传统的 TCP/IP 协议栈根本扛不住这种高频率、低延迟的需求。直到团队里的资深工程师推荐了 Fast DDS才真正解决了这个痛点。Fast DDS 是 eProsima 公司基于 DDSData Distribution Service标准实现的开源中间件专门为需要实时数据分发的场景设计。它最核心的优势在于采用了发布/订阅模型不同于传统的客户端/服务器模式这种架构让数据生产者Publisher和消费者Subscriber完全解耦双方不需要知道对方的存在只需要关注共同的数据主题Topic。举个实际例子在机器人系统中导航模块发布当前位置主题而路径规划和控制模块订阅这个主题。当导航模块更新位置数据时所有订阅者会自动收到更新完全不需要写复杂的网络通信代码。这种设计让系统扩展变得特别简单——新增一个需要位置数据的模块只需要让它订阅对应主题就行。2. Fast DDS 核心机制解析2.1 发现协议设备如何自动找到彼此Fast DDS 最让我惊艳的功能之一就是它的自动发现机制。还记得第一次部署多机通信时我按照传统思路准备了一堆 IP 配置文档结果发现 Fast DDS 根本不需要手动指定地址——设备接入网络后会自动发现彼此就像蓝牙设备配对一样简单。这背后的魔法是 RTPS 标准定义的发现协议包含两个关键部分SPDPSimple Participant Discovery Protocol相当于设备的打招呼阶段。每个 DomainParticipant 启动后会定期广播自己的存在同时监听其他参与者的消息。这个过程使用 UDP 多播默认端口 7400。SEDPSimple Endpoint Discovery Protocol在参与者建立连接后会进一步交换各自的 DataWriter 和 DataReader 信息。这时会根据 QoS 策略进行匹配只有兼容的发布者和订阅者才会建立最终的数据通道。实际调试时可以用 Wireshark 抓包观察这个过程。我常使用这个过滤条件udp.port 7400 || udp.port 74102.2 QoS 策略精细控制数据传输行为QoSQuality of Service是 Fast DDS 的精髓所在也是它区别于普通消息队列的关键。通过组合不同的 QoS 策略你可以精确控制数据的传输行为。分享几个我在项目中常用的配置可靠性 vs 性能的权衡// 可靠传输配置适合关键指令 ReliabilityQosPolicy reliability; reliability.kind RELIABLE_RELIABILITY_QOS; // 最大性能配置适合高频传感器数据 ReliabilityQosPolicy best_effort; best_effort.kind BEST_EFFORT_RELIABILITY_QOS;历史深度控制// 只保留最新数据默认 HistoryQosPolicy history; history.kind KEEP_LAST_HISTORY_QOS; history.depth 1; // 保留所有历史数据适合调试 HistoryQosPolicy keep_all; keep_all.kind KEEP_ALL_HISTORY_QOS;实时性保障// 设置截止时间超过时限的数据自动丢弃 DeadlineQosPolicy deadline; deadline.period.seconds 0; deadline.period.nanosec 100000000; // 100ms在车载系统中我们会为刹车指令配置 RELIABLE TRANSIENT_LOCAL 的 QoS确保关键指令绝不丢失而为摄像头数据配置 BEST_EFFORT VOLATILE优先保证传输效率。2.3 序列化机制数据如何变成比特流Fast DDS 使用 CDRCommon Data Representation格式进行序列化这是 DDS 标准的一部分。第一次看到生成的序列化代码时我被它的效率震惊了——完全没有使用反射或运行时类型信息全是硬编码的位操作。以这个简单的 IDL 定义为例struct SensorData { unsigned long timestamp; double value; string name; };Fast DDS 生成的序列化代码大致是这样的void SensorData::serialize(eprosima::fastcdr::Cdr scdr) const { scdr m_timestamp; scdr m_value; scdr m_name.c_str(); }实测下来这种方式的序列化速度比 Protobuf 快 3-5 倍特别适合高频传感器数据。但要注意字符串处理——CDR 对字符串有特殊格式要求建议预分配足够空间避免反复内存分配。3. 实战机器人通信系统搭建3.1 环境准备与安装推荐使用 Ubuntu 20.04/22.04 系统安装 Fast DDS 最方便的方式是 aptsudo apt install ros-distro-fastrtps如果是非 ROS 环境可以编译安装git clone --recursive https://github.com/eProsima/Fast-DDS.git mkdir Fast-DDS/build cd Fast-DDS/build cmake -DTHIRDPARTYON -DBUILD_SHARED_LIBSON .. make -j$(nproc) sudo make install安装后验证fastdds --version3.2 开发流程详解以一个实际的机器人导航系统为例展示完整开发流程定义数据结构nav_msgs.idlmodule nav_msgs { struct Pose { double x; double y; double theta; }; struct Path { sequencePose poses; }; };生成代码fastddsgen -replace nav_msgs.idl发布者实现关键代码// 创建 Participant DomainParticipant* participant DomainParticipantFactory::get_instance()-create_participant(0); // 注册类型 TypeSupport type(new PosePubSubType()); type.register_type(participant); // 创建 Publisher Publisher* publisher participant-create_publisher(PUBLISHER_QOS_DEFAULT); // 创建 Topic Topic* topic participant-create_topic(robot_pose, nav_msgs::Pose); // 创建 DataWriter DataWriter* writer publisher-create_datawriter(topic); // 发布数据 Pose pose; pose.x(1.0); pose.y(2.0); pose.theta(0.5); writer-write(pose);订阅者实现关键代码class PoseListener : public DataReaderListener { public: void on_data_available(DataReader* reader) override { Pose pose; SampleInfo info; if (reader-take_next_sample(pose, info) ReturnCode_t::RETCODE_OK) { std::cout Received pose: ( pose.x() , pose.y() ) std::endl; } } }; // 创建 Subscriber 和 DataReader 时指定监听器 PoseListener listener; DataReader* reader subscriber-create_datareader(topic, DATAREADER_QOS_DEFAULT, listener);3.3 性能优化技巧在真实项目中我总结了这些优化经验零拷贝配置DataWriterQos writer_qos; writer_qos.endpoint().history_memory_policy PREALLOCATED_WITH_REALLOC_MEMORY_MODE;共享内存传输同机通信participant profile_nameshm_transport rtps useBuiltinTransportsfalse/useBuiltinTransports transports transport_idshm/transport_id /transports /rtps /participant流量控制FlowControllerQos flow_controller; flow_controller.max_bytes_per_period 1024 * 1024; // 1MB/s flow_controller.period 1000; // 1s4. 典型问题排查指南4.1 发现失败常见原因防火墙阻止多播确保 UDP 7400-7410 端口开放Domain ID 不匹配检查所有节点是否使用相同 Domain ID网络接口配置错误特别是多网卡环境4.2 数据丢失分析遇到数据丢失时按这个顺序检查QoS 兼容性发布者和订阅者必须兼容历史深度设置资源限制检查内存和带宽网络状况使用 ping 和 iperf 测试4.3 性能问题定位我的性能分析工具箱fastddsmonitor实时监控通信状态Wireshark分析网络层行为perf定位 CPU 热点valgrind检查内存问题记得有次遇到莫名其妙的延迟最后发现是 QoS 配置了 TRANSIENT_LOCAL 但没设置足够的历史深度导致系统不断尝试存储过期数据。
Fast DDS 核心机制与实战解析，一篇讲透
发布时间：2026/5/18 17:18:25
1. Fast DDS 是什么能解决什么问题第一次接触 Fast DDS 是在开发自动驾驶系统时遇到的通信瓶颈问题。当时我们的激光雷达、摄像头和控制系统之间需要实时传输大量数据传统的 TCP/IP 协议栈根本扛不住这种高频率、低延迟的需求。直到团队里的资深工程师推荐了 Fast DDS才真正解决了这个痛点。Fast DDS 是 eProsima 公司基于 DDSData Distribution Service标准实现的开源中间件专门为需要实时数据分发的场景设计。它最核心的优势在于采用了发布/订阅模型不同于传统的客户端/服务器模式这种架构让数据生产者Publisher和消费者Subscriber完全解耦双方不需要知道对方的存在只需要关注共同的数据主题Topic。举个实际例子在机器人系统中导航模块发布当前位置主题而路径规划和控制模块订阅这个主题。当导航模块更新位置数据时所有订阅者会自动收到更新完全不需要写复杂的网络通信代码。这种设计让系统扩展变得特别简单——新增一个需要位置数据的模块只需要让它订阅对应主题就行。2. Fast DDS 核心机制解析2.1 发现协议设备如何自动找到彼此Fast DDS 最让我惊艳的功能之一就是它的自动发现机制。还记得第一次部署多机通信时我按照传统思路准备了一堆 IP 配置文档结果发现 Fast DDS 根本不需要手动指定地址——设备接入网络后会自动发现彼此就像蓝牙设备配对一样简单。这背后的魔法是 RTPS 标准定义的发现协议包含两个关键部分SPDPSimple Participant Discovery Protocol相当于设备的打招呼阶段。每个 DomainParticipant 启动后会定期广播自己的存在同时监听其他参与者的消息。这个过程使用 UDP 多播默认端口 7400。SEDPSimple Endpoint Discovery Protocol在参与者建立连接后会进一步交换各自的 DataWriter 和 DataReader 信息。这时会根据 QoS 策略进行匹配只有兼容的发布者和订阅者才会建立最终的数据通道。实际调试时可以用 Wireshark 抓包观察这个过程。我常使用这个过滤条件udp.port 7400 || udp.port 74102.2 QoS 策略精细控制数据传输行为QoSQuality of Service是 Fast DDS 的精髓所在也是它区别于普通消息队列的关键。通过组合不同的 QoS 策略你可以精确控制数据的传输行为。分享几个我在项目中常用的配置可靠性 vs 性能的权衡// 可靠传输配置适合关键指令 ReliabilityQosPolicy reliability; reliability.kind RELIABLE_RELIABILITY_QOS; // 最大性能配置适合高频传感器数据 ReliabilityQosPolicy best_effort; best_effort.kind BEST_EFFORT_RELIABILITY_QOS;历史深度控制// 只保留最新数据默认 HistoryQosPolicy history; history.kind KEEP_LAST_HISTORY_QOS; history.depth 1; // 保留所有历史数据适合调试 HistoryQosPolicy keep_all; keep_all.kind KEEP_ALL_HISTORY_QOS;实时性保障// 设置截止时间超过时限的数据自动丢弃 DeadlineQosPolicy deadline; deadline.period.seconds 0; deadline.period.nanosec 100000000; // 100ms在车载系统中我们会为刹车指令配置 RELIABLE TRANSIENT_LOCAL 的 QoS确保关键指令绝不丢失而为摄像头数据配置 BEST_EFFORT VOLATILE优先保证传输效率。2.3 序列化机制数据如何变成比特流Fast DDS 使用 CDRCommon Data Representation格式进行序列化这是 DDS 标准的一部分。第一次看到生成的序列化代码时我被它的效率震惊了——完全没有使用反射或运行时类型信息全是硬编码的位操作。以这个简单的 IDL 定义为例struct SensorData { unsigned long timestamp; double value; string name; };Fast DDS 生成的序列化代码大致是这样的void SensorData::serialize(eprosima::fastcdr::Cdr scdr) const { scdr m_timestamp; scdr m_value; scdr m_name.c_str(); }实测下来这种方式的序列化速度比 Protobuf 快 3-5 倍特别适合高频传感器数据。但要注意字符串处理——CDR 对字符串有特殊格式要求建议预分配足够空间避免反复内存分配。3. 实战机器人通信系统搭建3.1 环境准备与安装推荐使用 Ubuntu 20.04/22.04 系统安装 Fast DDS 最方便的方式是 aptsudo apt install ros-distro-fastrtps如果是非 ROS 环境可以编译安装git clone --recursive https://github.com/eProsima/Fast-DDS.git mkdir Fast-DDS/build cd Fast-DDS/build cmake -DTHIRDPARTYON -DBUILD_SHARED_LIBSON .. make -j$(nproc) sudo make install安装后验证fastdds --version3.2 开发流程详解以一个实际的机器人导航系统为例展示完整开发流程定义数据结构nav_msgs.idlmodule nav_msgs { struct Pose { double x; double y; double theta; }; struct Path { sequencePose poses; }; };生成代码fastddsgen -replace nav_msgs.idl发布者实现关键代码// 创建 Participant DomainParticipant* participant DomainParticipantFactory::get_instance()-create_participant(0); // 注册类型 TypeSupport type(new PosePubSubType()); type.register_type(participant); // 创建 Publisher Publisher* publisher participant-create_publisher(PUBLISHER_QOS_DEFAULT); // 创建 Topic Topic* topic participant-create_topic(robot_pose, nav_msgs::Pose); // 创建 DataWriter DataWriter* writer publisher-create_datawriter(topic); // 发布数据 Pose pose; pose.x(1.0); pose.y(2.0); pose.theta(0.5); writer-write(pose);订阅者实现关键代码class PoseListener : public DataReaderListener { public: void on_data_available(DataReader* reader) override { Pose pose; SampleInfo info; if (reader-take_next_sample(pose, info) ReturnCode_t::RETCODE_OK) { std::cout Received pose: ( pose.x() , pose.y() ) std::endl; } } }; // 创建 Subscriber 和 DataReader 时指定监听器 PoseListener listener; DataReader* reader subscriber-create_datareader(topic, DATAREADER_QOS_DEFAULT, listener);3.3 性能优化技巧在真实项目中我总结了这些优化经验零拷贝配置DataWriterQos writer_qos; writer_qos.endpoint().history_memory_policy PREALLOCATED_WITH_REALLOC_MEMORY_MODE;共享内存传输同机通信participant profile_nameshm_transport rtps useBuiltinTransportsfalse/useBuiltinTransports transports transport_idshm/transport_id /transports /rtps /participant流量控制FlowControllerQos flow_controller; flow_controller.max_bytes_per_period 1024 * 1024; // 1MB/s flow_controller.period 1000; // 1s4. 典型问题排查指南4.1 发现失败常见原因防火墙阻止多播确保 UDP 7400-7410 端口开放Domain ID 不匹配检查所有节点是否使用相同 Domain ID网络接口配置错误特别是多网卡环境4.2 数据丢失分析遇到数据丢失时按这个顺序检查QoS 兼容性发布者和订阅者必须兼容历史深度设置资源限制检查内存和带宽网络状况使用 ping 和 iperf 测试4.3 性能问题定位我的性能分析工具箱fastddsmonitor实时监控通信状态Wireshark分析网络层行为perf定位 CPU 热点valgrind检查内存问题记得有次遇到莫名其妙的延迟最后发现是 QoS 配置了 TRANSIENT_LOCAL 但没设置足够的历史深度导致系统不断尝试存储过期数据。
