城区导航智能驾驶，真能让你解放？

本文来自微信公众号：九章智驾 （ID：jiuzhangselfdriving），作者：萧谭辉，首发于知乎，题图来自：视觉中国，原文标题：《城区导航智能驾驶难在哪？写在小鹏/华为-极狐NOA释放之时》

一、什么是城区导航智能驾驶

本文要讨论的城区导航智能驾驶，指的是在HD-MAP（高精地图）或类似功能ADS地图加持下的，可以实现特定城区范围内的（一般是高精地图范围内或者版本发布Geo Fence（地理围栏）内的）点到点智能辅助驾驶。

编者注：近来，也有不少公司开始尝试在城市导航智能驾驶方案中摆脱对高精地图的依赖，即所谓“重感知、轻地图”路线。

与一般意义上的tesla的AutoPilot（类似的还有小鹏的LCC，华为-极狐的ICA）这种不带点到点导航、路口不会拐弯不能处理红绿灯，一条道走到黑的简单车道保持+跟车的功能相比，城区导航智能驾驶需要人类驾驶员接管介入的概率更低，整体体验更连贯、更灵活，更符合普通消费者对于“自动驾驶”的认知（见图1）。

为了描述方便，以下统一用ego代指配备了城区导航智能驾驶特性的“自车”。

高精地图/ADAS地图可以提供海量丰富的各类图层与各种信息，在一般消费者可感知的角度，相比于简单的车道保持+跟车功能，城区导航辅助驾驶最大变化主要是以下4个方面：

图2 Traffic_light lane Association

图3 HD—MAP中海量的各种信息

针对这种功能，各家实现的技术路径大同小异：感知（包括目标检测/跟踪/多传感器融合），预测采用14年后爆火的深度学习技术栈，定位/规控/HDMAP则在以前机器人学的技术栈上通过不断演化。各家目前量产的名称略有不同：小鹏叫NGP（城区），华为-极狐叫NCA（城区），蔚来叫NOP（城区），长城叫NOH。

N：即Navigation：导航，对于城区智能驾驶场景经常被宣传为“ 点到点”

下面为了讨论方便，统一名称为城区导航智能驾驶。事实上，这个功能各家已经“跳票”好久，小鹏之前承诺今年初释放城区NGP，华为-极狐承诺去年底释放城区NCA，都已经跳票半年到一年不等，而蔚来的NOP（城区）则到今天都还没有踪影，实际上我个人认为今年底之前蔚来都不会释放城区NOP。

可见，如果说对现阶段自动驾驶技术实现难度排序的话，那么城区导航智能驾驶技术是绝对的、当之无愧的“珠穆朗玛峰”。

二、为什么等了这么久之后，小鹏与华为-极狐又几乎同时释放了？

近期国内开放了部分城市的城区高精地图作为试点，于是小鹏和华为-极狐开始了首发城区导航智能驾驶大战：9月17日，小鹏率先在其公众号的宣称自己已经开始向部分P5用户推送广州部分路段首发城区导航智能驾驶功能（NGP），并邀请大量媒体试乘试驾造势；结果9月23日，华为-极狐公众号官宣，已经向深圳部分用户推送全量深圳城区导航智能驾驶功能，“截胡”了全球首发城区高阶导航智能驾驶称号。

图4 小鹏与华为-极狐争夺城区导航智能驾驶首发排名

不过其实我猜两家的策略应该是一致的，都不敢同时放开大量普通消费者使用，均是先采用极其极其极其极其个别的友好用户（猜测每家普通消费者数目得到体验入场券的人不会超过小几十个人，基本上选中了就可以回家买彩票了）优先体验的方式打开城区导航智能驾驶。

而蔚来、理想，甚至是刚刚开过AI DAY的着重笔墨讲城区智能驾驶的毫末智行，均未见量产产品踪影。

三、为什么各家对于释放城区导航智能驾驶都这么谨慎？

因为城区导航智能驾驶实在太难了。

首先说一个结论，如果把人类司机驾驶员的平均水平作为Ground Truth来比对，目前各家的城区导航智能驾驶在安全性、体验、效率均需要继续打磨。

