去年年初我在整理仓库时翻出一块吃灰的毫米波雷达开发板，接上电源跑了一晚上的点云可视化，从数据流稳定输出的那一刻起，PLFM_RADAR 这个项目就算正式立项了。前后断断续续做了大半年，中间换过四套硬件方案，重写了三版数据管线，最大的收获不是那几份测试报告，而是把「雷达数据到底怎么变成业务可用的告警和轨迹」这条链路彻底跑通了。PLFM 是我给这套平台定的缩写，对应 Positioning、Localization、Feature Mapping 和 Motion Analysis 四个环节，RADAR 则是整套系统的感知前端。这篇就把整个项目从目标拆解到硬件选型、算法实现、多目标追踪踩坑、场景实测的完整过程整理出来，给正在做室内感知、跌倒监测、区域入侵告警这类项目的人一个可以直接参考的蓝本。无论你手里是 60GHz 还是 77GHz 的毫米波模块，只要关注的是「如何把雷达点云变成稳定业务数据」，这篇都适用。
1. PLFM_RADAR 解决什么问题：摄像头之外的感知选择
1.1 项目定位与缩写拆解
先交代清楚这个项目到底想干什么。PLFM_RADAR 的核心目标是做一个基于毫米波雷达的室内环境感知平台，不依赖摄像头就能完成人的存在检测、位置跟踪、动作状态识别和区域告警。之所以叫 PLFM_RADAR，是我按数据处理的层次拆出来的：
- P（Positioning）：通过雷达回波计算出目标相对雷达的方位角、距离和速度，得到连续的位置信息。
- L（Localization）：把单帧位置放到连续时间轴上，用跟踪算法形成稳定的运动轨迹。
- F（Feature Mapping）：在轨迹基础上提取目标的速度波动、停留时长、微动特征等，用于动作分类。
- M（Motion Analysis）：把特征映射到具体业务语义，比如「有人进入洗手间」「有人在仓库西北角长时间停留」「人员跌倒」。
这个分层思路决定了整个系统的骨架：底层是射频前端，中间是信号处理与目标检测，上层是业务逻辑。每一层只对上一层提供明确接口，这样后续替换硬件或者调整算法都不用把整套系统重写。
1.2 为什么不用摄像头和普通红外传感器
做室内人员感知，很多人的第一反应是装摄像头或者用被动红外（PIR）。我在项目初期也做过对比测试，结论是毫米波雷达在三个关键维度上有不可替代的优势，这也是 PLFM_RADAR 立项的根本原因。
第一是隐私问题。摄像头在办公区、卫生间、更衣室这类场景几乎无法部署，客户对隐私的敏感度远高于对功能的需求。雷达点云不生成任何可辨识的影像，从源头上规避了隐私争议。第二是环境适应性。我在一个半地下仓库里做过对比，完全无光条件下摄像头几乎失效，而雷达完全不受光照影响；同时被动红外对静止人体基本无法感知，因为 PIR 的探测原理就是捕捉温度变化，一个人坐在工位上不动超过两分钟，PIR 输出就会归零，而毫米波雷达可以通过微动特征（呼吸、心跳引起的胸廓起伏）检测到静止存在。第三是成本与部署效率。单个雷达模组的批量成本在几十到两百元区间，比一路高清晰度摄像头的整套方案便宜不少，而且不需要布设复杂的光照条件。
下面这个表是我在项目选型阶段做的对比记录：
| 感知方式 | 隐私友好 | 无光环境 | 静止人体检测 | 单设备成本 | 安装复杂度 |
|---|---|---|---|---|---|
| 摄像头 | 差 | 差（需补光） | 中 | 较高 | 需布线供电 |
| 被动红外 PIR | 好 | 好 | 差（需移动触发） | 低 | 低 |
| 毫米波雷达 | 好 | 好 | 好（微动检测） | 中 | 低 |
| 激光雷达 | 好 | 好 | 好 | 高 | 中 |
从这张表可以直观看出来，毫米波雷达在「隐私 + 静止检测 + 成本」这个组合上目前没有更好的替代方案。PLFM_RADAR 这一路做下来，我的判断是：在室内场景里，它取代不了摄像头（因为摄像头能看清细节），但摄像头也取代不了它。两者是互补关系，最终很多项目会采用雷达做感知、摄像头做取证复核的两级方案。
2. 系统总体架构：从射频回波到业务告警的四级数据管线
2.1 四级管线总览
整个 PLFM_RADAR 的软件架构分成四个层级，每一级都有清晰的输入输出和数据格式约定。从底层往上依次是：
- 射频前端层：负责雷达信号的发射、接收和原始 ADC 数据采集。这一层由雷达模组完成，我通过 SDK 拿到的是经过初步处理的点云数据或原始中频信号。
- 信号处理层：完成距离维 FFT、多普勒维 FFT、CFAR 恒虚警检测、角度估计和点云生成。这一层产出的是每一帧的雷达点云，每个点包含距离、角度、速度、信噪比四个属性。
- 目标感知层：把散乱的点云聚类成物理目标，再用多目标跟踪算法维护目标的连续轨迹和唯一 ID。这一层开始产生「人」级别的语义单元，而不再是「点」。
- 业务应用层：根据目标的状态（位置、速度、微动能量、停留时长）触发具体业务规则，比如区域入侵、跌倒识别、存在判断、人数统计，并把结果推送给上层系统。
每一层之间通过标准的数据帧格式衔接。我在设计时没有让上层直接读原始点云，而是强制走目标级数据接口。刚开始做的时候我也觉得多一层转换麻烦，但后面接第三方平台时发现这个决定非常关键——业务方根本不需要知道点云长什么样，他们只需要拿到「目标 ID、坐标、速度、置信度、事件类型」。
2.2 为什么核心算法要放在边缘端执行
PLFM_RADAR 在架构设计上有过一个关键取舍：把信号处理和目标感知放在设备本地，而不是把原始数据全部上传到服务器再处理。当时组里有人提出「既然算力不够，不如把点云数据回传中心端处理」，我坚持在边缘端完成全部目标级处理。原因有三个。
现实原因是带宽和延迟。以我用的这块 60GHz 雷达为例，点云数据帧率是 20fps，每帧大约 100 到 300 个点，如果每个点都以结构化数据回传，每秒产生的数据量在十几 KB 到几十 KB，看起来不大，但室内部署一铺就是几十个设备，汇聚到中心后再处理，端到端延迟会从几十毫秒拉到几百毫秒，响应式告警完全不可用。
架构原因是稳定性。边缘端处理意味着即使网络断开、中心服务宕机，设备本身依然能完成区域内的人员检测和告警，等网络恢复后再把事件补推上来。我在客户现场碰到过两次交换机故障，全靠边缘端的本地规则撑着没让安防出现空窗期。
从开发调试的角度，边缘端处理也让我能直接在设备上回放历史帧数据，快速定位算法问题。我只要在设备端加一个按帧记录点云和跟踪结果的功能，就能把一段出问题的场景完整回放出来逐帧分析，这个能力在整个项目排障阶段帮了大忙。
2.3 目标数据接口的约定
目标感知层对外输出的数据结构是我反复迭代过最多的部分。最初我输出的字段很随意，后来对接告警平台时发现对方要的字段和我的命名对不上，干脆把接口规范固定下来。单帧目标的数据长这样：
{ "frame_id": 10245, "timestamp": 1719567238.204, "targets": [ { "target_id": 3, "pos_x": 2.43, "pos_y": 1.18, "vel_x": 0.12, "vel_y": -0.03, "height": 0.0, "score": 0.93, "feature": { "micro_energy": 0.021, "speed_variance": 0.14, "stay_duration": 5.2 } } ] }几个关键字段的说明：
- pos_x、pos_y 是目标在雷达坐标系下的水平位置，单位是米，原点在雷达正下方投影点。
- vel_x、vel_y 是水平速度分量，用于判断运动方向和速度大小。
- score 是目标置信度，在 0 到 1 之间，低于阈值的跟踪结果不会输出。
- feature 里存的是业务层要用到的运动特征，micro_energy 表示微动能量，speed_variance 表示速度方差，stay_duration 表示目标连续停留的秒数。
这个接口成为整个系统稳定的关键。后续无论我在信号处理层怎么改算法、换模组，只要输出结构不变，上层业务就完全不用动。
3. 硬件选型与天线布局：毫米波方案为主的实测对比
3.1 雷达成像模组的选型对比
PLFM_RADAR 在硬件上前后评估过六款模组，覆盖了 60GHz 和 77GHz 两个主流频段。这两个频段的选择逻辑不复杂：60GHz 在室内短距离场景有约 4GHz 的可用带宽，距离分辨率可以做得很细，非常适合检测人的微动；77GHz 在车载和远距离上有优势，但在室内感知上优势不明显，而且天线设计和模块成本普遍更高。
我当时实际采购测试的有四款：
| 模组型号 | 频段 | 收发通道 | 最大测距 | 距离分辨率 | 接口方式 | 实测功耗 |
|---|---|---|---|---|---|---|
| TI IWR1443BOOST | 77GHz | 3发4收 | 约20m | 约4cm | UART/USB | 约2.5W |
| TI IWR6843ISK | 60GHz | 3发4收 | 约15m | 约3.7cm | UART/USB | 约2.8W |
| 英飞凌 BGT60TR13C | 60GHz | 1发3收 | 约8m | 约5cm | SPI/雷达MCU | 约1.2W |
| 国产某 60GHz 模组 | 60GHz | 2发4收 | 约12m | 约4cm | UART | 约1.8W |
从实测数据看，TI IWR6843 的综合表现最稳，点云质量、目标检测距离和 SDK 完善度都让人放心；BGT60TR13C 胜在功耗低、体积小，适合做电池供电的卫生间跌倒监测这类单点设备；国产模组性价比高，但 SDK 的完整性和文档质量差一些，对调试能力要求更高。
一个比较容易被忽略的点是：通道越多，角度分辨能力越强。我在对比时发现 1发3收的 BGT60TR13C 在 6 米以外对两个并排站立的人基本无法区分，而 3发4收的 IWR6843 在同样距离下能把水平间隔 0.8 米的两个人分开。所以如果你的场景里有并排人员、多人同时活动这类复杂情况，收发通道数至少要选 2发4收以上。
3.2 天线安装高度与倾角的实践数据
硬件选型之外，安装位置对感知效果的影响甚至比模组本身还大。我在测试中发现，同样一块 IWR6843，安装在 1.2 米高度平放和安装在 2.6 米高度向下倾斜 15 度，对人员轨迹的连续性和检测覆盖范围有巨大差异。
最终采用的推荐安装方式：雷达安装高度 2.4 到 3 米（天花板附近），向下倾斜 10 到 15 度。这样做的原因是使雷达波束的主瓣能够覆盖整个房间的水平区域，同时降低墙面反射带来的多径干扰。如果水平安装，波束会贴着天花板走，地面上 1 米以下的活动区域会形成探测盲区，人蹲下或者跌倒后目标很容易丢失。
提示：楼梯口、走廊这类狭长空间，建议把雷达安装在一端，波束沿走廊纵轴方向照射，实测有效覆盖距离比横向安装提升 30% 以上。
3.3 供电与射频校准的细节
雷达模组对供电稳定性比想象中敏感。我在第一版样机上直接用普通 USB 口供电，结果点云经常出现无规律的噪声点。后来用示波器量了电源纹波，发现某个频段的开关噪声正好落在中频信号带内，导致底噪抬升。换成低纹波的 3.3V LDO 供电之后，静止场景下的虚警点直接从每帧十几个降到一两个。
每块模组的出厂校准参数一定要加载，这是老生常谈但必须说。我之前写过一次跳过校准加载的测试脚本，结果测距偏差到了惊人的 0.8 米，排查了一下午，最后才发现是天线相位校准参数没写进去。奉劝各位拿到模组的第一步就是确认 SDK 里校准参数加载成功，用标准角反射器做一次距离标定，绝对不要跳过这一步。
4. 点云生成与目标检测算法的工程实现
4.1 从一维 FFT 到 Range-Doppler 图的参数设定
雷达信号处理的第一步是把中频信号按帧做距离维 FFT。毫米波雷达发射的是线性调频连续波，每个 chirp 的回波经过混频后得到一个中频信号，其频率与目标距离成正比。对一帧内的每一个 chirp 做 FFT，就能得到目标的距离分布，这一步在雷达术语里叫 Range FFT。
距离分辨率由发射带宽决定，我用的是 60GHz 模组，可用带宽约 4GHz，理论上距离分辨率等于光速除以两倍带宽，代入算下来约 3.75 厘米。这个分辨率意味着两个人只要径向距离差超过 3.75 厘米，在距离维上就能被区分。当然实际系统还会受到 FFT 点数、窗函数展宽等因素影响，我实测的有效分辨率约 5 厘米，但已经很够用。
做完 Range FFT 之后，对同一距离单元上的一串 chirp 再做一次 FFT，就得到速度维信息。这一步叫 Doppler FFT，输出的是一个二维矩阵，横轴是距离单元，纵轴是速度单元，每个单元的值反映该距离、该速度下回波的强度，这就是常说的 Range-Doppler 图。
关键参数设置我直接给一组经过实测的起点值，你们可以在这个基础上调：
# 雷达配置参数（以 IWR6843 为例，通过 CLI 下发） chirp_start_freq = 60e9 # 起始频率 chirp_slope = 40e12 # 调频斜率 Hz/s chirp_idle_time = 10e-6 # chirp 间隔 chirp_tx_time = 90e-6 # 单 chirp 持续时间 frame_period = 50e-3 # 帧周期 20fps num_chirps_per_frame = 128 # 每帧 chirp 数 num_adc_samples = 128 # 每个 chirp 采样点数帧率 20fps 是对算力和实时性的折中，再往上提高帧率会导致每帧积累点数下降，信噪比反而变差。
4.2 CFAR 门限为什么不能用固定值
Range-Doppler 图上每个单元都代表一个潜在目标，但直接设一个固定阈值来筛选目标是不行的。原因很简单：不同距离上的回波功率天然不同，近处墙面的反射信号强度可能是远处人身的几十倍，一个全局阈值要么漏掉远处的目标，要么被近处的杂波淹没。
工程上我用的是 CA-CFAR（单元平均恒虚警检测）。核心思路是对每个待检测单元，取周围一圈参考单元的平均值作为噪声功率估计，再乘以一个缩放系数得到自适应门限。这样门限会跟随局部背景噪声动态变化，在均匀噪声背景下保持恒定的虚警概率。
CFAR 参数中，参考窗口宽度和保护单元数量最关键。参考窗太窄，噪声估计不稳定；太宽则会引入目标的能量，导致门限被抬高。我实测后的推荐配置：
- 距离维参考单元：前后各 8 个
- 距离维保护单元：前后各 2 个
- 多普勒维参考单元：前后各 4 个
- 多普勒维保护单元：前后各 1 个
- 门限缩放因子：12 到 16 dB 之间
这个参数组合在我测试过的室内场景里虚警和漏检达到了比较理想的平衡。但要注意，CFAR 参数和场景强相关，空旷仓库与狭小办公室的推荐值差异很大，必须带着现场数据调。
4.3 DBSCAN 聚类与目标质心提取
CFAR 检测之后得到的是一堆离散点，这些点来自同一个人的手臂、躯干、腿部等不同反射部位。为了把同一目标的点归到一起，我用了 DBSCAN 密度聚类算法。选 DBSCAN 而不是 K-Means 的原因是人数未知，DBSCAN 不需要预先指定簇数，还能自动把离群的噪声点剔除。
我在 DBSCAN 上的两个核心参数：
- eps（邻域半径）：取 0.45 米。理由是人体的物理宽度在 0.4 到 0.8 米之间，同一人的反射点距离基本在这个范围内；间距小于 0.45 米的两个不同人的点云大概率会被合并成一个目标，但这个代价可以接受，因为这种场景本身极难区分。
- min_samples（最小点数）：取 3。低于 3 个点形成的簇，大概率是墙角和金属柱的反射残影，丢掉不心疼。
聚类完成后，对每个簇内点云的坐标取质心，作为目标的位置。质心计算时我给每个点加了信噪比权重，信噪比高的点说明反射强、更可信，权重更高。实测这个加权质心相比普通平均质心，位置抖动降低了约 20%。
4.4 卡尔曼滤波：目标位置平滑与状态估计
有了每帧的目标位置还不够，因为单帧检测有抖动和丢帧。PLFM_RADAR 使用卡尔曼滤波做目标跟踪，状态量是[x, y, vx, vy]，即目标的水平位置和速度。观测模型是一个简单的线性模型，观测值是 DBSCAN 聚类得到的质心位置。
卡尔曼滤波的两个核心参数需要手动调：
- 过程噪声协方差 Q：反映我们对目标运动模型不确定性的估计。人不是匀速直线运动的，随时会加速、减速、转弯，所以 Q 不能设得太小。我最终取的量级是位置噪声方差 0.05 m²/s⁴、速度噪声方差 0.5 m²/s⁴。
- 观测噪声协方差 R：反映雷达位置测量本身的随机误差。实测在 60GHz 模组下，位置观测噪声大约在 0.06 米左右，因此 R 取 0.06² 量级。
Q 和 R 的比值直接影响滤波输出是更相信预测还是更相信观测。我的经验是：在室内行人场景下，宁可让滤波器相信观测多一点，也不要让它过度平滑。过度平滑的后果是目标已经停下来了，轨迹还在缓慢往前飘，导致位置精确度大打折扣。我最后定下的 Q/R 比值大概在 2.5 到 3 左右，轨迹既平滑又能跟得上人的急停急转。
5. 多目标追踪与 ID 管理的踩坑排查链路
5.1 问题表象：静止目标消失与人员交错互换 ID
PLFM_RADAR 在第一版完整跑通之后，我拉了几位同事做了两轮场景测试，结果暴露了两个看起来不大但对业务来说是致命的 bug。
第一个 bug：人走进办公室后坐下不动，过了 20 秒左右，雷达输出里的 target_id 消失了，再过一会儿又重新出现一个新 ID。在安防语义里，这意味着「区域有人」这个状态出现了间断，如果刚好在间断期间有另一个目标靠近，系统会产生完全错误的判断。
第二个 bug：两个人在走廊相向而行、交错之后，系统给出的轨迹经常出现 ID 互换。也就是说，走出去之后标记为 A 的人，实际是之前从另一侧走进来的 B。如果用这套数据做人员考勤或者区域归属判断，结果完全是错的。
5.2 根因排查：把原始点云一帧帧回放
解决这类问题不能用猜的，我把有问题的场景用设备端的离线录制功能完整录了下来，然后逐帧比对点云和跟踪结果，最终定位到两个独立根因。
第一个根因出在 CFAR 的速度维处理上。毫米波雷达的目标速度是用多普勒效应测的，但完全静止目标的回波多普勒频移为零，这部分能量全部集中在 Range-Doppler 图上速度为零的那一行。而在实际环境里，静态墙体和桌椅的反射同样集中在零多普勒行，能量强度远高于人体，所以我的 CFAR 为了抑制静态杂波，在速度维上人为挖掉了一个零速带。这样一来，人一旦停下来，他的所有回波都被当成墙面杂波滤掉，信号处理层直接输出空帧，跟踪器因为没有新观测点自然就丢掉了 ID。
修复方案不是简单把零速带回填，那样会把墙面杂波全放进来。我做的是双通道检测：第一通道保留原有抑制零速带的逻辑，专门负责运动中的人；第二通道对零速带单独做更严格的 CFAR，门限抬高到 20dB，同时要求检测点必须满足微动特征（速度维两侧有非零能量的伴生信号）。人体静止时呼吸和心跳会引起胸廓微小起伏，反映在多普勒上就是零速带两侧会出现低频伴生分量，墙是完全没有这个特征的。用这个微动判据，就能在放行静止人体和压制墙杂波之间找到平衡。
第二个根因在数据关联的距离门限。我的跟踪器用了匈牙利算法做目标到轨迹的最优指派，但指派时计算代价矩阵用的是目标预测位置和观测位置之间的欧氏距离。走廊里两个人交错时，他们的空间距离本来就很小，如果我把关联门限放宽到 0.8 米以保证不丢点，就会导致交错瞬间 A 的观测点被指派给 B 的轨迹，B 的观测点被指派给 A 的轨迹，ID 就这么无声无息地交换了。
修复办法是给代价矩阵增加一维速度代价。交错瞬间两人的速度方向是完全相反的，即使空间距离很近，速度代价也会让正确的是配对被选中。我加了一项速度差的加权项，权重设为位置代价的 1.5 倍。改完之后跑了同一段录制的数据，50 次交错场景只出现了 1 次 ID 互换，而且是在两人几乎贴身并行超过两秒的情况下。
5.3 修复之后的回归验证
修复不是改完就算，我把回归测试固定成了项目流程。现在每次改动跟踪算法，都会跑一遍预先录制的 20 段场景数据，包括单人进出、两人交错、三人围坐交谈、静止坐姿检测、跌倒模拟等场景。用录制的数据做回归的好处是可以量化对比：同一帧数据，改代码前后输出的轨迹点数、ID 连续性、位置误差一目了然。
注意：多目标跟踪类项目一定要把「录数据回放」当作基础设施来做。没有离线回放能力，你在现场修 bug 就只能靠肉眼盯着实时点云猜测，效率低一个数量级。
5.4 同一根因链上的其他坑：天花板安装的多径反射
修复双通道检测时，我还顺带解决了一个藏得很深的假目标问题。在某个层高 4 米、顶部有金属通风管的测试点，我经常在空无一人的情况下看到一个目标在房间里反复横跳。逐帧分析点云发现，这组点云的距离和角度变化呈现很强的规律性，但真实人目标不可能做到每帧位置跳变超过 1 米还能保持信噪比几乎不变。
最后定位到是多径反射：雷达波束打到金属风管表面，反射到地面，再反射回雷达，形成了一条虚像路径。虽然物理路径比真实距离长得多，但信号链路是连续且稳定的，CFAR 完全把它当成真实目标输了进来。
处理多径假目标我总结了三个过滤器，按顺序叠加使用：一是驻留时间过滤，假目标往往在固定区域反复出现，如果目标连续出现时间超过设定阈值但位置基本不动，并且周围没有任何伴生点，判定为疑似虚像；二是微动特征过滤，真实静止人体有微动伴生信号，金属反射路径没有；三是轨迹交叉过滤，当虚像目标和真实目标同时出现时，两者速度往往成镜像关系，可以用这个规律把虚像目标剔除。
6. 场景实测：三组典型部署的精度数据与调优记录
6.1 办公室人员存在感知：静态目标检测是核心
第一个实测场景是在一间约 20 平米的办公室，面积 5.4 米乘 3.7 米，有一张大会议桌和六个工位。部署目标是判断每个工位区域是否有人在使用，数据输出给空调和照明联动系统。
这个场景最大的难点不是检测运动的人，而是检测坐着不动的人。我调了两周才把静止检测调到可用状态。最终配置是零速带微动检测门限开到 20dB，目标停留超过 5 秒后切换为静止跟踪模式。实测一周，人员存在检测准确率 98.2%，误报率为每 8 小时 0.3 次，响应时间小于 2 秒。误报主要出现在窗户开了一条缝、窗帘被风吹动的时候——布料整体摆动产生的多普勒信号和人体移动特征非常像，后来在跟踪层加了一个「目标面积」约束，布料产生的点云簇面积普遍小于 0.15 平米，而成年人躯干点云簇面积普遍在 0.2 平米以上，误报明显下降。
6.2 卫生间跌倒监测：速度特征区分跌倒与快速下蹲
第二个场景是养老设施里的卫生间，面积约 2.5 米乘 2 米，部署目的是跌倒监测。这个场景里雷达安装在 2.6 米高度，正对淋浴区，覆盖整个卫生间。
跌倒检测算法用的是目标高度和速度特征联合判断。人在站立淋浴时，点云质心高度通常在 0.8 到 1.3 米之间；跌倒瞬间，质心高度在 0.5 秒内下降超过 0.5 米，同时速度特征会有一个先快后慢的典型曲线。我把这两条判据组合起来做了一个简单的有限状态机：
- 目标在站立状态持续超过 10 秒；
- 质心高度在连续 3 帧内下降超过 0.4 米；
- 下降结束后目标保持静止或只有微动，持续超过 3 秒。
三条同时满足才触发跌倒告警。这个设计有一个关键的防误报考量：老人快速坐在马桶上时，质心高度也会快速下降，但下降幅度通常不到 0.4 米，而且坐定后微动特征依然存在（因为身体还在活动），不满足「完全静止」判据。我拿 120 组模拟实验做测试，跌倒检出 113 次，灵敏度 94%；快速坐下误触发了 1 次，误报率大概每周 1 次，还在可接受范围内。
6.3 仓库区域入侵告警：多雷达协同与盲区处理
第三个场景是一个 25 米乘 18 米的半地下仓库，区域内有货架遮挡，单台雷达完全覆盖不了。我部署了 4 台 IWR6843，每台负责一片区域，通过局域网把目标数据汇聚到一台边缘计算网关，由网关做区域级规则判断。
多雷达协同的难点不在数据融合，而在盲区。货架遮挡会导致每台雷达都有固定盲区，目标从一台雷达覆盖区走进另一台雷达覆盖区时，如果中间跨越了盲区，就会出现轨迹断裂。我最初的方案是各雷达独立上报目标，网关只做规则判断，结果实测目标跨区时经常出现 2 到 3 秒的跟踪中断。
优化方案是让相邻两台雷达的覆盖区域重叠约 1 米。目标进入重叠区时，两台雷达都会上报目标，网关用位置和速度做最近邻匹配，匹配成功后将两个目标 ID 做绑定，轨迹无缝衔接。调整之后目标跨区跟踪中断时间从平均 2.1 秒降到 0.6 秒，位置误差平均 0.23 米，区域入侵告警延迟约 1.2 秒，满足安防联动要求。
三组场景的最终数据汇总如下：
| 场景 | 部署设备 | 检测准确率 | 误报情况 | 告警响应 |
|---|---|---|---|---|
| 办公室存在感知 | 单台 60GHz | 98.2% | 0.3 次/8小时 | 小于 2 秒 |
| 卫生间跌倒监测 | 单台 60GHz | 94.0% | 约 1 次/周 | 小于 3 秒 |
| 仓库区域入侵 | 4 台 60GHz | 96.5% | 0.5 次/天 | 约 1.2 秒 |
从三组实测可以明显看出，场景差异对算法参数的影响远大于硬件差异。办公桌、金属货架、淋浴水汽这些环境因素造成的多径和杂波，才是雷达感知项目真正需要花大力气解决的问题。PLFM_RADAR 做到最后，真正有用的资产反而不是那几块开发板，而是我手上这套录制的各场景雷达数据回放库和那几条反复打磨过的参数配置。这套数据资产才是后续所有算法迭代的地基。
