自動駕駛汽車依靠人工智能、視覺計算、雷達、監控裝置和全球定位系統協同合作，讓電腦可以在沒有任何人類主動的操作下，自動安全地操作機動車輛。

Voyage是汽車自動駕駛領域內的一家專業公司，他們想要實現的終極目標是：對于世界上的任何一個人，他都可以隨時隨地召喚一輛汽車直接開到他的家門口，并將他安全地送達到目的地，而且價格也非常便宜。對于Voyage來說，他們將不可避免地給乘客提供汽車關鍵功能的控制權，因為總有一天開車的將不再是我們人類，而這一天馬上就要到來了。

CAN總線介紹

一臺現代化汽車擁有大量的控制系統，這些控制系統的作用與Web應用中各種微服務的作用是非常相似的。對于一臺電動汽車來說，它擁有安全氣囊、自動剎車系統、電動助力轉向系統、音響系統、電動車門、后視鏡調整系統、以及電池與充電系統等等。這些系統需要相互通信并獲取其他系統的運行狀態。1983年， 博世公司 (德國一家從事汽車與智能交通技術的公司)的一個團隊開始嘗試通過研究CAN(Controller Area Network-控制器區域網絡)總線來解決這一復雜的問題。

你可以把CAN總線當作一個簡單的網絡，汽車中的任何一個系統都可以通過這個網絡來監聽或發送命令，它可以將汽車中那些復雜的組件以一種“優雅”的方式組合起來，并給我們的汽車提供各種各樣的現代化功能。

下圖為一輛1988年款的寶馬8系，這也是全球第一臺采用了CAN總線的汽車：

自動駕駛汽車與CAN總線

近些年來，隨著自動駕駛汽車的快速發展，CAN總線的概念也得到了普及。為什么呢?因為自動駕駛汽車領域內的絕大多數公司都不會從零開始設計和制造自家的汽車，而且他們還需要想辦法通過編程的方式來控制汽車。

通過對汽車CAN總線進行逆向工程分析，工程師將可以通過軟件來向汽車發送控制命令。比如說，最常用的控制命令有旋轉方向盤、加速(踩油門)和制動(踩剎車)。

通過使用類似LIDAR(激光雷達)這樣的傳感器，汽車將能夠“看到”或“感受到”它所處的外部環境。汽車內的電腦可以根據傳感器傳回的數據來決定向汽車發送怎樣的控制命令，比如說將方向盤旋轉多少度、加速到多少邁、或者是否應該立即踩剎車等等。

下圖為LIDAR技術的動態演示圖：

實際上，并不是每一臺汽車都可以成為自動駕駛汽車。

CAN總線

自從1994年開始，CAN已經成為了美國汽車和輕型卡車中的一種標準了，但是直到2008年它才成為一種強制標準。它主要使用了兩條線：CAN high(CANH)和CAN low(CANL)。CAN使用的是差分信號，這意味著當信號傳輸進來時，CAN會提升一條線路的電壓，并等量降低另一條線路的電壓。一般來說，只有對噪聲容錯較高的環境才會使用差分信號，例如汽車系統或工業制造領域。

下圖顯示的是示波器中觀察到的原始CAN信號：

這也就意味著，通過CAN總線傳輸的數據包并非標準化的數據包，每一個CAN總線數據包都包含下面這四個關鍵元素：

1.仲裁ID(Arbitration ID)：仲裁ID是一種廣播消息，代表的是需要進行數據通信的設備ID，不過一臺設備可以發送多個仲裁ID。如果兩個CAN數據包同時在總線上進行發送，那么仲裁ID較小的那個數據包將優先傳輸;

2.標識符擴展(IDE)：對于標準CAN來說，這部分數據永遠為o;

3.數據長度碼(DLC)：它代表數據的長度，范圍從0到8字節不等;

4.數據(Data)：需要傳輸的數據，標準CAN總線數據包可攜帶的數據大小最多為8字節，但某些系統會將數據包強制填充至8個字節;

標準CAN數據包的格式

CAN框架

為了能夠控制汽車空調系統的開啟和關閉，我們首先需要找到正確的CAN總線(因為一輛汽車有很多CAN總線)。福特Fusion至少有四條總線(廠商記錄)，其中有三條為高速CAN(500 kbps)，還有一條為中速CAN(125 kbps)。

