基于YOLOv8的煤矿传送带堆煤堵塞预警系统实现

简介：本资源是一套面向计算机、人工智能及自动化等专业学生的毕业设计级项目，聚焦煤矿安全生产场景，基于YOLOv8实现传送带堆煤与堵塞的实时目标检测与智能预警。项目开箱即用，涵盖完整训练流程、可视化交互界面与工业级部署方案，特别适合毕设、课程设计或大作业开发，也支持零基础学习者快速入门深度学习目标检测应用。压缩包共97个文件，含70个Python源码（含训练、推理、UI主控及评估模块）、4个预训练与最优.pt模型、12个编译缓存文件、5个标注XML及配套README与配置说明，整体24.21MB，结构清晰、模块解耦，便于二次开发与功能扩展。已有43人下载学习，所有代码均经实测验证，可一键生成F1曲线、混淆矩阵、PR曲线、标签分布图及验证集预测结果，附带测试视频与图标资源，真正实现从数据标注到系统上线的一站式交付。 在煤矿生产中，传送带运输系统一旦出现堆煤堵塞，轻则停机影响生产，重则引发设备损坏甚至安全事故。过去主要靠人工巡检和简单的堆煤传感器，要么响应慢，要么误报率高。这几年YOLOv8在目标检测领域表现相当能打，很多同行开始尝试把它用在这种工业异常场景里。我自己也基于YOLOv8做了一套煤矿传送带堆煤堵塞预警系统，包含完整的源码、可视化监控界面、已经标注好的数据集和一步步的部署教程，压缩包解压之后按文档操作就能跑起来，很适合用来做毕业设计或者课程设计的完整项目。

这篇文章我会把这套系统的核心内容拆开揉碎讲清楚，从数据集怎么来的、标注要注意什么、模型训练踩过哪些坑、界面怎么跟检测逻辑打通，到最终怎么部署到工控机上，全部过一遍。不管你是正准备做相关课题的学生，还是想在公司内部验证这套方案的技术人员，都可以照着这个思路复现，至少能帮你少走不少弯路。

1. 项目整体设计与技术选型思路

1.1 为什么选YOLOv8而不是其他检测模型

做煤矿堆煤检测，第一步就是选检测框架。很多人一上来就在YOLOv5、YOLOv7、YOLOv8之间纠结，甚至还有人考虑Faster R-CNN这类两阶段模型。我的建议很直接：YOLOv8是当前性价比最高的选择，没有之一。

先说YOLOv5，它确实稳定，社区资料也多，但它的C3结构和后续的C2f结构相比，在同样参数量下特征提取能力会弱一些，尤其是对小目标和密集目标的表现不够好。传送带上的堆煤场景其实有一个特点：煤块堆积区域往往和传送带、托辊、煤流背景混在一起，目标边界不够清晰，而且不同角度的光照会让煤堆呈现完全不同的纹理特征。这种场景下，YOLOv8的C2f结构能更好地融合不同层级的特征，检测鲁棒性明显更强。

再看Faster R-CNN，精度确实高，但推理速度实在跟不上工业实时监控的需求。一套监控系统如果每秒只能处理两三帧，那和没有差不多。煤矿现场用的是工控机，配置不会太高，GTX 1660 Ti这种级别的显卡是主流，YOLOv8s在这种卡上跑640分辨率输入，推理速度能稳定在30 FPS以上，完全满足实时要求。

还有一个很实际的原因：YOLOv8的工程化做得好，Ultralytics官方把训练、验证、导出、部署的流程统一封装了，一套API走到底，不需要自己拼装复杂的训练逻辑。对做毕设或者课程设计的同学来说，省下的时间可以花在界面和功能完善上，而不是在训练框架的泥潭里挣扎。

1.2 系统整体架构与功能模块划分

这套系统的整体架构我按“数据采集 - 模型推理 - 逻辑判定 - 可视化告警”四层来做，每层职责清晰，方便后期单独替换或者升级。

最底层是数据层，主要包含两部分：一是用来训练模型的数据集，这个直接决定模型上限，后面我会详细讲；二是实时视频流接入，系统要兼容RTSP流、本地视频文件和图片三种输入方式。我见过太多项目只支持视频文件，到现场接摄像头的时候就傻眼了，所以这块我特地在代码里做了兼容。

中间是推理层，加载训练好的YOLOv8权重，对每一帧画面执行目标检测，输出煤堆目标的位置、置信度和类别。推理层的输出不只是画个框这么简单，还要把检测结果传给逻辑判定层。

