低功耗IoT人体检测:PIR+毫米波雷达联合方案解析

发布时间:2026/8/28 11:38:42
低功耗IoT人体检测:PIR+毫米波雷达联合方案解析 最近圈子里有个挺典型的联合项目几家不同赛道的公司凑在一起要做一款电池供电的低功耗IoT人体检测设备。项目标题是“Firms Team for Low Power IoT Person Detection”听起来不算多复杂但真正跑起来你会发现这个题目几乎把嵌入式低功耗、传感器融合、边缘AI、无线传输这几块硬骨头全踩了一遍。这篇文章想把这类项目背后的核心矛盾、技术路线、协作方式和容易踩的坑拆开聊聊。不管你是做硬件选型、嵌入式软件、算法移植还是负责产品定义只要接触过“电池供电 人体感知”这类需求这篇文章应该能帮你少走不少弯路。我按自己的实际经验把从原理到选型再到部署的完整链路梳理一遍。1. 为什么“人体检测”在IoT里是个功耗难题1.1 电池容量与寿命的算账逻辑先算一笔很基础的账。一颗CR2032纽扣电池标称容量大概220mAh如果系统平均电流做到50uA理论寿命大概是220mAh / 0.05mA 4400小时约等于183天。但这是理想值实际还要算上电池自放电、低温容量衰减、天线匹配损耗、偶尔的无线重传真实可用时间经常打个六折甚至更低。所以“低功耗”三个字本质上不是省一个元器件的电而是把整机的平均电流压到几十微安以内。这类项目里有一个经常被忽略的公式锂电池或碱性电池的“脉冲放电能力”和“平均放电能力”是两回事。人体检测设备平时在睡觉一旦检测到事件会瞬间拉高电流去跑雷达、启动无线这个脉冲峰值可能冲到100mA以上。选电池的时候如果只看平均电流现场就会出现“电量显示正常但一触发就掉压重启”的诡异故障。这一点后面我还会专门展开。1.2 传统RGB视觉方案为什么顶不住很多人一听到“Person Detection”第一反应就是上摄像头做视觉识别。确实深度学习目标检测在安防摄像头里已经非常成熟YOLO系列、SSD、MobileNet这些模型随便一个都能框出人形。但问题在于一颗普通RGB摄像头加上ISP和NPU功耗通常在几百毫瓦级别。哪怕用最新的低功耗视觉芯片把分辨率降到QVGA、帧率压到1fps整机功耗也很难低于30mW。对比一下一颗PIR传感器被动红外的功耗是微安级别一颗毫米波雷达的功耗是几十毫瓦级别两者相差2到3个数量级。对电池供电的IoT设备来说这中间的差距就是“一年换一次电池”和“一个月换三次电池”的区别。不是说视觉方案不能做而是它不应该作为“全天候持续工作”的传感器更适合放在检测链路的最后一环等前置传感器已经确认“大概率有人”之后再唤醒抓拍这样才能把平均功耗压下来。1.3 先分清“存在感知”和“人员检测”这里要澄清一个概念。标题里的Person Detection在很多低功耗IoT场景里并不是“识别出这个人是谁”而是“判断这个区域有没有人”。有朋友会说“这不就是人体存在传感器吗”对但要区分两种能力运动检测人只要动就能感知PIR就能干算力需求为零。静态存在检测人坐在椅子上不动甚至睡着了只有呼吸带来的微小起伏依然要能判断“有人”。这就不是普通PIR能解决的需要毫米波雷达或者高灵敏度视觉。这两种需求对应完全不同的硬件架构。如果产品定义只要求“有人走过就上报”一颗PIR加上一颗低功耗MCU就够了。如果要求“检测到人静坐超过10分钟”那就必须有雷达介入。很多项目失败就是产品经理和硬件工程师在这一点上没有对齐做出来的设备要么功耗超标要么需求满足不了。2. 主流检测技术路线的横向对比功耗、精度、成本三方博弈2.1 PIR被动红外uA级功耗但只能“看个大概”PIR传感器被动红外靠检测人体发出的红外辐射变化来触发信号。它的好处是功耗极低、价格便宜、结构简单一个传感器加一个菲涅尔透镜整套物料成本能控制在几块钱以内。待机电流大概1-10uA触发时也不过几十微安几乎是所有低功耗检测设备的第一道闸门。但PIR的短板也很明显它对“静止的人”无效。原理决定了它感应的不是红外线本身而是红外线的变化。人坐在工位上不动PIR输出就是平的没有任何中断系统以为房间空了。我见过一个办公座位占用检测项目客户反馈“我明明坐在座位上系统却说没人”排查了几天最后发现是PIR的固有特性不是产品坏了。这个问题的工程解法有很多一是把PIR当成唤醒源而不是最终判决PIR触发后启动雷达确认二是设计“遮挡检测”逻辑当PIR输出长时间没有变化时主动发一个低功耗雷达探测三是用两组PIR配合光学透镜分区增加触发覆盖面。但无论如何PIR只能是整套方案的起点不可能是终点。2.2 毫米波雷达最平衡的候选者但门槛在算法毫米波雷达是最近几年低功耗人体检测领域最热的方向尤其是60GHz频段。它的核心原理是发射FMCW或FSK调制的毫米波信号通过反射波的多普勒频移和距离门分析判断目标是否存在、距离多少、微动特征如何。60GHz频段的波长大约5mm足够检测到人体呼吸时胸廓几毫米的起伏。功耗层面一颗集成了雷达收发机的SoC工作电流大约在30mA到100mA量级视输出功率和采样率而定相比视觉方案低了一个数量级但比PIR高了两三个数量级。所以雷达不适合一直开着正确用法是“按需唤醒”PIR先检测到粗粒度事件MCU再给雷达上电雷达用几百毫秒到几秒时间做一次确认然后立即断电。算法门槛是雷达方案最大的坑。很多人以为买了一颗雷达模组串口直接输出“有人/无人”接上就能用。实际上一颗雷达模组的原始数据需要经过FFT、CFAR检测、聚类、跟踪、微动特征提取这一整套流程才能输出稳定的存在判断。如果只用模组厂家提供的默认阈值在现场十有八九会出现“空调一吹就误报”“隔着玻璃人走过去没反应”之类的问题。后面我会专门讲怎么调试这些参数。2.3 视觉、ToF、超声波等补充路线除了PIR和毫米波雷达还有一些在特定场景下值得关注的技术路线视觉方案适合需要“人员数量统计”“人脸识别”或“行为分析”的场景。功耗高、成本高但信息量最大。低功耗IoT里通常作为末端确认手段比如雷达确认有人后摄像头抓拍一张图通过低功耗AI芯片做一次人形分类再决定要不要上报。ToF飞行时间适合近距离检测比如智能门锁的人体接近唤醒。ToF传感器的功耗在几十毫瓦量级距离通常不超过5米室外强光下性能会明显变差。超声波成本低、功耗低但容易被窗帘、衣物等软质材料吸收检测距离短且多个设备之间有干扰风险。Wi-Fi/Sub-GHz信号感知利用现有无线模块检测环境中人体移动造成的RSSI信号强度变化功耗可以非常低但精度和稳定性受环境影响大更适合做“区域占用粗判”而不是“精确存在检测”。2.4 一张表看懂各方案的综合素质我做一个比较实用的对比表方便大家在做方案选型时快速排除选项。方案典型待机功耗静态人体检测误报率物料成本参考算法复杂度适用场景PIR 菲涅尔透镜1-10uA不支持中高热源/气流易触发低几元极低低成本人体运动感知、系统唤醒源毫米波雷达60GHz30-100mA工作态支持呼吸级微动低需调参中高数十到上百元高静态存在检测、房间占用、老人看护低功耗视觉QVGA1fps30-300mW支持低模型决定中高高人员计数、身份识别、行为分析ToF十几到几十mW支持中强光/远距失效中中近距离唤醒、手势识别超声波数十mW支持近距离中低低短距离防遮挡检测这里有一个特别重要的提醒单独看任何一个方案都是不全面实际产品几乎都是两种或三种方案叠加使用。最典型的架构是“PIR粗检 雷达确认”既控制了平均功耗又补上了静态检测能力。后面我展开讲这套配合逻辑。3. 联合项目的协作架构传感器、芯片与算法的分工3.1 为什么“单打独斗”做不好这类产品标题里“Firms Team”这个词很关键。一个完整的低功耗人体检测设备需要传感器技术、低功耗芯片设计、边缘AI算法、无线通信、结构散热甚至云平台接入。没有任何一家公司能在这所有环节都是专家成熟的产品通常是多家企业分工协作传感器芯片原厂负责把雷达前端或PIR传感器的功耗做低、封装做小提供参考驱动。MCU/SoC厂商提供低功耗处理器、睡眠唤醒机制、安全启动和FOTA能力通常也给定点运算库。算法团队负责把person detection模型裁剪、量化、部署到MCU或轻量级NPU上解决模型精度和存储空间的矛盾。模组厂把传感器、MCU、天线、电源管理集成到一块小板上做一致性校准输出标准化接口。云平台负责设备接入、数据下发、告警推送让终端用户可以远程管理。整机品牌定义产品需求、做系统级集成测试、过认证、量产管控。这种协作模式最考验的是“接口定义”。我在实际项目里遇到最多的冲突是算法团队说“我要每帧原始雷达数据”而硬件团队说“MCU的RAM只能装两帧”两边没对齐就导致后期推倒重来。避免这个问题的办法是在项目启动时就把数据流画清楚传感器输出什么格式、算法在哪个阶段跑、需要多少内存、每阶段允许多少延迟这些都要以书面协议定下来。3.2 事件驱动三阶段流水线PIR唤醒、雷达确认、无线发送低功耗人体检测设备的核心设计思路是把“检测”这个动作拆成多级流水线每一级都比上一级更精确但更耗电。最实用的是三阶段模型深度睡眠阶段MCU处于STOP或Standby模式只留外部中断引脚监听PIR整机电流控制在5-20uA。PIR一旦检测到红外变化立刻通过GPIO中断唤醒MCU。雷达确认阶段MCU给雷达模组上电加载配置跑一次或多次检测连续几帧输出“有人”才判定为有效事件。这个阶段根据算法复杂度需要0.5秒到2秒。判定完成后立即把雷达断电。无线发送阶段MCU把事件结果打包通过BLE、LoRa、Wi-Fi或NB-IoT发送到网关或云端然后再次进入深度睡眠。这套流水线最关键的地方是“每一阶段都能独立失败并回退”。比如雷达确认发现是误报就不需要启动无线电流直接降回睡眠态。又比如无线发送失败需要按退避算法重发但重发次数要有限制避免在信号差的时候把电池耗尽。一个实际功耗估算的示例假设待机电流10uA每天有效触发30次每次雷达工作2秒、工作电流50mA那么雷达带来的日均消耗约为30×2×50mAs 3000mAs 0.83mAh折算成平均电流约34.7uA。整机平均电流大约45uA。如果用两节AA碱性电池2Ah按70%可用容量算理论寿命约为1400mAh / 0.045mA ≈ 31111小时超过3.5年。这个账能让产品经理和客户都满意。3.3 MCU侧的低功耗设计要点在MCU选型和软件设计上有几点经验值得专门提一下深度睡眠不等于一切很多人觉得进入睡眠模式就万事大吉实际上漏电流、外部上拉电阻、LDO的静态功耗、串口转接芯片的待机功耗每一项都可能比MCU本身的sleep current还高。画原理图时就要排查每颗芯片的工作/关断状态。时钟选择低功耗设备建议外部接一颗32.768kHz的低速晶振用于RTC和协议栈低频时钟。低频时钟功耗低而且能让BLE等协议栈在sleep时保持时间基准。任务调度要“集中处理”不要在中断里做耗时的运算中断里只置标志位主循环在检测到标志后集中处理一次。否则MCU会因为频繁中断退出睡眠再进入睡眠反而增加平均功耗。协议栈也要省电BLE广播间隔、连接事件间隔拉长LoRa的发送功率和扩频因子调到能满足通信的最低档位这些软件参数对功耗的影响往往比硬件选型还大。4. 实测与踩坑从原型到量产容易忽略的细节4.1 实测功耗数据的典型套路很多开发者在实验室里测功耗习惯用万用表串联测平均电流这样测出来的数据在“稳态”下还行但无法反映设备真实工作的脉冲特征。推荐用电子负载或高精度电流探头的示波器抓一条从深度睡眠到触发唤醒再到无线发送的完整电流波形观察峰值电流、脉冲宽度和恢复时间。我见过一个让人印象深刻的例子某款设备明明标称待机电流8uA实测平均电流却高达200uA。用示波器抓波形才发现MCU每隔几百毫秒就会醒来一次一次醒几十毫秒跑一段协议栈任务然后再次睡去。虽然每次工作时间短但次数太频繁平均功耗被推高了几十倍。这种“频繁浅睡”的问题比“持续工作”更有迷惑性因为它不会让温度明显升高却悄无声息地吃电。4.2 误报与漏检的工程权衡调参就是一场心理战毫米波雷达的“灵敏度”是一个让所有开发团队头疼的参数。阈值设得太低空调出风、窗帘飘动、甚至电磁干扰都能触发误报阈值设得太高人坐在沙发上不动就漏报。我在一个老人看护项目里踩过很深的坑。客户要求“老人跌倒了要报警”但跌倒检测的触发逻辑不能只看雷达一帧数据否则老人弯个腰捡东西就会被误报为跌倒。最终的做法是雷达输出多帧连续数据算法综合“距离变化率、持续时间、姿态角变化”三个维度来打分连续3帧得分超过阈值才触发报警。误报率从之前的每天十几次降到每周不到一次。这里有一个普适经验任何检测电路都不要用“单次触发”就下结论至少要连续两个独立样本确认且两个样本之间要有时间间隔。PIR也是这个道理很多误报来自上电瞬间或者温度骤变加一个“200ms稳定窗口”就能过滤掉大部分。4.3 环境、结构与电池的隐性坑原型机在研发台上一切正常一到客户现场就各种灵异事件多半是下面这几个环节出了问题PIR透镜和外壳的距离如果菲涅尔透镜贴外壳太近外壳吸收日晒升温后辐射热量给传感器会造成“晚上没人却不断误报”的闹鬼现象。设计方案时要在透镜和外壳之间留足空气隔热层。雷达天线的净空区毫米波雷达对天线前方的金属物体极度敏感。如果结构设计里雷达上方有金属支撑柱或者螺丝波束会被扭曲出现检测盲区。调试阶段最好对每一台样机做一次“多角度走动测试”不要只看正前方效果。电池低温特性锂亚电池能量密度高但脉冲放电能力差低温下甚至无法支撑雷达启动时的瞬态电流。如果产品要出口到寒冷地区建议在电池选型阶段直接把“低温脉冲电流”列进硬性指标。FOTA升级的功耗陷阱无线固件升级需要在短时间内连续接收数据平均功耗会是平时的几十倍。如果设备是几个月才换一次电池的场景要设计“升级行为提示”甚至“升级时外接电源”的逻辑。5. 我的选型建议与一次类似项目的复盘5.1 如果现在让我从头做一个低功耗人体检测项目我会怎么选假设需求是“电池供电、能检测静态人体存在、事件上报到云端要求在室内等效距离5米内可靠工作”我的优先级排序是传感器方案PIR 60GHz毫米波雷达的组合PIR负责唤醒雷达负责确认。理由很简单这是当前功耗和检测能力平衡最好的方案。如果预算紧张且需求只要求运动检测可以砍掉雷达纯PIR方案加一颗低功耗MCU搞定。MCU选型优先考虑集成低功耗射频的SoC比如nRF52系列、STM32U5系列、Silicon Labs的EFR32系列。理由是把无线通信和主控集成到一颗芯片上省去外部射频匹配的功耗损耗。RAM和Flash要留足因为雷达算法可能要跑FFT和浮点运算如果MCU不带硬件浮点算法团队会用定点化方案两者对算力的要求差异很大。算法部署形式优先用传感器原厂提供的“开箱即用”模组哪怕贵一点也要先把数据链路跑通。等整机逻辑稳定了再考虑把算法往前移甚至移到SoC内部做融合。不要一上来就追求深度学习模型低功耗场景下多数“检测”问题用传统雷达信号处理就能解决深度模型是最后一步锦上添花的工具。5.2 一张可以抄作业的设计检查清单每次做这类产品我都会在评审会上留一页检查清单包括但不限于平均电流是否按真实场景算过有没有把无线重传、雷达确认、FOTA都算进去睡眠模式下每一颗芯片的漏电流是否逐个确认过有没有不需要供电的外设还挂着LDO雷达天线区域有没有金属结构遮挡结构图纸上是否画了净空区PIR透镜和外壳之间是否留有隔热距离菲涅尔透镜的安装方向是否按传感器厂家的推荐来了算法在MCU上的内存峰值是否算过有没有给系统任务留出至少20%的余量无线发送失败后的重试策略是什么能不能保证在极端信号环境下不会“忙到没时间睡觉”产品在低温环境下的启动电流是否验证过电池型号的脉冲放电能力满足瞬态需求吗量产一致性怎么做每台设备的雷达天线参数是否有出厂校准环节说实话这几个问题里只要有一个没答上来产品到了现场大概率会出事。技术方案能做到90分剩下10分全靠这些“不起眼的检查项”兜底。5.3 一点项目复盘我参与过的一个项目最初硬件团队为了赶进度用了供应商提供的默认雷达配置没有针对现场环境重新调参。结果在客户办公室测试时中央空调一启动就疯狂报警上线当天就被客户投诉。后来我们花了两周时间把雷达的检测阈值、CFAR参考窗口、时间积累帧数全部重新标定并在设备端加入“PIR先唤醒、雷达再确认”的联动逻辑误报率才降到可接受范围。这个教训让我彻底明白低功耗人体检测产品的技术难点根本不在于传感器灵敏度而在于“误报与漏报的平衡”和“功耗与功能的平衡”这两对矛盾从产品定义阶段就要想清楚。如果以后再开类似的坑我一定会把第一阶段的预算花在“带着雷达模组到真实场景里连续跑一周”上而不是花在办公室里的Demo演示上。真实环境的数据用它来训练阈值和模型参数比任何实验室仿真都有价值。