做车载雷达感知的同学大概率都遇到过这种“玄学”时刻装车时功能一切正常跑了一个月之后系统开始间歇性抽风目标时有时无严重的时候干脆一个点都不出。第一反应通常是怀疑算法逻辑写错了或者雷达硬件坏了折腾半天才发现问题出在雷达罩表面那层厚厚的泥浆、水膜甚至只是安装位置被前车的卷泥带崩了一点。这件事的本质就是雷达被“遮挡”了而系统里没有做遮挡检测。这两年在行业群里聊毫米波雷达、4D毫米波雷达、RoboSense Helios-16P这类激光雷达大家慢慢达成一个共识雷达遮挡检测不是什么“锦上添花”的功能而是感知可信度的底线之一。尤其当你开始用AWR2243读取原始ADC数据或者把3D激光雷达接入Nav2做导航避障或者做IMU雷达外参标定的时候你会发现所有后续算法都建立在一个前提上——雷达是真的在“看”而不是被一块泥巴捂住眼睛。这篇东西就把雷达遮挡检测这件事从原理到落地完整聊一遍适合正在做车载感知、机器人导航、毫米波雷达产品化以及刚入门雷达信号处理但被这套概念绕晕的同学。1. 先把问题聊透雷达被“挡住”到底意味着什么1.1 哪些场景最容易把雷达“闷”住先说结论雷达遮挡不是小概率事件它是感知系统里最常见的“慢性病”。整车前保险杠里的毫米波雷达装在格栅后面或车标后面看起来有外壳保护但泥浆、雪、雨水形成的连续水膜、砂石击打留下的污渍、碰撞后雷达罩位移都是高危因素。工程机械和矿山车辆更夸张粉尘和泥土几乎是常态化覆盖。轮式机器人如果雷达装得低草丛泥水、灰层一样会糊住视窗。还有些遮挡来得非常隐蔽。我见过一个项目雷达本身没问题但前格栅重新设计后雷达和格栅之间的间隙被金属装饰条靠近结果雷达视场里多了一个强反射体。这种“结构性遮挡”比泥浆更难判断因为它不像污损那样让所有目标消失而是让一小片区域出现异常反射导致目标分裂或者出现大量鬼点。再有一种容易被忽略的是维修和改装后留下的隐患。比如换过一次前保雷达支架没按原扭矩固定雷达面朝天了一点或者贴了不符合要求的车膜、加装了什么装饰件。这些情况系统自检时往往是过的因为雷达的内部自检只检查电路和天线是否导通它不会告诉你“你的安装位置被物理改变了”。这也是为什么遮挡检测不能只靠硬件自检位得靠信号层面的特征去识别。1.2 遮挡为什么是系统性问题一个雷达距离方程能看出很多东西搞雷达的同学应该都熟悉雷达距离方程教科书里能写整整一章但做工程的人最关心的其实是这个简化关系接收功率和距离的四次方成反比和目标的等效雷达截面积RCS成正比。Pr (Pt · Gt · Gr · λ² · σ) / ((4π)³ · R⁴ · L)这里面σ是目标的RCSR是目标距离L是系统损耗。遮挡出现后不是简单地把某个变量调大或调小而是引入了一个额外的损耗项L_occ。泥浆、水膜、油污这类介质会吸收微波能量还会让天线罩表面的介电常数不均匀一部分发射能量被反射回雷达内部一部分被吸收真正透射出去的能量大幅缩水。生活化类比一下雷达正常工作时相当于你耳朵张开听远处的人喊话遮挡之后等于有人在你耳朵前蒙了一层棉被。不仅是听到的音量变小连声音的方位感和层次感都会变差。所以遮挡导致的不是某个目标RCS变小那么简单而是整个场景的信噪比被系统性压低远端目标全部掉进噪声里近处的强目标也可能因为混叠和相位畸变出现测距测角偏差。最麻烦的是现代雷达处理链里通常都有CFAR恒虚警检测。CFAR的思路是根据背景噪声动态调整门限保持恒定的虚警概率。当噪声底被遮挡整体抬起来之后自适应门限也会跟着抬高。结果就是真正目标的回波被“系统性淹没”。表现出来就是你看到雷达点云里近处全是杂点远处的目标点全部消失点云数量骤降。1.3 传感器越来越卷遮挡检测的关注度为什么反而更高这几年行业热词从普通毫米波雷达卷到4D毫米波雷达点云越来越密角度分辨率越来越高甚至开始拼图像级点云了。按常理说传感器性能越好遮挡的影响就应该越小实际恰恰相反。4D毫米波雷达之所以能被接受是因为它能提供高密度点云和俯仰角信息。但高密度点云对遮挡也很敏感——如果视窗上有积水雷达可能看到的不是“干净场景里少几个点”而是“近场多出一团乱点”这些乱点甚至会被后端聚类成虚假目标。换句话说传感器越灵敏遮挡造成的脏数据越像“真实目标”算法越容易被骗。同时功能安全ISO 26262这种体系里对感知系统的要求也在变高。遮挡检测已经从“诊断功能”变成了“降级策略的一部分”。如果系统检测到雷达被遮挡至少要能输出遮挡状态让上层决策知道“我的感知置信度降低了”不能只顾着继续报目标否则AEB这类主动安全功能会在关键时刻漏报甚至误触发。这也是为什么现在很多OEM和Tier1都把遮挡检测作为雷达内部的一项必备特性来要求。2. 遮挡检测的四种主流思路我们挨个拆解2.1 基于回波统计特征最朴素但最实用的第一道防线最早做遮挡检测的方案基本都围绕“CFAR检测前后的统计量”来做。逻辑很简单雷达在干净视窗下噪声底是相对稳定的一旦遮挡出现噪声底会抬升目标峰值会下降这两个变化叠加起来就是非常明显的“遮挡指纹”。可以提取的特征有这么几类距离-多普勒谱的噪声底水平Noise Floor遮挡时通常会整体抬升。检测点数量正常工作时有几十上百个点遮挡后可能暴跌到个位数。平均峰值功率/峰值旁瓣比遮挡后主峰能量降低旁瓣相对变高。零多普勒附近的能量聚集度静止杂波、天线罩反射会产生大量近场零速能量。这个方案最大的优点是实时性好不需要额外的传感器也不依赖大量标注数据。在DSP或MCU上做几个统计量计算几十个周期就能给出一个遮挡置信度。缺点是不同温度、不同湿度下噪声底本身就有波动如果阈值写死很容易误报。所以做这个方法核心工作其实在“特征标定”而不是“算法模型”。2.2 基于点云分布变化4D雷达带来新“抓手”到了4D毫米波雷达和激光雷达这里点云密度足够高就可以看空间分布特征了。正常情况下雷达视场里的点云会呈现“近密远疏地面连续”的分布模式。遮挡之后会出现几个比较典型的变化近场0到10米的杂点数量异常增多这些点大多是天线罩或视窗上的遮挡物反射。中远场的目标点数急剧下降尤其是那些原本稳定的地物、路沿、护栏点。点云在俯仰维上的分布被压缩4D雷达能看到原本有一片反射出俯仰角的区域直接变成扁平的“墙”。这类方法比单纯看回波统计量更直观尤其是在多传感器融合系统里可以通过点云分布的变化快速定位是哪颗传感器出了问题。缺点是需要点云质量足够稳定对稀疏点云的普通毫米波雷达来说统计意义不强。还有个小细节。做雷达信号分选的同学可能熟悉“天线扫描周期估计”这类概念那是电子侦察领域用来判断对方雷达工作模式的方法。车载雷达的遮挡检测虽然场景不同但底层思路有一点相通我们也在从接收信号里识别“异常状态”区分正常信号模式和遮挡模式。这种跨领域的方法迁移做工程时其实很值得借鉴。2.3 基于时序建模从“单帧抽风”到“状态稳定”单帧判断最大的问题是抖动。车辆经过桥洞、经过大型金属广告牌、旁边有大货车经过时雷达回波都会出现几帧异常。如果把每一帧的异常都当成遮挡去报警车上得多出多少误报。所以稍微成熟一点的做法是把遮挡检测当成“状态估计”而不是“事件检测”。输入一段时间的特征序列比如过去1秒内的噪声底、目标点数、峰值能量变化然后判断当前雷达处于“正常”、“部分遮挡”、“严重遮挡”中的哪种状态。工程上最常用的不是复杂的深度学习模型而是滑动窗口统计加滞后比较器。比如计算过去200帧目标点数的滑动平均值和标准差当平均值连续50帧低于阈值A同时标准差变大才判定为“疑似遮挡”。再加一个恢复条件后续100帧内平均值回到阈值B以上才恢复为“正常”。这样就把一个高频抖动信号变成了稳定的状态机误报率能降一个量级。如果你想上更智能的可以用LSTM或Transformer对特征序列建模输入连续帧的特征输出遮挡概率。但以我实际经验来看在车规MCU或嵌入式计算平台上这类模型性价比并不高。先把滑动窗口和滞后比较器做扎实覆盖90%的场景完全没问题模型是锦上添花的角色。2.4 多传感器交叉验证融合系统里的“终极裁判”到了融合阶段遮挡检测就不只是看单雷达自己的特征了而是看“雷达和别人的话对不上”。这是最符合直觉的做法如果摄像头和激光雷达都看到前方有一辆卡车唯独毫米波雷达什么都没报那你大概率可以判断毫米波雷达要么被遮挡要么已经坏了。常规做法是先从其他传感器拿到目标假设和目标航迹投影到雷达坐标系然后检查雷达在这些目标假设位置附近是否有点云或者检测框输出。如果连续一段时间多个明显目标在雷达侧都没有回波同时雷达噪声底特征也异常就给出遮挡置信度。这套方案的前提是“外参要准”。我见过不少项目摄像头和雷达明明都在正常工作就是因为外参标定偏了两度投影点对不上导致交叉验证一直误报雷达遮挡。所以做多传感器交叉验证之前务必先把雷达-相机-IMU的外参标定做扎实。做完标定之后还可以用IMU的预测航迹来做“盲区推断”比如车辆直线行驶时某些固定目标应该在雷达视场里持续出现如果航迹消失的时间点高度一致说明那个方向极有可能被遮挡了。3. 手把手实现一套遮挡检测数据、特征、阈值与集成3.1 硬件平台与数据准备AWR2243能读出什么这里以TI的AWR2243毫米波雷达为例因为它是目前做雷达算法验证时很常用的平台配合DCA1000采集卡可以直接读原始ADC数据后面接ROS2驱动也很方便。AWR2243是一个76-81GHz的毫米波雷达SoC支持多片级联很多4D雷达原型系统都基于它来做。数据流大概是这样的天线接收反射信号经过混频得到中频信号ADC采样后得到原始数据。AWR2243的原始ADC数据保存下来通常是二进制文件每个chirp包含若干次采样点。读取时要注意数据的位宽、IQ通道顺序、chirp和frame的排列方式。很多刚接触的同学会把原始数据读错位导致后面做距离FFT时频谱全是乱的这一点要特别小心。如果你不想从ADC开始也可以用雷达厂商提供的SDK直接拿到点云或目标列表。以AWR2243为例用mmWave Studio可以配置参数并采集数据ROS2驱动里也能直接订阅点云话题。做遮挡检测时从点云话题取数据最省力但如果你想看到更本质的信号特征还是建议直接从距离-多普勒谱上取噪声底和峰值特征这些特征在点云层面是被“压扁”过的很多细节丢了。3.2 一张Range-Doppler图里的“遮挡指纹”拿到原始数据后第一步是做距离FFT和多普勒FFT得到距离-多普勒图。这张图上横轴是多普勒速度纵轴是距离每一个峰值代表一个潜在目标。正常视窗下图上会有几个清晰的目标峰背景比较干净遮挡时近距区域会出现一片连续的高能量区表现像一面“墙”堵在那里同时远端目标峰模糊甚至消失。下面给一份简化版的特征提取代码用于从Range-Doppler数据中计算几个关键遮挡特征import numpy as np def read_adc_bin(file_path, num_chirps, num_samples, num_rx4): # 按实际采集配置读取原始ADC数据 # 这里简化处理实际需解析chirp配置、IQ交织等 raw np.fromfile(file_path, dtypenp.int16) # 假设数据排列为 [num_chirps, num_samples, num_rx, 2(IQ)] raw raw.reshape(num_chirps, num_samples, num_rx, 2) data raw[..., 0] 1j * raw[..., 1] return data def compute_rd_map(data, num_rx4): # 对每个chirp做距离FFT再对不同chirp做多普勒FFT range_fft np.fft.fft(data, axis1) # 累加多个接收天线取平均 range_fft np.mean(range_fft, axis2) rd_map np.fft.fftshift(np.fft.fft(range_fft, axis0), axes0) # 取幅度 rd_map_db 20 * np.log10(np.abs(rd_map) 1e-6) return rd_map_db def extract_occlusion_features(rd_map_db): # 距离-多普勒图近场区域比如前10个距离门 near_field rd_map_db[:, :10] # 全图噪声底取幅度值的低分位数 noise_floor np.percentile(rd_map_db, 20) # 峰值能量 peak_energy rd_map_db.max() # 近场能量占比 near_energy_ratio np.mean(near_field) / (np.mean(rd_map_db) 1e-6) return { noise_floor: noise_floor, peak_energy: peak_energy, near_energy_ratio: near_energy_ratio, }这里有几个点需要说明。第一噪声底选取的分位数不是固定的要根据实际平台和环境调整。在干净的室内环境下20%分位数和80%分位数差别不大到户外有大量地面杂波时可能需要改用更稳健的统计量。第二近场区域选前10个距离门是假设我们的距离分辨率在0.2米左右对应2米以内。不同雷达配置下距离分辨率不同要根据参数重新算。第三真实代码里还要做加窗、去直流和校准这里只保留了核心思路。拿到这些特征后接下来要做的就是“让数据说话”——在干净环境和遮挡环境下分别采一批数据看这些特征的分布差异。3.3 判定阈值怎么标定别拍脑袋用数据说话阈值标定是遮挡检测落地时最容易被低估的一步。很多同学喜欢先看一眼数据然后拍脑袋写一个“噪声底大于-80dBm就算遮挡”结果到现场一测晴天、阴天、雨天数据分布差得远立刻被打脸。正确的做法是分场景采集基线数据。至少需要采集这几类场景干净场景晴天干燥雷达视窗清洁。轻度污损少量灰尘或者用透明胶带模拟部分遮挡。重度污损用泥浆覆盖雷达罩的一部分或者用金属板遮挡一半视场。干扰场景附近有大型金属围挡、车辆密集、有同频雷达干扰。每一个场景连续采集至少10分钟尽量覆盖不同的车速和周边环境。然后把采集到的特征做分布分析画出每个特征的直方图或箱线图观察干净场景和遮挡场景之间是否有明显的分离度。以我的经验单纯一个特征往往很难做到完全分离。比如近场能量占比这个特征在车辆靠近墙面或前方紧贴大车时也会升高容易和遮挡混淆。所以工程上通常用组合特征[noise_floor异常] AND [peak_energy下降] AND [近场能量占比升高]三者同时满足才判断为遮挡。这种“与逻辑”能有效降低误报代价是漏报率会略微上升但整体上利大于弊。阈值具体取多少可以用一个很小的样本集做“k折交叉”验证把正常场景和遮挡场景的样本混合按不同阈值计算检出率和误报率画出ROC曲线挑一个误报率可接受的阈值点。不要追求100%检出率那一定是以大量误报为代价的。3.4 接到ROS2/Nav2里遮挡状态如何参与上层决策对做机器人或自动驾驶的朋友来说遮挡检测不能停留在离线分析得真正接到系统里。我建议把遮挡检测做成一个独立的ROS2节点输入是雷达点云或Range-Doppler特征输出是一个自定义的RadarOcclusion.msg包含遮挡状态枚举、遮挡置信度和当前关键特征值。消息定义可以很简单uint8 OCCLUSION_NONE 0 uint8 OCCLUSION_PARTIAL 1 uint8 OCCLUSION_SEVERE 2 uint8 occlusion_status float32 confidence float32 noise_floor_db float32 peak_energy_db float32 near_energy_ratio std_msgs/Header header在Nav2里接入时可以通过一个nav2_behavior_tree的条件节点获取遮挡状态。如果检测到严重遮挡比较合适的策略不是直接急停而是把代价地图里雷达输入部分的置信度调低或者切换到备用传感器比如超声波或摄像头。同时给用户一个明确的提示比如“前雷达被遮挡请清理”。这里还要注意一点就是“恢复”的处理。遮挡不会瞬间消失需要持续监测。如果系统检测到峰值能量回弹、噪声底回落到正常范围并且这个状态维持了几百毫秒才能把状态恢复为正常。否则在雨刮刮一下的瞬间就恢复然后马上又被水膜判定为遮挡系统会在两个状态之间反复横跳比一直报遮挡更让上层头疼。4. 现场实录遮挡检测调试中绕不开的坑4.1 噪声底居高不下时先查这四件事做遮挡检测时最容易遇到的问题就是“我明明已经把遮挡算法写好了怎么噪声底一直偏高甚至一开始就判定为遮挡”。这时候先别急着调阈值按下面的顺序排查第一检查供电。雷达的供电噪声会直接影响ADC的底噪。如果用的是开发板USB供电噪声底大概率比车载稳压电源高好几个dB。我见过最夸张的案例用劣质USB供电噪声底直接从-95dBm抬到-80dBm整个算法全部失灵。第二确认天线罩是不是真的干净。很多实验室环境看着干净实际上雷达罩上已经有手印和灰尘了人眼不容易察觉但毫米波对水分子和油污特别敏感。第三查一下周围有没有同频段干扰源。特别是77GHz雷达密集的路口或停车场其他雷达的发射信号会抬高本地噪声底而且这种抬升是间歇性的。第四检查天线耦合。天线罩和雷达之间的距离如果太近或者中间有异物发射信号会在天线-天线罩之间来回反射形成“驻波”导致接收机底噪异常抬高。4.2 阈值总是误报你可能是踩了“绝对阈值”的坑我早期做遮挡检测的时候特别爱写绝对阈值比如“噪声底-80dBm就算遮挡”。后来发现这个值在不同温度下能漂3到5dB。夏天暴晒后雷达罩温度升高接收机增益下降噪声底整体往下掉冬天或者雨后低温噪声底又往上走。如果阈值写死要么冬天频繁误报要么夏天严重漏报。比较稳妥的做法是用“相对阈值变化斜率”。首先在雷达上电的初期或者在某次确认无遮挡的时刻记录一个基准值作为“自校准基线”然后遮挡判定看的是“当前噪声底相对于基线的抬升幅度”而不是绝对数值。同时观察这个抬升的变化速度。遮挡通常是缓慢累积的噪声底抬升是一个渐变过程而硬件故障或强干扰往往是几帧之内突变。通过区分“渐变”和“突变”可以在一定程度上把遮挡和硬件故障分开。这套逻辑用代码实现其实就是维护一个滑动窗口窗口内计算噪声底的中位数。然后比较当前帧噪声底和窗口中位数的差值。如果差值连续多帧超过设定阈值才判定为遮挡。4.3 单帧判断飘忽不定加一点“记忆”就好多了判断结果的抖动是遮挡检测落地时被吐槽最多的问题。目标点数这个特征尤其不稳可能前一帧还有80个点下一帧就掉到50个再下一帧又回到75个完全取决于场景里有多少目标。如果只看单帧几乎天天心情过山车。解决办法是给判断加“记忆”也就是状态机。我常用的是一个三态状态机OK→PENDING→OCCLUDED。每个状态都有滞回条件比如OK状态下只有当“遮挡特征异常”连续累计达到M1帧才迁移到PENDINGM1一般取20到30帧。PENDING状态下如果异常继续累计到M2帧迁移到OCCLUDEDM2可以取30到50帧。OCCLUDED状态下只有连续若干帧特征恢复“正常”才能回到OK这个恢复帧数要更大比如100帧。这样处理之后即使原始特征抖动很大状态输出也非常稳定。这个思路在信号处理和控制系统里叫“滞后比较器”做硬件的小伙伴应该很熟放到软件逻辑里一样好用。不需要上什么复杂算法纯粹靠状态机的记忆特性就能把大部分毛刺滤掉。4.4 和外参、多传感器吵架时怎么定“谁说了算”多传感器交叉验证听起来很美好做起来最容易翻车的点就是外参。摄像头看到一辆车通过外参投影到雷达坐标系下结果因为外参偏了1度投影点落在目标边缘雷达在这个位置检测不到目标于是判断“雷达被遮挡”。这个误报逻辑非常顺畅但根源是外参问题。所以建议是交叉验证逻辑里对外参误差留出容忍带。比如目标投影到雷达坐标系时沿方位角方向扩展几度再检查雷达在这个锥形区域内有没有检测到目标。具体扩展多少取决于外参标定精度。如果标定质量很好可以收紧到2度以内如果标定质量一般宁可放宽到4-5度也要优先保证不误报。另外要有一个“仲裁策略”。多个传感器对遮挡状态各执一词时不能简单投票。我常用的策略是如果某个传感器自身特征已经强烈指示遮挡噪声底异常目标点数暴跌就优先信任自身特征如果自身特征中性再看其他传感器是否支持遮挡假设。摄像头被太阳直射时容易过曝激光雷达在大雨里点云也会衰减每个传感器都有自己“盲目的时刻”所以在仲裁时要结合传感器特性来加权别想着一刀切。做融合系统的同学还要特别注意遮挡检测的结果最好不要直接作为“硬开关”去屏蔽某个传感器的数据流而是作为“置信度”去参与融合权重。比如雷达严重遮挡时把这个雷达在融合模块里的输出权重下调到0.2而不是把它的数据完全丢掉。这样即使雷达的恢复时刻和算法判断不一致融合系统也不会瞬间出现目标丢失整体感知会更平滑。最后分享一点个人体会做了几年雷达感知后我越来越觉得遮挡检测这类基础功能才是整个系统里最“值钱”的部分。高级的检测算法、复杂的跟踪逻辑都可以靠堆算力和数据慢慢打磨但遮挡检测这种“感知的免疫系统”它保证了你的算法能力不会因为一个物理环境问题瞬间归零。我见过太多项目把精力全放在提高检测精度上结果一遇到雨天泥地就现出原形最后还是乖乖回来补遮挡检测的课。如果你现在正打算给自己的系统加这个功能我的建议是不要急着先上模型先花两周时间把数据采集和特征分析做扎实把干净场景和遮挡场景的典型分布搞清楚。你把这个基础打好了后面无论是用简单的阈值还是用深度学习都会很快见效。遮挡检测不是一道难做的算法题而是一项需要耐心和细致打磨的工程活做得好的话它能替你省掉很多售后和调试的麻烦。