RoboMaster
标题: 【交流帖】关于2017年裁判系统通讯的几个槽点(2017/4/26) [打印本页]
作者: 黄金剑士 时间: 2017-4-20 02:47
标题: 【交流帖】关于2017年裁判系统通讯的几个槽点(2017/4/26)
[attach]12175[/attach]现在很多队伍都得到裁判系统,并且看过裁判系统的数据手册了,现在就聊聊裁判系统通讯的事情。P.S. 如果赶时间的可以直接跳到最后看总结。
槽点一
首先,我们看看裁判系统用户手册V2.0,没下载的请点击 [官方公告] RM2017裁判系统用户手册(更新至17.4.17,版本V2.0)
[attach]12171[/attach]
[attach]12172[/attach]
好,第一个槽点出现,有谁能看出来有什么问题吗?
请细看,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个字节。
所以用户手册这里应该改成
[attach]12173[/attach]
槽点二
通过通讯协议格式,我们可以知道:
一帧数据:5字节帧头FrameHeader + 2个字节命令码ID CmdID + n个字节数据Data + 2个字节的CRC校验CRC16
一个帧头:1个字节的起始字节SOF(固定为0xA5) + 2个字节数据帧内Data长度DataLength + 1个字节包序号Seq + 1个字节的CRC校验CRC8
在此,我说一下,我们可以通过 命令码ID CmdID 来判断我们接受的是什么数据,然后可以通过 包序号Seq 来判断我们是否有出现丢帧的情况。
然后开始说第二个槽点。
现在我用某宝上便宜的逻辑分析仪去测串口数据,测试图如下
[attach]12174[/attach]
好,现在让我们测一下,得到下图:
[attach]12177[/attach]
从用户手册的47页可知比赛进程信息数据包发送频率为50Hz,周期就是20ms,从上图感觉好像没什么问题。是的,这里是没什么问题,那是因为我特地截取一段没问题的
现在我们看看别的:
[attach]12176[/attach]
我们可以发现这部分有4处的间隔不是16ms。经观察,大约220ms就会出现一次这种状况。也就是说,比赛进程信息发送频率并未完全如手册所说的是50Hz。
槽点三
接着我们聊聊下一个槽点,我敲击装甲片,并同时测量数据,得到下图
[attach]12188[/attach]
我们可以发现这里的数据有两个0xA5,而且根据0xA5推算的包序号刚好是按序递增,其实是两帧数据合在一起,分别是我敲击装甲片导致血量变化而发送的实时血量变化数据和定时50Hz发送的比赛进程信息。
P.S. 其实这点电科的开源代码也有提到过
由此可知,实时数据是粘连在比赛进程信息数据包
槽点四(2017/4/26更新)
对裁判系统重新上电,然后采集数据,得到下图:
[attach]12331[/attach]
通过图片我们可以看到,在上电后,裁判系统会一次性发送超过500个字节。所以,注意设置buffer的长度,或者上电的时候有一段时间不要读取串口。
槽点五
最后再聊聊我最最最想吐槽的,也是我感到最恶心的地方,现在我截取另一部分数据
[attach]12178[/attach]
我们可以看到数据1和数据4宽度差不多,数据2貌似比数据1和数据4窄点,数据3更过分了,那么窄。
然后我们放大各个数据。
[attach]12179[/attach]
[attach]12180[/attach]
[attach]12181[/attach]
数据1
[attach]12182[/attach]
[attach]12183[/attach]
数据2
[attach]12184[/attach]
数据3
[attach]12185[/attach]
[attach]12186[/attach]
[attach]12187[/attach]
数据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。当然如果上面有不对的地方,也请各位多多指教!
作者: lhpppp 时间: 2017-4-20 12:52
顶一个!我们也发现了类似问题
作者: 我爱吉神 时间: 2017-4-20 13:58
最近发现裁判系统不太稳定,有时候开机之后部分装甲片总是会红蓝灯狂闪,需要重启才会恢复正常。
但是谁的程序不会犯点小错误呢?
当然是选择原谅他啊!
作者: 我爱吉神 时间: 2017-4-20 14:00
看完这篇帖子,感觉楼主真的太认真了!大神费心了!
作者: Snail 时间: 2017-4-20 15:28
感谢指出
作者: USTC-damon 时间: 2017-4-20 15:51
已经具备一个工程师的严谨态度了。 赞一个。
第一个锅,接了。文档审核不严格。
第二、三、四就不接了。 楼主分析的这么仔细肯定会想到解决办法的。
作者: USTC-damon 时间: 2017-4-20 15:53
大家一起想一下解决办法
作者: USTC-damon 时间: 2017-4-20 15:56
感谢理解。小装甲的传感器有问题,程序目前解决不了。检录时,发现有问题,及时更换新的吧。
作者: 黄金剑士 时间: 2017-4-20 16:51
其他的都好解决,第四个有点蛋疼啊
作者: USTC-damon 时间: 2017-4-20 17:02
一帧数据不连续发, 可以使用buffer缓存。不要急着用串口空闲中断去解包。
作者: 黄金剑士 时间: 2017-4-20 18:55
了解,谢谢
作者: USTC-damon 时间: 2017-4-20 20:10
裁判系统确实也有一些不完善的地方的, 大家多积极讨论。互相进步,论坛都来讨论技术就好了。
期待你们的成长。
作者: 懂武 时间: 2017-4-20 21:39
感谢楼主分享!
作者: 我爱吉神 时间: 2017-4-20 22:40
大佬还是劳心解决一下吧,要不然基地一秒20发子弹岂不是掉帧掉到死......
可以在程序中分配各个包发送的时间段啊,比如说固定2ms留给0x01,1ms留给0x02,再不行直接打成一个包算了...
作者: 技术小宅 时间: 2017-4-23 13:59
请问楼主能把程序发给我吗?我也想研究研究,可到现在还没能接收到裁判系统返回的东西
QQ527960790,我可以送楼主好多金币的,谢谢啦
作者: ckyoung 时间: 2017-4-24 10:23
大哥,血量包上电之后两分钟左右以后再击打就没有血量数据包了。
。还必须要重新上电才能收到,这个问题不是分开解包就能解决的问题了吧。。
是裁判系统主控发送实时血量包的任务炸了么。。
作者: USTC-damon 时间: 2017-4-25 14:42
这个问题能复现嘛?确定是这个规律嘛?两分钟后打击装甲就不会有血量包了??
这个就不科学了,所有数据包的发送均是由一个单独的任务处理的。 血量变化数据,定时数据,都是写入一个buffer,然后由任务独立进行发送的。 你帮忙确认一下?是不是真有这样的现象?看下OLED实时数据显示界面,有没有掉血,真的产生了扣血,就应该会发出去的。
作者: LIAOYUANGANG 时间: 2017-4-25 20:09
同款骚红z7d2
作者: 天行 时间: 2017-4-28 21:15
楼主,图上剩余能量数据是0x00 0x00 0x70 0x42;但剩余能量值最大不是60吗?请问接收到的数据是怎么换算的?
作者: 黄金剑士 时间: 2017-4-28 23:32
本帖最后由 黄金剑士 于 2017-4-28 23:36 编辑
P.S. 如果看不懂,去看电科的开源程序(http://bbs.robomasters.com/thread-3650-1-1.html),或者百度联合体转换数据。
//联合体用于转换数据
typedef union
{
u8 u8_temp[4];
float float_temp;
s32 s32_temp;
u32 u32_temp;
}FormatTrans;
FormatTrans dataTrans;
dataTrans.u8_temp[0] = Array[31];
dataTrans.u8_temp[1] = Array[32];
dataTrans.u8_temp[2] = Array[33];
dataTrans.u8_temp[3] = Array[34];
gameinfo->remainPower = dataTrans.float_temp;
作者: 天行 时间: 2017-4-29 11:29
嗯嗯,谢谢楼主
作者: winner凡 时间: 2017-4-29 13:42
请问,如果在键盘上操控机器人,一定要用到遥控器吗,新系统说可以不要啊,为什么不用遥控器,键盘上操作不行,数据传输不到
作者: 黄金剑士 时间: 2017-4-29 16:30
如果想用键鼠操作战车,需要用数据线连接遥控器,安装好遥控器驱动,然后打开客户端
作者: winner凡 时间: 2017-4-29 16:48
问题是现在连接上了也不能操控
作者: 黄金剑士 时间: 2017-4-29 22:11
试一下用去年的(下载链接:http://bbs.robomasters.com/thread-3465-1-1.html),如果能用,那就是你电脑和新的客户端不兼容(据说,就win7 64位能用)
作者: voit 时间: 2017-8-14 13:46
有正确读回裁判系统的血量数据的吗,根据文档协议拿回来的数据看不懂呀!求大神指点,我请求血量数据,返回来的是这样的[63,e2,52,b,42,42,42,c2,ff],求解释呀
作者: 木 木跶 时间: 2017-10-20 20:46
66666666666666666666
作者: huangdihe 时间: 2017-11-3 23:38
赞赞赞赞赞
作者: 小小白白 时间: 2017-11-4 13:30
6666666666666666666666666666666666666666
作者: 123abc 时间: 2017-12-2 19:00
多谢楼主
作者: Copyright 时间: 2018-9-29 20:53
666666666666666666666666666666666666
欢迎光临 RoboMaster (https://bbs.robomaster.com/) |
Powered by Discuz! X3.2 |