企业官网建设流程全解析

翻到第9章的时候，我正对着一组跑不出目标的实测数据发愁：波形参数调了三轮，距离维上始终有一层抬不起来的底噪，点云稀得像撒了一把芝麻。那一章标题叫“汽车雷达的应用概述”，乍看像全书最“水”的一节，讲的无非是雷达装在车上能干哪些活。真正读进去才发现，它其实是在回答一个更要命的问题——信号处理链路上每一个参数，最后都要落到某个具体功能、某个安装位置、某类天气场景里去交差。自动驾驶里的毫米波雷达从来不是实验室里的孤立传感器，它的距离分辨率、角度精度、刷新率，甚至外壳材料，都是被应用场景反推出来的。这篇笔记就把第9章的内容拆开，结合我自己在几个量产项目和台架调试里踩过的坑，把“应用概述”这层皮下面的东西讲透。适合刚接触车载雷达信号处理的同学，也适合做感知融合、功能标定、系统集成的朋友拿来对照——你会发现很多调试时的怪现象，答案其实早在需求定义阶段就埋下了。

1. 第9章讲了什么：把雷达从信号拉回车上

1.1 章节定位：为什么“应用概述”排在信号处理之后

这本书的编排很有意思，前面几章讲调频连续波、距离多普勒处理、角度估计、检测跟踪，全是硬核数学，第9章突然转去讲应用。我一开始以为是凑篇幅，读完才明白这是有意为之。信号处理的世界里，参数是可以自由组合的：带宽想开多大开多大，chirp 想多密多密。可一旦装到车上，约束就从四面八方压过来——保险杠的透波率限死了频段和功率，安装高度限死了俯仰覆盖，功能响应时间限死了帧周期，成本限死了天线通道数。

所以这一章的作用，是把前面所有抽象的公式按到现实地面上。作者列举的那些功能场景，本质是一张张“指标合同”：AEB 要求多远发现横穿行人，ACC 要求多稳地跟踪前车，BSD 要求在相邻车道里分出摩托车和护栏。这些合同条款最终会翻译成带宽、阵元数、积累时间和检测门限。我在做第一个项目时吃过亏，算法端拼命优化 CFAR 的检测概率，结果系统集成那边一句“那颗雷达只有两发四收”，直接把我辛苦搭的超分辨方案废掉了。后来我养成一个习惯：拿到任何一颗雷达，先问它装在哪、服务哪个功能，再谈算法。

1.2 一台车上的雷达分工：功能清单与场景拆解

第9章把车载雷达的应用大致分成几类：前向的长距探测、侧后方的盲区监测、角雷达的交通穿行预警、低速泊车用的近距探测，还有舱内的生命体征检测这类新方向。这些功能对雷达的要求差异极大，用同一颗雷达通吃在工程上并不划算。长距前向雷达追求的是作用距离和角度精度，宁可贵一点、大一点；角雷达追求的是覆盖扇区和成本，宁可距离短一些；泊车雷达追求的是近距盲区和极小目标，对刷新率要求反而没那么高。

下面这张表是我根据章节内容和实际项目经验整理的对照，参数取的是行业里比较常见的量级，不同厂商会有出入，但量级关系基本稳定。

注意：作用距离这一列不要当成产品规格书抄，它和目标的雷达截面积强相关。表里默认的是轿车量级目标，换成行人或者自行车，距离要打对折甚至更多。

我在一个项目中做过一次实测：同一颗前向雷达，对轿车稳定跟踪到 180 米左右，换成行人，稳定跟踪距离掉到 70 米出头，再远就只能零星出点。这不是算法不行，是雷达方程摆在那里——行人 RCS 大约只有轿车的十分之一到二十分之一，回波功率按四次方根关系折算，距离自然缩水。所以做 AEB 的行人场景，光靠前向长距雷达往往不够，得配合摄像头做前融合，或者用更高增益的天线设计。第9章提到应用场景时要结合目标特性一起看，这句话看着平淡，实际是整章最值钱的一句提醒。

1.3 读这一章的正确顺序：先看约束，再看算法

