简介面向目标检测与计算机视觉学习者这套基于yolov5的人员跌倒检测资源整合了预训练模型、标注数据集与完整源码覆盖从数据准备、模型训练到测试应用的全流程适合快速上手yolo系列实战也可用于智慧养老、安全监控等场景的跌倒识别方案预研。压缩包共331个文件、约207.91MB主要包含jpg图像样本、py训练脚本、yaml模型配置、pt权重文件、mp4测试视频以及txt标注信息等便于对照理解每个环节。已有310人学习下载。数据集提供跌倒场景的图像与边界框标注源码内置训练参数配置以及优化器、损失函数设置预训练模型可直接基于测试视频验证效果同时附带的训练日志和csv结果有助于分析mAP、召回率等指标。整体目录结构清晰适合具备一定Python和深度学习基础的读者用于课程设计、算法实验或实际监测需求的二次开发。1. 基于YOLOv5训练人员跌倒模型拆包后为什么先看数据集而不是先跑训练市面上的YOLOv5跌倒检测资源并不少但很多下载下来要么数据集零散、标注格式混乱要么源码和配置对不上能一口气跑通全流程的很少。这份资源包把图片数据集、txt标注文件、训练推理源码和预训练权重整理在一起目标是让拿到手的人能直接训练出可用的跌倒识别模型。真正动手前我建议你先花十分钟检查数据目录因为YOLO训练吃的是归一化坐标的txt标注类别编号、坐标顺序一旦和配置文件错位后面训练出来的模型基本是废的。它适合做监控告警、老人看护、边端行为识别一类场景也适合想照着完整流程入门YOLOv5做目标检测的开发者。2. 数据包内部结构目录规划、标注格式与版本匹配跌倒检测看起来是目标检测的常规应用真正做起来才会发现模型结构大家都熟数据集标注口径才是决定成败的地方。这个资源包解压后目录规划和标注文件的组织方式决定了你后续训练脚本怎么改、验证脚本怎么跑。这一章先把包里的东西拆清楚。2.1 目录结构与核心文件的作用解压之后你首先会看到一个按YOLO惯例组织的目录树常见的大致如下fall_detection/ ├── data/ │ └── fall.yaml # 数据集配置路径、类别数、类别名 ├── datasets/ │ └── fall/ │ ├── images/ │ │ ├── train/ # 训练图片 jpg │ │ └── val/ # 验证图片 jpg │ └── labels/ │ ├── train/ # 训练标注 txt │ └── val/ # 验证标注 txt ├── weights/ │ └── yolov5s.pt # 预训练权重 ├── train.py # 训练入口 ├── detect.py # 推理入口 ├── val.py # 验证入口 ├── export.py # 模型导出入口 └── runs/ # 训练输出目录这个结构里fall.yaml是整个训练配置的枢纽。它决定了训练脚本去哪里找图片、找标注以及模型输出层有多少个类别。如果这个文件和 datasets 目录的位置对不上训练会直接报错或者训练后模型行为很怪。YOLOv5的需要其实就三类源码、权重、数据和配置。源码通常沿用社区通用版本train.py、detect.py 这类入口文件不需要大改权重决定训练从什么基础开始数据集决定模型能学到什么fall.yaml则把三者串起来。我先做的一件事是打开fall.yaml确认类别数量和类别名再统计一下标注文件里到底有哪些类别编号两边对得上才继续。文件/目录作用常见问题datasets/fall/images训练验证图片图片损坏或格式混杂datasets/fall/labels对应的 YOLO 格式标注标注缺失或文件为空weights/yolov5s.pt预训练权重权重文件损坏或版本错配data/fall.yaml数据集配置路径写错、类别数不对2.2 数据分布决定模型上限跌倒样本与干扰样本的比例打开 labels/train 下的任意一个 txt 文件一行代表一个目标框格式是类别编号 中心点x 中心点y 框宽度 框高度所有坐标都是相对于图片宽高的归一化值范围在 0 到 1 之间。这是 YOLO 系列的标准标注格式。比如某一张图里有两个目标标注文件可能是1 0.4531 0.3204 0.0962 0.1187 0 0.5214 0.5833 0.0881 0.3155第一行是类别 1第二行是类别 0。我习惯写一个脚本统计所有标注里的类别分布思路很简单读取每个 txt 文件记录每行第一个字段出现的次数。这个包如果按person和fall两类来标注那么类别 0 通常是正常状态的人类别 1 是跌倒状态的人。两者比例接近 1:1 或负样本略多训练起来会比较稳。如果 fall 的样本数远多于 person模型会倾向于把所有躺着的人都框成 fall反过来如果 person 太多模型可能对跌倒样本召回不足。数据里另一个容易忽略的点是跌倒姿态本身的多样性。比如正面跌倒、侧身跌倒、被遮挡的跌倒如果数据集里全都是固定视角下的相似样本模型在换一个摄像头角度后就很难保持准确率。这个资源包如果包含了多角度、不同光照的样本那还好如果发现所有图片几乎来自同一个机位建议训练完务必拿另一路监控画面做验证。2.3 预训练权重与源码版本先对号入座再动手YOLOv5 在不同阶段演进很大早期版本和后期版本在模型结构、anchor 设置、训练策略上都有差别。一个常见的翻车现场是源码版本较新权重却是旧版加载时提示权重键名不匹配或者直接报错。我一般先看权重文件的体积来判断基础模型大小。yolov5s.pt通常在 14MB 左右yolov5m.pt在 40MB 左右yolov5l.pt在 90MB 左右。s 模型训练快、推理快适合边端部署m 和 l 精度更高但需要更大的显存和更长的训练时间。然后检查源码版本常见做法是运行python -c import yolov5; print(yolov5.__file__)或者直接看源码目录里是否有models/yolo.py、utils/general.py这些固定文件并观察train.py的参数列表来判断。不同大版本的训练参数名会有差异比如--img-size改名为--img如果你直接用网上拷贝的旧命令跑新版本代码很可能因为参数名不识别而报错。对号入座的另一个细节是fall.yaml里的nc和names必须一致。如果配置里写了两类权重加载时会自动调整输出层但如果你拿的是官方 COCO 预训练权重80 类第一次训练时 YOLOv5 会重新初始化输出层这是正常行为不是报错。3. 训练一个可用的跌倒检测模型环境、参数与训练监控目录、数据、版本都确认没问题后才进入真正的训练环节。这里说几个我实际跑下来的经验环境搭错的概率不低参数选择决定训练结果训练过程能不能看懂决定了你有没有后悔药可吃。3.1 环境准备依赖安装与 GPU 环境确认YOLOv5 的依赖核心是 PyTorch、OpenCV、numpy 这几个版本匹配是头等大事。PyTorch 版本太新或太旧都可能和源码里的某些接口对不上。我习惯先新建一个干净的虚拟环境避免污染其他项目conda create -n fall_yolo python3.9 -y conda activate fall_yolo cd 资源包解压目录 pip install -r requirements.txtrequirements.txt 里通常包含 torch、torchvision、opencv-python、numpy、matplotlib、pyyaml 等。注意一点如果机器有显卡建议先确认驱动版本再安装对应版本的 PyTorch否则安装默认 CPU 版 torch 后训练会慢到怀疑人生。确认 GPU 可用python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))输出 True 表示 GPU 可用False 就需要检查显卡驱动和 PyTorch 的 CUDA 版本是否匹配。CPU 也不是不能跑只是训练时间会翻倍batch 也要调小。3.2 训练参数batch、epoch、imgsz 到底怎么定YOLOv5 官方默认训练参数有很多讲究。训练脚本的核心参数是 batch-size、epochs、img。先给一份能直接用的训练命令python train.py \ --data data/fall.yaml \ --weights weights/yolov5s.pt \ --epochs 120 \ --batch-size 16 \ --img 640 \ --device 0 \ --name fall_exp参数说明--data指向数据集配置文件train.py 会从这里读取训练集、验证集路径和类别数。--weights指定预训练权重这里用 yolov5s.pt 做初始权重迁移学习最快。--epochs训练轮数。120 轮是跌倒检测比较稳妥的起步值如果数据集小50 到 80 轮就可能收敛但轮数太少会影响拟合。--batch-size每次送入 GPU 的图片数。16 是一个起步值如果显存不足降到 8 或 4。--img训练输入尺寸。640 是速度和精度的常见平衡点如果跌倒目标较小可以试 960 或 1280但显存消耗会显著上升。--device指定 GPU 编号0表示第一块显卡没有 GPU 就写cpu。--name训练输出项目的名称最终产物会在 runs/train/fall_exp 下。关于 batch 和 img 的选择我的经验是在显存允许的前提下batch 尽量大因为 YOLOv5 的 batch 和初始学习率有联动逻辑batch 太小而学习率偏大时loss 曲线会剧烈震荡。这里补充一下--batch-size 16和--epochs 120不是金标准如果数据集只有几千张64 轮甚至 32 轮也能收敛如果模型部署在边缘设备上建议从 320 或 416 的推理尺寸开始评估精度而不是一上来就用 640。如果想看更多可调参数可以运行python train.py --help输出会列出全部参数包括--cos-lr、--mosaic、--label-smoothing、--patience这类进阶项。前期不要一次性开太多容易叠加出不可控的问题。3.3 训练过程怎么看日志、loss 走势与权重选择训练启动后终端会每隔一段打印一次结果包含当前的 batch、box loss、obj loss、cls loss 和 mAP 曲线。很多人第一次跑会盯着那几个 loss 数值看到它们上下波动就觉得模型坏了。这是误区loss 波动很正常你真正要看的是整体趋势前 20 轮 loss 下降明显之后缓慢收敛最终趋于平稳。训练结束runs/train/fall_exp/weights 下会出现两个文件best.pt验证集 mAP 最高的权重。last.pt最后一轮的权重。我通常先拿best.pt做推理测试如果 best 和 last 的性能差距很大说明训练后期出现了过拟合或学习率策略问题需要回看日志。在训练日志里还有几个容易被忽略的指标P和R代表精确率和召回率。跌倒检测应用里召回率比精确率更重要——漏报一次跌倒比误报几次严重得多。如果训练结束时R明显低于P我一般会回训练阶段把置信度阈值降低或者补充跌倒样本数据。4. 推理实战图片、视频和摄像头输入的配置差异训练产出的 best.pt 只是模型把它放到真实输入流里才是完整的检测链路。YOLOv5 的 detect.py 对三种常见输入——单张图片、录好的视频、摄像头实时流——的命令差别不大但每个场景下的参数选择逻辑很不一样。4.1 单张图片跑通检测链路先用单张图片验证模型是否工作这是排查一切后续问题的最快路径python detect.py \ --weights runs/train/fall_exp/weights/best.pt \ --source data/test.jpg \ --conf-thres 0.45 \ --iou-thres 0.5 \ --img 640 \ --save-txt \ --project runs/detect \ --name fall_test参数说明--source可以是图片路径、视频路径或者摄像头设备号。--conf-thres置信度阈值默认 0.25。0.45 表示模型只有自信程度超过 45% 才会框出来。阈值越高误检越少但漏报风险也越高。--iou-thresNMS 的交并比阈值0.5 是常用值。它控制两个重叠很高的框是否被合并。--save-txt额外保存检测结果的 txt 文件方便跑批量验证时统计结果。--project和--name控制输出目录避免每次运行把结果混在一起。检测结果会输出到 runs/detect/fall_test 下图片上会画好框。如果跌倒的人和正常站立的人都被标成同一个类别那要回去看数据配置如果只看到 person 没有 fall大概率是模型还没学会区分。4.2 视频推理结果输出与性能监控视频推理和图片推理的差异主要在输出组织上。命令如下python detect.py \ --weights runs/train/fall_exp/weights/best.pt \ --source test_room.mp4 \ --conf-thres 0.4 \ --img 640 \ --save-vid \ --save-txt视频输入时YOLOv5 默认按帧处理检测后会把框绘制到每一帧上。--save-txt会为每一个有检测到的帧生成一个结果文件如果你不需要逐帧标注文件就别加这个参数否则运行几分钟会产生几百个小文件。视频推理最容易出现的问题是处理速度跟不上视频帧率。如果视频是 30 帧每秒而你的显卡推理只能跑到 15 帧每秒输出视频会变慢或者产生跳帧。这时优先把--img从 640 降到 416再把--conf-thres稍微调高减少后处理阶段的候选框数量。4.3 摄像头实时检测参数和场景的适配把模型接到摄像头是最接近真实部署的一环命令很简单难点在阈值和帧间逻辑python detect.py \ --weights runs/train/fall_exp/weights/best.pt \ --source 0 \ --conf-thres 0.55 \ --view-img \ --img 416这里--source 0表示本地第一个摄像头--view-img直接弹窗展示检测画面。我把置信度阈值提到了 0.55因为摄像头画面的动态模糊和光照变化会让模型对跌倒这种动作产生更多不确定性。实时场景里要注意摄像头画面的构图会影响模型泛化能力。训练数据如果大多是宽视角、从上往下拍的监控画面而你在测试时把摄像头放在平视角度误检率会明显上升。我建议即使是快速验证也先录一段现场视频跑推理而不是一直用图片测试。5. 避坑从训练到落地最容易翻车的五个问题这套流程我陪不同的人跑过很多轮训练和推理阶段翻车点基本集中在这五个地方。每一条都按“现象 → 原因 → 解决”讲清楚对照排查会快很多。5.1 标注文件有问题导致 Loss 异常或直接报错现象训练到一半 loss 突然变成 inf 或 nan或者训练结束 mAP 始终在 0.01 附近。原因labels 目录下的 txt 标注里出现了越界坐标、空文件、字段数不对或类别编号超出配置的 nc 数量。YOLO 对标注格式要求很严格一个小错误会让整张图的 loss 贡献出问题。解决先用脚本扫描一遍标注文件发现坏文件及时修正或剔除。参考代码如下from pathlib import Path label_dir Path(datasets/fall/labels/train) nc 2 # 类别数对应 fall.yaml for label_file in label_dir.glob(*.txt): lines label_file.read_text().strip().splitlines() if not lines: print(f{label_file}: 空标注) continue for i, line in enumerate(lines): parts line.split() if len(parts) ! 5: print(f{label_file} 第{i1}行 字段数错误) continue cls int(parts[0]) if cls 0 or cls nc: print(f{label_file} 第{i1}行 类别越界) coords list(map(float, parts[1:])) if not (0 coords[0] 1 and 0 coords[1] 1 and 0 coords[2] 1 and 0 coords[3] 1): print(f{label_file} 第{i1}行 坐标越界)扫描后需要看两端结果如果只有零星几个坏标注直接删掉对应 txt 文件或修正该行即可如果大量标注都有问题那说明标注工具导出坐标没有做归一化需要重新整理。5.2 误把正常动作当跌倒负样本不足现象部署后频繁把弯腰捡东西、蹲下系鞋带、甚至正常走路时手部遮挡检测为跌倒。原因数据集中只标注了“跌倒”这个正样本却几乎没有“蹲下”“弯腰”“坐到地上”这类易混淆的负样本。模型学到的不是“跌倒”而是“人在画面中姿态发生变化”。解决如果资源包内数据不足先从现场收集一周左右的监控画面把蹲下、弯腰、坐地等动作单独抽出一部分样本标注成另一类别或作为背景负样本混合进训练集。我在一个车间项目里加了约 800 张“蹲下”图片后误报率直接降了一半。如果不想重新标注也可以把 conf 阈值从 0.45 提高到 0.6但这只是缓解不能根除。5.3 单帧检测不稳定的抖动问题现象视频推理时跌倒框时而出现、时而消失一秒钟内掉帧几次就误报一次。原因单帧检测本质上是独立判断跌倒姿态在画面中会出现自遮挡、模糊、光照突变模型的可信度会在相邻帧间大幅波动。只看一帧就触发告警必然抖动。解决不要用单帧决定是否报警改成滑动窗口。连续 3 到 5 帧里至少有 3 帧检测到 fall才确认跌倒事件。这个思路我在下一章会写成一个可直接用的判断类。5.4 验证集 mAP 很高换现场画面效果却很差现象val.py 跑出 0.92 的 mAP但拿到部署点位真实摄像头录的几分钟视频测试漏检、误检都很严重。原因模型过拟合了训练集的拍摄角度、光照条件和画面尺寸。特别是跌倒检测数据如果来源单一比如全是同一个摄像头从高处俯拍模型到了平视视角的新环境就明显退化。解决mAP 只是参考部署前唯一可信的是现场数据回放测试。我在每个点位都会用真实摄像头录至少 20 分钟的带标注片段回放检测并逐帧统计误报和漏报再反推阈值调整。如果现场画面和训练集差异实在太大最实际的办法是补充现场图片微调模型。5.5 导出 ONNX 后推理报错或结果不对现象用 export.py 转 ONNX 后拿 ONNX Runtime 推理得到的输出老是不对要么没有框要么框坐标错乱。原因YOLOv5 的检测头里包含 anchor 解码和 NMS 后处理直接导出 ONNX 默认不含 NMS 逻辑输出是原始特征图张量。如果推理代码直接读取三个输出并当最终框用必然出错。解决导出时使用官方 export.py 并带上--include onnx参数推理端可以用官方提供的 YOLOv5 ONNX 推理脚本做基准如果要在自己代码里跑常见做法是手动实现 decode NMS或者借助 ONNX Runtime 的 NMS 自定义算子。不要省这一步否则模型的输出维度都会让你蒙圈。6. 让模型真正可用帧间投票与部署验证的顺序把模型接进实际场景前有一步很多人会跳过帧间判定逻辑。单独一帧检测到 fall不等于画面里的人真的跌倒了。我之前做一个看护场景项目模型在测试集上表现很好装到现场之后第一晚误报了三次其中两次是老人弯腰整理床铺一次是光线突然变暗。后来我把单帧判定改成滑动窗口投票误报才稳下来。核心思路很简单不要用一帧的置信度做决断而是维护一个最近 5 帧的检测结果窗口只有窗口内超过阈值的帧数达标才确认跌倒事件。代码片段如下class FallVoteDetector: def __init__(self, window5, need_hit4, conf_thr0.5): self.window window self.need_hit need_hit self.conf_thr conf_thr self.history [] # 保存最近若干帧的置信度 def update(self, conf): # conf 为当前帧最高检测框的置信度无检测则填 0 self.history.append(conf if conf else 0) if len(self.history) self.window: self.history.pop(0) hits sum(1 for c in self.history if c self.conf_thr) return hits self.need_hitwindow5表示观察最近 5 帧need_hit4要求其中 4 帧都检测到跌倒才触发conf_thr和推理置信度保持一致。这样即使某一帧因动作模糊漏检只要前后帧稳定仍然能正确触发反过来偶发的一次高分误检也不会立刻造成告警。从那以后我每次部署跌倒检测模型都会强制走一遍三步验证先拿现场摄像头录像回放测试至少二十分钟再看误报集中在什么动作上决定要不要补样本最后用帧间投票逻辑上线并保留一周检测日志复盘。这套流程帮我躲过了不少坑。希望帮到你。本文还有配套的精品资源点击获取