剖析Tesla全自动驾驶之路：从 Autopilot 2.0 到 3.0的硬件提升历史程序|特约评论
作者简介：Ryan Woo，XXXXXXXX
之前笔者曾在知乎上发表过两篇关于Tesla Autopilot 1.0的文章，感兴趣的读者可在知乎上查询“Ryan Woo：Tesla自动驾驶的前世今生”、“Ryan Woo：Tesla 自动驾驶2.0”。今天笔者将主要剖析Tesla全自动驾驶之路的最近一个程序——从 Autopilot 2.0 到 3.0的升级。
虽然 HW 3.0 FSD 全自动驾驶电脑的喧嚣已经过去一段时间了，不过还是希望这篇文章能够提供一个比较硬核的关于 Tesla Autopilot 硬件及其发展历史的介绍。。（
在下文中为了方便把 "Autopilot 自动辅助驾驶" 简称为 "AP"）
首先我们来看一下从第一代到如今第三代AP电脑的对比简图：
虽然我们这里说的是自动驾驶硬件，我们先来聊一个不起眼的东西：摄像头滤镜。
摄像头滤镜
AP 2.5 与 AP 2.0 在硬件上一个看似不起眼的区别，便是摄像头从RCCC滤镜换成了RCCB滤镜。
在说RCCC和RCCB滤镜前，我们先说个大家几乎每天都在用的滤镜——RGB滤镜，也叫做拜尔滤色镜：
RGB其实是分布着3种彩色的滤镜， RGB 分别代表着：R（Red）红，G（Green）绿，B（Blue）蓝，但是在实际应用中，为了更好的适应人眼视锥细胞的特性，我们——对绿光尤其敏感，所以我们实际使用了50%的空间安装绿滤镜，剩余各25%安装红和蓝滤镜，所以因此实际应用中应该被称为RGGB滤镜 。
当光线经过不同颜色的滤镜后，我们会得到相应的RGB通光量，再通过去马赛克算法来插值得到每个画素的红、绿、蓝色的组成数值，从而得到呈现我们所看到的彩色。
解释了我们常见的RGGB滤镜，我们再来看 Tesla 用到的 RCCC 和 RCCB滤镜，。这其中C代表着Clear，也即是白色滤镜。，于是当光线通过滤镜时，我们能得到更多的亮度资讯而不是色彩资讯，这样做的直接好处就是在昏暗的光线下，可以得到几倍于RGB滤镜的亮度资讯，这对于CMOS感测器面积有限的车载应用尤其重 ：
那么为什么我们需要一块红色滤镜呢？聪明的你应该能猜到了——因为人类世界很多警告资讯就是用红色／橙色代表的，例如红灯，、停车牌等，所以获取红色资讯远比蓝色，、绿色更为重要。
现在说完了RGGB和RCCC滤镜，RCCB就很好解释了：B也即是蓝色，所以 RCCB 就是 25%红色，50% 白色，25% 蓝色组成的滤镜[3]，那么为什么我们要加入蓝色呢？
因为随着技术的进步，RCCC 已经不能满足我们不再仅仅只需要获得亮度和红绿灯感知（RCCC），我们还需要更多的靠颜色来感知整个世界，如果说RCCC是最大限度做到辅助驾驶，让一切光线变得有利于物体有无的判断，那么RCCB就是让你在不牺牲亮度的前提下，最大限度的感知整个世界，这也正是全自动驾驶所需要的资讯量——我不仅要知道那是一个障碍物，我还需要知道那是一个什么样的障碍物，会对我的自动驾驶决断产生如何的影响。
在Aptina的RCCB演示图示中可以对比看见，RCCB 滤镜可以能够比参考的RGGB滤镜多出 3-4dB 信噪比，同时依然能保证影象的清晰度和接近的彩色还原 ：
看完了这不起眼的滤镜介绍，这里插播一个问题供大家思考：为什么Tesla HW 2.0 没有提供行车记录仪和哨兵模式呢？
360度环绕摄像头
在聊摄像头之前，我们先看一个有趣的视讯：
上传视讯封面
Tesla Model 3 Autopilot Dance
为什么仪表盘的车跳得那么欢快呢？
如果这就是 AP 计算时摄像头采集的资料，我是不是应该很担心呢？
先说结论：
1. 因为AP摄像头最佳工作状态时时运动时，静止或者慢速时会产生不可避免的显示问题。
2. 屏幕显示的动画是示意图，远不是AP实际得到的计算输入资料，因此完全不用担心AP的决策。
现在我就来解释这种看似可笑的显示失误是如何产生的，以及为什么我们不用担心 AP 的决策。
如前所述，AP HW 2.0 之后的系统装备了8个周边摄像头，由于视角的差异，摄像头与摄像头之间其实是有重叠的部分。
这就是摘取的一个AP状态时侧后，、侧左同时看到的一帧影象：——
非常正常的一辆阿尔法埃尔法从左后方开过来:
但是我们如果把时间再往后一点，阿尔法埃尔法侧后还没完全经过，车头确却进入了侧左摄像头的视角：
而如果我们看三个摄像头，侧后，、侧左和超广，这台阿尔法埃尔法甚至车头都没有了！
同时多了一个屁股留在左后视角中：
我们再往前看一点，左后干净了，但是左侧剩下一点车尾，而超广中居然仅有一个车头：
所以我们再去看刚才那个仪表"跳舞"的视讯，结合这里的视角想想，其实就是当车停止或者慢速的时候，摄像头在判断车的形状，、方向，、大小的细节时被这种切割的画面所干扰，得到了匪夷所思的跳舞效果。类似的，如果你仔细观察一辆车从你后方超车经过，你也会看到动画中的车会在接近你时突然靠近你的车道，似乎是要侧撞了，但是又渐渐回到自己车道，再安全远离。其实这些都是摄像头采集资料时，车在跨越集合部分时断层产生的错误影象。
那么我们究竟要不要在乎这种看似很危险的显示呢？AP 会不会认为旁道的车突然接近我而反向躲避呢？这里就要用到一点神经网络资料处理的知识，了——当输入资料的时候，我们是有错误标记的，那么神经网络的第一步就是尽可能标准化我们的资料（Normalization），所以对摄像头视野进行校准，对两个摄像头之间的重叠区域进行标记和取舍就是 AP 资料处理时的重要一部分，而这些恰恰是 AP 硬件决策计算前可以很容易解决的，。还记得你提车时那段几十公里的路校准摄像头吗？就是这个作用——每一台车的摄像头角度会有细微的差异，而这个校准的过程也会一直在背后进行，渐渐的AP电脑就会知道每台摄像头的像差如何，距离如何，重合的视角如何计算，后期就只需要套用这个计算好的补偿公式，就便能得到一个完整的360度视讯进行传递给 AP 的神经网络进行做决策计算。
所以现在你明白当我们看到那些好笑的"跳舞"的小车时，不用过度惊慌了吧？！当然如果Tesla 有足够的计算能力，他它也能在显示动画小车的部分做这样一个数据校正补偿处理，也许等到 HW 3.0 有足够算力时，他们会逐步解决这个显示问题。
Autopilot 车载电脑
在以前介绍AP 1.0 的文章中我详细解释了它的硬件构造和布局，这里我便跳过这部分，直接对HW 2.0，、HW 2.5 以及HW 3.0 进行比较和说明。
HW2.0，先说结论：HW 2.0 是赶工的产物，由于那次著名的AP事故 ，Mobileye 与 Tesla 的关系极速变冷，Tesla 只能把还在研发中的 HW 2.0 匆忙上架，具体赶工到什么样，我们可以通过电路板间接看出来。：
这是 NVIDIA 的 Drive PX 2开发基板，：
正面是两块 Parker CPU 模组：
NVIDIA Drive PX2 测试基板正面是两块 Parker CPU 模组
背面是两块 Pascal GPU 模组：
NVIDIA Drive PX2 测试基板背面是两块 Pascal GPU 模组
所以总共是：
4x Denver + 8x Cortex A57 CPU + 2x Parker GPGPU。
这是第一批 Tesla 2016 Model S AP HW 2.0 的主板，可以明显看到四个问题：
1. 主CPU附近有大量的基板留白；
2. 整个主板仅有一颗 Parker CPU 和一颗 Pascal GPU；
3. Pascal GPU 依然通过类似开发主板桥接的方式与主基板连线在一起；
4. 背面有大量的留白。
可以明显看出其主板的整体整合度并不高，基本就是NVIDIA 开发公版的简单套用，同时所有芯片加起来仅有：
2x Denver + 4x Cortex A57 CPU + 1x Parker GPGPU。
相较于NVIDIA Drive PX2 测试基板理论算力整整少了一倍，如果 NVIDIA 都不敢说自己完整版的Drive PX 2 可以做到L5 甚至 L4，Tesla 何德何能可以把仅有一半算力的平台做到全自动驾驶？
Tesla 2016 Model S AP HW 2.0 主板- 正面
背面：
Tesla 2016 Model S AP HW 2.0 主板 主板-背面
所以到这里我想你也能得到同样的结论：
这个HW 2.0 就是内外压力之下，Tesla 匆忙上架的产物，为了降低采购成本 为了降低采购成本，Tesla 仅仅选取了最核心的 Drive PX2 AutoCruise（理论计算效能仅有一半）先满足宣传和稳定民心的需要。接下来怎么走？ 我们站在2019年往回看，那会是风雨摇摆的两年。
2016年12月，就在 HW 2.0 释出后不到两个月 Tesla AP 主管 Sterling Anderson 便离职，而且带走了不少 AP 组的工程师和高管去自己的创业公司。
而失去了自己主管的Tesla 情急中找到了LLVM 编译器和 Apple Swift 语言的创始人 Chris Lattner 来领导 AP 开发，而这时的 HW 2.0 AP 就像襁褓中的婴儿，不仅硬件资源吃紧，整体软件也要从0开始研发，Elon Musk 许诺的2-3个月便能超越 AP 1.0 的计划彻底落空。最终顶着巨大压力的 Chris Lattner 仅仅只干了不到 6个月便潸然离去悄然离去，加入了 Google ：。
而购买了AP HW 2.0的车主甚至发起诉讼，控告Tesla 没有拿得出手的 AP 可用，就在这生死存亡之时，Elon Musk 终于给AP部门物色到了新的主管：——Andrej Karpathy，作为Musk 从OpenAI 挖来的大将，也是李飞飞的高徒，Andrej 临危受命，以一个研究人员的身份扛起了 AP 开发的大旗。
也在同一时间，Tesla 释出了 HW 2.5 硬件，但是整个过程非常低调，有黑客发现Tesla的线上配置系统突然出现了 AP3 程式码，才锁定了这个新的平台，Tesla 官方对 HW 2.5 一直都非常低调，只是唯一强调说这只是提供了冗余性，并没有实质性的改变，而直到第一台 HW 2.5 拆机时我们才知道，这一年的时间，Tesla 究竟做了多大的改进：。
在这张2017 Model 3 的 HW 2.5 主板上我们可以欣喜的看见：
1. 整体整合度空前提高，没有了留白；
2. 多出来一块Parker CPU 模组；
3. Pascal GPU 模组被直接整合到主板中，不再通过桥接方式连线；
4. 背面整合度同样满点，几乎没留下任何多余空间 ；
所以整体的计算能力提升为：
4x Denver + 8x Cortex A57 CPU + 1x Parker GPGPU
Tesla 2017 Model 3 AP HW 2.5 主板 主板-正面
Tesla 2017 Model 3 AP HW 2.5 主板 主板-背面
单就 AP HW2.5 主板这个区域性来说，其设计的紧密度和整合度空前提高，很难想象这是在资源有限，、不到一年的时间中完成的，这种整合度上的飞跃，甚至被拆解过Model 3 的名人 Munro 称之为 F35 上面才能看到的技术 。虽然依然没有完全达到 Drive PX 2 AutoChauffeur 的完整效能（缺少一组 Pascal GPU），但是设计和布局显然已非常成熟和老道，完全不像是第一次 HW 2.0 的青涩和没信心，同时少用了一组 Pascal GPU 也给我们留下一个问题：Tesla 究竟葫芦里卖的什么药，HW 2.5 的算力能实现预期的全自动驾驶吗？当然我们现在回顾这一切，都少不了感谢 Pete Bannon 和 Jim Keller 领导的 AP 硬件组的努力。
但是 Model 3 带来的整合度提升不仅仅是把 AP 芯片主板做到一块干净的主板上，他们还创造性的通过液冷把 AP 主板和MCU媒体控制主板通过夹心的方式组装成一块模组：——
Tesla 2017 Model 3 AP HW 2.5 + MCU 综合模组
这块模组通过三明治的方式把两块独立的主板整合到一起，再通过液冷共同散热 ：
Tesla 2017 Model 3 AP HW 2.5 + MCU 综合模组设计图
这与之前 Model S／X 那种 MCU 和 AP 分离式设计通过风冷散热高了又是一倍：
Tesla 2016 Model S MCU 模组 + 触控式屏幕
Tesla 2016 Model S AP HW 2.0 模组
Tesla 2016 Model S AP HW 2.0 模组 拆解
而为什么要如此激进的整合为一体呢？
当然是为了降低成本，提升组装效率，同时为了满足把HW 2.0 替换成HW 3.0 实现全自动驾驶的承诺。
由于充分考虑到了可替换性，HW3 FSD 模组或者说 HW 2.5 模组从一开始就是以 FSD 模组的设计为原型进行了定型，两者之间完全可以替换使用，功能上可以100% 替代，可见这需要非常强大的设计实力才能预估到短短1-2年中可提前预铺好可升级的能力。满足了相容性，自然就会一定程度上放弃扩充套件性，所以HW2.0 - HW3.0 是 Elon Musk 对老使用者的承诺，同时也是给自己的限制，要想获得更进一步的提升，未来HW 4.0，乃至5.0 很大可能会采用全新的设计以适应新的挑战。
好了，花了这么长的篇幅，我们终于进入到了 HW 3.0 的讨论，在下一篇中我会更加细致的解释为什么 HW 3.0 会是 Tesla 决胜 FSD 的武器， 以及 Model S3XY 能够实现FSD的可能性有多大。
后记：
这篇文章我前前后后改了有一年多时间，一直没有时间做完最后的润色，但是从最初的标题"从Autopilot 2.0 到 Autopilot 2.5" 到如今 Autopilot 3.0 都已经量产了。我终于还是觉得不能这样一直拖下去，就已有的资讯和结论来说还是能给读者提供一点干货，所以就先成文了。