我的建议是反着读。先翻到功能清单，挑一个你最关心的功能，比如 AEB，然后倒推：它要求多远发现目标，要求多快做出判断，要求在什么天气下不能失效。把这三个问题回答清楚，再回头看信号处理章节里对应的参数——带宽决定距离分辨率，帧周期决定响应时延，天线口径决定角度精度。

这么做的好处是，你不会陷入“参数调优”的无底洞。雷达调参最大的陷阱是没有终点：提高带宽能改善分辨率，但会抬高采样率和数据量；缩短帧周期能提升响应，但会减少相干积累时间，速度分辨率变差；增加阵元能提高角度精度，但成本和布板面积顶不住。只有把应用约束摆在前面，调参才有一个明确的停止条件——够用就行。

2. 频段选择背后的账：24 GHz 和 77 GHz 差在哪

2.1 波长决定了一切：从天线尺寸到分辨率

第9章在讲应用时顺带提了频段划分，篇幅不大，但这是绕不开的基础。车载雷达主流频段是 24 GHz 和 77/79 GHz 两档，波长分别约 12.5 毫米和 3.9 毫米。这个差别听起来只是个数，实际影响是全链条的。

最直接的是天线尺寸。阵列天线的阵元间距通常取半波长，24 GHz 下是 6.25 毫米左右，77 GHz 下只有约 1.95 毫米。这意味着同样的物理尺寸，77 GHz 能塞下更多阵元，或者同样的阵元数，77 GHz 的板子小得多。我在对比两款雷达拆机图时印象很深：24 GHz 的板子上天线阵列铺得满满当当，77 GHz 的阵列只占一角，剩下全是射频前端和处理器。寸土寸金的车规板子上，这个差别直接决定能不能把雷达做成掌心大小。

带宽的差别更关键。24 GHz 频段可用的带宽通常只有 200 MHz 量级，77 GHz 能开到 1 GHz 以上，79 GHz 甚至能到 4 GHz。距离分辨率等于光速除以两倍带宽，代进去算一下：200 MHz 对应 0.75 米，1 GHz 对应 0.15 米，4 GHz 对应 3.75 厘米。0.75 米的分辨率什么概念？一辆轿车长度四米多，理论上会被切成五六个点，但实际因为目标起伏和旁瓣泄漏，常常糊成一团，很难分辨紧挨着的两辆车。这就是为什么现在前向雷达几乎清一色转向 77 GHz 以上。

2.2 为什么量产车几乎都换成了 77 GHz

除了分辨率和尺寸，还有几个现实原因。一是大气衰减，77 GHz 附近有一个氧分子吸收峰，信号衰减比 24 GHz 明显，听起来是缺点，但从另一个角度看反而降低了远处同频设备的相互干扰概率，对密集车流场景是好事。二是天线增益，同样的口径，77 GHz 的增益更高，波束更窄，对角度测量有利。

三是产业配套。24 GHz 频段在全球范围内的可用带宽和用途限制比较杂，长期演进空间有限，芯片厂商的重心早就转到 77/79 GHz，射频前端、基带、封装工艺都成熟了，单通道成本反而更低。我在选型时算过一笔账：24 GHz 方案虽然射频器件便宜，但因为通道数上不去、带宽不够，要达到同等角度精度得靠机械扫描或者额外传感器补盲，系统总成本并不占优。

提示：频段相关的频谱使用规则各地差异较大，做产品定义时要按目标市场的现行技术标准确认，这里只讨论物理特性和工程取舍，不涉及具体规定。

2.3 频段选择的实际约束清单

如果你正在做方案选型，可以用下面这几条快速过一遍：

• 需要 0.2 米以内距离分辨率来分辨相邻车道车辆的，直接看带宽 1 GHz 以上。
• 安装空间受限、需要高集成度的角雷达，77 GHz 的单片方案更合适。
• 近距泊车场景对分辨率要求不高但对最小可测距离敏感，重点看收发切换时间和天线近场特性，不必盲目追求大带宽。
• 舱内微动检测这类特殊应用，频段选择更多考虑的是人体反射特性和天线尺寸，未必跟车外雷达走同一路线。