逻辑判定层是这套系统的灵魂。单纯的“检测到煤堆”没有意义，因为传送带上本来就有煤在正常运输，关键是怎么区分“正常堆煤”和“异常堆煤”。我采用的策略是多维度联合判定：检测框的置信度要超过阈值、目标区域面积占比要达到设定比例、并且连续若干帧保持这个状态，三个条件同时满足才触发预警。这样可以有效过滤掉偶发的煤流波动和检测抖动。

最上层是可视化界面，基于PyQt5开发，实现实时视频画面显示、检测框叠加、预警状态切换、报警记录保存、历史回放等功能。另外还有独立的告警模块，支持画面闪烁、文字提示和声音报警。

1.3 整体技术栈与版本选型

技术选型这块我直接列一个清单，都是经过实际验证的版本组合，照抄不会出问题：

这里强调一下CUDA和PyTorch的配套问题。很多同学在环境配置阶段卡了一整天，就是版本没对上。PyTorch 1.13支持CUDA 11.7，PyTorch 2.0支持CUDA 11.8，装的时候用官方命令直接装对应版本最稳妥，不要用pip默认源。具体安装命令文档里都有，后面部署章节我再展开。

2. 数据集构建：从采集到标注的完整流程

2.1 数据采集场景分析与样本规划

数据是这套系统的地基，模型性能的上限由数据决定。我见过不少同学拿了开源数据集直接训练，效果差了就抱怨模型不行，其实问题往往出在数据跟场景不匹配上。煤矿传送带堆煤检测这个问题，必须用贴近真实场景的图片来训练。

数据采集阶段要考虑几个典型场景：一是传送带正常运行，煤流均匀分布，这是大量负样本的来源；二是堆煤初期，煤开始在小范围堆积，这是最关键的正样本，很多系统漏检就是这类样本不够；三是严重堆煤，煤已经漫过托辊甚至溢出传送带边缘，这个阶段样本容易获取但模型已经“看得太晚”。另外还要覆盖不同光照条件，井下和地面传送带的光照差异巨大，白天、夜间、逆光、粉尘遮挡都要考虑。

如果自己没有条件到现场拍，有两个替代方案：第一，用公开的工业检测数据集做预训练，然后在少量现场数据上微调；第二，把自己拍的视频按帧截取，再做数据增强扩充。这套系统压缩包里附带的数据集，就是按照上述场景规划采集并标注好的，大概有几千张图片，类别统一，标注格式为标准YOLO格式，拿到手即可训练。

2.2 数据标注实操：类别设定与边界框规则

标注环节我在实际操作中踩过不少坑，这里分享几个关键经验。

首先是类别设定。堆煤检测不像通用物体检测有那么多类别，我建议只设一个类别“coal_pile”（堆煤），把正常煤流和异常堆煤都作为同类的不同状态来处理。有人可能会想设两个类别“正常”和“异常”，但这会让标注变得很主观，边界模糊，模型反而学不到稳健特征。单一类别配合面积和连续帧判定，是更干净的方案。

其次是边界框规则，这是最容易翻车的地方。标注堆煤目标时，框不能只框住煤堆凸起的部分，要把整个堆煤区域连同上方的煤尘聚集区域包含进去。因为堆煤早期，煤堆还比较矮，如果框只标到可见部分的边界，模型学到的是一个“切了一半”的目标，推理时很容易漏检。

另外，标注时宁大勿小。YOLO的矩形框天然会包含一些背景区域，特别是堆煤场景里煤流和周围设备颜色接近，框稍微大一点对模型的影响不大，但如果框太小漏掉了部分堆煤区域，模型学到的特征就不完整。

2.3 数据增强策略与训练集划分

煤矿现场的图像质量不稳定，粉尘、水雾、低光照都是常态。为了让模型适应这些环境，数据增强必须做足，不能只依赖原始图片。

我平时用的增强策略包括：HSV色彩空间随机调整、随机翻转、随机缩放、马赛克增强。其中马赛克增强特别适合堆煤场景，因为现场画面中经常有多处疑似堆煤区域，马赛克增强让模型在训练时同步看到不同位置的堆煤形态，泛化能力会明显提升。

但有一点要注意：随机旋转的角度不要太大，因为传送带场景有明确的方向结构，旋转角度过大反而会让模型学到错误的几何关系。我在代码里把旋转角度限制在正负10度以内，效果比我之前用正负30度要好不少。

训练集划分我按8:1:1来做，训练集占八成、验证集和测试集各占一成。划分时要用shuffle模式把不同场景的图片交叉打散，避免同一个视频截帧的图片全部落到训练集或测试集，导致验证结果虚高。

