城区导航智能驾驶难在哪？写在小鹏 / 华为 - 极狐 NOA 释放之时

作者：萧谭辉

【本文一万字左右，预计阅读时间约 20 分钟，文中有若干图片 / GIF / 视频，请尽量连接 WIFI】

什么是城区导航智能驾驶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

城区导航智能驾驶到底难在哪？

HD—MAP

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

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

这样会带来两个问题：

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

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

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

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

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

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

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

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

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

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

整个高精地图 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（内容链接：https://www.zhihu.com/zvideo/1389638431253868544）

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

Perception

( Obj_Detection,Tracking,Mutli_Sensor Fusion)

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

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

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

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

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

前向冗余传感器 ROI 内事故

而假设 ——

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

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

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

Prediction

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

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

原视频实在是太惊悚了.. 链接我放在下面

https://www.bilibili.com/video/BV1Ug411a7aG/?spm_id_from=333.999.0.0&vd_source=a37d790330008054e1e6d0d77131fe1d

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

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

交互式预测 / 社会化博弈

（Reaction Prediction 或 Social Interaction)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

对于这点，我特意翻看了小鹏和华为 - 极狐的用户手册， 在其智能驾驶章节对系统可能的问题与应对不了的场景有着非常详尽的罗列与描述，各种使用限制，错误与警告，甚至让我觉得看了以后觉得 「功能不可用，完全不想开」 的程度。然而我认为，这才是对消费者负责任的态度。反观别的一些厂商的用户手册，这一部分的描述可以说一言难尽。以至于我甚至怀疑这些厂商到底有没有做过成系统成规模的泛化场景测试，他们自己到底知道不知道自己的系统有这么多不能处理的场景。

写在最后的话

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