px4中的UAVCAN_V1特点与仲裁原理

简介

在 2021 年，UAVCAN 进行了升级，名称也修改为了 OpenCyphal，这是由于其将协议内容扩展到了 UDP，串口，以后也将扩展到更多底层协议，而不但单只能用于 CAN，因此名称修改了。而最初此协议就是基于 CAN 来做的，因此最初名称为 UAVCAN。
在PX4中，从2021年左右，开始更新新版本的 UAVCAN，之前的 UAVCAN 版本为 v0.9，后续，由于 UAVCAN 官方对此协议进行了较大的更改，因此 PX4 在 21 年之后，将新版本的 UAVCAN 在工程中另建立了一个文件夹，命名为 uavcan_v1，之前 v0.9 的版本还是叫做 uavcan，但是 uavcan_v0.9 版本应用比较广泛，因此 uavcan 团队将旧版本的 uavcan，即 uavcan_v0.9 又另建立了一个工程，名字叫 DroneCAN，来单独维护。PX4 中对旧版本的 uavcan_v0.9 还是沿用原来的名字 uavcan。

DroneCan：uavcan_v0.9 ，PX4 对其维护得时间较久，功能美满
uavcan_v1：官网对其进行了优化修改，PX4 刚开始更新
UAVCAN 是基于 CAN 总线来实现的，但并不是修改了 CAN 的底层实现，而是在 CAN 协议的底子上，再次封装了传输层，应用层，以 CAN 协议作为物理层和数据链路层。类似于串口与 MAVLink 的关系。
目前，UAVCAN 支持两种语言，按照库，语言，以及传输设备分为：
库传输设备语言LibcanardCANCPyCyphal恣意Python PX4 中 uavcan_v1 使用的是以 C 实现的 Libcanard，uavcan 使用的是用 c++ 实现的 DroneCAN 库--- Libuavcan。
UAVCAN 使用 DSDL 格式文件来管理数据。DSDL 全称为 Data structure description language，即数据结构形貌语言，使得数据看起来更清晰，更易明白。
除库之外，官方提供了三个工具：
1）Nunavut ---用于将DSDL文件编译成 C/C++/python 源文件
2）Yakut --- 一个命令行工具，用于调试和诊断 Cyphal 网络，支持请求订阅消息，提供了心跳检测
3）Yukon ---用于观测，调试
通信模式

UAVCAN 重要是两种通信模式：
1）服务模式：以服务端/客户端的方式，点对点通信
2）消息模式：以发布/订阅的方式，一对多通信
CAN总线的仲裁机制

如果要明白 UAVCAN 的实现原理，首先必须了解 CAN 总线的仲裁机制。
在 CAN2.0 协议中，分为 A版本与 B版本，A版本就是常说的标准帧CAN，B版本就是常说的扩展帧CAN。
如果要了解 CAN 的仲裁机制，需要了解一下这三项内容：
1）ID 标识符
2）差分信号
3）仲裁过程
ID 标识符

标准帧的 ID 标识符 为 11 位的，而扩展帧的 ID 在 11 位的底子上，扩展到了 29 位。ID 标识符在 CAN 协议中的作用就是用来实现总线仲裁，总线根据 ID 优先级来判定当前哪一个节点抢占总线，发送数据，而 ID 标识符，在 CAN 的完备数据帧中，就是仲裁段。
标准帧与扩展帧两者的数据帧结构如图：

从图中可以看到，扩展帧的仲裁段在 RTR 段之前，又扩展了 18 位的 ID 数据。
CAN差分信号

在了解仲裁机制之前，需要大概了解一下 CAN 总线的差分信号。
CAN 总线上，使用 CAN_H 与 CAN_L 两根线的电位差来体现数据，将电位差的状态分为：显性电平，隐形电平 两种。显性电平代表逻辑电平的 0，隐形电平代表逻辑电平的 1。
在整个传输中，先是 CPU 将逻辑电平发送给 CAN 控制器，之后 CAN 控制器将逻辑电平转化为 差分电平：

逻辑电平与 CAN 差分电平的对应关系为：

CAN仲裁过程

在 CAN 总线通信中，有两个机制对实现总线仲裁是非常重要的：
1）回读机制
3）线与机制
回读机制：指节点在向总线发送消息的时间，也会对总线上的二进制位进行回读。之后，节点就可以对比要发送的数据位与总线实际的数据位是否是雷同的，如果不雷同，则说明总线已经被优先级更高的节点占用，当前节点就不会再抢占总线，进而会转为吸收状态。
线与机制：指总线上，显性位(逻辑0) 可以或许覆盖隐形位(逻辑1)，即，总线上只要有一个节点将此位拉到了低电平，那么总线就是低电平。
以一个例子来说明 CAN 总线的仲裁过程，假设总线上有两个节点 Node_A 与 Node_B ，在总线空闲时，为隐形电平，两个节点都检测到了总线当前空闲，之后，两个节点同时向总线发送消息：

