跌倒检测这件事，我在实际项目里踩过不少坑。很多人以为拿个开源模型跑一下，能框出“人”就算完事，但真正落地到养老院、独居老人监护或者工地安全场景时，你会发现误报率、漏检率、实时性这些指标每一项都能让人头疼。今天这篇就基于YOLOv11，完整拆解一个带UI界面、登录注册、Python源码和训练好的模型的跌倒识别检测系统，从数据集构建到模型训练，再到界面封装，把整个链路讲透。
1. 项目核心思路：为什么选择YOLOv11来识别“跌倒”这个动作
先聊一个很多人没想清楚的问题——跌倒识别本质上是个什么任务？它不是普通的分类，也不是纯粹的目标检测。在实际场景里，“跌倒”是一个动态的身体姿态变化过程，但在单帧图像上，它表现为一个人“躺在地上”或“蜷缩在地”的异常姿态。所以用目标检测来做完全可行，核心在于检测到人，再通过人体边界框的几何特征（比如宽高比、倾角、关键点位置）去判断是否发生了跌倒。
YOLOv11作为新一代目标检测模型，相比之前的版本有几个很实在的优势。它的骨干网络和特征融合结构做了进一步优化，在同等算力下推理速度更快，这对实时视频流检测特别重要。跌倒检测系统需要每秒处理至少10到15帧画面，如果模型推理一次要200毫秒以上，报警就失去了意义。我实测下来，YOLOv11的nano版本在CPU上能把单帧推理压到100毫秒以内，在GPU上更是能跑到几十毫秒。
另外一个关键点是，YOLOv11对“小目标”和“遮挡目标”的召回率有了提升。跌倒场景里经常会出现部分遮挡，比如人倒在沙发后面、被桌子挡住一半，老版本模型容易漏检，而YOLOv11在这些边缘情况下的表现更稳定。
这个项目不是只做一个模型就完事，它包含了完整的数据集、模型权重、登录注册界面和UI界面。换句话说，这是一个“能直接拿去交差或者二次开发的全栈项目”。我一开始接触这类项目时也觉得，算法工程师写前端界面是不是有点不务正业，但后来发现，如果做一个只有命令行输出的模型，场景方根本没法用。值班人员不可能去跑Python脚本看检测结果，他要的是一个能登录、能实时看画面、能收到报警弹窗的界面。
所以这个项目的整体设计思路就是：模型负责“看”，UI负责“用”，登录注册负责“管”。三者缺一不可。对于想学习目标检测全流程的开发者来说，这也是一个很好的综合练习项目——你不仅能学到YOLOv11的模型训练，还能了解怎么用Python把模型封装成一个桌面应用或Web应用，顺便把SQLite或MySQL的用户管理也过一遍。
1.1 跌倒检测的本质：从“检测到人”到“判断跌倒”
很多人第一反应是跌倒检测需要姿态估计，比如用OpenPose或者MediaPipe提取人体关键点。这个思路没问题，但复杂度高、部署重，而且姿态估计模型在低算力设备上跑不动。用YOLOv11做跌倒检测，走的是一条轻量务实的路线。
核心逻辑如下：检测模型先框出人体的边界框，然后根据边界框的特征来分类状态。一个站立或行走的人，边界框通常是高大于宽（竖直方向长），宽高比小于0.5；而当人跌倒躺下时，边界框会变成宽大于高（水平方向长），宽高比可能超过1.5甚至到2以上。这里的关键就是计算宽高比，然后设定阈值。
我在实际项目里常用的判断规则是：宽高比大于1.2且持续超过3帧，同时检测框中心点的垂直位移比正常站立时下降了超过某个比例，就判定为跌倒。为什么要连续多帧判断？因为单帧的异常可能是弯腰捡东西、蹲下系鞋带造成的，这些动作也会让宽高比变大，但人体还是保持一定姿态。连续几帧都出现异常宽高比，才能排除短暂蹲起的情况。
有些更细致的实现还会结合人体关键点，比如用YOLOv11的pose变体输出关节坐标，然后计算“躯干角度”——当躯干与地面的夹角小于30度，且头部高度低于髋部高度时，判定为跌倒。这种方式准确率更高，但模型体积和推理时间也会相应增加。做项目时我通常建议先用“边界框几何特征”的方案跑通流程，因为它的逻辑简单、容易调试，可视化也直观——你可以直接看到按宽高比画出的矩形旋转框或标注线。
1.2 项目文件结构的整体规划
一个合格的跌倒检测项目，文件组织要清晰，不然开发到一半你自己都会迷路。我通常这么规划：
DengDaoSystem/ ├── app.py # 主程序入口，启动UI和摄像头检测 ├── models/ # 模型权重存放目录 │ ├── yolov11n_fall.pt │ └── fall_detect.py # 模型推理封装 ├── datasets/ # 数据集存放目录 │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/ ├── ui/ # 界面模块 │ ├── login.py # 登录注册逻辑 │ └── main_window.py # 主检测窗口 ├── utils/ # 工具函数 │ ├── alert.py # 报警推送 │ └── logger.py # 日志记录 ├── requirements.txt └── README.md这个结构的好处是，模型推理、界面逻辑、业务功能各自独立，后续想替换模型或者升级UI都不用动其他模块。我之前见过一些人把所有代码写成两三个大文件，看起来工作量小，但一旦要加功能，改一处崩三处，得不偿失。
2. 数据集构建：YOLO格式的跌倒检测标注与样本平衡
数据是跌倒检测里最要命的环节。YOLO格式的数据集看起来简单，每张图片对应一个同名的txt文件，每行是“类别id 中心点x 中心点y 框宽 框高”，其中x、y、宽、高都是归一化到0到1之间的值。但真正做好这个数据集，需要处理的问题远比格式本身复杂。
第一个问题就是类别定义。朴实的方式是只标注两个类：person和fall。person对应所有站姿、走姿、坐姿的人，fall对应已经倒地的人。注意这里有个细节，坐在椅子上的人不是fall，蹲着的人也不是fall，他们的框虽然接近水平，但持续时间和姿态特征与真正的躺倒有差别。训练时模型看到的fall样本应该是真实的倒地姿态——平躺、侧卧、趴着、蜷缩倒地，而不是坐着或蹲着。
第二个问题是样本不平衡。在实际采集的监控视频里，99%的帧都是正常行走、站立、坐着的人，摔倒的画面非常少。如果用原始视频直接训练，模型会严重偏向person类，fall类根本学不出来。我见过的解决方案有两种：一是用数据增强（旋转、翻转、亮度变化、裁剪）来扩充fall样本；二是从公开的跌倒数据集中找素材，比如一些高校和实验室发布的跌倒检测公开数据集，里面有针对各种场景的跌倒视频帧。
第三个问题是标注质量。很多新手用LabelImg标注时会忽略一个细节：框要贴合人体轮廓，不能大概画。特别是跌倒的人，肢体展开幅度大，框如果只包住躯干而漏掉伸出去的手臂或腿，模型的回归损失就会变得不稳定。我习惯的标注策略是，框住整个人体轮廓的最外缘，哪怕有一截手指露出也没关系，但绝不能切割肢体。另外，模糊帧和小目标帧也要标注，不能只挑清晰的算，否则模型在低分辨率摄像头下会直接瘫痪。
2.1 数据集增强与预处理细节
在做这个项目的数据集时，我总结了一个“有效增强”清单。普通的目标检测任务用翻转和亮度调整就够了，但跌倒检测还需要考虑视角变化。摄像头可能是俯视、平视或斜视，如果你手里的素材全是平视角度，模型到了俯视环境就会失效。所以我建议在增强里加随机仿射变换，模拟不同摄像头安装角度。
另一个必须做的操作是Mosaic增强。YOLOv11训练时可以开启Mosaic，把四张图随机缩放后拼接成一张，这样模型就能学到在不同尺度下的目标形态。我训练时开了Mosaic，发现模型对小尺寸人像的检测提升非常明显——因为遥距摄像头里的人往往只有几十个像素高。
关于数据集规模的取舍，我实测下来，跌倒检测不用追求海量数据。一个类别是person，一个类别是fall，只要fall样本数量达到3000到5000张，分布覆盖室内、室外、不同光照、不同穿着，模型就已经能有不错的泛化能力。核心在于样本的“差异度”，而不是无脑堆数量。全部素材都来自同一个场景同一个摄像头角度，哪怕2万张也是白搭。
2.2 标注后处理：划分训练集与验证集
标注完成后，别急着训练。按8:2或9:1的比例划分训练集和验证集时，要注意一个容易犯错的点——避免同源视频帧同时出现在训练集和验证集里。如果连续帧被分到两边，验证集的指标会虚高，因为模型其实已经“见过”这些画面了。
我的做法是：先按视频序列或录制时间段分组，然后以组为单位划分。这样验证集里出现的是模型从未接触过的独立片段，评估出的mAP才有参考价值。划好后可以用一些脚本自动统计各类别的数量分布，确保训练集和验证集中person与fall的比例大致相同。我在项目中习惯跑一个简单的Python脚本统一检查标注格式，比如确认坐标没有越界、类别id是否正确、有没有空的txt文件。标注格式里哪怕有一处坐标值为负数或大于1，训练时会产生NaN损失，直接让你的训练过程报废。
3. 模型训练与部署：从YOLOv11训练到推理封装
3.1 训练环境配置与超参数调整
YOLOv11的训练环境配置，本质上和之前版本一样。需要PyTorch、CUDA、GPU驱动，这些是基础。我用的是PyTorch 2.x配合CUDA 11.8或者12.1的版本，顺手把训练前的硬件检查也说明一下——有了GPU训练速度能提升一个量级，没有显卡就要考虑用CPU或云端平台。
训练命令方面，官方仓库的train.py可以直接使用，但在跌倒检测这个场景下，有几个超参数值得特别调整。首先是batch size，这决定了单次前向传播的图片数量，内存占用也跟着成倍增长，需要根据显存实际大小来设置。其次是epoch，大概跑150到200轮就够了，跑太多会出现过拟合——训练损失还在降，但验证集mAP已经不涨甚至下跌。这时候就要看模型的泛化能力，而不是训练集的完美拟合。
我最看重的是三个指标：fall类别的精度和召回率，以及整体的mAP50。精度决定了系统报一次警有多少是真正跌倒，召回率决定了真的有跌倒发生时系统能不能发现。做安全监控场景时，宁可精度低一点让系统多报几次误警，也不能让召回率太低漏报一次真正的摔倒。所以训练时我会把fall类的置信度阈值设得偏低，让模型倾向于检出端到端的异常姿态。
训练过程中的监控也别忽略。建议每训练几轮就在验证集上测试几张样本，把检测可视化结果保存下来，直接看模型有没有学到“躺在地上的人”这种特征。如果模型把坐在地上的人识别成fall，那说明训练数据里坐姿样本太少，需要补充负样本去压制这种误判。我曾经在训练时发现模型对“站在床边”的人误报跌倒，后来排查发现是数据里床旁边的站立样本分布少，模型直接把靠近床铺的竖直框理解成了上下文异常。
3.2 模型导出与推理速度优化
训练完成后，模型文件通常是一个.pt格式的PyTorch权重，但实际部署时直接用.pt有点浪费。YOLOv11提供了模型导出功能，我通常会导出成两个版本：一个还是.pt方便做二次开发和调试，另一个导出为ONNX或者TensorRT格式用于实际推理。在CPU设备上用ONNX配合OpenVINO推理，速度能比原始PyTorch翻几倍；有NVIDIA显卡的话TensorRT的加速效果更明显。
推理这一块，代码逻辑也不复杂。加载模型后，对每一帧画面做预处理——缩放、归一化、转Tensor——然后送入模型，输出是一个张量，包含预测框坐标、置信度和类别。对输出做非极大值抑制（NMS），保留置信度最高的框，然后按前面说的宽高比规则去判断是否跌倒。这里有个细节：如果视频流分辨率很高比如1080p，可以先缩放一半再做检测，因为跌倒检测的目标是人，不需要检测眼镜这种小物件，降低分辨率后推理速度能提升不少，精度损失却很小。
3.3 跌倒判断逻辑的工程化实现
判断逻辑说起来简单，但在工程里要做得稳定需要一个稍完整的状态机。我实现的是这样一套流程：
每一帧检测出人的边界框后，计算宽高比ratio。如果ratio大于某个阈值比如1.5，且持续超过N帧（通常3到5帧），就进入“疑似跌倒”状态。此时启动一个计时器，如果在接下来的时间内，该框依然保持水平姿态且中心点没有明显移动，就正式触发报警。为什么要求“中心点没有明显移动”？因为如果人倒地后还在爬动，说明他可能有意识，紧急程度低一些；如果倒地后完全不动，大概率是晕厥或受伤，需要立即告警。
报警信号触发后，UI界面会把检测框标记成红色，同时弹出警告文字，语音播报一下，再把报警截图保存到本地日志目录。时间信息、置信度、跌倒前后几帧的画面都要记录下来，方便事后复盘。
注意：这个状态机逻辑看着简单，但真正难的是阈值调优。阈值太高会漏报，阈值太低会频繁误报吓到值班人员。我建议上线前拿几段真实监控视频做离线回放测试，统计误报率和漏报率，再针对性地调整连续帧数和宽高比阈值。
4. UI界面与登录注册模块：把模型包装成完整系统
很多做算法的人对PyQt或者Tkinter不屑一顾，但我要说，这个项目如果少了UI，价值直接砍半。跌倒检测系统是要给值班人员用的，他们不会Python，也不想看黑底白字的命令行。一个合格的界面至少要包含三块：视频显示区域（可以实时预览摄像头画面或者回放视频文件）、检测结果面板（显示当前画面中有几个人、是否有跌倒报警、最近一次报警的时间）、操作控制区（开始/停止检测、选择视频源、调节置信度阈值）。
我建议UI框架用PyQt5，因为它的布局灵活，摄像头画面可以用QLabel实时刷新，报警弹窗可以用QMessageBox，多线程用QThread。帧率这点可以从卡顿问题说起，如果在UI线程直接做模型推理，界面会卡成幻灯片，所以必须把推理放到后台线程，推理完成后再把结果帧回调给UI线程刷新显示。
4.1 登录注册功能的设计与实现
登录注册模块是这个系统里容易被小看的部分。它解决了“谁能看这个系统”的问题。在养老院或者工地场景里，不是任何人都能查看监控画面、确认报警信息的，所以一个基础的账号体系是必要的。
我在项目里用SQLite做数据库，因为一套桌面应用带着一个嵌入式数据库最省事，不需要额外安装MySQL服务。数据库里建一张user表，字段包括id、username、password_hash、create_time。密码不能存明文，这是底线。我用的是hash加盐的存储方式，登录时比对哈希值，即使数据库文件被人拷走，也无法直接看到密码。
注册逻辑需要注意一个细节：用户名唯一性校验和密码强度校验。我做的校验规则是密码至少6位，必须包含字母和数字。这不算苛刻，但能挡住最简单的弱口令攻击。登录成功后，界面跳转到主检测窗口，同时把当前用户名传递过去，这样报警日志里可以记录“是谁处理了这起报警”，事后如果想追责或复盘也有据可查。
4.2 UI布局与报警联动
主界面布局我是按上中下三段设计的。最上面是工具栏，放“开始检测”“停止检测”“选择视频”和“报警设置”按钮；中间左侧是视频画面的实时显示，右侧是检测信息的实时列表；最下方是状态栏，显示当前模型推理耗时、帧率、检测到的人数。
报警联动这里，我除了在界面上弹窗、变色、截图保外，还加了一个可选的音频播放功能。用PyQt5自带的QSound播放提示音，不需要额外引入音频库。如果是部署到远程监护场景，还可以通过网络协议往服务端推一条报警记录。不过在项目源码里，我一般默认只做本地报警，因为如果服务器不稳定，报警消息丢失反而比不报警更糟。这属于基础能力——前提是报警必须绝对可靠，权限不足宁可不做。
经验提示：UI界面开发最耗时的地方不是布局，而是“摄像头打开-推理线程-界面刷新”这三者之间的协作。Qt里子线程不能直接更新UI组件，必须通过信号和槽机制传递结果帧。新手最容易在这里报“segmentation fault”或者界面无响应，原因就是试图在推理线程里直接调用label.setPixmap()。
5. 实际运行中的常见问题与排错记录
5.1 模型训练时Loss出现NaN
这个问题我在训练YOLOv11时遇到过两次。现象是训练前几轮loss正常，跑到十几轮突然出现NaN，然后loss永远回不来了。排查下来原因通常是两种：批次里有标注异常的图片（坐标值为负数、框宽高为0，或者类别id超出类别数），以及学习率设置过大导致梯度爆炸。
解决方法是：先写一个数据检查脚本，遍历所有标注文件，把异常标注直接剔除；然后把初始学习率调低，从0.01降到0.005，同时开启warmup让模型先适应一下。处理完这两步再重新训练，问题基本消失。
5.2 推理时检测框剧烈闪烁
这是跌倒检测系统最影响体验的问题之一。原因为单帧检测结果不稳定，这一帧检测到人，下一帧丢了，导致框忽隐忽现。解决它有两个办法。一是调低置信度阈值，让模型更容易检测到人，但这样也会增加误检；二是加一个简单的跟踪逻辑，用IoU把相邻帧的同一个目标关联起来，目标短暂丢失时用上一帧的框位置做平滑过渡。不需要用到特别复杂的跟踪算法，卡尔曼滤波或者简单的最近邻匹配在单目标场景下就很好用。这里建议直接用代码实现最简版跟踪，没有必要一上来就部署一个完整框架。
5.3 CPU推理太慢，帧率只有3到5
如果没有GPU，CPU跑YOLOv11的高版本模型确实吃力。我实测过一个3050Ti的笔记本，CPU模式下YOLOv11n的推理耗时大概在150到250毫秒，也就是4到6帧的样子。如果视频流是25帧每秒，这个速度完全跟不上。
这时候有两个优化方向。一是导出成ONNX格式再用OpenVINO推理，同样的CPU，推理时间能缩短到80到120毫秒。二是把输入尺寸从640降到416，这样计算量会减少差不多一半，跌倒检测的精度损失在可接受范围内。另外，在推理线程里要保证帧率控制，检测用的帧数只要每秒不超过5帧就行，中间直接跳过未处理的帧。对跌倒检测来说，人倒地的过程少说也有半秒钟，4到5帧的检测频率完全够用。
5.4 误报和漏报该如何权衡
误报率高会让系统的报警在值班人员眼里失去可信度，狼来了喊多了，真的倒下反而没人管了。漏报则直接导致系统失效。这个平衡必须结合使用场景来定。
我的经验是：对于非紧急场景，比如居家监护，可以设置连续5帧以上的异常才报警，降低日常活动引起的误报；对于紧急场景，比如独居老人浴室，可以设置连续3帧就报警，宁可多报几次也不能漏掉一次。这些阈值应该做成界面上的可调参数，而不是写死在代码里，这样现场人员可以根据实际反馈动态调整。
6. 扩展方向：从实验室Demo到真正可落地的产品
这个项目如果只停留在“能跑通”的阶段，其实还是有点浪费。我个人经验里，有几个扩展方向值得思考一步。
第一个方向是增加音频事件检测。跌倒发生时往往会伴随撞击声、呼救声，把音频特征和视觉特征做多模态融合，能显著降低漏报率。这个想法看起来要加麦克风阵列，复杂程度不小，但可以先从简单的“音频能量突刺”做起。当UI同时收到视频报警和音频异常信号时，报警等级自动提升，这个增强逻辑不复杂，做出来效果却很明显。
第二个方向是数据闭环。系统每次报警后保存的截图和视频片段，收集一段时间后可以重新标注、重新训练模型，形成数据飞轮。很多实际场景里的罕见跌倒姿态，公开数据集里根本没有，只能靠系统自己积累。我把这称为“越用越准”的系统，而不是上线后模型就永远不变了。
第三个方向是边缘设备部署。YOLOv11n的模型经过量化剪枝后，体积能做到十几MB甚至更小，理论上可以部署到树莓派或嵌入式设备上。这样摄像头端本地推理，只有触发报警时才有网络流量上送，隐私性也好，实时性也好，部署成本都优于纯云端方案。这也是跌倒检测系统从“项目”变成“产品”的必经之路。
我在做这个项目的过程中，最大的感触是：深度学习模型只是其中最确定的一块拼图，真正决定系统好不好的，是对数据质量的把控、对误报漏报的权衡、对界面交互细节的打磨。一个跌倒检测系统，模型部分的代码可能只占20%，剩下80%的工作都在解决“实际场景里怎么用得住”的问题。
如果你已经跟着思路把项目跑通了，我建议下一步别急着换模型架构，先拿自己手机拍几段不同角度的模拟跌倒视频，丢到系统里测一测。你会发现非常多有意思的边界情况——有些你以为没问题的规则，实际一测就露馅了，而这个过程积累下来的认知，比训练一万个模型都值钱。
