YOLOv8-Pose实时跌倒检测：从姿态估计到智能报警

先说背景。老年人跌倒这事，说小是小，说大能致命。很多独居老人在家里摔一下，身边没人，错过了黄金救治时间，后果往往比摔伤本身严重得多。之前大家主要靠可穿戴设备（手环、挂坠）做跌倒检测，但老人不愿意戴、忘了充电、洗澡摘下，实际落地效果大打折扣。这几年视觉方案逐渐被重视，摄像头装在客厅、卧室，不用老人配合，靠算法自动识别跌倒行为。我这次做的就是基于 YOLOv8-Pose 的实时跌倒检测系统，用 AI 视觉识别人体姿态，在跌倒发生瞬间触发报警。这篇文章把整个项目的设计思路、模型训练、推理优化、误报排查完整拆开讲，适合正在做视觉巡检、行为识别、智能看护项目的工程师，也适合想用姿态估计解决实际问题的朋友参考。

这个系统最终跑下来效果让我比较满意：在普通 GPU 上 1080P 视频推流能做到每帧 12ms 左右的推理耗时，用 TensorRT 压到边缘设备上也有接近实时的速度。整套逻辑并不复杂，核心就三块：YOLOv8-Pose 做关键点检测、基于关键点的时序跌倒判定规则、以及报警联动。下面从选型开始一步步拆。

1. 项目背景与核心技术选型

1.1 跌倒检测的现实痛点与方案对比

做跌倒检测，首先得搞清楚这类场景跟普通安防监控有什么不一样。普通监控只要识别"有人"或者"有异常物体"就行，跌倒检测要识别的是"人从站立状态在极短时间内变为躺倒状态"，这是一个强时序行为，单帧画面往往说明不了问题。一个人躺在地上，可能是睡觉、可能是蹲下系鞋带、也可能是真的摔倒了。所以算法层面不能只看单帧的姿态，还要结合连续几帧的变化趋势判断。

再看当家养老、医院病房、康复中心这类落地场景，对设备的要求非常具体：不能打扰老人、不能侵犯太多隐私、要能 7x24 小时工作、误报率还不能太高。去调研一圈会发现，可穿戴设备的问题就出在"人机交互"上，老人对这个东西天然有抵触，戴不戴全看心情。视觉方案用固定摄像头，完全被动式感知，老人没有负担，这是它最大的优势。

视觉方案内部也有几条技术路线：

• 传统图像处理：背景建模 + 运动目标检测 + 轮廓分析，便宜但对光照、遮挡、复杂背景极度敏感，夜里基本废掉。
• 普通目标检测（YOLO 系列检测人的 bounding box）：能框出人，但框的宽高比变化在跌倒时确实有特征，可单独靠检测框很容易把"坐下""弯腰捡东西"误判成跌倒。
• 姿态估计（Pose Estimation）：直接回归出人的骨骼关键点，能拿到更丰富的信息——肩膀和脚踝连线的角度、重心高度、躯干倾斜度，这些都是判断跌倒的"硬通货"。

所以最终选型很明确，用YOLOv8-Pose，模型本身就是 YOLOv8 系列里做姿态估计的变体，检测头同时输出人的 bounding box 和 17 个关键点坐标。它兼顾了目标检测的速度和姿态分析的灵活性，工程上是性价比最高的解。

1.2 为什么选择 YOLOv8-Pose 而不是普通检测模型

有不少人问，我做普通YOLOv8检测人的框，跌倒时宽高比从"高瘦"变成"矮胖"，这个特征不够吗？说实话，光靠宽高比，能筛掉一部分误报，但撑不住真实场景。老人弯腰捡东西、坐在沙发上滑下来、半躺在床上看手机，这些动作框的宽高比都会变得"矮胖"，误报率会高到让护理人员想把设备拔了。

YOLOv8-Pose 多输出 17 个人体关键点，这就把"人长什么样"升级成了"人是怎么摆放的"。我可以用关键点计算：

