一、背景：飞控通信正在变成“系统工程”

在传统飞控系统中，ESC、传感器和飞控之间的通信方式大多是：

• PWM / DShot（控制）

• UART / CAN（遥测）

• MAVLink（对外）

这种方式在 单飞控、单控制器 的时代完全够用，但随着系统复杂度提升，问题逐渐暴露：

• 数据格式强耦合，扩展困难

• 外设智能化程度提高（ESC、智能传感器）

• 与 ROS 2 / Companion Computer 的融合成本高

在 PX4 生态不断向 分布式 + ROS 2 演进的背景下，一个问题变得非常现实：

资源受限的 MCU（ESC / 外设），如何“原生”接入 DDS / ROS 2？

这正是 XRCE-DDS 出现的背景。

---

二、什么是 XRCE-DDS？

XRCE-DDS（eXtremely Resource Constrained Environment DDS）
是 OMG 制定的 DDS 标准子集，专门用于：

• MCU

• RTOS / Bare Metal

• RAM / Flash 极小的设备

一句话概括：

XRCE-DDS 是让 MCU 设备进入 DDS / ROS 2 世界的通信协议。

它并不是完整 DDS，而是通过 Client–Agent 架构，把复杂度放在资源充足的一侧。

---

三、XRCE-DDS 的核心设计：Client–Agent 模型

这是理解 XRCE-DDS 的关键。

1️⃣ 架构思想

• Client（MCU 侧）

  • 只负责收发数据

  • 不参与 DDS 发现

  • 不维护复杂 QoS

• Agent（Linux / Companion 侧）

  • 真正的 DDS 节点

  • 与 ROS 2 / Fast DDS 交互

MCU 并不“直连 DDS”，而是被代理接入。

---

四、PX4 + XRCE-DDS 系统整体架构图

下面这张图，非常适合直接放在 CSDN 文章里👇

 ┌──────────────────────────────────────────────┐
 │                 ROS 2 应用层                  │
 │  ┌──────────────┐     ┌──────────────────┐  │
 │  │ 控制 / 监控节点 │     │  状态分析 / UI   │  │
 │  └───────▲──────┘     └─────────▲────────┘  │
 │          │ DDS Topic                │         │
 └──────────┼─────────────────────────┼─────────┘
            │                         │
 ┌──────────┴─────────────────────────┴─────────┐
 │              XRCE-DDS Agent                   │
 │        (Fast DDS / micro-ROS Agent)           │
 └──────────▲─────────────────────────▲─────────┘
            │ XRCE-DDS                 │ XRCE-DDS
     UART / CAN / UDP            UART / CAN / UDP
            │                         │
 ┌──────────┴─────────┐     ┌─────────┴──────────┐
 │        ESC #1       │     │        ESC #2       │
 │  ┌──────────────┐  │     │  ┌──────────────┐  │
 │  │ XRCE Client   │  │     │  │ XRCE Client   │  │
 │  │ 电流 / 电压    │  │     │  │ ERPM / 温度   │  │
 │  │ 转速 / 方向    │  │     │  │ 状态遥测     │  │
 │  └──────────────┘  │     │  └──────────────┘  │
 └────────────────────┘     └────────────────────┘

👉 ESC 在系统中不再只是“执行器”，而是 DDS 网络中的数据节点。

---

五、ESC 场景下 XRCE-DDS 的工程角色划分

ESC MCU 侧（XRCE-DDS Client）

在实际工程中，ESC 侧只需要做很少的事情：

• 建立 XRCE Session

• 定期发送遥测数据

• 接收控制 / 配置命令

例如发布的 Topic：

• esc/telemetry

  • 电流

  • 电压

  • 温度

  • ERPM

  • 旋转方向

接收的 Topic：

• esc/command

  • 启停

  • 模式

  • 参数配置

---

Agent / Companion 侧

Agent 运行在：

• Companion Computer

• Linux 飞控

• 或 PX4 支持的 Linux 平台

主要职责：

• 创建 DDS Topic

• 转发 XRCE 数据

• 对接 ROS 2 节点

---

六、电机遥测的数据流分析（工程视角）

以 电机转速 ERPM 为例：

ESC 采样 ERPM
   ↓
XRCE-DDS write()
   ↓
UART / CAN
   ↓
XRCE-DDS Agent
   ↓
DDS Topic: esc/telemetry
   ↓
ROS 2 / PX4 / 控制算法

实时性分析

• 无 DDS 发现延迟

• 无动态内存分配

• 确定性强

• 非常适合 100Hz～1kHz 级遥测

---

七、Reliable / Best-Effort 的工程取舍

XRCE-DDS 支持两类 Stream：

类型	适合场景
Best-Effort	ERPM / 电流 / 电压
Reliable	参数配置 / 状态同步

在 ESC 实际工程中，常见策略是：

• 遥测 → Best-Effort

• 控制 / 配置 → Reliable

这和飞控“控制优先，数据可丢”的设计哲学完全一致。

---

八、XRCE-DDS 与 PX4 uORB 的关系

很多人会问：

XRCE-DDS 会不会替代 PX4 的 uORB？

答案是：不会，也不应该。

• uORB

  • 飞控内部通信

  • 强实时、低延迟

• XRCE-DDS

  • 飞控对外通信

  • 面向分布式系统

你可以把 XRCE-DDS 理解为：

PX4 的 DDS 出口

---

九、与 MAVLink / CAN 的工程对比

对比项	MAVLink	CAN	XRCE-DDS
ROS 2 原生	❌	❌	✅
扩展性	一般	中	极强
MCU 资源占用	低	低	低
数据模型	消息 ID	帧	IDL / Topic

XRCE-DDS 的最大优势不是“快”，而是：

系统级架构扩展能力

---

十、总结

在 PX4 + ESC 场景中，XRCE-DDS 带来的并不是简单的通信升级，而是：

• 架构解耦

• 数据标准化

• 与 ROS 2 原生融合

• 更清晰的系统边界

一句话总结：

XRCE-DDS 让 ESC 和外设，从“被控制对象”升级为“系统节点”。