3. FMCW 体制：为什么它是车规雷达的默认答案

3.1 一个 chirp 里同时藏着三件事

第9章讲应用时没有重复推导 FMCW 原理，但对体制选择的理由给了几句话。我把这几句话展开一下，因为这是理解后续所有参数的前提。

调频连续波在一个 chirp 周期内，发射频率随时间线性上升，遇到目标反射回来，和当前发射信号在混频器里一搅，得到一个差频信号，也就是中频。这个中频里同时编码了三样东西：目标的距离对应频率差，目标的径向速度对应相邻 chirp 之间的相位变化，目标的方位对应不同接收通道之间的相位差。一次数据采集，三个维度的信息全部拿到，这是脉冲体制做不到的，也是 FMCW 在车规场景里胜出的核心原因。

再往深一层，FMCW 的发射功率可以做得低，因为它是连续发射、长时间积累，不需要高峰值功率；收发同时工作，没有脉冲体制的收发切换死区，近距盲区小。这两点对车载场景太重要了——发射功率低意味着射频器件和散热压力小，近距盲区小意味着泊车、拥堵跟车这类场景能顶得住。

3.2 关键公式与一次完整的参数推演

我把几个核心公式和一组实际参数整理成脚本，跑一遍就能看清各维度之间的牵制关系。下面这段是用 Python 做的推演，参数取的是一颗典型的中距雷达配置。

c = 3e8 # 基本配置 fc = 77e9 # 中心频率 lam = c / fc # 波长 B = 1e9 # 扫频带宽 T_chirp = 50e-6 # 单个 chirp 周期 N_chirp = 128 # 每帧 chirp 数 N_sample = 512 # 每 chirp 采样点数 fs = 40e6 # ADC 采样率 T_frame = N_chirp * T_chirp print("波长 mm:", round(lam * 1000, 3)) print("距离分辨率 m:", round(c / (2 * B), 3)) print("调频斜率 Hz/s:", B / T_chirp) print("最大不模糊速度 m/s:", round(lam / (4 * T_chirp), 2)) print("速度分辨率 m/s:", round(lam / (2 * T_frame), 3)) print("帧率 Hz:", round(1 / T_frame, 1))

跑出来的结果值得逐条看。波长 3.9 毫米，距离分辨率 0.15 米，调频斜率 2×10¹³ Hz/s，最大不模糊速度约 19.5 米每秒，折合 70 公里每小时，速度分辨率约 0.039 米每秒，帧率 156 赫兹。这里面有两个数字要特别注意。

最大不模糊速度只有 70 公里每小时，意味着对向车辆一来，相对速度轻松破百，速度维就会发生模糊，测出来的速度和真实值差一个或多个速度模糊区间。这在 ACC 跟车时是致命的——你以为前车在减速，实际它在加速。工程上的解法通常是多管齐下：缩短 chirp 周期提升不模糊速度，或者用多组不同周期的 chirp 做解模糊，再或者借助目标跟踪的时间连续性做速度拟合。

帧率 156 赫兹听起来很高，但这是理论值，实际要考虑帧间处理时间、数据传输时间，真实输出点云的帧率往往掉到 20 到 30 赫兹。对 AEB 来说这个刷新率够用，对更高速的响应场景就要压缩每帧的 chirp 数，牺牲速度分辨率换刷新率。

3.3 速度模糊：解模糊的几种工程做法

速度模糊是新手最容易栽的地方。我见过一个团队调了两周，一直以为目标检测有问题，最后发现是速度维混叠，跟踪器把对向来车当成了同向慢车。

第一种做法是变周期 chirp，两组 chirp 周期一长一短，各自算出的速度值做比对，利用余数关系还原真实速度。这个方法的代价是帧内时间变长，或者占用更多 chirp 数量。第二种做法是借助先验信息，比如用跟踪器上一帧的速度做预测，在当前帧的模糊解里挑最接近的那一个。这个做法简单，但在目标突然出现时容易出错。第三种是提高不模糊速度本身，缩短 chirp 周期，代价是采样率和数据量上升，同时中频带宽占用变大，对射频前端要求更高。