城区导航智能驾驶是corner case的集散地，是长尾挑战的史前巨坑。一般情况下，Robotaxi公司由于其成本压力低，其Sensor Set的配置几乎是最豪华的；其造型外观要求也没有量产车那么高，其Sensor Layout也是最优的（标志性的花盆顶激光造型），在这种情况下，其城区场景下的MPI水平一般都在几十左右。

图5 RoboTaxi公司典型的传感器布局

这里请有些同学收起来加州DMV的统计报告，那份报告中的MPI数据与其说是通过MPI比较各家公司的技术水平，不如说是通过MPI比较各家公司的道德水准。不过excel里面有些公司的disengage原因还是值得一看的，写的很真诚。

也就是说，国内最高算法水平、最佳sensor Layout的公司，在国内每天平均通勤距离（有统计一线城市的平均通勤距离大概在每天30km左右）下使用时，平均下来一天有1次紧急接管的可能性。

要知道，对于量产车而言，坐在驾驶位上的是普通消费者，而不是“久经考验”的智能驾驶公司的Test-Driver们，其对于系统表现的预见性与车辆操控的熟练度远远比不上被自家系统天天“训练”的Test Driver们。所以各家在释放城区导航驾驶上非常谨慎，也就可以理解了。

这也就意味着，如果有100辆车开启了城区智能驾驶，每天的潜在可能的紧急接管数目在100次左右，如果有1000辆车，那么潜在的接管次数就是1000次左右。这个数据下，指望普通消费者像被自家系统天天“训练”的Test Driver们一样，在出现紧急情况下都能救回来显然是不现实的。

不过也不用过于悲观，Tesla FSD在闹市区的MPI是个位数，有兴趣的同学可以没事了去油管一个一个视频数数……注意油管上很多Tesla的测试路况其实比国内城区路况差得远，数的时候要大概挑一挑。

四、城区导航智能驾驶到底难在哪?

下面以为由易到难的排序，去描述城区导航智能驾驶的难题。

1. HD—MAP

高精地图其实本质上已经不是一个技术难题，而是一个成本难题。一般同学可以把高精地图当成一个异次元世界，ego从某种程度上来说，是在这个异次元世界中行驶，再把ego“看见”的其他目标（人、车、骑行人、红绿灯结果）投射到或者匹配到这个异次元世界中，从而“理解”这个异次元世界，最后达到看起来像是在现实世界中行驶的目的。

事实上，这个原理跟家里的扫地机器人没有太本质的区别。现阶段的自动驾驶就是人工智能（特别是计算机视觉）与机器人学的集大成者。

这样会带来两个问题：

①这个异次元世界的表达与真实物理世界的贴合程度直接决定了城区导航智能驾驶的水平

即HD—MAP的制作工艺质量、反应现实世界元素的丰富程度、拟合现实世界人类开车习惯的准确程度直接决定了城区导航智能驾驶的水平。

以这个异次元世界中道路元素表达和真实物理世界中人类开车习惯的匹配程度举例：高精地图中ego所行驶的车道叫做lane，你可以把他理解成火车的轨道。ego在绝大多数情况下会沿着这条reference lane行驶，极其个别情况下，会做一些“看上去类人”的比如避障一类的操作。

地图中的reference lane（特别是路口，merge等道路拓扑复杂的场景下）的制作水平直接决定了ego的行驶合理性甚至是安全性。且各家的制作水平不一，在lane内（或者更大策略空间）策略空间的优化水平参差不齐，这种“看上去类人”的动作很多时候是“看上去智障”的操作甚至是“看上去危险”的操作。以至于在各家智能驾驶经常测试的路段，只要稍微用心观察就可以轻松分辨出车辆是否处于智能驾驶状态。

图6 在HD—MAP的Reference Lane中行驶的Ego

从这个角度看，与其说城区导航智能驾驶是智能驾驶小汽车，还不如说是“智能驾驶”小火车——沿着既定的HD—map给出的“轨道”行驶。“轨道”铺到哪里，“小火车”就开到哪里，“轨道”修得不好，“小火车”就开得不好。

图7 “智能驾驶小火车”的轨道

与此类似的，还有hd—map中是否包含红绿灯倒数灯信息，在无红绿灯路口拓扑的处理方式，hd—map中环岛的道路拓扑建立（实际上真实世界中，人类开车处理环岛都很复杂），等等。