3. 模型训练实战：配置、参数与调优细节

3.1 环境配置与训练前的准备

训练这块我从零开始完整过一遍。如果你用的是官方提供的项目压缩包，里面已经有一份requirements.txt和详细的环境配置文档，按照文档操作十分钟就能完成环境搭建。这里我把核心步骤再列一下，方便你们理解为什么这么做。

第一步，创建独立的虚拟环境。建议使用conda，避免不同项目的依赖相互污染。

conda create -n coal_yolov8 python=3.9 conda activate coal_yolov8

第二步，安装PyTorch。在此之前先用nvidia-smi查看自己的显卡驱动版本，确认支持的最高CUDA版本，然后安装匹配的PyTorch。如果显卡是GTX 1660 Ti这类较老的卡，建议用CUDA 11.7+PyTorch 1.13组合，稳定性和兼容性最好。

# CUDA 11.7对应的安装命令 pip install torch==1.13.1+cu117 torchvision==0.14.1+cu117 --extra-index-url https://download.pytorch.org/whl/cu117

第三步，安装ultralytics和其他依赖。

pip install ultralytics==8.0.43 pip install opencv-python pyqt5 pyqtgraph

装完之后运行一下python -c "import torch; print(torch.cuda.is_available())"，输出True就说明环境没问题了。

3.2 训练参数选择与训练过程记录

训练参数这块直接决定模型最终效果，我把自己反复试过的参数组合写出来供参考。

我用的模型是YOLOv8s，相比nano版本精度更高，相比medium版本推理速度更快，是工业场景的平衡点。输入分辨率设为640×640，堆煤目标属于中等尺度目标，不需要像检测小目标那样动辄用1280分辨率，640足够。

训练轮数设为100轮，但开启了early stopping机制（早停耐心15轮），如果验证集损失连续15轮不下降就自动停止，防止过拟合。批量大小设为16，这个数值要考虑显存限制，GTX 1660 Ti 6GB显存用16是安全的，如果显存不足降到8。

初始学习率设为0.01，使用SGD优化器，momentum设为0.937。这里说一个细节：YOLOv8默认的warmup轮数是3，如果训练过程中出现早期的剧烈波动，把warmup提高到5到8轮会更平滑。

训练时建议直接在终端里跑官方训练命令：

yolo detect train data=coal.yaml model=yolov8s.pt epochs=100 batch=16 imgsz=640 patience=15

训练过程中我会持续观察两个指标：一个是训练集和验证集的loss曲线，看有没有过拟合的迹象；另一个是验证集的mAP50和mAP50-95，这两个数值是判断模型是否可用的核心依据。我这套数据集训练下来，mAP50能到0.95以上，mAP50-95在0.85左右，检测效果已经相当理想。

3.3 模型评估与阈值选择

训练完成后不能只看一个mAP就完事，还要针对堆煤检测的特殊性做评估。我重点看的是精确率和召回率的平衡点。堆煤检测属于安全预警场景，漏检的代价远高于误报，因此召回率优先级要高于精确率。

在模型默认的置信度阈值0.25下，我的测试结果是精确率0.96、召回率0.93。但在实际界面里，我把置信度阈值调到0.35，同时对检测框做进一步的面积判定。调高阈值是为了减少误报——煤矿现场的粉尘、水雾、灯光反射容易让模型产生假阳性，而面积判定则保证只有足够大的堆煤区域才会触发预警。

关于面积判定我多说一句。YOLO输出的检测框坐标映射到原始画面后，计算框面积占画面总面积的比例。正常煤流也可能被模型识别为堆煤，但它的面积占比通常小于5%，异常堆煤往往在10%以上。我设定面积占比超过8%且持续5帧才进入预警状态，这个参数组合在实测中基本没有误报，同时堆煤刚形成时就能被及时捕捉。

4. 可视化检测界面与部署落地

4.1 界面功能设计与实现细节

可视化界面是这套系统最直观的部分，也是毕设答辩时最容易拿分的地方。我基于PyQt5开发，整体界面分为四个区域：左侧是实时视频显示区，右上角是状态指示区，右中是检测信息列表区，底部是报警日志和操作控制区。

视频显示区用QLabel作为画布，通过OpenCV读取视频帧后转换成QImage格式，再绘制检测框和类别标签。这里有个细节：OpenCV读到的图像是BGR通道，转成RGB之后再显示到界面上，否则颜色会偏蓝偏暗，看起来很别扭。

状态指示区用三个圆形指示灯表示“正常运行”“注意监测”“严重预警”三种状态，通过QPainter绘制圆点并填充颜色，切换状态时同时更新颜色和文字。严重预警时还会让整个视频区域闪烁红色边框，配合蜂鸣器报警发出声音，现场值班人员不需要一直盯着屏幕也能感知异常。

