筆者之前參與過基於 ROS1 的機器人開發， 但是如大多數創業公司一樣， 這些系統也都僅僅限於demo 階段。失敗的原因一方面是市場的因素， 一方面也是當前的機器人系統並不成熟， 開發者必須在及其有限的資源下 板載 CPU，內存等資源開發一個感知決策系統，但在當前 ROS1 的狀況下總是無法做到穩定，接下來是我的討論，歡迎大家評論中留言。
自動駕駛系統中的數據量越來越大
自動駕駛中用到的傳感器很多，每種都有自己的劣勢，但也都存在自己的盲區。
- 3D 激光雷達， 只能對三維空間進行稀疏的採樣， 線束越多采樣點越密集但數據量也加大， 對玻璃無效
- 2D 激光雷達， 只能探測水平面的物體， 無法感知立體，對玻璃等透明物體無效
- RGB 攝像頭， 空間感知較差，但紋理豐富，能夠對近距離物體實現 分類和識別（機器學習算法), 遠距離無效
- odom 輪式里程計， 誤差較大
- IMU 慣性測量單元，累計誤差較大。
目前的趨勢是3D激光線束越來越密集了，探測距離也越來越遠，但是數據量也爆炸式的上升， 海量的數據處理對於一個實時操作系統是一個很現實的問題。但這也是目前 魯棒性較高的方式之一。【 所以稠密點雲處理是方向之一？】
所以如此龐大的數據量，需要實時的處理，對系統處理能力和穩定性 要求很高 , 好奇當前成熟的自動駕駛系統處理如此龐大數據量的策略。
ROS1 的缺點
- ROS因爲將功能分佈在各個節點之中，節點間基於消息機制通信，通訊部分消耗了很多系統資源。尤其是當所有節點位於同一個處理器時，ROS仍然一直執行相應的消息分發，節點間的數據傳遞通過內存複製，大量的系統資源都浪費在通訊上，使得系統必須選用高性能的處理器和存儲系統以彌補損耗。換句話說，利用ROS來實現SLAM，需要配備性能優越的硬件設備，這對於一些小型化嵌入式平臺，尤其是實際的機器人產品裏，其對計算資源、存儲空間的消耗會使成本大幅上升。
- 軟硬件數據量過載，由於ROS1 有一個核心的master 節點，如果崩潰後如何修復，以及各個模塊如何有效的溝通。
ROS2 - 基於DDS 的消息分發機制
- 系統可靠性 -> 去中心化
- 系統通信性能提升 -> memory-map 機制
- 資源管理和安全 -> 節點劃入 Linux Container 中,節點間相互隔離；信息加密防止被劫持
什麼是 DDS（Data Distribution Service）
- DDS（Data Distribution Service）是基於以數據爲核心的設計思想提出的，定義了描述網絡環境下數據內容/交互行爲和服務質量要求的標準技術
- DDS (數據分發服務) 工業級別中間件，通信節點動態發現，用shared memory 方式使得通信效率邊高
- DDS 使所有節點的通信拓撲結構都依賴於P2P 自我發現模式，無master 中心節點，
- 在該模型下分佈式節點在網絡上以發佈或訂閱的方式傳輸數據，節點可以是發佈者或訂閱者，或者既是發佈者又是訂閱者。
- 網絡中的數據對象用主題((Topic)做標識，分佈式節點在全局數據空間中發佈或訂閱感興趣的主題信息。
- 各個節點在邏輯上無主從關係，點與點之間都是對等關係.通信方式可以是點對點、點對多、多對多等，在QoS的控制下建立連接，自動發現和配置網絡參數
DDS 缺點：
- DDS 本身的資源消耗
- DDS 接口複雜
DDS組成模型
-
DDS內所有的成員都是Entity，DDS中的任兩個Entity（實體角色）通信都必須在同一個Domain 內進行交互，即他們初始化時DomainID是同一個，並且不同Domain的DomainID必須唯一。Domain內的DomainParticipant是服務的入口點，任何DDS應用都需首先獲取DomainParticipant，然後通過Domain Participant獲取其他服務，如Publisher、Subscriber、Topic等。
- 服務質量策略(QoS)。DDS規範定義了豐富的服務質量策略(Quality of Services Policies)，QoS是一種網絡傳輸策略，應用程序指定所需要的網絡傳輸質量行爲，QoS服務實現這種行爲要求，儘可能地滿足客戶對通信質量的需求，DDS定義QoS策略使其對複雜網絡環境的適應性和魯棒性大大增強，優化網絡傳輸質量。QoS可以理解爲數據提供者和接收者之間的合約。
- 服務質量策略(QoS)。DDS規範定義了豐富的服務質量策略(Quality of Services Policies)，QoS是一種網絡傳輸策略，應用程序指定所需要的網絡傳輸質量行爲，QoS服務實現這種行爲要求，儘可能地滿足客戶對通信質量的需求，DDS定義QoS策略使其對複雜網絡環境的適應性和魯棒性大大增強，優化網絡傳輸質量。QoS可以理解爲數據提供者和接收者之間的合約。- 參與者（Domain Participant）：一個參與者Participant就是一個容器，對應於一個使用DDS的用戶，任何DDS的用戶都必須通過Participant來訪問全局數據空間。
- 發佈者（Publisher）：數據發佈的執行者，支持多種數據類型的發佈，可以與多個數據寫入器（DataWriter）相聯，發佈一種或多種主題（Topic）的消息。
- 訂閱者（Subscriber）：數據訂閱的執行者，支持多種數據類型的訂閱，可以與多個數據讀取器（DataReader）相聯，訂閱一種或多種主題（Topic）的消息。
- 數據寫入器（DataWriter）：應用向發佈者更新數據的對象，每個數據寫入器對應一個特定的Topic，類似於ROS1中的一個消息發佈者。
- 數據讀取器（DataReader）：應用從訂閱者讀取數據的對象，每個數據讀取器對應一個特定的Topic，類似於ROS1中的一個消息訂閱者。
- 主題（Topic）：這個和ROS1中的Topic概念一致，一個Topic包含一個名稱和一種數據結構。
- QoS Policy：Quality of Service，質量服務原則，這個模塊在ROS1中可從沒見過，看名稱就猜測應該是負責數據質量的。QoS是DDS中非常重要的一環，控制了各方面與底層的通訊機制，主要從時間限制、可靠性、持續性、歷史記錄幾個方面，滿足用戶針對不同場景的數據應用需求，可以參考下邊的圖片和表格，看一下這幾個原則可以哪些配置
ROS2 VS ROS1
- 實時性增強：數據必須在deadline之前完成更新。
- 持續性增強：ROS1儘管存在數據隊列的概念，但是還有很大的侷限，訂閱者無法接收到加入網絡之前的數據；DDS可以爲ROS提供數據歷史的服務，就算新加入的節點，也可以獲取發佈的所有歷史數據。
- 可靠性增強：通過DDS配置可靠性原則，用戶可以根據需求選擇性能模式（BEST_EFFORT）或者穩定模式（RELIABLE）。
ROS 的 進展
最後我們來看看 ROS2 走到哪一步了， 還有活着嗎？ 未來在哪裏？
ROS2 發行版本歷史
| 版本名 | 發行時間 | 特點 |
|---|---|---|
| Eloquent Elusor | Nov 22nd, 2019 | |
| Dashing Diademata | May 31st, 2019 | |
| Crystal Clemmys | December 14th, 2018 | |
| Bouncy Bolson | July 2nd, 2018 | |
| Ardent Apalone | December 8th, 2017 | |
| beta3 | September 13th, 2017 | |
| beta2 | July 5th, 2017 | |
| beta1 | December 19th, 2016 | |
| alpha1 - alpha8 | August 31th, 2015 |
計劃中的版本
| Distro | Release date | Supported for | Planned changes |
|---|---|---|---|
| Foxy Fitzroy | May 2020 | 3+ years | Target Ubuntu 20.04 |
| G-turtle | May 2021 ? |
- 可以看出每年都會有一個新的版本計劃
ROS2 究竟解決了哪些痛點，辦到了那些ROS1 不能辦到的事情？
【TO DO】
思考
- 目前深度學習和各種算法對於這樣的系統感覺像一個資源黑洞，有效的利用 GPU 和 FPGA 加快運算是很重要的
- 當前正在使用的 自動駕駛系統 Waymo 和 百度的系統不知道如何處理這些問題，如何和環境感知，如何使用生產環境下的 深度學習算法， 畢竟論文和實際應用還有着很長的距離。
- 自動駕駛從最初的 2020是自動駕駛元年， 到五年內實現，到現在有些人覺得19年內難以實現，都是有原因的。 作爲科研方向，不知道怎麼水論文了