现实世界中无穷复杂的道路场景，如何在hd—map中合理、类人地表达这些人类社会中已经潜移默化约定俗成的开车习惯是非常困难的。很多时候自动化的算法处理在很多场景下并不能尽如人意，仍然需要大量的人工介入check和精修。这会大幅度增加高精地图的制作成本。

②真实物理世界路况的实时变化及时同步到异次元世界中非常困难

即维护高精地图“鲜度”成本极高，且现阶段城区导航智能驾驶技术不能很好处理这种情况，可能会导致严重后果。

这也是Tesla掌舵人Elon Mask频繁diss  Waymo高精地图路线的关键原因。

图8 We briefly barked up the tree of high precision lane line [maps]， but decided it wasn't a good idea. by Elon Musk

整个高精地图bring up制作工具链及其复杂，国内目前完全掌握的玩家并不多。再加上国内城区道路基建与道路变化相当频繁，要维持HD—MAP的“鲜度”，随着基建与道路变化进行更新的维护成本几乎无法衡量。（要不怎么叫developing country，我没搞自动驾驶的时候从来不觉得国内的城市基建有这么频繁）

极端情况下，甚至会出现A路段在修路，地图情报部门通过种种渠道主动或者被动地得知以后，开始更新A路段的作业流：派出地图采集车采集，采集数据回传，地图融合制作，更新A路段Tile，转内部测试Bugfix，最后商用发布推送DOTA到车端，一套流程走下来操作猛如虎，最后发现A路段已经修路完成“恢复原状”……

一方面，是各家图商就算不计成本，也很难在一定周期内（比如一周甚至是一天内）更新HD—MAP的现状，而另一方面，在城区导航智能驾驶之中，如果出现了高精地图“鲜度不足”的问题，则系统便很难应对该场景。

比如上述的A路段在修路，在原来直道的基础上修出来一条大大的弯道，那么Ego在接近这个弯道的时候，很可能会仍然沿着高精地图中的“直道”行驶，从而造成危险。

上图是某厂商的事故视频，有可能当时使用的功能并非城区导航智能驾驶。不过这个事故场景非常的Match高精地图“鲜度”不足情况下可能产生的严重后果。实际上，这个场景几乎和American Flight 965的空难场景如出一辙，下来看看有没有时间专门写下。

如何应对高精地图“鲜度”不足的问题，就成为各家城区导航智能驾驶和众多robotaxi公司共同面对的问题。而现阶段解决方式大家也都大同小异：使用实时感知到的静态道路信息作校验，当发现实时感知到的静态信息（主要是车道线、道路结构拓扑、道路硬边界比如curb、红绿灯等）与高精地图中预制的信息相差很多时，触发下游进一步处理比如提示驾驶员接管等。

比如在一些OEM的SOR/RFQ中，要求系统在发现HD—MAP“鲜度”不足时，ego可以按照实时感知的静态道路信息继续行驶而非直接退出智能驾驶系统。

然而，在很多时候这种处理是一种悖论：这种处理本质上是相信车端实时感知的置信度高于预制的hd—map数据置信度，认为前者可以校验后者甚至取代后者作为下游预测—规控模块的输入；可既然我们有一个“强于高精地图”的实时感知信息源，那还需要高精地图做什么呢？

而另外一种思路是比较promising的，就是使用实时众包构图的方式，类似Mobileye的REM，华为-极狐的Roadcode-RT，Tesla的2021年AI day也对他们类似的技术有过描述，相信小鹏也有类似的技术路线。

一个常见的误区是：Tesla没有使用HD—MAP。Tesla确实没有使用用Lidar点云生成的“HD—MAP”， 不过是自己定义了新的MAP的格式，把“喵喵“叫成了”咪咪“。这部分工作可以参考21年Tesla AI DAY与华为智驾部门天才少年秦通的工作：RoadMap: A Light-Weight Semantic Map for Visual Localization towards Autonomous Driving。