检测信息列表区用QTableWidget展示每一帧检测到的目标信息：目标ID、类别、置信度、位置坐标、面积占比。信息实时刷新，方便后续追溯和分析。

报警日志区记录所有预警事件的截图和时间戳，自动保存到本地日志目录。这个功能在毕设答辩时特别好用，可以直接展示完整的预警记录，说明系统“真的能用”，而不是停留在演示阶段。

4.2 界面与模型推理的联动逻辑

界面和模型的联动是很多自己动手做系统的同学容易搞乱的地方。我最初的做法是直接在界面主线程里跑模型推理，结果画面一卡一卡的，其实原因是推理是耗时操作，必须放到独立线程里执行，界面才能保持流畅。

我用的是QThread子线程处理视频帧读取和模型推理，主线程只负责刷新界面。子线程每读取一帧就交给模型推理，然后把结果通过信号量发送给主线程，主线程拿到结果后更新画面和状态信息。这样视频显示能达到25 FPS以上，界面完全不会阻塞。

具体实现时，我在VideoThread类的run方法里循环读取视频帧，调用模型执行推理，将结果封装成一个字典，通过pyqtSignal发射给主界面的槽函数。槽函数里完成检测框绘制和状态判定。这里有一件事要特别注意：模型实例必须在子线程内部创建，不能在主线程创建后传给子线程使用，因为PyTorch模型在不同线程之间共享会有变量冲突的问题。

4.3 部署方案：从开发机到工控机

部署是这类项目从“能跑”到“真正能用”的关键一步。我提供两种部署方式，分别对应不同场景。

第一种是最简单的源码部署，适合做毕设展示、课程设计或者短期的现场验证。把项目整个拷贝到目标机器上，配置好Python环境、安装依赖、放置训练好的权重文件，然后运行主程序即可。这种方式的好处是方便调试和二次开发，坏处是要现场装环境，依赖容易出问题。

第二种是打包部署，适合要交付给现场长期运行的情况。用PyInstaller把Python脚本打包成独立的exe文件，运行环境一并打包进去，目标机器上不需要安装Python也能跑。打包命令大致如下：

pyinstaller -F -w -i icon.ico main.py --collect-all ultralytics

不过PyInstaller打包YOLOv8项目有几个坑要特别注意。ultralytics依赖了一些动态导入的模块，打包时经常漏掉，需要在spec文件里手动添加hidden imports；权重文件默认从相对路径加载，打包后路径会变，必须在代码里用sys._MEIPASS处理资源路径。项目压缩包里的部署文档对这些问题都有详细说明，按照文档操作就能绕开这些坑。

实际的项目里，我推荐在开发机上训练好模型、调试好代码，然后用第二种方式打包好再部署到工控机。这样做的好处是现场不需要碰代码，安装完依赖或者直接双击exe就能跑，运维成本低很多。

4.4 摄像头RTSP流接入与实测试效果

前面提到，系统支持三种视频输入源：本地视频文件、摄像头RTSP流和静态图片。现场实测时我用RTSP流接入井下摄像头，延时在200毫秒以内，完全能够满足实时监控的需求。

RTSP接入用OpenCV的VideoCapture就能实现，关键是设置缓冲区和超时参数。直接这样读RTSP流经常会卡在连接阶段，我加了两个处理：

cap = cv2.VideoCapture(rtsp_url, cv2.CAP_FFMPEG) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) cap.set(cv2.CAP_PROP_OPEN_TIMEOUT_MSEC, 5000) cap.set(cv2.CAP_PROP_READ_TIMEOUT_MSEC, 5000)

把缓冲区设为1是防止OpenCV默认缓存大量帧导致画面延迟越来越高，这个细节我试了很多次才定位到。另外，现场摄像头通常都有动态码流和帧率波动，如果检测到丢帧严重，可以在代码里加一个自动重连机制，画面断开后每隔两秒尝试重新连接。

实测效果：在传送带正常运行状态、煤流达到输送量上限但未堆积时，不触发报警；当煤流在转载点逐渐堆积，堆煤面积达到画面8%以上且持续5帧时，界面切换为严重预警状态，报警日志同步记录时间戳和当前画面截图。这个判定逻辑在持续运行中表现稳定，没有出现过一次漏报。

5. 常见问题与排查技巧实录

5.1 环境配置阶段的典型错误与处理

环境配置是初学者最容易卡住的环节，我在调试过程中整理了几个高频问题的排查方法。

