毫米波雷达目标识别全解析：点云生成、4D雷达与工程实践

先从一个小问题开始聊吧：为什么在摄像头、激光雷达方案已经满天飞的今天，毫米波雷达仍然是自动驾驶感知里绕不开的传感器？我最初接触这个方向时也有同样的困惑，后来在项目里被雨雾天气里的摄像头、以及夜间弱光场景中的视觉识别狠狠教育过几次之后，才真正意识到毫米波雷达的价值。这篇笔记是我系统整理毫米波雷达学习路线与实践细节的第一篇，核心会围绕“目标识别”这条主线展开，包括雷达的工作原理、点云如何形成、目标识别从传统方法到4D毫米波雷达的新变化，以及工程落地时绕不过去的数据集、仿真工具和时空同步问题。适合刚进入自动驾驶感知领域、准备入门毫米波雷达的工程师，也适合已经在做多传感器融合但想补强雷达知识细节的同行。

1. 为什么毫米波雷达在自动驾驶目标识别里这么关键

1.1 先认清传感器的分工

自动驾驶感知系统里，主流传感器无非是摄像头、激光雷达、毫米波雷达这么三大类，外加超声波做近距离低速场景的补充。摄像头的优势是信息极其稠密，颜色、纹理、语义都能看到，但本质上它是一个被动光学传感器，对外界光照条件非常敏感，夜间、逆光、隧道出入口、雨雾天气都会有不同程度的性能衰减。激光雷达靠主动发射激光束测距，精度高、角度分辨率也漂亮，点云能勾勒出非常精细的物体轮廓，但它的造价和维护成本一直偏高，而且激光在雨雾、扬尘环境下同样有衰减问题，只是在恶劣天气下的鲁棒性比摄像头好一些。

毫米波雷达走的完全是另一条技术路线。它发射的是波长在毫米量级的电磁波，穿透雨、雾、烟尘的能力非常强，几乎不受光照条件影响，白天黑夜一个样。更关键的是，毫米波雷达可以直接通过多普勒效应测得目标的径向速度，这是摄像头和激光雷达都很难直接做到的事情。所以在L2级别及以上的辅助驾驶方案里，毫米波雷达几乎成了标配——自适应巡航里的目标跟车、自动紧急制动的触发判断、盲区检测，全靠它提供距离、速度和角度信息。

那问题来了，既然毫米波雷达这么好用，为什么还需要摄像头和激光雷达一起上？因为毫米波雷达也有自己的短板：点云稀疏、角度分辨率不高、缺少语义信息。雷达扫过去看到一坨反射点，它并不知道这是一辆车还是一个广告牌，也不容易分辨目标的颜色和纹理。真正可靠的环境感知，需要多种传感器互相补齐短板。

1.2 毫米波雷达的优势与代价

从目标识别的角度来看，毫米波雷达有几个非常突出的特点，这些特点决定了它在整个感知架构里所承担的角色。

第一是测速直接且准确。雷达测速不需要像视觉那样靠连续帧目标匹配来估算，一个chirp周期内就可以通过多普勒频移算出径向速度，响应非常快。对于前方突然减速的车辆、鬼探头场景，雷达能比摄像头更早感知到目标在速度维度的变化，这对AEB这类安全功能至关重要。

第二是作用距离远且全天候稳定。目前主流车载毫米波雷达的长距模式一般能检测到150米到250米左右的目标，在高速场景下这个距离足够给决策规划留出时间。而且毫米波雷达在夜间、雨雾、团雾这些恶劣天气下依然能保持稳定的检测能力，这一点在真实的高速公路场景里非常关键。我实测过一个场景：夜间下雨，摄像头在远光灯照射下对前方暗色车辆基本失效，而毫米波雷达的航迹还能稳定保持跟踪，那一刻我确实对这个小盒子刮目相看。

第三是成本可控。相比激光雷达动辄大几千甚至上万的硬件成本，毫米波雷达的量产成本已经压到了几百元级别，这让它在量产车型上可以大规模铺开，算法一旦成熟，单车可以装到5个甚至更多。

