搞智能駕駛視覺感知的人對這樣的場景應該不陌生模型明明框到了前方的車但框在連續(xù)幾幀里左右跳類別一會兒是轎車一會兒是貨車框的中心位置漂移得離譜。你要是敢把這個結(jié)果直接丟給AEB或者ACC去用車在高速上能給你來一腳莫名其妙的剎車。模型輸出的是“框”是單幀的、帶噪聲的、彼此獨立的“檢測假設”而下游功能要的是“目標”——是連續(xù)、穩(wěn)定、帶著運動狀態(tài)和置信度評價的對象。這中間缺的那一大塊就是視覺后處理。這篇是視覺障礙物后處理系列的第五篇聊的主題是視覺后處理與輔助駕駛功能。前面幾篇分別講了檢測輸入、前后處理鏈路、以及障礙物基本信息處理這篇更側(cè)重一個層面后處理好的障礙物目標到底怎么跟FCW、AEB、ACC這些輔助駕駛功能銜接后處理結(jié)果的質(zhì)量會怎么影響功能表現(xiàn)以及實操過程中那些文檔里不會告訴你的坑。適合做感知后處理、融合、功能算法或者系統(tǒng)集成的人參考也適合想搞清楚“感知和功能之間到底發(fā)生了什么”的入門者。1. 先弄清楚后處理在整條鏈路里到底要干什么1.1 從“框”到“目標”后處理解決的不是檢測而是信任問題很多剛接觸這個領(lǐng)域的人覺得后處理不就是把檢測結(jié)果的置信度過濾一下、把重疊框去掉嗎如果只做這兩件事那叫“檢測結(jié)果清理”不叫后處理。真正的視覺后處理任務是把單幀的檢測假設變成時間上連續(xù)、物理上可信、語義上穩(wěn)定的目標級輸出。換句話說它解決的是“信任”問題——讓下游功能愿意相信這個目標存在、位置可信、狀態(tài)可預測。你看檢測模型的輸出格式就知道了每幀給出一堆結(jié)構(gòu)化數(shù)據(jù)包含類別標簽、框坐標、置信度分數(shù)。這些數(shù)據(jù)之間沒有任何關(guān)聯(lián)前一幀的框和后一幀的框誰是誰、哪里去了模型不關(guān)心。而后處理恰恰要解決這個問題幀與幀之間的目標如何關(guān)聯(lián)目標被遮擋了怎么辦目標的速度和加速度怎么估算目標類別閃變了怎么平滑這些如果不處理ACC跟車時前方車輛速度稍微變一下感知速度就跳一下跟車就會一沖一沖的坐在車里的人分分鐘暈車。所以整體鏈路是這樣的檢測模型感知→ 障礙物后處理目標化→ 決策規(guī)劃功能決策→ 執(zhí)行器控制。后處理是感知的“收尾者”也是功能的“接口者”。它的質(zhì)量好不好用戶體感最直觀的兩個指標就是誤報率和漏報率。誤報率高AEB天天制造驚險瞬間漏報率高FCW該響不響功能就成了擺設。1.2 為什么模型輸出不能直接進功能一個例子看清楚我舉個特別典型的例子。某次我調(diào)一個前向的FCW功能最初直接把YOLO系檢測器的輸出拿來計算TTC碰撞時間。正常跟車時前方目標相對速度大約20km/h相對距離30米TTC應該穩(wěn)定在5秒左右。但由于檢測框的寬度抖動比較厲害目標在圖像上的尺寸一會兒大一會兒小換算出的相對距離就是33米、28米、35米這樣來回波動TTC也跟著從4秒跳到7秒FCW的觸發(fā)邏輯被搞得疲于奔命該報警的時候沒報不該報警的時候響個不停。檢測框抖動是必然的神經(jīng)網(wǎng)絡對目標邊緣的回歸有噪聲光照變化、目標部分遮擋、車輛顛簸都會放大這種噪聲。而后處理的一個重要工作就是對這些有噪聲的輸入做時間和空間上的濾波讓輸出的目標位置、尺寸、速度有“慣性感”。這不是簡單做一下平均而是需要建立目標狀態(tài)估計模型用歷史信息和當前觀測融合還得考慮目標的運動模型是勻速還是勻加速、傳感器的觀測噪聲有多大。這些都是后處理的核心內(nèi)容。2. 視覺后處理的核心細節(jié)從框到軌跡的關(guān)鍵技術(shù)2.1 目標關(guān)聯(lián)怎么判斷這兩幀的框是同一個人后處理的第一步也是最基礎的一步是幀間目標關(guān)聯(lián)。上一幀檢測到前方第1輛車、第2輛車這一幀又檢測到一輛車你得知道這一幀的這輛車是不是上一幀的1號車這個問題解決不好后面全是空中樓閣。常用的關(guān)聯(lián)方法有兩大類一類是基于位置重疊的比如IoU交并比一類是基于特征相似度的比如外觀特征、尺寸特征。但在純視覺后處理里最主流、性價比最高的做法是“預測框與檢測框的IoU匹配”。你先用上一幀目標的位置和速度預測出這一幀它大概在哪然后用預測框和一幀檢測框算IoU如果IoU大于某個閾值就可以認為是同一個目標。實際操作中我用的是匈牙利算法來做全局最優(yōu)匹配。先構(gòu)建一個代價矩陣矩陣元素是預測框和檢測框的IoU或距離的負值然后通過匈牙利算法找到整體代價最小的匹配方案。核心經(jīng)驗是IoU閾值的選擇——我一般設0.30.5之間。閾值太低比如0.2容易出現(xiàn)兩個不同目標錯配在一起閾值太高比如0.7目標稍微移動快一點就斷開連接、重新分配ID。低速城區(qū)場景可以設高一些高速場景建議設低一些因為高速下相同時間間隔內(nèi)目標的位移更大幀間重疊率天然偏小。2.2 軌跡生命周期管理目標不是一出現(xiàn)就是“真”的目標發(fā)出來一個ID不是馬上就推給下游使用的。因為檢測模型偶爾會對背景誤檢比如路牌、樹影、橋上橫梁都可能被誤檢為障礙物。如果誤檢也被當成穩(wěn)定目標FCW會對天降橫梁瘋狂報警。因此我會給每條軌跡定義幾個生命周期狀態(tài)未確認候選、已確認、丟失中、已刪除。一個新目標進入系統(tǒng)時先掛一個候選軌跡連續(xù)幾幀都能匹配到檢測框才升級為已確認軌跡并輸出給下游功能。反過來已確認目標連續(xù)多幀匹配不上比如被前車遮擋軌跡進入丟失狀態(tài)在丟失狀態(tài)下目標位置繼續(xù)用運動模型推測但置信度會隨時間衰減。連續(xù)丟失時間超過閾值軌跡直接刪除ID不再復用。參數(shù)怎么定我自己的經(jīng)驗是確認幀數(shù)設3~5幀丟失幀數(shù)設30~50幀。確認幀數(shù)設太短誤檢容易混進來設太長真實目標剛出現(xiàn)在視野邊緣時功能層遲遲拿不到確認結(jié)果等都確認完目標已經(jīng)離很近了留給系統(tǒng)的反應時間變短。丟失幀數(shù)的設置要考慮目標遮擋場景。高速上如果前車被旁邊大車擋住通常只會遮擋一兩秒30~50幀假設25~30fps足夠撐過遮擋期目標ID不會丟但遮擋時間再長軌跡預測的置信度已經(jīng)很低繼續(xù)跟下去反而可能導致目標位置漂移很遠的假軌跡這時候刪除軌跡反而干凈。2.3 目標運動狀態(tài)估計卡爾曼濾波和它的工程落地輔助駕駛功能里目標的速度、加速度是核心輸入。ACC要知道前車是加速還是減速AEB要知道碰撞時間還有多少FCW要判斷危險等級。那么目標速度怎么來最樸素的方法是相鄰兩幀位置差除以時間差但這樣算出來的速度噪聲非常大你根本沒法用。所以工程上普遍用卡爾曼濾波做運動狀態(tài)估計。這里分享一個基礎的勻速模型CV模型實現(xiàn)思路。目標狀態(tài)定義為 x [pos_x, pos_y, vel_x, vel_y]觀測是檢測輸出的目標中心位置 [pos_x, pos_y]。每幀做兩步操作先通過運動模型預測目標狀態(tài)預測步再用當前幀檢測結(jié)果對預測進行修正更新步。核心要調(diào)的兩個參數(shù)是過程噪聲協(xié)方差Q和觀測噪聲協(xié)方差R。Q大表示更信任觀測、響應快但噪聲大Q小表示更平滑但滯后明顯。我調(diào)車時的經(jīng)驗是初始先給Q設一個相對偏小的值讓速度曲線平滑再根據(jù)實際跟車體感逐步調(diào)整。如果發(fā)現(xiàn)目標速度響應太慢前車剎車了感知速度還在慢慢降就適當增大Q如果速度曲線毛刺多就增大R?？柭鼮V波在工程上的一個復雜點是目標初始化和終止條件要做處理。第一幀出現(xiàn)的目標沒有歷史速度需要用連續(xù)兩幀的位置差來初始化速度但這兩幀檢測噪聲會讓初始速度偏差很大。我的做法是限制初始速度的范圍比如相機感知的目標速度不能超過物理極限比如200km/h超過就置為邊界值再用后續(xù)幀的觀測逐步修正。2.4 類別與置信度的時序平滑讓車不再“變性”檢測模型對目標類別的判斷在單幀上會存在抖動。同一個目標這一幀輸出是Car下一幀輸出是Truck再下一幀又是Car。如果你直接把類別變化傳給下游功能層會非常困惑——Truck和Car的動力學模型、剎車能力、危險程度完全不一樣。我做類別平滑的方法很簡單給每條軌跡維護一個類別投票器。每幀匹配上檢測框時把檢測類別的得分加進去最后輸出得分最高的類別且只有得分超過一定比例才允許類別切換。一個比較保守的策略是新類別連續(xù)N幀比如5幀都占優(yōu)勢才切換類別否則保持原類別輸出。這能有效過濾掉單幀的閃爍。代價是真實類別變化時比如拖掛車切換會有幾個幀的延遲但這對功能層面通常是可接受的。置信度的處理也類似。模型輸出的置信度分數(shù)在不做處理時抖動很大尤其夜間、逆光、雨天場景。我習慣對置信度做時間維度的加權(quán)平均當前幀置信度占60%70%歷史置信度占30%40%。這樣單個低置信度的突變幀不會導致目標被直接刪除也不會讓一個高置信度的偶然誤檢瞬間升級成穩(wěn)定目標。置信度閾值的選擇則需要分場景城區(qū)場景我通常把初始閾值設0.4左右郊區(qū)高速設0.5因為高速上誤檢代價更高寧可多漏一些也不能亂報。3. 實操后處理管線實現(xiàn)與輔助駕駛功能對接3.1 一個可復現(xiàn)的視覺后處理管線架構(gòu)理清核心點之后我直接給一套最常見的視覺后處理管線架構(gòu)。輸入是檢測模型輸出的檢測框列表輸出是帶有ID、類別、位置、速度、置信度等屬性的目標列表。管線內(nèi)部通常分四個模塊預處理與坐標轉(zhuǎn)換、目標關(guān)聯(lián)與匹配、軌跡管理與狀態(tài)估計、輸出與接口適配。預處理模塊負責把檢測框從像素坐標換到相機坐標系或車身坐標系。這里特別提醒一點像素坐標框不能直接用于速度估算。如果不做坐標轉(zhuǎn)換用像素位移近似物理位移目標距離越遠越不準。通常我們是利用相機內(nèi)參、外參和地面平面假設把檢測框底邊中心點投影到地面上得到目標的世界坐標x, y。這一步的精度直接決定后續(xù)距離和速度的精度標定參數(shù)要定期檢查和校驗。輸出接口是給下游功能用的object list結(jié)構(gòu)。我常用的結(jié)構(gòu)體包含以下關(guān)鍵字段target_id // 全局唯一ID class_type // 障礙物類別轎車/卡車/行人/騎行者/未知 bbox // 原始圖像檢測框調(diào)試用 position_x // 車身坐標系下的縱向位置米 position_y // 車身坐標系下的橫向位置米 velocity_x // 縱向速度米/秒 velocity_y // 橫向速度米/秒 confidence // 目標置信度得分 existence_score // 目標存在概率 track_age // 軌跡已維持幀數(shù) lost_age // 軌跡丟失幀數(shù) valid_flag // 是否可作為可信目標參與功能決策valid_flag這個字段在設計時一定要留。它表示該目標是否滿足功能安全的最低要求比如是否經(jīng)過足夠幀數(shù)確認、置信度是否超過閾值、時間戳是否新鮮。功能層拿到目標列表后優(yōu)先只看valid_flag為真的目標。這樣即使感知端有異常、目標處于丟失狀態(tài)只要valid_flag置為false功能層就不會用它做決策從源頭避免誤觸發(fā)。3.2 關(guān)鍵模塊偽代碼目標關(guān)聯(lián)、生命周期、狀態(tài)更新我寫一個簡化但可運行的偽代碼流程方便大家對照自己的工程實現(xiàn)思路。# 偽代碼視覺后處理主循環(huán) for frame_idx in range(total_frames): detections detector.infer(image) # 當前幀檢測結(jié)果 # 1. 坐標轉(zhuǎn)換檢測框到車身坐標系 dets_world world_coord_transform(detections) # 2. 預測用已有軌跡的運動模型預測當前幀狀態(tài) predicted_tracks [track.predict(dt) for track in tracks] # 3. 關(guān)聯(lián)預測軌跡與當前幀檢測做匹配 cost_matrix build_iou_cost_matrix(predicted_tracks, dets_world) matched_pairs, unmatched_dets, unmatched_tracks hungarian_match(cost_matrix) # 4. 更新匹配上的檢測用于修正軌跡狀態(tài) for track_idx, det_idx in matched_pairs: tracks[track_idx].update(dets_world[det_idx]) tracks[track_idx].confirm() # 累加確認計數(shù) # 5. 處理未匹配的檢測新軌跡候選 for det_idx in unmatched_dets: new_track Tracker.initialize(dets_world[det_idx]) tracks.append(new_track) # 6. 處理未匹配的軌跡進入丟失狀態(tài) for track_idx in unmatched_tracks: tracks[track_idx].mark_lost() # 7. 生命周期管理確認/刪除 for track in tracks: track.update_state_machine() # 8. 產(chǎn)出過濾無效目標輸出object list output_targets [track.to_object() for track in tracks if track.is_confirmed()] publish(message_frame_id, output_targets)這里每一步都有細節(jié)講究。第三步的代價矩陣如果純用IoU遇到快速接近的大貨車和遠處的小轎車時容易匹配混亂。我建議代價矩陣不要只用IoU可以加入位置距離和高寬比約束IoU低于0.2的配對直接設為無窮大排除高寬比差異超過一定倍數(shù)也排除。這樣即使兩個目標空間上接近但形狀差異大也不會錯配。另外一個實操技巧是如果檢測幀率穩(wěn)定每次預測的dt要嚴格用時間戳計算不要默認等于1/幀率。相機幀率在顛簸路面上可能偶發(fā)掉幀統(tǒng)一用時間戳計算dt可以讓速度估算更穩(wěn)。3.3 時間戳對齊最容易翻車的細節(jié)時間戳對齊是我見過最容易被忽略、也是最容易翻車的問題。視覺后處理輸出的目標列表帶上時間戳是不夠的關(guān)鍵是你這個時間戳是“算法完成時間”還是“圖像曝光時間”。這兩個時間差了可能幾十到上百毫秒高速場景下100毫秒意味著車輛向前移動了好幾米。如果你的目標位置是100毫秒前的而下游功能按“當前時間”做決策那AEB的反應距離憑空縮短好幾米。我的做法是感知輸出里的每個目標都帶兩個時間戳一個是圖像曝光時間一個是后處理完成時間。下游決策用曝光時間作為目標狀態(tài)的有效時刻用完成時間判斷數(shù)據(jù)的時效性。如果完成時間和當前規(guī)控時刻差超過一個閾值比如150ms這幀感知數(shù)據(jù)就不能參與實時安全決策功能層要降級處理。另外后處理內(nèi)部在計算速度時必須用相鄰兩幀曝光時間戳的差值作為dt而不是用算法執(zhí)行間隔否則速度里會混入處理延遲的誤差。3.4 后處理如何支撐FCW、AEB、ACC這些具體功能后處理做完最終要落到功能上。這里講三個最典型的對接實例。先看FCW前向碰撞預警。FCW的核心參數(shù)是TTC計算方式是相對距離除以相對速度。后處理給的是自車的目標縱向位置和縱向速度經(jīng)過差值得出相對速度和相對距離再算出TTC。FCW的報警閾值一般分兩級預警級TTC在2.6~3.0秒介入級在1.2~1.5秒。但單純靠TTC觸發(fā)工程上會誤報很大因為目標可能正在切入或者本身在制動過程中。所以功能層通常還要求后處理額外提供目標的生命周期穩(wěn)定度和橫向運動趨勢。如果目標剛確認不久、橫向速度明顯即使TTC很小也不會觸發(fā)FCW。我在調(diào)這個的時候發(fā)現(xiàn)后處理輸出的目標橫向速度估算尤其重要橫向速度估算不準功能會把旁邊車道正常行駛的車誤判為切入車輛。然后是AEB自動緊急制動。AEB對感知置信度的要求比FCW高得多因為它要主動制動。功能層一般需要后處理提供一個“危險目標等級”的評價除了TTC還會結(jié)合目標類別行人、騎行者、車輛權(quán)重不同、目標是否被遮擋遮擋狀態(tài)、置信度分數(shù)。AEB觸發(fā)的目標后處理必須給出valid_flag為真且已經(jīng)確認跟蹤超過一定幀數(shù)并且目標位置必須經(jīng)過濾波穩(wěn)定。工程上這類目標通常還要過一遍“安全邏輯”——如果后處理內(nèi)部檢出目標狀態(tài)異?；蛘邥r間戳超時寧可延遲一幀制動也不能在目標不明確時誤制動。ACC自適應巡航是另一個典型場景。ACC的核心是選目標從所有有效目標里選出同車道內(nèi)距離最近的目標作為跟隨目標。后處理在這里要做的是保證每個目標的速度估計平滑尤其是目標剛進入ACC跟隨范圍時速度不能突變。否則ACC控制端發(fā)現(xiàn)目標速度從0突然跳到20m/s會先急減速再慢慢跟上那種駕駛體驗約等于新手司機猛踩剎車。我的經(jīng)驗是ACC用到的目標速度至少經(jīng)過5幀以上的濾波再進入控制且速度變化率也就是加速度也需要平滑輸出讓控制端有預測性。3.5 輸出質(zhì)量的評價閉環(huán)你說了不算回歸數(shù)據(jù)說了算后處理做得好不好不能靠主觀感覺需要一套評價閉環(huán)。我自己的習慣是除了常規(guī)的檢測指標Precision/Recall對后處理效果重點盯三個指標ID Switch次數(shù)ID切換率、軌跡中斷次數(shù)、以及跟車速度波動幅度。ID Switch是行業(yè)里衡量追蹤穩(wěn)定性的核心指標一幀之內(nèi)目標ID發(fā)生切換的次數(shù)。高速場景下一次ID Switch就會讓ACC把目標當成新目標處理導致一頓一挫。軌跡中斷次數(shù)統(tǒng)計的是已確認軌跡因為遮擋或丟失而結(jié)束的次數(shù)如果一條軌跡在中遠距離頻繁中斷下游功能就會頻繁重新選取目標。速度波動幅度則是直接在功能層看跟車目標速度序列的方差正常情況波動應該很小。怎么測我的做法是錄一批包含城區(qū)、高速、夜晚、雨天、隧道進出口等場景的測試數(shù)據(jù)跑完后處理算法用標注工具比如分析追蹤結(jié)果的腳本腳本自動統(tǒng)計上述指標。每次改動關(guān)聯(lián)閾值、卡爾曼參數(shù)或者生命周期參數(shù)都要跑一遍回歸對比指標變化。我調(diào)參時最常遇到的情況是某個場景ID Switch變好了另一個場景誤檢變多了。這種時候就需要定義場景權(quán)重不是簡單求平均而是按場景安全性分配權(quán)重后綜合評分。4. 踩坑實錄視覺后處理常見問題與排查經(jīng)驗4.1 目標ID頻繁切換先別改算法先看數(shù)據(jù)ID Switch算是后處理問題里最讓人抓狂的一個。目標ID頻繁切換會導致功能層對目標狀態(tài)感知不連續(xù)AEB可能把同一個目標當成新目標重新評估ACC會重新選目標體感就是車在高速上“猶豫不決”。遇到ID Switch我的排查路徑是固定的。第一步把前后幾幀圖像數(shù)據(jù)抽出來看目標在圖像上的重疊度。如果兩個相鄰目標在圖像上幾乎完全重疊那是當前匹配邏輯無法區(qū)分的正?，F(xiàn)象需要考慮加入特征匹配比如目標外觀特征或者用多傳感器融合輔助分離。第二步檢查檢測框的穩(wěn)定性。如果檢測框?qū)挾仍谶B續(xù)幀內(nèi)劇烈變化導致IoU不穩(wěn)定優(yōu)先解決檢測框抖動比如對檢測框做寬高比平滑。第三步調(diào)整匈牙利算法的代價矩陣。這個我在前面提過IoU閾值太嚴格會導致同一目標短暫失配然后重新分配ID太寬松又會讓兩個目標交叉時錯配。我最終的做法是把IoU閾值作為場景參數(shù)緩存在不同場景高速、城市、隧道波動而不是全局固定一個值。4.2 高速上的目標速度突然跳到離譜值這是我自己踩過比較深的一個坑。某次測試中前方目標速度在200多公里每小時和正常值之間來回跳。后來排查發(fā)現(xiàn)問題不在卡爾曼增益而在坐標轉(zhuǎn)換。車輛在彎道上行駛時如果是做純像素到地面的投影目標框底邊中心點在地面上的投影位置會有很大的系統(tǒng)偏差因為相機外參中的俯仰角在車輛加減速時會變化車輛抬頭點頭導致目標底邊投影位置在前后方向上劇烈漂移速度自然就跳變了。解決思路有兩個方向。一是做俯仰角補償利用車道線消失點、或者IMU數(shù)據(jù)來實時估計相機俯仰角變化。二是目標位置濾波時增加觀測噪聲的自適應調(diào)整當檢測到目標在圖像上處于遠距離、且地面投影不穩(wěn)定的邊緣區(qū)域時增大觀測噪聲R讓濾波器更信任預測而不是觀測。注意這是過濾問題不是根治問題根治還是需要前端做穩(wěn)定的相機姿態(tài)補償。但后處理端的這個自適應R能極大緩解功能層面的體感問題。4.3 低置信度目標造成誤檢置信度閾值不是一拍腦袋定的很多人一開始面試時問“置信度閾值設多少”脫口而出0.5。但0.5根本不具備普適性。檢測模型在不同天氣、不同距離上的置信度分布完全不一樣。遠距離的行人置信度普遍在0.3~0.5之間你要是全局設0.5行人目標全被濾掉AEB對行人功能就失效了。夜間大燈照射下目標的置信度整體偏低但目標往往是真的。所以閾值設定要考慮場景和距離維度。我的做法是把圖像劃分成近、中、遠三個區(qū)域?qū)煌撝低瑫r結(jié)合時間信息連續(xù)低置信度但穩(wěn)定的軌跡可以作為候選目標不立即丟棄。還有一個技巧是利用“消失一致性”——如果一個低置信度的目標軌跡在連續(xù)幾幀內(nèi)保持了穩(wěn)定的運動趨勢它比一個突然出現(xiàn)的高置信度目標更值得保留。功能層更怕的是那種“突然冒出來、又突然消失”的不穩(wěn)定目標。4.4 雨夜、逆光、隧道口的經(jīng)典翻車場景這幾個場景幾乎每個做后處理的人都會遇到我就直接給結(jié)論和經(jīng)驗。白天進隧道那一瞬間相機自動曝光來不及調(diào)整畫面要么過曝要么全黑檢測結(jié)果基本沒法用。后處理這時候要做兩件事一是對感知結(jié)果的時間戳做“無效標記”告訴下游這一幀數(shù)據(jù)不可信二是利用軌跡預測維持目標輸出但不能讓目標速度產(chǎn)生假變化。如果功能層因為進隧道瞬間感知失效而退出ACC體驗很糟糕但如果后處理強行輸出預測位置又可能因為預測誤差積累導致目標位置偏差很大。折中方案是輸出預測軌跡但降低置信度同時告訴功能層數(shù)據(jù)處于“感知降級”狀態(tài)ACC可以繼續(xù)保持但限制加減速幅度。雨夜場景則是另一個問題。地面反光、雨滴在鏡頭前形成光暈檢測模型容易把水漬、燈光反射誤檢成障礙物。后處理層面能做的是加大確認幀數(shù)讓這類誤檢因為時空不一致而被過濾掉。逆光場景目標往往只檢測到上半部分或者出現(xiàn)“局部檢測”框高度偏矮這會導致目標實際位置投影偏差。后處理可以加一個針對性的箱體過濾目標高度低于物理合理高度比如0.5米以下且ID又是首次出現(xiàn)就提高確認門檻。5. 一些個人經(jīng)驗與后續(xù)擴展方向說到這再補充一個我實際調(diào)試中摸索出來的經(jīng)驗。后處理里面參數(shù)“跟著場景走”這件事不要只靠感覺去調(diào)最好做成一張場景參數(shù)表。高速、城市、隧道、雨天、夜晚分別配一組不同的確認幀數(shù)、IoU閾值、置信度閾值、卡爾曼Q/R參數(shù)。運行的時候根據(jù)當前的場景識別結(jié)果光照、車速、雨刮狀態(tài)、車道場景自動切換參數(shù)組。這比用一個全局參數(shù)跑所有場景要穩(wěn)得多。但也要注意參數(shù)不能切得太頻繁否則場景識別抖動會造成參數(shù)反復切換目標狀態(tài)也跟著抖。我一般對場景標簽做5秒以上的“粘滯”處理標簽變了至少保持幾秒再切換參數(shù)。另一個值得擴展的方向是和雷達、超聲波的融合問題。純視覺后處理做到最后你會發(fā)現(xiàn)一些結(jié)構(gòu)性問題靠視覺本身很難解決比如單目視覺對目標絕對距離估計天生不精確尤其是遠距離目標。這時候就需要多傳感器融合來做互補。視覺后處理的輸出結(jié)果可以作為融合的輸入之一而融合后的目標質(zhì)量反過來也可以校驗視覺后處理的好壞。這個我后續(xù)準備單獨寫一篇這里先提一個核心觀點視覺后處理做到后半段目標已經(jīng)不是“檢不出來”的問題而是“信不信得過”的問題而融合恰好是解決“信得過”的另一條關(guān)鍵路徑。最后再分享一個小技巧調(diào)試后處理算法時記得做一個可視化的調(diào)試工具在圖像上同時繪制檢測框和目標軌跡、目標ID、速度矢量能極大提升排查問題的效率。很多復雜問題比如ID切換、速度跳變、軌跡漂移你光看數(shù)字是看不出來的但在圖上放慢播放一眼就能定位。好的可視化調(diào)試工具是后處理算法迭代效率的分水嶺——這個工具值得你花時間建好越早越好。