我个人的经验是，前向雷达用第一种加第二种组合，角雷达因为作用距离近、相对速度普遍不高，直接缩短 chirp 周期通常够用，省下来的算力留给角度估计。这个取舍没有标准答案，要结合你的功能定义来定。

4. 从波形到指标：一次完整的雷达配置推演

4.1 距离维：分辨率、量程和 ADC 采样率的三角关系

距离维的三个指标互相咬得很死。分辨率由带宽决定，这个没得商量；最大探测距离由中频带宽和 ADC 采样率决定，中频频率等于调频斜率乘以传播时延，200 米的目标在 2×10¹³ Hz/s 的斜率下，中频大约 26.7 MHz，按奈奎斯特采样率至少要 53 MHz 以上，实际要留余量。如果 ADC 只跑到 40 MHz，最大无模糊距离就会被卡在 150 米附近。

这里有个容易被忽略的点：中频信号是有带宽的，一个分布式目标回波不是一根谱线，而是一段。目标在距离维展开之后，中频带宽还要乘上目标尺寸对应的频率跨度。做远距目标检测时，如果只按点目标算量程，实际会漏掉一部分能量。我在台架上做过对比，同一颗雷达检测一辆卡车，按点目标算能到 200 米，实际在 160 米之后信号就开始明显衰减，原因就是卡车长度带来的距离展开。

还有一个参数是采样点数。512 点在 40 MHz 采样率下对应 12.8 微秒的采样窗口，要覆盖整个 chirp 的有效回波时间。采样窗口设短了，远距目标的回波落在窗口之外，直接丢失；设长了，浪费数据量还给后端增加负担。这个窗口长度要按最大作用距离对应的时延来配，留 20% 左右的余量。

4.2 速度维：量程、分辨率和帧率的互斥

速度维的矛盾更明显。不模糊速度与 chirp 周期成反比，速度分辨率与帧时长成反比。想要速度量程大，chirp 要短；想要速度分辨率细，帧要长。两者不可能同时满足。

实际的调法是这样的：先按功能确定速度量程。ACC 跟车场景，本车 120 公里每小时，前车可能 80，相对速度 40 公里每小时，约 11 米每秒，那 19.5 米每秒的不模糊速度是够的。但 AEB 要考虑对向来车，相对速度可能到 200 公里每小时，约 55 米每秒，就必须解模糊或者缩短 chirp。确定量程之后，剩下的帧时长全部用来堆 chirp 数，把速度分辨率做细。128 个 chirp 给到 0.039 米每秒，已经足够区分行人和慢速自行车了。

我在调一个拥堵跟车场景时发现，速度分辨率太细反而不完全是好事。相邻两个 chirp 之间的相位变化非常小，微小的相位噪声就会被放大成速度抖动，点云在速度维上看起来毛刺很重。后来把帧时长压缩了一点，速度分辨率放宽到 0.06 米每秒，点云明显干净了。这个经验说明参数不是越精细越好，要和系统的相位噪声水平匹配。

4.3 角度维：MIMO 虚拟阵列是绕不开的一步

角度分辨率是我认为整章最该被反复强调的部分。公式很简单，均匀线阵的角度分辨率近似等于波长除以阵元数与阵元间距的乘积，间距取半波长时就等于 2 除以阵元数，单位是弧度。八阵元算下来是 0.25 弧度，约 14 度。这个精度什么概念？在 100 米外，14 度的角度误差对应横向 24 米的定位偏差，相邻车道的车根本分不开。

所以车载雷达必须上 MIMO。四发八收，虚拟出 32 个通道，角度分辨率能压到 3.6 度左右。如果阵元排布优化过，比如用稀疏阵或者非均匀阵扩展孔径，还能再改善一些。这里有个工程细节：虚拟阵列的排布不是简单地把收发阵元摆成两条线就完事，要保证虚拟阵元尽量连续、不出现空洞，否则会出现栅瓣，产生虚假目标。我在看一款雷达的点云时发现正后方总有规律性的鬼影，查了半天是虚拟阵列有周期性空洞导致的栅瓣。

