前言

本文主要內(nèi)容是——無(wú)人駕駛中的CAN（Controller Area Network ）總線。

CAN總線在整個(gè)無(wú)人駕駛系統(tǒng)中有著十分重要的作用。除了在VCU信號(hào)需要通過(guò)CAN總線進(jìn)行傳輸外，無(wú)人車上的某些傳感器（如雷達(dá)、Mobileye）的信號(hào)傳遞也是通過(guò)CAN實(shí)現(xiàn)的。

我在無(wú)人駕駛，個(gè)人如何研究？中提到過(guò)實(shí)現(xiàn)一個(gè)無(wú)人駕駛系統(tǒng)，會(huì)有幾個(gè)層級(jí)： 感知層 → 融合層 → 規(guī)劃層 → 控制層 更具體一點(diǎn)為： 傳感器層 → 驅(qū)動(dòng)層 → 信息融合層 → 決策規(guī)劃層 → 底層控制層

“傳感器層”在之前的分享中已經(jīng)介紹過(guò)了，這次主要介紹的是“驅(qū)動(dòng)層”相關(guān)的內(nèi)容。

正文

CAN通信是一套高性能、高可靠性的通信機(jī)制，目前已廣泛應(yīng)用在汽車電子領(lǐng)域。有關(guān)CAN的總線的原理及特性并不是本次分享的重點(diǎn)。本文的重點(diǎn)在無(wú)人駕駛系統(tǒng)獲取到CAN消息后，如何根據(jù)CAN協(xié)議，解析出想要的數(shù)據(jù)。從CAN總線中解析出傳感器的信息，可以說(shuō)是每個(gè)自動(dòng)駕駛工程師，甚至每一個(gè)汽車電子工程師必備的技能。

認(rèn)識(shí)CAN消息

以百度推出的Apollo開(kāi)源的代碼為例做CAN消息的講解，我們先看到每一幀的CAN消息是如何被定義的。

可以看到這個(gè)名為CanFrame的消息結(jié)構(gòu)中包含4個(gè)關(guān)鍵信息，分別是：

1. uint32_tid

CAN消息的ID號(hào)。

由于CAN總線上傳播著大量CAN消息，因此兩個(gè)節(jié)點(diǎn)進(jìn)行通信時(shí)，會(huì)先看id號(hào)，以確保這是節(jié)點(diǎn)想要的CAN消息。最初的CAN消息id號(hào)的范圍是000-7FF（16進(jìn)制數(shù)），但隨著汽車電控信號(hào)的增多，需要傳遞的消息變多，信息不太夠用了。工程師在CAN消息基礎(chǔ)上，擴(kuò)展了id號(hào)的范圍，大大增加了id號(hào)的上限，并將改進(jìn)后的CAN消息稱為“擴(kuò)展幀”，舊版CAN消息稱為“普通幀”。

如果拿寫信做比較，這個(gè)id就有點(diǎn)類似寫在信件封面上的名字。

2. uint8_tlen

CAN消息的有效長(zhǎng)度。

每一幀CAN消息能夠傳遞最多8個(gè)無(wú)符號(hào)整形數(shù)據(jù)，或者說(shuō)能夠傳遞8*8的bool類型的數(shù)據(jù)。這里的len最大值為8，如果該幀CAN消息中有些位沒(méi)有數(shù)據(jù)，這里的len就會(huì)小于8。

3. uint8_tdata[8]

CAN消息的實(shí)際數(shù)據(jù)。

正如剛才提到的，每一幀CAN消息都包含至多8*8個(gè)bool類型的數(shù)據(jù)，因此可以通過(guò)8*8個(gè)方格，可視化CAN消息中的data。如下圖所示：

在沒(méi)有CAN協(xié)議幫助我們解析的情況下，這里的數(shù)據(jù)無(wú)異于亂碼，根本無(wú)法得到有用的消息，這也是CAN消息難以破解的原因之一。

4.timestamp

CAN消息的時(shí)間戳。

時(shí)間戳表示的是收到該CAN消息的時(shí)刻。通過(guò)連續(xù)多幀的時(shí)間戳，可以計(jì)算出CAN消息的發(fā)送周期，也可以用于判斷CAN消息是否被持續(xù)收到。

綜上，每幀CAN消息中最重要的部分其實(shí)是data，即8*8的bool值。所謂解析CAN消息，其實(shí)就是解析這8*8個(gè)bool類型的值。

認(rèn)識(shí)CAN協(xié)議

目前業(yè)界的CAN協(xié)議，都是以后綴名為dbc的文件進(jìn)行存儲(chǔ)的。德國(guó)Vector公司提供CANdb++ Editor是一款專門用于閱讀dbc文件的軟件。

如下圖所示，為Mobileye提供的車道線的dbc文件。（文末提供CANdb++ Editor安裝包和Mobileye車道線的dbc文件的獲取方法）

