早几年我在社区里分享过一个用普通摄像头做独居老人看护的小项目当时还是拿 MediaPipe 加一堆 if-else 硬凑的效果只能说勉强能用。今年重新把这事捡起来改用 YOLOv8-Pose 做姿态估计配合边缘 AI 模块做端侧推理整套跌倒检测系统的实时性、准确率和功耗表现都上了一个台阶。这篇文章就把整个系统的选型思路、跌倒判定算法、实时推理架构、低功耗端侧部署以及实测调参经验完整写出来给正在做类似项目的朋友一个可以直接抄作业的参考。这个系统解决的问题很明确独居老人在卫生间、客厅、卧室发生跌倒后如果长时间无人发现后果往往非常严重。传统的红外传感器、毫米波雷达存在误报率高、无法区分“人倒了”和“人蹲下捡东西”的问题而基于视觉的 AI 方案可以直接从人体骨骼关键点判断姿态误报率低得多。整个项目从零实现涉及 YOLOv8-Pose 模型选型、跌倒判定逻辑设计、视频流实时处理、端侧低功耗部署四大核心模块适合做智慧养老、家庭看护、医院病房监控的开发者参考。1. 先搞清楚跌倒检测为什么不用目标检测偏要用姿态估计刚开始接触这个需求的人第一反应往往是“用 YOLOv8 检测人检测到人不就行了吗”这个思路有个致命问题目标检测只能输出一个矩形框告诉你“这里有人”但完全没有表达“这个人当前是什么姿势”。而跌倒检测的核心恰恰在于判断姿态的剧烈变化——人从站立变成倒地这中间是身体姿态的转变不是简单的“人出现/人消失”能描述的。1.1 目标检测只能回答“人在这”回答不了“人怎么了”我拿 YOLOv8 目标检测做过一次对照实验把一个人在摄像头前做蹲下、弯腰、摔倒、躺下四个动作目标检测的输出几乎没有任何区分度——四类场景下都是同一个检测框只是宽高比略有变化。如果单纯用检测框的宽高比变化来判断跌倒会引入大量误报因为蹲下和摔倒从检测框的形变来看非常接近。更麻烦的是目标检测的输出是“物体级别”的缺乏身体部位的对应关系。它不知道哪是头、哪是腿、躯干朝向什么方向。而跌倒判定的关键依据恰恰是这些部位的空间关系躯干是否从垂直变成了接近水平、人的中心点是否在极短时间内快速下坠、身体在地面上的姿态是否持续异常。这些信息只有姿态估计模型才给得出来。1.2 姿态估计提供的 17 个关键点恰好是跌倒判定的“量角器”YOLOv8-Pose 基于 COCO 关键点定义一个人体输出 17 个关键点包括鼻子、双眼、双耳、双肩、双肘、双腕、双髋、双膝、双踝。这 17 个点的空间坐标就是一套完整的“人体姿态量角器”。这是 COCO 17 关键点的索引对应关系我建议你把这份表背下来因为后面的判定算法全靠它索引关键点索引关键点0鼻子9右手腕1左眼10右手腕右手2右眼11左髋3左耳12右髋4右耳13左膝5左肩14右膝6右肩15左踝7左手肘16右踝8右手肘有了这些点我们能算出很多对跌倒判定有用的几何特征。比如取点 5 和点 6 的平均值得到肩部中心取点 11 和点 12 的平均值得到髋部中心连接肩部中心和髋部中心就能得到躯干向量这个向量与垂直方向的夹角就是躯干倾斜角。人在站立时这个角度接近 0 度跌倒或躺下时可能瞬间拉到 60 到 90 度。再比如髋部中心点的 Y 坐标在图像坐标系中的变化速度能直接反映人体是否在“快速下坠”。1.3 对比 OpenPose、MediaPipe为什么最终选 YOLOv8-Pose做姿态估计的成熟方案并不少我前期对比过 OpenPose、MediaPipe Pose、MoveNet 和 YOLOv8-Pose 四套各有各的问题。OpenPose 效果最稳但模型重量和专业度换来的是推理速度极慢通常每帧需要几百毫秒在端侧设备上根本跑不动实时。MediaPipe Pose 轻量且 CPU 上跑得不慢但它输出的关键点模型是 Google 自研的 33 点结构和 COCO 标准不通用而且在多人场景、遮挡场景下稳定性一般。MoveNet 主打轻量但对输入尺度敏感训练自由度也低。YOLOv8-Pose 的优势在于它在检测框架内直接输出人体框和关键点不需要单独做人体检测再加关键点检测两级串联一步到位且支持从 n 到 x 多种尺寸从服务器到端侧都有匹配的模型选择。我的选择标准很直接模型体积可控、推理速度快、开源生态好、能导出 ONNX/TensorRT/NCNN 等中间格式用于端侧部署且支持自定义数据集继续微调。YOLOv8-Pose 这几项全部满足。更关键的是Ultralytics 提供统一的训练推理接口数据标注直接用 LabelMe 之类工具导出的格式就能转换训练工程化成本比 OpenPose 低不少。2. YOLOv8-Pose 模型选型尺寸、速度和精度怎么平衡确定用 YOLOv8-Pose 之后第二个问题就是选哪个尺寸的权重。YOLOv8-Pose 有 n、s、m、l、x 五个版本参数量和推理耗时差异很大。做跌倒检测这种需要 24 小时不间断跑的任务选型不能只看精度更要看功耗和实时性的综合表现。2.1 模型尺寸与推理速度的取舍五个版本在 COCO 验证集上的关键点 mAP50 和参数量大概是这样的实测数据会因为输入分辨率和硬件不同有浮动但相对关系稳定模型参数量输入尺寸关键点 mAP50CPU 单帧耗时约适用场景YOLOv8n-pose3.3M640x64050.460-100ms端侧实时YOLOv8s-pose9.6M640x64060.0150-200ms端侧/边缘YOLOv8m-pose26.4M640x64064.4300-400ms边缘服务器YOLOv8l-pose45.1M640x64067.0600ms服务器YOLOv8x-pose69.4M640x64068.0900ms离线分析我的建议是端侧实时项目闭眼选 YOLOv8n-pose边缘小主机可以选 YOLOv8s-pose。我在实际测试中把输入分辨率从 640x640 降到 480x480YOLOv8n-pose 在 RK3588 NPU 上单帧推理耗时可以压到 12ms 到 18ms完全满足 10fps 以上的实时检测需求而精度损失大概只有 1 到 2 个点的 mAP对跌倒判定这种任务完全可以接受。2.2 关键点输出格式与坐标还原说一个新手特别容易踩的坑YOLOv8-Pose 输出关键点坐标是相对于输入图像尺寸的归一化坐标不是原始图像的绝对像素坐标。如果你直接把模型输出的 x、y 当作像素坐标去画框算角度画出来的点全偏的。推理结果的 keypoints 数据格式是 [batch, num_person, 17, 3]最后一维的 3 个值分别是 x、y、置信度其中 x 和 y 是 0 到 1 之间的归一化值。还原到原始图像坐标需要乘上输入图像的宽和高import cv2 from ultralytics import YOLO model YOLO(yolov8n-pose.pt) results model.predict(frame, imgsz640, conf0.5, devicecpu) for result in results: boxes result.boxes.xyxy.cpu().numpy() # [N, 4] keypoints result.keypoints.data.cpu().numpy() # [N, 17, 3] # 关键点坐标还原 h, w frame.shape[:2] for person_idx in range(keypoints.shape[0]): for kpt_idx in range(17): x_norm, y_norm, conf keypoints[person_idx, kpt_idx] x_pixel int(x_norm * w) y_pixel int(y_norm * h) if conf 0.3: # 过滤低置信度关键点 cv2.circle(frame, (x_pixel, y_pixel), 3, (0, 255, 0), -1)很多教程里的示例代码直接画归一化坐标效果看起来“差不多”那是因为画图用的坐标系也是归一化的。一旦你要用真实物理距离、像素速度去计算跌倒特征归一化和真实坐标的换算错误就会直接导致阈值全部失效。这个细节务必重视。2.3 训练数据公开数据集加自建数据集的组合策略直接用 YOLOv8n-pose 的预训练权重做人体姿态估计精度在正常站立、行走场景下可用但跌倒场景属于“分布外数据”模型可能识别得不够好。我在项目里采用了两段式策略先下载公开的跌倒检测相关数据集再录一段自己环境下的数据做微调。公开数据集我推荐三个UR Fall Detection、Le2i Fall Detection、UP-Fall。UR Fall Detection 是意大利公司做的跌倒数据集包含 30 个序列、70 个跌倒事件有 RGB 图和深度图Le2i 是法国实验室做的包含多场景家庭、咖啡厅、办公室的跌倒视频UP-Fall 规模更大包含多传感器数据。这三个数据集都包含图像序列和跌倒标注可以转换成 YOLO 格式训练。转换的时候注意标准 COCO 格式的关键点标注是 17 点UP-Fall 这类数据集的标注格式可能不是 COCO 结构需要写脚本做转换映射。我踩过的坑是有些公开数据集只标注了人体框没有关键点标注这种数据只能拿来做人检测微调不能做姿态估计微调。自建数据时我建议在目标场景比如你家客厅、老人卧室正对摄像头录 30 到 60 分钟视频内容包含正常行走、坐下、弯腰捡东西、慢慢躺下、突然跌倒几个动作然后用 LabelMe 或者 X-AnyLabeling 做关键点标注。自建数据量不用太大300 到 500 张标注图就足够微调了。微调命令很简单Ultralytics 已经把流程封装好了yolo pose train datafall_dataset.yaml modelyolov8n-pose.pt epochs100 imgsz640 batch16fall_dataset.yaml里配置训练集和验证集路径以及关键点数量、类别名称。训练完看验证集的关键点 mAP 和 PR 曲线如果跌倒姿态下的关键点置信度普遍偏低优先增加这类样本量而不是盲目加训练轮数。3. 跌倒判定算法从关键点坐标到报警的完整链路模型输出 17 个关键点这只是中间产物。真正的核心难点在判别逻辑怎么根据关键点坐标判断一个人“摔倒了”这里不能只用一个特征拍脑袋定阈值要设计一套包含瞬态变化和持续状态确认的多条件判定机制。3.1 核心几何特征躯干角度、中心点速度、宽高比我在项目里用了三个几何特征组合起来判断跌倒躯干倾斜角。取肩部中心点索引 5、6 的关键点均值和髋部中心点索引 11、12 的均值构造躯干向量计算该向量与图像垂直方向的夹角import numpy as np def compute_torso_angle(kpts): shoulder_center (kpts[5][:2] kpts[6][:2]) / 2 hip_center (kpts[11][:2] kpts[12][:2]) / 2 torso_vec hip_center - shoulder_center # 躯干向量 vertical_vec np.array([0, 1], dtypenp.float32) # 垂直方向 # 计算夹角弧度 cos_theta np.dot(torso_vec, vertical_vec) / ( np.linalg.norm(torso_vec) * np.linalg.norm(vertical_vec) 1e-6 ) theta np.arccos(np.clip(cos_theta, -1.0, 1.0)) return np.degrees(theta)人在站立时躯干基本垂直角度在 0 到 20 度之间坐下时角度在 20 到 45 度之间真正跌倒或躺平时角度往往超过 60 度。我取 55 度作为第一层判断阈值。中心点垂直速度。跌倒的瞬态特征是人在极短时间内从高处落到低处髋部中心点的垂直像素坐标会有一次急剧变化。用当前帧和 5 帧前髋部中心 Y 坐标的差值再除以间隔时间帧数得到一个速度量纲的指标。def compute_hip_velocity(kpts_now, kpts_prev, dt_frames): hip_now (kpts_now[11][:2] kpts_now[12][:2]) / 2 hip_prev (kpts_prev[11][:2] kpts_prev[12][:2]) / 2 vy (hip_now[1] - hip_prev[1]) / dt_frames # 垂直方向速度像素/帧 return vy注意 Y 坐标向下为正所以跌倒时 vy 是正值数值越大说明下坠越快。这个特征最大的价值是能区分“慢慢躺下”和“摔倒”——前者速度低后者速度快。人体框宽高比。YOLOv8-Pose 同时输出检测框可以直接用框的宽高比做辅助特征。直立时高远大于宽宽高比在 0.3 到 0.5 之间倒地时宽和高互换宽高比大于 1。不过宽高比在坐着和蹲着时表现不稳定只能作为辅助特征不能单独作为主判据。3.2 判定阈值与误报场景处理把三个特征组合起来我设计了一套两阶段判定逻辑第一阶段是瞬态触发同时满足以下条件进入“疑似跌倒”状态躯干倾斜角大于 55 度髋部中心点垂直速度大于设定阈值这个值需要根据摄像头安装高度和视角标定我调试下来 480p 分辨率下取 15 像素/帧左右比较合适人体检测框宽高比大于 0.9第二阶段是持续确认。进入疑似状态后连续观察 30 帧约 3 秒如果这期间躯干倾斜角持续大于 45 度且髋部中心点一直处于图像下方区域则确认为跌倒触发报警。这套两阶段逻辑重点解决的就是误报问题。最常见的是老人弯腰捡东西躯干倾斜角可能瞬间达到 70 度中心点速度也够快但弯腰后很快会恢复直立不会持续躺在地上所以第二阶段确认机制能过滤掉这种瞬态误报。另一个高频误报场景是老人从床上坐起或者从沙发起身这时躯干角度变化也大但髋部中心点的垂直速度方向是向上的起身或变化缓慢第一阶段的速度条件就能挡住。实测下来还有一个很有用的技巧结合场景 ROI 区域做过滤。比如卧室场景里床的位置本身就长期有一个人体平躺的姿态如果不对这部分区域做特殊处理老人正常卧床休息会被判定为跌倒。我的做法是在配置界面里画一个可交互的 ROI 掩码把床、沙发的常驻区域排除出检测范围或者单独降低这些区域的报警优先级。3.3 时序平滑与稳定如何避免单帧抖动姿态估计模型在单帧上的输出是有抖动的同一个姿势连续两帧的关键点坐标可能有几个像素的随机波动。如果直接用原始坐标计算角度和速度阈值边缘的检测结果会频繁闪烁表现为 False Positive 和 False Negative 交替出现。我的解决方案是引入指数移动平均对关键点坐标做平滑smooth_kpts alpha * raw_kpts (1 - alpha) * prev_smooth_kptsalpha 我取 0.5 到 0.7 之间。alpha 越大平滑效果越弱跟随速度越快alpha 越小越平滑但延迟越大。实测下来 0.6 是个不错的平衡点既能过滤掉关键点抖动又不会让跌倒的瞬态速度特征被过度抹平。另一个必须处理的问题是跟踪稳定性。YOLOv8-Pose 对一帧画面里的多个人分别输出关键点如果画面里有多个目标前后帧的同一个人怎么对应最简单的方式是用检测框的 IoU 匹配做轻量级跟踪。上一帧的人体框和当前帧的人体框 IoU 超过阈值就认为是同一个人然后把关键点序列按人分别保存。我在项目里自己实现了一个不到 100 行的 IoU 匹配器没有引入 ByteTrack 这样的独立跟踪模块原因是跌倒检测场景下画面中人数通常很少简单匹配完全够用还能少一个依赖。4. 实时视频流接入与多线程架构保证稳定不掉帧跌倒检测系统如果推理速度够快但取流环节出问题整体依然会卡顿。实际部署中摄像头取流、模型推理、告警推送三个环节必须解耦各自跑在独立线程里否则任何一环卡顿都会形成连锁阻塞。4.1 摄像头与 RTSP 取流的缓冲策略家庭看护场景首选普通 USB 摄像头或者支持 RTSP 协议的 IPC。USB 摄像头用 OpenCV 的 VideoCapture 就能直接读但要注意它这个接口有个坑在不稳定的网络或 USB 带宽受限时VideoCapture 的 read() 可能长时间阻塞。我的做法是单独开一个取流线程把读到的帧放进一个有限长度10 帧左右的环形缓冲区推理线程从缓冲区取帧。如果缓冲区满了直接丢掉最旧的一帧保证推理永远处理最新画面。RTSP 取流则更考验网络状况。Wi-Fi 信号不稳时 RTSP 流会周期性卡顿延迟增大。实测下来海康和大华的主流摄像头只要在子码流上跑跌倒检测用 H.264 编码、分辨率 640x480、帧率 15fps、码率限制在 1Mbps 以内RTSP 延迟可以稳定在 300 毫秒左右。如果你的场景允许尽量选择子码流而不是主码流来跑算法因为跌倒检测的核心是姿态变化趋势不需要极高清的画面细节。4.2 推理线程与检测逻辑的解耦整个系统的线程模型我建议拆成五个模块取流线程负责从摄像头或 RTSP 读取帧写入帧缓冲姿态估计线程从帧缓冲取帧运行 YOLOv8-Pose 推理输出关键点跌倒分析线程消费关键点序列运行平滑、特征计算、状态机判定告警线程收到确认为跌倒的事件后执行本地声光报警和网络推送主线程负责管理上述线程的生命周期和配置更新这样的好处是每层的耗时可以独立评估。姿态估计线程如果因为设备温度降频变慢不会影响取流线程继续缓冲最新帧告警推送如果因为网络超时阻塞也不会让分析和取流停下来。实际部署中我遇到过一个典型的崩溃场景网络断线导致告警推送线程在 socket 连接上阻塞了几十秒从而连带整个进程卡死。把告警做成独立线程后即使推送失败也只是丢掉一次告警不会影响主流程。Python 里可以用queue.Queue做线程间通信注意给所有队列设置maxsize否则内存会被慢速消费者拖爆。我前面说的环形缓冲区设计本质上就是对这个问题的防护。4.3 告警推送的三种方式现场、局域网、公网跌倒检测的告警必须做到“即使家里没人也能通知到”。我按可靠性排序列出三种方式现场声光报警接一个蜂鸣器和 LED 灯检测到跌倒后 GPIO 拉高现场发出刺耳警报。这是最原始也最可靠的断电都能靠电池模块顶上。局域网通知通过 MQTT 协议把跌倒事件发布到家庭中枢Home Assistant 或者自建的 MQTT broker中枢可以做更复杂的联动比如开灯、发语音提醒。公网推送微信推送用 Server酱或者企业微信群机器人只需一个 Webhook URL跌倒事件以 HTTP POST 形式推送。如果家里老人独居且没人安装 App可以考虑加一个 4G 短信模块跌倒时直接发短信到子女手机。我实际用下来微信推送 MQTT 联动是最实用的组合。要注意公网推送必须处理失败重试和去重不能一次跌倒触发几十条重复告警。我的去重策略是同一个人的跌倒状态在 5 分钟内只推送一次直到检测到该人恢复站立才重置状态。5. 超低功耗端侧部署从插电跑算法到电池供电的边缘 AI 视觉模块实话说系统跑在 PC 上并不稀奇真正让跌倒检测能落地到独居老人家里的是端侧低功耗部署。老年人家庭不可能常开一台高功耗主机也不希望摄像头画面被送到云端引发隐私顾虑。边缘 AI 视觉模块就成了刚需。5.1 为什么端侧部署是家庭跌倒检测的刚需家庭场景有两条硬约束一是不能有高功耗设备长期运行二是视频数据最好不出本机。以 NVIDIA Jetson Orin Nano 为例它的算力足够跑 YOLOv8s-pose但满载功耗在 7 到 25W 之间长期运行一个月光电费就是一笔开销而且需要风扇散热噪音和体积都不适合放在老人床头。普通桌面 CPU 跑 YOLOv8-Pose 的功耗更夸张动辄上百瓦。端侧 NPU 方案则完全不同。我之前测试过几款电池供电的边缘 AI 视觉模组整机平均功耗能做到 2W 到 5W 左右。比如瑞芯微 RV1106/RV1103 系列内置 0.5 TOPS 到 1 TOPS 算力的 NPU专门为 IPC 摄像头设计一颗芯片加上摄像头传感器、内存、Wi-Fi 模组整个模组功耗不超过 2W。这样的功耗水平理论上用一节 12V 10Ah 的锂电池就能跑超过 40 小时这已经是“电池供电的端点 AI”的实际水平了。5.2 模型量化与 NPU 加速的实操要点端侧 NPU 通常跑不了原始 FP32 模型需要量化到 INT8。Ultralytics 导出 ONNX 后可以根据目标 NPU 的平台选择对应的量化工具链瑞芯微平台使用 rknn-toolkit2 把 ONNX 转为 RKNN 格式支持 INT8 量化算能平台使用 tpu-mlir 工具链转换支持 INT8/BF16Hailo 平台使用 Hailo Dataflow Compiler 转换支持 INT8OpenVINO 平台直接用 Intel 工具链做 FP16/INT8 转换我在 RV1106 上转 YOLOv8n-pose 的流程是先把 PyTorch 权重导出为 ONNX再通过 rknn-toolkit2 做 INT8 量化校准。量化校准数据集不需要太多从训练集里抽 100 到 200 张代表不同光照和姿态的图片就够了。转换完的 RKNN 模型在 NPU 上单帧推理可以跑到 15fps 到 25fps输入 256x256 或 320x320功耗只有 1W 左右这个表现足够支撑实时的跌倒检测了。有一个特别重要的坑要提醒不同 NPU 对算子支持度不一样。YOLOv8 的 C2f 模块里有一些结构在转换到部分 NPU 时可能报算子不支持。遇到这种情况不要硬转优先修改模型配置把 C2f 换成更基础的 CSP 结构或者直接改用对应平台官方仓库优化过的 YOLO 变体比如瑞芯微的 rknn_model_zoo 里有现成的 YOLOv8 适配版本。硬转出来的模型就算能跑推理精度也可能因为图优化失败而大幅下降。5.3 功耗优化策略动态帧率与事件触发电池供电的核心约束是功耗预算而功耗与帧率几乎是线性关系。在待机状态画面中没有人体时不需要满帧率跑姿态估计。我的策略是分级功耗调度状态触发条件检测帧率平均功耗深度待机画面无变化0.2fps每5秒一帧约1W浅待机画面有移动目标但无人形1fps约1.5W实时检测检测到人体10-15fps约3W跌倒分析疑似跌倒事件触发15fps 状态机满载这个调度逻辑的本质是把算力集中在“有人的时候”人不在就只跑一个极低帧率的运动检测。运动检测用帧差法在 MCU 或 CPU 上就能实现不需要 NPU 参与。实测下来假设老人每天在摄像头前活动 4 小时其余时间处于深度待机系统的日均功耗可以从持续的 3W 降到 1.5W 左右电池续航直接翻倍。5.4 端侧设备选型参考如果你想自己攒一套低功耗跌倒检测盒子我列几个真实评估过的方案供参考平台算力典型功耗YOLOv8n-pose 实测帧率开发难度RV1106/RV11030.5-1 TOPS1-2W15-25fps中RK35886 TOPS3-7W30-40fps低Hailo-8L13 TOPS2.5W50fps中Jetson Orin Nano20 TOPS7-25W60fps低树莓派5 TensorFlow LiteCPU/NPU5-10W5-10fps低我的排名是如果要做产品原型RV1106 模组性价比最高如果要在已有 Linux 小主机上快速验证算法RK3588 最省心如果追求极致能效比Hailo-8L 配合树莓派或 x86 主机很能打。注意 Jetson 虽然性能强劲但功耗不适合纯电池供电的长期部署。6. 实测效果、误报漏报调优和部署前检查清单算法和硬件都定了最终效果还是要在真实场景里打磨。我在客厅、卧室、卫生间三个场景分别跑了连续一周的测试记录误报和漏报情况并针对性地调参这个环节花的时间比写代码多得多。6.1 三个典型场景的实测数据我在一个模拟独居老人的环境中用一台安装高度 2.2 米、俯视角度约 30 度的摄像头做了为期一周的测试。测试内容包含正常起居动作和模拟跌倒动作。场景检测到跌倒漏报误报平均检测延迟客厅94231.2s卧室76151.5s卫生间51371.8s从数据能明显看出卫生间的误报率最高主要原因是空间狭小、人离摄像头近身体部位容易被裁切出画面关键点丢失严重。睡眠场景下老人夜间翻身、坐起的动作也很容易被误判为跌倒。这套系统在开阔场景下可用性已经很高但小空间场景还需要针对性优化。针对卫生间我做了两个调整一是把摄像头的安装角度调成更大的俯视角让人的整个身体更容易完整落在画面内二是调整了髋部中心点速度阈值因为小空间里人离镜头近像素位移本身就偏大不调整阈值会导致所有动作都被认为速度过快。6.2 误报漏报的调优经验漏报的典型原因是关键点置信度低。跌倒时人体快速移动会产生运动模糊模型在这种情况下输出的关键点置信度普遍下降。如果关键点置信度太低判定逻辑里过滤这些点时会把所有特征计算都跳过造成漏报。我的做法是把关键点置信度阈值从 0.5 降到 0.3同时对低于阈值的点启用插值预测——用上一帧的位置加上估计速度来填充缺失点保证特征计算不断流。误报则更多来自场景和动作的歧义。最容易误报的动作为老人从沙发滑坐到地上的动作、弯腰系鞋带、在床上翻身导致躯干短暂接近水平。针对这些除了前面说的两阶段确认机制外还可以在判定逻辑里加一个速度敏感型开关如果髋部中心点的垂直速度没有超过阈值即使躯干角度达到 60 度以上也不进入疑似状态。这个开关能把“缓慢坐倒”和“突然摔倒”区分开后者才是跌倒检测真正需要报警的事件。6.3 部署前必须确认的检查清单最后把我踩过的坑整理成一份检查清单照着做能省大量返工时间摄像头安装位置决定算法上限。尽量正对活动区域高度 2 到 2.5 米、俯角 20 到 40 度避免背光、强逆光和遮挡物。预训练模型必须在目标场景微调后再上线直接用通用的 YOLOv8n-pose 权重跑跌倒检测误报率会高到不可用。关键点坐标必须做归一化还原和时序平滑否则阈值判定会抖动。端侧部署时先确认算子的平台兼容性再买硬件否则模型转不到目标格式会非常被动。告警必须做去重和失败重试否则网络抖动时子女手机可能同时收到十几条告警。电池供电方案要提前测连续运行 72 小时记录温度、功耗曲线和降频情况很多模组长时间运行后 NPU 频率会下降导致推理延迟翻倍。我在做最后一轮测试时还发现一个有意思的现象安装高度低一点比如 1.8 米虽然人体检测框更大但俯角变小后躺倒时躯干角度的区分度反而变差容易把站立和躺倒混淆。所以摄像机高度和俯角的搭配一定要根据房间面积反复试不能只看检测框大小。这套系统从调研到稳定运行差不多花了一个半月的时间其中模型微调和误报调优占了七成时间。如果只追求快速跑通用预训练权重加双阶段判定逻辑两天就能搞定一个能看的 Demo但如果要做成 7x24 小时可靠运行的看护设备关键点特征的设计、端侧功耗的优化和误报场景的长期测试每一环都不能省。