|
機器人操作系統（RobotOperating System, ROS）是一個專門為機器人應用而設計的，被廣泛使用的高性能分布式的計算框架（參見下圖是一個典型機器人操作系統）。 每個機器人所要完成的任務（如自身定位）都由一個ROS的子節(jié)點處理。這些節(jié)點間是通過話題和服務進行相互連接的。它對于自主駕駛而言是一個合適的操作系統，但也有一些問題： · 可靠性：ROS只有一個主節(jié)點而且對子節(jié)點沒有監(jiān)控，從而無法實現失效恢復。 · 性能：在發(fā)送廣播消息的時候，ROS會把消息復制多份，這就導致性能的降低。 · 安全性：ROS沒有認證和加密的機制。 雖然ROS 2.0版宣稱要修復這些問題，但它還沒有被廣泛的測試過，并且很多特性也沒有實現。為了在自主駕駛車輛上使用ROS，我們需要先解決這幾個問題。 現有版本的ROS的實現僅有一個主節(jié)點。因此當主節(jié)點崩潰時，整個系統就崩潰了。這一點并不能滿足自主駕駛的安全性要求。為了解決這一問題，我們在ROS上實現了一個類似ZooKeeper的機制。 如下圖所示，就是在ROS上使用ZooKeeper的示意圖。 這個設計包含一個主節(jié)點和一個備份主節(jié)點。當主節(jié)點失效時，備份節(jié)點就接替主節(jié)點，并確保系統能持續(xù)運行無間斷。另外，ZooKeeper的機制還可以監(jiān)控所有節(jié)點，并在節(jié)點失效時重啟它們。從而可以確保整個系統的可靠性。 性能問題是現有ROS實現的另外一個缺陷。ROS節(jié)點間通信很頻繁，因此節(jié)點之間的通信就必須是非常高效的。首先，ROS客戶端節(jié)點間的通信采用的是環(huán)回機制。每完成一次環(huán)回的管道，就會帶來約20毫秒的開銷。為了降低這個節(jié)點間通信的開銷，我們可以使用共享內存的機制來避免消息傳輸必須經過TCP/IP的打包/拆包的過程。另外，ROS的節(jié)點在廣播消息的時候，消息會被復制多次，極大地占用了系統帶寬。改用多點傳送機制就能夠很好地提升系統吞吐量。 而安全性問題，更是ROS的最大的死穴。設想兩個場景：第一個，某個ROS的節(jié)點被“黑”了，隨后操作系統內存被持續(xù)的占用并最終導致內存溢出，從而開始殺掉其他的ROS的節(jié)點。最終黑客成功地讓整個系統崩潰。第二個場景，ROS的消息默認是不加密的。黑客可以很容易地監(jiān)聽節(jié)點間的通信，然后使用消息攔截機制發(fā)動攻擊。 為了解決第一個安全問題，我們可以使用Linux容器機制（LXC）來限制每個節(jié)點可以使用的資源數量，并提供沙箱機制來防止一個節(jié)點被其他節(jié)點破壞。這樣可以有效地防止資源溢出。對于第二個問題，可以通過加密消息來阻止消息被竊聽。 因此我們首先會在模擬器上測試新算法，例如在ROS節(jié)點上做數據重現。然而，如果只是在一個單機上測試新算法，要不會花費很長時間，要不就沒有能做到全覆蓋測試。 為了解決這個問題，我們可以使用一個分布式的模擬平臺，如下圖所示是Spark和基于ROS的模擬平臺。 這里，Spark被用于管理分布式計算節(jié)點。每個節(jié)點上，我們可以運行一個ROS再播放實例。在一個單機服務器上做自動駕駛物體識別測試將會需要3個多小時。而使用分布式系統，水平擴展到8個服務器，整個測試在25分鐘內完成。 如下圖所示是一個基于云平臺的高清晰度地圖生成。高清晰度地圖的生成是一個復雜的過程，涉及到很多步驟。包括原始數據處理，點云生成，點云對齊，2維反射地圖生成，高精度地圖標記以及最終地圖生成。使用Spark，我們可以把所有的這些步驟放入一個任務中完成。Spark的一大優(yōu)點是它提供基于內存的運算機制。這樣我們就可以不用存儲中間數據到硬盤上，從而可以級大地提升地圖生成的速度。 因為我們?yōu)樽灾黢{駛使用了多種不同的深度學習模型，所以持續(xù)更新模型來保證它們的有效性和高效性就非常重要。然而，由于原始數據的量非常的大，僅僅靠單機是很難快速地完成模型的訓練的。為了解決這個問題，我們使用Spark和Paddle（最近由百度開源的一個深度學習平臺）開發(fā)了一個高可擴展的分布式深度學習系統。 在Spark驅動程序里，它可以管理Spark Context和PaddleContext。在每個節(jié)點里，Spark執(zhí)行器容納了一個Paddle的訓練實例。在此架構之上，我們使用Alluxio作為這個系統的參數服務器。使用這一系統，我們可以實現線性的性能擴展（甚至在增加了更多資源后），從而證明它是高可擴展的。 關于自動駕駛的技術文章，可以參考前文，下面是鏈接： |
|
|