代价也很明显。传统毫米波雷达的方位角分辨率很低，常见前向雷达的水平角度分辨率一般在几度甚至十几度量级，导致远处两个并排走的目标很容易被合并成一个点。雷达点云没有颜色和纹理信息，区分行人和骑行者、判断目标朝向这些任务，单靠毫米波雷达非常吃力。还有一个问题是高度信息缺失——不少车载雷达只能给出距离、速度和水平角，没有俯仰维度，天桥、路牌这些高处的目标很容易被误判成前方障碍物。正是因为这些短板，才逼出了后面的4D毫米波雷达方案，也逼着算法工程师把点云处理、目标识别、多传感器融合这些技术吃透。

2. 毫米波雷达的核心处理链路：从回波到点云

2.1 距离、速度、角度是如何算出来的

做目标识别之前，先得搞清楚毫米波雷达输出的一堆数据是怎么来的。以目前主流的调频连续波（FMCW）体制为例,雷达芯片周期性发射频率随时间线性变化的电磁波信号，碰到目标后反射回来，接收端将回波和发射信号混频，就得到了一个中频信号。这个中频信号的频率和发射信号频率之间的差值，正比于目标到雷达的往返时间，从而直接换算出距离。这里有个关键公式：

f_b = (2B·R) / (c·T_c)

其中f_b是中频频率，B是扫频带宽，R是目标距离，c是光速，T_c是chirp周期。这个公式看起来简单，但它是整个测距链路的根基，我在做信号处理时经常用这个关系反推硬件参数选型的合理性。

距离知道了，速度怎么来？同一目标在相邻两个chirp之间会有一个微小的相位差。由于目标运动，回波信号的相位随chirp序号线性变化，把这个相位变化做一次FFT，就可以得到目标的多普勒频率，再换算成径向速度。这里需要把距离维FFT的结果作为输入，再在慢时间维上做FFT，也就是常说的距离-多普勒二维FFT。速度测量的精度和chirp周期、发射频率都有关系，这也是为什么车载毫米波雷达在硬件设计上对晶振稳定性要求很高。

角度的估计相对复杂一些。车载雷达一般有多个接收天线，目标到不同天线的波程差会造成相位差，通过不同天线间的相位差可以解算出目标的到达角，也就是水平方位角。工程上常用的是角度FFT或MUSIC一类的超分辨算法，后者精度更高但计算量也上去了。这里有一个现实问题：天线间距和探测视场之间有直接矛盾，阵列设计一旦定下来，角度分辨率的天花板也就基本定了。

2.2 从一维FFT到二维FFT再到目标角度估计的完整流程

我刚开始看雷达数据的时候，对“点云是怎么从原始ADC数据里出来的”完全没概念，后来把整个信号处理链路捋了一遍之后才豁然开朗。整个过程其实是一条链：

原始ADC采样数据进来之后，第一步是做一个距离维的FFT，把时域信号转换到距离维度，这时候每个距离单元上都能看到一个复数幅度。第二步是在每一个距离单元上按照chirp序号再做一次FFT，也就是多普勒维FFT，得到一个距离-多普勒二维谱图。这个二维谱图就是雷达回波在距离和速度两个维度上的能量分布，是后续所有目标检测的基础。

做完二维FFT后，第三步是恒虚警率检测，也就是常说的CFAR。因为环境里有杂波、噪声，不能简单设一个固定阈值去找峰值，CFAR算法会在每个待检测单元周围取一片参考窗，动态估计局部噪声水平，再根据这个水平判断当前单元是否超过阀值判为目标。这一步非常关键，它直接决定了检测虚警率和漏检率的平衡。

CFAR筛出来的只是距离和维度上的峰值点，每个峰值点还要通过角度估计来补上方位角信息，初略得到这个点云的空间坐标。同时，点云的RCS（雷达散射截面）强度一般也会从幅度谱里取出来作为特征保存。到这一步，一个标准的毫米波雷达目标点就生成了，数据格式一般是(x, y, z)，附带(v, rcs)信息。如果只有一个目标当然好办，但真实场景下目标成百上千，大量反射点混在一起，后面要做的工作就是如何把这些离散的点聚类成一个个有意义的可识别目标。

2.3 点云生成与检测算法里的那些细节

