當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Openpilot EP1：Openpilot开源项目深度解析

發布時間：2023/12/31 编程问答 42 豆豆

生活随笔收集整理的這篇文章主要介紹了 Openpilot EP1：Openpilot开源项目深度解析小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

0.前言

1.整體介紹

2.系統架構與硬件配置

2.1 系統架構

2.2 硬件配置

3.量產安全規范體系

4.生態體系

5.軟件算法分析

5.2 Supercombo模型

5.3 DMS模型

5.4 Localization算法

5.5 Planner/Controls算法

6.后記

0.前言

目前市場上的已經量產并產品化的車端自動駕駛方案，如特斯拉基于純視覺環視自動駕駛方案，又如Mobileye的True Redundancy方案，即純相機方案 + 雷達與激光雷達方案形成一冗余的自動駕駛方案。這兩種方案對移動平臺的算力要求不容忽視，就Tesla 2021 AI DAY 公布的FSD chip就達到144TOPS，Mobileye面向L4級自動駕駛推出的EyeQ Ultra，其AI算力更是能夠達到176TOPS。雖然兩者在TOPS上面都不是最出彩的，但拼算力的背后，也道出了算法模型復雜度不斷攀升的原因。但是，通過我們PerceptionX的研究，今天想為大家介紹一款經濟實用且性價比超高的自動駕駛外裝產品，來自Comma.ai 的Openpilot，它僅僅用一款樂視手機以及高通驍龍821芯片，搭載openpilot software，就能實現L2+自動駕駛。

感謝PerceptionX 蔡老師這篇文章的大力支持，若有建設性問題，請聯系caizhitian@pjlab.org.cn?。自動駕駛團隊OpenPerceptionX是上海人工智能實驗室的智能駕駛感知團隊，致力于探索前沿的學術界與工業界感知、融合、端到端算法，感興趣同學請聯系小編Hugo maihaoguang@pjlab.org.cn ，我們在招聘！
上海人工智能實驗室坐落于美麗的徐匯濱江，這里即有學術大牛具體指導實習生、剛入職的校招生；也適合工作多年的社招大佬在這里充分展現自己的價值。我們堅信在這里能做出solid impact的工作、對標國際一流實驗室成果。
PS: 未經許可，禁止私自轉載。

1.整體介紹

What is Openpilot?

在探索基于端到端的自動駕駛過程中，一次偶然的機會，我們接觸到了Openpilot這款產品，它是一套比較成熟的面向L2輔助駕駛功能的開源項目，基于端到端模型實現了ACC、LKA、DMS等輔助駕駛功能。目前，已經面向消費者售賣，能夠適配了多種車型，通過簡單的安裝在自己的車上便能夠體驗輔助駕駛功能。

相關鏈接

公司官網：?https://comma.ai/

開源項目：?https://github.com/commaai/openpilot

Demo視頻：https://www.youtube.com/watch?v=XOsa0FsVIsg

Openpilot夜晚效果：https://www.youtube.com/watch?v=aUncj2myFwc

Openpilot vs Tesla Autopilot：https://www.youtube.com/watch?v=YJzvrDBQwOE

第三方評測表現，此為2020年基于消費者使用評價進行統計出來的評測報告。

https://data.consumerreports.org/wp-content/uploads/2020/11/consumer-reports-active-driving-assistance-systems-november-16-2020.pdf

通過以上視頻demo以及第三方評測，可以看出Openpilot整體產品表現還是比較驚艷的，針對這款產品，我們列了一些核心的Keypoints ：

首款開源的基于端到端（Perception to Planning）的輔助駕駛系統
采用自標定模塊，相機安裝簡單
整體算法思路很新奇
- 將感知+規劃放到一個model
- 引入時序信息
- 關注最危險的幾個目標/輸出速度
數據體系/生態體系完善
- 積累了大量數據
- 用戶可以自行上傳數據
- 開源社區共同服務

2.系統架構與硬件配置

2.1 系統架構

整體系統架構如圖所示，可分為四個部分

環境：
- 配置
- 接管
- 物理環境
車機：
- CommaTwo device
- CAN bus
- Panda(連接CAN和CommaTwo的硬件適配器)
- Stock sensors
- Actuators (執行器，例如方向盤steering、油門gas、剎車brake)
Sensors:
- Cameras: 前視和車艙內部兩個攝像頭
- GPS
Software components:
- Infrastructure
- Communication dependencies
- Selfdrive Core
- Radar
- Planner
- Control

