关于2018年东南大学Robomaster算法组工做的总结

笔者在写做时，为东南大学机器人俱乐部下Robomaster大赛SUPER NOVA战队算法组的负责人之一（这名字写起来好长）。而SUPER NOVA战队则于2018年5月19日正式结束了中部分区赛，得到了二等奖与总决赛前复活赛的参赛资格，将于两月以后奔赴深圳参赛。本次比赛中咱们的工做有种种不如意之处、值得记录与反思。本文是对算法组在迄今位置的开发过程当中取得的各类成绩、遇到的各类问题的总结。

项目历程

我加入算法组是在一年前，也就是上个学期开始时开始。因为各类人员变更，现任的组长hby同窗是半年前上任的，项目实际上从那时才刚刚起步。那时咱们算法组的状况是，整个战队的算法历史很短，是去年的比赛临近比赛时开始工做的，老人们在退出前没有留下什么经验，而已有的代码难以复用。算法组负责的工做主要集中在比赛主办方DJI公司强调的视觉方面。好比很是强力的神符须要短期内按照数码管的指示依次击打一个九宫格内的手写数字，时间很是有限，只能靠机器完成；又或者今年的比赛中加入了全自动的哨兵机器人、只能经过内置的程序控制运行。

当时咱们对项目的规划并不清晰，只是提出要为哨兵开发地方机器人自动识别算法与防护策略、为步兵装载装甲板识别与跟踪，小符的击打等等。当时的人手则是有我和hby还有一个后来退出的三个大三的同窗，以及hby带的三个学弟。有感于今年近于从零开始的情景，hby提出来两点，一是要把工做下放到学弟手中练手，确保算法组工做的传承，一是要写一个高度模块化、复用性好的库，后者是他叫我进来的理由。

而算法的难度不在考虑之列，是的，这些视觉算法其实都算不得难，至少在科研界是入门级都够不到的东西。

到后来发生了人员变更、资金短缺等等事情，但咱们的算法开发很是顺利，由于算法毕竟都很简单，到比赛前几天，算法基本都到了可用的地步，能够装车了。就在这时，咱们项目中的种种问题暴露了出来。在省赛前的最后几天，咱们日日熬夜，我与hby通宵四天，最后仍是没能让它在车上发挥做用，直到今天，也就是比赛的最后一天，自瞄功能才刚刚上线，已经于事无补了。

发生了什么？

这个项目中发生的事太多，当局者迷，我须要一点一点理清各个致使进度异常的因素。

首先是最后几天发生的事情，也就是在算法开发完成后上车实测的时候发生的事情。

1. 上下位机交互没有保证
2. 代码移植出现问题
3. 新系统上出现问题

第一件事用掉了我一天的时间，咱们上下位机之间经过串口通讯，按照约定的协议发送信息。我把致使这些事情的缘由列举在下面。

硬件不清楚

既然使用串口通讯，那么天然是要链接串口线的，不幸的是，我对硬件的链接并不清楚，在调试硬件上的代码前须要确保硬件的链接无误，即便要多花一些时间也是值得的。事实上，我就是由于线在屡次调试时时而插反，妙算将电流噪声当作了下位机发来的信息，天然是抓破脑壳都查不出问题来。

底层协议编写出现问题

底层的协议实际上是有问题的。因为align的存在，底层在计算一帧长度时少算了一些长度，在我被噪声困扰时，我首先意识到这个问题而且跟电控确认修改了这个问题。为何协议没有先行测试？由于之前有测试的那一版被更新了，编写者以为本身没改多少就没测。为何之前没有出现这个问题？之前的协议是去年的算法组写的，他们知道这个问题。这其实是联控问题。

开发环境没有统一

代码移植的问题是由开发环境未统一形成的。实际上，hby是坚决的VS拥护者，由于在VS下调试视觉算法有众多方便的插件，而整个组里熟悉Linux环境的人只有我一个。咱们的代码最终运行在Linux Arm环境的妙算上，算一算，咱们开发时可谓四大皆空——平台、库版本、语言标准、编译器均不相同。

