【交流帖】关于2017年裁判系统通讯的几个槽点（2017/4/26）
6145
0
30
2017-04-19
[attach]12175[/attach]现在很多队伍都得到裁判系统，并且看过裁判系统的数据手册了，现在就聊聊裁判系统通讯的事情。P.S. 如果赶时间的可以直接跳到最后看总结。
![]()
槽点一
首先，我们看看裁判系统用户手册V2.0，没下载的请点击 [官方公告] RM2017裁判系统用户手册（更新至17.4.17，版本V2.0）
槽点四（2017/4/26更新）
对裁判系统重新上电，然后采集数据，得到下图：
槽点一
首先，我们看看裁判系统用户手册V2.0，没下载的请点击 [官方公告] RM2017裁判系统用户手册（更新至17.4.17，版本V2.0）
好，第一个槽点出现，有谁能看出来有什么问题吗？
请细看，46页上写LOC状态部分数据的大小为13，好，让我们看看tLocData结构体定义。tLocData结构体包含5个成员，分别为一个uint8_t型和4个float型，学过C语言的都知道，1个float型数据的大小是4个字节，1个uint8_t（即unsigned char）型数据的大小是1个字节。
好，现在我们算一下，tLocData结构体的大小=1x1+4x4=17个字节
对，没有错，是17个字节，实际发送的也是17个字节。
所以用户手册这里应该改成
槽点二
通过通讯协议格式，我们可以知道:
一帧数据：5字节帧头FrameHeader + 2个字节命令码ID CmdID + n个字节数据Data + 2个字节的CRC校验CRC16
一个帧头：1个字节的起始字节SOF（固定为0xA5） + 2个字节数据帧内Data长度DataLength + 1个字节包序号Seq + 1个字节的CRC校验CRC8
在此，我说一下，我们可以通过 命令码ID CmdID 来判断我们接受的是什么数据，然后可以通过 包序号Seq 来判断我们是否有出现丢帧的情况。
然后开始说第二个槽点。
现在我用某宝上便宜的逻辑分析仪去测串口数据，测试图如下
好，现在让我们测一下，得到下图：
从用户手册的47页可知比赛进程信息数据包发送频率为50Hz，周期就是20ms，从上图感觉好像没什么问题。是的，这里是没什么问题，那是因为我特地截取一段没问题的
现在我们看看别的：
我们可以发现这部分有4处的间隔不是16ms。经观察，大约220ms就会出现一次这种状况。也就是说，比赛进程信息发送频率并未完全如手册所说的是50Hz。
槽点三
接着我们聊聊下一个槽点，我敲击装甲片，并同时测量数据，得到下图
我们可以发现这里的数据有两个0xA5，而且根据0xA5推算的包序号刚好是按序递增，其实是两帧数据合在一起，分别是我敲击装甲片导致血量变化而发送的实时血量变化数据和定时50Hz发送的比赛进程信息。
P.S. 其实这点电科的开源代码也有提到过
由此可知，实时数据是粘连在比赛进程信息数据包
槽点四（2017/4/26更新）
对裁判系统重新上电，然后采集数据，得到下图：
通过图片我们可以看到，在上电后，裁判系统会一次性发送超过500个字节。所以，注意设置buffer的长度，或者上电的时候有一段时间不要读取串口。
槽点五
最后再聊聊我最最最想吐槽的，也是我感到最恶心的地方，现在我截取另一部分数据
我们可以看到数据1和数据4宽度差不多，数据2貌似比数据1和数据4窄点，数据3更过分了，那么窄。
然后我们放大各个数据。
先说明一下，因为我没有接定位模，没连服务器，也没过自检，所以输出的数据为：比赛剩余时间，电压，电流，LOC状态都是0，机器人剩余血量为1500，剩余能量为60J。
好，现在我们看一下，数据1，数据2，数据4都是有数据帧起始字节0xA5，其包序号依次为0xDA，0xDB，0xDC，数据3开始字节不是0xA5。
难道这数据3是杂波，或者是因为逻辑分析仪比较便宜识别错误？
来，我们对比一下数据1，数据2，数据4，他们都有0xA5的起始字节，包序号依次递增，然而，到后面，我们看到数据1，数据4结尾是0x00 0x00 0x70 0x42（剩余能量数据）和CRC16校验（因为包序号不同，即使数据一样，其CRC16也是不同的），而数据2是却是一堆0做结尾。
难道数据2发生丢失？
然后再看数据3，我们发现数据3的结尾是0x00 0x00 0x70 0x42，这不是剩余能量数据吗？通过数字节数，发现数据1，数据4的字节数为44，数据2的字节数为35，数据3的字节数为9。数据2和数据3的字节数加起来刚好是44。
通过这些迹象表明，数据2和数据3实际为同一帧数据，也就是说裁判系统它把一帧数据拆成两段发出来。
![]()
总结一下，通过上面的实验我们知道一下几点：
最后说一下，根据以上特点，如使用DMA+串口空闲中断的方式去读取裁判系统很容易产生丢帧现象，所以，如果想要很好读取裁判系统数据，必须修改串口读取数据的方式，具体是哪种读取方式，就看各位了，有兴趣的可以说一下，同时有别的槽点也请说出来，让大家看一下，谢谢！
P.S. 关于数据发送频率不一致和一帧数据拆成两段发送这两个情况，我不知道这是设计者有意而为之还是失误，从在下渣渣的理解能力来看，觉得是应该是裁判系统程序的任务互相干扰导致串口数据不正常发送，不知道后面会不会修复这个BUG。当然如果上面有不对的地方，也请各位多多指教！
我们可以看到数据1和数据4宽度差不多，数据2貌似比数据1和数据4窄点，数据3更过分了，那么窄。
然后我们放大各个数据。
数据1
数据2
数据3
数据4
先说明一下，因为我没有接定位模，没连服务器，也没过自检，所以输出的数据为：比赛剩余时间，电压，电流，LOC状态都是0，机器人剩余血量为1500，剩余能量为60J。
好，现在我们看一下，数据1，数据2，数据4都是有数据帧起始字节0xA5，其包序号依次为0xDA，0xDB，0xDC，数据3开始字节不是0xA5。
难道这数据3是杂波，或者是因为逻辑分析仪比较便宜识别错误？
来，我们对比一下数据1，数据2，数据4，他们都有0xA5的起始字节，包序号依次递增，然而，到后面，我们看到数据1，数据4结尾是0x00 0x00 0x70 0x42（剩余能量数据）和CRC16校验（因为包序号不同，即使数据一样，其CRC16也是不同的），而数据2是却是一堆0做结尾。
难道数据2发生丢失？
然后再看数据3，我们发现数据3的结尾是0x00 0x00 0x70 0x42，这不是剩余能量数据吗？通过数字节数，发现数据1，数据4的字节数为44，数据2的字节数为35，数据3的字节数为9。数据2和数据3的字节数加起来刚好是44。
通过这些迹象表明，数据2和数据3实际为同一帧数据，也就是说裁判系统它把一帧数据拆成两段发出来。
总结一下，通过上面的实验我们知道一下几点：
| 命令码 | 功能介绍 | 备注 |
| 0x0001 | 比赛进程信息 | 正常情况下是以50Hz发送，但有时数据频率并不是50Hz，并且会出现1帧数据拆成两部分发送 |
| 0x0002 | 实时血量变化数据 | 该数据当发生血量变化时才发送，并粘连在比赛进程信息前面发送 |
| 0x0003 | 实际射击数据 | 该数据当发生射击动作时才发送，具体粘连在哪个位置就不清楚了，没测，有兴趣的可以帮测一下 |
最后说一下，根据以上特点，如使用DMA+串口空闲中断的方式去读取裁判系统很容易产生丢帧现象，所以，如果想要很好读取裁判系统数据，必须修改串口读取数据的方式，具体是哪种读取方式，就看各位了，有兴趣的可以说一下，同时有别的槽点也请说出来，让大家看一下，谢谢！
P.S. 关于数据发送频率不一致和一帧数据拆成两段发送这两个情况，我不知道这是设计者有意而为之还是失误，从在下渣渣的理解能力来看，觉得是应该是裁判系统程序的任务互相干扰导致串口数据不正常发送，不知道后面会不会修复这个BUG。当然如果上面有不对的地方，也请各位多多指教！
文章标签
请问这篇文章对你有用吗？
【交流帖】关于2017年裁判系统通讯的几个槽点（2017/4/26）