去年年初我在整理仓库时翻出一块吃灰的毫米波雷达开发板接上电源跑了一晚上的点云可视化从数据流稳定输出的那一刻起PLFM_RADAR 这个项目就算正式立项了。前后断断续续做了大半年中间换过四套硬件方案重写了三版数据管线最大的收获不是那几份测试报告而是把「雷达数据到底怎么变成业务可用的告警和轨迹」这条链路彻底跑通了。PLFM 是我给这套平台定的缩写对应 Positioning、Localization、Feature Mapping 和 Motion Analysis 四个环节RADAR 则是整套系统的感知前端。这篇就把整个项目从目标拆解到硬件选型、算法实现、多目标追踪踩坑、场景实测的完整过程整理出来给正在做室内感知、跌倒监测、区域入侵告警这类项目的人一个可以直接参考的蓝本。无论你手里是 60GHz 还是 77GHz 的毫米波模块只要关注的是「如何把雷达点云变成稳定业务数据」这篇都适用。1. PLFM_RADAR 解决什么问题摄像头之外的感知选择1.1 项目定位与缩写拆解先交代清楚这个项目到底想干什么。PLFM_RADAR 的核心目标是做一个基于毫米波雷达的室内环境感知平台不依赖摄像头就能完成人的存在检测、位置跟踪、动作状态识别和区域告警。之所以叫 PLFM_RADAR是我按数据处理的层次拆出来的PPositioning通过雷达回波计算出目标相对雷达的方位角、距离和速度得到连续的位置信息。LLocalization把单帧位置放到连续时间轴上用跟踪算法形成稳定的运动轨迹。FFeature Mapping在轨迹基础上提取目标的速度波动、停留时长、微动特征等用于动作分类。MMotion 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 IWR1443BOOST77GHz3发4收约20m约4cmUART/USB约2.5WTI IWR6843ISK60GHz3发4收约15m约3.7cmUART/USB约2.8W英飞凌 BGT60TR13C60GHz1发3收约8m约5cmSPI/雷达MCU约1.2W国产某 60GHz 模组60GHz2发4收约12m约4cmUART约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 问题表象静止目标消失与人员交错互换 IDPLFM_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 秒满足安防联动要求。三组场景的最终数据汇总如下场景部署设备检测准确率误报情况告警响应办公室存在感知单台 60GHz98.2%0.3 次/8小时小于 2 秒卫生间跌倒监测单台 60GHz94.0%约 1 次/周小于 3 秒仓库区域入侵4 台 60GHz96.5%0.5 次/天约 1.2 秒从三组实测可以明显看出场景差异对算法参数的影响远大于硬件差异。办公桌、金属货架、淋浴水汽这些环境因素造成的多径和杂波才是雷达感知项目真正需要花大力气解决的问题。PLFM_RADAR 做到最后真正有用的资产反而不是那几块开发板而是我手上这套录制的各场景雷达数据回放库和那几条反复打磨过的参数配置。这套数据资产才是后续所有算法迭代的地基。
去年年初我在整理仓库时翻出一块吃灰的毫米波雷达开发板接上电源跑了一晚上的点云可视化从数据流稳定输出的那一刻起PLFM_RADAR 这个项目就算正式立项了。前后断断续续做了大半年中间换过四套硬件方案重写了三版数据管线最大的收获不是那几份测试报告而是把「雷达数据到底怎么变成业务可用的告警和轨迹」这条链路彻底跑通了。PLFM 是我给这套平台定的缩写对应 Positioning、Localization、Feature Mapping 和 Motion Analysis 四个环节RADAR 则是整套系统的感知前端。这篇就把整个项目从目标拆解到硬件选型、算法实现、多目标追踪踩坑、场景实测的完整过程整理出来给正在做室内感知、跌倒监测、区域入侵告警这类项目的人一个可以直接参考的蓝本。无论你手里是 60GHz 还是 77GHz 的毫米波模块只要关注的是「如何把雷达点云变成稳定业务数据」这篇都适用。1. PLFM_RADAR 解决什么问题摄像头之外的感知选择1.1 项目定位与缩写拆解先交代清楚这个项目到底想干什么。PLFM_RADAR 的核心目标是做一个基于毫米波雷达的室内环境感知平台不依赖摄像头就能完成人的存在检测、位置跟踪、动作状态识别和区域告警。之所以叫 PLFM_RADAR是我按数据处理的层次拆出来的PPositioning通过雷达回波计算出目标相对雷达的方位角、距离和速度得到连续的位置信息。LLocalization把单帧位置放到连续时间轴上用跟踪算法形成稳定的运动轨迹。FFeature Mapping在轨迹基础上提取目标的速度波动、停留时长、微动特征等用于动作分类。MMotion 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 IWR1443BOOST77GHz3发4收约20m约4cmUART/USB约2.5WTI IWR6843ISK60GHz3发4收约15m约3.7cmUART/USB约2.8W英飞凌 BGT60TR13C60GHz1发3收约8m约5cmSPI/雷达MCU约1.2W国产某 60GHz 模组60GHz2发4收约12m约4cmUART约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 问题表象静止目标消失与人员交错互换 IDPLFM_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 秒满足安防联动要求。三组场景的最终数据汇总如下场景部署设备检测准确率误报情况告警响应办公室存在感知单台 60GHz98.2%0.3 次/8小时小于 2 秒卫生间跌倒监测单台 60GHz94.0%约 1 次/周小于 3 秒仓库区域入侵4 台 60GHz96.5%0.5 次/天约 1.2 秒从三组实测可以明显看出场景差异对算法参数的影响远大于硬件差异。办公桌、金属货架、淋浴水汽这些环境因素造成的多径和杂波才是雷达感知项目真正需要花大力气解决的问题。PLFM_RADAR 做到最后真正有用的资产反而不是那几块开发板而是我手上这套录制的各场景雷达数据回放库和那几条反复打磨过的参数配置。这套数据资产才是后续所有算法迭代的地基。