OBD-II端口暴露了其中的兩條總線：HS1和HS2，但這臺汽車上這兩條總線有防火墻的保護，因此不允許我們向其發送欺騙指令。在Alan(Voyage員工)的幫助下，我們解決了這個問題并成功拿到了HS1、HS2、HS3和MS的訪問權。注：OBD-II端口后面有一個名叫Gateway Module的設備，所有的總線最終都要將數據傳輸到這個設備中，這就是我們的解決方案。

由于空調系統可以通過汽車多媒體接口(SYNC)來進行調整，因此我們直接將目標鎖定在了MS總線身上。

但是我們怎樣才能讓我們的計算機去讀寫CAN數據包呢?答案就是 SocketCAN ，它是一套開源CAN驅動，而且也是 Linux內核 中的一種網絡棧。

現在，我們可以將汽車上的三條線路(GND、MSCANH和MSCANL)連接到Kvaser Leaf Light HSv2或CANable上，然后通過一臺擁有最新版Linux內核的計算機將這些總線當作一種網絡設備來進行加載和讀取。

modprobe can

modprobe kvaser_usb

ip link set can0 type can bitrate 1250000

ifconfig can0 up

加載完成之后，我們可以使用命令candump can0，然后開始查看CAN的數據流量：

但是，我們這樣去監控總線的數據流量，就相當于用眼睛來觀察聲音信號的振幅一樣，我們不僅很難弄清楚總線到底在傳輸什么數據，而且也很難發現其中的模式或規律。因此，我們需要像分析聲音頻率一樣來分析這個問題，我們可以調用cansniffer.和cansniffer來查看相應的ID，然后主要分析CAN框架的數據區域中具體發生了哪些變化。我們通過研究后發現，我們可以利用特定的ID來過濾掉那些我們不需要的數據，然后只留下與我們問題相關的那些數據。

下面我們對MS總線調用cansniffer命令。我們只留下了CAN id 355、356和358的相關數據，并過濾掉了其他無效內容。與此同時，按下了汽車中的溫度調節按鈕，我們可以看到數據下方出現了001C00000000，它代表的就是我們按下調節按鈕的操作。

下一步就是將汽車的空調系統與我們運行于汽車內的PC進行連接，PC運行的是Robot操作系統(ROS)。幸運的是我們使用了SocketCAN，因為它有一個模塊可以方便我們的操作，即socketcan_bridge可以將我們的CAN框架轉換成一種ROS可接受的消息格式。

下面演示的是整個解碼過程：

if frame.id == 0x356:

raw_data = unpack('BBBBBBBB', frame.data)

fan_speed = raw_data[1] / 4

driver_temp = parse_temperature(raw_data[2:4])

passenger_temp = parse_temperature(raw_data[4:6])

解碼后的數據保存在CelsiusReport.msg之中：

bool auto

bool system_on

bool unit_on

bool dual

bool max_cool

bool max_defrost

bool recirculation

bool head_fan

bool feet_fan

bool front_defrost

bool rear_defrost

string driver_temp

string passenger_te

在按下了汽車內所有的相關按鈕之后，我們得到了下面這個清單列表：

CONTROL_CODES = {

'ac_toggle': 0x5C,

'ac_unit_toggle': 0x14,

'max_ac_toggle': 0x38,

'recirculation_toggle': 0x3C,

'dual_temperature_toggle': 0x18,

'passenger_temp_up': 0x24,

'passenger_temp_down': 0x28,

'driver_temp_up': 0x1C,

'driver_temp_down': 0x20,

'auto': 0x34,

'wheel_heat_toggle': 0x78,

'defrost_max_toggle': 0x64,

'defrost_toggle': 0x4C,

'rear_defrost_toggle': 0x58,

'body_fan_toggle': 0x04,

'feet_fan_toggle': 0x0C,

'fan_up': 0x2C,

'fan_down': 0x30,

}

現在，我們就可以直接向ROS節點發送字符串數據，然后通過它來將我們發送的信息轉換成汽車可以識別的特殊代碼：

rostopic pub /celsius_control celsius/CelsiusControl ac_toggle

分析結果

我們現在可以向CAN總線發送相應的CAN控制代碼了，這些代碼與我們按下汽車物理實體按鈕時所發出的總線控制命令是一樣的。這也就意味著，我們可以遠程改變汽車的車內溫度了。