做“擦屁股”的多傳感器融合，對開發(fā)者的意義是什么？

通常，一個(gè)完整的動(dòng)態(tài)目標(biāo)感知包括激光目標(biāo)感知、視覺目標(biāo)感知、毫米波目標(biāo)感知和傳感器融合（目標(biāo)級后融合）四個(gè)模塊。其中，傳感器融合模塊，同時(shí)接收前端激光、毫米波、視覺的感知目標(biāo)結(jié)果，加工處理后，以目標(biāo)的形式，輸出給下游。

自入行以來，本人一直在融合組，先是從開發(fā)人員成為融合模塊的負(fù)責(zé)人，后來成為動(dòng)目標(biāo)感知模塊的版本交付leader，再到現(xiàn)在作為動(dòng)目標(biāo)感知模塊的功能和方案設(shè)計(jì)專家。這些經(jīng)歷讓我意識(shí)到，很多從事動(dòng)目標(biāo)感知的同事，都不愿意加入傳感器融合小組做相關(guān)的開發(fā)工作，甚至對這個(gè)模塊嗤之以鼻。

因?yàn)?，單傳感器感知中的目?biāo)檢測算法涉及很多當(dāng)前學(xué)術(shù)界和工業(yè)界前沿的深度學(xué)習(xí)成果（比如，bev和transformer是每個(gè)做深度學(xué)習(xí)人掛在嘴邊的家常便飯，聽起來就很高大上），顯然更符合個(gè)人的職業(yè)發(fā)展方向；相比之下，傳感器融合算法，本身是一個(gè)基于規(guī)則設(shè)計(jì)的兜底模塊——而兜底，就意味著要幫上游的感知模塊“擦屁股”。

解決上游感知模型性能不足導(dǎo)致的誤檢、漏檢、精度不準(zhǔn)等各種各樣的問題（利用另外一個(gè)或多個(gè)傳感器的結(jié)果），需要用到的規(guī)則本身并不會(huì)有多復(fù)雜，這更多依賴開發(fā)者的經(jīng)驗(yàn)及其對上游傳感器特性的理解。這種特別工程化的，依賴經(jīng)驗(yàn)的開發(fā)內(nèi)容，顯然不太能在自己的簡歷上出彩，甚至?xí)寗e人覺得你做的這些事很“l(fā)ow”。

因此，有人形容傳感器融合是“夜壺”一般的存在。但我認(rèn)為，很多開發(fā)人員不僅低估了傳感器融合模塊在整個(gè)感知系統(tǒng)中的價(jià)值，而且也忽略了從事融合模塊開發(fā)對自身職業(yè)發(fā)展的意義。

01融合模塊是感知系統(tǒng)的定義者

傳感器融合模塊是感知的最后一個(gè)環(huán)節(jié)，負(fù)責(zé)將感知的結(jié)果輸出給下游消費(fèi)。因此，融合組的開發(fā)人員，一定最了解下游對于動(dòng)態(tài)目標(biāo)的需求是什么，最清楚感知系統(tǒng)要做成什么樣子。

很多做感知的模塊負(fù)責(zé)人，容易沉迷于自己的模型“在這一輪迭代中漲了幾個(gè)點(diǎn)，模型在car或者vru的mAP有百分之幾的提升”，而你要是問他，“這個(gè)模型發(fā)布后，我們在車上相應(yīng)的體驗(yàn)有什么優(yōu)化”，他多半是回答不上來的。這就是上游模塊對于業(yè)務(wù)和端到端體驗(yàn)的理解不夠深刻，導(dǎo)致做的事情不聚焦，收益不明顯。

而融合模塊開發(fā)者們需要做的事情，就是明確指出上游發(fā)力的方向。比如這個(gè)版本要優(yōu)化路口橫穿和匯入車輛的處理能力，對感知的需求就是橫穿目標(biāo)的檢出距離、位置朝向速度精度的提升，那么，融合對上游的感知需求就是“提升橫穿目標(biāo)的檢出能力和檢出精度，模型就需要針對性的補(bǔ)充橫穿和匯入場景的目標(biāo)數(shù)據(jù)”。

