【导航业务架构】Autoware和Apollo自动驾驶系统的对比
系列文章目錄
提示：這里可以添加系列文章的所有文章的目錄，目錄需要自己手動添加
TODO:寫完再整理
文章目錄
- 系列文章目錄
- 前言
- 一、Autoware和Apollo自動駕駛系統區別
- 1.硬件系統底層方面
- 2.軟件系統上層方面
- （1）Autoware使用ROS中間件
- （1）優點
- （2）缺點
- （2）Apollo3.5以后的版本使用了自己的CyberRT中間件
- （1）CyberRT的介紹
- （2）CyberRT優點
- （3）CyberRT缺點
- 3.源碼開源程度
- 二、Autoware和Apollo自動駕駛系統的安全程度比較
- 1.Autoware
- （1）行為安全
- （2）功能安全
- （3）碰撞安全性
- （4）操作安全
- 2.Apollo
前言
認知有限，望大家多多包涵，有什么問題也希望能夠與大家多交流，共同成長！在項目和平時的學習中，我對機器人/無人駕駛的決策規劃模塊進行了劃分，當然劃分的方法有很多，我的劃分方式僅供參考
（1）動態障礙物行為預測模塊（Behavior prediction）–結合感知和高精度地圖信息，估計周圍障礙物未來運動狀態
（2）執行機構的軌跡規劃模塊（Trajectory_planning）–執行機構如機器人載體上的機械臂、串行云臺等的運動軌跡規劃
（3）任務決策模塊（Mission_planning）–任務決策模塊比較偏業務層了，處理機器人/無人駕駛的各種任務，主要分為三個方面：車底盤航線業務決策（交規、橫向換道等等）、執行應用機構業務決策（機械臂、人機交互等等）、不同場景的導航方案切換決策（組合導航、融合導航）
（4）前端路徑探索模塊（path_finding）–全局路徑規劃算法難度不算復雜，找到一條可通行的（必須滿足）、考慮動力學的（盡可能滿足）、可以是稀疏的路徑base_waypoints【由于其只考慮了環境幾何信息，往往忽略了無人機本身的運動學與動力學模型。因此，其得到的軌跡往往顯得比較“突兀”，并不適合直接作為無人機的控制指令】
（5）后端軌跡處理模塊（motion_planning）–我主要歸納整理為三個方向：（1）對base_waypoints進行簡單處理及生成方向、（2）對base_waypoints軌跡優化方向【一般是二次優化，這里用的較多的事優化方面的知識】、（3）進行對應功能的replan方向（replan之前的預處理、進入replan的條件、停障replan、避障replan、糾偏replan、換道replan、自動泊車replan、穿過狹窄道路replan等等），這部分內容使用的方法比較專
（6）路徑跟蹤模塊（trajectory_following）–這個模塊就得針對機器人載體了，如無人駕駛使用得阿克曼模型可以采用幾何的pure pursuit純追蹤算法，更好的可以用模型預測控制MPC方法，還有強化學習做的（效果怎樣我就沒驗證過了）；當然也可能事麥克納姆輪車、差速車PID、還有無人機的三維軌跡跟蹤等等
（7）碰撞檢測模塊
（8）集群多機器人規劃模塊
當然，這種劃分方式是我權衡了原理和功能粗略劃分的，在實際產品研發過程中，需要理解了各個算法的功能和定位的基礎上融匯貫通，不能生搬硬套，如全段通過hybrid A探索出來的路徑與A、RRT*探索出來的路徑更平滑，后端軌跡優化的任務就不用這么重了；又如，機器人/無人駕駛項目研發的需求業務還沒發展到能響應很多功能階段，任務決策使用簡單的狀態機（fsm）就可以對現有任務進行狀態轉移了
本文先對Autoware和Apollo自動駕駛系統的對比做個簡單的介紹，具體內容后續再更，其他模塊可以參考去我其他文章
提示：以下是本篇文章正文內容
一、Autoware和Apollo自動駕駛系統區別
1.硬件系統底層方面
（1）Apollo推薦64位x86指令集的CPU加英偉達GPU架構
（2）Autoware主要使用英偉達的AGX Xavier或PX2，也就是推薦ARM的V8指令集架構CPU。當然，也支持64位x86指令集的CPU加英偉達GPU架構
.
.
.
2.軟件系統上層方面
相比，Apollo的框架更加豐富和復雜
（1）Autoware使用ROS中間件
（1）優點
Ros作為世界上最豐富的機器人操作系統，積累了大量的經驗，避免了開發者重復的開發工作，提高了開發效率
（2）缺點
由于Linux是一個極其開放的開發環境，內核調度器對于算法業務邏輯并不清晰，只能保證公平的分配資源。所以，ROS Node運行順序并無任何邏輯。【防盜標記–盒子君hzj】但本質上自動駕駛是一個專用系統，任務應按照一定的業務邏輯執行
ROS是針對機器人整個領域的，不是針對無人駕駛車的
.
.
.
（2）Apollo3.5以后的版本使用了自己的CyberRT中間件
（1）CyberRT的介紹
CyberRT從下到上依次的層
（1）基礎庫：高性能，無鎖隊列；
（2）通信層：Publish/Subscribe機制，Service/Client機制，服務自發現，自適應的通信機制（共享內存、Socket、進程內）；
（3）數據層：數據緩存與融合。多路傳感器之間數據需要融合，而且算法可能需要緩存一定的數據。比如典型的仿真應用，不同算法模塊之間需要有一個數據橋梁，數據層起到了這個模塊間通信的橋梁的作用；
（4）計算層：計算模型，任務以及任務調度；
.
.
（2）CyberRT優點
（1）沒有調度，無算法運算邏輯，為了解決這個不足Cyber RT 的核心設計將調度、任務從內核空間搬到了用戶空間。調度可以和算法業務邏輯緊密結合。之所以能這么做，主要是“協程”的運用。線程分為內核態線程和用戶態線程，用戶態線程需要綁定內核態線程，CPU并不能感知用戶態線程的存在，它只知道它在運行1個線程，這個線程實際是內核態線程。用戶態線程實際還有個名字叫協程（co-routine），為了便于區分，我們使用協程指用戶態線程，使用線程指內核態線程。協程跟線程是有區別的，線程由CPU調度是搶占式的，協程由用戶態調度是協作式的，【防盜標記–盒子君hzj】一個協程讓出CPU后，才執行下一個協程
（2）相比Ros，CyberRT增加了Component組件，組件之間通過 Cyber channel 通信。Cyber RT 中用Message實現模塊間通信，其實現基于 protobuf。同時，CyberRT也支持異步計算任務，優化線程使用與系統資源分配，同時支持定義模塊拓撲結構的配置文件
（3）CyberRT缺點
CyberRT也存在用戶經驗少的短板，同時資源也沒有Ros全面
3.源碼開源程度
Autoware的代碼完全開源,Apollo的代碼還處于非完全開源狀態
二、Autoware和Apollo自動駕駛系統的安全程度比較
1.Autoware
Autoware自動駕駛安全包括行為安全、功能安全、碰撞安全、操作安全和非碰撞安全。每一個領域都需要各種測試方法的組合，這些測試方法可以讓我們驗證全自動駕駛汽車的安全性
（1）行為安全
行為安全是指車輛在道路上的行駛決策和行為。正如人類駕駛員，自動駕駛車輛也要遵守交通規則，必須在各種情況下安全地導航——無論是預料中的還是意外的。【防盜標記–盒子君hzj】autoware運用功能分析、仿真工具和道路駕駛，以充分了解在我們的業務設計領域提出的挑戰，并制定安全要求和多管齊下的測試和驗證過程
（2）功能安全
功能安全旨在確保我們的車輛安全運行，即使有系統缺陷或故障。這意味著要建立備份系統和冗余機制來處理意外情況。例如，我們所有的自動駕駛車輛都配備了第二臺計算機——在主計算機出現故障時可立刻接管車輛，使車輛安全停車（即最小風險條件）。我們的每一輛車都有備用轉向和制動，整個系統還有其他許多冗功能。
（3）碰撞安全性
碰撞安全性，即耐撞性，是指車輛通過各種措施保護車內乘客的能力，從保護車內人員的結構設計到具有座椅約束和安全氣囊的功能，以減輕傷害或防止死亡。【防盜標記–盒子君hzj】碰撞安全性是由美國聯邦機動車輛安全標準（FMVSS）定義的，由美國國家公路交通安全管理局（NHTSA）發布。汽車廠商必須證明他們的基礎車模型滿足FMVSS要求。
（4）操作安全
操作安全是指我們的車輛和乘客之間的互動。有了操作上的安全，我們可以確保消費者在自動駕駛車輛中擁有安全舒適的體驗。
我們建立安全產品的方法是通過危險分析、現有安全標準、廣泛測試和各種行業的最佳實踐而得知的。例如，通過我們早期的乘坐項目（在4節中進一步介紹），我們已經開發和測試了一種能使乘客可以清楚地表明目的地，指揮車輛靠邊停車，并聯系autoware的用戶界面
2.Apollo
Apollo的自動駕駛安全包含安全設計和安全運行兩大主要內容，【防盜標記–盒子君hzj】其中細分為操作安全、環境安全、行為安全、功能安全、質量安全、機制安全和安全進化七大內容。
綜合來看，阿波羅的勢力最強，合作伙伴最多，但車規方面和嵌入式系統方面考慮還不夠。Autoware考慮嵌入式系統最多，車規方面較少，雙方各有優缺點
總結
以上是生活随笔為你收集整理的【导航业务架构】Autoware和Apollo自动驾驶系统的对比的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 向日葵RCE
- 下一篇： Clinet dose not supp