实际的角度精度还受信噪比影响。低信噪比目标的角度估计方差很大，同一个行人，近处角度稳稳的，远处角度就开始左右横跳。这不是算法问题，是克拉美罗下界摆在那里。做融合时如果直接拿远处目标的原始角度做关联，很容易关联错，通常要在跟踪器里做角度平滑。

4.4 一份可以照着抄的参数表和实测记录

把上面几节的内容汇总成一张配置表，这是我目前手上一个中距前向方案的参数，供参考，不代表任何产品的实际规格。

实测记录里有两个数据值得分享。一个是静止目标的检测，在 5 米以内近距，因为收发泄漏和直流偏置，静止目标很容易被高通滤波滤掉，需要在信号链前端保留一段近距处理通道，或者用更长的 chirp 把近距目标的中频推到滤波器通带内。另一个是金属护栏，沿着路边连续分布的护栏在距离速度图上会形成一条拖尾，看起来像一堵移动的墙。这个现象在第9章讲应用场景时没有展开，但对 BSD 功能影响很大，后面第6节再细说。

5. 数据怎么用：点云、目标与融合层级

5.1 信号处理链上每一步都在丢信息

第9章在讲应用时提到雷达输出有多种形态，原始数据、点云、目标列表。这三种形态对应完全不同的融合策略，理解它们各自丢了什么信息，是做系统设计的基本功。

原始数据是 ADC 采样后的复数矩阵，信息最全，但数据量惊人。按前面那张配置表算，32 个虚拟通道，每帧 128 个 chirp，每个 chirp 512 个采样点，16 位精度，一帧就是 4 MB 出头。按 20 帧每秒算，数据率超过 80 MB 每秒。这个量级在量产车上几乎不可能实时传出来，所以绝大多数方案在雷达内部就完成了距离维和多普勒维的 FFT。

点云是检测之后的结果，每个点包含距离、速度、角度、信噪比。这一步损失的是同一距离速度单元里多个目标的叠加信息，以及目标内部的散射分布。好处是数据量小，几百个点就能描述一帧场景。目标列表则是跟踪之后的结果，每个目标带唯一编号、平滑后的运动状态、历史轨迹。这一步进一步损失了目标的形状和尺寸信息，扩展目标被压成一个点，对卡车这种长条目标，目标列表很难表达它的真实占位。

我个人的判断是，做 AEB 这类安全功能，尽量用点云级甚至原始级融合，宁可多花算力；做 BSD 这类舒适性功能，目标级融合足够，成本更友好。

5.2 三级融合的取舍与坑

原始级融合最理想，理论上信息无损，但对时间同步要求极高。雷达和摄像头的采样时刻错开几毫秒，在高速场景下目标位置就差出几十厘米。我经历过的项目里，时间同步没做好导致的融合误检，比算法本身的缺陷还多。

点云级融合是目前的折中主流。雷达出点云，摄像头出检测框，在统一的车辆坐标系下做空间关联。难点在于坐标系转换的精度，雷达安装角度偏差半度，在 100 米外就是接近一米的横向误差，直接导致关联失败。这也是为什么标定环节那么重要，后面会专门讲。

目标级融合最省事，但也最脆弱。雷达的目标编号在遮挡、分裂、合并时会跳变，摄像头那边也有同样问题，两边编号对不上，融合逻辑就得靠位置和速度硬关联，容易出错。我的做法是要求在目标级融合里也保留目标的协方差矩阵，用马氏距离做关联，比欧氏距离稳得多。

5.3 典型功能对雷达的真实诉求

拿 AEB 来说，它的核心诉求不是精度，是漏检率。宁可虚警多一些，也不能在该刹车的时候没检测到。这就要求检测门限压低，CFAR 的虚警率设置得比常规更激进，同时靠跟踪器的时间一致性来抑制误报。这个思路和 ACC 完全相反，ACC 更怕虚警，一个不存在的目标会导致车辆无故减速。