以id號(hào)為0x766的LKA_Left_Lane_A為例，這是Mobileye檢測(cè)無(wú)人車左側(cè)車道線的部分信息，包括了左側(cè)車道線的偏移量，曲率等。該幀CAN消息（Message）中的五個(gè)信號(hào)（Signal），分別是Lane_Type、Quality、Curvature、Curvature_Derivative、Width_left_marking、Position。

每個(gè)信號(hào)的具體描述顯示在軟件右側(cè)，其中與解析直接相關(guān)的三個(gè)要素已用綠色框選中。

1. Value Type（Unsigned或Signed）

某些物理量在描述時(shí)是有符號(hào)的，比如溫度。而描述另外一些量時(shí)，是沒(méi)有符號(hào)的，即均為正數(shù)，比如說(shuō)曲率。

2. Factor 和 Offset

這兩個(gè)參數(shù)需要參與實(shí)際的物理量運(yùn)算，F(xiàn)actor是倍率，Offset是偏移量。例如Lane_Type和Quality信號(hào)的Factor為1，Offset為0，而其他信號(hào)的Factor均為小數(shù)。具體的計(jì)算方法請(qǐng)往下看。

雙擊LKA_Left_Lane_A，打開(kāi)Layout頁(yè)，會(huì)發(fā)現(xiàn)很熟悉的方塊陣列，如下圖所示。

工程師真正關(guān)心的恰好是這塊彩色圖，因?yàn)樵搱D上的每個(gè)小方塊和data中的每一個(gè)bool量一一對(duì)應(yīng)。這就是CAN協(xié)議的真面目。

解析CAN信號(hào)

由于彩色方塊圖與data是一一對(duì)應(yīng)的，我們將兩個(gè)圖疊加，將得到如下圖所示的data圖。

每個(gè)信號(hào)物理量的計(jì)算公式為：

1.Factor為1的物理量

由于Lane_Type和Quality的Factor為1，Offset為0，因此十進(jìn)制值為多少，實(shí)際物理量即為多少。

從圖中就能直接看出Quality這個(gè)信號(hào)占據(jù)兩個(gè)位，二進(jìn)制數(shù)11，換算為十進(jìn)制是3（1*2 + 1*1）；Lane_Type占據(jù)四個(gè)位，二進(jìn)制數(shù)為0010，換算為十進(jìn)制是2（0*8 + 0*4 + 1*2 + 0*1）。

所以這一幀信號(hào)表示此時(shí)的左車道線Lane_Type值為2，Quality值為3。對(duì)于整數(shù)值，通信雙方可以約定規(guī)則，比如Mobileye就規(guī)定了，Quality為0或者1時(shí)表示車道線的置信度較低，不推薦使用此時(shí)的值；2表示置信度中等，3表示置信度較高，請(qǐng)放心使用。

2.Factor為小數(shù)的物理量

對(duì)于Factor不為1的物理量，比如Position，需要使用移位的方法進(jìn)行解析，但解析公式保持不變。以百度 Apollo提供的源碼為例進(jìn)行講解。

這里的bytes即為CAN消息中的data，首先將Position信號(hào)所在的行取出來(lái)，將第1行的8個(gè)bool值存儲(chǔ)在變量t1中，將第二行的8個(gè)bool值存儲(chǔ)在變量t0中。由于在這條CAN消息中，Position同時(shí)占據(jù)了高8位和低8位，因此需要將第一行和第二行的所有bool位拿來(lái)計(jì)算，高8位存儲(chǔ)在32位的變量x中，低8位存儲(chǔ)在32位的變量t中。

現(xiàn)在需要將高8位和低8位拼接，將高8位左移8位，然后與低8位求或運(yùn)算，即可得到Position的二進(jìn)制值。隨后進(jìn)行的左移16位，再右移16位的操作是為了將32位的變量x的高16位全部初始化為0。之后將x乘以Factor再加上Offset即可得到真實(shí)的Position值，給真實(shí)值加上單位meter，即可獲取實(shí)際的物理量。

與CAN類似的通信協(xié)議

VCU、雷達(dá)等通過(guò)CAN總線傳遞信號(hào)，隨著CAN的負(fù)載越來(lái)越高，很多傳感器選擇了其他通信方式。比如激光雷達(dá)的點(diǎn)云數(shù)據(jù)量太過(guò)龐大，使用的是局域網(wǎng)的方式進(jìn)行傳遞；再比如GPS和慣導(dǎo)使用的是串口進(jìn)行通信。

雖然通信方式和通信協(xié)議千差萬(wàn)別，但解析的方法都是一樣的。

結(jié)語(yǔ)

好了\(^o^)/~，這篇分享的內(nèi)容基本上講清楚了CAN總線消息的解析過(guò)程。這是無(wú)人駕駛系統(tǒng)傳感器驅(qū)動(dòng)層的基本理論。

由于不同ID的CAN消息的結(jié)構(gòu)不一樣，因此在寫解析代碼時(shí)，需要十分仔細(xì)，否則會(huì)給后續(xù)處理帶來(lái)想不到的bug。