做自动驾驶感知的同学应该都有体会，拿到一款前向毫米波雷达，样品没拆封之前觉得自己什么都能做，拆封之后才发现后面的链路全要自己搭。PLFM_RADAR这个项目，就是我折腾雷达感知平台时攒出来的一套东西。PLFM取自Platform，RADAR就是雷达本行，合起来就是一个面向量产项目预研的雷达数据处理与验证平台。它主要干了三件事：把各家新雷达的原始报文收进来统一解码，做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 一套可以直接抄作业的初始参数表

下面是我在多个项目里起始配置并微调后得到的一套参数，不能说通用，但可以作为初版配置快速起步：

参数表只是起点，真正落地必须结合自己雷达的精度水平重新标定。比如某款雷达的点云位置噪声特别大，R值却沿用默认的1.5m，滤波器会过度相信量测，输出轨迹反而更晃。合理做法是先录一段目标静止的数据，统计点云位置的标准差，把这个值作为R的初值再去微调。

4. 高频问题与排查方案速查

4.1 目标跳变、丢帧、虚警的常见根因

我把自己在调试PLFM_RADAR过程中遇到最多的问题整理成了一张排查表，很多问题不是算法本身有bug，而是“数据链路上的脏数据”带来的连锁反应。

排查的核心原则是“先看数据，再怀疑代码”。我每次遇到诡异现象，第一件事就是打开点云和航迹可视化，把雷达原始点云、聚类结果、跟踪航迹三层叠加显示。如果点云本身就跳，问题大概率在接入或CFAR；如果点云稳而航迹跳，问题大概率在跟踪或时间戳。

4.2 时间戳与回放对齐的一个隐蔽坑

做实车采集时，很多人习惯直接用电脑的系统时间打时间戳，但如果电脑没有做PTP同步，系统时间和雷达硬件时间会有漂移。曾有一次我在路口连续绕圈，发现目标轨迹在弯道处总是滞后真实位置约半米，查了很久才发现是采集电脑的时钟在开机后持续漂移，回放时时间戳错位被放大。后来我规定采集工具统一从GPS接收机读取UTC时间，并且每个数据帧里保留雷达自身的硬件时间，两套时间戳互相比对。回放时如果发现两端时间差超过3ms，直接拒绝该帧参与算法验证。这个坑非常隐蔽，我建议每个做感知平台的人都提前加这道保险。

4.3 日志与可视化工具链

最后说说排查必备的工具链。PLFM_RADAR的代码库里我放了一个轻量级的可视化工具，可以实时画点云、画目标框、画航迹，也能离线回放录制的数据包。日志方面，我要求所有模块都输出同一格式的日志行，包含帧号、模块名称和关键指标，这样可以用脚本直接做回归对比。雷达参数的改动、标定值的变更，全部记录在一个配置变更表里，哪次改完效果变差，能立刻知道是哪个参数引起的。

有条件的话，建议把录制的原始数据包做成自动化回归集。我每次调完CFAR或聚类参数，都会先在回放数据集上跑一遍，对比检测率、虚警率、航迹存活时间三个指标，再决定是否装车实测。没有回归集，只靠现场试，很容易出现“这个场景好了，另一个场景崩了”的尴尬状况。

整个项目做下来，我个人最深的体会是：雷达感知平台难的不是某个算法，而是让从报文、点云到目标航迹的整条链路稳定可复现。PLFM_RADAR最让我满意的地方不是用了多前沿的算法，而是它做到了“每个问题都有日志、每次改动都有对比、每个参数都有来源”。做感知底座，这份踏实感比什么都重要。如果你也在搭类似的雷达处理平台，建议先别急着优化算法，把平台的数据链路质量先打磨到位，后面你会感谢自己当初这个决定。