明確了迭代的方向，才能使各個(gè)模塊發(fā)力的方向一致，才能使各個(gè)模塊形成合力，整個(gè)智駕系統(tǒng)才能快速的演進(jìn)。

簡言之，融合模塊的開發(fā)者們可以基于對需求的正向分解，將需求傳遞給上游各個(gè)傳感器感知模塊，形成了各自模塊的ODD。不夸張地說，融合就像是整個(gè)感知的發(fā)動(dòng)機(jī)，一個(gè)優(yōu)秀的融合模塊設(shè)計(jì)者，應(yīng)該是基于整個(gè)智駕系統(tǒng)的功能定義，不斷地向上游提出明確的、邊界清晰的需求，指導(dǎo)上游的開發(fā)和模型迭代方向。

02融合是對產(chǎn)品和業(yè)務(wù)理解最深刻的模塊

感知融合團(tuán)隊(duì)作為感知的對外接口，是處理外部問題單和需求的“第一負(fù)責(zé)人”。所有的感知問題和對感知的需求，下游都是首先找融合模塊確認(rèn)和溝通。因此，融合模塊是感知系統(tǒng)里任務(wù)量最重的模塊，但也接觸到了更多的第一手、未經(jīng)閹割的信息。

一個(gè)長期從事融合開發(fā)工作的同事，不僅僅熟悉上游傳感器的各種性能優(yōu)劣和常見問題，也清楚下游使用感知目標(biāo)的各種屬性的具體策略，對各種屬性的依賴程度，也能敏感地認(rèn)識(shí)到感知端的各種問題對智駕的影響，哪些是高感知的，非預(yù)期的，用戶容易抱怨的問題。哪些是為了確保產(chǎn)品的競爭力而必須要做好的關(guān)鍵屬性。

舉個(gè)例子，在開發(fā)撥桿換道這個(gè)功能中，融合組的同事能夠接觸到如下信息：當(dāng)前友商對換道功能的設(shè)計(jì)邏輯是什么，依賴哪些傳感器，存在什么問題；換道過程中的人機(jī)交互過程如何設(shè)計(jì)；換道支持的最大車速和速度差是多少；哪些場景不能激活撥桿換道功能；我們的撥桿換道功能要做成什么樣；對感知的性能需求是什么；對規(guī)控的需求是什么；規(guī)控如何消費(fèi)感知的相關(guān)屬性；功能開發(fā)測試中，存在哪些設(shè)計(jì)缺陷和非預(yù)期問題等等各個(gè)方面的信息。

在這樣一個(gè)開發(fā)流程中，融合的開發(fā)者能接觸到一個(gè)功能從定義到開發(fā)的方方面面的一手信息，而在對這些信息消化吸收的過程中，開發(fā)者就會(huì)自然培養(yǎng)出了“自頂向下”的思維方式和“端到端”的看問題思維。

因而，在解決問題的過程中，就不會(huì)輕易地陷入單點(diǎn)的算法優(yōu)化，而是從功能定義的角度，首先去思考“我們預(yù)期的功能表現(xiàn)應(yīng)該是什么樣子的，這是不是一個(gè)問題”；再去進(jìn)一步分解“這個(gè)問題應(yīng)該在歸屬于哪個(gè)模塊優(yōu)化”；最后才是有針對性的優(yōu)化算法。

因此，我認(rèn)為，在融合組開發(fā)，更容易培養(yǎng)出“端到端”的大局觀，這顯然更有利于一個(gè)人在后續(xù)的職業(yè)生涯中更輕松地上手其他更需要統(tǒng)籌全局的崗位。

寫到這里，我想起組里有很多同事都羨慕那些能夠做前融合預(yù)研工作的人，因?yàn)樵谒麄兛磥恚叭诤鲜巧疃葘W(xué)習(xí)更高大上的一個(gè)分支，做前融合更有前（錢）途。大家都盯著前融合算法開發(fā)本身，卻不去思考我們?yōu)槭裁匆銮叭诤?、前融合要做成什么樣子、前融合要解決什么問題、相比于當(dāng)前的后融合，有哪些收益。