CFAR检测虽然名字听起来高大上，实际上原理并没有多玄乎。我习惯把它类比成一个自适应调门槛的人：在噪声低的地方把门槛放低一点，在噪声高的地方把门槛抬高一点，从而保证整体误报率基本稳定。车载毫米波雷达的CFAR实现中，最常用的是CA-CFAR（单元平均恒虚警），也有用OS-CFAR（有序统计恒虚警）来处理多目标交叠场景的。OS-CFAR在多目标环境下抗干扰能力强一些，但计算量明显更大，实际工程里需要做取舍。

CFAR相关的一个重要参数是参考窗长度和保护单元数目。参考窗太短，对噪声估计不准；参考窗太长，会把邻近的强目标能量带进来，导致弱目标被淹掉。保护单元则用来防止目标自身能量泄漏到参考窗里。这几个参数说白了就是要对着真实场景数据反复调，不同的雷达型号、不同的安装位置、甚至不同的场景类型，最优参数都不一样。我自己的经验是，高速路场景和城区路口场景最好能各保留一套独立的检测参数配置，放在同一个配置文件里按场景切换，效果比一套参数吃天下稳得多。

还有一个经常被忽略的点是点云聚合。同一辆车上可能对应几十个反射点，有的来自车身平面，有的来自轮胎、后视镜等角反射器结构，如果把这些点全部当成独立目标上报，后面融合模块会被大量重复航迹淹没。所以雷达内部或者上游感知算法里通常会先做一次点级聚类或者目标级检测，把物理上属于同一刚体的反射点合并成一个目标再输出，系统里常见的目标列表就是这么来的。这个“目标对象列表”模式也是传统毫米波雷达目标识别算法的关键输入之一。

3. 从点云到目标识别：聚类、特征与分类

3.1 目标分割的常用思路

拿到一帧雷达点云之后，第一步并不是直接识别，而是先把原始点云分割成若干个候选目标，也就是常说的点云聚类。毫米波雷达点云和激光雷达点云有个显著不同：雷达点云真的很稀疏，一个行人往往只有两三个反射点，一辆轿车也许只有十几个点，而且点的分布密度在不同距离上差异很大。

基于这样的数据形态，聚类算法里最常用的还是DBSCAN。它不像K-Means那样要先指定簇的数量，也不需要假设簇的形状是凸的，完全靠密度可达关系划分点集，非常适合雷达点云这种密度不均、形状不固定的场景。但DBSCAN有两个超参数：邻域半径eps和最小点云数minPts，这两个参数对效果影响极大。eps设太小，一辆车的反射点会被切成好几块；eps设太大，旁边并行行驶的车辆又会被粘成一个目标。我在实际项目里一般先用统计方法估算一帧点云的平均邻域距离，再拿几个典型场景反复调，最后把eps定在一个能区分“并排小车”和“同一辆车的车头车尾”的中间值附近。

聚类之后，每个簇还需要再做一步目标属性判断。有些聚类簇可能是固定的金属护栏，有些可能是桥下的金属横梁，有些才是真正的车辆行人。这一阶段常用的手段是从聚类簇中提取特征，再交给分类器去判断。目标分类的常用特征包括：簇内点云数量、点云的空间分布范围（长宽高估计）、RCS统计值（均值、方差、最大值）、径向速度一致性、多普勒展宽，以及点云在多个连续帧中的运动一致性等。

3.2 特征提取与分类器设计

特征提取是整个雷达目标识别里最考验功力的一步。雷达点云没有纹理，所以特征设计必须围绕雷达本身能感知到的物理量展开。以车辆目标为例，它一般具有较大的RCS、相对稳定的点云空间分布、刚性体的速度一致性；行人则相反，RCS小、点云少、不同部位反射点速度分散——因为走路时手臂和腿的摆动会造成明显的多普勒展宽。骑行者比较特殊，车体本身是强反射体，但骑车人的腿在踩踏板时有周期性的多普勒调制，这类特征可以用来区分骑行者和行人。

在分类器选型上，过去的量产方案多采用随机森林、XGBoost这一类传统机器学习模型，输入就是人工设计的几十维统计特征。传统模型的优势是解释性强、算力消耗低、在嵌入式平台上非常友好。不过随着数据量的增加和对识别精度要求的提高，基于深度学习的端到端方法也越来越主流——把一段连续帧的雷达点云直接输入到神经网络中，由网络自己学习时空特征，省去了大量人工特征设计的功夫。这里以PointPillars等点云网络为代表的一类方法，在激光雷达点云上已经很成熟，最近几年也逐步被迁移到毫米波雷达点云上使用。