毕竟去年华为智能驾驶部门前总裁的采访中，已经非常明确剖析了传统HD—MAP的种种问题（当时华为叫Roadcode-HD），算是给各家讲明了踩坑的经验。目前各家的名称有区别，不过其本质都是在单车上使用slam技术，经过一定程度的融合后上传云端，最后在云端实现fleet级别的地图数据融合。不过在国内由于法律法规的限制，目前这种方式还没有大规模商用的先例（起码我没看见，如果有的话请评论区提醒下）。

2. Perception（Obj_Detection，Tracking，Mutli_Sensor Fusion）

在感知上，城区存在着大量无法解决的corner case（有一些人称之为“弱势场景”？）：各种类型的遮挡检出、千奇百怪的各种实体交通参与者、每个城市（甚至一个城市不同区）种类繁多的红绿灯样式、从不相同的施工场景和道路障碍物……只要存在一个漏检，就是一次By force 的 Disengagement。

图9 各种奇怪的的红绿灯，甚至还有专门的Git（https://github.com/Charmve/OpenCC）

虽然这次发布城区的小鹏和华为-极狐的都有Lidar加持，但Lidar并不是一个完美的传感器。

其实在很多场景下（阳光直射，雨天路面积水，高反障碍物，雨天黑车，超近距离盲区，烟尘雨雾）下，Lidar的表现都一般甚至可以说是“很差”——绝大多数LIDAR典型工作频率为10Hz，考虑到误报，几乎所有厂商的算法都会滤波1~2帧，这在城区极端场景（鬼探头）下是比较致命的；且Lidar需要消耗大量算力才能发挥其对动目标、通用障碍物等的检测，在目前捉襟见肘的Soc算力情况下是个挑战。

至于多目标融合……真正在做融合的同学应该很清楚，无论是所谓的后融合、特征级融合还是前融合，本质上都无法消除漏检、误检，甚至融合后的结果，都可能拉低原有的某单一传感器的检出表现，这一点在Tesla 21年AI DAY AK的报告中已有明确的阐述。

目前所有的你能说的上来的智能驾驶恶性事故，无一例外，车辆都在事故发生的ROI配备着多传感器冗余做融合，然而最后的结果我们也都知道了。

图10 前向冗余传感器ROI内事故

而假设——

1、对于感知：我们不计成本，使用超高算力的SOC，堆叠各类Sensor形成冗余达到完美感知；

2、对于HD—MAP：在一个限定区域内不计成本，所有地图元素均人工标注，给出完全类人的语义信息，并假设能做到实时更新从而获得完美HD—MAP。

我们就能解决城区导航智能驾驶问题了么？答案是不能。因为城区导航智能驾驶最难的部分，其实不是HD—MAP和感知，而是预测和博弈。

3. Prediction

预测是使用感知到的目标信息（包括目标heading、速度、加速度、历史观测、目标类别等），辅以高精地图信息（eg：他车在直行车道上，且为绿灯，大概率下来的运动趋势就会直行通过路口），在道交法规或者commen sense的基础上（比如VRU即弱势道路参与群体会遵守红绿灯），对目标交通参与者进行后续3到X秒内的运动趋势（Trajectory，Reachable Set or Occupancy Grid）进行预测。

然而上面的例子可以说是最简单的预测，大家依然可以举出无穷多的反例：他车在直行车道上，但是没有直行，而是左拐了；VRU（弱势道路参与群体）没有遵守红绿灯，直接从遮挡中窜出；再有些公认的更难一些的例子：比如城区的无保护左转场景……

图11 他车在直行车道上，但是没有直行，而是左拐了

图12 VRU没有遵守红绿灯，直接从遮挡中窜出，实际上这个case其实不是特别极限。

如果说在只有机动车参与的高速场景下，他车基本上都遵守交规，其意图预测总体可控；那么在城区特别是低速VRU（弱势道路参与群体）比如行人、骑行人的预测基本上等同于“算命”。而在城区场景下，对弱势道路参与群体的预测恰恰是保证ego安全行驶的最高优先级的目标。

诚然，我们可以挤出来一些有限的SOC算力做一些例如行人Skeleton，甚至是Face Detection去给预测提供更多的信息，用以提升预测的准召；但基本可以想象，这也只能非常有限地提升预测模块的能力，而通过skeleton，face detection等肢体语言想准确的预测VRU的行为，可能要把三季lie to me 加入预测模型训练大礼包……

