一、中件間系統概述
簡述
在無人駕駛與機器人領域，演算法，一直都是研究的核心。無論是導航技術、控制技術，還是識別技術都是構成其技術棧的重要組成部分。但是，隨著技術的發展，開發者們逐漸認識到一個問題，即程式本身的組織架構與實效性，也對系統的正確性與精度產生了極大的影響。低延時、高負載能力、高易用性等等資料傳輸的質量與效能指標，也逐漸為工程師們所重視起來。這使得中介軟體與架構設計的重要性，逐漸凸顯出來。目前國內主要分為兩類方案：一類是基於既存的開源中介軟體進行開發；另一類則是自己研發或是基於開源中介軟體二次研發中介軟體。
開源中介軟體
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. 支援分散式
極特殊情況下，我們可能要支援多板系統，這時就要支援分散式了。分散式系統對系統實現方式就有了一定的限制，跨板情況下無法採用共享記憶體等較高效的方式實現。但整體狀態與普通多程式相似，只是更加複雜而已。
總結
總之，無論採用開源系統還是自研系統，都應根據專案的實際情況程式中介軟體的規模選擇與配置。能採用執行緒通訊的，就不要採用程式通訊，能單板完成的，就不要採用分散式系統。儘量減少系統的不必要開銷才是保障實時性和穩定性的根本。