關於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說這個項目的進度須要通過仔細地設計。

而後確保底層接口的穩定性，越底層的東西越須要高質量地儘早完成，而不是相反。