CAN总线：用编程来控制汽车

自动驾驶汽车依靠人工智能、视觉计算、雷达、监控装置和全球定位系统协同合作，让电脑可以在没有任何人类主动的操作下，自动安全地操作机动车辆。

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控制代码了，这些代码与我们按下汽车物理实体按钮时所发出的总线控制命令是一样的。这也就意味着，我们可以远程改变汽车的车内温度了。