## 协议概述
本协议是一种用于M1上位机与下位机之间通信的自定义通信协议,波特率为115200,以16进制格式传输。上位机向下位机发送请求(commands),下位机在收到来自上位机的请求后,作出相应的反应并返回应答(feedback)至上位机,帧结构说明如下。
## 帧结构说明
数据帧分为5个部分:起始标志位/帧头(Header),数据长度(Length),序列号(Sequence),有效载荷数据(Payload),检验码(Checksum)。
数据帧结构如下表所示:
Name |
Header |
Length |
Sequence |
Payload |
Checksum |
Size |
2 Byte |
1 Byte |
1 Byte |
N Bytes |
1 Byte |
### 起始标志位/帧头(Header)
起始标志位,即为我们常说的帧头,以固定不变的“55AA”作为起始标志位,标志着一帧的开始。
### 数据长度(Length)
数据长度,其值表示数据包Payload的长度。
### 序列号(Sequence)
帧的序列号从0开始,范围为0~255,消息的发送端每发送一个帧将该字段的值加1,接收端可以根据该字段是否连续,判断是否有丢包的情况发生。
### 有效载荷数据(Payload)
有效载荷数据,即实际数据内容,考虑到数据传输效率与可扩展性,本协议将Payload的长度设计为非固定长度,可适应不同的消息类型。
Payload分为两部分:MsgID和PARAM。
Payload |
MsgID |
PARAM |
指令的类型 |
指令的内容 |
Payload指令如下表所示:
Name |
Type |
MsgID |
PARAM |
Description |
车轮速度指令 |
发送 |
01 |
00 00 |
00 00 |
00 00 |
00 00 |
* M1是2电机4轮驱动模式,左/右两侧的两个轮子各由一个电机驱动。因此左边的两个轮子的速度是相同的,在发送左/右轮速度时,仅需发送一个轮子的速度,每个轮速是2个字节
* PARAM中前2个字节设置左轮的速度,接着2个字节设置右轮的速度,后面4个字节全部置0,用于后续拓展四轮控制
* 当我们改变车轮的速度的时候,其实是改变车轮编码器的计数,例如给左轮一个0.1m/s前进的速度,即给出的指令是0004,则需要通过计算将车轮速度转化为编码器的计数,后面会讲到如何计算
|
左轮 |
右轮 |
空字段,用于后续扩展 |
接收 |
01 |
00 04 |
00 00 |
00 00 |
00 00 |
返回的数据是当前时刻车轮编码器的累计计数 |
左轮 |
右轮 |
空字段,用于后续扩展 |
电池电量指令 |
发送 |
02 |
00 |
请求电池电量 |
接收 |
02 |
32 |
返回的数据为0~100电量区间的16进制表达,例如电量为50,则返回32 |
重置状态指令 |
发送 |
05 |
00 |
**注:当上位机在发送指令后,接收到错误状态信息FF时,必须发送重置指令,重置后才能恢复对下位机的控制**
|
接收 |
05 |
01 |
返回操作成功 |
05 |
00 |
返回操作失败 |
清除编码器计数指令 |
发送 |
06 |
00 |
对编码器计数清零 |
接收 |
06 |
01 |
返回操作成功 |
06 |
00 |
返回操作失败 |
错误状态指令 |
接收 |
FF |
01 |
电池没电 |
当上位机向发送请求,下位机发生错误无法执行指令时,会向上位机返回相应的错误信息 |
FF |
02 |
电流过大 |
FF |
03 |
串口通信故障 |
FF |
04 |
车轮卡死 |
错误状态处理流程图:
![Flow](imgs/autolaborPro1-flow.jpg)
### 检验码(Checksum)
为保证上位机与下位机所传输数据的无误性与一致性,本协议采用异或(XOR)校验的方式,根据具体发送的指令生成异或校验码,校验的数据包括帧头55AA,用户可以使用在线的[异或校验计算器](http://www.ip33.com/bcc.html)来计算,如下图所示**计算结果(Hex)**即时我们所需的异或校验码。
![XOR](imgs/autolaborPro1-xor.png)