4. 交互式预测/社会化博弈（Reaction Prediction或Social Interaction）

下面为了描述方便，将用词统一为“交互博弈”。

首先我们来看一个例子，还是华为-极狐在21年上海车展的城区导航智能驾驶视频节选，横穿的行人明显有一个发现ego以后停止的动作，并在较短时间内起步，再次穿行ego前方。

图片来自42号车库过往的作品。图14 这个场景，经常开车的同学应该很熟悉，很多时候我们开车，发现前方有一个人要横穿马路，踩下刹车，同时行人也看见了我们，也停止了。时间仿佛静止了1秒钟，你发现他没动，他发现你没动，于是你踩油门起步，他迈开腿前进，于是你踩刹车，他停止，于是奇妙的俄罗斯套娃开始了……

视频可以看到类似的套娃式的交互博弈互动，这种博弈天然的存在于ego各种交通参与者之间。类似的问题还有如ramp merge in场景下的ego与他车的博弈，无保护左转下的ego与他车的博弈。可以说，在整个有人类参与的城区的驾驶环境下，极端场景不可穷尽，人类的博弈策略几乎完全无法公式化表达。

图15 实际上，VRU和人类司机一样，存在大量的Legal Norms之外的甚至是Social Norms之外的行为

这也就导致在城区智能驾驶场景下，只要还有人类这种交通参与者存在，就无法“安全地”实现城区导航智能驾驶，更别说一众robotaxi要做的“driver out”了。

如果说感知、预测的问题都可以用数据驱动，靠着model见过足够多的数据来解决，交互博弈我个人认为已经超出了现在人工智能可解决的能力范围了，可能需要所谓的“强人工智能”来解决了。

正是因为城区导航智能驾驶有上述这么多难题存在，很多问题其实连学界都还在研究，是属于问题本身都还没有明确定义的开放问题。本次小鹏，华为-极狐释放城区导航智能驾驶在“跳票”严重的情况下还如此谨慎，仅给极其个别的普通消费者开放，也就成为了意料之中的事情了。

五、与各家已经释放的高速导航智能驾驶相比，城区导航智能驾驶的系统策略有什么不同？

首先说结论：如果说高速导航智能驾驶最高优先级是“保证自己不出事”，那么城区导航智能驾驶的最高优先级是“保证别人（特别是VRU）不出事”。

对于高速导航智能驾驶而言，无论各家怎么宣传，其策略直白点说，都是驾驶体验大于行车安全。各家大可以说自己是L2系统，主体责任在驾驶员。

高速场景相对可控，交通参与实体没有各式各样的VRU，基本上只有各种车辆且绝大多数情况符合一定规则行驶，这个时候只要保证ego没有非常突然或者激进的横纵向行为即可。以Tesla为例，很多时候会忽略大量的风险场景（甚至是系统已经识别并且显示出来的风险场景）。

你能发现在驾驶tesla的过程中，大量的相邻车道车已经越线侵入Ego车道，甚至是在感知他车不准、heading严重摆动的情况下，ego没有任何反应而是维持原有行驶速度和轨迹前进。

而一旦进入城区，在城区导航智能驾驶的场景下，不论各家再怎么说自己是L2系统，承担L2系统的责任，其实都是非常苍白的了。

因为在城区场景下，任何一个与VRU的恶性事故，都几乎是一个车企或者供应商不可能承受的，这事实上已经进入了一个对L4级别自动驾驶车辆的要求范畴。

图16 2018年，49岁的Elaine Herzberg在坦佩市，亚利桑那州推着自行车过马路时被一辆正在路测的Uber自动驾驶汽车撞死，该事件直接导致Uber被吊销路测执照，最后整个自动驾驶团队解散

在城区导航智能驾驶需要cover的场景下，安全不再只是ego的安全，而是更多的要保证和Ego交互的城区内各式各样的VRU的安全，这就要求整个系统调教的大策略是安全大于驾驶体验。

