背景

通過前期在家庭拖地機器人方面的工程實踐，我們發現處理這種類似場景（封閉場所，環境相對靜態，低速行動，需要機器人主體在2D平面上自主導航）的應用，有太多相似的地方，可以模塊化，提供硬件平臺+軟件平臺的打包方式，幫助工程應用迅速完成導航，感知，決策，運動控制方面比較專業和困難的任務，快速應用和市場化。我們把這個可復用，通過簡單配置的即插即用的硬件+軟件平臺，統稱為運動控制平臺。 目前除了家庭掃地，拖地機器人應用外，我們還在 下一代智能AGV小車(自動導引車），進行工程導引，解決傳統的AGV小車需要為某個特定路線預設磁條，修改路線非常困難的痛點。

目前人工智能領域普遍被認為是移動互聯之后，下一個風口，但是看到能夠落地的工程應用不多，其中自動駕駛是其中最炙手可熱的可落地領域。互聯網巨擎（谷歌，uber,百度為首），傳統汽車大廠， tier1供應商，學術明星和領域知名專家的初創公司，紛紛進入該領域，投入到這場轟轟烈烈的全新的交通運輸生態的創建中。截止2017年6月18日以來，共有34家公司獲得美國加州路測資格，其中中國背景的公司就有9家，見下圖（來自公開互聯網）：

通過對自動駕駛技術的了解，發現自動駕駛與我們的運動控制平臺無論從技術框架構成，還是到硬件平臺應用理解，軟件核心算法上都基本契合。本文通過比較自動駕駛和運動控制平臺的技術棧，具體實現算法，普及自動駕駛技術，分析自動駕駛技術發展給我們留下的切入點和機會，及運動控制平臺未來的擴展點。

下文的比較，自動駕駛主要拿百度的Apollo技術作為描述比較主體，因為目前自動駕駛技術，百度公開的最為徹底，它所用的思想，代表了目前做自動駕駛的主流路線。

技術框架（運動控制平臺vs自動駕駛）

下圖是我們運動控制平臺的技術棧分層：

上圖中，橙色部分是我們運動控制平臺的主體，其中運算單板是運動控制平臺提供的硬件模塊部分，由ARM CPU，NEON， Mali GPU, FPGA 組成的嵌入式異構并行計算平臺。其中感知，定位，避障，地圖，路徑規劃，導航，跟蹤是封裝的軟件算法模塊，工程應用通過配置就可即插即用。藍色模塊，是配套，硬件部分根據工程實踐的需要進行選取，軟件操作系統層和仿真層是目前開源的軟件棧。

運動底座是工程方進行設計提供，在我們的家庭拖地車實踐中，我們自己設計了結合拖地要求的底座。在AGV小車的工程實踐中，傳統的AGV小車輪式結構可以直接拿來用。 一般來說，對于低速移動的場景應用，差分輪式運動底座是應用比較普遍的選擇。 有兩個主動輪，可以分別控制轉速和轉的方向， 前面有一個被動萬向輪。運動底座向上提供的基本接口包括：線形速度，角速度或者曲率控制， 查詢當前里程計信息（運動底座通過輪半徑，轉動數目進行統計），完成上層對于運動底座的底層控制和信息查詢，通過低速的串行接口通訊就基本滿足要求。做對機器人做算法學術研究，或者前期對運動控制算法做驗證階段，會選擇商用的運動底盤提供商的產品，如比較有名的kobuki運動平臺，從圖中可以看到，它的提供了豐富的接口，非常方便對于傳感器和計算單元的擴展。

在與運算單板同層的其他模塊，都是感知單元。按照工程實踐的實際要求，進行選取。這些感知單元涵蓋了目前主流的環境感知技術，傳感單元中 沒有包含gps。 這跟我們目前運動控制平臺主要的應用場景和要求有關。 我們的工程應用目前在室內的比較多， gps 在室內環境是沒有信號的，對于定位沒有幫助。 傳感單元中提供了碰撞傳感的選項，在室內掃地拖地場景中，低速機器人是要求盡量全覆蓋，尤其是墻角邊緣，這樣是需要碰撞傳感結合滿足要求的。 在其他場景如AGV小車，則不能碰撞，不需要與障礙物無限靠近。激光雷達的選擇，結合成本和當前應用場景的要求，單線雷達就滿足要求。 傳感器的作用相當于，機器人的眼睛，跟上層軟件功能棧配合，完成定位算法，物體識別，物體跟蹤，建圖，避障，動作規劃功能。

操作系統層面，我們的軟件建立在目前主流的機器人操作系統ROS（Robot operation system)。ROS是Willow Garage公司在2010年發布的開源機器人操作系統，由于其具有點對點設計，不依賴于編程語言，分布式架構，強大的硬件抽象，廣泛的社區參與貢獻，豐富的可復用，知名的開源庫資源，已經成為機器人設計的不二選擇。對于低速運動場景，原生的ROS環境完全滿足設計要求。

