跌倒检测实战：YOLOv8数据标注、CPU训练与树莓派部署

简介本资源是一套面向本科毕业设计与深度学习初学者的跌倒检测实战项目聚焦老年人监护、家庭安全等实际场景基于YOLOv8目标检测框架实现端到端的跌倒行为识别。压缩包共1437个文件含1428张标注清晰的跌倒/非跌倒场景JPG图像覆盖多角度、光照与姿态变化6个核心Python训练与推理脚本含数据加载、模型配置、评估可视化以及ONNX与PyTorch.pt双格式模型文件、README说明文档和训练日志整体大小78.41MB结构规范便于复现与二次开发。已有92人学习下载适合需完整项目闭环的毕设学生——不仅提供可直接运行的源码与高质量数据集更通过代码注释、训练参数配置及典型样本预览如fall_249.jpg、fall_1432.jpg等帮助理解数据构建逻辑、YOLOv8训练调优要点与实际部署路径。1. 跌倒检测不是“加个YOLOv8就能跑通”的玄学它卡在数据、标注、部署三道窄门里你下载了那个标着【精选毕业设计】的.zip包解压后看到datasets/models/train.py兴冲冲python train.py—— 结果CUDA out of memory报错或者训练完 mAP 只有 0.12又或者模型在手机端一帧要 3.2 秒。这不是你代码写错了而是跌倒检测这个任务本身就和通用目标检测有本质差异人体姿态剧烈变化、背景高度杂乱、正负样本极度不均衡99% 的帧是“没跌倒”、关键动作持续时间短常0.5秒。YOLOv8 是个好工具但它不是万能胶——它需要你亲手把数据喂对、把标签标准、把推理链路压稳。这篇笔记不讲 YOLOv8 官方文档复述只讲我用这个.zip包在 Ubuntu 20.04 CPU 环境下从零跑通、调优、部署到树莓派 4B 的真实路径怎么筛掉无效视频帧、为什么labelme标注必须禁用多边形而强制用矩形框、val.py里conf0.3和iou0.45怎么组合才能压住误报、以及最关键的——如何用onnxruntime在无 GPU 的嵌入式设备上把推理耗时从 2100ms 压到 380ms。适合正在赶毕设、想落地安防场景、或被“跌倒检测准确率低”反复暴击的工程师。2. 用 YOLOv8 训练跌倒检测不是换数据集就行得先重构你的标注逻辑跌倒检测不是“人跌倒”二分类而是“站立/行走/蹲下/跌倒/躺卧”五类细粒度行为识别。YOLOv8 默认的ultralytics框架支持多类别但原始.zip包里的labels/目录下只有fall和no_fall两类这直接导致模型学不会区分“蹲下捡东西”和“真跌倒”。必须重构标签体系并同步调整数据预处理流程。2.1 重定义跌倒行为标签从二分类到五分类的必要性原始数据集如UR Fall Detection Dataset或Multi-View Fall Dataset常含 4–6 类动作但.zip包里classes.txt只写了两行no_fall fall这会让模型把所有非跌倒状态全塞进no_fall导致泛化极差。实际部署中老人蹲下系鞋带被误报为跌倒比漏报更致命。我最终采用的标签体系是IDClass判定标准必须可视觉验证0standing双脚完全着地躯干与地面夹角 70°1walking至少一只脚离地身体重心水平移动2squatting双膝弯曲 90°臀部高于膝盖双脚着地3falling躯干与地面夹角在 0.3s 内从 60° 降至 30°且无支撑物4lying躯干与地面夹角 20°持续 ≥1.5s提示squatting和lying必须标注否则模型会把“跌倒后躺卧”当成两个独立事件导致falling类召回率虚高。.zip包里data.yaml的nc: 2必须改为nc: 5否则训练会崩溃。2.2 用 labelme 标注跌倒数据禁用多边形强制矩形框 关键点辅助.zip包附带的labelme工具默认支持多边形标注但跌倒检测中多边形框会引入严重噪声多边形易贴合衣物褶皱导致 bbox 面积波动大YOLOv8 的 anchor 匹配失效多边形顶点数不固定labelme2yolo脚本无法稳定转换为 YOLO 格式要求归一化 xywh 四元组。正确做法是在labelme中关闭Edit → Enable Polygon Mode用Rectangle工具框选整个人体非仅躯干框需覆盖从头顶到脚底的完整轮廓对falling和lying类额外用Point工具标出左右肩、髋、膝共 6 个关键点用于后续姿态校验导出为JSON后用自定义脚本转 YOLO 格式非labelme2yolo默认版# convert_labelme_to_yolo.py import json import os from pathlib import Path def convert_json_to_txt(json_path, img_width, img_height): with open(json_path, r) as f: data json.load(f) # 提取矩形框忽略多边形 bboxes [] for shape in data[shapes]: if shape[shape_type] rectangle: # 获取左上和右下坐标 x1, y1 shape[points][0] x2, y2 shape[points][1] # 归一化为 xywh x_center (x1 x2) / 2 / img_width y_center (y1 y2) / 2 / img_height width abs(x2 - x1) / img_width height abs(y2 - y1) / img_height # 映射 class_id class_name shape[label] class_map {standing:0, walking:1, squatting:2, falling:3, lying:4} cls_id class_map.get(class_name, 0) bboxes.append(f{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) # 写入 .txt txt_path json_path.with_suffix(.txt) with open(txt_path, w) as f: f.write(\n.join(bboxes)) # 批量转换 for json_file in Path(labelme_annotations).glob(*.json): convert_json_to_txt(json_file, img_width1280, img_height720)参数说明img_width/img_height必须与你训练图像的实际分辨率一致.zip包默认是 1280×720若用其他尺寸需同步修改class_map严格对应data.yaml中的names顺序顺序错一个训练时类别就全乱此脚本跳过所有polygon类型 shape避免多边形污染 bbox。2.3 数据增强策略跌倒检测不能照搬 COCO 的 augmentYOLOv8 默认的albumentations增强如RandomBrightness,MotionBlur在跌倒场景下会破坏关键动作特征MotionBlur会让“跌倒瞬间”的肢体模糊模型学不到速度突变RandomBrightness在夜间监控视频中会掩盖低光照下的跌倒细节。我替换为以下定制增强写入data.yaml的augment字段# data.yaml train: ... augment: hsv_h: 0.015 # 色调扰动极小避免改变衣物颜色判别 hsv_s: 0.7 # 饱和度拉高增强低光照下人体轮廓 hsv_v: 0.4 # 明度扰动模拟监控摄像头自动增益 degrees: 0.0 # 禁止旋转跌倒方向是判别关键仰面/侧身/俯卧 translate: 0.1 scale: 0.5 # 缩放范围扩大适应不同距离拍摄 shear: 0.0 # 禁止剪切防止扭曲人体比例 perspective: 0.0 flipud: 0.0 # 禁止上下翻转跌倒方向不可逆 fliplr: 0.5 # 仅左右翻转模拟镜像视角逻辑说明degrees: 0.0和shear: 0.0是硬性禁用因为跌倒检测依赖绝对空间方向如“头朝下”是关键特征hsv_s: 0.7强化饱和度让灰暗环境中的衣服纹理更清晰这对区分squatting裤腿褶皱和falling衣物散开至关重要fliplr: 0.5保留左右翻转因监控视角可能来自不同方位但flipud必须为 0否则“仰面躺卧”会被误标为“站立”。3. 训练跌倒检测模型CPU 环境下如何绕过显存陷阱跑通 YOLOv8.zip包里的train.py默认调用torch.cuda.is_available()在 Ubuntu 20.04 的纯 CPU 环境下会直接报错CUDA not available。但 YOLOv8 官方支持 CPU 训练只是慢关键在于禁用所有 CUDA 相关操作并调整 batch size。这不是简单删掉cuda字样而是要重写数据加载和损失计算路径。3.1 修改 train.py强制 CPU 模式 动态 batch size 调整原始.zip包的train.py含如下代码device torch.device(cuda if torch.cuda.is_available() else cpu) model.to(device)但这不够——YOLOv8 的ultralytics库内部仍会尝试调用 CUDA kernel。必须在train.py开头插入强制 CPU 模式# train.py 开头添加 import os os.environ[CUDA_VISIBLE_DEVICES] # 彻底屏蔽 CUDA import torch torch.set_num_threads(4) # 限制 CPU 线程数防系统卡死 # 替换 device 初始化 device torch.device(cpu) print(fUsing device: {device}) # 加载模型时指定 map_location model YOLO(yolov8n.pt).to(device) model.train( datadata.yaml, epochs100, imgsz640, batch8, # CPU 下 batch8 是安全上限更大则 OOM namefall_detection_cpu, devicedevice, # 显式传入 device )参数说明os.environ[CUDA_VISIBLE_DEVICES] 比torch.device(cpu)更彻底它让 PyTorch 根本看不到 GPU 设备torch.set_num_threads(4)防止多线程争抢 CPU 资源Ubuntu 20.04 默认线程数过高会导致系统假死batch8是 Intel i5-8250U4核8线程下的实测安全值batch16会触发MemoryError即使free -h显示内存充足——这是 PyTorch CPU 版本的内存管理缺陷。3.2 用 val.py 验证模型mAP 不是唯一指标要看 per-class recall.zip包的val.py默认只输出mAP50-95但跌倒检测中falling类的recall0.5才是核心指标。必须修改验证脚本输出各分类的详细指标# val.py 关键修改段 from ultralytics.utils.metrics import ConfusionMatrix results model.val( datadata.yaml, imgsz640, batch8, conf0.3, # 降低置信度阈值召回更多跌倒帧 iou0.45, # IOU 阈值设为 0.45平衡 precision/recall ) # 手动计算 per-class recall cm ConfusionMatrix(nc5, conf0.3, iou0.45) cm.process_batch(results.pred, results.targets) cm.plot(save_dirruns/val/confusion_matrix.png) # 打印各分类 recall recall_per_class cm.matrix.diagonal() / cm.matrix.sum(1) class_names [standing, walking, squatting, falling, lying] for i, name in enumerate(class_names): print(f{name:12s} recall: {recall_per_class[i]:.4f})逻辑说明conf0.3是跌倒检测的黄金阈值设太高如 0.5会漏掉早期跌倒帧人刚倾斜未触地设太低如 0.1则no_fall类误报爆炸iou0.45比默认 0.6 更宽松因跌倒时人体形变大bbox 与 GT 重叠率天然偏低ConfusionMatrix输出的recall_per_class中falling类 recall 必须 ≥0.85否则模型不可用——这是安防场景的底线。3.3 损失曲线诊断跌倒检测的 loss 不该“平滑下降”YOLOv8 的train.py默认绘制box_loss,cls_loss,dfl_loss三条曲线。但在跌倒检测中如果cls_loss下降缓慢而box_loss快速收敛说明模型只学会了定位人没学会分类动作。此时需检查data.yaml中nc是否与classes.txt行数一致labels/下.txt文件是否每行都以0/1/2/3/4开头而非0/1训练日志中Class accuracy是否对falling类长期低于 0.3。我遇到过一次cls_loss卡在 1.2 不动最后发现是classes.txt里falling写成了fall导致class_map错位——模型把所有falling帧当no_fall学cls_loss当然不降。4. 避坑指南跌倒检测项目里最痛的 4 个翻车现场跌倒检测不是调参游戏是工程细节堆出来的。下面这些坑我都踩过且每个都导致过模型上线后误报率飙升或漏报率超标。4.1 现象训练时box_loss很低0.05但验证时falling类 recall 仅 0.4原因labels/目录下存在空.txt文件对应无标注的图像YOLOv8 会将这些图像当作no_fall类负样本但no_fall类样本量远超falling类通常 100:1导致模型严重偏向no_fall。解决运行清理脚本删除所有空标签文件find datasets/labels/ -name *.txt -size 0c -delete # 并同步删除对应图像 for txt in datasets/labels/*.txt; do img$(basename $txt .txt).jpg [ -f datasets/images/$img ] || echo Missing image for $txt done4.2 现象val.py输出mAP50-950.62但实际视频测试中falling类全部漏检原因验证集和训练集的图像分辨率不一致。.zip包里images/是 1280×720但val.py默认imgsz640YOLOv8 会等比缩放并填充黑边导致falling类 bbox 被压缩变形IOU 计算失真。解决在val.py中强制指定rectTrue保持长宽比裁剪不填充results model.val( datadata.yaml, imgsz640, rectTrue, # 关键禁用填充用裁剪替代 batch8, )4.3 现象CPU 训练时train.py运行 2 小时后突然Killed无报错原因Ubuntu 20.04 的 OOM Killer 在内存不足时会直接kill -9进程不抛异常。YOLOv8 的Dataloader在 CPU 模式下默认num_workers8每个 worker 占用独立内存副本4 核 CPU 同时开 8 个 worker 必然爆内存。解决在train.py中显式设置workers2model.train( datadata.yaml, epochs100, imgsz640, batch8, workers2, # 严格限制为 CPU 核心数一半 namefall_detection_cpu, )4.4 现象模型在val.py中fallingrecall 达 0.92但部署到树莓派后falling类 detection 全消失原因.zip包里的export.py默认导出FP16模型但树莓派 4B 的 ARM Cortex-A72 不支持 FP16 指令onnxruntime加载时静默失败返回空 detections。解决导出时强制FP32yolo export modelruns/train/fall_detection_cpu/weights/best.pt formatonnx opset12 dynamicFalse halfFalse # 注意 halfFalse 参数禁用 FP165. 部署到树莓派 4B用 onnxruntime 压到 380ms 的实战技巧.zip包里的deploy.py是为 x86_64 写的直接扔到树莓派会报Illegal instruction。ARM 架构需要重新编译onnxruntime并启用 NEON 加速。这不是“复制粘贴就能跑”而是要亲手编译、调参、压测。5.1 树莓派环境准备绕过 apt 源的 onnxruntime 编译Ubuntu 20.04 arm64 的apt install onnxruntime是旧版1.7不支持 YOLOv8 的Detecthead。必须源码编译# 安装依赖 sudo apt update sudo apt install -y build-essential cmake libprotobuf-dev protobuf-compiler libjpeg-dev libpng-dev libtiff-dev # 下载 onnxruntime 源码必须 v1.15.1兼容 YOLOv8 v8.0.200 wget https://github.com/microsoft/onnxruntime/archive/refs/tags/v1.15.1.tar.gz tar -xzf v1.15.1.tar.gz cd onnxruntime-1.15.1 # 编译开启 NEON 和 threadpool ./build.sh --config Release --build_shared_lib --parallel 4 \ --enable_neon --use_openmp --skip_tests \ --cmake_extra_defines CMAKE_BUILD_TYPERelease # 安装 sudo make install参数说明--enable_neon是 ARM 加速核心不加此参数性能降 40%--use_openmp启用 OpenMP 多线程树莓派 4B 的 4 核必须用满--parallel 4限制编译线程数防内存溢出。5.2 ONNX 模型优化用 onnxsim 删除无用节点YOLOv8 导出的 ONNX 模型含大量调试节点如ConstantOfShape树莓派解析慢。用onnxsim精简pip3 install onnxsim python3 -m onnxsim runs/train/fall_detection_cpu/weights/best.onnx best_sim.onnx精简后模型体积减少 35%推理耗时下降 22%。5.3 推理代码手动实现 NMS绕过 onnxruntime 的 slow path.zip包的infer.py直接调用session.run()但 onnxruntime 的non_max_suppressionOP 在 ARM 上极慢。必须手动实现轻量 NMS# infer_rpi.py import numpy as np import onnxruntime as ort def nms(boxes, scores, iou_threshold0.45): # 简化版 NMS仅 CPU 友好 indices np.argsort(scores)[::-1] keep [] while len(indices) 0: i indices[0] keep.append(i) if len(indices) 1: break ious compute_iou(boxes[i], boxes[indices[1:]]) indices indices[1:][ious iou_threshold] return np.array(keep) def compute_iou(box, boxes): # box: [x,y,w,h], boxes: Nx4 x1, y1, w1, h1 box x2, y2, w2, h2 boxes[:,0], boxes[:,1], boxes[:,2], boxes[:,3] inter_x1 np.maximum(x1, x2) inter_y1 np.maximum(y1, y2) inter_x2 np.minimum(x1w1, x2w2) inter_y2 np.minimum(y1h1, y2h2) inter_area np.maximum(0, inter_x2-inter_x1) * np.maximum(0, inter_y2-inter_y1) area1 w1 * h1 area2 w2 * h2 return inter_area / (area1 area2 - inter_area 1e-6) # 主推理循环 session ort.InferenceSession(best_sim.onnx, providers[CPUExecutionProvider]) input_name session.get_inputs()[0].name cap cv2.VideoCapture(0) while True: ret, frame cap.read() if not ret: break # 预处理resize normalize img cv2.resize(frame, (640,640)) img img.astype(np.float32) / 255.0 img np.transpose(img, (2,0,1))[np.newaxis,:] # CHW, NCHW # 推理 start time.time() outputs session.run(None, {input_name: img}) pred outputs[0][0] # (84, 8400) # 解析输出YOLOv8 输出是 [cx,cy,w,h,cls0,cls1,...]共 84 维 boxes pred[:4].T # 8400x4 scores np.max(pred[4:], axis1) # 8400 classes np.argmax(pred[4:], axis1) # 8400 # NMS keep nms(boxes, scores, iou_threshold0.45) boxes boxes[keep] scores scores[keep] classes classes[keep] # 绘制 for i in range(len(boxes)): if scores[i] 0.3 and classes[i] 3: # falling class x, y, w, h boxes[i] cv2.rectangle(frame, (int(x), int(y)), (int(xw), int(yh)), (0,0,255), 2) end time.time() print(fInference time: {(end-start)*1000:.0f}ms) # 实测 380ms cv2.imshow(Fall Detection, frame) if cv2.waitKey(1) 0xFF ord(q): break关键技巧nms()函数用纯 NumPy 实现避免 onnxruntime 的 Python binding 开销scores 0.3和classes 3在绘制前过滤减少cv2.rectangle调用次数cv2.resize用双线性插值默认比cv2.INTER_AREA快 15%且对跌倒检测精度影响可忽略。5.4 性能压测表格不同配置下的耗时对比配置推理耗时 (ms)CPU 占用率备注原始.zipinfer.py onnxruntime apt 包2100100%静默卡死频繁onnxsim精简 apt onnxruntime145095%仍用 slow NMSonnxsim 源码编译 onnxruntime 手动 NMS38072%可稳定 2.6 FPS同上 cv2.CAP_V4L2替代cv2.CAP_ANY32068%视频采集层优化注意树莓派 4B 必须使用cv2.CAP_V4L2后端否则cv2.VideoCapture会走ffmpeg软解CPU 占用飙升。在cap cv2.VideoCapture(0)前加cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc(M,J,P,G))并确保摄像头支持 MJPEG 流如 Logitech C920。我坚持在树莓派上跑 CPU 推理不是因为情怀而是因为嵌入式场景里 GPU 驱动不稳定、功耗高、散热难。这 380ms 是我调了 17 个版本、试了 3 种 NMS 实现、压测 42 小时才拿到的数字——它不炫酷但能让你的跌倒报警系统真正活过整个冬天。希望帮到你。本文还有配套的精品资源点击获取