如果让刚接触自动驾驶的人猜哪类目标最难识别十有八九会说是“移动的、速度快的东西”。真实情况恰恰相反。过去几年公开报道过的自动驾驶测试事故观察下来大多指向同一个画面车直直撞上了停在主车道上的事故车、施工设备或者一片根本算不上“车”的散落物。静止的东西恰恰是感知系统最典型的盲区也是我从做感知工程以来被问得最多的一个问题。这篇文章不打算泛泛讲“自动驾驶怎么识别物体”而是把“为什么静止目标最难”真正拆开——从传感器的物理限制、检测算法的设计惯性、训练数据分布的偏差再到多传感器融合里的逻辑取舍尽量讲透。读完你至少能回答一个问题为什么一辆120km/h的测试车能躲开横穿的行人却撞上一辆停在路中间打着双闪的事故车。1. 传感器底层机制静止目标在感知链路上的“先天失明”先说结论三种主流传感器——摄像头、毫米波雷达、激光雷达——各有各的问题但加在一起对静止目标仍然存在系统性缺陷。这个缺陷不是某一个传感器的精度不够而是它们从物理原理上就对“静止”这件事不友好。要理解后面的所有问题得先从传感器看懂这个世界的方式说起。1.1 毫米波雷达的多普勒盲区速度为零等于不存在毫米波雷达测速度靠的是多普勒效应目标朝雷达靠近时反射波频率变高远离时变低频率变化量跟相对速度成正比。运动目标因此有“速度签名”而静止目标的速度签名是零。雷达信号处理里有个常规操作叫动目标显示把多普勒频移接近零的回波当成杂波抑制掉因为地面、护栏、灯杆、桥墩全都在这个类别里。这套思路最早来自防空雷达目的是从复杂地物回波里找出飞行的目标用在车载场景却埋下了隐患停在路中间的事故车对雷达来说和桥墩没有本质区别。部分前向雷达会用恒虚警率CFAR检测器把静态强回波保留下来但接下来的问题是区分——它到底是可通行的路侧护栏还是必须避让的障碍物传统雷达只有几十厘米到米级的角分辨率距离和角度信息都不足以回答这个问题。还有一个工程细节常被忽略很多雷达目标跟踪模块会直接在速度维上做门控多普勒速度的绝对值低于某个阈值比如0.5m/s就认为“不是动态目标”直接不输出。这个阈值防的是把路牌和铁桥误报成障碍物引发幽灵刹停代价就是把真正的静止车辆也一并丢掉了。我在实际调参时对这个阈值的感受特别深调小了高速上碰到龙门架就急刹调大了静止事故车在雷达眼里彻底消失。两头都是事故。1.2 激光雷达点云里“静止”和“噪声”的模糊边界激光雷达在物理上对动静一视同仁它发出去的光脉冲不管照到停着的车还是跑着的车都会有回波。问题出在数据处理环节尤其是地面分割。感知pipeline第一步通常是把地面点滤掉只保留障碍物点。地面分割算法比如射线法、平面拟合、Patchwork这类在处理低矮物时会翻车——竖着的锥桶可能没问题但一个掉在路面上的轮胎、一个斜躺的杆件或者一辆底盘特别低的车很容易被当成地面点抹掉。另一个问题是远距离点数稀疏。一辆车在100米外对16线激光雷达来说可能只有十几个点甚至更少。稀疏点云做聚类时本来就抖再做分类器现在多是PointPillars、CenterPoint这类特征不够置信度自然低。动态目标还有个优势它在连续帧里位置变化明显可以在关联阶段用多帧信息补足单帧特征的不足静止目标每帧都长一样反而没有这个“时间积分”的便宜可占。更麻烦的是静止点云和地面、背景点云混在一起一旦聚类时把这个目标并进了背景簇后面就不会再有人提起它。1.3 摄像头有外观没有物理量靠“认脸”吃饭摄像头是唯一能真正“认出”物体是什么的传感器但它没有直接的速度概念。单帧图像里停着的车和正在走的人只是图像系统只能在连续帧里通过特征匹配去推算运动。这就意味着摄像头对静止目标并无先天优势。更要命的是深度单目相机对距离的估计是从目标在图像里的位置、尺寸、先验知识反推的误差随距离急剧放大。一辆静止车在100米外可能只占图像几十个像素分类置信度和距离估计都会崩。人眼为什么能轻松分辨路中间的静止车靠的其实不是“车长什么样”而是它和周围环境的相对关系别的车都在动它在动流场里是静止点它挡在车道的行驶轨迹上。摄像头单帧算法恰恰没有这些上下文它只能“看脸”距离、运动、物理上下文全得靠别的模块补。三种传感器各自的短板可以压在下面这张表里看传感器对静止目标感知能力主要受限点毫米波雷达弱多普勒盲区无法与桥墩、护栏等环境杂波区分激光雷达中等地面分割误删低矮物远距离点云稀疏摄像头中等无直接速度信息单目深度弱缺少场景上下文2. 从检测算法看静止目标网络结构并不天然理解“静止”传感器拿到原始数据后算法层的设计惯性也在放大这个问题。早期ADAS的思路和现在的深度学习检测网络之间其实有一条明显的断层线前者从根上排斥静止目标后者虽然理论上不排斥但工程pipeline里残留的运动偏好让静止目标始终处于弱势地位。2.1 两帧差分与运动目标检测的路径依赖传统视觉感知有经典三件套帧间差分、光流、背景建模。核心思想都是“变了才算东西”。这种思路从根上就把静止目标推到了感知盲区——镜头里一切不变的东西都被归为背景。很多最早的量产ADAS前向碰撞预警只对相对速度异常的目标响应本质上是运动目标检测MOD思路。现代深度学习目标检测已经是单帧的端到端识别理论上不再依赖运动线索。但工程落地时大量pipeline仍然保留了“先检测出物体再用运动属性做验证”的环节。追踪模块尤其如此卡尔曼滤波器里的状态向量通常包含速度和加速度关联时用马氏距离做门控。一个静止目标在状态空间里速度为零如果某帧检测置信度波动导致漏检这个track很容易被删掉动态目标因为持续有“运动轨迹”支撑track生命周期反而长得多。你让一个主力做动态目标追踪的工程师去改静止目标召回他大概率会先愣一下因为整套工具链都是为动态设计的。2.2 锚框、中心点和NMS静态小目标的系统偏见检测网络对目标尺寸、位置天然有偏。Anchor-based时代小目标锚框召回的运气成分居多CenterPoint这类无锚框范式虽然提升了整体精度但类别预测头对静态小目标锥桶、碎片、低矮障碍物的样本量不足输出概率仍然不稳定。再加上后处理NMS如果一个低置信度的静态真值框和一个高置信度的背景误检框重叠NMS会把低置信度的真值框直接抑制掉。这类问题在单帧推理上几乎无解只能靠后续的时序和融合模块补救而正如前面说的时序和融合模块对静止目标并不友善。2.3 速度分支与分类器的耦合类别标签绑架了行为判断还有个更隐蔽的问题很多多任务检测头会同时预测类别和速度相对本车的速度。这个速度分支的训练目标来自标注中的“瞬时运动状态”而类别分支的监督来自“语义是什么”。两者耦合之后模型会学到一种隐含关联——“车”这个类别往往伴随非零速度“静止”更常和“障碍物”“其他”这类模糊标签绑定。结果就是同样一辆车停着的时候模型输出的类别置信度往往比它开着的时候低。这不是玄学是数据分布的直接投影。我在跑实验时见过很典型的曲线同一个模型对“行驶中的轿车”AP能到90以上对“静止轿车”掉到70不到。类别没变变的只是运动状态精度就差出一个量级。3. 数据分布决定识别上限静态目标在训练集里的长期弱势不管传感器和算法怎么设计模型最终是被数据喂出来的。静态目标难识别的第三个原因藏在训练数据本身。这部分最容易被忽视因为它不在代码里、不在网络结构里却在源头决定了系统能力的上限。3.1 开源数据集里的静止样本占比看几大公开数据集——KITTI、nuScenes、Waymo Open Dataset、Argoverse——标注规范各有各的体系但趋势一致动态交通参与者的标注密度远高于静止障碍物。原因很简单数据集的首要任务是支撑“多目标跟踪”和“轨迹预测”评测这两项都需要动态目标。于是你会发现路边停的车有框但路中间的静止障碍物、散落物、作业区设备经常被归到ignore区域或者干脆不标。更具体一点nuScenes这类城市数据集里车辆标注框绝大多数来自行驶中的交通流静止车辆大量集中在路边泊位而高速公路上“停在车道正中间”这种真正要命的目标在公开数据里占比极小。模型没见过自然认不出。这也是为什么很多感知团队拿公开数据集训出来的模型一到自己车队回传的高速数据上就露馅。3.2 标注一致性难题同一个“静止”在不同人眼里不是一回事即便是被标出来的静止目标类别定义也充满争议。一辆停在路肩的车A标注员标“静止车辆”B标“停泊车”C可能因为它旁边站了人就标“其他”。红灯路口排队等灯的车瞬时速度为零但它不是“障碍物”可模型从单帧里根本区分不了“等一下要走的静止”和“永远不走的静止”。标注层面的语义混乱会让分类器学出一堆矛盾信号。我参与过数据质检这类case几乎是每天的争论焦点。标注规范写得再细也挡不住真实世界的边界情况。最后大家只能妥协把“是否占用行驶轨迹”作为标注的主要依据但轨迹是动态的标出来就已经过时了。这种模糊性直接传导给模型表现为静止目标检测结果在时间维度上极不稳定。3.3 类别不均衡制造“看不见的墙”自动驾驶的感知评价有个核心矛盾漏报FN和误报FP要去哪一边。静止障碍物容易引发幽灵刹停高速上对桥墩、路牌突然急刹所以量产系统在标定上强烈倾向压FP。压FP最直接的办法是提高检测置信度阈值、加运动门控。这套组合拳下去模型对那些“长得很像背景的静止真目标”的漏报几乎无人问责——因为公开评测集里这类样本本来就少。于是系统对静止目标的召回就成了那道所有人都知道、但没人愿意先动的墙。做算法的人KPI是公开集上的mAP和NDS做功能的人KPI是幽灵刹停投诉率两个数字打架最后牺牲的必然是没有专门评测指标支撑的静止目标召回。4. 多传感器融合中的静止目标“惨案”融合策略如何把本该检测到的目标删掉单个传感器有短板正常融合的核心价值就是互补。但具体到静止目标融合逻辑反而可能放大缺陷。这一节我想还原一条完整的误删链路你会发现每个环节单独看都合理串起来却是闭环的盲区。4.1 融合的优先级与置信度投票机制主流量产方案是视觉毫米波雷达的后期融合L2以上再加激光雷达。后期融合的基本单位是“track”每个传感器各自输出目标列表融合模块再按位置、尺寸、速度做关联和ID管理。关联阶段通常要求多帧一致。静止目标在这个机制里天然吃亏上一帧检测置信度不高这一帧刚好被雨滴干扰漏了一次关联不上的track直接消亡。动态目标得益于持续运动坐标变换误差对它的轨迹连续性影响小静止目标只要有一帧掉链子后面就没它了。更隐蔽的是置信度投票机制多个传感器对同一个目标的置信度取加权甚至取最大雷达对静止目标本身就不输出等于投票从一开始就少了一票剩下相机一票还要扛过阈值和时序关联两道关卡。4.2 一条完整的误删链路从雷达过滤到高置信度删除拿高速前向场景举例以典型量产融合方案为例第一步雷达CFAR检测器把多普勒为零的回波判成静态杂波事故车没有进入雷达目标列表。常见工程代码长这样# 雷达目标速度门控示意ADAS工程中常见的静态杂波过滤逻辑 GATE_V 0.5 # m/s低于该速度视为静态杂波 def radar_gate(detection): if abs(detection.relative_speed_ms) GATE_V: return None # 不输出防止桥墩/路牌误报 return detection第二步进入相机检测模型检出了车但距离远、置信度只有0.6低于融合设定的0.7阈值。第三步融合模块做交叉验证要求视觉目标有雷达目标支撑雷达列表里没有这个目标于是相机目标因为没有“交叉验证”被丢弃。第四步规划模块拿到的就是一个干净的前方道路一切正常直到撞上。四个环节里没有一个是“坏了”的但串起来就是灾难。这种系统性偏见靠纯调某一个模块参数解决不了必须有人站在整条链路上做专项治理。4.3 高精地图先验的双刃剑L2系统还会引入高精地图车道边界、红绿灯位置、路沿都是先验。先验帮系统把静态目标“应该在哪”框定了——路边的车不需要管车道内的物体才危险。这很大程度降低了误报率让系统的行为变得更像人知道哪里能走、哪里不能走。但副作用同样明显地图里没有的静止目标刚落下的树、刚发生的事故车、刚围起来的施工挡板会被当作“地图外噪声”。静态感知变成先验的忠实执行者而不是独立观察者。这也是为什么很多量产系统“平时挺好一遇到地图没更新的路段就露馅”。我在测试里遇到过一次前方100米刚发生追尾、两辆车横在车道上的case系统直到80米才开始减速因为它此前完全相信地图里“这里应该是一条畅通车道”。5. 真实道路上的静止目标误判复盘三种典型场景前面讲机制这一节把机制落到具体场景。以下三类场景出现频率最高我在工程和测试中也反复看到。每个场景都不是单一原因而是前面几节提到的传感器、算法、数据、融合问题在不同比例下的组合。5.1 高速主车道上的静止事故车高速场景是静止目标误判的重灾区。车距100米以上时摄像头里事故车的成像高度可能不到20像素分类器给出的几乎都是低置信度。同时高速AEB的触发阈值通常只覆盖“运动目标”很多量产法规和NCAP测试场景也只考核相对速度较大的前车切入、前车减速静止目标测试速度普遍不超过中低速。把这几件事叠加结果就是系统在120km/h下能稳定识别300米外的龙门架因为它是强反射加高置信语义却识别不了100米外的事故车。这不是某一个模块能解决的是传感器分辨率、算法置信度和功能安全标定共同决定的。最讽刺的是事故车打的双闪灯在夜间反而会造成相机的过曝、眩光进一步压低检测置信度。越是危险的场景系统表现越差。5.2 施工区域的锥桶与路障施工区是最典型的“语义缺失”场景。锥桶对毫米波雷达来说反射截面太小回的波弱得跟噪声一样LiDAR能看到但上百米外的锥桶点也就几个摄像头能认出锥桶但训练集里“施工锥桶”类别本来就少加上颜色、磨损程度各异置信度飘忽不定。更麻烦的是施工区通常伴随改道规划模块依赖的车道线断了、实时地图没更新于是系统对“前方有一个需要绕行的障碍物”这个判断迟迟不做。常见的结果是车辆在锥桶前减速到很低但不知道该不该变道最后需要驾驶员接管。这类case里感知其实已经“看见了”锥桶但语义层和规划层没有给足够的响应权重等于看见了等于没看见。5.3 路面散落物与异形障碍物散落物是另一个“不属于任何类别”的难题。掉落的轮胎、木板、纸箱、货物绑带模型里往往没有对应类别输出只能是低置信度的“unknown”。规划模块对“unknown”的处理策略大多是“保守但不作为”——不主动撞它但也不给你做出明确的避让动作。更麻烦的是散落物又小又矮时地面分割和分类器双重失效LiDAR可能直接把它当路面起伏滤掉雷达更是几乎无回波。等驾驶员肉眼看到时制动距离往往已经不够了。这类场景我在测试中见过好几次每次都是系统的至暗时刻。它不像事故车还有“车辆”类别可以往上面靠散落物连类别都没有整套目标检测范式对它就失效。6. 正在发生的技术修补从传感器升级到范式转换说完问题聊点实际的。业界这几年其实已经在做系统性修补方向有几个各有取舍。没有哪一个方案能单独解决全部问题但组合起来静止目标的处境确实在改善。6.1 4D毫米波雷达让静止目标在速度维之外多一个维度4D成像雷达在传统距离、速度、方位角之外加了俯仰角输出点云密度接近低线数LiDAR。它对静止目标的提升在于有了高度和几何形状系统可以把“路面上的一个凸起柱状物”和“远处桥墩”区分开。多家供应商的4D雷达方案已经把静止目标检测距离拉到了200米以上。但它不是银弹——点云仍然稀疏角分辨率远不如LiDAR目标分类仍然依赖相机。实际工程里更常见的做法是4D雷达LiDAR相机的冗余组合而不是指望某一颗传感器。我在选型时最大的体会是4D雷达把“雷达看不见静止目标”这个硬伤治好了但把“雷达分不清静止目标是什么”这个难题留给了融合层。6.2 时序融合与占据网络放弃“认物体”转而“认空间”一个更根本的转变是从“目标检测”走向“占据感知”。占据网络不再是输出“这里有一辆车置信度0.8”而是输出“这个栅格被占了”直接把空间分成可通行和不可通行。它不需要知道目标是什么类别只要知道它挡住了路。国内外多家方案的BEV感知都在走这条路。对静止目标而言这几乎是解药——散落物、锥桶、事故车不再需要精确分类它们的“不可通行属性”本身就能被规划模块拿到。后融合阶段再把占据栅格和语义类别结合既保留了“是什么”的信息又绕开了“先分类再避障”的死胡同。这套范式的代价是算力和标注方式都要重来但方向我判断是对的。6.3 静止目标专用数据集与难例挖掘数据侧的补课同样关键。现在的趋势是从车队回传的海量clip里做自动难例挖掘专门挑出“系统漏检的静止目标”帧做标注回流训练同时在仿真里大规模插入虚拟锥桶、施工区、散落物做场景增强。这条路比较慢但很扎实。我个人的经验是单纯加静态样本对精度的提升有限更有效的是把“类别”和“瞬时运动状态”解耦成两个独立head来监督让模型不再被“车动态”这层隐含关联绑架。数据标注规范也要改不要把“静止车辆”和“停泊车辆”混在一个标签里分开标、分开评测模型才不会自相矛盾。6.4 系统层面的兜底功能安全标定与能力边界最后说说系统工程层面的兜底。静止目标召回率短期内不可能拉满所以量产方案普遍用运行设计域ODD来兜底高速场景明确限制对静止目标AEB的速度上限在有限度自动驾驶里ODD会排除无地图更新的施工路段。这些限制看着“退步”其实是用户安全与系统能力之间的合理折中。做感知的人如果只盯着模型精度很容易忽略真正让系统安全的往往是清晰的能力边界。与其让系统在能力边缘硬撑不如把边界说清楚让驾驶员知道什么时候该接管。这个思路在整车失效安全设计里叫“安全退场”放到静止目标这个难题上同样适用。做了这么多年感知我越来越觉得“静止目标难识别”不是一个单一技术点而是传感器、算法、数据、系统标定四条线共同作用的结果。每次看到类似的测试事故我第一反应不是“某个模块不行”而是“这条链路上有没有一个环节其实在有意无意地抛弃静止目标”。如果你也在做相关方向建议从数据集里单独拉一版“静态障碍物”的召回率曲线看看多数情况下你会被结果吓一跳。先把这条曲线盯起来很多问题才有机会被真正看见。