最先发送出来的就是数据帧中的仲裁段，也就是 ID 标识符段，从上图中可以看出，前面的两个节点发送的位都是雷同的。从 ID7 开始，位就开始差别，总线上的电平是取0的：
节点/IDID10ID9ID8ID7Node_A1010Node_B1011总线电平1010 将节点发送的电平与总线电平列了上面的表格，发送的时间是按照 ID 位从高到低位发送，前面都雷同，在 ID7 的时间，Node_A 的 ID7 为0，Node_B 的为 1，此时根据线与机制，总线上的电平为0。
在每一次发送之后，节点都会有一个回读机制，读取当前总线上的电平，在发送到 ID7 的时间，Node_B 回读发现总线上的电平已经与自身发送出去的差别了，之后 Node_B 就会放弃抢占总线，转为吸收状态，不再发送消息。
根据回读机制与线与机制，CAN 总线实现仲裁过程，之后就可以保证根据 ID 来确定优先级来抢占总线发送数据，即节点 ID 越小的，优先级越高。
UAVCAN特点

UAVCAN 与 CAN2.0 相比，重要的特点包含两大部分：
1）节点ID
2）数据帧
UAVCAN 与普通 CAN 相比，UAVCAN 对扩展帧 CAN 的 29 为 ID 进行了重新定义。
对扩展帧 ID 进行重定义的原因

CAN 总线是广播机制的，也就是一对多的通信模式，可以直接实现 发布/订阅 的功能，因为普通CAN 总线包含的 ID 就是吸收此消息的目标节点 ID。
如果要实现 服务端/客户端 的功能，实现点对点通信，就需要将消息节点ID 与目标节点ID 一起发送出来，这也就是 UAVCAN 需要对扩展帧 CAN 的 ID 进行重定义的原因。
也就是说，UAVCAN 对 29 位 ID 进行重定义之后，不仅包含了吸收此消息的目标节点ID(普通CAN只包含此吸收消息的目标节点 ID)，也包含了发送消息的节点 ID。
UAVCAN的ID定义

UAVCAN 的 ID 是在扩展帧的底子上进行重定义的，节点 ID 是低7位来体现，以是节点范围为：0-127，记作 Source node-ID。
广播消息

对于广播消息，UAVCAN 对 ID字段的自定义如下：

低 7 位用于存放发送源节点 ID，范围为 0-127；
中间 8-20 位为消息主题ID (Subject-ID)，也就是自定义的消息类型 ID，范围为 0-8191，即，支持发送 8192 种消息主题。
最先三位体现优先级，Priority。优先级越小，级别越高(与 CAN 的仲裁机制有关)
请求/相应消息

请求/相应消息对应 服务端/客户端，ID 定义如下：

Service-ID --- 请求或相应的服务主题 ID (类比 Subject-ID 消息主题 ID，此为 服务主题 ID)
Destination node-ID --- 目标节点 ID，如果此消息是请求消息，则为目标节点为服务端 ID，如果是此消息是相应消息，则目标节点为客户端 ID
广播消息与请求/回复消息的区别是第 25 位 ID：
广播消息的第 25 位 ID 为 0，请求服务消息的第 25 位为 1。
请求/回复消息的类型由第24位ID决定：
为1体现此消息是从客户端到服务端的请求消息，为0体现此消息是从服务端到客户端的回复消息
这里有一个概念，DSDL 数据格式支持两种数据类型：
1）消息主题类型
2）服务主题类型
因此，在广播消息中，有一个消息主题 ID，指定此消息的主题类型，在请求/相应消息中，有一个服务主题 ID，指定此服务类型的主题。
优先级越小，级别越高，优先级的定义如下表：
0异常1立刻2快速3高速4正常5低速6慢速7可选 UAVCAN数据帧

UAVCAN 对于普通 CAN 的重定义，除了 ID 的重定义外，还有数据帧的重定义。
普通的 CAN 数据帧，单帧发送的数据包，最大是 8 个字节。
单帧消息

UAVCAN 对单帧的最后一个字节进行了拆分，1 个字节的 8 个位分成了几个字段，携带协议信息：

Start of transfer --- 如果此主题消息单帧发送不完(超过7个字节)，则必然会发送多帧数据，如果此帧是第一帧，则此位为1，否则为0；如果是单帧消息，则该为一直为1
End of transfer --- 如果此主题消息单帧发送不完(超过7个字节)，则必然会发送多帧数据，如果此帧是最后一帧，则此位为1，否则为0；如果是单帧消息，则该为一直为1
Toggle --- 如果是单帧消息，则该为一直为0，如果是多帧消息，则翻转该位(若第一帧为0，则第二帧为1，云云翻转)
Transfer ID --- 标识此次传输的ID
传输ID(Transfer ID)

传输ID 的作用在于不一连传输，UAVCAN 支持消息传输的不一连性，尤其是请求/相应消息时，加入客户端有两个请求，请求1 与请求2，则 UAVCAN 就是通过差别的请求 ID 来区分相应的消息时回复哪一条请求的。
多帧消息

多帧消息与单帧消息就头帧是差别的，别的都雷同，多帧消息的第一帧的前两位增加了 CRC 校验信息，校验整个主题消息的数据，别的与单帧雷同，单帧消息没有增加 CRC 校验信息。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。