这实际上是个人责任，做为惟一熟悉Linux编程的人，应该在最开始就提醒移植代码这件事的困难性。否则、我也应该确保这些东西的一致，给队员作必要的培训，为他们部署使用简单的软件，或者干脆使用模拟器或者交叉编译等技术来解决它。只能说我没有经验，这件事是一个教训、一个警钟。代码必须可以保证运行，而这件事在测试前很难保证，于是实际环境下测试是很是重要的

代码同步有问题

这一点须要和上一点结合来看。咱们使用git管理代码并协同工做，并在码云上托管了一个远程仓库。这件事原本是一件好事，然而因为所有人员都不能保证熟悉git，于是在离开图形界面后操做变得很是困难，以致出现了有git却还要手动同步，或者整个团队都中止工做，只为等待一我的代码完成同步成功的状况；同时因为没有意识，你们常常会有忘记同步的状况发生，每次都是一个灾难。这些事情大大地拖慢了项目进度，无论怎样，一夜什么事都没作只同步了一下实在是不像样。

项目中心化太强

“对这个项目有全面了解的人只有我，这样不行” ----hby

是的，还在成长中的学弟须要hby去带，知道项目已经写到什么状况的人只有hby，知道下一步应该作什么的也只有他一我的。这种状况下他实际上变成了这个原本应该并行的项目中的互斥锁，这样在前期还好，在后期你们聚在一块儿磨合的时候，这样就会实际上空耗整个团队的人力，俗称全队看着程序员干活无所事事。

新系统上出现问题

这个问题并非代码的问题，而是系统自己的问题。在妙算的嵌入式linux系统上，会出现不少windows上不会出现的问题。好比，它上面的opencv必需要使用V4L库先作处理才能打开摄像头，直接调用VideoCapture类会出现打不开的问题，并且，调用V4L的opencv程序必需要正常退出，而不能使用Crtl - c 用信号退出，由于系统不能自动回收摄像头资源，屡次Crtl-C以后会致使摄像头没法再次打开的问题。另外，C++不保证正常return之外的退出main函数的操做会调用析构函数。

我目前的解决办法是捕获SIGINT信号，让它改变一个全局变量，主函数轮询这个变量以后退出。

另外，出现相似须要解决动态库连接等与系统相关的问题时，开发人员缺乏独立解决问题的能力，可能查百度都不能照着解决。

这都能有技术流失

到最后几天终于作出初版装甲板跟踪后，咱们却发现控制性能很是差：飘得很厉害。

诸多调试后，才发现这是好久以前已经解决过的一个问题，可是随着协议的更新，电控那边发生了技术流失，这个问题又从新回来了——很不幸，又浪费了巨多的时间。

更根本的缘由呢？

是什么致使了上面这些琐碎的问题发生？确定有开发人员和管理人员都没有经验的缘由，除此以外，还有一些其它的缘由。

首先是整个队伍的进度太慢。是的，直到最后几天车只是勉强能动，距离作完差得还远。因此直到最后咱们才真正有机会调试，问题于是暴露得太晚。

其次是资金的短缺。hby在一个月前曾经花一个下午的时间把他本身的程序移植到了TX2上，而且作出了已经能用的装甲板跟踪，因此他以为不少事情都很简单。然而，由于资金的问题，咱们最后只能用次一档的妙算。咱们忽略了这一点。

最终是项目规划的问题。虽然知道本身该作什么，但整个项目的规划是有问题的，这其实仍是管理人员没有经验，对时间的规划是很是重要的。

因此学到的教训是什么？

就我我的而言，教训是在作项目时，须要对目标平台有明确的认识，对所使用到的技术要详细地调查，而且可以熟练地使用，在此以前，须要肯定开发的目标平台不要变。

若是让我来重作这个项目，我必定要先确认团队的资金，进而肯定最终使用的平台，而后确认使用的库版本以及标准，确保这些东西可以和目标平台兼容。把全部的程序隔三差五就在妙算上跑一遍，最好就要求每一个人的代码都要本身在linux上跑。在此以前我须要给队员开linux培训，教给他们make cmake shell脚本 程序的编译连接 动态库静态库等知识。若是时间不够我教，那么我就要给他们提供尽量便利的环境。

而后跟hby说这个项目的进度须要通过仔细地设计。

而后确保底层接口的稳定性，越底层的东西越须要高质量地尽早完成，而不是相反。