为什么需要去除高精地图？

6 月 17 日， 理想家庭科技日，理想智能驾驶交卷，郎博气定神闲，给出了理想智能驾驶自研的阶段性结果。

出乎意料的，整体功能交付水准远远超出我的预期。

毕竟理想宣布全栈自研智能驾驶在蔚小理三家中最晚，但是交卷的速度却没有落到最后，甚至有后来者居上的态势。

而在众多公司对高精地图的成本头疼不已的时候，理想这次发布会示范了一个优秀的解决方案，将无图化真正部署上车。

01

为什么需要去除高精地图？

使用高精地图的目的是，和实时定位搭配找到对应车道位置，加上实时感知车道线进行小规模修正，最后达到循迹或者变换车道上下匝道的目的。

这里就会有一个问题：对于实时变化的场景或者定位精度不准，对高精地图依赖越强，产生的问题就会越多。

比如施工后的车道如果发生了改变，而高精地图也没有进行实时更新，同时实时感知车道线的置信度不高，此时自动驾驶系统会沿着原来的绘制车道线行驶。

之前高速 NOA 刚刚量产发布时，很多用户会抱怨匝道乱打方向盘问题，一部分原因来自于这里。

当然后来通过一些工程方式，例如地理围栏，就是部分位置即使有高精地图也不会提供功能降级，或者车道线感知能力提升后提高感知权重的方式获得了解决。

但是来到城区，一切都不一样了。

城区的道路相较于高速复杂得多，如果把红绿灯路口当作是匝道的话，一段 1 公里的路程难度可能相当于高速上 100 公里。用高精地图去完成城市 NOA 成本极高，城市内部道路更新频率远远高于高速道路，需要一个测绘车队常年无休更新地图。

同时，某些城市的内部道路由于密级要求，是不允许测绘的， 这也就很大限制了功能的可用位置。

高精地图贵而且不灵活， 面对城区的复杂路况是不适用的。

所以城市 NOA 短期小范围推送尚且可以使用高精地图， 但是长期来看，想要更快推广，或者降低成本从智能驾驶部分获得正向现金流的话，去除高精地图势在必行。

理想的 Neural Map Prior 就是为此而生的。

02

NPN 先验网络‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

理想的 Neural Map Prior For Autonomous Driving 是什么？

简单来说，主要是两个点：

离线（云端）特征更新（Update，Offline Global Map Prior update）：看一次路口看不清楚，那就多看几次。

在线（车端）地图推理（Online Local Inference）：这次路口没看清楚，就想一下上次是什么样的，再看。

在线地图推理，结合以前的信息进行感知，看的更远。

在线地图推理这里使用了公认最先进的智能驾驶感知技术栈 BEV 网络作为基础， 从俯视的角度将每个摄像头的信息组合到一起，这样各个摄像头之间的信息能够共享，识别能够更加精准，稳定。

但是实时感知的局限性在于，在复杂的道路上，常常需要移动一定的角度才能获取足够多的信息。

对于决策规划来说，感知信息不够多和精准让决策变得很艰难。

对于人类驾驶员来说，一般我们会通过经验，即使没有看到目标路口的车道线也可以做出正确的操作，因为我们有之前的经验信息。

这里的整体工作流也非常类似，使用之前的经验，进行信息补全，最后保证感知结果的更加可靠。

当然，整体来看，这与实时感知车道线与高精地图信息融合作为最终环境感知结果的方法依然类似，只不过这里使用的并非是高精地图测绘结果作为输入，而是特征中间值作为隐式输入。

这里有一个很有意思的「隐式表达」的概念。

常规的已经感知出车道线结果再与高精地图进行融合的方式，可以称之为：「显式融合」。

即具有相当的可解释性，有经验的工程师是可以完全看懂的，也可以被直接描述。

而理想这里的表达方式更加倾向于隐式表达，也就是，一切规则由神经网络自行学习完成，无法被直接描述。

模型能力逐渐变强的当下，能够覆盖更多子任务，很多中间层显式的表达可以用隐式的方式完成，例如原来单摄像头感知后融合，到现在多摄像头 BEV 完成的隐式融合。

理想的先验地图和感知结果融合的方式，都属于此列，这也是算力充足的情况下，人工智能发展的趋势。

03

离线地图更新，实时云端对齐

对于某个新的感知结果，是否需要被实时更新到云端离线地图中去？

