行有不得者皆反求诸己，其身正而天下归之
前几天去天津比赛了，智能车华北赛区的比赛。
今天刚回来
”笑死，根本没完赛“
大概是这么一个过程
七月十九日---第一天
上午从学校出发坐大巴去北京科技大学天津学院。真的是特别偏僻的地方，离天津市区七十多公里...
走的时候比较仓促，对赛道元素的判断和方案都没有最终确定，所以决定抱着几小块赛道（一块白直道、一块两端有斑马线的直道，四块R100 90°弯道）去住宿地调试。
因为之前赶工熬了两天夜，在车上基本上全程睡着，太累了。
到了目的地，在登记入住的楼下，我们发现另一个团队，人数众多，在一层门厅内整齐列队。我们调侃说他们是正规军，我们是游击队来着。
住宿条件还可以，比我想象的要略好，不过忘记拍图了。比较难受的是地板是白色瓷砖，和赛道基本上没有什么差异。找了半天，我们发现床板是深棕色的，就把床垫移了下来，基本上可以铺设赛道了。又清点了工具、组装了比赛用车和调试的半成品车。
晚上整个车队跑去旁边的旋转小火锅吃了顿饭，看起来其他队伍都很有信心，但是我的三岔还没有调完......?
第二天就要交车模，晚上连夜改代码，修改三岔识别不准确的问题（之前是用色块比对的，斜入三岔是无法识别的)
众所周知，熬夜改代码的效果非常糟糕。人也非常疲惫，很想躺下再也不起来。但终还是赶了出来。
这套代码将三岔识别的方式由以往的固定色块识别改成了连通域判断，对于三岔的判断还是比较灵敏。
具体思路：
- 先将图像以3x3的大小按照一定的权重缩小，缩小后的图像大小为16x62，减少后续运算量。
- 将最底层的扫线基准点的横坐标以及最大扫线高度转换为16x62图像中的坐标
- 按照算出的坐标设置赛道标记的种子，用四连通域生长来标记赛道范围
- 扫描顶层四行，当出现大于等于四个的赛道-黑色 跳变点，以及大于等于四个的黑色-赛道 跳变点时设定为三岔
当天凌晨再赛道上试的时候还比较好用，和圆环及十字设置了互斥条件，所以不易误判。
屋漏偏逢连夜雨 船迟又遇打头风
不幸的事情总是迟迟的在关键节点发生，第二天早上八九点钟，我正在调试的时候，发现斑马线会被识别成三岔...
对，因为斑马线出现在图像上端时是符合设定的“大于等于四个跳变点”的条件的...
然后整个人就懵了，此时距离上场比赛不到一个小时。
很明显，斑马线误判成三岔的是因为跳变点的原因，没有限制同一行跳变点的个数以及两种跳变点之间的最小距离。
明确了方向就比较好改，也确实做出了修改版。但是，等候区的棚子是红色的，光透过来根本分不清赛道和地面，也就无从尝试...
进入赛场，先领车然后到等候区等待，确认车辆正常后进入赛场。
对于全新的赛道，自然做的是先标定赛道参数（对于电磁和图像循迹大都有一些跟赛道相关的特征）
我们在入环岛、三岔内时使用了电感辅助判断或者矫正偏差，所以应当记录和修改直道、环口和三岔中的电感值。
但是实际上在比赛前我们并没有详细的说明需要标定的元素，所以忘记了对于环岛电磁特征的标定
这也直接导致第一天电磁入环原因未能检出和第二天在尝试入环时内切严重而失败的结果。
智能视觉组只有三次发车机会，比赛时间限制在10分钟内。
前三分钟完成了标定，后面多次尝试电磁出库均失败，修改程序时笔记本死机、下载器失灵，最终因时间耗尽比赛结束，未能完赛。
晚上回去总结后发现以下几点问题：
- 程序适应性较差，在简易搭建的赛道上没有大量的实验验证，无法保障其正常运行。
- 版本管理出现问题，赛赛场上使用的程序版本根本不是决定的最终版。因为本地的最终版本提交，但因为网络原因未成功推送到远程仓库。
- 时间分配出现问题，没有针对复杂的赛场情况做充足的准备，当出现电脑死机、下载器失灵的状况没有对应的处置措施。
七月二十日--第二天
熬夜，没熬住。
醒的时候已经是六点多了。
本来以为换成倒叙就可以安排在下午比赛的。好家伙，比第一天还早。
代码相比昨天修改内容如下：
- 更正了版本差异
- 更正了模式切换后，没有设置对应的
Judge_MODx枚举变量的问题 - 更新了三岔判断条件，使跳跃性的顶部黑区面积增长将三岔状态归零（一定程度上可以减少斑马线误判成三岔）
- 更新了AprilTag的识别条件，在原有条件下增加对图像两侧固定区域的扫描，避免和斑马线误判
这一部分我有点和补赛记混了。
因为自己了解完成的状况，所以在预赛第二轮中似乎有点过于放松。
按照预定的规划，第一次先尝试入环程序，也就是使用Judge_MOD3()
这一部分的入环出环主要是根据实验室赛道环境（Φ120cm的环岛）设置的，因为没有判断入环出环时的顶部特征，直接采用了延时拉线，配合设置的电感左右权重的土办法，虽然效果还可以，但是要求赛道特征相近，否则会出现切边等问题。
然后PLAN A就?了...
PLAN B过环岛（直接略过）是可行的，但是过三岔总是撞到标靶，也就是说卡在了三岔识别的第一阶段，或者直接进入了十字模式（十字模式只依赖电感偏差）。
当裁判宣布“时间耗尽，比赛结束”的时候，心情有点复杂。
两个多月的摸鱼时光是消费掉了，还随附着大半瓶冻干咖啡粉。
但至少终于结束了这糟糕的未准备好的比赛，只不过是预料之内的结果罢了。
颇象是差生面对自己不及格的成绩一般。
反正已经结束了
然后和同样没完赛的基础四轮组跑去沙县小吃干饭
喝了一杯酸梅汤。
自从七月初发烧隔离开始，似乎就没正常吃过饭。早饭是照常不吃的（除非通宵），午饭和晚饭二选一，缺少的那顿用含糖饮料代替。
下午说又补赛，内容很简单，完成给安慰奖。
好嘛，就三岔有问题，那就把三岔条件给宽松就好了。
然后比赛的时候好像忘记给三岔开锁了，也就是行驶到三岔处的时候无法进入三岔的判断程序。
随机按丢边补线进入了三岔，然后又随机按丢边补线没成功出三岔...
到这里，真就结束了。
总结
原来想着如果整的好的话，代码就开源了。但是实际上跑的不行，代码也缝缝补补，改的稀烂，就不丢人现眼了。
然后再回来看这一段时间的备赛过程，无非就这几个问题：
- 对赛题解读不完善，导致最后几天才了解到需要跑两圈赛道，调试不充分
- 后期版本管理不完善，没有在提交是写好commit信息，多处修改没有分次提交，提交后没有确认是否将本地内容推送到远程服务器。
- 赛前调试不充分，不仅仅是元素识别不稳定，并且因为长时间针对校内赛道进行参数上的调试，导致程序缺乏普适性。
- 状态机不完善，对于在某状态中跳出或者两个元素间互斥的判断没有做好（大坑）
- 其它（想到再改）
新坑
下学期肯定不当正式队员了，技术本领不过硬，熬夜也熬不动，而且也不是特别喜欢这种总是被催着干活的形式...
当然遇见了困难，最好是尽量解决，以免后来者也受此坑害
所以预备着先把用过的图像调试程序改一改，基本实现能够实时通过串口接受小车采集的图像，然后在电脑上运行图像处理程序并实时显示补线结果。后期如果有时间就集成上下双向通信，使用上位机调参或控制小车（但是我好像没带板子，只有mm32和ab32的裸片...）
大概就这样，一篇总结更了一周...
哦我AprilTag的思路还没写，那就过几天再写一篇吧...
Comments 2 条评论
不愧是我曹哥
@奥秘Sir 嘿嘿，欢迎到访