BSD 的诉求是覆盖范围和稳定性。相邻车道要全覆盖，包括摩托车这种小目标，同时护栏、隔离带不能报成车辆。这里的难点是静止目标和准静止目标的区分，摩托车相对速度可能只有几公里每小时，和护栏的雷达回波特征很接近，必须借助横向位置和多帧连续性来判断。

RCTA 的诉求是侧向视野。车尾两侧的雷达要能看到垂直方向驶来的车辆，这个场景下雷达的安装角度往往是斜向的，波束覆盖要专门设计。我见过有用前向雷达参数直接套到 RCTA 上的方案，结果侧向完全看不见，因为波束宽度根本不够。

6. 量产路上的坑：干扰、标定、材料和环境

6.1 互干扰：从底噪抬升到虚假目标

路上跑的 77 GHz 雷达越来越多，同频干扰是绕不过去的问题。干扰的表现有两种，一种是底噪整体抬升，灵敏度下降，原本能检测到的远处目标突然消失；另一种是产生虚假目标，对方的 chirp 信号被你的接收机捕获，在距离速度图上形成一个本不存在的亮点。

第9章对这个问题只是提了一句，但它在量产阶段的权重很高。工程上的应对手段主要有几类。一是波形随机化，每个 chirp 的起始频率或者斜率做伪随机抖动，让对方信号在你这里无法形成相干积累，能量被打散到底噪里。二是极化隔离，收发采用不同极化方式，能抑制一部分干扰。三是检测后处理，在距离速度图上识别窄带的强干扰条带，做置零或者插值修复。

我在实测中遇到过一种情况：在一个空旷场地做测试，点云非常干净，换到车流密集的城市快速路，同一颗雷达的虚警率翻了三四倍。后来用频谱仪抓了一次，发现干扰主要来自对向车道的雷达，而且是间歇性的。这种间歇干扰最难处理，因为跟踪器会把间歇出现的虚假目标当成真实目标维持一段时间，形成鬼影轨迹。最后靠的是波形随机化加上跟踪器的航迹管理策略，对连续三帧都没有检测支撑的航迹快速删除。

6.2 标定：产线一次，在线一生

雷达标定分两块，一块是产线下线标定，一块是在线自校准。下线标定是用角反射器或者金属板在固定距离和角度上摆好，让雷达测出的角度和真实角度对齐，修正安装偏差。这一步的精度直接决定了后续所有角度测量的准确度。

在线自校准是车跑起来之后持续修正。常用的做法是找直道，利用路边静止目标在车辆坐标系里的位置关系，反推雷达的安装角度偏差。这个方法的假设是车辆直行且路边目标静止，实际路况下这个假设经常被打破，所以要做鲁棒估计，剔除异常点。

我踩过最深的坑是保险杠形变导致的角度漂移。新车下线时标定得好好的，跑了几万公里之后，保险杠因为轻微碰撞或者热胀冷缩发生形变，雷达的安装角度偏了零点几度，BSD 就开始频繁误报。后来在诊断里加了一个安装角度的长期监控，超过阈值就提示重新标定，问题才收住。这个经验说明标定不是一次性动作，而是全生命周期的事。

6.3 保险杠和雷达罩：最容易被忽视的天线一部分

这一条是我认为第9章最该被补充的内容。很多人把雷达当成一个独立模块，装上就完事，实际上保险杠就是天线系统的一部分。它的材料介电常数、厚度、涂层成分，都会影响电磁波的透射和反射。

常见的问题有两个。一是油漆含金属成分，某些珠光漆或者金属漆对毫米波的衰减很明显，装上去之后作用距离直接掉一半。二是保险杠和雷达罩之间存在空气层，形成类似法布里-珀罗谐振腔的结构，某些频点上透射率骤降，表现为特定距离段的目标检测不稳定。我在一个项目里遇到过 30 米附近的目标总是丢，换了三版算法都没解决，最后量了保险杠厚度，正好在某个频点形成驻波，改材料厚度才彻底解决。

提示：涉及雷达罩和保险杠的材料选型，一定要在微波暗室或者近场测试台上做透波率实测，不能只看供应商给的介电常数参数，厚度和层叠结构的影响往往比材料本身更大。

6.4 环境适应性：雨雾、护栏、隧道和井盖

