简介这套基于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.10PyTorch 1.10~2.0 均可CUDA 11.3 以上。我不建议一上来就装最新版 PyTorchYOLOv7 官方仓库某些操作算子在新版上有兼容问题遇见了再升级不迟。# 克隆官方仓库并安装依赖 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.02hsv_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_frames5, height_ratio_thresh0.8, speed_thresh0.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_frames5表示连续 5 帧满足条件才报警约合 0.4 秒12.5 FPS 推理时。height_ratio_thresh0.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_locationdevice) model.eval() cap cv2.VideoCapture(0) # 0 表示本机摄像头也可以是 RTSP 地址 judge FallJudge() while True: ret, frame cap.read() if not ret: break # 推理解析, 这里省略了 letterbox 等预处理细节 results model(frame, size640) # 假设 results 里有 track_id 和 bbox, 送入判定器 for track_id, bbox in results: if judge.update(track_id, bbox, time.time()): cv2.imwrite(falarm_{time.time()}.jpg, frame) cv2.imshow(fall_detect, frame) if cv2.waitKey(1) 0xFF ord(q): break这段代码里值得注意的点是attempt_load加载的模型路径和训练时可能不同。如果提示权重文件不匹配检查是否用了torch.load的map_locationcpu参数——跨设备加载权重最常翻车的就是 GPU 训练的权重在 CPU 上加载时报错。5. 跌倒检测部署避坑训练到落地之间的 5 个拦路虎5.1 模型在测试集 mAP 很高部署后却频繁漏检现象验证集 mAP 0.95 以上一到实际走廊就漏掉傍晚时段的跌倒事件。 原因训练数据的摄像头角度和部署现场不一致。验证集和训练集来自同一数据源只能证明「类似场景」下的检测能力而部署场景的走廊纵深、灯光色温、摄像头畸变都是新分布。 解决在部署现场采集至少 30~50 分钟的视频抽帧后人工标注用这些真实场景数据做微调fine-tune。微调时学习率降为初始的 1/10epochs 设置 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 的模型能力只是系统的一半另一半是你对业务场景的判断——认识到自己的数据局限、重视误报率、把摄像头安装位置当作用户需求来调研。如果你刚开始做建议先拿公开数据集把训练流程跑通再逐步替换成自己的场景数据。希望这篇笔记里的参数和踩坑记录能帮你省下几个重复造轮子的夜晚。本文还有配套的精品资源点击获取
简介这套基于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.10PyTorch 1.10~2.0 均可CUDA 11.3 以上。我不建议一上来就装最新版 PyTorchYOLOv7 官方仓库某些操作算子在新版上有兼容问题遇见了再升级不迟。# 克隆官方仓库并安装依赖 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.02hsv_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_frames5, height_ratio_thresh0.8, speed_thresh0.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_frames5表示连续 5 帧满足条件才报警约合 0.4 秒12.5 FPS 推理时。height_ratio_thresh0.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_locationdevice) model.eval() cap cv2.VideoCapture(0) # 0 表示本机摄像头也可以是 RTSP 地址 judge FallJudge() while True: ret, frame cap.read() if not ret: break # 推理解析, 这里省略了 letterbox 等预处理细节 results model(frame, size640) # 假设 results 里有 track_id 和 bbox, 送入判定器 for track_id, bbox in results: if judge.update(track_id, bbox, time.time()): cv2.imwrite(falarm_{time.time()}.jpg, frame) cv2.imshow(fall_detect, frame) if cv2.waitKey(1) 0xFF ord(q): break这段代码里值得注意的点是attempt_load加载的模型路径和训练时可能不同。如果提示权重文件不匹配检查是否用了torch.load的map_locationcpu参数——跨设备加载权重最常翻车的就是 GPU 训练的权重在 CPU 上加载时报错。5. 跌倒检测部署避坑训练到落地之间的 5 个拦路虎5.1 模型在测试集 mAP 很高部署后却频繁漏检现象验证集 mAP 0.95 以上一到实际走廊就漏掉傍晚时段的跌倒事件。 原因训练数据的摄像头角度和部署现场不一致。验证集和训练集来自同一数据源只能证明「类似场景」下的检测能力而部署场景的走廊纵深、灯光色温、摄像头畸变都是新分布。 解决在部署现场采集至少 30~50 分钟的视频抽帧后人工标注用这些真实场景数据做微调fine-tune。微调时学习率降为初始的 1/10epochs 设置 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 的模型能力只是系统的一半另一半是你对业务场景的判断——认识到自己的数据局限、重视误报率、把摄像头安装位置当作用户需求来调研。如果你刚开始做建议先拿公开数据集把训练流程跑通再逐步替换成自己的场景数据。希望这篇笔记里的参数和踩坑记录能帮你省下几个重复造轮子的夜晚。本文还有配套的精品资源点击获取