• 肩膀中心高度和脚踝中心高度的差值，判断人到底是站着还是躺平；
• 躯干主轴（肩部中点到髋部中点连线）与水平面的夹角，角度接近 0 度大概率是倒地；
• 头部关键点的瞬时速度，跌倒是一个快速过程，正常躺下有准备、速度慢，跌倒有明显的加速度。

这些信息叠加起来，判定规则的维度就多了，误报率能压到很低的水平。而且 YOLOv8 本身在 COCO 上的检测精度就不差，Pose 版本的关键点 mAP 在公开数据集上也能到 50 以上，接近实时推理的表现。综合准确率、速度、工程成熟度，它就是当前做视觉姿态分析的最优选。

需要提醒一点，如果用 OpenPose 或者 HRNet 这类姿态估计方案，单帧精度其实也不错，但推理速度和模型体积完全没法跟 YOLOv8 比。落地到嵌入式设备时，实时性就卡死了。工程里"够用的精度 + 极致速度"往往比"最高精度"更值钱。

注意：YOLOv8-Pose 的 17 个关键点遵循 COCO 标注格式，顺序依次是鼻子(0)、左眼(1)、右眼(2)、左耳(3)、右耳(4)、左肩(5)、右肩(6)、左肘(7)、右肘(8)、左腕(9)、右腕(10)、左髋(11)、右髋(12)、左膝(13)、右膝(14)、左踝(15)、右踝(16)。这个顺序在做后处理的时候非常重要，写代码时一定要拿索引对照清楚。

2. 数据准备与模型训练细节

2.1 数据集选择与自建数据策略

模型训练之前，数据是最关键的一环。公开数据集里面，UR Fall Detection Dataset（URFD）和 Le2i Fall Detection Dataset 是比较常用的两个，URFD 用 Kinect 摄像头采集，包含 30 个跌倒序列和 40 个日常生活序列，Le2i 是普通 RGB 摄像头，场景覆盖了咖啡厅、办公室、家庭室。这些公开数据的优点是拿来就能用，跑基线版本足够了。

但只靠公开数据训练出来的模型，拿到真实场景里大概率要翻车。公开数据集的摄像头角度大多是中等高度俯拍，可真实养老院走道的摄像头经常装在高墙角，角度接近 70 度俯视，关键点在这种视角下会变形得很厉害。所以我强烈建议租一个或自己搭一个测试环境，模拟真实安装高度和角度，录 2-3 个小时的室内视频，把正常行走、坐下、起立、弯腰、蹲下、慢慢躺下、模拟跌倒这些动作都录进去，标注后混进训练集。这个过程很累，但回报极高。

标注工具我用的是 Labelme 或者 CVAT，CVAT 支持关键点标注，直接导出 COCO 格式给 YOLOv8 用。标注关键点时注意：被遮挡的关键点不标，只标清晰的。跌倒场景里人躺在地上，脚踝被身体挡住一部分很常见，硬标出来的错误关键点会教坏模型。

2.2 训练配置与关键参数调优

训练这块直接用 Ultralytics 的框架最省事。安装依赖后，把数据集组织成 YOLO 格式的目录结构，写好 data.yaml，就能开训。我选的基础模型是 yolov8n-pose 和 yolov8s-pose，用 COCO 预训练权重做迁移学习。

# fall_dataset.yaml path: ./fall_dataset train: images/train val: images/val nc: 1 kpt_shape: [17, 3] names: 0: person

from ultralytics import YOLO # 用训练好的模型继续微调 model = YOLO("yolov8s-pose.pt") model.train( data="fall_dataset.yaml", epochs=150, imgsz=640, batch=16, lr0=0.001, weight_decay=0.0005, device=0, workers=8, augment=True, patience=20, )

有几个参数我调过之后体会很深。imgsz不是越大越好，640 输入在速度与精度之间最均衡，用 1280 训练关键点精度会高一点，但推理速度直接掉一半，对实时性不友好。kpt_shape必须是[17, 3]，第三个维度 3 表示每个关键点的数据是 (x, y, visible_flag)，这个配置如果写错，训练会在数据加载阶段就报一堆奇怪的 error。另外patience建议开 20 左右，早停正则能防止模型在后期过拟合到训练集上。

