1. 课程导入

当你拆开一架现代多旋翼或固定翼无人机，会看到飞控、电调、GPS、磁罗盘、气压计、云台、电池管理、空速管等大量部件。它们并不是各干各的，而是通过一根或几根总线彼此交换数据：飞控要知道每个电机的转速指令是否被执行，电池要上报电压与温度，GPS要持续输出经纬度与定位质量。总线通信就是无人机的“神经系统”，决定了整机能否实时、可靠、可扩展地协同工作。

一、为什么无人机需要总线，而不是简单点对点连线

早期航模常用PWM信号：每个舵机或电调一根信号线，飞控输出脉宽控制。这种方式简单直接，但存在明显瓶颈。第一，线束数量随通道数线性增长，八轴飞行器仅电机就需八根信号线，加上传感器、云台，线束复杂且重量可观。第二，PWM只能单向传递一个控制量，无法回传电调温度、电流、转速等状态。第三，缺乏统一的错误检测与仲裁机制，某个节点故障可能直接导致失控。

总线通信把“多根线”变成“一对差分线或一组共享介质”，多个节点挂载在同一物理层上，通过协议约定谁在什么时候发送、发送什么格式、出错如何重传。这样带来的核心收益是：线束简化、双向通信、状态可观测、节点可扩展、错误可管理。对于无人机而言，重量、可靠性和实时性三者都极其敏感，总线方案因此成为必然选择。

二、无人机常用总线对比：UART、I2C、SPI、CAN

在进入DroneCAN与Cyphal之前，先建立总线全景。无人机内部常见的通信方式包括UART、I2C、SPI和CAN。它们各有适用场景，不能简单说谁替代谁。

可以看到，CAN在拓扑上天然适合“多节点共享总线”，并且具备差分抗干扰、非破坏性仲裁、CRC校验和错误帧机制。但CAN只定义了物理层和数据链路层，它规定了“怎么把一帧数据可靠地发出去”，却没有规定“这帧数据代表什么”。例如，帧ID为0x100的数据，到底是电机转速还是电池电压？这需要上层协议来约定。DroneCAN与Cyphal正是建立在CAN之上的两种应用层协议。

三、DroneCAN与Cyphal的定位

DroneCAN的前身是UAVCAN v0，由Pavel Kirienko等人发起，后来在无人机社区中广泛落地，成为ArduPilot、PX4等飞控生态中电调、GPS、电池、空速管等设备的重要通信标准。它的核心特点是：基于CAN、采用DSDL描述数据结构、支持即插即用、节点动态分配ID、消息优先级明确、适合资源受限的MCU。

Cyphal则是UAVCAN v1的演进与标准化成果，定位更通用。它不再局限于CAN，可运行在CAN FD、以太网、串口等多种传输层之上；采用更严格的类型系统和接口描述语言；强调确定性、安全性和大规模网络能力。可以这样理解：DroneCAN是无人机领域经过大量实战验证的CAN应用层协议，Cyphal是面向更广泛实时控制网络的下一代协议体系。

四、学习目标与整体框架

本课程的目标不是让你背协议条文，而是让你具备“从物理层到应用层”的完整开发能力。学完之后，你应当能够：

• 理解CAN物理层与数据链路层的关键参数，能独立排查总线不通信、误码率高、终端电阻缺失等问题。
• 掌握DroneCAN的节点ID分配、消息优先级、DSDL数据结构、动态节点分配与固件升级流程。
• 理解Cyphal的传输层抽象、类型系统、发布/订阅与服务调用模型，并能与DroneCAN进行对比选型。
• 能够在ArduPilot/PX4或裸机MCU上配置、调试、抓包分析DroneCAN/Cyphal通信。
• 能够设计一个多节点无人机总线网络，包括电调、电池、GPS、云台等设备的接入与参数配置。

整体框架按照“基础—协议—实战—排障”四段推进。基础部分讲清CAN帧、位定时、仲裁与错误处理；协议部分分别深入DroneCAN与Cyphal；实战部分覆盖飞控配置、设备接入、固件升级与日志分析；排障部分则围绕典型故障现象建立判断路径。

五、常见误区与复盘

初学者最容易陷入三个误区。第一个误区是“CAN就是DroneCAN”。实际上CAN只到数据链路层，DroneCAN是应用层协议，两者不在同一层。第二个误区是“速率越高越好”。CAN总线速率越高，对线缆长度、终端匹配和收发器要求越苛刻，1 Mbps在长线束上可能反而不如500 kbps稳定。第三个误区是“节点随便接就行”。CAN总线两端必须各有一个120Ω终端电阻，中间节点不能随意加终端，否则阻抗不匹配会导致反射和误码。

典型CAN总线检查清单：
1. 总线两端是否各有一个120Ω终端电阻？
2. CAN_H与CAN_L是否使用双绞线，且未与动力线长距离并行？
3. 所有节点波特率是否一致（如500 kbps）？
4. 节点ID是否冲突？DroneCAN动态分配是否正常？
5. 用示波器观察差分波形，是否存在明显反射或幅度不足？
6. 抓包工具是否能收到心跳帧与节点状态？