這是什麼、給誰用
這不是賣給一般車主的「改裝套件」。這是工程服務：你有一台車、一個車隊、一套車用設備或一批行車資料， 想要它做到原廠不給、市面沒有的事——我們以開源的 openpilot 與自己累積的工具鏈把它做出來，並附上可驗收的數字。
適合找我們的：
- 車用電子／後裝 ADAS 業者：要驗證自家感測器或演算法在真車上的表現、要一套可重播的資料驗收流程、要把功能移植到新車型。
- 車隊與物流業者（含營業大客車、遊覽車、貨運）：做運安智慧化，想從車機 log 知道駕駛實際怎麼開、警示設備準不準、哪些路段哪些行為在耗成本，或要一個客製副屏／HUD。
- 工控與特殊車輛設備商（AGV、堆高機、工程機具、農機）：有 CAN／Modbus 訊號要解、有感測器要接、要在嵌入式 Linux 上跑自己的控制與顯示。
- 研究單位與開發團隊：需要一個把 openpilot 拆開、改對地方、再驗回去的工程夥伴。
四種服務
ADAS／車機軟體客製與移植
以 openpilot（MIT 授權）為底，把你要的行為做進去：新車型移植、縱向／橫向控制調校、停車與路口邏輯、按鍵與儀表整合、跟上游版本同步。我們自己的分支從 VW 換到 Hyundai、從 comma three 換到 comma four，一路自己維護。
CAN 匯流排逆向與整合
從原廠 CAN 訊號找出你要的欄位（按鍵、定速狀態、油量、雷達目標…），接外接感測器（雷達、鏡頭），寫進 DBC 與車型設定。沒有文件也做得出來；協定裡真的沒有的指令，就下到硬體層（Arduino＋繼電器接原車撥桿）——這跟我們逆向太陽能逆變器 Modbus 是同一套本事。
行車資料工程：擷取、重播、驗收、訓練
把車機 log 變成可回答問題的資料：逐段重播比對決策、影片與訊號幀對齊、以百分位數量化「這台車、這個駕駛實際怎麼開」、用自己的 log 訓練神經網路前饋模型，並附驗收腳本讓改動有數字可驗。
副屏 HUD 與嵌入式部署
車機以外的顯示與運算：樹莓派副屏 HUD（雷達多目標、速度、油量、加速度上限來源）、在 comma 裝置螢幕上跑自己的 Qt 介面、車機熱點與網路自動切換、開機服務與遠端部署流程。
我們自己做過的
下面每一條都是在自己的車、自己的裝置上做出來並留有 log 與 patch 的。數字是自家樣本，不是通用承諾。
從 2023 年在 Passat 上逆向方向燈開始，經 FrogPilot 底的自家分支（副屏、Android 導航面板、離線圖資、外部輸入服務），到 2026 年以 openpilot master 為底移植 Custin；換車、換裝置時移植與重驗流程都走過一遍。
VW Passat MK8 時期查遍 opendbc 的 MQB DBC，確認只有方向燈狀態回報、沒有控制指令；改走硬體——Arduino 數位腳位驅動繼電器，接進 J527 車身控制模組的撥桿接頭。拆開實測撥桿只有 5 條線（不是資料上猜的 8 條），以實物為準。
自寫 joystick 工具（pytoar、keyinput）用搖桿控制並經串列送指令給 Arduino；後改為 USB 鍵盤＋Arduino 方向燈，設計成獨立的 cereal 訊息流服務而不是寫 params——因為 params 會拖慢主程式。
Hyundai Custin 上找到 openpilot 上游對車身 ECU 持續發 tester present 的方向燈控制機制（CAN-FD 路徑），評估移植到 CAN classic 平台。三年前的硬體解法與現在的協定解法，是同一個問題的兩種答案。
216 萬筆樣本、低速轉彎樣本從 2,143 筆擴增到 21,020 筆，轉向控制誤差降一半，部署到車機實車驗證。
現用 45 公尺門檻命中率、相對門檻對照、「無前車才啟動」濾波條件——每個判斷都拿 814 段 log 跑過；驗收：應介入 7 次抓對 5、無誤停、放行提早 1.4 秒。
實車比對加速後 2 秒內又踩煞車的頻率，由每分鐘 1.22 次降到 0.67 次，系統重煞次數由 106 次降到 53 次；跟車距離沒有因此變短。
用新累積的行車紀錄重訓前饋模型：25–35 km/h 入彎停頓指標 0.97→0.17、35–50 km/h 1.07→0，駕駛出手修方向盤由每分鐘 4.43 次降到 3.67 次。
夜間雷達與視覺前車來源來回切換由每分鐘 34.2 次降到 8.7 次，跟車加減速更平順。每一項都先在模擬與重播驗過，再上車用實車紀錄比對前後。
交通部 TDX 的 20,735 面速限標誌（109 條國道、快速公路與省道，含位置、數值、方向）加上警政署測速點，與開放地圖逐段比對，做成約 10,727 公里的有方向修正表，另補上 706 筆地圖沒標的速限。已上車、實車驗收中——資料先對、再談控制。
把彎道武裝率、駕駛實際側向加速度（中位數 0.89、90 百分位 1.10 m/s²）量出來，再把門檻縮放到這位駕駛真的會用的範圍。
分析實車資料時發現影片幀比訊號慢 159 幀，修正後才診斷出模型預測減速度不足的根因。資料對不齊，後面的結論全是錯的。
40 段完整 log 的驗收腳本：介入率、側向加速度尾部、駕駛拒絕率。改一個常數要能回答「改了之後哪幾段變好、哪幾段變差」。
下載實際行駛紀錄做 CAN 匯流排分析，主線 MAIN cruise 按鍵無效的根因（TCS13.ACCEnable 恆為 0）與修法，外接雷達方案與社群實作路徑盤點。
樹莓派 1280×400 長條觸控屏當 HUD：雷達多目標框選、時速／設定速度、油量、加速上限來源；在 comma three 螢幕跑自己的 Qt 介面並設開機服務；車機開機 75 秒沒連上已知 WiFi 自動開熱點。
所有改動以 patch 形式留存，能回答「這行為什麼是這個數字、什麼時候改的、當時的量測是什麼」。也曾以此驗出某社群 fork 的版本資訊造假並淘汰。
後窗 LED 字幕機（把車況即時告訴後車）的做法另寫成一項服務：LED 看板即時資料串接。
方法：每個數字都有出處
- 先量，再改。 改任何門檻前，先從 log 算出這台車、這位駕駛的實際分佈（中位數、90 百分位）。「3 m/s² 是一般路口轉彎」這種寫在註解裡的猜測，我們會把它換成量出來的 1.2–1.5。
- 一次只改一處，commit 訊息寫量測。 每個改動都能回答「原本的值哪裡來、新的值哪裡來、預期哪幾段會變」。
- 重播驗證，再上路。 用實盤規則逐幀重跑歷史 log，比對改前改後的決策差異；上路後再跑 40 段驗收腳本。
- 資料先對齊。 影片與訊號幀對不齊、雷達與視覺目標配不上，後面的結論全是錯的——這一步永遠先做。
- 誠實記錄失敗。 借來的做法（例如某 fork 的彎道前瞻法）實測會誤觸發，就寫進紀錄不採用；上游 revert 掉的模型不追。
應用：車隊運安智慧化
營業大客車、遊覽車、貨運車隊這幾年都在做「運安智慧化」：加裝前向碰撞與車道偏離警示、駕駛身分辨識、 車輛動態回報主管機關、駕駛行為管理。多數業者卡在同一個地方——設備裝了，資料卻只是一堆事件通知， 不知道警示準不準、不知道哪位駕駛哪段路真的有風險、也沒辦法回放出事前那三十秒。 我們做的行車資料工程，正好補這一段。
從 CAN 與車機 log 直接算每位駕駛的急煞、急加速、側向加速度、跟車距離、超速分佈（中位數與 90 百分位），不靠 OBD 小盒子推估。可做駕駛評分、教練回饋、保險與績效依據。
影片與訊號逐幀對齊後，任一路段、任一事件都能回放「當時車速、方向盤、煞車、前車距離、系統有沒有警示」；159 幀對不齊的坑我們踩過。
補助案要求的碰撞／車道偏離警示，裝了之後到底在對的時機響幾次、誤報幾次？用真實 log 算命中率與誤報率，給車隊當驗收依據、給設備商當調校依據。
車隊定位（自製發射器免月費）、油量與行駛狀態從 CAN 直讀、每日營運資料自動產報表推到主管機關或公司群組——這條我們在市府商店的每日回報上已經跑了幾個月。
副屏 HUD 顯示前車距離、路口減速、跟車狀態，做成不擋視線的長條屏；也可只做警示不做控制。
以資料層切入：讀你現有行車紀錄器、GPS、ADAS 設備的輸出，統一進一個資料模型，再做分析與儀表板。不要求整車換裝。
同一套能力，車以外的地方
邊界與責任
- openpilot 是實驗性的駕駛輔助軟體；我們交付的是研發成果與工程文件，不是經法規認證的量產品。上路使用的安全責任由導入方承擔，合約會明訂。
- 我們不販售整車方案給一般駕駛、不代購硬體、不做「保證通過某項法規」的承諾。
- 調校數字是針對特定車型、特定駕駛量測的；換車、換人要重量、重驗，這會寫在報價裡，不會用「通用參數」帶過。
- 所有交付含原始碼、patch 與量測資料，你不會被綁在我們身上。