训练过程还要注意类别不平衡。跌倒样本相对少，正常站坐行走的动作不要删，反而可以多保留一些，因为跌倒判定的对比基线就是正常状态。训练时把"日常生活"和"跌倒"两类样本比例控制在大概 3:1 比较合理，不然模型会过度偏向某一类，泛化能力就下降了。我实测下来，单纯追求 Accuracy 没有意义，重点看的是在"大部分正常动作不误报"前提下的"跌倒召回率"，宁可少报一次，也不能天天报假警。

2.3 模型轻量化选择：nano 还是 small

YOLOv8-Pose 有多个规格，nano、small、medium、large。我在项目里做了对比测试，把结果整理在下面：

对跌倒检测来说，关键点精度并不需要做到像素级完美，只要肩、髋、脚踝这些大关节位置准确，后续计算角度和速度就够用。所以做边缘部署用 nano，服务器端用 small，medium 对于实时场景有点奢侈。我自己最终默认首选yolov8s-pose，在速度和精度之间最平衡。

训练结束之后瓶颈已经不在模型精度，而在推理链路和判定规则上。模型再好，判定逻辑写得稀烂，照样误报。下面进入整个系统最核心的部分。

3. 跌倒判定算法：从关键点到动作判断

3.1 单帧特征提取：宽高比、主轴角度与重心速度

拿到模型输出的 17 个关键点之后，不能直接把坐标丢给规则，得先做归一化和特征提取。我的做法是提取三类特征：

第一是人体检测框的宽高比。这个特征虽然之前说不能单用，但作为辅助依然有参考价值。站立时通常height > width，宽高比小于 1，倒地时框会翻转，宽高比大于 1.2 左右。用keypoints可以直接算一个人体包围盒，比模型输出的检测框更贴合姿态变化。

第二是躯干主轴与水平面的角度。这个是最核心的特征。取左肩(x5, y5)、右肩(x6, y6)的均值得到肩部中点，左髋(x11, y11)、右髋(x12, y12)的均值得到髋部中点，连接这两个中点就是躯干主轴。计算主轴向量(dx, dy)与水平面的夹角：

import numpy as np def compute_torso_angle(kpts): left_shoulder = kpts[5] right_shoulder = kpts[6] left_hip = kpts[11] right_hip = kpts[12] shoulder_center = (left_shoulder + right_shoulder) / 2 hip_center = (left_hip + right_hip) / 2 dx = hip_center[0] - shoulder_center[0] dy = hip_center[1] - shoulder_center[1] angle = np.degrees(np.arctan2(abs(dy), abs(dx) + 1e-6)) return angle

这个角度有意思的地方在于：站立时它接近 90 度，完全倒地时接近 0 度。我设的角度阈值是 30 度，即躯干与水平面夹角小于 30 度，就认为这个人已经处于"接近水平"的状态。

第三是头部关键点的移动速度。跌倒的过程是身体位置快速变化的过程，尤其是头部。按帧率 25fps 来算，正常站立时头部位置每秒变化一般不超过 20 像素，而跌倒时头部可能在 0.4 秒内移动超过 100 像素。这里的像素值跟相机距离有关，所以我用了归一化速度——即头部关键点在相邻帧间的位移除以人体检测框的高度，这样不同远近的人速度特征是一致的。

3.2 时序状态机：消除单帧误判

有了单帧特征，还要处理"怎么不误报"的问题。我的方案是构建一个三段式状态机：STANDING（正常状态）、FALLING（疑似跌倒状态）、DOWN（确认倒地状态）。

触发机制是：

• 当前帧检测到人，计算躯干角度小于 30 度，同时头部归一化速度大于 0.3，临时判定为FALLING，进入观察窗口。
• 在接下来的 5 帧里，至少有 3 帧满足躯干角度小于 30 度，才确认进入DOWN状态并触发报警。
• 如果 5 帧内姿态恢复正常（角度回到 60 度以上），则判定为误触发，状态机重置。

这个设计解决了一个很关键的问题：老人弯腰捡东西可能只有 2-3 帧变成"水平状"，但通常很快就会起身回到站立状态。用连续帧投票，就能把这类正常动作跟真正的跌倒区分开。