Gazebo 仿真平臺是機器人設計人員的主流選擇。在算法驗證階段，我們不可能缺省認為運動底座，傳感器，單板，驅動都準備就緒的機器人，立在那里等我們上板調試。也不可能有戶型各異，障礙物擺放各異的室內環境讓我們去嘗試。仿真平臺對于機器人設計至關重要。 Gazebo 仿真平臺是一個開源的仿真工具，通過Gazebo，我們可以在pc上設計我們的機器人外觀，各種傳感方式，機器人各部分相對移動方式（如機械手臂6個自由度的移動）。我們可以設計任何三維環境，根據設計師三維建模水平而定，可以設計無限逼真的三維仿真環境。當然，簡單的環境仿真，直接通過所見即所得的方式，拖拽一些缺省模塊，可以快速建立一個室內仿真環境。 我們曾經為商場掃地車工程實踐， 設計過一比一的掃地車，和商場模型，玻璃窗和地面的光反射，激光透射玻璃都相當逼真。我們可以在pc 的Gazebo平臺上，使用我們預先建立的機器人模型和環境模型，驗證算法。Gazebo 仿真平臺目前是商用自主移動機器人，無人機設計的主流選擇。

下圖是自動駕駛Apollo技術框架（來自于互聯網）:

百度的自動駕駛分為四層技術棧：

1. 參考汽車平臺： 一輛汽車， 必須可以實現電子化的控制，也就是線控。百度目前的參考設計使用的是Lincoln MKZ, enhanced by Autonomous Stuff, 為用戶提供了一個無障礙的自動車輛平臺。該平臺為用戶提供了一整套硬件和軟件解決方案。用戶可以直接獲得車輛某些模塊控制權限，如檔位，速度和指示燈。見下圖：

2.? 參考硬件平臺： 為了實現高性能穩定的計算，百度采用的是工業級PC Neousys宸曜科技 Nuvo-5095GC作為運算單元， 配置6th-Gen Intel? Core? i7/i5 LGA1151 CPU 和NVIDIA? GeForce? GTX 1050* GPU，可以工作在-25度到60度的工作范圍。

GPS/IMU采用的是NovAtel SPAN-IGM-A1，理論上 rtk-gps加IMU的融合方案出來的精度能達到厘米級別。在apollo 1.0 沒有公開攝像頭，Lidar(雷達)，Radar(毫米波雷達)信息，不過根據百度以前無人駕駛車的信息，有一個Velodyn 64線HDL64E雷達，配套一個長距毫米波雷達和中距毫米波雷達，一個魚眼攝像頭和一個攝像機鏡頭。

3. 操作系統： Apollo 采用 ubuntu 14.04+ ROS indigo。 其中ROS是做了定制化修改的，使得更適合自動駕駛的要求，后面章節會詳細介紹。

4. 上層算法：算法模塊的構成與運動模塊基本類似。多了端對端和HMI。HMI是百度自動駕駛提供的人機交互界面，方便操作者統計，調試。 端對端算法是一種所見即行動的一種思想，通過深度學習，將感知直接轉化為控制，這是一種實驗性質的算法，目前的狀況不應該是主流應用。

5. 云： 主要有三個作用, ?訓練模型， 自動駕駛仿真， 高精地圖提供。

從上面關于運動導航模塊和自動駕駛技術棧的描述，我們可以看到兩者之間有頗多相似的地方。

