简介基于YOLOv8的商场扶梯逆行行为预警系统是一套完整的计算机视觉项目面向人工智能、计算机视觉等专业的毕业生或开发者用于检测商超扶梯上的逆行人员可替代传统人工监控也可作为毕业设计或课程设计的主体方案。压缩包共8个文件包含3个Python脚本模型训练、视频检测、可视化界面、3个模型权重文件如best.pt、yolov8n.pt和2个说明文档整体大小约15.91MB部署便捷。目前已有37人浏览学习资源内提供完整源码、数据集、可视化页面及部署教程训练好的模型可直接运行也可在现有代码基础上修改扩展。运行后可输出混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果及标签分布图等核心指标便于在答辩评审中直观展示模型性能。所有代码均经过测试按README指引即可复现。1. 商场扶梯逆行预警这个系统在解决什么、值不值得做《基于YOLOv8的商场扶梯逆行行为预警系统》这类项目拆开看是三个工程问题人怎么被稳定检测出来、逆行行为怎么在连续帧里判定、告警怎么通过可视化界面呈现。做过监控类项目的人会有同感——检测模型只是第一公里真正让系统可用、可演示的是后面的行为判定和界面交互链路。这套方案把 YOLOv8 权重、标注数据集、可视化界面源码和部署教程整合在一起简单部署即可运行。对准备用 YOLOv8 做毕设或课程设计的同学来说它把算法、数据、交互三个维度都覆盖了选题完整度高答辩时也容易拿出实物演示。2. 技术选型与数据准备YOLOv8 为什么适合扶梯逆行检测2.1 逆行检测的两条技术路线分类网络还是检测加轨迹扶梯逆行在单帧图像里没有明显的视觉特征——一个人站在扶梯上无论上行还是逆行姿态、着装、箱体位置几乎一模一样。真正被验证有效的做法不是训练一个“逆行分类器”而是让检测模型负责把人找出来再用连续帧的轨迹方向判定是否逆行。这条链路分三步目标检测框出人、跟踪算法在后续帧里保持身份、轨迹方向与扶梯运行方向比对后触发预警。另一条路线是直接训练视频理解网络比如 SlowFast 或 VideoMAE一次输入多帧直接输出“逆行/正常”。这类模型在学术论文里很常见但毕设落地有几个硬伤标注成本高需要逐帧逐段标注视频训练慢一张 GPU 卡跑一次要几天推理延迟大很难做到实时预警。而对扶梯这种视角固定的场景它的性能优势并没有想象中明显。我自己的经验是在没有大量视频标注的前提下用 YOLOv8 做目标检测加轨迹方向判定是性价比最高的方案也最容易向非技术背景的答辩评委解释清楚。判定逻辑上常见做法是记录目标中心点的轨迹序列计算连续若干帧的位移方向。扶梯明确向下运行时目标中心的 Y 坐标持续向上移动超过阈值就判定为逆行反之亦然。为了避免单帧抖动带来的误判通常会要求连续多帧都满足方向条件才触发预警这个连续帧数就是需要你亲手调的超参数。2.2 YOLOv8 的网络结构C2f、PAN-FPN 与解耦头YOLOv8 之所以是这类毕设项目的默认选择是因为它在精度、速度和易用性之间取得了很好的平衡。结构上它延续了 CSPDarknet 骨干设计但把 YOLOv5 里的 C3 模块换成了 C2f。C2f 通过更丰富的梯度流分支在不明显增加推理耗时的前提下提高了特征表达能力。颈部网络采用 PAN-FPN 结构让浅层空间细节和深层语义信息在多尺度特征图上融合这对扶梯场景“人近大远小”的尺度差异非常关键——扶梯出入口附近的人头尺寸差异可以超过五倍。检测头方面YOLOv8 从 YOLOv5 的 anchor-based 改成 anchor-free直接回归目标中心点和宽高不再预设锚框。这个改动省去了锚框聚类调参的麻烦对小目标的召回也更稳定。配合解耦头把分类和回归分支分开收敛速度比耦合头快不少。对扶梯任务来说person 是相对规整的类别YOLOv8n 或 YOLOv8s 就够用没必要上 YOLOv8x——GTX 1660 Ti 这种 6GB 显存的卡也能跑得很顺。如果你想在毕设里体现一点模型改进的思考YOLOv8 的 head 部分是最容易下手的点。常见做法是在检测头之前插入注意力模块比如在 C2f 后面加一个 SE 或 CBAM只改几十行代码就能跑通对比实验。改进未必能显著涨点但能展示你对网络结构的理解这在答辩里的价值比几个点的 mAP 提升更实际。2.3 数据集构建场景覆盖、标注规范与样本平衡扶梯逆行没有现成的大型公开数据集主流做法是从商场监控视频里截帧或者用手机在扶梯口固定机位拍一段。采集时要注意覆盖三个维度不同时段白天和晚上人流密度差异很大不同扶梯朝向上行和下行各拍一段不同距离尺度近景远景都要有。类别设计上最常见的是只标注 person 一个类别因为逆行行为本身是通过轨迹判断的不需要单独定义一个“逆行”类别。如果你拿到的数据是 COCO 格式或 VOC 格式YOLOv8 不能直接吃——它要求每张图对应一个同名 .txt 文件每行格式是类别、归一化的中心点坐标和宽高。所以数据准备阶段的核心工作其实是写一个转换脚本。很多同学在这里翻车不是训练参数的问题而是坐标归一化算错了。样本平衡也是扶梯数据里最容易踩的坑。扶梯人流高峰期上行和下行人数可能差很多即便只检测 person 类别不同时段、不同角度下的人头密度差异也会影响检测效果。常见的补救做法是少样本时段过采样、多角度采集补充、用不同帧率重复采样同一段视频来制造多样性。左右翻转也可以用但要小心——翻转之后扶梯的运行方向语义也随之反转轨迹判定代码里要跟着改方向常量。3. 本地部署跑通环境、推理脚本与可视化界面3.1 环境配置Python、PyTorch 与 ultralytics 的安装顺序先交代我常用的环境组合Python 3.10、CUDA 11.8、PyTorch 2.x、ultralytics 8.x。这套组合在 RTX 30 系列和 GTX 16 系列上都能稳定工作NVIDIA 驱动版本高于 460 基本没有兼容性问题。以下是创建独立虚拟环境并安装依赖的命令conda create -n escalator python3.10 -y conda activate escalator pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics opencv-python参数说明--index-url指定 PyTorch 官方预编译包源确保装到 CUDA 11.8 对应的 GPU 版本而不是默认源经常拉下来的 CPU 版。装完后用python -c import torch; print(torch.cuda.is_available())验证输出True才算装对。这一步没通过就不要往下走后面所有推理和训练都依赖 GPU 环境。这里有个我踩过的坑不要用pip install torch直接装默认源。默认源在多数情况下会拉到 CPU 版训练慢一个数量级还会出现“模型能加载但cuda.is_available()永远是 False”的诡异现象。如果你用的是 RTX 40 系列新卡可能还需要更新 CUDA 到 12.x配套的--index-url也要换成cu121或更高版本否则兼容层会报错。3.2 推理脚本与预警逻辑基于跟踪轨迹的方向判定部署的核心脚本包含视频读取、模型推理、轨迹跟踪和逆行判定四部分。ultralytics 已经把 predict 封装得非常简单但要做实时预警必须写一个带状态管理的推理循环因为单帧推理无法判断方向。下面是一个最小可运行的示例import cv2 from ultralytics import YOLO from collections import deque model YOLO(best.pt) cap cv2.VideoCapture(escalator.mp4) # 也可以是摄像头编号 0 track_history {} alert_frames 0 ESCALATOR_DIRECTION down # 扶梯运行方向部署时改成实际朝向 def check_reverse(track): if len(track) 10: return False dy track[-1][1] - track[-10][1] if ESCALATOR_DIRECTION down and dy -15: return True if ESCALATOR_DIRECTION up and dy 15: return True return False while cap.isOpened(): ret, frame cap.read() if not ret: break results model.track(frame, persistTrue, conf0.35, iou0.5) for box in results[0].boxes: if box.id is None: continue tid int(box.id.item()) cx, cy float(box.xywh[0][0]), float(box.xywh[0][1]) track_history.setdefault(tid, deque(maxlen30)) track_history[tid].append((cx, cy)) if check_reverse(track_history[tid]): alert_frames 1 else: alert_frames max(0, alert_frames - 1) if alert_frames 8: cv2.putText(frame, REVERSE ALERT, (10, 30), cv2.FONT_HERSHEY_SIMPLEX, 1.2, (0, 0, 255), 3) cv2.rectangle(frame, (int(box.xyxy[0]), int(box.xyxy[1])), (int(box.xyxy[2]), int(box.xyxy[3])), (0, 0, 255), 2) cv2.imshow(Escalator Monitoring, frame) if cv2.waitKey(1) ord(q): break cap.release() cv2.destroyAllWindows()这段代码的逻辑要拆开看model.track开启跨帧跟踪模式persistTrue表示沿用上一帧的跟踪状态deque(maxlen30)只保留每个目标最近 30 帧的中心坐标避免轨迹无限增长check_reverse比较当前帧和前 10 帧的 Y 轴位移来判断运动方向。关键参数conf0.35是置信度下限调低会召回更多目标但误检也变多扶梯场景我建议设在 0.3 到 0.4 之间iou0.5是 NMS 阈值一般不用动alert_frames 8是连续预警计数用来过滤瞬时抖动这个值在 5 到 15 之间比较合理。ESCALATOR_DIRECTION必须在部署时按照摄像头的实际安装位置手动设置——摄像头倒装时图像的 Y 轴方向与扶梯实际运行方向相反这也是最容易忽略的一步。3.3 可视化界面PyQt5 还是 Gradio可视化界面是这个项目的展示亮点。两种常见做法各有利弊PyQt5 适合做桌面软件界面专业事件回调灵活适合答辩时演示打包好的 exeGradio 适合快速搭 Web 演示代码量只有 PyQt5 的三分之一浏览器打开就能交互。如果你希望把精力集中在算法上Gradio 是更省事的选择。一个很短的可运行 Gradio 示例import gradio as gr from ultralytics import YOLO import numpy as np model YOLO(best.pt) def predict(frame): results model(frame, conf0.35) return results[0].plot() gr.Interface( fnpredict, inputsgr.Image(typenumpy), outputsgr.Image(typenumpy), title扶梯逆行检测演示, ).launch()这里results[0].plot()会把检测框、类别标签和置信度直接绘制在输入帧上返回给 Gradio 前端展示。如果你需要实时视频流Gradio 的 Video 组件配合生成器函数会比静态图复杂不少但应急情况下静态图上传检测已经足够撑起演示环节。PyQt5 版本的核心也没差多少只是把cv2.imshow换成了 QLabel 刷新加上一个“开始/停止”按钮和一个告警日志区域。4. 训练自己的数据集格式转换、超参调优与曲线解读4.1 将 VOC XML 批量转换成 YOLOv8 标注格式YOLOv8 的数据管线要求图像和标注文件按固定目录组织标注文件是归一化后的 YOLO txt。毕设拿到手的数据集最常见的是 VOC 的 XML 或 COCO 的 JSON必须先做格式转换。我一般用下面这个脚本把 VOC XML 批量转成 YOLO txtimport os import xml.etree.ElementTree as ET def convert_voc_to_yolo(src_xml, dst_txt, class_names): tree ET.parse(src_xml) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) lines [] for obj in root.findall(object): name obj.find(name).text if name not in class_names: continue class_id class_names.index(name) bbox obj.find(bndbox) x1 int(bbox.find(xmin).text) y1 int(bbox.find(ymin).text) x2 int(bbox.find(xmax).text) y2 int(bbox.find(ymax).text) x_center ((x1 x2) / 2) / img_w y_center ((y1 y2) / 2) / img_h width (x2 - x1) / img_w height (y2 - y1) / img_h lines.append(f{class_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}) with open(dst_txt, w) as f: f.write(\n.join(lines)) class_names [person] convert_voc_to_yolo(annotations/0001.xml, labels/0001.txt, class_names)转换脚本里最需要注意的是图像原始尺寸的读取。size/width和size/height是整张图像的宽高不是标注框的尺寸。如果原始图像被缩放或裁剪过必须同步更新这两个值否则归一化坐标全部错位——模型训练起来就是一个永远不收敛的玄学问题。转换完的目录结构是这样的dataset/ ├── images/ │ ├── train/ │ ├── val/ ├── labels/ │ ├── train/ │ ├── val/ └── data.yamldata.yaml的内容如下path: ./dataset train: images/train val: images/val nc: 1 names: [person]图片数量建议不低于 2000 张其中逆行场景占比 30% 以上。太少的话模型即使能拟合训练集泛化到商场真实监控视角时精度也会明显下滑。如果时间有限宁可减少类别也要保证每类的样本量和标注质量。4.2 训练命令与核心超参数从预训练权重开始微调数据准备好后训练命令本身并不长yolo detect train dataconfig/data.yaml \ modelyolov8s.pt \ epochs50 \ imgsz640 \ batch16 \ lr00.01 \ device0 \ project./runs \ nameescalator_v1参数从左到右解释modelyolov8s.pt是加载 COCO 预训练权重并做微调这比从头训练收敛快得多也是 COCO 预训练大模型能迁移到垂直场景的关键imgsz640是训练分辨率扶梯场景行人尺寸偏小用 640 比 1280 更省显存而且 6GB 显存卡跑 1280 基本要降 batchbatch16在 6GB 显存上是安全值不够时先降到 8不要先去改 imgszlr00.01是初始学习率用预训练权重时保持默认即可。两个值得单独调整的参数epochs和patience。毕设不要一上来就跑 300 epochs先用 50 epochs 跑通全流程看验证集 mAP50 是否还在上升再决定是否续跑。patience默认是 100也就是验证集指标连续 100 轮不提升就早停如果你只跑 50 轮把它调到 10 到 20可以省下不少时间。还有一个隐藏参数workers默认 8在 Windows 上经常因为多进程问题卡死改成 2 或 4 会更稳定。4.3 训练曲线怎么读mAP 之外要看什么训练完成后runs/escalator_v1/目录下会生成results.png包含 box_loss、cls_loss、dfl_loss 以及 precision、recall、mAP50、mAP50-95 共八条曲线。初期最该看的不是 mAP而是 train loss 和 val loss 之间的缺口两条线都下降且靠得近说明模型在正常学习train loss 下降而 val loss 停滞或反弹说明过拟合开始了这时要加数据增强或提前早停。我习惯把曲线判断和肉眼巡检结合。打开验证集预测图重点看三类错误漏检该框的人没有框出来错检把广告牌或模特当成人框偏移人的中心点没有对准。这三类问题各有对应的修法漏检多是置信度阈值定太高或者该视角的样本不够错检需要补充负样本或调高 conf框偏移多半是标注框不规范回头修数据比调参数更有效。如果你在训练过程中发现 loss 曲线振荡很大第一步不是调学习率而是确认data.yaml里的图片路径是不是绝对路径、图片是否完整。路径错误会导致训练时反复读取失败loss 曲线自然就乱成一团。5. 部署与训练中的常见问题排查四段血泪经验5.1 现象一环境装好后 CUDA 不可用现象torch.cuda.is_available()返回False但nvidia-smi里显卡明明存在。原因绝大多数情况下是 PyTorch 装成了 CPU 版。nvidia-smi显示的是驱动支持的 CUDA 版本和 PyTorch 实际编译的运行时版本是两回事。默认 pip 源拉取的就是不带 CUDA 的轮子才会出现这种“驱动正常、PyTorch 却用不了 GPU”的状态。解决卸载后从 PyTorch 官方 cu118 源重装pip uninstall torch torchvision -y pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118装完再检查一次python -c import torch; print(torch.__version__)输出后缀带cu118才是对的版本。这个坑我见人踩过不下十次基本都是没有用--index-url指定预编译源导致的。5.2 现象二训练时 OOM 显存溢出现象batch 设置 16刚开始跑就报CUDA out of memory进程直接崩溃。原因6GB 显存跑 YOLOv8s即使开了 AMP 混合精度在输入分辨率 640 和 batch 16 的组合下梯度累积的峰值显存照样会爆。很多人第一反应是继续降 imgsz但降到 512 以下时扶梯场景的小目标基本就丢了。解决优先降 batch把batch16改到 8 或 4如果仍然不够再考虑把 imgsz 从 640 降到 512。还可以在训练命令里加上cacheFalse默认设置下缓存策略也占显存。实在不行就换yolov8n.pt轻量模型的参数量只有 s 的三分之一显存压力小很多。5.3 现象三逆行行为一直检测不到现象模型能正常框出人但逆行预警永远不触发。原因轨迹方向判定里的扶梯运行方向常量设置反了。摄像头安装在扶梯顶端时画面 Y 轴方向与扶梯实际运行方向相反ESCALATOR_DIRECTION一旦写反反向条件就永远不成立。解决在部署现场放一段已知包含逆行的视频做冒烟测试。在check_reverse函数里临时加一行print(track[-1][1], track[-10][1])观察轨迹 Y 坐标变化方向与实际运动方向是否一致。确认后再把方向常量改回来。这个问题的隐蔽性在于检测结果一直正常界面看起来也没有报错只有预警永远安静。5.4 现象四视频推理卡顿明显现象720p 视频推理只有 10 帧出头界面肉眼可见地掉帧。原因推理循环对每一帧都做了完整的前向计算而视频流的帧率本身是 25 到 30 帧单帧推理时间一旦超过 40 毫秒就会开始累积延迟。CPU 推理的话会更明显。解决两个常用手段。第一给读取帧加间隔每两帧推理一次中间帧直接复用上一次结果帧率立刻翻倍第二把模型从 yolov8s 换成 yolov8nmAP 大约下降两三个点但推理速度提升明显。如果后续要做嵌入式部署可以转成 TensorRT 引擎这在第六章里会提到。注意不要一开始就用轻量模型——先保证检测效果再考虑速度优化这个顺序不要颠倒。6. 从能跑到跑好阈值调优、数据扩充与提速细节系统能运行只是完成了第一步真正让毕设拿高分的是最后这三件事。阈值扫描代替拍脑袋定置信度。conf默认值 0.25 在自己的数据集上不一定合适。在验证集上把conf从 0.1 到 0.6 按 0.05 步长扫一遍记录每个阈值下的 precision 和 recall找到曲线的转角点。扶梯监控场景里漏检危害远大于误报所以我会把实际阈值设在转角点偏低 0.05 的一侧。这个操作只需要写一个几十行的循环脚本跑十分钟就能出结果但它在答辩时是实打实的数据比口头说“我调过参数”有说服力得多。数据扩充要关注物理语义。扶梯场景的典型问题是重复背景多、光照差异大。YOLOv8 内置的hsv_h、hsv_s、scale、flipud等增强参数可以缓解光照过拟合但有一个原则必须记住不要把物理上不可能的增强开太大。比如fliplr左右翻转会改变扶梯的走向语义训练时翻转后的样本就带上了错误的方向信息轨迹判定模型会被误导。如果你开了 0.5 的左右翻转部署时方向判定逻辑必须同步适配。ROI 裁剪是最简单的提速手段。扶梯监控画面里真正需要检测的区域只占全图的三分之一到四分之一。手动标一个矩形 ROI推理前把帧裁剪到 ROI 范围再输入模型背景区域的误检自然消失推理帧率也能明显提升。这个方法只改三行代码但收益非常直观。最后说一个让我后悔过的习惯备份。训练数据、转换脚本、界面代码、配置文件每完成一个阶段就带日期版本归档。我有一次因为修改data.yaml路径后没有备份中途重训花了十二个小时当时那叫一个懊恼。从这以后所有关键配置文件都强制带版本号保存。以上这些技巧都很简单但每一项的效果都能用肉眼看到。阈值扫描花十分钟ROI 裁剪只改三行代码答辩时这两项优化往往是最容易被追问、也最能体现工程能力的地方。希望这些来自实战的部署经验能帮到你让你把更多时间花在真正值得打磨的地方。本文还有配套的精品资源点击获取