另外考虑到隐私问题，实际工程中我只跑检测算法，不做视频存储。系统只在触发报警后抓拍一张现场图和一段前后各 5 秒的短视频，用于家属确认。推断过程全在本地完成，视频流不出局域网，这在养老院这类隐私敏感场景里是必须处理好的底线。

3.3 关键点缺失与遮挡处理

真实场景里人不可能永远完整地出现在画面中央。老人扶着墙慢慢滑倒、被桌子挡住半边身体、或者躺下的位置靠近画面边缘，都会导致部分关键点缺失或置信度极低。YOLOv8-Pose 输出的每个关键点带一个 visible flag，我处理遮挡的逻辑是：

• 计算躯干角度时，如果肩部中点和髋部中点中任意一个不可用，本帧直接跳过，不更新状态机；
• 如果连续 30 帧都检测不到完整人体，说明可能是误检，重置状态机；
• 只用置信度高于 0.5 的关键点参与计算，低于阈值的坐标直接丢弃，防止噪声点把角度带偏。

这里有个容易踩的坑：摔倒时人可能蜷缩起来，脚踝被身体挡住。很多姿势估计算法会把被挡的脚踝点"猜"到一个离谱的位置，然后用这个错误的位置计算身体主轴，导致判定失败。我的办法是，宁可缺少一个脚踝关键点，也不要用 -- 置信度极低的点，反正我主要靠躯干的肩髋连线，这个不容易被漏掉。

4. 实时推理链路与系统架构

4.1 端到端实时链路：从 RTSP 拉流到报警推送

整个系统跑起来之后，数据流是这样的：摄像头/RTSP 视频流 -> OpenCV 拉帧 -> YOLOv8-Pose 推理 -> 关键点后处理 -> 状态机判定 -> 报警推送。用 Python 跑单线程，在普通 GPU（比如 RTX 3060）上每帧推理 12ms 左右，加上拉流和绘制，整体能跑到 30fps 以上，完全满足实时要求。

import cv2 import numpy as np from ultralytics import YOLO import requests import time class FallDetector: def __init__(self, model_path, conf_thres=0.5, alert_url=None): self.model = YOLO(model_path, task="pose") self.conf_thres = conf_thres self.alert_url = alert_url self.state = "STANDING" self.fall_candidate_frames = 0 self.last_alert_time = 0 def process_frame(self, frame, frame_id): results = self.model(frame, verbose=False)[0] if results.keypoints is None: return frame, None kpts = results.keypoints.data.cpu().numpy() for person_kpts in kpts: torso_angle = self.compute_torso_angle(person_kpts) head_speed = self.compute_head_speed(person_kpts, frame_id) if torso_angle < 30 and head_speed > 0.3: self.fall_candidate_frames += 1 else: self.fall_candidate_frames = 0 if self.state == "STANDING" and self.fall_candidate_frames >= 3: self.state = "FALLING" if self.state == "FALLING": if self.fall_candidate_frames >= 5: self.state = "DOWN" self.trigger_alert(frame, frame_id) elif self.fall_candidate_frames == 0: self.state = "STANDING" return frame, self.state

报警推送用 webhook 最方便。我接的是企业微信机器人，把抓拍的图片和文字消息推到家属群里，用的就是requests.post，代码里一个函数的事情。也可以接 MQTT 到智能家居平台，或者发短信，看部署环境需求。

4.2 推理加速：ONNX 导出与 TensorRT 部署

模型要在边缘设备上跑，还得做一步推理加速。Ultralytics 的 PyTorch 模型直接部署在嵌入式设备上太勉强，我通常导出成 ONNX，再转 TensorRT engine，推理速度能提升两三倍。

# 导出 ONNX yolo export model=best.pt format=onnx opset=12 # 用 trtexec 转 TensorRT engine trtexec --onnx=best.onnx --saveEngine=best.engine --fp16