2.2 硬件配置

前面架構圖中的CommaTwo device根據樂視手機改裝而來，至于為什么要用樂視手機改裝呢？通過查閱官網資料了解到，由于CommaTwo采用高通驍龍821芯片，支持這款芯片的手機包括樂視3Pro，目前只適配了樂視這款手機的camera接口，如果采用其他型號還需自己去適配camera。下面展示了該設備的具體參數

3.量產安全規范體系

Openpilot作為一款已經量產的輔助駕駛產品，因此每次發版上市都要遵循相關的法律法規，保證功能安全。對于Openpilot而言，整體的安全規范流程如圖所示

從圖中可以看出Openpilot功能生產遵循ISO26262標準，ASIL安全評級、DFMEA(潛在失效模式與效應的分析)、NHTSA（美國國家公路安全管理局）以及FMVSS（美國公路機動車安全標準）標準
- 對于汽車系統，ASIL安全等級劃分為QM、A、B、C、D五個等級，QM代表與安全無關，D等級最高?？紤]因素包括：
  - 嚴重性（Severity of failure，S）：致命傷S3
  - 可能性（Probability of exposure，E）：高可能性E4
  - 可控性（Controllability，E）：難以控制C3
  - Openpilot系統ASIL等級為D=S3 + E4 + C3
