1. 为什么“雷达遮挡”会成为躲不开的工程问题先聊一个很多做感知的朋友都绕不开的场景一辆带辅助驾驶的车在雨天跑高速ACC自适应巡航原本稳得很结果开了两个小时系统突然提示“前雷达传感器被遮挡功能受限”紧接着车道保持、自动紧急制动全部退出。车上的人一脸懵明明路上没什么脏东西怎么一进服务区擦了一下雷达罩就恢复正常了。这事在智能驾驶、安防监控、交通流量检测这些领域几乎天天发生。雷达装在车头格栅后面、装在路侧杆子上、装在机器人底盘上时间一长必然会沾上泥、盖住雪、贴上广告贴纸甚至被撞歪。但问题是雷达不像摄像头镜头脏了驾驶员一眼就能看出来毫米波雷达的天线罩看起来干干净净内部到底有没有被脏污衰减信号肉眼根本判断不了。更麻烦的是另外一个层面雷达被遮挡之后系统并不会立刻“瞎掉”。它的表现是信噪比变差、最远探测距离缩水、小目标漏检率上升如果软件没有遮挡检测机制ECU还会拿这组“带病数据”去做融合决策。在自适应巡航场景下这意味着前车距离可能从150米突然缩短到30米才被感知到给紧急制动留下的时间窗口几乎为零。所以行业里有个共识雷达遮挡检测不是“锦上添花”的高级功能而是直接挂钩功能安全和预期功能安全的基础需求。这篇文章就把雷达遮挡检测这事从头到尾捋一遍包括它为什么会发生、工程上怎么检测、不同方案有哪些坑、以及现在比较前沿的做法是什么。内容主要面向做智能驾驶感知、毫米波雷达应用开发、以及安防雷达集成的工程师也适合刚入门雷达信号处理、想理解“工程落地视角”的学生。我会尽量把原理讲透但也不会扯一堆公式就不管了毕竟真正干活的时候一个阈值设不好什么花哨算法都白搭。2. 遮挡如何影响雷达信号从雷达方程到CFAR消失2.1 雷达距离方程里的“隐形衰减项”理解遮挡检测之前得先搞清楚遮挡到底是怎么让雷达“变瞎”的。教科书里最常见的雷达距离方程长这样Pr Pt × Gt × Gr × λ² × σ / ((4π)³ × R⁴ × L)其中Pt是发射功率Gt和Gr是收发天线增益λ是波长σ是目标雷达截面积R是目标距离L是系统损耗。对于车载毫米波雷达来说这个公式的关键在于接收功率Pr和距离R的四次方成反比——也就是说目标距离变远一倍回波功率掉到原来的十六分之一。遮挡物在这里扮演的角色是在系统损耗L这一项里“塞进”一个额外衰减因子。比如一块湿泥巴盖在天线罩上电磁波穿过泥巴时会产生吸收损耗和散射损耗这部分能量既没有到达目标也没有回到接收天线等效于L增大了。具体增大多大取决于遮挡物的介电常数、厚度、含水量还有雷达工作频率。举个例子77GHz毫米波雷达的波长只有大约3.9毫米这个频段对介电常数变化非常敏感。干燥的塑料膜可能只带来0.5dB到1dB的损耗但一片浸透雨水的树叶盖上去损耗可能直接飙到6dB到10dB。6dB的衰减是什么概念它意味着回波功率变成原来的四分之一等效到距离上最大探测距离直接缩水到原来的约70%10dB衰减就更夸张探测距离掉到只有原来的56%。也就是说遮挡不只是“灵敏度低了一点”而是直接把感知范围砍掉了一半。2.2 遮挡之后距离-多普勒图上发生了什么雷达信号处理的一般流程是把回波做距离维FFT和多普勒维FFT得到一张距离-多普勒图Range-Doppler Map简称RD图。在RD图上正常目标是孤立的亮点静止目标多普勒频率为零运动目标会出现在对应的多普勒单元上。背景则是均匀的噪声底噪声功率的大小由接收机热噪声决定。遮挡发生之后RD图会出现两种典型变化。第一种变化是整体噪声底抬高。遮挡物本身就在天线近场范围内它反射的强能量会直接进入接收机形成宽带干扰。反映在RD图上就是某些近距离距离门的噪声电平整体抬升目标峰值和噪声底之间的信噪比差距急剧缩小。原本一个信噪比18dB的行人目标噪声底抬高6dB之后信噪比就剩12dB了。如果本来目标就弱比如远距离的摩托车那它直接淹没在噪声里CFAR检测器根本点不出来。第二种变化是近距离出现“一堵墙”式的强反射。泥、雪、金属贴纸这类遮挡物本质上就是贴在雷达脸上的一块大目标。它的回波极其强烈而且在距离维上占据连续的门。反映在RD图上就是从第几个距离门开始一整片区域全是高能量。这其实是一个很好的检测信号但它同时也是一个严重的干扰源。如果CFAR检测器的参考窗刚好覆盖这片高能量区域那参考电平会被拉高反而导致原本能检测到的目标被判为噪声丢掉形成“目标被遮挡物压住”的现象。2.3 为什么CFAR会在遮挡场景下“翻车”恒虚警检测CFAR是雷达检测目标的核心手段它的原理是在被检测单元周围取一个参考窗统计参考窗内的噪声/杂波电平然后根据设定好的虚警概率计算一个检测门限。如果被检测单元的能量超过这个门限就判定为目标。问题恰恰出在“参考窗统计噪声电平”这一步。正常场景下RD图的噪声底是平稳的参考窗能给出一个稳定的估计。可一旦雷达被遮挡近距强反射区域进入参考窗噪声统计就失真了。参考窗电平被抬高检测门限跟着抬高真实目标反而过不了门限反过来如果遮挡物刚好落在保护单元附近又可能因为保护单元没挡住强泄漏而产生一串虚警。很多刚入门的朋友会问那我把CFAR的门限设低一点不就完了不行。门限设低了虚警率立刻飙上去系统天天报假目标比漏检还让人崩溃。这个矛盾是CFAR固有的也是为什么遮挡检测不能单纯依靠“调CFAR参数”来解决的底层原因——遮挡场景下整张RD图的噪声分布已经不符合CFAR的平稳性假设了。3. 工程上主流的遮挡检测实现思路3.1 方法一基于接收噪声底噪的检测这是最简单、也最常用的一类方法。思路非常直白雷达没有被遮挡时接收机输出的底噪功率是相对稳定的遮挡发生后底噪会明显变化通常是抬高。所以只要持续统计RD图中无目标区域的噪声功率跟雷达出厂标定的基准值做比较差值超过阈值就判定为遮挡。这个方案的关键在于“无目标区域”怎么选择。选得太远可能超出雷达有效探测范围统计的是纯噪声没错但遮挡物对远距离底噪的影响很弱选得太近又可能把自身泄漏或天线罩反射统计进去。我在实际项目中一般会在中远距离段取若干个距离门比如40米到80米之间对这些距离门上的功率做排序取中位数或低分位数作为底噪估计值这样比取均值更抗异常点。另外一个容易踩坑的地方是温度。毫米波雷达的噪声系数受温度影响很明显夏天暴晒和冬天零下二十度底噪可能差好几个dB。所以阈值不能做成固定值必须用雷达内部的温度传感器做补偿或者在上电之后做一段自适应基线校准。否则冬天一到系统隔三差五报“遮挡”用户投诉能把售后电话打爆。3.2 方法二基于近距离强反射的检测遮挡物就在雷达天线罩外面距离近、截面积大、回波强。利用这个特点可以直接在近距离距离门看是否有异常强反射。具体做法是设置一个较低的检测门限只在0.3米到1米范围内的近距离门上找连续高能量区域同时统计这些区域的宽度和稳定度。这里有个很重要的区别正常目标也会在近距离出现例如车头正前方蹲个人、或者旁边车道的车头切进来。怎么区分正常近距目标和遮挡物经验是两个维度——时间稳定性和空间连续性。正常目标不会一直停在那里它的距离、速度、位置会随时间变化遮挡物则是不动的连续几十帧、几百帧都在同样的距离范围出现同样形态的强回波。空间连续性则是指遮挡物在RD图上往往占据多个连续的距离门而且能量分布比较均匀不像行人那样存在明显的闪烁起伏。这套方法对泥浆、积雪、贴纸这类“贴在脸上”的遮挡非常灵敏但对一种特殊情况会漏检如果遮挡物是湿润的薄冰层或者某些特殊塑料它的介电常数匹配得“恰到好处”电磁波几乎无反射地穿透过去或者被吸收掉近距离反而看不到强反射。这种“无反射遮挡”是最棘手的因为它既不给底噪信号也不给强反射信号几乎只能靠目标级表现来反推。3.3 方法三基于业务目标统计的健康度判断这个思路不关心物理信号只看雷达输出的目标级数据的“质量”。雷达正常工作时一帧RD图里检测出的目标数量、目标距离分布、目标信噪比分布是有一定统计规律的。拿高速公路场景来说空旷路段目标少但远距离目标多城市道路目标多且分布集中。遮挡发生后最典型的特征是远距离目标突然消失目标平均信噪比下降目标数量在某些距离区间出现断层。工程实现上就是做一个滑动窗口统计器比如统计过去10秒内目标数量均值、最远稳定目标距离、超过一定信噪比阈值的目标占比。如果最远稳定目标距离明显小于正常水平且低信噪比目标占比升高就给出遮挡置信度。这个方法实现成本低不需要改动底层雷达信号处理链路很多时候直接在融合模块里加个逻辑就能用。缺点也很明显它对场景的依赖太强。隧道里、极端暴雨中、复杂城市峡谷环境即使雷达完全没被遮挡目标统计特征也可能和“被遮挡”非常相似。所以这种方案一般只作为辅助判据用来交叉验证前两种方法的结果。3.4 方法四雷达自检与天线罩状态监测有些雷达芯片会提供内建自检功能比如通过耦合通道在发射和接收之间注入一个小幅度的已知信号检测整个收发链路的增益是否正常。如果接收通道增益掉得厉害说明前端可能有问题。这个方案对“雷达内部故障”的检测非常有效但对“天线罩外部被泥糊住”这种纯外部因素只能间接反映。另外部分高端雷达开始尝试在雷达罩上集成专用传感器比如在靠近天线罩的位置布置电容式或光学传感器直接测天线罩表面有没有附着物。这个方法在实验室里效果很好但量产阶段面临耐候性、成本、一致性等一系列问题目前还没有成为主流。下表把这几种方法的优劣势汇总了一下检测方法核心信号优点缺点适用场景底噪估计RD图噪声功率实现简单、响应快受温度影响大、阈值标定麻烦前装量产雷达近距离强反射近距RD能量物理意义清晰、直观对吸收型遮挡失效泥雪等附着物检测目标统计目标列表不影响链路、易集成场景依赖性强、易误报融合模块辅助判断芯片BIST注入信号响应覆盖内部链路无法检测外部遮挡故障诊断、售后排查4. 遮挡检测系统的完整落地流程4.1 数据采集遮挡样本比你想的更难得做遮挡检测算法最大的困惑不是算法本身而是数据。雷达正常工作的数据满地都是但被泥糊住、被雪盖住、被贴纸贴住的“真实遮挡数据”量产之前根本攒不够。所以我们的经验是在项目启动阶段就要专门设计遮挡数据采集方案。比较实用的做法是准备一套可替换的遮挡模拟件包括不同厚度的湿润海绵、塑料板、金属网格、泥沙混合物等分别贴在雷达天线罩上进行整车道路采集。注意每种遮挡物都要覆盖不同车速、不同场景高速、城区、隧道、雨天至少采集几十分钟以上连续数据确保覆盖目标出现、消失、超车等各种情况。这样才能在RD图层面积累足够多样的遮挡形态。另外一定要记录真值。遮挡检测的真值不像目标检测那么好标——雷达模块要输出“当前是否遮挡”的状态这个状态在数据回放阶段很难人工判定。我们习惯的做法是在采集时用一个外部设备记录遮挡动作时间戳比如用一个按钮盒手动标记“开始遮挡”“解除遮挡”后期用这个时间戳自动生成标注比人工逐帧看RD图靠谱得多。4.2 离线分析找准特征再做算法拿到数据之后不要在算法上急着动手。先把样本里的RD图逐帧看一遍统计遮挡前后的底噪曲线、近距能量曲线、目标信噪比分布曲线。这一步做得越细后面算法选型越省事。比如有的雷达型号遮挡后底噪抬高非常明显那直接用底噪阈值方案就够了有的雷达天线罩设计得比较讲究近距反射却很弱那就得靠目标统计来兜底。我踩过的坑是只看了一个雷达型号的数据就定了方案结果换一个供应商的雷达之后底噪特性完全不一样算法参数全部重新标定。所以如果你的项目里有多家雷达供应商最好在方案设计时就考虑“通用特征”优先选择那些在物理原理上对所有雷达都成立的特征而不是针对某个特定型号的RD图形态过拟合。4.3 阈值标定与状态机设计特征定好之后就需要设计判定逻辑。工业界用得比较成熟的做法是输出连续遮挡置信度而不是直接输出一个二值状态。典型流程是每个雷达帧比如50ms一帧计算一次基础特征包括底噪偏差、近距能量指标、目标统计指标然后把这些特征做时间平滑形成三个置信度分量最后加权融合成一个遮挡置信度。状态机需要至少设计四个状态正常、疑似遮挡、遮挡确认、遮挡恢复。从正常到疑似遮挡置信度需要超过一个较低门限并维持一段时间比如0.5秒从疑似到确认需要更高门限并维持更长时间比如2秒。这个延迟设计非常重要——如果响应太快车辆经过一片水花时雷达会频繁误报如果响应太慢实际遮挡后系统还一直报“功能可用”又违背了功能安全要求。阈值怎么定我个人的习惯是先拿采集的遮挡数据跑一遍离线仿真画出特征分布的直方图找一个尽可能把遮挡和正常样本分开的初始阈值再在实车上做几轮迭代微调。注意阈值不能只让算法在遮挡样本上效果好还要在正常场景下保证极低的误报率。因为雷达遮挡误报对用户体验的伤害很多时候比漏报还要大。4.4 与下游系统联动检测出来之后怎么办遮挡检测的最终输出要接入到整车的功能安全策略里。ISO 26262和ISO 21448这两份标准都强调如果感知传感器处于降级状态系统必须通过人机交互明确告知驾驶员并限制相关功能的运行权限。实际工程上遮挡状态一般分为几个等级。轻度遮挡底噪略有抬高功能还能用但性能下降此时在仪表盘上提示“传感器脏污请清洁”中度遮挡探测距离明显缩短禁止激活ACC和AEB已经激活的逐步降级退出严重遮挡雷达完全失效系统直接显示故障码并告知驾驶员需要进店检修。这里有一个细节值得单独说雷达在“遮挡确认”之后如果几分钟后遮挡物被雨水冲掉了系统需要能够自动恢复正常。所以遮挡置信度不能只升不降要设计恢复机制比如持续检测到远距离目标恢复、底噪回落就逐步降低置信度回到正常状态。这个“自动恢复”功能做得好不好直接决定了用户的售后评价。5. 工程实战中的典型问题与排查技巧5.1 雨天误报“我感觉雷达没脏但系统一直报遮挡”这个问题在量产车上出现频率相当高。排查思路不要一上来就怀疑算法先从信号源头看。雨天环境下前车卷起的水雾、路面溅起的泥水、以及直接打在雷达天线罩上的雨滴都会让近距反射信号短时增强。如果阈值设得比较激进一片水雾飘过就可能触发遮挡置信度飙升。解决办法有两层。第一层是算法层面把遮挡置信度的时间平滑系数加大单帧或者短时几帧的尖峰不会立刻把置信度推到确认门限以上。第二层是特征层面雨雾的反射特性和固态遮挡物不一样——雨雾是不断流动变化的在RD图上的近距能量会出现明显的帧间起伏而泥块、雪、贴纸这类固态遮挡物近距能量是高度稳定的。所以加一个“时间稳定性”特征能有效区分雨天误报和真实遮挡。5.2 低温环境下底噪异常冬天户外停车一晚第二天上车发现雷达报遮挡这个问题我以前排查了很久。最后定位到是低温导致接收机增益变化底噪基线整体漂移了。当时用的固定阈值没有做温度补偿低温下底噪一降和基线的偏差就超了门限。解决办法是给雷达内部的底噪统计加一个温度查表补偿。标定的方法是把雷达放在温箱里从-40℃到85℃每5℃测一次底噪值拟合出一条温度-底噪曲线然后在算法里实时根据雷达上报的温度做修正。这一步虽然枯燥但非常重要。我建议所有做雷达算法的人前期标定阶段一定要拿到雷达的温度特性数据。5.3 遮挡检测功能在隧道路段误触发隧道场景下误报的根源和前两类不同。隧道壁是连续金属反射面雷达在隧道里RD图会被大量强杂波填充底噪估计和目标统计都会失真。如果遮挡检测算法用了目标统计特征隧道场景很容易被误判成“远距离目标消失、目标数量下降”从而把隧道误判成遮挡。排查时可以先做个简单的区分逻辑如果雷达同时检测到大量近距离目标比如两侧隧道壁而且这些目标的距离随着本车移动保持相对稳定那就应该判定为“场景异常”而不是“传感器遮挡”。更稳妥的方案是在遮挡判定逻辑里加一个场景置信度开关当检测到类似隧道的高杂波场景时适当调高遮挡确认的门限用更长的确认时间来过滤误报。6. 遮挡检测的当下趋势与扩展方向6.1 4D毫米波雷达带来的变化4D毫米波雷达在距离、速度、水平角之外新增了俯仰角维度输出的是完整的点云数据。这让遮挡检测有了新的玩法4D雷达不仅能看RD图还能从点云的空间分布上判断遮挡。如果天线罩表面附着泥块点云会在近距离区域形成一片“贴脸”点簇且点簇的形状和位置长时间不变而正常的近距离目标比如路沿、护栏会随车辆运动发生相对运动。另外4D雷达的高角度分辨率也让“部分遮挡”检测成为可能。传统3D雷达只能判断“整个雷达是否被遮挡”4D雷达可以把视场角划分成多个子区域单独检测每个子区域的遮挡状态。比如天线罩左下角被泥糊了一块系统能定位到是哪个方位角范围的探测性能下降了这对于远距离目标的置信度降权很有价值。6.2 基于学习的遮挡状态估计传统方法依赖人工设计特征和阈值通用性有限。近几年业界开始尝试用深度学习方法直接在RD图或点云数据上做遮挡状态分类。具体形式可以是一个轻量化CNN输入为多帧RD图序列输入出为遮挡概率也可以是一个时序模型直接把一帧帧的特征序列做分类。这类方案的优势在于它不需要人工去定义“底噪偏移多少算遮挡”“连续性多强算遮挡”模型可以从数据里自动学到不同遮挡物、不同场景下的复杂特征。坦白说在测试集上效果确实比传统方法好不少尤其对吸收型遮挡这种“无声无息”的情况学习法表现得比传统特征法更灵敏。但落地时要面对两个现实问题。一是数据RD图级别的标注比目标级标注还痛苦需要大量人工筛选和半自动标注工具辅助。二是可解释性功能安全评审时你能说清楚一个阈值对应什么物理含义但很难讲清楚CNN的某个权重为什么是这样。所以在实际操作中我倾向于把学习法当成一个辅助置信度来源和传统特征法做融合而不是完全替代。融合策略可以简单做加权平均也可以用逻辑回归学一个“二分类器套分类器”的组合权重。6.3 遮挡检测与传感器融合的联动再往上一层看遮挡检测的结果不应该只是用来报个警。理想的架构是感知融合模块实时获取每个雷达传感器的健康状态然后根据这个状态动态调整传感器在融合输出中的权重。例如左前雷达报“部分遮挡”那么融合模块在生成目标车辆状态时对来自这个雷达的目标点的置信度进行降权更多依赖毫米波雷达其他区域和其他传感器比如摄像头的数据。这个方向目前还在落地过程中但它代表了一个趋势传感器健康管理从“故障后告警”走向“感知全生命周期健康监控”。雷达不只是一个采集数据的硬件它本身也是一个有状态、会损耗、需要持续监控的子系统。最后再分享一点我的个人体会。遮挡检测这个功能论文里经常被一两句话带过但真正做量产之后你会发现它是感知系统里跟用户体验、功能安全、售后成本关联最紧密的一环之一。算法本身并不复杂真正的复杂度来自场景的无限多样性和工程细节的无数坑。谁能把这些坑提前填平谁的感知系统就能在恶劣环境里比别人多稳住一秒钟——在自动驾驶这件事上一秒钟往往就是天壤之别。