FishBot底盘通讯协议V1.0.0.220621_alpha

小鱼

FishBot底盘通讯协议V1.0.0.220621_alpha

本协议主要针对运动控制板与上位机通信制定，协议分为数据帧和数据段两部分，校验方式采用CRC16循环冗余校验，传输采用小端模式。

本版本暂不设计响应帧和心跳帧。

数据帧协议

帧头	帧序	目标地址	数据段	校验位	帧尾
1B(0X5A)	1B	1B	NB	2B	1B(0X5A)

转义规则

非帧头尾出现0X5A，将0X5A转义为 0X50 0X0A，除 0X50 0X0A出现0X50，使用0X50 0X05替换。

数据段协议

数据总数	数据编号n	数据长度	数据操作	数据n	数据编号n+1	数据长度	数据操作	数据n+1
1B	1B	2B	1B	NB	1B	2B	1B	NB

数据编号：

0x01-左右轮编码器
0x02-IMU传感器
0x03-速度控制数据
0x04-PID设置
0x05-版本信息

数据操作：

0X01,反馈数据（底盘向主控）
0X02,命令数据（主控向底盘）

数据协议

协议1：传感器数据

编码器（左右轮count数量）与IMU数据（MPU6050-三轴角速度&三轴加速度）

数据总数	数据编号1	数据长度	数据操作	数据2	数据编号2	数据长度	数据操作	数据2
0x02	0X01	0X00 0X04	0X01	0X00 0X01 0X00 0X01	0X02	0X00 0X0C	0X01	0X00 0X01 0X00 0X02 0X00 0X03 0X00 0X04 0X00 0X05 0X00 0X06

协议2：电机速度控制

数据总数	数据编号n	数据长度	数据操作	数据
0x01	0X03	0X00 0X04	0X02	0X00 0X01 0X00 0X02

协议3：PID

数据总数	数据编号n	数据长度	数据操作	数据
0x01	0X04	0X00 0X06	0X01/0X02	0X00 0X01 0X00 0X02 0X00 0X03

协议4：版本

软硬件版本以ASCII明文传输

数据总数	数据编号1	数据长度	数据操作	数据
0x01	0X05	0X00 0X04	0X01/0X02	硬件版本,软件版本（ASCII）

本协议为小鱼定的初稿，欢迎大家针对其中内容提出问题，留言讨论。

小鱼

@小鱼我发现个错误，数据长度为2B，你样例只用了1B。

哈喽哈嘿

鱼总，看了这个协议，我有两个疑问哈。
第一：帧序感觉说的不够清楚，我不太明白它是干啥用的。
第二：关于转义规则中的0x5A问题，如果数据里出现0x5A，比如编码器的值或者IMU的值，那么也要转义么？这样不就会增加数据端的长度了么，感觉程序处理起来比较麻烦啊，不如加长帧头，加上crc16的校验，出问题的可能性已经非常低了。

小鱼

@哈喽哈嘿我来解释下

帧序代表每一帧发送出去的序号，发送端各自累加，帧序的设计主要是为了响应帧的设计，某段时间内发送端收到发送帧相同帧序则代表响应，初次之外也可以检测是否出现丢帧情况，后面可能还会在时间同步上用到。
具体可以参考TCP/IP的滑动窗口协议。

2.关于转义，转义的进行是在组装完帧发送前完成的，改变的是最终发送时候的长度，数据段无法感知，所以不用直接的对IMU数据或者编码器数据做校验。关于出问题可能性，因为我们最有可能采用UDP传输数据，出错可能性相对直接串口较大。程序上是稍微不好处理些，但可以保证不会因为我们正常数据中出现0x5A造成接收端解析错误。