车内通信协议

日期：2015年4月1日

版本：0.13

作者：Ricky Gong

网址：https://www.zybuluo.com/Tessedar/note/71749

LegoCar CommunicationProtocol

---

协议格式

Header	Func. ID	Data	Checksum
0xAAAA	0x03	...(different content)	SUM

左边为内存低位，右边为内存高位。发送与接收顺序皆为从左往右。

解释

Header：头部字段

该字段的值可分为以下两种情况：

• Server -> ECU，头部为0xAAAA
• ECU -> Server，头部为0xAAAF

Func. ID：功能字段

该字段的值（称为“功能字”）可分为以下几种情况：

• 0x03：传递数据
• 0x05：配置Power Module(PM)'s Firmwire
• TBD...

对于每一种功能字，与之对应的Data部分的长度是固定的；但是不同种功能字之间，相应的Data部分长度则不同。要注意，功能字隐含了数据字段的长度。这种安排是“定长”与“变长”之间的一种平衡。

Data：数据字段

该字段的值为要传输的数据。相对于不同的功能字，数据字段有不同的格式。下面将根据功能字分情况描述。

FID=0x03：传递数据

数据字段为PM的运动参数，表现为以下形式：

Func. ID	Servo Direction(SD)	Servo Angle(SA)	Motor Direction(MD)	Motor Speed(MS)
0x03	1 byte	1 byte	1 byte	1 byte

左边为内存低位，右边为内存高位。发送与接收顺序皆为从左往右。

字段中包含4个部分：舵机方向，舵机偏转角度，马达方向，马达速度。其中，舵机及马达方向，都是以地理坐标系（按车头方向，以前为正，以后为负；逆时针旋转为正，顺时针旋转为负）为参考的，而舵机偏转角度及马达速度，则由[0,100]的PWM百分数来表示。

取值范围：

• SD & MD = { 0xFF(pos), 0x00(neg) }
• SA & MS = [0, 100]

FID=0x05：配置PM’s Firmwire

数据字段为PM内部的坐标转换参数，表现为以下形式：

Func. ID	Servo Direction Convertor(SDC)	Motor Direction Convertor(MDC)
0x05	1 byte	1 byte

左边为内存低位，右边为内存高位。发送与接收顺序皆为从左往右。

由于FID=0x03帧传输的方向数据，是以地理坐标系为参考的，而车体中的各个PM，可能需要对相同的地理坐标数据做出不同的反应，才能相互配合完成整体的动作（例如：车体自旋[spin]）。换言之，PM需要依据各自的情况，将数据从地理坐标系转换成自身的几个简单动作（例如：舵机摆左，马达倒车）。这就要求可以在运行时动态配置PM的能力，而该能力则由FID=0x05帧来完成。

若转换参数为0xFF，则意味着需要对地理坐标进行转换；若为0x00，则不需要。

取值范围：

• SDC & MDC = { 0xFF, 0x00 }

Checksum：校验和字段

该字段用于数据校验，检验的范围是整一个帧（忽略SUM字段自身，可理解为SUM部分为0）。为了简便，计算时仅简单地将前面的数据按字节相加，且忽略高位溢出。

其余事项

1. 该协议为TCP协议的上层协议，考虑到TCP协议可以方便地实现单播和广播，因此这两种特性就使用TCP协议来实现，而该协议不再考虑。至于多播，对此目前而言仍没有需求。今后若要实现，可使用【TCP广播+上层多播】的方式来实现。

---

变动记录（Change Log）

版本 0.13 (2015-04-01)
- 改进: 改进 文档格式

版本 0.12 (2015-03-03)
- 新增: 添加 FID=0x05的格式及内存顺序
- 解决: 补充 FID=0x03的内存顺序
- 新增: 添加 FID=0x03的取值范围
- 新增: 添加 FID=0x05的取值范围
- 改进: 改进 FID=0x05的描述
- 解决: 补充 SUM部分的检验范围

版本 0.11 (2015-02-16)
- 解决: 补充 数据格式的内存顺序
- 解决: 修改 FID=0x03的格式
- 改进: 改进 FID=0x03的描述
- 新增: 添加 FID=0x05的描述（不完整）

版本 0.1 (2015-02-15)
- 新增: 构建 文档基本框架