但必须说一句，雷达点云的稀疏性对深度学习网络并不友好。同样的网络结构在激光雷达点云上跑得很好，换到毫米波雷达点云上可能连收敛都不稳定。一个可行的做法是先通过积累多帧的方式把点云密度提上来，再输入网络，可以在很大程度上缓解稀疏问题。我试过把8到10帧雷达点云在自车坐标系下做时间累积，点云数量差不多能多一到两个量级，识别精度提升幅度非常可观。

3.3 4D毫米波雷达带来的变化

最近两年，4D毫米波雷达这个概念一路走红，简单的理解就是传统毫米波雷达只输出(x, y, v)，也就是平面的位置和径向速度，而4D雷达在硬件上多了俯仰方向的天线，可以直接测量高度，输出(x, y, z, v)这样四维数据。可别小看了这个高度维度，它直接解决了一大类工程痛点——天桥、路牌、桥梁横梁这些原本在高处的基本确定不会影响行驶的目标，在安装俯仰天线后可以很自然地被过滤掉，大大降低虚警带来的误制动风险。

4D雷达带来的另一个改变是点云密度有了明显提升。传统车载雷达近距离的点云可能也就百来个点，4D雷达通过多发多收的MIMO体制，虚拟孔径变得更大，点云数量可以翻数倍甚至更多。点云密度上来之后，很多图像域和点云域的目标识别算法就派得上用场了，比如语义分割、目标检测网络，都能直接在4D雷达点云上做。业界甚至有人把4D雷达数据投到视觉检测网络的前融合方案里，和摄像头图像做跨模态融合，效果比单模态高出一截。

不过4D雷达也并非万能。点云数量增加意味着算法处理负载变大，同时硬件成本和功耗也相应提高。另外4D雷达点云在远距离上依然存在严重的稀疏问题，点云质量并不如中近距离那么理想。从应用落地的角度看，当前阶段4D雷达更适合作为多传感器融合中的增强组件，而不是完全替代其他传感器。但至少它让毫米波雷达在目标识别这个赛道上多了一个很有想象力的选项。

4. 工程实践：数据、仿真与多传感器对齐

4.1 公开数据集怎么选、怎么用

搞目标识别算法，没有数据寸步难行。自己做数据采集记录又贵又费力，所以在起步阶段，借助公开数据集是最高效的路径。目前业界常用的几个和毫米波雷达相关的公开数据集，各有侧重，我简单梳理一下。

nuScenes是目前用得最多的自动驾驶多模态数据集之一，全套数据里包含5个毫米波雷达、1个激光雷达、6个摄像头，时间同步做得比较好，也有完整的目标级标注，非常适合做雷达-视觉融合感知的研究。Waymo Open Dataset也有毫米波雷达数据，不过它更偏向激光雷达为主的研究路线，雷达数据相对少一些。RadarScenes是一个专门为毫米波雷达点云语义分割设计的数据集，里面提供了时间连续的雷达点云帧和逐点语义标签，目标类别包括行人、自行车、汽车、卡车等等，对于做“雷达点云语义分割”方向的研究是非常宝贵的资源。

使用公开数据集时有几个细节需要留心。第一，数据格式差异很大，雷达点的坐标系定义、速度单位、RCS量纲在不同数据集里都不一样，读取后要先做标准化处理。第二，标注形式不同，有的数据集只在目标级别标注，有的提供点级语义标签，需要根据任务目标选择合适的数据集。第三，雷达型号和配置代表了某一时期的硬件能力，比如早期数据集的雷达点云数量明显比现在4D雷达少得多，算法模型在不同硬件代际之间迁移时需要做适应，不推荐直接拿一个老数据训练的模型部署到新一代雷达上。

4.2 仿真工具链：Carsim、NI和VTD联合仿真

纯靠路测和采集数据来迭代算法，周期长、成本高、场景覆盖有限，所以仿真验证必不可少。在毫米波雷达算法和自动驾驶控制器开发流程中，一套比较常用的仿真组合是Carsim、NI实时仿真平台和VTD场景仿真软件联合工作。