毫米波对雨雾的穿透能力比激光强，但也不是无感。大雨时雨滴的后向散射会抬高噪底，等效于降低了信噪比，远处目标检测率下降。湿路面会形成镜面反射，雷达波打到路面再弹到目标上，形成多径，测出来的距离和角度都是错的。我见过雨天高速上雷达把前方车辆的虚像报在天上，就是路面多径造成的。

护栏是最经典的难题。连续的金属护栏在距离速度图上形成一条长拖尾，因为它由大量密集的散射点组成，每个点的距离略有差异。这条拖尾在 BSD 功能里会被误判成一辆超长的车辆。处理思路一般是从横向位置和速度一致性入手，护栏的横向位置固定且连续，速度接近本车速度，可以利用这两个特征做过滤。

隧道内壁的多次反射更麻烦，信号在两侧墙壁之间来回弹，形成多个虚假目标，而且这些虚假目标的位置还会随着车辆行驶而变化。井盖和桥梁接缝这类强反射体，会在静止目标检测里形成密集的点，如果跟踪器没有静止目标过滤逻辑，很容易报出一堆不存在的障碍物。

7. 常见问题速查与我的踩坑记录

7.1 问题排查速查表

下面这张表是我这几年调试雷达时攒下来的，按现象查原因，能省不少时间。

7.2 几个文档里不会写的小技巧

第一个技巧是关于 CFAR 的参考单元选择。教科书上给的典型值是 16 到 32 个参考单元，配 2 到 4 个保护单元。实际调试时，参考单元的数量要和目标在距离维上的展开宽度匹配。检测卡车这种长目标，参考单元太小会把目标自身的能量算进噪声估计里，导致检测门限被抬高，目标反而检不出来。我一般会按最大目标长度对应的距离单元数来设保护单元，宁可牺牲一点近距分辨能力。

第二个技巧是关于点云聚类。DBSCAN 的邻域半径和最小点数这两个参数，很多人直接套默认值。实际上这两个参数要跟着雷达的角度分辨率走。角度分辨率 3.6 度，在 50 米外横向间距大约 3 米，如果邻域半径设得比这个还小，同一辆车会被拆成多个簇。我通常按最大作用距离处的横向分辨率来设初始值，再根据实测调整。

第三个技巧是关于数据录制。调试阶段一定要录原始数据，不要只存点云。我吃过一次亏，现场问题复现不了，只有点云存下来，根本没法判断是检测环节还是跟踪环节出的问题。后来统一要求关键场景录距离多普勒原始矩阵，虽然数据量大，但排查效率提升明显。

7.3 读完这章之后我调整的几件事

第一件事是把参数配置从“算法导向”改成“功能导向”。以前调参是看哪个指标好看就调哪个，现在会先把功能的验收条件列出来，每个参数对应到具体条件上，不达标就回头改配置，达标就停手，不再无休止优化。

第二件事是在项目早期就把保险杠和雷达罩的透波测试排进计划。以前总是等到整车集成阶段才发现透波不行，那时候改材料周期很长。现在样件阶段就做近场透波扫描，把风险提前暴露。

第三件事是给每颗雷达建立安装角度的长期监控。这个改动看起来不起眼，但在售后阶段省了大量扯皮——有了数据，能明确区分是标定问题、碰撞形变还是器件老化。

第四件事是重新审视了速度维参数。以前习惯性把速度分辨率做到最细，现在会先算清楚功能需要多细，再把省下来的 chirp 预算分给角度维或者提高帧率。这个思路转变来自一次拥堵跟车场景的实测，速度分辨率过细带来的相位噪声放大，反而让跟踪器更难用。

第9章这种“概述”性质的章节，价值不在于给了多少新公式，而在于它把前面所有技术选择放回了真实的约束场里。我现在的习惯是每读一遍信号处理章节，就回来翻一遍这一章，看看哪些参数是被应用场景逼出来的，哪些是可以放松的。很多时候调不出来的问题，答案不在算法里，在保险杠的厚度里，在安装角度的那半度偏差里，在 chirp 周期和帧率的那笔账里。