写这篇文章之前我先交代一下背景。最近我在梳理车载毫米波雷达的技术脉络找到一份标题叫《汽车雷达高级信号处理和建模技术简介》的综述性材料篇幅很长内容密度极高。我是逐段精读的一边读一边在笔记本上画信号流图、推公式、查参数前后折腾了两周才把上篇的内容消化干净。这期间踩了不少概念混淆的坑也发现很多资料里一笔带过的细节恰恰是工程落地最容易出错的地方。所以这篇博客就是我的精读笔记不打算做成面面俱到的教材复述而是把我认为真正值得停下来思考的点挑出来结合我自己做信号处理仿真和实测数据的经验讲清楚为什么这么做以及这里到底在解决什么问题。如果你刚开始接触车载雷达或者正在做雷达数据后处理、传感器建模相关的工作这篇文章可以帮你省掉大量翻资料的时间。它适合三类读者一是刚入行需要建立雷达信号处理整体框架的工程师二是做ADAS高级驾驶辅助系统系统集成但想搞清楚雷达点云内部逻辑的朋友三是准备做雷达仿真、需要理解传感器建模边界的算法工程师。1. 这份资料到底在讲什么先盘清楚主线1.1 拿到资料的第一反应标题信息量很大乍一看《汽车雷达高级信号处理和建模技术简介》这个标题很容易被高级两个字唬住。我读完才意识到这里的高级其实不是指堆了多少复杂的数学而是指汽车雷达从原始ADC采样到最终目标点云输出的这条链路涉及的信号处理环环相扣每拆开一层都有值得深挖的设计细节。资料真正的主角是信号处理和建模这两件事而建模这个词比我一开始理解得要宽得多不只是对雷达回波建立数学模型还包括对目标、对传感器特性、对系统级行为的一套完整的抽象描述方式。我读的过程中一直在想为什么作者要专门花大量篇幅讲建模而不是直接铺公式。后来想通了汽车雷达和通信雷达有个很大的差别它的使用场景高度受限路测成本高、极端场景难复现所以工程实践中大量依赖仿真和半物理验证。仿真要靠谱前提是传感器模型、目标RCS雷达散射截面积模型、传播模型都要足够贴近真实物理过程。没有建模功底后面谈信号处理就是空中楼阁。1.2 全文脉络从波形设计到目标层级的完整链路资料的内容组织可以按信号处理链路的先后顺序拆成几个层次第一个层次是硬件与波形的物理基础包括频段选择、天线布局、波形参数斜率、带宽、周期的设计理由。这一部分偏基础但却是所有后续推导的根基。第二个层次是从原始回波到点云的信号处理流程。这里包括了多普勒处理、距离FFT快速傅里叶变换、速度解模糊、角度估计等经典模块。资料没有停在教科书层面的算法讲法而是刻意强调两个工程细节一是芯片输出的数据量非常大实时处理的资源约束会直接影响算法的选型二是点云的质量不只是单个算法决定的前后级之间的数据格式和接口协议甚至比算法本身更容易成为性能瓶颈。第三个层次是检测与决策也就是门限检测、CFAR恒定虚警率检测、聚类和关联跟踪。这部分在教科书里通常讲得比较简单但在实际系统中却是最考验调参功力的地方。第四个层次才是真正建模的内容包括目标的雷达截面积模型、微多普勒特征建模、以及整个雷达系统的端到端仿真模型。模型怎么建、精度边界在哪里、哪些特征可以简化、哪些特征一旦简化就会失真资料里给了不少值得记笔记的结论。1.3 为什么建模二字特别重要最容易忽略的一点是汽车雷达的建模并不只是仿真团队的事情。哪怕你只做真车测试的数据分析也逃不开模型思维。举例来说当你看到一个点云目标时你需要理解这个点云在物理上是怎么由多个反射中心叠加形成的当你在做阻挡检测时你需要知道灰尘和泥水对天线罩的影响在模型上表现为一个随距离变化的额外衰减项当你在调雷达的俯仰角度时你得知道地面的多径反射会让目标产生一个虚影而这个虚影本质上就是一个多路径模型。从更宏观的视角看建模决定了传感器系统在虚拟环境里测出来的性能是否可信。现在很多算法开发都依赖仿真场景回灌比如把仿真点云输入给感知模块。如果雷达模型把每个目标都当作一个理想的单点源那点云在空间上的扩展性、在角度分辨率下的分裂现象就完全体现不出来感知算法在仿真里跑得再好上了车面对真实点云照样抓瞎。资料里关于这一点反复强调了一个原则模型的复杂度要和算法验证的目的匹配不是越精细越好而是要在你不知道答案的地方保留足够的物理保真度。2. 汽车雷达的第一性原理波形、天线与测距测速2.1 FMCW为什么成了汽车雷达的默认波形汽车雷达的工作频段当前以77GHz为主欧美的一些早期产品用24GHz现在新设计基本都向77GHz聚拢。这个频段的取舍逻辑并不复杂波长越短同等物理尺寸下天线增益越高角分辨率越好带宽越大距离分辨率越好。77GHz附近可以用的带宽比24GHz大得多这对雷达最重要的距离分辨能力是决定性的。波形方面FMCW调频连续波几乎是绝对主流。资料里也提到还有其他波形比如OFDM正交频分复用雷达、相位编码雷达等但FMCW能在低成本、低复杂度的前提下满足车载环境的大部分需求所以一直被大范围使用。理解FMCW我推荐一个笨但有效的类比想象你在一个山谷里对着对面山壁持续喊话但你的喊声不是固定音调而是像唱歌一样音调越来越高。回声返回时当前你发出的音调和回声的音调之间就有了一个差值这个差值的大小和距离直接相关。FMCW雷达的核心就是通过当前时刻频率和回波频率之间的差值来反推目标距离。2.2 Range和Velocity怎么解出来快时间与慢时间分解资料里推导FMCW测距的方式非常经典但我想强调的是其中容易被初学者忽略的一步为什么回波的频率差还包括多普勒项。在快时间维度上即一个chirp内部的采样时间轴上回波的频率差近似为f_beat ≈ S * (2R / c)其中S是调频斜率R是目标距离c是光速。这个公式成立的前提是目标的径向速度不大在一个chirp内距离变化可以忽略。在实际车载场景下这个假设在大多数情况是合理的但在相对速度极高的对向场景比如两车相对速度接近300km/h时就需要考虑速度对频率差的影响了。慢时间维度上即多个chirp之间目标运动导致相位随chirp序号线性变化。这个相位的导数就是多普勒频率。资料中对这一块的推导带着读者遍历了一遍先在距离维做FFT然后在多普勒维做FFT最终得到一个Range-Doppler谱。整个过程的计算量并不小一个常见的中端雷达芯片一帧数据可能有几百个chirp每个chirp上千个采样点做二维FFT的矩阵规模动辄几十万点。这里有个工程上决定算法选型的细节距离FFT和多普勒FFT的顺序并不能随意调整因为多普勒FFT需要距离压缩后的数据作为输入。数据在内存中的组织方式决定了怎么访问才能保证cache友好很多嵌入式工程师调试了几天性能问题最后发现是FFT的维度遍历顺序反了导致内存访问不连续耗时翻了几倍。这在资料里没有展开但实际做优化时一定要留意。2.3 天线阵列与角度从相位差到到达角很多人觉得测距测速尚且好懂一到角度就晕。角度的核心其实非常朴素不同位置的天线接收到同一个目标的回波存在一个传播距离差这个距离差表现为相位差。只要知道天线间距d和目标回波的到达角θ相位差就是Δφ 2π * d * sin(θ) / λ反过来测得相位差就能解出θ。资料里讲的角度估计部分有几个反复出现的坑。第一个是天线间距d和阵列孔径的关系如果d超过半波长会出现角度模糊如果d太小相位差对角度变化不够敏感测角精度变差。实际产品天线间距往往不是理想的λ/2因为还要考虑与天线罩、物理布局的匹配所以最终测角性能是一个工程折中的结果。第二个坑是相位差只能在(-π, π]之间唯一确定所以sin(θ)的值必须落在(-λ/(2d), λ/(2d)]区间内超出就模糊。只要d≤λ/2单阵元间距就不会模糊。很多雷达前端的发射天线和接收天线数量不多为了获得更好的角分辨率往往会采用MIMO多输入多输出技术用较少的物理天线虚拟出更大的阵列孔径。资料里谈到MIMO的时候只是提到虚拟阵列的概念但实际工程时波形必须支持正交性时分、多普勒偏移等多种方案这会直接影响后续处理的复杂度。3. 信号处理链路拆解从ADC原始数据到目标点云3.1 芯片输出的脏数据长什么样精读资料的过程中我最大的收获之一是意识到芯片原始数据和我们教科书里画的理想中频正弦波之间差距非常大。一个真实的ADC输出首先是直流偏置。这个直流分量由混频器泄漏、自混频等原因产生在距离维FFT后会表现为频谱上的零频附近很大的尖峰。如果不做去直流处理它会抬高噪声底还会掩盖近距弱小目标。另一个问题是I/Q不平衡。理想情况下中频信号被正交混频分成I路和Q路幅度完全一致、相位差恰好90度但真实电路一定存在幅度和相位误差这会导致镜像频率泄漏使得真实目标的谱峰在频谱上产生一个对称的假峰。资料里特别提到如果只用单通道比如只使用I路或只使用Q路中频信号会同时在正负频率上出现距离估计变成全正数距离模糊目标镜像问题会比较麻烦。这也是为什么现在的雷达芯片基本都提供完整的复数中频输出就是让信号处理端可以使用希尔伯特变换后的解析信号。我在真实数据处理过程中还发现ADC的饱和失真也是一个很容易被忽略的问题。近距目标的回波功率非常强如果不做增益控制或限幅ADC直接削顶谐波分量会变成很多假目标。解决方向包括模拟前端的AGC自动增益控制、数字域的削峰补偿以及接收链路里的低噪声放大器的增益切换策略。这些内容资料里不会展开但做系统的人必须心里有数。3.2 Range FFT与Doppler FFT的实操细节关于FFT窗函数的选择资料里只提了一句需要权衡主瓣宽度和旁瓣电平但这一句背后有大量实操经验。以距离维为例矩形窗的主瓣最窄距离分辨率最好但第一旁瓣只比主瓣低约13dB这意味强目标旁边会拖出很多假旁瓣。汉宁窗的旁瓣低但主瓣变宽距离分辨率下降。实际工程里通常会根据当前场景动态选择窗类型视野空旷的高速公路上用矩形窗或低旁瓣窗换取更干脆的分辨能力城区拥堵场景里强反射体多就偏向更高的旁瓣抑制性能。多普勒维FFT的采样点数量直接决定了速度分辨率Δv λ / (2 * T_frame_chirps)其中T_frame_chirps是一帧内所有chirp的总时间。如果想要1m/s以下的速度分辨率需要的chirp数量并不少。但chirp数量变多又会让帧周期变长导致最大不模糊速度变小、回访率下降。这个取舍在资料中是用一个参数表展示的我觉得是全文最实用的几个表格之一。Doppler维还有个常见问题就是盲速。如果目标的速度恰好让每个chirp之间的相位变化是2π的整数倍那么多普勒FFT之后目标会落在零频附近与静止目标混在一起。汽车雷达里这个问题尤其突出因为车辆本身也在运动。解决办法不外乎多种波形参数交替发射或使用多普勒补偿算法但成本和复杂度都在那里需要产品团队下定决心。3.3 角度估计DBF也好MUSIC也罢角度估计的算法选项非常多。资料在上篇里主要介绍了数字波束形成DBF的起点和极限也提到了超分辨算法如MUSIC、ESPRIT存在的必要性但没有展开具体推导。我读到这里时停下来仔细对照了一下工程现状。DBF的做法本质上是给阵列各个阵元的输出加一组复加权系数让天线波束指向设定方向。它的好处是稳健、计算量小对误差不敏感所有主流雷达芯片都支持硬件级别的DBF计算。但它有个硬约束角度分辨率大约等于λ/(N*d)量级也就是阵列孔径的倒数。你想分辨两个角度相距一度左右的目标阵列孔径就需要做成米级这在车头或保险杠上几乎不可能。所以当需要更细的角度分辨时超分辨算法就展现出价值。MUSIC算法的核心是对阵列协方差矩阵做特征分解把信号子空间和噪声子空间分开然后通过谱峰搜索估计角度。理论上它可以突破瑞利极限。工程上最大的问题是协方差矩阵需要足够多的快拍即多个chirp的时间样本来估计得准而车载场景里目标是运动的相干源的存在还会让协方差矩阵秩亏损导致算法失效。资料里明确提了一句超分辨算法在实测数据上的表现远不如仿真理想这句话我举双手赞同。做仿真时每个通道的信噪比、相位一致性都是理想的MUSIC能分清两个相隔两度的目标实测时只要通道间有一点点幅度或相位失配谱峰就糊成一团。实际做系统的时候要么在软件里做通道校正要么在算法前串联一个自校正流程。3.4 点云是怎么生成的CFAR检测与聚类从Range-Doppler谱到点云中间最经典的一步是CFAR检测。CFAR的核心思路是自适应地确定检测门限使得虚警概率恒定。实际工程通常不做全局门限而是对每个待检测单元取其邻近单元的平均功率作为噪声估计再乘以一个缩放因子。这里面窗口的选择很有讲究保护单元太少强目标自身就会拉高噪声估计把目标自己给压没了保护单元太多两个邻近目标可能分不清。我在资料上做了个批注CFAR只是检测器的骨架真正的难点在目标分裂。一个真实的车辆在雷达视线上往往表现为多个反射点比如保险杠角落、后视镜、轮拱间距可能只有几十厘米。如果距离分辨率足够好它们就会在Range-Doppler谱上形成多个邻近峰。CFAR检测可能把它们判成多个点也可能因为互相抑制只剩下一个点。这个行为直接决定下游跟踪算法处理的是一个目标多个点还是多个目标各自独立处理不当就会频繁产生航迹分裂和合并。聚类阶段解决的就是这个问题。常见方法是基于距离和速度的近邻聚类或基于密度的DBSCAN聚类。DBSCAN的优势是能自动发现任意形状的簇而且抗噪能力强。缺点是参数邻域半径eps和最小点数MinPts在稀疏场景和密集场景下需要动态调整很难一组参数走天下。我的经验是点云的坐标变换之前不要急着聚类先把速度和角度误差分布标定出来再用误差椭圆做距离权重效果会好很多。4. 建模的核心思想建模到底在建什么4.1 传感器模型、目标模型、还是场景模型资料里把建模分成了三个层次我顺着这个思路做了进一步细化。第一个层次是传感器模型包含雷达发射波形、天线方向图、收发射通道的噪声特性、ADC位数与饱和门限等。它的作用是尽量精确地复现同样的物理世界里这台雷达到底会看到什么。传感器模型的输出通常是基带I/Q数据有时也直接输出Range-Doppler谱。第二个层次是目标模型描述的是雷达视角下的目标电磁散射特性。对汽车来说关键挑战在于车身不是理想导体光滑曲面而是由大量不同形状的部件组成的复杂结构。在不同方位角下雷达看到的是完全不同的散射中心组合。如果目标模型把一个车简化为一个点那点云的空间分布、闪烁特征就全丢了。资料里强调RCS不是一个标量而是随角度、频率变化的复向量这句话值得反复去品。第三个层次是场景模型指的是道路、护栏、交通标识、其他车辆形成的多目标环境以及目标之间的相互遮挡关系、多径传播。城市峡谷场景里护栏连续反射形成的幽灵点是很多雷达感知算法的梦魇本质上就是场景模型没有把多径加进去。4.2 目标RCS模型的坑RCS雷达散射截面积是目标对雷达电磁波的有效反射面积的量度。它不是目标的物理面积而是在雷达接收端看来等效为一个多大面积的理想反射体的回波强度。一个普通轿车的RCS典型值在几平方米到几十平方米之间但这不是一个固定值它随方位角剧烈起伏可能在某些角度掉到1平方米以下在正侧向又飙到几十平方米。资料里有个我特别认同的观点很多仿真项目直接用查表方式给每个目标赋值一个固定RCS然后套用雷达方程就完事了这对于远距离粗粒度存在性仿真够用但对点云级算法开发完全不够。因为真实目标回波不是单个点而是多个散射中心回波的相干叠加在不同视角下会干涉增强或相消。建模时若只给一个RCS标量点云强度和闪烁统计特性都与实测不吻合。我做仿真时处理过一个案例某目标在模型里被设成固定RCS10dBsm仿真点云非常稳定跟踪器稳定输出一条航迹换用多散射中心模型后目标在相邻几个方位角之间切换时点云强度跳变了七八个dB跟踪器的置信度输出也出现明显波动。后者显然更接近真实。仿真模型用哪种复杂度完全取决于你的下游算法对点云强度敏感性有多高。4.3 从仿真视角看全数字与半实物的取舍建模的最终目的通常是仿真资料里对全数字仿真和半实物仿真HIL硬件在环的边界做了比较清晰的描述。全数字仿真指的是雷达模型也跑在计算机里输入一段虚拟场景输出虚拟点云。优点是场景灵活、可批量回归、成本低。缺点是模型再精细也很难复现硬件真实噪声、温度漂移、装配误差引入的通道失配。这就导致在全数字仿真里性能很好的算法在实车上可能因为通道失配直接破功。半实物仿真则是把真实雷达硬件接上目标模拟器目标模拟器产生射频回波注入给雷达让雷达以为自己身处虚拟场景。目标模拟器的核心是射频前端和多通道延时/多普勒模拟能力。这个方案的保真度远高于纯数字仿真因为它把真实雷达的射频前端、ADC、信号处理链全部跑进去了。代价是硬件成本高、通道数有限无法模拟特别复杂的场景。从我的实践看一个产品级项目通常兼顾两者算法迭代阶段用全数字仿真把参数空间跑宽系统验证阶段用半实物仿真跑几个关键场景。资料里提醒了一个点就是全数字仿真出的点云有时过于干净这会让下游感知算法产生乐观偏差称为仿真自信陷阱。解决方法是主动注入噪声、加随机故障模拟、引入点云缺失/分裂/粘连这些错觉现象。这需要在传感器模型里做大量的工程性扩展单纯靠增加高斯噪声是不够的。5. 精读时的几个高频疑问与个人理解5.1 分辨率墙带宽到底决定了什么距离分辨率的一般公式是ΔR c/(2B)B是调频带宽。很多人会问为什么不是采样率决定分辨率我试着用一个简单的方式来理解。FFT的频率分辨能力由观察时长决定而FMCW距离维上等效的时长就是chirp的扫频时间扫频时间T_sweep和调频斜率S的关系是B S × T_sweep。频率差分辨率是1/T_sweep对应的距离分辨率是ΔR c/(2S) × (1/T_sweep) c/(2B)所以直流上分辨率完全由带宽决定和采样率无关。采样率只决定最大不模糊距离比如ADC采到的最高中频频率对应最远距离。同样是77GHz频段带宽选1GHz还是选200MHz距离分辨率直接从0.15m差到0.75m。这个差别在做不做目标内部尺寸测量这个问题上影响很大。5.2 速度模糊最大不模糊速度与分辨率的矛盾最大不模糊速度由两个chirp之间的时间间隔PRT决定V_max λ / (4 * PRT)也就是说chirp发得越密集能测的速度范围越大。但这样的话想保持相同的速度分辨率就必须增加chirp数帧长又会变大。这就是为什么很多汽车雷达在高速场景和低速泊车场景用的波形参数完全不同高速场景要把PRT缩短牺牲一些速度分辨率换取大测速范围低速泊车场景速度本身不高反而可以把PRT拉长获得精细的速度分辨率。在实际产品里波形参数的切换是动态的需要考虑目标跟踪的连续性。频率规划一旦变化同一目标在不同帧间可能速度估算量程不一致处理不当就会有跳动。资料在上篇虽然没有展开谈波形调度的动态性但做系统的需要特别关注这个前向兼容问题。5.3 角度分辨率为什么MIMO虚拟阵列不是万能的MIMO的基本思想是切换不同的发射天线发射波形接收时通过分离不同的发射源等效形成一个比物理阵元多很多的虚拟阵列。比如4发4收如果波形设计得当可以形成最大16个虚拟阵元角度分辨率比单发4收的物理阵列显著提升。但这个增益不是白来的。第一MIMO需要发射天线和接收天线在空间上满足特定的排布约束否则虚拟阵列会出现空洞。第二发射天线之间必须有良好的正交性工程上常用时分方式即逐个发射天线轮流发射这会降低功率孔径积导致单帧信噪比下降。做信号处理的朋友需要留意角分辨率的提升和测速性能是联动关系——你可用的有效chirp数变了多普勒谱的形状也会变。我在资料上写了一个备忘MIMO虚拟阵列只是提供了一种形成大孔径的手段真正的角度估计精度依然受信噪比和通道校正质量的制约千万不要在指标分解的时候把虚拟阵列的数量当成最终角分辨率。6. 读完上篇之后的落地建议6.1 要复现这套处理链建议的工具路径如果要从头搭建一个基本的信号处理验证环境我的经验是分两步走。第一步用脚本语言做离线验证。所有主流科学计算语言都可以胜任推荐路径是先用现成的FFT库搭Range-Doppler谱再用仿真点生成器验证距离、速度、角度解算是否正确。做离线验证时一定要先把坐标变换写好从极坐标距离、角度转到笛卡尔坐标时角度的定义域和方向必须和雷达安装方向保持一致否则后处理出来的点云朝向会整体旋转一个角度容易在项目初期造成混乱。第二步是做实时C/C实现。最关键的优化点有三个FFT函数的指针对齐和内存布局、复数乘法的位宽处理、以及CFAR窗口遍历时的边界条件处理。很多崩溃bug都出在最后一个元素上处理时务必多测边界。6.2 上篇里值得反复咀嚼的几个知识点如果要我列一个优先级清单我会这么排FMCW的拍频公式不只是距离频率还包含了多普勒项理解它的耦合关系是理解后面所有解耦处理的前提。Range-Doppler谱的二维FFT顺序不是随便定的它决定了目标相参积累的效果以及计算效率。角度估计的DBF和超分辨不是替代关系而是互补关系工程上通常是级联执行超分辨只做局部筛选不做全局搜索。RCS建模至少要区分标量RCS和多散射中心模型两种复杂度具体选型取决于下游是做探测概率评估还是做点云级算法验证。所有仿真模型都要有意识注入非理想效应通道失配、增益漂移、饱和、遮挡、多径。否则仿真性能会给人虚高的信心。6.3 给下一篇留的问题清单因为是上篇精读进展到这里其实还有一大块内容没覆盖。我自己在笔记末尾列了三个问题准备下篇集中解决。第一目标跟踪与航迹管理的建模细节特别是点云分裂时的航迹合并/分裂决策逻辑。第二雷达与其他传感器如摄像头、激光雷达融合时建模层面需要统一哪些坐标和误差语义至少不能让雷达的球坐标误差模型和摄像头的像素误差模型直接用同一个方差去初始化卡尔曼滤波器。第三整车仿真链路中雷达模型与场景引擎之间实时交互的时间同步策略这听起来不像是信号处理问题但在系统工程里常常是瓶颈。整理完这篇精读笔记我最大的感觉是汽车雷达的高级不在于某几个炫技算法而在于所有模块之间严丝合缝的配合。做信号处理的人如果只盯着自己的那一级模块很容易在点云输出之后发现上一层的数据特征和自己的算法假设对不上。反过来从建模的角度提前把理想算法和真实数据之间的差距想清楚后续开发可以少走很多弯路。最后分享一个小习惯我以前读这类综述喜欢直接划重点公式现在改成在公式旁边标注这个公式在什么条件下会失效。比如拍频公式在低信噪比时估计方差很大FFT测角在阵元失配时会偏转CFAR在非均匀杂波中会性能衰减。把这些失效条件写出来比记住公式本身有用得多。如果你也在读类似的雷达资料建议试试这个方法读一遍相当于别人读三遍的效果。