简单拆解一下这套体系的分工：Carsim负责车辆动力学建模，能够给出车辆在不同工况下的运动状态，包括速度、加速度、横摆角等；VTD用来搭建虚拟交通场景，生成道路环境、交通参与者、目标物信息，同时可以用内置的传感器模型模拟毫米波雷达的探测效果，输出带噪声的点云或目标列表；NI平台则负责把前面两者的信息实时接入到控制器或者算法代码中，形成一套硬件在环或者软件在环的测试系统。

联合仿真的目标很直接：在虚拟世界里尽量真实地复现毫米波雷达的“所见”，然后让算法在同样接口的数据流上做开发验证，等仿真效果达到预期以后再进入实车阶段。我在做这套联合仿真时感受最深的一点是，仿真雷达模型的质量决定了仿真结果的可信度。VTD自带的雷达传感器模型虽然能模拟出目标距离、速度、角度以及基本噪声，但它毕竟不是真实雷达，点云的稀疏特性、多径反射等物理现象往往模拟得不够“痛苦”，导致算法在仿真里表现良好一上车就问题频发。因此，有条件的话可以在仿真链路里嵌入真实雷达采集的杂波数据，或者使用雷达厂家提供的回波级仿真模型，让训练和验证的数据分布更接近真实物理世界。

另一个要注意的点是仿真接口的时间同步。Carsim、VTD、NI三者运行在不同主频上，信号交互必然会存在延迟，如果时间戳对不上，算法里每一帧数据都会有错位。我在项目里一般会在仿真服务器上用一台统一时钟源做PTP时间同步，同时在每一帧数据包头打上时间戳，让下游算法识别当前数据的“新鲜度”，避免因为数据乱序造成的误判。

4.3 摄像头与毫米波雷达目标时空同步

多传感器融合里，时空同步是永远绕不开的硬骨头。摄像头是图像坐标，毫米波雷达是笛卡尔坐标，两者要做数据融合，就必须先把雷达目标投到图像像素坐标系上，或者把图像检测结果映射到雷达坐标系里做匹配。整个过程分成时间同步和空间同步两部分。

时间同步要解决的是传感器帧率不一致、曝光时间不同、数据触发时刻不同带来的时间偏差问题。常见策略是硬件触发同步，让相机曝光和雷达帧周期的起始时刻对齐；如果硬件不支持，只能在算法层面做插值外推，通过最近邻时刻匹配或者运动补偿来对齐各传感器的时间戳。在实际的多传感器系统中，时间偏差哪怕只有几十毫秒，在车辆高速运动时也会造成几米的投影误差，所以不能有半点凑合。

空间同步的核心则是标定。相机和雷达之间需要求解一组外参，包括旋转矩阵R和平移向量t，将雷达坐标系下的点变换到相机坐标系，再通过相机的内参投影到图像平面。在Nuscenes等数据集里，官方都提供了传感器标定文件和坐标变换矩阵，但自己搭建的系统里就得手动标定。常用的标定方法包括基于靶标特征的联合标定法，在雷达和相机共同视野里放置角反射器或特制标定板，分别采集雷达点云和图像，再通过对应点对求解外参。

这条变换链路在代码实现里并不长，但坑很多。我踩过的坑主要有三个：一个是雷达坐标系朝向定义不一致，有的雷达x轴朝前、y轴朝左，有的则完全相反，标定前不统一坐标系直接白干；第二个是使用了错误的相机内参，导致投影出来的雷达点和图像边缘位置系统性偏差；第三个是忘了考虑雷达到车体中心的安装位置误差，外参只标定了雷达和相机之间的关系，没有经过车体坐标系中转，导致后续融合结果在高频颠簸路段出现晃动。每次换传感器布局，都要重新完整走一遍标定流程，省不得。

5. 常见问题与排查技巧实录

5.1 目标漏检与误检

我把这段时间实车上最常见的毫米波雷达问题整理成下面这张速查表，每个问题都附上排查方向，方便实际碰到的时候快速定位。

