2. DroneCAN基础

DroneCAN 是建立在经典 CAN 总线之上的轻量级应用层协议，理解它必须从物理层、帧结构、节点身份和通信模型四个层面同时切入。很多一致性测试失败并非协议实现错误，而是对底层 CAN 行为、帧格式字段或节点 ID 分配规则理解偏差造成的。本节把这条链路拆开，帮助你在后续测试中准确判断“问题出在哪一层”。

一、CAN总线原理：差分信号与仲裁机制

经典 CAN 使用两根差分线 CAN_H 与 CAN_L，显性位（逻辑 0）将总线拉成约 2V 压差，隐性位（逻辑 1）压差接近 0V。这种差分结构带来强抗共模干扰能力，非常适合无人机上电机、电调、电源线密集的电磁环境。总线两端各需一个 120Ω 终端电阻，用于吸收信号反射，缺少终端电阻时波形会出现振铃，误码率显著上升。

CAN 的核心是“非破坏性逐位仲裁”。每个节点发送帧时，先发帧起始位，再逐位发送标识符。显性位会覆盖隐性位，因此 ID 数值越小（显性位越多）优先级越高。当多个节点同时发送时，发送隐性位却读到显性位的节点立即退出仲裁，转为接收，赢得仲裁的节点继续发送，报文不会丢失也不会重发冲突。这一机制决定了 DroneCAN 中高优先级消息（如节点状态、安全相关指令）应分配较小的 CAN ID。

二、DroneCAN帧格式：从CAN帧到应用消息

DroneCAN 使用扩展帧（29 位标识符），把 CAN ID 拆成多个字段承载协议语义。典型结构如下：

数据场最多 8 字节。当应用消息超过 8 字节时，DroneCAN 使用传输层分片：首帧携带总长度和起始数据，后续帧按序拼接，接收端重组后交给上层。测试中常见的“大消息丢包”往往与分片超时、序号错乱或重组缓冲区不足有关。

# 典型 DroneCAN 扩展帧 ID 解析示例
CAN ID = 0x1A0F2C05
Priority        = 0x03
Message Type ID = 0x0F2C
Service/Message = 0 (广播消息)
Source Node ID  = 0x05
Destination     = 0xFF (广播)

三、节点ID分配：动态分配与冲突处理

DroneCAN 节点 ID 为 7 位，范围 0~127，其中 0 通常保留给控制器或调试工具，1~125 可供普通节点使用，126 和 127 有特殊用途。节点上电后若未配置固定 ID，会进入动态分配流程：先监听总线，发送 NodeStatus 探测，若发现 ID 被占用则随机退避后重试，直到获得唯一 ID。分配完成后，节点会周期性广播自身状态，供其他节点和地面站发现。

固定 ID 与动态 ID 各有适用场景。量产机型建议固定 ID，便于日志分析和故障定位；研发阶段或即插即用设备可用动态分配。无论哪种方式，同一总线上 ID 必须唯一，否则会出现仲裁冲突、状态混淆和参数读写错乱。

四、通信模型：广播、服务与参数访问

DroneCAN 的通信模型可归纳为三类交互：

• 广播消息：如 NodeStatus、uavcan.protocol.NodeStatus，发送方不指定目标，所有节点均可接收，用于状态发布和周期遥测。
• 服务请求/响应：如参数读取、固件升级、节点重启，采用请求-响应模式，目标节点 ID 明确，响应帧通过 Request Not Response 位区分。
• 参数访问：基于服务实现，读取或写入节点参数，是配置管理和一致性测试的高频操作。

从信号链角度看，一次参数读取的完整路径是：地面站构造服务请求 → CAN 控制器仲裁发送 → 目标节点接收并解析 → 执行参数读取 → 构造响应帧 → 总线回传 → 地面站匹配请求 ID 并解析。任一环节超时或字段错误，都会导致测试失败。

五、案例与复盘：一次参数读取失败的排查

某机型在参数读取时偶发超时。排查发现总线上两个电调节点都被配置为 Node ID = 3。由于 ID 相同，两者在服务响应阶段交替赢得仲裁，地面站收到的响应帧 Source ID 相同但内容不同，导致请求匹配混乱。将其中一个节点改为固定 ID = 4 后问题消失。这个案例说明：节点 ID 唯一性是 DroneCAN 通信模型成立的前提，也是一致性测试的第一道检查项。

另一个常见误区是把 CAN 总线当成“可靠传输”。CAN 只保证帧级 CRC 和自动重发，不保证应用层消息一定被处理。DroneCAN 的服务请求需要应用层超时和重试机制，测试时应验证节点在丢帧、总线负载高、目标节点忙等情况下的行为是否符合预期。

掌握以上四层基础后，后续的测试用例设计、日志解析和故障定位都会变得有据可依。建议在实际总线上用示波器观察差分波形，同时用协议分析工具抓取扩展帧 ID，把“位”和“字段”对应起来，形成对 DroneCAN 的直观认识。