2022/02/16 comma ai如期釋出openpilot 0.8.13，我們來看看有什麼更新內容吧～
Version 0.8.13 (2022-02-18)
=======================
-增強駕駛監控
--重新調整駕駛姿勢的學習得以使用輕鬆的駕駛姿勢
--增加駕駛模式的信賴度能適應更多場景
--更嚴謹的對應comma two與comma three
-補償道路傾斜角度，提高轉彎時的性能
-增強comma two的對焦能力
-AGNOS 4
--支援ADB
--增強對有無電池的自動配置能力
-NEOS 19
--套件升級
--提升穩定性
此外comma ai的blog也更新了0.8.13的博客內容(https://blog.comma.ai/0813release/)
這個版本對於可靠度與穩定性有很大的提升
信賴度與穩定性
Openpilot 1.0的其中一個目標是達到1000小時的MTBF（平均故障間隔時間）。在符合ISO26262 Level2 ADAS的標準下，Openpilot的禁用狀態分為軟禁用與立即禁用。軟禁用像是安全帶鬆脫，系統會警告三秒後若無恢復就會中斷Openpilot。而立即禁用則是像是突發性的資料延遲導致分析不一致的時候，會立即禁止使用Openpilot，Comma ai針對立即禁用做了研究並修正了先前版本的錯誤。
MTBF報告
Comma提供它們的數據，目標是總體MTBF超過1000小時。大多數軟禁用狀態沒有導致脫離或強制解除事件，不過Comma仍然有修正軟禁用的狀態。
修正
Comma說對於MTBF的些證結果非常滿意。在0813版本中，修正了所有的立即禁用，同時也修正大部分的軟禁用。Comma將繼續使用這樣的報告來提高MTBF，預計很快也能修正那些幾千小時之後才發生的錯誤。
立即禁用
canError其實是OP使用者系統不穩定時會遇到的狀況，造成canError的原因非常多。主要分為兩類，一類是Boardd的運行過程延遲或是連接線的接觸不良導致資訊中斷。現在分成兩種事件，以後會更好分析與追蹤。（#23362）
其它的事件通常是汽車移植的臭蟲，是由於panda和openpilot在汽車的狀態不一致而引起。當panda和openpilot意見不一致時，panda為了安全性會阻擋openpilot發給汽車訊息。如果信息被阻斷的時間過長，汽車上接收這些信息的ECU電腦就會出現故障與引發跳錯。如果ECU發生故障碼時，就會觸發像是brakeUnavailable或steerUnavailable的事件，否則openpilot就會出現內部controlsMismatch的錯誤導致禁用。具體的修正方法在此。
軟禁用
vehiceModelInvalid是至今為止最常見的事件，comma估計在這版已經修正了九成。詳見後述paramsd修正。 radarFault與上面的canError類似，但主要是雷達CAN的連接失敗。deviceFalling事件大多是誤報，所以comma目前禁用了設備檢測器，直到它能被改進才會恢復。
駕駛監控的改進
現在駕駛監控中的姿勢偵測的俯仰和座椅偏離狀態被獨立處理。在0812中，如果駕駛在開車的前幾分鐘以不尋常的姿勢開車，司機姿勢很容易誤判導致過鬆或過嚴。0813這版的姿勢學習器增加了上限和下限值，它現在可以應對那些極端的初始狀態。
圖.駕駛姿勢與剎車預測有更顯著的關聯性
根據comma的研究，在不同速度下，駕駛姿勢與駕駛模型預測是否應該剎車之間有很強的關聯性。所以駕駛監控也導入車輛速度來調整監控政策。(我個人認為應該是速度放慢時，駕駛監控會略為寬鬆)
滾動補償
橫向MPC給了OP一個汽車在某瞬間需要達到的實際曲度，而這個曲度透過模型轉化為轉向角。Comma目前使用的是一個單軌車輛模型，它包含質量、重心位置、輪胎硬度和轉向比。除了這些因素外，OP還學習了paramsd中慢速與快速的角度偏移，來處理單軌車輛模型無法解釋對曲度影響的所有情況。
圖、加入滾動補償道車輛模型當中
所以，理論上0813對於入彎出彎會有更精緻的駕駛體驗。Comma表示"過彎偏離規畫路徑"，是衡量過彎削減程度的指標。在0813的版本，左轉和右轉的平均和標準偏差都減少了近一半。
另一個有趣的事情是，左轉和右轉的平均偏差是反向的。這是因為過彎道路設計的傾斜，是為了避免輪胎因離心力過大導致車輛打滑。但是0813已經針對這樣的傾斜常規，做出更精確的過彎駕駛操控。
圖、0.8.12與0.8.13對於道路偏離的程度。
paramsd修正
先前一段有提過，近九成的vehicleModelInvalid錯誤是由steerRatio或stiffnessFactor超出可接受範圍引起的。通常發生在長時間直線行駛，由於沒有關於steerRatio或stiffnessFactor的有效資訊，標準差會因為變異不斷累積而增加，直到轉彎又再重新校正。在0813版本中(下圖)，會根據觀察前值來約束標準差，這使得系統與參數穩定性更高。此外，轉向角度已經能適應轉向角度本身的雜音，因此Prius現在的最小轉向角度可以到0.1度。(Prius車主應該會有全新的感受，過彎明顯增加穩定性，這個是很厲害的修正。)
圖、在長直線道路上paramsd的模擬狀態
Comma two的對焦改進
Comma two的相機模組不是定焦鏡頭(與comma 3不同)，需要移動焦距找到適當的對焦點。然而車子的加速度也會作用在鏡頭對焦模組上，使得鏡頭偏離而導致移焦。所以0813針對這個作用力做出補償，在不同加速度下會有不同的對焦補償。透過camerd計算並比較qlog的畫質清晰度，我們得到不同加速度下的稅度圖。在以前加速度越大會導致銳利度下降，現在導入補償之後，加速度對畫值的相關性幾乎完全消失。
圖、comma two在0812與0813的加速度與畫質銳利度的關係圖
NEOS 19
這次NEOS19對comma two提高了穩定性。comma修正了Android的NetworkPolicy服務中一個罕見的bug，它導致出現Zygote事件，Android核心保護程序而重新啟動。(當Zygote重啟時，openpilot保持運行，但openpilot的UI界面被啟動動畫覆蓋，原本OP核心的Android服務重啟。從使用者的角度來看，看起來像是一次自發性重啟，但實際上，openpilot仍然在運行。)此外，這版還更新了所有的Python套件包。
AGNOS 4
這次對comma three的更新主要是為未來的功能做準備。增加了casync，可以大幅減少未來AGNOS更新時的下載量。GSM自動配置也有改良，這應該可以解決某些電信商的SIM卡在comma three無法工作的問題。
另外還增加了對ADB功能的支持。這使得任何為安卓系統編寫的好工具，如Snapdragon Profiler，都能在comma three上使用。
圖、在Snapdragon Profiler中觀察openpilot在C3上的運作的情況
DBC清理
openpilot已經有五年的發展歷史，新的車款DBC資料庫比舊的車款要簡單幹凈許多。這跟各種版本的長頸鹿一樣的原因：Comma一開始沒有想到所有的汽車會有這多麽相似之處。
比較一下，福斯汽車的移植和本田的移植。一款福斯車型新增的代碼，只需要數行的檔案，差不多5行代碼，以及大約15行的韌體參數。相比之下，本田車型移植卻充滿了不同的代碼路徑，這取決於車型，幾乎每款車型都有一個單獨的DBC。
Comma已經將豐田的DBC減少到只有三個不同的DBC，依照平台劃分。大部分的工作只是把重覆的信息定義移到共同的DBC中。Comma透過對數百萬的豐田上傳片段驗證，找到了共同的信號來取代許多特定車輛的訊號。接下來，本田的DBC也要進行同樣的處理。
DBC的清理工作，比汽車移植是更大的改進項目。Comma首先要清理汽車代碼，從DBC到CANParser。當這些代碼清理完畢，我們將專注於建立龐大的文檔和工具，以完成你在openpilot中對汽車所做的三件大事：指紋識別、單個車型的移植和完整的品牌移植。
你以後可以在儀表模式下進行一次駕駛，然後在你的電腦上用這次駕駛的數據來開發你的完整移植。
如果你有想法，也可以加入Comma在GitHub上的討論。