这些案例里，让我印象最深的是隧道场景。第一次在隧道里测试L2级巡航功能时，原本跟得好好的前车目标突然分裂成好几个速度不一样的虚假目标，差点触发一次虚假紧急制动。后来用存储的原始回放数据排查才发现，隧道壁的强反射叠加目标的多径回波，在距离-多普勒图上形成了多个峰值，CFAR又把这些峰值全部当成独立目标放了出来。事后解决的思路是“多传感器互相投票”：当摄像头在隧道场景下报告清晰的前车目标，而雷达出现大量不稳定目标时，融合层优先采信摄像头，同时用雷达测速信息修正前车速度。这个策略简单实用，也是在一次一次被“吓”过之后才逼出来的方案。

5.2 点云噪点过多怎么处理

雷达点云噪点问题在近距离和强反射环境中特别突出。有一次在园区里做测试，周围全是金属围栏、混凝土立柱和钢结构雨棚，雷达输出的点云密密麻麻，几乎分不清哪些是真实目标哪些是反射杂波。

处理思路先是分析噪点的特征规律：绝大多数杂波点速度接近零，和自车运动状态解算出来的一致性很差；RCS值普遍偏低，且空间分布随机。基于这些特征，我在预处理阶段加了两道过滤：第一道是利用速度一致性做静态杂波滤除，将点云径向速度和自车速度投影量做差值比较，明显不一致的多余点直接剔除。第二道是在聚类之后增加对簇最小点数和最大空间尺寸的约束，过小的簇多半是随机噪点，过大的簇往往是护栏一类连续强反射物，在判断目标类型时单独归类处理。

补充一点，不要为了提高检测率一味的调高灵敏度。CFAR阈值调低确实能多检出一些弱目标，但代价是杂波点会成倍增加，下游聚类和跟踪的压力随之飙升。一个健康感知系统的目标应该是“不多报、不漏报”，而不是单纯追求某一帧点云数量多。

5.3 速度不准、角度抖动怎么办

速度测量是毫米波雷达的强项，但在一些复杂场景下仍然会出现异常。比如目标做加速或减速时，雷达测得的径向速度会有短暂滞后，这是因为雷达测速本质上是在一个chirp周期内的平均多普勒频移，目标加速度过快时，这个平均值并不能完全代表当前瞬时速度。处理办法是在跟踪层引入匀加速运动模型，用卡尔曼滤波平滑速度输出。

角度抖动的问题更常见，尤其出现在目标处于雷达视场边缘时。这其实是雷达阵列角度估计的天生理缺陷，靠近视场边缘的相位差变化率较小，对噪声更敏感，角度估计方差明显增大。工程上常用的缓解手段是对目标角度做时间上的平滑滤波，同时结合目标的多帧运动轨迹预测来限制角度跳变。还有一个看似笨但很有效的办法：合理设置Far-Field阵列的有效视场范围，宁可少报两个边缘目标，也不要让边缘目标的角度数据反复横跳，给下游决策模块造成困扰。

5.4 关于数据标注与真值验证的几点心得

最后补充一下目标识别的另外一个现实环节——数据标注和验证。毫米波雷达点云数据不像图像那样直观，人眼很难基于一张雷达点云图判断“这个点是行人还是自行车”，所以标注难度大、效率低。在做目标识别模型的数据集构建时，我建议充分利用多传感器信息做交叉标注：先通过时间同步把摄像头图像叠加到雷达点云上，标注员同时看“雷达点的位置+对应区域的图像内容”来打标签，比只让标注员盯着稀疏点云判断类别要靠谱得多。完标注之后再通过激光雷达点云做二次验证，能明显提高标签精度。

真值验证环节还要注意雷达特性带来的系统偏差。同一个目标在不同距离下，其点云数量、RCS统计特性差异非常大，在做模型性能评估时最好按距离分桶统计，比如10到30米、30到60米、60到100米各算一套指标，否则总体精度看着还行，实际远距离段却大概率不达标。这类问题不深入做几轮评测是看不出来的。

这套毫米波雷达的知识链路其实还很深，这篇笔记只聊了目标识别里最核心的几个环节。我自己的体会是，毫米波雷达不像摄像头那样“所见即所得”，它的每一个输出点都凝聚了一串信号处理和检测决策，只有先把底层原理吃透，后面做聚类、识别、融合时才知道问题出在哪一环。希望这篇笔记的内容能帮你少走一些弯路。后面我会继续更新关于雷达跟踪、航迹管理与多传感器深度融合的实操笔记，如果某一段踩了新的坑，也会第一时间整理到这里。