1. ?運動底盤 vs 參考汽車平臺：都是運動的控制主體，為上層算法提供控制接口進行驅動，提供查詢接口進行反饋。 運動底盤和汽車控制的時候都是要滿足非完整約束，就是不在作出向前移動的情況下，無法單獨完成橫向位移。 相比于運動底盤，汽車平臺的動力學模型會更加復雜，除了速度不是一個量級的 ，慣性因素會使得控制更加復雜。 汽車的橫向位移（轉彎）靠前輪的朝向與前輪后輪形成直線的夾角的變化，屬于自行車模型。 運動控制模塊多采用差分輪運動底盤，橫向位移靠兩個輪子相互反方向旋轉，靠不同的旋轉速度比，來滿足不同曲率的要求。在控制算法的選取中，會有不同。

2. 硬件平臺： 運算單元和感知單元部分。 運算單元， 運動控制平臺采用的是嵌入式異構計算單板， 滿足低速簡單運動場景的感知算法，決策，控制算法的計算要求。 汽車應對的高速，絕對可靠安全的場景，運算量不是一個量級，目前多采用工業級PC的方案，里面多采用英偉達的GPU，來滿足感知對于運算量的要求。芯片廠商， 英偉達，德州儀器，賽靈克斯，intel， 也紛紛推出自己的芯片方案，中國的寒武紀，中星微也有自己的芯片方案，后續運算單元平臺將是百花爭妍的局面。感知單元， 運動控制平臺和自動駕駛采用的傳感器大多重疊。有幾個不同地方。 深度攝像頭可以在運動控制平臺應用場景中的室內場景中使用，深度主要靠結構光技術，抗干擾能力差，目前的技術上，在室外場景不可靠。 自動駕駛多采用雙目攝像頭來完成深度識別。 運動控制平臺采用超聲和紅外完成被動障礙感知， 自動駕駛采用汽車電子方面非常成熟的毫米波雷達方案。

3. ?操作系統， 兩者都使用 ubuntu 14.04+ ROS indigo。汽車對于實時性， 帶寬， 分布式要求會更加嚴苛。 原生的ROS 對于這三方面都無法達到自動駕駛的要求，雖然 ROS 2.0 會在這三個方面有很大的提升，但是仍然處于實驗階段。 大部分自動駕駛廠商，包括百度，都是在ROS基礎上作深度定制。?

4. 上層算法：模塊分類基本類似，所采用的算法實現有很多借鑒的地方， 在后面的章節詳細描述。

5. ?仿真： 運動控制平臺的場景相對簡單，采用開源的gazebo 仿真技術，在一些相對高配置的pc上基本滿足要求。 自動駕駛一般要自動駕駛廠商自己搭建仿真平臺， 汽車要仿真的環境非常復雜，計算量消耗很大，一般要采用云技術分布式平臺。?

6. 地圖： 運動控制平臺的地圖創建所描繪的場景比較簡單， 一般2d 場景地圖大概滿足要求，在運算單元上可以完成創建和使用。 自動駕駛需要高精地圖， 3維點云，精確到厘米級別，全國地圖。 特點是需要提前采集，需要花費巨大成本用采集車去采集，生成的高精地圖要隨時去更新，消耗大量的存儲，一般要放在云端，自動駕駛車通過高速無線網絡下載當時位置的高精地圖滿足實時決策要求。?

7. 訓練： 運動控制平臺會對地墊，椅子，人有簡單識別要求，實際情況根據工程需要。模型提前可以在服務器端訓練，訓練數據相對不多。 汽車有海量的數據要進行訓練，滿足高可靠性的物體識別任務，要在云端進行訓練。

8. 運動控制平臺的多機協作要求 vs 車聯網方案： 目前運動控制平臺的設計沒有過多考慮多機協作的要求，不過會在以后擴展，應用場景如 多個AGV小車互聯互通共同完成調度任務，是車車通信的一種方式。 車聯網方案是自動駕駛的一條路徑，在百度Apollo框架中并沒有提及。 包含V2V(車車通信），V2I( 車路通信）， V2P（車人通信），完成信息共享后的汽車決策，控制算法。目前通信標準主要是歐美主推的DSRC(專用短程通信）和中國主推的5G標準LTE-V。

后面的章節，會對具體的一些算法和模塊進行一些詳細比較和描述。