这个问题其实也没有这么简单。

因为不论何时，新感知的结果与离线地图都是有一定差异的，如何规定学习新的感知结果和忘记旧的信息规则也是一件不容易的事情。

在理想的这个方案里，依然使用了隐式学习的方式去规定，并使用了一种 Gated Recurrent Unit（GRU）门控循环单元变体结构完成，这样也保证网络的长时记忆能力。

简单来说，规定一个忘记比例，一个更新比例，这两个都是一个小的神经网络单元，输入都是实时感知的结果和离线地图查询结果，让神经网络自行学习两个比例。

最后再将这两个比例与实时感知结果和离线查询结果进行操作，最后得出新的离线地图更新。

这里再次呼应了上文中提到的隐式表达概念，隐式决定如何更新地图。

实际上也就是，让神经网络知道，往什么方向去更新地图才是对的，而不是规则化这个任务。

04

一些疑问和工程化问题

定位问题

关于离线地图查询时的定位问题这里并没有说明，事实上，之前 Tesla 在 AI Day 上也提到过 Spatial RNN 众包建图方案，与理想本次提出来的方案具有非常强的相似性。

但是这些任务都基于一个非常强的假设，因为需要有不同时空同一位置的地图更新，也就是说定位需要非常准确。

但是，实际上，车端的定位是无法准确到满足这个强假设的。

不准确的定位可能在查询整体离线地图时会出现偏差，也就会影响最后的感知结果。

所以一般来说，还需要实时位置特征去满足定位的要求，这一点应该也需要工程师们持续的努力。

这里有一个细节是，是否可以在查询地图时也加入一个隐式网络，将目标路面特征作为查询的来源，而不是纯显式地图定位表达。

地图的成熟度自动确认

在发布会上，郎博提到一个路口成熟度的概念，也就是在多次更新之后，离线地图会达到一个可以被使用的阈值。

关于什么时候可以被使用，郎博并没有给出来， 这里假设两点：

实际高精定位车辆采集地图，并且与目标比对，但是此时又回落回到高精地图采集的传统工作流中去。当然我相信，在早期项目设计开发时，一定需要实时地图采集作为真值训练网络的。

实时特征比对，一定存在一个合理的误差值，达到该误差时，路口结果会被释放。这是积累了足够多的数据之后，数据驱动产生的效能。

存储和实时云端互传

在论文中，提到使用 Nuscenes数据集作为验证，整体 2km X 1.5 km 的小区域，0.3m 的分辨率，使用了 11GB 的存储空间。

关于本车如何使用这些数据，如何从云端下载数据，事实上也是一个需要实践解决的工程问题。

因为如果实时云端查询并且下载地图先验特征，常常会因为网络问题造成数据并不能实时传输完成，这样无法完成实时地图更新。

我的猜测应该也是与高精地图的使用方式一样，根据地图定位提前下载小片区的地图，例如通勤模式，可以将整个通勤范围内的地图提前下载并且查询由车端实时完成。

关于本车数据不断上传问题，并且理想并没有实时绘制地图，保存的只是地图的中间值特征，不具有地图拓扑含义，因此应该不算测绘，不需要特殊的测绘资质。

这也是一次数据驱动面对数据保护条例的小小胜利。

写在最后

自动驾驶感知发展的趋势非常明朗，即从越来越多的信息中获取输入，保证感知结果的精确。

从 2D 直视图到 3D BEV 感知融合保证多视图的信息共享，再到 4D 时序融合保证前后帧的预测，再到理想地图先验多时空信息的融合，我这里想简单称之为 5D 平行时空融合。

理想智能驾驶走在了正确的道路上。

有个理想车主问我，为什么理想这么快就可以拿出来一个这样的 Demo 产品？

我想了想回答：现在的自动驾驶开发，绝对不存在一种天顶星算法，能够直接将竞争对手产品斩落马下。

而最重要的是一步步的耐心和极强工程能力。

如果必须要回答这个问题的话，答案只能是：后发者找对了方向，省去了一大部分探索和拉扯的时间，并且能够持续专注地开发。

在技术栈开始变化时，一切之前的积累， 可能都只是拖累。

当然， 这一切都建立在 Demo 的水准可以大规模推广使用，并且能如期交付的基础上。

不过现在， 我想提前恭喜理想同学，在去高精地图的战场上，开出了响亮的第一枪。