接上一期。Karpathy在ScaledML2020会议上的主题演讲专题>>
在针对Smart Summon智能召唤功能的分析中，Karpathy明确了对于参与其中的7个摄像头所获取的视觉信息，需要进行工作量相当可观的“融合”计算处理，这样才能获取完整的、有效的Bird-view视角信息，才能驱动Tesla车辆在自主的前提下完成完全的低速无人驾驶功能。但针对这个“融合”处理，却并不简单。按照Karpathy的分析，就是他们选择了完全不同于传统的“显性代码”/Explicit program理论去实现这个功能，后面篇幅我们将会做出解释。
提前需要注意的是，并非所有的Autopilot代码都是依赖机器学习（神经网络）来实现的，传统的显式编程手段（比如利用C++）和专家系统逻辑，一样可以写出绝大多数的Autopilot功能。【根据小编的理解，对于视觉识别，神经网络显然是更好的方式，但自动驾驶显然不仅仅只包括机器识别这一种Task，还有其它各种Task需要实现。】如果就仅针对Smart Summon功能，其中的Occupancy Tracker，Tesla可以选择传统程序实现手法（1.0 code）或者以机器学习为基础的2.0实现方法来完成。如下图所示：
上图代表着Autopilot的代码实现栈，代码/功能的输入是各类传感器，当然是以视觉信息为主，辅助以毫米波雷达和IMU等其他传感器输入；广义上的Autopilot输出，会直接驱动车辆的方向和油门。而整个Autopilot代码实现栈位于中心，处理各种各样的传感器数据并作出驱动指令。
并非只局限在Smart Summon，在Autopilot的代码栈中，显然code 2.0风格的代码比例正在逐步上升。按照Karpathy所介绍的实践经验，这种代码生产风格转换，也直接提高了Autopilot的AI团队的生产力，工程师将不再用特别关注具体的功能实现逻辑，而是可以通过对于训练数据的关注，和对于训练数据质量的筛选和监督，来间接让机器和AI自动实现相关代码功能。这就是所谓的“2.0 code”。
显然，2.0 code在整体软件功能中的占比越高，效率越高，且Autopilot整体功能并不受这种Code 2.0代替1.0比例的影响，从功能角度看，他们是一致的。Karpathy提到自从他加入Tesla的AI部门两年半时间里，Code 2.0的占比已经大幅度上升了。这也暗示大家，Tesla这家公司或者Autopilot的这个软件实体，利用基于神经网络为基础的机器学习比例，已经越来越高了。
以Smart Summon的功能实现为例子，Autopilot就是用了code 2.0的方法。上图所示，对于参与智能召唤摄像头的数据处理，逻辑上使用了神经网络为主的方法，包括Fusion layer（对于图像进行缝合操作）和BEV Net（对于图像进行视角转换到俯视图操作）。
基本的业务数据处理流程如下：
1 摄像头感知视觉数据，并送回FSD硬件；
2 FSD硬件上的AutopilotBackbone对于数据进行共性处理，比如提取视觉信息的特征（边、角、点等信息），形成各个摄像头数据的feature maps。关于Backbone的定义请参见之前的Multi-tasks的文章；
3 之后数据被送入Fusion layer进行缝合处理，在这里不同摄像头的数据被融合到一幅图型文件中去，并完成从摄像头天然的获取视角到Bird-view俯视图视角；
4 接下来是Temporalmodule，主要是针对上一层的网络输出进行数据的smooth处理；【不太确定这个步骤的具体含义】
5 最后进入BEV Net，完成top down视角的数据展示，最后则输出在Smart Summon应用中所必须识别和跟踪的目标，包括：动目标、道路标识线、道路边界三种。
综合以上，因为并非是显式的代码/程序完成了这个功能，而是依赖神经网络对于输入数据判定后产生的预测性质的输出，因此最后的输出我们称作，Bird’s eyes view predictions（预测而非识别）。这里还是以Smart Summon功能为实际案例，看看最终的Bird-eyesview预测输出的工作效果。
上图中两部分数据。上半部分是实际的3个摄像头（并非全部的摄像头数据）的真实数据，并且经过Autopilot的backbone处理之后，已经可以提供道路边界（红色线条）以及“道路线标识”（蓝色线条）的识别结果叠加显示。上图中的下半部分，则是经历了完整的Smart Summon功能网络处理的BEV俯视视角结果。
最左侧的是Ground-Truth数据，也就是实际这个路口的俯视图，作为参照物而存在；最右侧的则为一幅处理不完整的BEV俯视视角的路口图，基本上是一幅垃圾，没有参考价值。以这幅图为目标，我们可以看到图形底部的小兰点儿使车辆自身的位置，则可以评估，在距离自车车身很近的地方，似乎这幅俯视图还能基本表达得出车身和道路边缘的相互关系，但是稍微距离车身远一些的位置则是一塌糊涂。这个结果也不出乎意料。因为就车辆车身摄像头的安装位置来说，其视场内距离很近的地方，显然是还可以判断相对位置的；但是在视场内距离车身较远的位置，甚至最远到路面和天空的交界之处，则道路信息是压缩到一起而基本是无法分辨的。
这是为什么第二行的最右侧俯视图质量非常之差以至于不可用的原因。
但如果是经历我们前述的Autopilot完整的smart summonBEV流程和网络预测处理的实际输出，则是第二行中间这幅图形（俯视图）。可以目测识别，即便没有精确吻合左侧的实际交叉路口的俯视图，也是相当精确了。这个态势信息，已经足够提供给Autopilot的Smart summon进行路口穿越动作了。因此我们会有这个认识，基于code 2.0的功能实现，确实可以协助autopilot的具体功能落地，而且精度非常高。在Smart summon的这个功能中，他协助了软件处理靠近地平线的哪些模糊信息，从而复制出精确的俯视图。
一家之言，欢迎讨论。下期我们继续讨论Autopilot的技术现状。
车右智能
info@co-driver.ai
备注：
1 题图1/2/3来自于Karpathy在ScaledML会议上的演讲“AI for Auto-Driving”，https://www.youtube.com/watch?v=hx7BXih7zx8&t=1240s；
2 题图来自互联网。
相关专题：
特斯拉Autopilot机制的最新介绍 ——Karpathy在ScaledML2020会议上的主题演讲 （1）
特斯拉Autopilot机制的最新介绍 ——Karpathy在ScaledML2020会议上的主题演讲 （2）
特斯拉Autopilot机制的最新介绍 ——Karpathy在ScaledML2020会议上的主题演讲 （3）
特斯拉Autopilot机制的最新介绍 ——Karpathy在ScaledML2020会议上的主题演讲 （4）