转 TensorRT 有几个经验：一是--fp16基本无损，关键点 mAP 下降可以忽略，但速度提升立竿见影；二是输入输出张量名字在导出后会变，推理时拿不准就打印一下输入输出名；三是 TensorRT engine 跟显卡型号绑定，换个设备必须重新转，这个坑每次都要跟同事解释一遍。

4.3 低功耗端侧部署方案

最近端侧 AI 视觉模块很火，超低功耗方案甚至能靠电池供电做到设备独立部署，摆脱网线、插座和边缘服务器的限制。如果用树莓派的环境，选yolov8n-pose也能在 30fps 左右跑起来，功耗大约 5-10W，适合在房间里装多路摄像头。若需要更极致的功耗控制，还有一类 "超低功耗端侧 AI 视觉模块"，用推理芯片加电池供电，几瓦功耗就能跑跌倒检测模型，非常适合养老院隔间改造和老旧小区加装。这类模块通常预装 Linux 系统，算力大约 1-4 TOPS，跑小模型正好。当然这类模块的摄像头和传感器集成度高，客户通常只能做配置和告警联动，算法层面做不了太复杂的微调，适合产品化场景，而不是算法调试场景。

我自己测试过的边缘平台上，Jetson Orin Nano 是一个比较舒服的配置，yolov8n-pose用 TensorRT 加速后能做到 20ms/帧，还有余力跑一些辅助算法。树莓派 5 也能跑，但 CPU 推理基本只有 10fps 左右，实时性差一些，建议至少加一个 USB 加速棒或者选择带 NPU 的开发板。

4.4 视频帧采样的取舍

实时分析还有一个容易被忽略的细节：摄像头帧率。有些廉价的 IPC 摄像头宣称 25fps，但实际弱光下会掉到 10fps 以下。跌倒动作本身可能只持续 0.3-1 秒，如果帧率低到 5fps，一个跌倒动作可能只抓到 2-3 帧，状态机根本来不及做连续帧投票。

针对这个问题，我在低帧率场景下做了策略调整：把fall_candidate_frames >= 3这个连续帧条件改成了"5 帧窗口内出现 2 次疑似状态"，这样即使只有 3fps 的帧率，也能在跌倒过程中捕捉到足够证据。另一个补救方式是采用"隔帧处理 + 立即推理"策略，即视频流拉流线程和推理线程分离，拉流线程始终以摄像头最高帧率接收图像并缓存最新帧，推理线程每次取最新帧做分析，这样 CPU 计算跟不上视频流时，不会因为处理旧帧增加延迟。

5. 实测效果与误报案例复盘

5.1 现场实测数据

我在一个模拟养老院场景（客厅 + 走廊）里做了 7 天测试，摄像头装在天花板下沿，距地面 2.8 米，45 度俯视。一共组织了 5 位不同体型的志愿者，每人表演 20 次各种方式的跌倒（正面倒、侧倒、后退倒、滑倒），同时穿插几十种日常行为（走路、坐下、弯腰、捡东西、蹲下、伸懒腰），测试结果如下：

漏掉的 6 次基本都是同一个原因：跌倒位置在画面边缘，人体被沙发扶手遮住了下半身，导致关键点置信度过低。这个问题不是模型的问题，而是摄像头安装位置的问题，加一个广角镜头或者调整摄像头角度就能解决。4 次误报里有 2 次是老人突然蹲下捡东西（躯干角度瞬间降低），另外 2 次是从沙发上猛地站起来然后弯腰看桌下。这些误报在增加状态机冷却时间后（触发报警后 15 秒内不重复报警）减少到可接受范围。

5.2 真实部署中的教训

有几个实际部署时踩过的坑，这里详细说一下。

第一，模型泛化能力不足。用公开数据集训练的模型，第一次在现场测试时，把"坐在椅子上弯腰系鞋带"识别成了跌倒，因为躯干角度的确一度小于 30 度。后来我在训练数据里补充了大量"坐着弯腰"的样本，同时把状态机的连续帧数从 3 帧提高到 5 帧，这个问题就明显缓解了。

第二，画面的光照变化影响巨大。养老院房间晚上关灯后，普通 RGB 摄像头画面噪点很多，关键点检测质量严重下降。解决方式是选带红外夜视功能的摄像头，或者在训练数据里加入大量低光照样本（用亮度增强做模拟），效果立竿见影。