Openpilot基于DMS(Driving Monitor System)系統監控駕駛員狀態，遵守FMVSS requirements，同時符合NHTSA發布的標準pertinent documents
關于危險等級（Hazard and Risk Analysis）和FMEA/DFMEA, Openpilot主要符合兩點設計理念
- - 人類駕駛員優先級永遠最高，如果有任何接管，立即退出openpilot
  - 執行器(Actuators）變化不能過快，例如change trajectory需要within reasonable limits.不同車型關于safety module的閾值、case都不太一樣，具體參考?https://github.com/commaai/panda/tree/master/board/safety
在軟件功能生產時嚴格按照編碼規范MISRA C：2012 , 該規范由汽車產業軟件可靠性協會（MISRA）提出的C語言開發標準，其目的是在增進嵌入式系統的安全性及可移植性。 Openpilot 利用Panda Firmware作為codebase，以及cppcheck模塊做代碼規范分析，通過panda的safety model保證安全性
在每次新版本發布之前，都會經對功能的測試以及進行SIL，HIL，VIL三項測試，具體的流程如圖所示。

4.生態體系

下面這幅圖展示了Openpilot的解決自動駕駛問題的設計理念-大道至簡，Openpilot生態體系包括數據體系和開源社區服務，通過積累大量的數據，用于模型訓練部署，循環迭代，并以此對標Tesla。

那么Openpilot是怎么實現他的生態圈，或是數據閉環呢？

開源社區體系

- openpilot：https://github.com/commaai/openpilot?，通過Pull request，添加車輛配置，bug reports ，數據Replay/simulation等功能，用于數據存儲，離線開發
- explorer：https://github.com/commaai/explorer?網頁在線replay功能

數據體系

- Comma10k：https://github.com/commaai/comma10k?，真實場景，10000 png，社區用戶標注，模型訓練
- Comma2k19：https://github.com/commaai/comma2k19，真實場景，comama EONs采集，Pose&Localization
- Selling：https://github.com/commaai/data-sales?，真實場景，comma twos采集數據
- 眾籌數據：https://my.comma.ai/?，用戶將設備數據上傳到服務器，標注用戶數據，用于模型訓練
- challenge比賽：https://github.com/commaai/calib_challenge

Openpilot開源的數據體系包括Comma10k和Comma2k19，其中，Comma10k主要用作像素級分割任務，Comma2k19用于車規控制算法，考慮后續我們基于此數據集進行復現模型，可以持續關注后續更新，這里重點關注Comma2k19這個數據集。

Raw_log

Globalpose from fusion

數據集解析Setup

下載數據解析相關代碼

git clone https://github.com/commaai/comma2k19 git submodule update --init --recursive sudo apt-get install libcurl4-gnutls-dev sudo apt-get install libghc-gnutls-dev pip3 install pycurl cd {PATH}/comma2k19-master && pip3 install -r requirements.txt

解析代碼demo：{PATH}/notebooks

(注：需要添加所需模塊路徑：sys.path.append('{MODULE_PATH}'))

Comma2k19 數據集分 10 個卷，解壓后大約 100G。通過踩坑，可以利用openpilot提供的docker環境，然后將數據集掛載到相應目錄進行解析數據，可以減少環境依賴。若對數據格式感興趣，可以前往Openpilot github

Sample

5.軟件算法分析

前面幾個部分主要從宏觀角度介紹了Openpilot產品性能，系統架構，安全規范體系以及生態體系。對于沒有接觸到Openpilot這款產品的人，可能不太相信在自動駕駛領域這種采用Percetion to Planning的方案能夠work，更神奇的是，它還是一款量產的產品。正所謂撥開云霧才能見天日，帶著這樣的疑問，有必要對Openpilot源碼進行深入分析一波，接下來我們將會細致全面地給大家介紹關鍵模塊，若有想法去調試Openpilot設備的小伙伴請細品。

Camera數據流部分參考代碼版本為version0.8.12
模型分析部分版本參考：Link

Camera底層（kernel）分析

針對camera數據流部分，我們主要關注Openpilot設備中camera采集的圖像如何從從硬件采集到輸出給模型，根據前面硬件設備介紹可知Openpilot設備SOC采用高通的驍龍821，系統采用定制的安卓系統。通過查找源碼發現，如圖所示，camera底層（kernel）基于linux V4L2視頻框和應用層通信，對V4L2具體細節感興趣的可參考https://deepinout.com/v4l2-tutorials/linux-v4l2-architecture.html。

針對高通平臺而言，內核相機驅動在v4l2框架上進行了相應的擴展。首先，創建了一個整體相機控制者的CRM，以節點video0暴露給用戶空間，主要用于管理內核中的Session、Request以及子設備，同時各個子模塊都實現了各自的v4l2_subdev設備，并且以v4l2_subdev節點暴露給用戶空間，暴露子設備的設備節點，在用戶空間直接通過標準的字符設備控制接口來控制各個設備。其次，創建了另一個video1設備節點用于同步數據流，保證用戶空間和內核空間的buffer能夠高效得進行傳遞。

Camera init部分

Init部分主要執行系統初始化，分配視頻幀內存，源碼中預留了4幀數據大小內存

Camera open部分

根據前面分析的視頻框架，V4L2將camera設備節點以設備文件形式映射到用戶空間，打開camera也就是打開對應的設備文件節點

Cameras run

首先，開啟sensor基于i2c通信，發送控制信號，三路camera對應三個線程，當視頻流觸發時，通過poll機制監測road camera對應的文件句柄（video0_fd），執行handle_camera_event處理（圖像幀預處理）

根據以上分析可得camera部分函數調用關系

Cameras_init(wide/road/driver camera)Set camera stateSet camera paramerter（grey_fraction,gain,exposure_time ,etc）Camera buf init(allocate related mem)set vipc_server to cameradallocate 4 frame_sizeget_model_yuv_tranform(do a 2x downsize)vipc_server create buffers for rgb and yuvCameras_open(wide/road/driver camera) Open video0_fd/video1_fdOpen ispQuery icp for MMU handlesRequest msg subscribe from video0_fdCamera_open(wide_cam)Open v4l2 sensor_fdCreate sessoinAccess sensorConfig isp/CSI PHYLink devices:start csiphy/isp/sensror Vipc_server start listen cameras Camera_run(wide/road/driver camera)start thread to process road camera Receive frame_data Fill frame data and yuv transformPublish "roadCameraState" msg including frame dataStart devices by send i2c sinnal to sensorOpen poll events to monitor video stream and callback processSet per frame parameter

總結

前面的分析，在load模型前，camera數據流部分按照系統層級劃分可分為

硬件層：基于高通驍龍821 SOC，前視采用Sony Imx298，Monitor采用ov8865，camera基于 I2C和處理器通信

驅動層：基于高通定制的V4L2視頻框架，最終camera抽象為video文件節點，供用戶層調用

應用層：監測camera數據流變化，通過設備文件讀寫

通信層：源碼中，camera數據流以兩種方式和模型層通信，即Client/Server模式和

Subscriber/Publish模式前者主要用于傳輸圖像數據，后者用于消息節點通信

對應的camera流程圖如圖所示

5.2 Supercombo模型

關于模型分析這部分，我們主要從整體去分析supercombo模型的網絡結構，從宏觀上了解Openpilot模型這部分的工作。實際上一個模型從設計到應用于量產產品中，至少包括兩個部分，

根據設計的模型網絡結構，選取合適的數據集，在服務端進行訓練，

根據訓練的模型文件在設備端部署。

因此，更多深入的細節方面，后續我們會單獨推出兩個系列，重點說明我們在模型復現和模型部署方面的工作。

通過netron將源碼中supercombo.onnx模型文件打開，可以看出，整體模型結構還是比較精簡的，分為Backone，GRU，Head三部分。

Model input

從模型輸入可以看出，網絡圖像Input size: 12, 128(H), 256(W)，格式為YUV420，具體轉換過程

原始輸入三通道RGB（256*512*3），每幀RGB轉換成6通道YUV格式（6*128*256）
取兩個連續幀作為模型輸入，因此，輸入大小為（12*128*256）

Backbone

網絡backbone部分，采用了Google團隊的Efficientnet-B2結構（EfficientNet: Rethinking Model Scaling for Convolutional Neural Networks）。該結構采用復合縮放策略，主要特點是效果好，速度快。卷積部分下采樣5次，為了減少參數量，有幾個conv是采用group conv，激活函數函數采用Elu

GRU部分

網絡同時引入了時序結構（GRU），把歷史信息encode在 h_t中，輸入狀態信息(desire)到模型；輸出Pose, desire_predict, plan, lead(object), lane等信息，經過我們后續模型復現驗證，GRU對整個模型起到了比較重要作用（后續可關注我們的模型復現系列）

Head部分

Head部分主要輸出三部分policy信息，具體地

左側frame policy 出Pose, meta
中間temporal policy 出planning, lead信息
右側temporal policy 出lanes信息

Model output

接下來，我們來分析一下模型輸出數據含義，以及它是如何形成形成輸出的message的。

首先，關于損失函數，模型輸出了自車多個未來軌跡預測，軌跡預測損失函數采用MPH(Multiple Hypothesis Prediction)方法，此處參考?https://github.com/commaai/openpilot/discussions/19535

這里的MPH方法，可以參考Multimodal Trajectory Predictions for Autonomous Driving using Deep Convolutional Networks

文章中方法和MPH類似，這里的multimodal應該指的自車多個未來軌跡預測

整個模型輸出包含自車的plan，lane_lines，road_edge，lead，desire_state，metadata，pose等多個信息，詳細的框架圖如圖所示

網絡輸出到建立消息的過程
- plan的每個group最后一個量表征該plan group的好壞，選擇概率最大的一個作為best plan

lead的每個group最后三個量表征該lead group的好壞，分別對應三個t_offset，對于每個t_offset選擇值最大的一個作為該t_offset下的best lead。
laneline采用x方向的anchor方法，在0-192m設置33個anchor，對應的時間t來自best plan。
對plan處理時采用時間t的anchor方法，在0-10s設置33個anchor

綜合以上分析，我們可以得到一個比較清晰supercombo模型網絡結構框圖，

5.3 DMS模型

模型輸入格式同樣為YUV，大小（6*320*160）
Backbone部分，與supercombo模型類似地，dms模型也采用efficientNet的結構
Head也分成三個部分，分別為face/eye/summary，值得注意的是，eye head中的前面兩個（1,8）結果未放到輸出的msg結果中（猜測可能為之前用，現在已經deprecated的descriptor）

整體的網絡結構如圖所示

DMS算法梳理

Monitor系統僅在接收到driverState時更新driverMonitoringState
carState主要提供driver_engaged信息，在driver未操作情況下，
- 首先，在接收到modelV2時更新pose/blink cfactor，作為判斷distracted的閾值
- 然后，由driverState的結果計算pose/blink，計算歷史所有pose的mean/var
- 最后，計算awareness，給出不同的alerts
controlsd接收driverMonitoringState的events及awarenessStatus結果，當awarenessStatus<0時，control端會給出強制減速指令

算法流程框架圖如圖所示

5.4 Localization算法

首先，介紹一下openpilot坐標系

坐標系具體信息可參考：?https://github.com/commaai/openpilot/tree/master/common/transformations

為便于理解，大致示意圖如下：

view frame為相機坐標系，右方為X軸，下方為Y軸，前方為Z軸，為示意將其放在右側
device frame位于相機坐標處，前方為X軸，右方為Y軸，下方為Z軸
car frame為device frame下方的在road平面上的坐標系
calibrated frame為在相機處的，以car frame的pitch/yaw，device frame的roll組成的坐標系，也為model輸出幀

localizationd模塊部分實現功能

接收模型輸出cameraOdometry進行在線標定，（實際上為device frame-calibrated/car frame之間的轉換關系），此處的標定不考慮roll情況
接收ublox gnss結果
根據gnss、cameraOdometry、imu等傳感器信息通過卡爾曼濾波進行最有狀態估計，得到精確定位
根據定位及carState對car Params進行更新

Calibrationd相關

需滿足條件Straight and fast (25km/h)
Rpy, trans from ModelV2 camera odometry
實際上是較簡單的加權平均，結合有效性判斷
實際上不考慮roll

核心代碼部分

在基本直線運動情況下，根據trans直接計算rpy
rpys保存至多50個rpy，對rpys和new_rpy進行加權平均（共100個）記錄到rpys中，最終rpy結果為前valid_blocks個rpy的均值
在update_status()中，對更新的rpy進行有效性判斷，并在前valid_blocks個rpy差值過大（2 deg）時，重新reset到前一次的rpy結果

Localization

接收gps/gyro/accelerator/vEgo/cameraOdometry/liveCalibration，通過KF得到最終的定位結果
如果event的時間與kf時間差過大，current_time - filter_time > 10時，reset KF到初始狀態
除senseEvents中更新時用sensor帶的timestamp，其余用sm log對應的monoTime；若sensor time與logMonoTime差大于100ms，舍棄該sensor reading
僅在接收到cameraOdometry時發送liveLocationKalman消息

根據以上分析，得到整體的算法流程如圖所示

5.5 Planner/Controls算法

Radard部分作用

首先對RadarData中的點進行track以及Kalman Filter的update，再利用fastcluster算法合并鄰近的track
把modelV2感知模型結果和radar信息融合，具體的融合算法思路
- match_vision_to_cluster()方程中，對模型結果中的lead和clusters，計算d/y/v的laplacian_cdf乘積，選取最大的作為匹配的cluster
- 若有匹配的cluster，則設radar cluster為lead結果；若無則設模型輸出的lead為最終結果
- 在v_ego較小且目標cluster較近（yRel<1.5, dRel<25），如果此時比先前得到的lead結果更近時，override先前結果
- modelV2的第一個lead，get_lead()時設置參數low_speed_override=True，第二個設為False

整體的算法流程圖

Plannerd/Control算法分析

Plannerd中包含兩個方向，即橫向和縱向的plan，兩者互相獨立
Lateral控制會輸入感知模型信息
Longitudinal控制只有radar信息（但是radarState也有融合結果？）
MPC（model predictive control）使用ACADO（Automatic Control and Dynamic Optimization） Toolkit進行解算，MPC核心代碼參考：controls/lib/lateral_planner.py#L180
Longitudinal方向采用PID控制
Lateral方向根據車型，采用不同控制算法，包括PID，LQR，INDI等
車輛的控制信號通過CAN發送給車輛控制器

算法流程圖

6.后記

本文對Openpilot開源項目進行了整體介紹，包括系統架構，硬件配置，安全規范體系，生態體系等。為了更深入的了解它，我們還重點分析了軟件算法，包括camera數據流，感知模型，定位以及規控。后續我們會基于此進行實車評測，看實際功能表現如何，并進行量化性能分析和一些典型場景分析，歡迎持續關注后續更新。

參考

https://github.com/commaai

https://blog.comma.ai/end-to-end-lateral-planning/

https://blog.comma.ai/towards-a-superhuman-driving-agent/

https://desosa.nl/projects/openpilot/2020/03/11/from-vision-to-architecture.html

comma AI - 知乎

comma.openpilot 的規劃控制 - 知乎

comma.openpilot底盤接口及其實現 - 知乎

https://www.its404.com/article/yufeilongyuan/122217990

https://www.thedrive.com/tech/36604/we-tested-openpilot-the-1199-device-that-adds-entry-level-autonomy-to-your-car

https://medium.com/@chengyao.sh

總結

以上是生活随笔為你收集整理的Openpilot EP1：Openpilot开源项目深度解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：文本三剑客之sed命令--文本替换；gr
下一篇：伺服选型计算