一、中件間系統概述
簡述
在無人駕駛與機器人領域，算法，一直都是研究的核心。無論是導航技術、控制技術，還是識別技術都是構成其技術棧的重要組成部分。但是，隨着技術的發展，開發者們逐漸認識到一個問題，即程序本身的組織架構與實效性，也對系統的正確性與精度產生了極大的影響。低延時、高負載能力、高易用性等等數據傳輸的質量與性能指標，也逐漸為工程師們所重視起來。這使得中間件與架構設計的重要性，逐漸凸顯出來。目前國內主要分為兩類方案：一類是基於既存的開源中間件進行開發；另一類則是自己研發或是基於開源中間件二次研發中間件。
開源中間件
1.ROS
ROS系統是機器人領域最經典的中間件通信框架之一。目前流行的主要開源算法幾乎都在ROS上有功能包的實現，如gmapping、teb local planner等等。ROS系統的一大優越性，即是其完備的配套工具。它提供了一個未完成的系統調試時需要的幾乎全部的功能，並且完美支持分布式訪問。它作為出現較早的機器人領域的主要框架，幾乎被應用於各種機器人的研發。而早期的無人駕駛，甚至當前國內部分廠商的低速系統，仍在使用此系統。
由於這個系統最初是為實驗性研究所建立的，更注重的是通用性和適應性。所以在性能方面就有所欠缺了。基於xmlrpc的service調用功能速度實在不怎么樣，而由於缺少Qos機制，topic的穩定性與質量也難以保證。並且運行時要依賴roscore，一旦roscore出現問題就會造成較大的系統災難。其安裝與運行體積又較大，對很多低資源系統會造成負擔。
所以從目前來看，ROS適用對穩定性要求較低的，對實時性要求較低的項目，即一些demo型項目和危險性不大的低速系統項目。
2.ROS2
由於ROS具有如此多的問題，ROS2便逐漸被提起和研發出來。ROS2與ROS不同，它底層主要是基於DDS進行數據傳輸。DDS是基於RTPS的去中心化的通信框架，這就去除了對roscore的依賴，使得系統的穩定性及對資源的消耗得到了降低。並且，ROS2提供了Qos機制，對通信的實時性、完整性、歷史追溯等功能有了支持。大幅加強了框架功能，避免了在ROS上出現的高速系統難以適用等問題。
有優點也不可避免的就會有缺點。首先就是生態，由於ROS已流行多年，其生態具有較高的廣度。而ROS2，雖然目標如Navigation Stack等功能包也已向其移植，但整體的生態還是較差。並且ROS2的Qos配置較為復雜，不是十分熟悉的人很容易出錯。所以此系統目前主要為國外一些相關專業的大學或實驗室所使用，資料稀缺。國內行業內僅有極少數公司在嘗試。
所以理論上來說ROS2可以用於任何算力和其他硬件資源能夠承載其的平台。但由於生態問題，導致只被少數人所推崇。
3.Apollo
Apollo是百度所開發的一款類ROS無人駕駛系統。在早期版本（v3.1前）中，Apollo其實是基於ROS開發的一個二級系統，底層通信還是ROS，只是包裹成了Apollo App的形式。但是在ROS的弊端逐漸被認識到后，百度開始對核心進行改進，對其進行優化。其所做的主要工具其實與ROS2類似，即去中心化，並且通過如內存映射技術等內核技術進行速度優化。目前百度已將其應用在自家生產的各種系統上。
其相對於其他系統的一大優勢是，專為無人架駛設計。這一點與ROS最初主要為機器人設計是不同的，所以Apollo系統從一開始就主攻高精地圖技術，並以此為整個導航系統的高質基礎保障。在配以深度網絡的識別能力、prediction演算的預測能力、gps/lidar/radar等多傳感器的綜合定位能力、橫縱控制器等的眾多功能，實現了一個較精細全面和功能強大的導航能力。僅在無人駕駛這一塊，Apollo具有天然優勢。
而與之相對的，太過強大的能力自然也就帶來了麻煩。由於高度依賴高精地圖，使得Apollo系統難以簡單使用。而各種方面演算對硬件平台的算力要求也極大。故此系統僅適用於較復雜場景下的大中型車使用。如玩具車、掃地車、快遞車等較小型低速車並不是十分適合。
開源通信框架
除過使用完整的開源中間件系統，其實一些開源通信框架也可以用來進行無人駕駛與機器人的開發。這些通信框架通常都是面向數據的，即基於topic的架構。
1. Fast-RTPS/OpenDDS
之所以將這兩種框架放在一起，是因為它們具有一定的相似性。它們都是基於RTPS實現的面向數據通信框架，遵循的是同一的標准。這類框架的特別是去中心化，支持Qos機制，支持實時通信。通常會綁定如protobuf等序列化工具。功能強大，但使用麻煩，比較適合對實時性要求較高的項目和大型項目。這兩種框架都可以在github上找到它們的源碼。
Fast-RTPS: https://github.com/eProsima/Fast-DDS
OpenDDS: https://github.com/objectcomputing/OpenDDS
2. MQTT
MQTT通常用於物聯網技術。但實際上它對於低速車領域也同樣適用。它體積極小，並提供了簡單的Qos保證，非常適合玩具車，掃地車等功能簡單、硬件資源有限的項目。但由於對延時控制等方面功能較差，不適用於高速項目和大型項目。
MQTT的一個實現mosquitto: https://github.com/eclipse/mosquitto
自研系統
由於開源系統較復雜且對系統要求較高，很多廠商選擇自行研發中間件系統。因為這樣在提供系統掌控性的同時，也可以作為產品的一個亮點進行宣傳。自研系統的話，通常分為幾個層級：
1. 僅支持多線程
對於很多小型車或機器人項目，其實整個系統只有一塊核心板，系統所分的模塊也並不是很多，那么就完全沒必要去支持進程間通信。所以只完成一個小型的線程間通信框架即可。而面向數據的通信模式目前已經成為無人駕駛與機器人領域的主流，故對於這種情況，通常是實現一個支持publish/subscribe和service/call的線程通信框架。實現時，可考慮幾種方式，分別是針對不同的開發人員架構：
1）集成組-算法組架構
此種架構下，算法組人員只負責實現某一算法，封裝為lib庫，提供為集成組人員使用。算法組人員非必要情況下不直接參與系統的整體調試，所以實機調試工作都由集成組人員負責。故算法組人員對中間件系統並不敏感，只有集成組人員才與中間件接觸。此時集成組人員是整個系統應用的核心研發人員，如果開發線程通信的中間件系統，應當對各模塊回調線程等進行管理與維護，故需要開發本身支持消息隊列與線程回調的框架，以便掌握整個系統的運行。
2）集成組-模塊組架構
此種架構下，模塊組成員是主要角色，他們不僅要負責某一功能模塊算法的實現，還要深入的參與到本組模塊與其他組模塊的對接調試工作。而集成組人員則主要負責提供統一的數據對接途徑，保證整體應用系統與操作系統的協調等。在功能調試上，集成組人員更多的是協助工作，而非主導。此時由於集成組人員並不負責系統的應用功能部分，而是由各模塊組協調負責，故集成組不應對功能性線程等進程維護。那么，僅提供面向數據的無隊列消息通信框架即可。不應由中間通信造成過多的額外性能開銷，力求最簡。更多的系統狀態功能交由各模塊組自己負責。
2. 支持多進程/多線程
當由於系統需要，不得不將應用切分為多個進程時，則需要開發同時支持多線程與多進程通信的框架。通常此種框架應具有的功能為：提供publish/subscribe和service/call，並且，能夠根據訂閱對象對通信進行優化：當訂閱對象在同一進程內時，采用線程間傳輸模式；當訂閱對象在不同進程時，采用進程間通信模式。這種框架較僅支持線程的框架就要復雜了很多，因為要考慮性能開鎖、實時性、穩定性等諸多問題。由於具有跨進程特性，所以系統必須帶有消息隊列功能。這種框架通常要一個組來單獨負責，即中間件組專注負責其開發，而不再是由集成組兼職提供。而采用的架構一般是中間件組-算法組-集成組或中間件組-模塊組-集成組。
3. 支持分布式
極特殊情況下，我們可能要支持多板系統，這時就要支持分布式了。分布式系統對系統實現方式就有了一定的限制，跨板情況下無法采用共享內存等較高效的方式實現。但整體狀態與普通多進程相似，只是更加復雜而已。
總結
總之，無論采用開源系統還是自研系統，都應根據項目的實際情況進程中間件的規模選擇與配置。能采用線程通信的，就不要采用進程通信，能單板完成的，就不要采用分布式系統。盡量減少系統的不必要開銷才是保障實時性和穩定性的根本。