这与之前各家释放的高速导航智能驾驶的策略有着设计大原则的本质区别——背后牵扯到感知/预测模块报出策略（如何Trade off precision 和 recall？），博弈/规控模块处理策略（与VRU是否博弈？怎么量化场景处理的激进/保守程度？），系统如何在保证一定体验连续性的情况下确保司机在环，时刻关注ego行为并随时接管车辆？体现着整个系统的CTO/技术领军人的对整个自动驾驶的Insight，技术前瞻性和全系统视角能力。

而这几年很火的数据闭环本质还是用“L2的思想”来解决城区这种L4要求的问题——数据闭环试图用发生事故或潜在事故的弱势场景数据来解决城区导航智能驾驶的问题，这几乎是有些“亡羊补牢”的意味在里面的。

如前所述，不同级别的智能驾驶（L2 VS L4）使用的算法和解决问题的方法论应该是有巨大差别的。本质上，城区导航智能驾驶应用的场景是典型的长尾小样本，而且绝不是Close Set而是Open set的问题，要求在Worst  Case下整个算法设计有比单纯的数据闭环复杂的多的保障，整体的Benckmark也要也要更倾向于Worst Case。这也就意味着整个系统准出的Test case分布更倾向于Worst Case从而与符合系统调教的大策略：安全 >>> 行驶体验。

当然，数据闭环虽然不是城区导航智能驾驶的Silver Bullet，但是做做预标注什么的倒是挺好用的。

六、在这种情况下，普通消费者需要注意什么？

直白点说，所有厂商（包括Robotaxi公司）说自己不能宣称L4只能宣称L2是法律法规的原因都是借口。不要管车厂的销售、外面的推广广告如何天花乱坠，大家需要知道的是：

1. 现阶段，如果说高速导航智能驾驶确实可以一定程度上减轻人的驾驶负担的话，那么所有厂商的城区导航智能驾驶绝对不能减轻你驾驶的负担，特定场景下绝对会加重你驾驶的“紧张感”。说直白点就是ego会自己产生一些让普通消费者认知范围之外的，意料不到的“迷之操作”并直接引起事故。

请时刻关注路况并紧握方向盘！

2. 与AEB，ACC等成熟的L1功能不同，不止我们国家，整个业界都没有对城区导航智能驾驶的量产放行标准。各家厂商水平绝对参差不齐，请不要体验过A厂商的功能就觉得B厂商也大差不差，或者看过的网上媒体评测/demo的视频就认为你买的相同厂商的量产车有类似水准。

个别厂商的智能驾驶功能（这里不仅仅指的是城区智能驾驶）还有较大提升空间。

请时刻关注路况并握紧方向盘！

3. 就像本文开始说的，城区导航智能驾驶功能由于其体验更连贯、控车更灵活，使用一段时间以后会让消费者逐步信任这个系统，而当人类逐步信任机器的时候，也恰恰也就是事故爆发的开端。

请无论如何熟读厂商给你的用户手册特别是有关智能驾驶的部分，熟悉系统的相关操作并使之成为肌肉记忆，熟知该厂商智能驾驶的弱势场景描述并在使用该功能时不断提醒自己。

总之，无论任何时候，请时刻关注路况并握紧方向盘！

对于这点，我特意翻看了小鹏和华为-极狐的用户手册， 在其智能驾驶章节对系统可能的问题与应对不了的场景有着非常详尽的罗列与描述、各种使用限制、错误与警告，甚至让我看了以后觉得“功能不可用，完全不想开”的程度。

然而我认为，这才是对消费者负责任的态度。反观别的一些厂商的用户手册，这一部分的描述可以说一言难尽。以至于我甚至怀疑这些厂商到底有没有做过成系统成规模的泛化场景测试，他们自己到底知道不知道自己的系统有这么多不能处理的场景。

图19 小鹏P5手册中密密麻麻的限制与警告，华为-极狐中也有类似的繁琐章节描述

七、写在最后的话

未来的五年内，是国内城区导航智能驾驶内卷后大爆发的年份，各个公司都会以跑步前进的速度开放这个功能。我们每个在这个行业奋斗，以这个行业作为终生事业的从业者，都应该保持一颗清醒的头脑，本着对客户、消费者、行业负责的态度，推进智能驾驶走进千家万户。

本文来自微信公众号：九章智驾 （ID：jiuzhangselfdriving），首发于知乎，作者：萧谭辉