做自动驾驶感知的同学应该都有体会拿到一款前向毫米波雷达样品没拆封之前觉得自己什么都能做拆封之后才发现后面的链路全要自己搭。PLFM_RADAR这个项目就是我折腾雷达感知平台时攒出来的一套东西。PLFM取自PlatformRADAR就是雷达本行合起来就是一个面向量产项目预研的雷达数据处理与验证平台。它主要干了三件事把各家新雷达的原始报文收进来统一解码做CFAR和聚类检测得到稳定点云再通过卡尔曼滤波跟踪输出目标航迹。这个项目对刚接触雷达感知的新人以及需要快速搭一套原型验证环境的算法工程师都挺有参考价值。我把整个平台的代码、配置、标定流程都整理在了一套仓库里后面会逐步把设计思路和踩坑过程写清楚。需要说明的是这套代码并不是某个厂家的SDK也不是纯离线分析工具而是一套可以接实车、接台架、接录制的数据包、甚至接仿真数据做回灌的通用雷达感知底座。无论是做AEB前向预警、BSD盲区监测还是做多传感器融合的前级目标生成它都能承担比较核心的感知职能。下面我按整个平台的搭建顺序从头到尾拆开聊。1. 项目整体设计思路为什么我要攒一个雷达平台1.1 雷达数据处理链路到底卡在哪里做雷达感知的第一步不是写算法而是解决数据链路的问题。不同厂家的毫米波雷达输出格式差别非常大有的走CAN有的走车载以太网有的只输出目标级数据目标列表有的能输出点云级数据甚至还有原始的距离-多普勒数据流。早期我接触过某几款国产雷达明明都叫“4D毫米波雷达”点云协议却各写一套连速度的单位都敢用不同的换算系数。算法组想快速验证一个聚类算法或者跟踪策略光是写解码器、对齐时间戳就要耗掉一两周。PLFM_RADAR最核心的设计动机就是把“算法研究”和“平台工程”这两件事剥开。上层算法模块只面对统一格式的点云结构体和目标结构体不用关心底层是CAN还是以太网、是某雷达A还是某雷达B。底层接入模块做成可插拔的动态库雷达厂家变了只换驱动不影响上层。这样一来算法同学关注算法效果平台同学关注数据质量和稳定性职责边界清晰联调整体都舒服很多。1.2 模块化流水线的架构选择整体架构我参考了量产项目里常见的“数据源—感知模块—应用接口”三段式但更强调模块之间的数据解耦。每个模块都定义清晰的输入输出结构体模块之间用环形缓冲区和共享内存通信不搞一锅炖的回调地狱。管线从原始帧数据开始依次经过接入解码、预处理、CFAR检测、聚类、目标跟踪最终对外发布稳定航迹。这样的流水线还有一个好处可以单独用录制数据回放某个模块也能在仿真数据上先跑通检测再换真实报文。每次版本迭代我只关心某个节点有没有退化而不是整个链路异常了才去怀疑所有环节。因为雷达点云相对相机点云更稀疏中间环节容易出各种稀奇古怪的问题——数据帧不同步、参考窗参数不合理、目标号跳变没有模块化隔离排查成本能让你怀疑人生。2. 核心模块拆解从原始报文到稳定目标航迹2.1 数据接入与时间同步数据接入是PLFM_RADAR的地基。对于CAN报文我使用了一个独立接收线程按通道ID分派到对应雷达的解析器对于以太网UDP报文则用零拷贝收包方式减少用户态拷贝开销。这里最需要注意的不是接收速度而是时间戳。雷达帧到达时会打上硬件时间戳但这个时间戳和系统UTC时间不在一条时间轴上。如果后面要把雷达数据和相机、IMU做融合时间不同步会导致目标位置错位尤其是在车辆颠簸或加减速时。我的做法是在接入层统一对齐到PTP或GPS授时后的系统时间并把原始时间戳保留在结构体里备用。整车环境下如果不开PTP至少也要确保NTP同步的误差在毫秒级以下否则融合结果会出现肉眼可见的跳变。2.2 点云生成与预处理解码之后我先把雷达上报的目标或点云转换到统一的雷达直角坐标系X轴正前方Y轴左侧Z轴上方。4D毫米波雷达通常直接给点云比如典型的一帧点包含距离、水平角、俯仰角、径向速度、信噪比SNR。我还会额外根据SNR做一次质量打分因为后续聚类算法对噪点非常敏感一个SNR极低的点会把聚类中心和质心拉偏。预处理阶段我习惯加两步一是根据速度和RCS雷达散射截面过滤静止杂波候选点二是做多帧点云去重。雷达点云有“帧间重复闪烁”的现象同一个目标可能上一帧报5个点、下一帧报12个点点的数量变化不是因为目标变了而是由于多路径和检测门限边缘效应。先做质量过滤再做聚类能大幅减少跟踪时的航迹抖动。2.3 CFAR检测与门限参数怎么定如果雷达厂家开放了距离-多普勒矩阵接口那CFAR检测就是核心。CFAR的意义是在没有目标的时候保持一个基准虚警率在有目标的时候根据周围噪声水平自适应抬升检测门限避免把噪声当目标。我采用二维CFAR分别在距离维和多普勒维滑动窗口。每个检测单元会对比“参考窗内噪声均值乘以阈值系数”超过门限才算检测到目标。这里有个常见误区很多人在CFAR里把参考窗设得过大结果目标本身占据了参考窗的很大面积噪声均值被目标能量抬高于是旁边弱目标直接漏检。正确做法是在参考窗里加入保护窗保护窗宽度要大于目标在对应维度上的最大展宽。举例来说对于前向雷达距离维保护窗一般设2~4个距离单元多普勒维保护窗设1~3个单元。阈值系数我常用3.5~4.5太高漏检太低噪点多需要对着实际路测数据反复试。2.4 目标聚类从点云到目标提案检测之后得到的是一堆点还没形成“目标”。我采用基于密度的聚类算法DBSCAN因为雷达点不像图像像素有固定邻域结构点云密度变化很大用固定半径的球状聚类最容易挂一漏万。DBSCAN只需要两个参数eps邻域半径和min_samples邻域内最小点数。我的经验是前向高速场景eps取0.5~1.0米城区场景取0.8~1.2米min_samples取3~5因为雷达点本身稀疏取大了目标容易散。聚类完成后每个目标簇的质心、扩展尺寸、平均径向速度、检测点数都会被记录作为跟踪器的输入。这里我专门保留了一个字段簇内最大速度和最小速度的差值。如果差值过大大概率是目标簇包含了静止护栏和运动车辆的点需要在聚类阶段做速度一致性检验拆开否则跟踪器会被这个复合目标搞得很混乱。3. 实操调参记录我踩过的参数坑与经验值3.1 雷达安装角误差带来的横向偏移雷达标定是项目里最容易拖后腿的一步尤其是安装角误差。很多同学觉得安装角偏差半度一度无所谓实际上在远距离目标上误差会被放大得很厉害。举个例子如果雷达安装偏航角偏差0.5°目标在150米处横向位移误差大约是150m × tan(0.5°) ≈ 1.31米。这个误差在车道级预警里足以让目标被判到相邻车道。我在PLFM_RADAR里做了一套基于直线行驶数据的偏航角校准流程车辆沿平直道路行驶找静止路牌或护栏的反射点拟合出雷达坐标系下的目标横摆直线然后反算应补偿的角度。实测下来用这个方法可以把偏航角补偿精度做到0.1°以内。每次整车换雷达位置或调整支架后必须重新做一次不要偷懒沿用旧标定值。3.2 跟踪器生命周期参数的取舍跟踪滤波我用的是一组相互独立的扩展卡尔曼滤波器每个滤波器状态量包括位置、速度、加速度。滤波器本身不复杂复杂的是航迹管理逻辑。航迹的“出生”和“消亡”需要设门限连续几帧命中才确认航迹通常3帧连续多少帧丢失才删除航迹通常5~8帧。门限调得太严虚警少但目标亮相慢调得太松目标跟踪连贯但短暂干扰也可能形成假航迹。我在实际测试里的建议值是确认门限3帧、删除门限6帧再配合一个“航迹质量分数”做加权。对于AEB这类安全功能假航迹比漏检更危险我会把删除门限适当放宽让跟踪器多保持一段时间尽量不让目标号在中途反复重生。目标号跳变对下游决策影响很大这一点很多算法新手容易忽略。3.3 一套可以直接抄作业的初始参数表下面是我在多个项目里起始配置并微调后得到的一套参数不能说通用但可以作为初版配置快速起步模块参数名推荐初值说明CFAR参考窗距离单元64视距离分辨率调整CFAR参考窗多普勒单元16视速度分辨率调整CFAR保护窗距离单元4防止目标自身抬升噪声CFAR保护窗多普勒单元2同上CFAR阈值系数alpha3.5噪声适应性检测门限聚类DBSCAN eps0.8m城区可增大到1.2m聚类min_samples4点数少于该值视为噪声跟踪确认航迹帧数3连续命中帧数跟踪删除航迹帧数6连续丢失帧数跟踪过程噪声Q0.5 m/s²代表目标加速度变化幅度跟踪量测噪声R1.5 m代表点云中心的位置抖动参数表只是起点真正落地必须结合自己雷达的精度水平重新标定。比如某款雷达的点云位置噪声特别大R值却沿用默认的1.5m滤波器会过度相信量测输出轨迹反而更晃。合理做法是先录一段目标静止的数据统计点云位置的标准差把这个值作为R的初值再去微调。4. 高频问题与排查方案速查4.1 目标跳变、丢帧、虚警的常见根因我把自己在调试PLFM_RADAR过程中遇到最多的问题整理成了一张排查表很多问题不是算法本身有bug而是“数据链路上的脏数据”带来的连锁反应。现象常见根因排查方向目标位置周期性跳变点云与目标航迹时间戳错位检查接收线程时间戳是否统一高速目标忽隐忽现CFAR阈值系数过高或保护窗过大拉低alpha减小保护窗静止护栏被识别成移动目标雷达多普勒速度维未做静止目标补偿检查自车速度补偿是否生效相邻车道的目标横穿到本车道聚类eps过小导致目标碎片化增大eps并开启速度一致性检验雨天出现大量虚警地杂波反射能量升高提升alpha增加杂波图更新目标航迹滞后于场景滤波器过程噪声Q取值过小调大Q让滤波器更快响应急转目标号频繁跳变确认门限与实际帧率不匹配确认门限配合帧率设3~4帧排查的核心原则是“先看数据再怀疑代码”。我每次遇到诡异现象第一件事就是打开点云和航迹可视化把雷达原始点云、聚类结果、跟踪航迹三层叠加显示。如果点云本身就跳问题大概率在接入或CFAR如果点云稳而航迹跳问题大概率在跟踪或时间戳。4.2 时间戳与回放对齐的一个隐蔽坑做实车采集时很多人习惯直接用电脑的系统时间打时间戳但如果电脑没有做PTP同步系统时间和雷达硬件时间会有漂移。曾有一次我在路口连续绕圈发现目标轨迹在弯道处总是滞后真实位置约半米查了很久才发现是采集电脑的时钟在开机后持续漂移回放时时间戳错位被放大。后来我规定采集工具统一从GPS接收机读取UTC时间并且每个数据帧里保留雷达自身的硬件时间两套时间戳互相比对。回放时如果发现两端时间差超过3ms直接拒绝该帧参与算法验证。这个坑非常隐蔽我建议每个做感知平台的人都提前加这道保险。4.3 日志与可视化工具链最后说说排查必备的工具链。PLFM_RADAR的代码库里我放了一个轻量级的可视化工具可以实时画点云、画目标框、画航迹也能离线回放录制的数据包。日志方面我要求所有模块都输出同一格式的日志行包含帧号、模块名称和关键指标这样可以用脚本直接做回归对比。雷达参数的改动、标定值的变更全部记录在一个配置变更表里哪次改完效果变差能立刻知道是哪个参数引起的。有条件的话建议把录制的原始数据包做成自动化回归集。我每次调完CFAR或聚类参数都会先在回放数据集上跑一遍对比检测率、虚警率、航迹存活时间三个指标再决定是否装车实测。没有回归集只靠现场试很容易出现“这个场景好了另一个场景崩了”的尴尬状况。整个项目做下来我个人最深的体会是雷达感知平台难的不是某个算法而是让从报文、点云到目标航迹的整条链路稳定可复现。PLFM_RADAR最让我满意的地方不是用了多前沿的算法而是它做到了“每个问题都有日志、每次改动都有对比、每个参数都有来源”。做感知底座这份踏实感比什么都重要。如果你也在搭类似的雷达处理平台建议先别急着优化算法把平台的数据链路质量先打磨到位后面你会感谢自己当初这个决定。
