3. DroneCAN协议入门
DroneCAN 是无人机与小型无人系统中广泛使用的一种轻量级 CAN 总线应用层协议。它最初以“UAVCAN”之名诞生，目标是在资源受限的飞控、电调、GPS、磁力计、电源模块、舵机等设备之间，建立一套统一、可互操作、可自动发现的数据通信标准。理解 DroneCAN，不能只把它当作“CAN 报文格式”，而应把它看作一套建立在 CAN 物理层与数据链路层之上的节点管理、数据交换和服务调用体系。
协议起源：从 UAVCAN 到 DroneCAN
UAVCAN 最早由 Pavel Kirienko 等人提出，旨在解决无人机内部设备通信协议碎片化的问题。早期飞控与外围设备常使用 PWM、UART、I2C、SPI 等点对点或短距离总线，线缆复杂、扩展困难、错误检测能力有限。UAVCAN 选择 CAN 总线作为底层，因为 CAN 具备差分传输、抗干扰强、多主仲裁、硬件 CRC 与错误帧机制，非常适合电机、电池、舵机等强电磁干扰环境。
随着 UAVCAN v1 与 Cyphal 的演进，社区出现了标准分裂与生态迁移。为了保持现有无人机生态的稳定，DroneCAN 作为 UAVCAN v0 的延续与独立维护分支出现，继续沿用成熟的 DS-015 风格数据类型、动态节点 ID 分配、固件升级、参数访问等机制。因此，DroneCAN 不是“另一个 CAN 协议”，而是面向无人机工程实践的 UAVCAN v0 兼容实现。
关键结论：DroneCAN 的根是 UAVCAN v0；它保留 CAN 2.0B 扩展帧、29 位标识符、1 Mbps 典型速率和基于 DSDL 的数据类型定义，强调即插即用与多厂商互操作。
设计目标：为无人机而生的通信约束
DroneCAN 的设计目标可以归纳为五个方面：
- 互操作性：不同厂商的飞控、电调、GPS、电源模块只要遵循同一 DSDL 数据类型，就能在同一总线上交换数据。
- 自动发现与动态节点 ID：节点上电后可通过动态分配获得 1~127 的节点 ID，避免手动配置冲突。
- 实时性与确定性：CAN 仲裁机制保证高优先级报文优先发送，适合姿态、电机控制等周期数据。
- 资源受限友好：协议栈可运行在 32 位 MCU 上，RAM 与 Flash 占用相对可控。
- 可维护性：支持参数读写、固件远程升级、节点状态监控与总线诊断。
这些目标决定了 DroneCAN 的报文不是“裸数据”，而是带有节点 ID、数据类型 ID、传输类型和校验信息的结构化通信单元。典型 CAN 扩展帧的 29 位 ID 被划分为优先级、数据类型 ID、源节点 ID 等字段，接收方据此判断“谁发的、发的什么、要不要处理”。
与标准 CANopen 的关系：同源不同路
DroneCAN 与 CANopen 都建立在 CAN 总线之上，都使用 11 位或 29 位标识符、对象字典思想、节点 ID 和心跳/状态监控机制，但二者面向的领域和工程取舍明显不同。CANopen 源自工业自动化，强调过程数据对象 PDO、服务数据对象 SDO、网络管理 NMT、紧急对象 EMCY 等完整体系，适合 PLC、伺服、传感器等工业设备。DroneCAN 则面向无人机，强调动态节点分配、DSDL 数据类型、固件升级和轻量级实现，不直接兼容 CANopen 的 CIA 301 应用层。
| 对比维度 | DroneCAN | 标准 CANopen |
|---|---|---|
| 起源领域 | 无人机 / 小型无人系统 | 工业自动化 / 运动控制 |
| 应用层标准 | UAVCAN v0 / DSDL 数据类型 | CIA 301 + 设备子协议 |
| 节点 ID 分配 | 支持动态分配，即插即用 | 通常拨码或配置固定 |
| 数据建模 | DSDL 消息 / 服务 | 对象字典 + PDO/SDO |
| 固件升级 | 协议内置文件传输与升级 | 依赖厂商或额外协议 |
| 典型速率 | 1 Mbps，CAN 2.0B 扩展帧 | 125 kbps ~ 1 Mbps，11 位帧常见 |
学习提示：如果你熟悉 CANopen，可以把 DroneCAN 理解为“为无人机裁剪并重新定义数据类型的 CANopen 近亲”。二者共享 CAN 底层，但应用层报文不能直接互认，需要网关或协议转换。
典型应用场景：从飞控到外围设备
DroneCAN 在无人机中的典型应用非常集中，主要解决“多设备、强干扰、轻线缆、可维护”的问题。
- 飞控与电调通信：飞控通过 DroneCAN 向电调发送油门、转速、电流限制等指令，电调回传转速、温度、电压、故障状态。相比 PWM，CAN 总线只需两根信号线即可串联多路电调。
- GPS / 磁力计 / 气压计：GNSS 模块通过 DroneCAN 上报位置、速度、时间、卫星数、定位状态，飞控无需为每个传感器单独布线。
- 智能电池与电源模块：电池管理单元上报电压、电流、剩余电量、温度、循环次数，飞控据此做低电量返航与功率限制。
- 舵机与执行机构：固定翼舵机、云台电机可通过 DroneCAN 接收位置指令并回传状态，减少 PWM 线束。
- 固件升级与参数管理：地面站可通过总线对节点进行参数读写、固件刷写和节点状态监控。
案例：四旋翼上的 DroneCAN 总线
假设一架四旋翼使用 DroneCAN 连接飞控、4 个电调、1 个 GPS 模块和 1 个电源模块。上电后，飞控作为动态节点 ID 分配服务器，为各节点分配 1~127 的 ID。飞控周期发送 uavcan.equipment.esc.RawCommand 广播报文，电调根据自身 ID 判断是否响应；电调周期回传 uavcan.equipment.esc.Status，飞控据此检测电机堵转、过温、过流。GPS 模块发送 uavcan.equipment.gnss.Fix，电源模块发送 uavcan.equipment.power.BatteryInfo。所有节点共享同一对 CAN_H/CAN_L 线，两端各接 120 Ω 终端电阻。
# 典型 DroneCAN 节点启动日志（示意）
[init] CAN bitrate = 1000000
[init] dynamic node id allocation start
[ok] node id = 42
[ok] esc status publisher started
[ok] gnss fix subscriber started
[ok] battery info publisher started
[ok] param server ready
[ok] firmware update service ready常见误区与复盘
误区一：把 DroneCAN 当成 CAN 本身。CAN 只定义物理层和数据链路层，DroneCAN 是应用层协议，二者是“公路”与“交通规则”的关系。
误区二：认为 DroneCAN 与 CANopen 可以直接混用。虽然都跑在 CAN 上，但标识符分配、数据类型、服务机制不同，混用会导致报文无法解析。
误区三：忽略终端电阻与总线拓扑。DroneCAN 仍遵循 CAN 总线规则，星形分支过长、终端电阻缺失或阻值错误，都会导致通信不稳定。
误区四：动态节点 ID 冲突。若多个节点同时请求分配，需依赖协议栈的仲裁与重试机制；调试时应先确认节点 ID 分配是否成功。
复盘来看，DroneCAN 的价值不在于“发明了新总线”，而在于把 CAN 的可靠性、多主仲裁和差分抗干扰能力，与无人机所需的动态组网、统一数据类型、固件升级和参数管理结合起来。掌握它的起源、设计目标、与 CANopen 的边界以及典型应用场景，是后续学习 DSDL 数据类型、节点分配、报文收发和总线调试的基础。