行業(yè)的現(xiàn)狀是，做過前融合開發(fā)的人一抓一大把，大家的水平不會(huì)有特別大的差別，簡歷上看也大同小異；而對前融合模塊有深刻認(rèn)識(shí)，能夠真正lead前融合模塊，快速將前融合上線并拿到預(yù)期收益的人才，卻很難看到。

也許你會(huì)反駁我說：“就一直做開發(fā)不好嗎？”。實(shí)話說，沒什么不好，但當(dāng)前自動(dòng)駕駛行業(yè)卷的程度，誰能有機(jī)會(huì)干一輩子開發(fā)呢。

在我的團(tuán)隊(duì)里，像某個(gè)項(xiàng)目的牽頭人這種需要負(fù)責(zé)端到端事務(wù)的崗位，往往是從融合組的開發(fā)者中優(yōu)先選拔。

03融合模塊要有兜底邏輯，但需要先想清楚怎么兜底

沒有一個(gè)做融合的人喜歡兜底，因?yàn)槎档拙鸵馕吨鴮憽芭K邏輯”，而寫“臟邏輯”是沒有任何價(jià)值和成就感可言的。但兜底又是融合模塊存在的天然使命，這導(dǎo)致做融合的人都不喜歡干融合，沒干過融合的人對融合模塊敬而遠(yuǎn)之。

確實(shí)，如果只是一味地?zé)o底線兜底，融合模塊最后就變成了一個(gè)雞肋般的存在。在傳感器性能還不太行的時(shí)候，融合是要做必要的兜底。模型的迭代需要一個(gè)過程，煉丹的結(jié)果也不一定每次都和預(yù)期一致，為了保證系統(tǒng)的正常演進(jìn)和測試，對上游感知的兜底是必須的。但這里有一個(gè)原則，就是一定要“有所為有所不為”。

我認(rèn)為作為融合模塊，首先要清醒地認(rèn)識(shí)到下游對感知端的需求是什么，再基于最終的需求做兜底的決策。

比如融合對于毫米波感知的需求，就是動(dòng)態(tài)目標(biāo)不能有任何漏檢，那你就要適當(dāng)?shù)貙撩撞ǖ囊恍┱`檢的和多檢的目標(biāo)做兜底。而反過來，如果毫米波的動(dòng)態(tài)目標(biāo)漏檢了，即使融合有別的傳感器可以確認(rèn)這個(gè)目標(biāo)報(bào)出，也不應(yīng)該去兜底，因?yàn)檫@不符合你的設(shè)計(jì)需求；而且，如果你做了（兜底），也會(huì)導(dǎo)致上游漏檢的問題無法暴露。

融合組在做每一個(gè)兜底的決策前，一定要先問一問自己，你期望的融合設(shè)計(jì)方案是什么樣的、你期望的傳感器感知上游做成什么樣，基于這個(gè)指導(dǎo)思想，再去審視要不要兜底。而兜底也不是將問題全部推給融合解決，一些明顯應(yīng)該由上游保證的輸出質(zhì)量，也是要推動(dòng)上游自己解決。

結(jié)語：

融合模塊是一個(gè)工程化程度比較高的模塊，現(xiàn)在業(yè)內(nèi)也想用深度學(xué)習(xí)的方法替代后融合的功能，從而讓整個(gè)感知系統(tǒng)更簡化，更容易基于數(shù)據(jù)驅(qū)動(dòng)。

在我看來，這只是“術(shù)”的不同而已，融合的“道”還是不變的——作為感知的輸出端，融合是一個(gè)承上啟下的模塊，對上游而言，融合是感知模塊的功能定義方；對下游而言，融合是感知模塊的解釋方。

做好融合模塊，也就具備了感知專家需要的基本能力，希望以此文，勉勵(lì)做融合的各位同事。