简介：这套基于YOLOv7的跌倒检测方案，以Python为主要开发语言，面向人工智能初学者、高校学生及安防项目开发者，用于解决公共区域、养老机构与家庭场景下的跌倒实时识别问题。压缩包共20个文件，包含17张用于效果展示与训练过程可视化的PNG图片、1个用于目录管理的Python脚本、1份Markdown格式的教程文档和1个TXT说明文件，整体大小仅14.9MB，结构精简易上手。目前已有199人学习下载，可用作毕业设计、课程项目或目标检测实战的参考资料。资源提供了可直接运行的源代码、配套跌倒数据集与完整教程，覆盖数据收集、预处理、模型训练、评估优化、系统集成等环节，同时附有实用的目录管理脚本等辅助工具，能够帮助读者快速理解YOLOv7在人员跌倒检测中的实际部署流程，具备较高的学习价值。
1. 跌倒检测为什么要用 YOLOv7：先看清方案边界
做人员跌倒检测的人，多半是被同一个问题逼过来的：家里老人或独居者摔倒后无法呼救，或者公共场所倒地没人及时发现。传统监控只能事后看录像，而基于Python的YOLOv7人员跌倒检测系统要解决的，是把「倒地」这件事从画面里实时捞出来，触发告警。整套方案包含三块：YOLOv7目标检测框出人体、姿态或位置逻辑判断是否跌倒、外围脚本完成告警和录像。
这类项目在GitHub上要么是纯学术演示，要么是半成品，真正能跑通训练、推理、部署全流程的很少。标题里带「源代码&教程&数据集」的往往意味着作者把踩过的坑提前填了。但这个方向能不能落地，取决于三个前提：你的摄像头视角是否俯视或侧视、检测频率能不能到 10 FPS 以上、以及你是否愿意花时间标注属于自己的跌倒样本——通用模型几乎不可能直接用在养老院或医院的真实场景里。
新手能从这个方案里学会完整的 YOLO 训练闭环，熟手则能拿到数据增强和跌倒逻辑判定的参考。我下面按「为什么选 YOLOv7 → 数据集怎么做 → 训练参数怎么调 → 跌倒判定怎么写 → 部署坑在哪」的顺序讲，全程给可复现的命令和代码。
2. YOLOv7 的模型选型与跌倒检测的数据标注策略
2.1 为什么是 YOLOv7 而不是 YOLOv5 或 YOLOv8
跌倒检测本质上是单阶段目标检测 + 行为判别的组合。YOLOv5 生态成熟但网络结构偏老，YOLOv8 的 Anchor-Free 设计虽然在新数据集上指标好看，但在小目标（比如远距离的倒地人体）上反而需要更多调参。YOLOv7 正处于一个微妙的平衡点：它保留了 Anchor-Based 的回归方式，对长宽比极端的倒地人体（横躺时宽高比可能达到 3:1 甚至 4:1）先天敏感，同时它的 E-ELAN 结构在同样显存下比 v5 能推更高的批大小，这对训练速度和稳定性都有实际意义。
还有一层现实原因是代码生态。YOLOv7 的官方仓库至今保持着较完整的训练、测试、导出脚本，很多跌倒检测的开源项目都基于它二次开发，遇到问题能搜到大量同类讨论。v8 虽然新，但相关跌倒检测数据集和权重大多是 v7 时期积累的，拿 v8 从头训反而要花更多时间在格式转换和超参搜索上。
我一般建议：如果你的目标设备是 Jetson Nano、树莓派这类边缘盒子，选 YOLOv7-tiny；如果服务器有 8G 以上显存，选 YOLOv7 基础版。跌倒检测不需要识别几十个类别，单类 human 就够，模型容量不是瓶颈，推理速度和稳定性才是。
2.2 跌倒数据集的三种来源与标注规范
标题里提到「数据集」，我默认指的是能直接用于 YOLO 格式训练的人体标注数据。实际做法上，数据集有三种来源。第一种是公开数据集，比如 UR Fall Detection、Le2i Fall Detection，这两个是老牌跌倒数据集，但有个通病——场景单一，摄像头角度固定，样本量几百到一千出头，直接训练很容易过拟合。第二种是自己采集 + 人工标注，这是最推荐的方式，因为最终部署场景的摄像头角度和光照只有你自己的数据能覆盖。第三种是在公开数据集基础上做增强扩充，比如对 UR Fall 做左右翻转、亮度扰动、随机裁剪，把样本量翻到 2000 张以上。
标注规范上，跌倒检测和普通行人检测有一个关键差别：跌倒时人体是横躺或半躺的，标注框的宽高比和站立时完全不同。我习惯用 LabelImg 或 LabelStudio 标注，类别只写一个 fall，框必须紧贴人体轮廓，不要把地面阴影或旁边的椅子框进去。特别提醒：半躺和蹲下的边界非常模糊，标注时如果拿不准就统一按非跌倒处理，否则模型会学到错误的决策边界。
# 用 LabelImg 标注后，确认 VOC 格式转 YOLO 格式的脚本输出 # 每行格式: class_id x_center y_center width height (归一化) # 例如一个跌倒样本：0 0.5123 0.6842 0.3124 0.1856 python voc_to_yolo.py --voc_dir ./Annotations --yolo_dir ./labels这段脚本的作用是把 XML 标注转成 YOLO 训练需要的 txt 文件。注意x_center和width必须除以图片宽度，y_center和height除以高度。我踩过的坑是横躺人体的高度方向维度很小，归一化后接近 0.1，如果程序里用int()而不是float()处理，数值会直接变成 0，导致训练时大量标注失效。
2.3 数据划分：跌倒检测不能随机划分
普通目标检测随机划分训练集验证集没问题，但跌倒检测必须按「视频片段」划分，而不是按「帧」划分。因为同一个视频片段里相邻帧高度相似，随机划分会导致模型的验证精度虚高——它在验证集里看到的画面，几乎在训练集里见过同场景的相邻帧。我一般按完整视频或连续动作段划分，训练集:验证集:测试集 = 7:2:1，并且保证同一个人的跌倒动作不会同时出现在训练和验证里。
另外一个实操细节是样本均衡。跌倒样本在真实场景中是稀有事件，公开数据集里跌倒帧可能只占 30%~40%，其余全是正常行走、坐、弯腰。如果直接用原始比例训练，模型会把所有检测都偏向「非跌倒」。我的做法是训练时把跌倒帧和非跌倒帧按 1:1 采样，多余的非跌倒帧直接丢弃，让模型的注意力集中在区分「横躺」和「站立/弯腰」上。
3. 用 YOLOv7 训练跌倒检测模型：命令、参数与损失曲线判断
3.1 从零跑通官方训练命令
拿到 YOLOv7 代码后，第一步不是立刻改配置，而是先原封不动跑一次 COCO 预训练权重的推理，确认环境没病。环境配置上，Python 版本建议 3.8~3.10，PyTorch 1.10~2.0 均可，CUDA 11.3 以上。我不建议一上来就装最新版 PyTorch，YOLOv7 官方仓库某些操作算子在新版上有兼容问题，遇见了再升级不迟。
# 克隆官方仓库并安装依赖 git clone https://github.com/WongKinYiu/yolov7.git cd yolov7 pip install -r requirements.txt # 下载 COCO 预训练权重后用单张图片做验证 python detect.py --weights yolov7.pt --source inference/images/horses.jpg --conf-thres 0.25跑通后你会看到终端打印检测框信息和耗时。这里有个容易忽略的参数--conf-thres，跌倒检测场景建议在推理阶段设到 0.5 以上，因为跌倒样本的误报代价高——把弯腰老人误报成跌倒，一天能触发几十次假告警，比漏检更让人头疼。
3.2 修改数据配置与模型配置
跌倒检测只需要一个类别，所以要改两个文件。数据配置文件放在data/fall.yaml，内容如下：
# fall.yaml train: ./datasets/fall/images/train val: ./datasets/fall/images/val test: ./datasets/fall/images/test nc: 1 names: ['fall']模型配置文件推荐直接用cfg/training/yolov7-tiny.yaml或者yolov7.yaml，只需要把最后一行的类别数从 80 改成 1。如果你用的是yolov7-tiny.yaml，注意它的深度和宽度系数已经写死，不要随意改，否则结构对不上预训练权重。
# 只需修改 nc 的那一行 # nc: 80 -> nc: 1这里有一个关键决策：是否加载 COCO 预训练权重。我的建议是必须加载，不要从零训练。跌倒检测的数据量撑不起从零收敛的复杂度，而 COCO 预训练权重里已经包含了对人体形态的丰富特征。用--weights yolov7.pt启动训练时，程序会自动丢弃类别维度不匹配的最后一层，只迁移前面 backbone 和 neck 的参数。
3.3 训练参数：批量大小、学习率和 epochs 的搭配逻辑
python train.py \ --weights yolov7.pt \ --data data/fall.yaml \ --hyp data/hyp.scratch.custom.yaml \ --epochs 150 \ --batch-size 16 \ --img-size 640 \ --device 0 \ --project runs/train_fall \ --name fall_v1参数说明如下。--batch-size是显存敏感项，8G 显存跑 base 模型建议 8，跑 tiny 模型可以 16；--img-size 640是精度和速度的平衡点，跌倒检测常见场景是监控画面里的远距离小目标，如果有余力可以把输入尺寸提到 768，小目标召回率会有可见提升。--epochs 150是经验值，跌倒数据集通常较小，150 轮足够收敛，再多容易过拟合；--hyp指向自定义超参文件，我一般会把hsv_h从 0.015 提高到 0.02，hsv_s从 0.7 提高到 0.8，因为养老院、医院走廊的灯光偏暖偏暗，颜色增强做狠一点能让模型适应更多光照环境。
训练过程中的损失曲线判断比看 mAP 更早暴露问题。正常收敛时，box_loss 和 obj_loss 在前 20 轮快速下降，之后缓慢波动下行；如果 box_loss 在 30 轮后出现反弹上升，大概率是学习率没配合好，或者数据里有错误标注。cls_loss 在这个项目里参考意义不大，因为只有单类。
3.4 导出第一次结果并测试边界样本
训练结束后，runs/train_fall/fall_v1/weights/下会出现best.pt和last.pt。best.pt按验证集 mAP 选最优保存，理论上用它做最终部署。但我的习惯是额外写一个脚本，专门用困难样本做人工测试——比如老人弯腰捡东西、从轮椅上滑落、儿童在地上爬这些高度疑似跌倒的动作。
# 用测试集里一批容易误判的图片单独验证 python detect.py \ --weights runs/train_fall/fall_v1/weights/best.pt \ --source ./hard_test_samples/ \ --conf-thres 0.5 \ --iou-thres 0.45 \ --save-txt--iou-thres 0.45控制 NMS 的合并阈值，跌倒场景中同一个目标不会重叠太多，保持默认即可。如果发现模型把「弯腰捡东西」误判成跌倒，不是阈值能解决的，而是训练数据里需要更多这类负样本。这正是公开数据集之外的补充价值。
4. 跌倒判定逻辑：检测框之外的最后一公里
4.1 只用检测框的局限：为什么「检测到人」不等于「检测到跌倒」
YOLOv7 的输出只是「边框 + 置信度」，它不知道这个框里的人是站着的、坐着的还是躺着的。跌倒判定的常见做法有两种：关键点方案和几何方案。关键点方案是在 YOLOv7 之外再接一个人体姿态估计模型，比如 OpenPose 或 YOLOv7-pose，用关键点之间的夹角和比例判断姿态；几何方案则是利用检测框本身的长宽比和中心点位置变化来判断。
我的实际经验是：纯几何方案在俯视摄像头下非常脆弱。因为俯视画面里，站着的人和倒地的人从上方看都是「一团」，检测框的长宽比差异不大。但在侧视或斜视监控角度下，几何方案简单有效。这里有一个重要的部署前提：摄像头安装高度在 2.5~3 米、俯角 30~60 度时，跌倒检测的可行性最高。太正的俯视会丢失姿态信息，太平的侧视会被遮挡。
因此在业务落地上，我推荐混合方案：检测框的高宽比加上中心点垂直速度。一个正常站立的人，检测框高 > 宽；跌倒后，高宽比会反转（横躺时宽 > 高）。同时，跌倒的动作特征是从站立到躺下的过程，中心点的 y 坐标会在 300~500 毫秒内快速下移。这两个条件同时满足，才判定为跌倒。
4.2 用 RGB 变化和跟踪器消除抖动误判
单纯用单帧检测框做判断会带来严重误报。摄像头轻微抖动、画面噪点、检测框的跳跃都会让高宽比和中心点突变。我的做法是引入跟踪器，让判断基于连续多帧的轨迹，而不是单帧。
# fall_judge.py —— 基于检测结果的跌倒判定逻辑 class FallJudge: def __init__(self, fall_frames=5, height_ratio_thresh=0.8, speed_thresh=0.3): self.history = {} # 每个 track_id 的检测框历史 self.fall_frames = fall_frames self.height_ratio_thresh = height_ratio_thresh self.speed_thresh = speed_thresh def update(self, track_id, bbox, frame_time): # bbox 格式: x1, y1, x2, y2 w, h = bbox[2]-bbox[0], bbox[3]-bbox[1] ratio = h / max(w, 1e-6) cy = (bbox[1]+bbox[3]) / 2 if track_id not in self.history: self.history[track_id] = [] self.history[track_id].append((frame_time, ratio, cy)) if len(self.history[track_id]) > 15: self.history[track_id].pop(0) # 条件1: 近5帧高宽比均值持续小于阈值（横躺） recent = self.history[track_id][-self.fall_frames:] if len(recent) < self.fall_frames: return False avg_ratio = sum([x[1] for x in recent]) / len(recent) # 条件2: 中心点纵向速度超过阈值（快速倒地） t0, r0, cy0 = recent[0] t1, r1, cy1 = recent[-1] dt = (t1 - t0) if t1 > t0 else 1e-6 speed = abs(cy1 - cy0) / dt return avg_ratio < self.height_ratio_thresh and speed > self.speed_thresh这段代码的逻辑是：每个跟踪目标保留最近 15 帧的历史，跌倒判定需要同时满足「高宽比均值连续低于阈值」和「中心点纵向移动速度超过阈值」。注意一个细节，速度的计算用的是第一帧和最后一帧之间的差值而不是逐帧差值，这是为了防止检测框抖动造成的瞬时速度误判。
fall_frames=5表示连续 5 帧满足条件才报警，约合 0.4 秒（12.5 FPS 推理时）。height_ratio_thresh=0.8含义是框高小于框宽的 80% 即判定为横躺。这两个参数的来源是我在养老院场景测试时观察到的：正常行走的人高宽比在 2~3 之间，坐姿在 1 左右，跌倒后稳定在 0.4~0.7，阈值 0.8 是区分坐姿和跌倒的折中点。如果你想降低漏检，可以把 0.8 提到 0.9，代价是蹲下捡东西这种动作也会被算进去。
4.3 从检测到告警的完整 pipeline
实际部署不是只挂这个判定函数就行，你需要串起视频流读取、YOLO 推理、跟踪、判定、告警这几环。常见的方案是：OpenCV 读摄像头或 RTSP 流 → YOLOv7 检测 → ByteTrack 或者 SORT 做目标跟踪 → 上述 FallJudge 做判定 → 判定触发后写入日志并截图保存。
# inference_pipeline.py —— CPU 或 GPU 均可运行的最小推理管线 import cv2 import torch from models.experimental import attempt_load device = torch.device('cuda' if torch.cuda.is_available() else 'cpu') model = attempt_load('runs/train_fall/fall_v1/weights/best.pt', map_location=device) model.eval() cap = cv2.VideoCapture(0) # 0 表示本机摄像头，也可以是 RTSP 地址 judge = FallJudge() while True: ret, frame = cap.read() if not ret: break # 推理解析, 这里省略了 letterbox 等预处理细节 results = model(frame, size=640) # 假设 results 里有 track_id 和 bbox, 送入判定器 for track_id, bbox in results: if judge.update(track_id, bbox, time.time()): cv2.imwrite(f'alarm_{time.time()}.jpg', frame) cv2.imshow('fall_detect', frame) if cv2.waitKey(1) & 0xFF == ord('q'): break这段代码里值得注意的点是attempt_load加载的模型路径和训练时可能不同。如果提示权重文件不匹配，检查是否用了torch.load的map_location='cpu'参数——跨设备加载权重最常翻车的就是 GPU 训练的权重在 CPU 上加载时报错。
5. 跌倒检测部署避坑：训练到落地之间的 5 个拦路虎
5.1 模型在测试集 mAP 很高，部署后却频繁漏检
现象：验证集 mAP 0.95 以上，一到实际走廊就漏掉傍晚时段的跌倒事件。 原因：训练数据的摄像头角度和部署现场不一致。验证集和训练集来自同一数据源，只能证明「类似场景」下的检测能力，而部署场景的走廊纵深、灯光色温、摄像头畸变都是新分布。 解决：在部署现场采集至少 30~50 分钟的视频，抽帧后人工标注，用这些真实场景数据做微调（fine-tune）。微调时学习率降为初始的 1/10，epochs 设置 30~50 轮即可，不要把模型训到重新收敛。
5.2 CPU 推理慢到无法实时，视频流出现丢帧
现象：同一套 YOLOv7 模型在 NVIDIA 显卡上 20 FPS，换到 CPU 只有 2~3 FPS。 原因：YOLOv7 的 E-ELAN 结构在 CPU 上没有优化加速，瓶颈在卷积算子。 解决：更换模型为 YOLOv7-tiny，把输入尺寸从 640 降到 480，再开启 OpenVINO 或 ONNX Runtime 的加速。如果还不行，考虑用 NCNN 或 TensorRT 做模型转换。经验的代价是精度下降 2~4 个点 mAP，但跌倒检测的核心是「能实时触发」，10 FPS 以上的帧率比 0.5 个点精度更重要。另外代码里用torch.no_grad()包住推理过程、把预处理移到 GPU 上，能再抠出 20%~30% 的耗时。
5.3 摄像头视角变化后完全不工作
现象：把训练时用的 45 度俯视摄像头换成吸顶 90 度垂直视角，检测率骤降。 原因：视角变化改变了人体在画面中的尺度分布和外观特征。YOLO 系模型对视角的泛化能力天然有限，靠数据增强只能小范围弥补。 解决：最稳妥的做法是每个摄像头点位单独采集数据并微调。不要指望一个通用模型适配所有摄像头安装条件。如果实在无法逐点微调，至少保证所有摄像头安装在同一高度和角度，尽量让画面分布与训练数据一致。
5.4 跌倒判定频繁误报：电风扇、窗帘飘动、光影变化
现象：没人在画面里时，FallJudge 逻辑也能报出跌倒——因为检测器把背景误检成人，后续判定逻辑跟着错。 原因：检测器输出的低置信度框也会进入判定流程，光照突变、摄像头的自动曝光调整会让背景区域出现假目标。 解决：在判定器入口处加置信度门槛，低于 0.5 的检测结果直接丢弃。同时判断目标框的面积比例，占画面比例太小的目标（比如远处的人只有 30x60 像素）不适合做高宽比判断，直接跳过。
5.5 多目标场景的 ID Switch 导致误判
现象：两个老人擦肩而过，跟踪 ID 互换之后，原本站立的人被误报跌倒。 原因：ByteTrack 和 SORT 在目标靠近时可能出现 ID 切换，判定器把另一条轨迹的历史数据接续到新目标上，导致高宽比和速度信息错乱。 解决：FallJudge 增加一个约束——目标的中心点必须在连续几帧里保持空间连续性。如果两帧之间的中心点位移超过检测框宽度的一半，说明发生了 ID 切换，重新初始化该轨迹的历史，不参与判定。这个是实际部署中很容易漏掉的细节。
6. 把跌倒检测系统调到能长期跑：验证方法、指标和日常巡检
前面五章涵盖了训练、判定和部署主线，但一个真正产品级的跌倒检测系统，最后还得解决「怎么证明它可靠」和「坏了怎么知道」。我分享两个工作中验证系统的做法。
第一个做法是回放验证。线上系统的摄像头 7x24 小时录着，我每周抽一天，把上一周的告警截图按时间轴排列，看哪些是真实跌倒、哪些是误报、哪些是漏报。这个习惯看起来土，但比任何指标都管用。你会逐渐发现自己场景里告警的时间规律——比如下午 3 点总有一两个误报，后来发现是那个时段阳光从窗户直射进来，把地面阴影映成了人形。知道了规律后，在代码里加了检测区域的 RoI 限制，把窗户区域排除在检测范围外，误报直接降了 70%。
第二个做法是区分指标验证。检测任务的 mAP 不能完全代表跌倒系统的可用性。我建议给系统定义三个可量化的业务指标：跌倒召回率、误报率、平均响应延迟。具体到代码上，你可以写一段离线评测脚本，把标注好的测试视频一段段送进完整 pipeline（检测+跟踪+判定），计算最后报警事件与标注事件的匹配度。
# 离线测评脚本的核心逻辑：对比报警时刻与标注时刻 def evaluate_alarm(detection_results, ground_truth): tp, fp, fn = 0, 0, 0 for gt in ground_truth: # 跌倒标注是一个时间区间 [start_frame, end_frame] matched = [d for d in detection_results if d['frame'] >= gt['start_frame'] - 10 and d['frame'] <= gt['end_frame'] + 10] if matched: tp += 1 else: fn += 1 fp = len(detection_results) - tp recall = tp / max(tp + fn, 1) precision = tp / max(tp + fp, 1) return recall, precision这段代码给你一个重要视角：系统最终的报警事件数才是评估对象，而不是逐帧检测精度。如果每段跌倒视频能稳定触发报警，且每小时误报不超过 1 次，这个系统就有资格交给用户。响应延迟方面，从跌倒动作完成到系统发出消息，我建议控制在 3 秒以内。这一步主要是验证跟踪器和判定逻辑的串行延迟，如果超了，优先优化预处理环节的耗时——往往一个letterbox函数用 Python 写就可能吃掉 200ms。
最后的日常巡检习惯上，我会在系统里挂一个心跳检测：每 10 分钟检查一次摄像头信号是否正常，如果画面黑屏或者帧率低于设定值，立刻发一条通知给运维人员。跌倒检测系统最致命的故障不是检测不准，而是摄像头掉了图像还在假装工作。如果你要长期部署，务必把这个巡检加进你的代码里。
这套方案走到这里，从数据标注、模型训练、跌倒判定到部署验证都齐了。YOLOv7 的模型能力只是系统的一半，另一半是你对业务场景的判断——认识到自己的数据局限、重视误报率、把摄像头安装位置当作用户需求来调研。如果你刚开始做，建议先拿公开数据集把训练流程跑通，再逐步替换成自己的场景数据。希望这篇笔记里的参数和踩坑记录，能帮你省下几个重复造轮子的夜晚。
本文还有配套的精品资源，点击获取