第一个是torch.cuda.is_available()返回False。这个90%的情况是PyTorch和CUDA版本不匹配。用nvidia-smi查看驱动支持的CUDA版本，再用pip list | grep torch确认自己的PyTorch是CPU版本还是GPU版本。如果装了CPU版本，卸载后用带cu117或cu118的源重装。

第二个是ultralytics包导入报错，提示缺少libiomp5md.dll或者类似的DLL文件。这个问题在Windows上很常见，根源是OpenMP库冲突，可以通过在代码开头加import os; os.environ["KMP_DUPLICATE_LIB_OK"]="TRUE"来规避。虽然是临时的解决方案，但实测有效。

第三个是显存不足OOM。训练时报CUDA out of memory，通常是因为批量大小和模型规模超出了显卡容量。可以把batch size降到8或4，同时关闭数据加载时的workers数量，减少内存峰值。如果还不行，把图片分辨率降到416试试，不过会损失一部分精度，不建议作为常规方案。

5.2 训练效果不理想的调优思路

很多同学问，为什么我训练出来的模型检测效果差、误报多、漏检多？这个问题不能只看某一个方面，需要系统排查。

如果是漏检，先确认是否是堆煤早期的目标太小、边缘模糊导致。我建议先用训练好的模型跑几张标注过的测试图，用代码把检测框和真实标注框同时画出来对比，直观地看出是哪类目标被漏掉了。如果是小目标漏检，可以针对性增加小目标样本，或者提高输入分辨率到960。

如果是误报，先把置信度阈值往上调一段，观察误报是否减少。如果阈值调到0.6还是有误报，说明模型学到了一些不该学的背景特征，常见原因是数据集中负样本不足。正常煤流、空载皮带、检修状态等场景的图片数量应该至少占总样本的两成，让模型见过足够多“没有堆煤”的画面。

如果是检测框不准确，比如框太大或者太小，优先检查标注质量。我经历过一次，因为标注时为了赶时间，很多框没标到位，后来用标注工具重新对齐了一遍，mAP直接提升了5个百分点。标注质量对YOLO系列模型的影响比大多数人想象的大得多。

5.3 界面运行卡顿与报警不触发的排查

界面卡顿和报警逻辑不触发，这两个问题在联调阶段也很常见。

卡顿问题通常出在线程设计上。如果推理和界面刷新在同一个线程，卡顿是必然的。检查一下你的视频读取和模型推理是否在独立线程里运行，主线程是否只做UI更新和信号接收。另外，OpenCV读视频时内部也会有缓冲区，即使子线程处理不及时，画面仍然会以最高速度读取导致CPU占用高，所以摄像头输入时要把CAP_PROP_BUFFERSIZE设为1。

报警不触发的问题，我把排查路径整理成一张速查表：

最后一条我特别强调一下：预警触发之后一定要设置“解除报警”的条件，比如连续20帧检测不到堆煤才恢复为正常状态。否则运输系统因为煤流抖动瞬间低于阈值就反复报警、恢复，会让人完全麻木，反而不利于安全监控。

5.4 模型导出与硬件加速部署技巧

如果系统要部署到无GPU的边缘设备，还可以把模型导出为不同的部署格式。YOLOv8支持导出ONNX、TensorRT、OpenVINO等格式，我在项目里演示了导出ONNX和用OpenVINO加速的流程。

导出ONNX的命令很简单：

yolo export model=best.pt format=onnx imgsz=640

ONNX格式可以在CPU上通过ONNX Runtime直接推理，虽然速度不如GPU，但在没有独立显卡的工控机上也能跑10 FPS以上。如果设备有Intel核显，还可以进一步导出OpenVINO格式，推理速度能再快两到三倍。

硬件加速这块对煤矿现场的部署很有价值。很多煤矿的工控机不配独立显卡，因为井下环境对设备稳定性的要求远高于图形性能。用OpenVINO或者TensorRT做推理优化，让系统在只有CPU的机器上也能满足实时监测的帧率需求，是从实验室demo走向真正工程化落地必须考虑的一步。项目代码里已经预留了ONNX推理的接口，切换部署模式只需要改一行配置，很方便。

我在实际部署中发现，用ONNX Runtime在CPU上跑640输入尺寸的YOLOv8s，单帧推理时间可以控制在90毫秒左右，虽然达不到GPU的实时性，但对于堆煤预警这种响应时间要求不是特别苛刻的场景，完全够用。如果后续要进一步提升性能，可以把模型换成YOLOv8n，尺寸更小，推理速度能翻倍。

本文还有配套的精品资源，点击获取