第三，报警延迟与防抖的平衡。最初状态机设置为连续 8 帧满足条件才报警，结果发现有些老人摔倒速度很快，等第 8 帧确认时人已经躺在地上好几秒了。后来改成了"3 帧快速确认 + 15 秒冷却"策略，既保证响应快，又避免重复报警。

5.3 与实时视觉方案的横向对比

测试过程中我也顺手对比了另一种方案：用普通目标检测（YOLOv8n）检测人，再计算检测框宽高比做判定。同样跑 7 天测试，结果是误报率大约降低到每百小时 0.8 次，但召回率从 94.5% 降到了 81%，漏报明显增加。这说明单纯用框形判断虽然误报少，但漏报严重——很多跌倒瞬间，人的框并不一定是"矮胖"的，例如脸朝下倒向镜头时，框高宽变化不明显。而关键点方案虽然计算量稍大，但召回率更有保证。这让我更坚定了"关键点 + 时序规则"才是跌倒检测的可靠路线。

6. 常见问题与排查技巧实录

6.1 训练与推理常见问题速查表

6.2 端侧部署特殊问题

在边缘设备上部署还会遇到其他问题。Jetson 上跑 TensorRT engine 时，最常见的坑是输入输出张量名字和 Ultralytics 的 Python API 不匹配——直接用model.predict()指定 TensorRT engine 没问题，但手动用 TensorRT Python API 推理时，必须确认输入是 NCHW 格式且归一化方式正确。YOLOv8 的预处理是 /255 归一化，BGR 转 RGB，这点千万别忘。

树莓派上跑，还有内存带宽瓶颈的问题。树莓派 4 的 CPU 推理速度其实不慢，但摄像头拉流和模型推理抢内存，处理 1080P 视频时经常出现掉帧。我最后把输入分辨率缩小到 640，推理帧率稳定在 12-15fps，体感上仍然可用，但不太适合要求快速响应的场景。

低功耗端侧 AI 模块跑这类模型，通常只支持 INT8 量化模型，需要在 PC 上离线校准量化再烧录，量化的校准集最好用现场真实场景截图，我用 COCO val 的 500 张图做过一次校准，效果明显不如拿 200 张现场图。

6.3 判定规则调参心得

状态机的三个阈值——躯干角度、归一化速度、连续确认帧数，是系统里最需要反复调的参数。我最后用的参数组合是：躯干角度 30 度、归一化速度 0.3、连续帧数 5。但如果换一个摄像头安装高度，这些参数基本都要重新调。我的做法是在程序里加了一个调试模式，把每一帧的关键点坐标、角度和速度直接打出来叠加在画面上，现场调优时能直观看到问题出在哪一步。

调整时比较实用的方法是记录误报前后的 3 秒视频，回放时看每一步特征的数值变化，而不是盲调参数。例如发现误报是因为"蹲下捡东西"，就看当时躯干角度到底到了多少度，速度是多少，是阈值设得太松还是连续帧设得太短，对症下药。

最后再分享两个小技巧

做工程和做论文不一样，论文追求通用性，工程追求在约束条件下解决问题。第一个技巧是：如果摄像头画面里同时出现多个老人，系统要能够分别追踪每个人的状态，不能因为 A 老人跌倒了就一直报警，而忽略 B 老人也跌倒了。我的做法是用一个轻量级的 IoU tracker 给每个人分配 ID，每个 ID 维护独立的状态机，这样多人场景下检测和报警不会串线。第二个技巧是：报警信息里除了图片，最好附带一张带有姿态骨架叠加的视频帧截图，护理人员一眼就能确认是什么情况，比纯文字报警直观得多。

这套系统的价值不在于模型本身多强，而在于把姿态估计技术真实地嵌入到了看护场景中。技术上没有太玄妙的地方，关键在于数据的真实覆盖度和规则设计的合理性。后续我还在尝试把"正常行走步态分析"加进去，这样同一个摄像头既能做跌倒检测，又能做健康趋势分析，一套设备的价值就更大了。