YOLOv5火灾烟雾检测：注意力机制与TensorRT部署实战

简介Python毕业设计专用的YOLOv5火灾火焰烟雾检测方案整合了标注数据集、训练好的模型、完整源码与PyQt交互界面适合深度学习或计算机视觉方向的毕业生或开发者参考能够解决火灾检测项目从数据准备到模型部署的完整需求并提供清晰的目录结构。压缩包共74个文件以31个yaml配置、28个Python脚本、5个shell脚本为主辅以图片与说明文档整体仅718KB配置文件用于定义模型与训练参数代码包含训练、推理、界面等核心逻辑命令脚本便于一键运行。目前已有118人学习下载。项目在常规流程外重点实现了TensorRT加速的预处理、推理与后处理并加入串口通信和OpenCV图像绘制适用于实时检测与硬件联动的扩展场景。通过这套代码可掌握从数据标注、模型训练到加速推理部署、PyQt界面集成的完整链路模块划分清晰对完成毕业设计、撰写论文也有直接帮助。1. 从数据集到TensorRT部署这套火灾火焰烟雾检测源码能直接跑通吗做毕业设计选YOLOv5做火灾检测最大的坑不是模型训练不出来而是训练出来的模型没法落地演示。很多人的项目停在在服务器上跑出mAP指标就结束了但答辩时老师要看的是实时画面、检测框、报警联动——这套资源好就好在把整个链条补全了带标注的火灾烟雾数据集、加了CBAM和SE注意力机制的YOLOv5源码、训练好的权重以及串口通信和PyQt界面这些演示环节都拆开了。它的技术主干是TensorRT加速的推理管线用pycuda管理GPU显存用serial.Serial和外部设备通信不是那种只给一个train.py就完事的半成品。适合两类人一类是拿它直接当毕业设计底座的另一类是已经在跑YOLOv5但卡在部署环节、想看看TensorRT和串口联动怎么写的。下面按数据集、模型改造、训练、部署这条线逐层拆。2. 数据集和标注先搞清训练原料的格式与质量2.1 标注格式与目录结构YOLO的txt标签为什么容易出错这套资源里标注好的数据是YOLO格式——每个图片对应一个同名txt文件每行五个数字类别id、归一化后的中心点x、中心点y、宽度w、高度h。这个格式看起来简单但翻车率极高。我经手过的火灾烟雾项目里至少有三分之一的数据集在标签上是有问题的要么是类别id写错要么是归一化坐标越界比如宽度算出来是1.2超过图像边界还有的是标签文件和图片文件名对不上。拿到数据先别急着训练第一件事是写一个脚本全量检查标签合法性。常见的检查逻辑是读取每个txt的每一行确认是五个float值确认坐标在0到1之间确认类别id小于类别总数。归一化坐标越界这个问题特别隐蔽因为它不影响训练启动但会在推理阶段表现为检测框偏移严重模型自信地给出一个框框的位置却是错的。训练时loss会震荡但很多人不会往数据上有问题的方向想。检查完合法性之后把数据按照7:2:1切分成train、val、test三份。注意一定要保证test是独立的不能和train有重叠。我见过有人写数据划分脚本时用了全局shuffle结果同一张图既进了train又进了val训练出来的指标虚高不少答辩时老师一深问就露馅。切分完目录结构按YOLOv5的约定来放就行fire_smoke_dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yamllabels目录的结构必须和images完全镜像train的图片对应train的标签。data.yaml里写上train和val的路径、类别数量nc、类别名字names。这里的路径建议写绝对路径YOLOv5对相对路径的处理在不同的运行目录下会出现找不到数据的玄学问题。2.2 类别定义与样本均衡火灾烟雾检测的类别策略类别怎么定直接决定模型的上限。这套资源里把火灾、火焰、烟雾分开作为独立类别。我拆过不少类似的项目有些直接把fire作为唯一类别烟雾和火焰混在一起导致模型对远处的浓烟和近处的明火无法区分误报率很高。火焰的纹理特征和烟雾的扩散特征在视觉上是完全不同的混成一类是对模型能力的浪费。从检测难度上说火焰是硬的、边缘清晰的、颜色饱和度高的区域烟雾是软的、半透明的、边缘模糊的区域。把两者分开模型只需要学各自的判别特征收敛更快。如果数据集里烟雾样本比火焰少我一般会做三件事对烟雾图片做水平翻转和随机亮度扰动来扩增保证烟雾类别在训练时每个epoch都能被充分采样其次检查类别分布如果某类样本占比极低考虑在loss里给这类加权重最后是从训练集中把那些看起来像烟雾但不是烟雾的负样本比如白云、雾气、水蒸气挑出来单独放一批让模型学会拒绝。数据集的yaml文件里同时带了VOC、COCO、VisDrone、xView这些预置配置说明这套源码本身就兼容多种数据协议的切换。换到自己数据集时只需要改data参数指向自己的yaml即可不需要动其他代码。3. 模型改造CBAM和SE注意力机制到底加在哪一层3.1 从注意力机制的原理看选型为什么用CBAM和SE这套资源有意思的地方在于它同时给出了add(CBAM)common.py和add(SE)common.py两个改动版本对应两个不同的yaml结构文件。两个注意力模块的思路完全不同SESqueeze-and-Excitation关注通道维度的关系先做全局平均池化再用两层全连接学习每个通道的权重把重要的通道放大、不重要的压下去CBAMConvolutional Block Attention Module则是在通道注意力的基础上叠加了空间注意力它会先算通道权重再对特征图的空间位置做注意力加权让模型知道看什么和看哪里。对火灾烟雾检测来说SE够用但不够好。烟雾的特征是通道信息本来就稀疏全局池化会把空间位置信息压掉SE只能让模型更关注纹理和频率相关的通道但烟雾的纹理本身是弥散的通道注意力帮不上大忙。CBAM的空间注意力分支能保留烟雾在画面哪个区域的信息对远距离小目标烟雾的召回有明显帮助。我一般建议在毕业设计里用CBAM版本因为它的收益更直观答辩时讲起来逻辑也更顺。3.2 注入位置CBAM模块如何嵌进YOLOv5的C3结构YOLOv5的主干网络用的是CSP结构C3模块把输入分成两路一路经过多个Bottleneck提取特征另一路直连最后在通道维度上拼接。加注意力最自然的位置是在C3模块的Bottleneck输出之后、concat拼接之前。这样注意力对提取到的特征做重标定保留有效信息抑制背景噪声。实现上在common.py里新增一个C3CBAM类把Bottleneck替换成带CBAM的变体class CBAM(nn.Module): def __init__(self, c1, reduction16, kernel_size7): super().__init__() self.channel_attention nn.Sequential( nn.AdaptiveAvgPool2d(1), nn.Conv2d(c1, c1 // reduction, 1, biasFalse), nn.ReLU(inplaceTrue), nn.Conv2d(c1 // reduction, c1, 1, biasFalse), nn.Sigmoid() ) self.spatial_attention nn.Sequential( nn.Conv2d(2, 1, kernel_size, paddingkernel_size // 2, biasFalse), nn.Sigmoid() ) def forward(self, x): ca self.channel_attention(x) x x * ca avg_out torch.mean(x, dim1, keepdimTrue) max_out, _ torch.max(x, dim1, keepdimTrue) sa torch.cat([avg_out, max_out], dim1) sa self.spatial_attention(sa) return x * sachannel_attention里我用AdaptiveAvgPool2d把空间维度压成1x1再做降维和升维sigmoid输出每个通道的权重。spatial_attention把通道维度的均值和最大值拼成两通道输入用7x7卷积生成空间权重图。CBAM作为即插即用模块可以在yaml的任何一个C3层后面串接不一定非要改C3的结构。参数上reduction设为16是平衡计算量和表达力的常用值通道数很小的层比如64通道可以改成8避免被压得太多。kernel_size用7空间注意力需要足够的感受野来覆盖烟雾的弥散区域。forward里的乘法是广播机制ca权重自动扩展到每个空间位置不用手动repeat。3.3 在yaml文件里改结构从yolov5s到带注意力的变体改完common.py之后还要在models目录下新建对应的yaml配置文件。以yolov5s为例把backbone和head里的C3层换成C3CBAM同时在文件头部加上CBAM模块的引用。这里最容易踩的坑是改了common.py但忘记在yaml里写模块名或者在yaml里写了模块名但import路径不对train.py一启动就直接报AttributeError。我一般会先把yaml文件里的模型结构打印出来确认每一层输出张量的维度符合预期再开始训练。yaml文件里的depth_multiple和width_multiple这两个超参数影响模型深度和宽度。depth_multiple作用于所有的C3里面的Bottleneck数量width_multiple作用于卷积通道数。对火灾烟雾这种目标不算特别小的任务用默认的0.33和0.5即yolov5s就行不必上yolov5l训练速度和推理速度都会吃紧。如果觉得烟雾小目标检出不够可以只调高P2层的输出也就是num_classes那一行不用动但增加一个更浅层的检测头这样对远处小烟雾更友好。4. 训练配置与超参数让模型在火灾数据集上稳定收敛4.1 训练启动命令与关键参数解析数据准备好、模型结构改完就可以开始训练了。这套资源用YOLOv5原版train.py启动命令如下python train.py --data data/fire_smoke.yaml --weights yolov5s.pt --img 640 --batch-size 16 --epochs 100 --device 0 --workers 4--data指向自己的数据集yaml--weights用coco预训练权重做迁移学习这个非常关键。火灾烟雾数据集一般也就几千张从零训练收敛极慢且精度上不去用预训练权重能省掉大量时间。--img 640是在输入尺寸、显存占用和检测精度之间的平衡点如果你的场景是远距离烟雾可以试1280但显存要翻好几倍还不一定收敛得动。batch-size要根据显存来定。16这个值在12G显存上跑yolov5s是安全的如果你用8G显存就要降到8或者4同时配合梯度累积来保证等效batch大小。workers是数据加载的进程数windows上最好设成0否则容易报DataLoader worker进程崩溃。device 0表示用第一张显卡纯CPU训练我不建议试一个epoch可能要跑几十分钟。4.2 超参数文件调整哪些参数对火灾检测影响最大YOLOv5的超参数写在data/hyps/hyp.scratch-low.yaml里。火灾烟雾检测有别于通用检测有几个参数值得单独调lr0: 0.003 lrf: 0.12 momentum: 0.937 weight_decay: 0.0005 fl_gamma: 1.5 hsv_h: 0.01 hsv_s: 0.7 hsv_v: 0.4lr0是初始学习率0.003是迁移学习场景下常用的值比从零训练常用的0.01低防止预训练权重被大步长的梯度冲坏。fl_gamma是focal loss的gamma参数控制难易样本的loss权重火灾烟雾数据里背景占大头的负样本极多把gamma设到1.5能抑制易分类负样本的梯度贡献。hsv_h、hsv_s、hsv_v是颜色增强的范围火焰的颜色偏暖烟雾偏灰我习惯把色调扰动设小一点0.01饱和度扰动反而可以大一些模拟不同光照条件下的火情画面。cos_lr这个参数控制是否用余弦退火学习率调度。我的经验是火灾烟雾数据集规模不大的时候余弦退火容易在中后期把学习率压得太低不如默认的线性衰减来得稳。设成False让学习率按线性方式从lr0衰减到lrflr0乘以0.12。训练时观察train/box_loss、train/cls_loss两个曲线的走势如果loss在某个epoch后不再下降说明学习率已经到平台期了这时候可以提前停止没必要硬跑满100个epoch。4.3 训练过程中的验证指标不要只看mAP训练日志里YOLOv5会输出P精确率、R召回率、mAP50、mAP50-95这几个指标。火灾烟雾检测场景下我最看重的是R召回率因为漏报的代价远高于误报——你宁可把一朵白云框成烟雾也不能让真实的火情从眼皮底下溜走。mAP50-95是更严格的指标它要求预测框和真实框的交并比在0.5到0.95之间都要达到一定水准小目标的分数通常被这个指标拖累。best.pt和last.pt两个权重文件需要理解清楚。last.pt是最后一个epoch的状态best.pt是整个训练过程中在验证集上mAP最高的那个checkpoint。答辩演示时一定用best.pt不能用last.pt——我见过有人图省事直接用last.pt部署结果效果差一截因为训练后期模型可能已经过拟合last.pt的验证指标在下降而best.pt停在最优位置。5. 避坑指南TensorRT加速、串口通信与界面联调的血泪记录5.1 TensorRT引擎构建失败deserialize_cuda_engine加载不了现象用tensorrt.Runtime的deserialize_cuda_engine加载引擎文件时直接报错提示could not find any supported formats或者干脆是空的engine。原因TensorRT引擎和CUDA版本、显卡架构强绑定。你在A机器上用TensorRT 8.5构建的engine文件拿到B机器上如果显卡型号不同比如从30系换到40系或者CUDA版本不一致就没法反序列化。engine文件不是跨平台通用的它跟硬件强相关。解决引擎文件在哪里部署就在哪里构建。source代码里虽然有序列化好的engine但这是在他那台机器上生成的换一台机器必须重新用build_engine从onnx转一次。我一般在部署脚本里先检查engine文件是否存在不存在就自动从onnx构建保证一次拉代码就能跑通def get_engine(onnx_path, engine_path): if os.path.exists(engine_path): with open(engine_path, rb) as f: return runtime.deserialize_cuda_engine(f.read()) # 重新构建引擎 builder trt.Builder(TRT_LOGGER) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, TRT_LOGGER) # 省略parser加载onnx的代码 engine builder.build_cuda_engine(network) return engine5.2 串口通信数据乱码波特率与数据位不匹配现象serial.Serial打开了端口程序不报错但serial_port.readline()读回来的数据是乱码。原因串口通信两端设备的波特率、数据位、停止位、校验位参数不一致。单片机端设的是96008N1Python端写的是115200数据肯定对不上。另外serial.Serial默认没有超时设置如果另一端没有发数据readline会一直阻塞主界面看起来就像死机了。解决连接串口前打印出当前的串口参数和对方设备的配置比对。还有就是要检查USB转串口的驱动是否装好——在设备管理器里看端口号是否存在。如果用的是CH340芯片的转接线Windows必须要装CH340驱动不然Serial打开端口直接抛异常。5.3 CUDA上下文绑定错误pycuda和TensorRT的context冲突现象推理第一帧正常第二帧起报错invalid device context或者直接显存崩溃。原因pycuda.autoinit创建的CUDA context和你手动创建的tensorrt execution context没有做好绑定。TensorRT的推理必须在同一个CUDA context里完成显存分配和kernel执行如果推理循环里反复创建和释放context就会冲突。解决在推理类初始化的地方一次性创建好context和显存buffer推理循环里只做前处理、执行、后处理不重复申请资源。显存拷贝用cuda.memcpy_htod和cuda.memcpy_dtoh输入输出buffer用cuda.pagelocked_empty预分配。因为反序列化engine、创建execution_context、分配device memory这三个动作的耗时远超单次推理把它们从循环里挪出来之后检测速度能提升一个量级。5.4 标签文件和图像文件名不一致训练loss异常低现象训练启动正常但train/box_loss从一开始就掉到0.0几验证集mAP却很低。原因数据切分脚本有bug部分label文件夹里的txt文件名是乱序的和images文件夹里的jpg对不上。模型训练时读到图像A但对应的标签是图像B的loss算出来两个框完全不匹配数值自然会掉得很低因为这等于在学随机数据。解决写一个脚本把labels里所有txt文件拉出来和images里的jpg做差集找出没有对应标签的图片训练前先删掉这些脏数据或用yolo格式的验证工具检查一致性。还有一个常见问题是txt标签文件的内容是空的0个字节这会让模型把那张图当成纯背景如果这类样本多类别的召回率会被严重拉低。5.5 PyQt界面卡死cv2.VideoCapture读取视频与QTimer冲突现象点击界面上的打开摄像头按钮后整个窗口未响应。原因用cv2.VideoCapture在GUI主线程里直接做视频循环读取block住了Qt的事件循环。QTimer的定时回调里如果执行了耗时操作比如TensorRT推理界面也会卡住。解决把视频读取和推理放到QThread工作线程里主线程只负责接收检测结果并更新QLabel上的画面。具体做法是在run方法里做while循环推理结果通过signal发送到主线程class DetectThread(QThread): frame_signal pyqtSignal(QImage) def run(self): cap cv2.VideoCapture(0) while self.running: ret, frame cap.read() detections self.engine.infer(frame) annotated draw_boxes(frame, detections) self.frame_signal.emit(convert_to_qimage(annotated))推理线程里也要注意tensorrt的context和cuda的stream都要在run方法之外创建一次避免每次循环重复初始化。我在这里翻过车一度把engine构建放在了while循环里结果一秒钟只能跑一帧还以为是TensorRT太慢。6. 推理引擎封装与串口联动从脚本到可交付的检测工具6.1 完整的TensorRT推理封装从ONNX到检测框部署的最终形态是一个Engine类完成TensorRT的初始化、推理、后处理三个步骤。后处理部分要自己实现nms非极大值抑制因为TensorRT的输出是原始的张量不包含筛选逻辑。TensorRT有内置的NMS插件efficientNMS但不是所有版本的onnx-tensorrt都能正确解析我一般图稳用pycuda把输出拷回CPU然后用numpy实现筛选。这个步骤在batchsize为1的时候性能损失可以忽略。class TRTEngine: def __init__(self, engine_path, conf_thres0.5, iou_thres0.45): self.logger trt.Logger(trt.Logger.WARNING) self.runtime trt.Runtime(self.logger) with open(engine_path, rb) as f: self.engine self.runtime.deserialize_cuda_engine(f.read()) self.context self.engine.create_execution_context() # 预分配输入输出内存 self.inputs [] self.outputs [] self.allocated_memory self._allocate_buffers() def infer(self, frame): # 预处理resize、归一化、CHW input_blob self.preprocess(frame) # 拷贝到device内存 cuda.memcpy_htod(self.inputs[0][device], input_blob) self.context.execute_v2(self.allocated_memory) # 拷贝回host内存 cuda.memcpy_dtoh(self.outputs[0][host], self.outputs[0][device]) dets self.postprocess(self.outputs[0][host][0]) return dets6.2 串口如何和检测结果联动发送报警标志位检测到火焰或烟雾之后通过串口给下位机发一个报警信号这是整个项目演示时最有视觉冲击力的一环。实现起来就是检测到目标时serial_port.write(b1)没检测到就发b0。下位机收到高电平后驱动蜂鸣器报警整个链路一目了然。注意serial_port.write要在时间上做节流比如连续3帧都检测到才发一次报警避免单帧误检导致蜂鸣器反复启停。我一般会加一个简单的状态机状态为ALARM时连续3帧无检测结果才复位到NORMAL这个滞后比较能扛抖动。串口属于系统资源程序退出时一定要serial_port.close()否则下次启动会报端口被占用。从那以后我每次做部署项目都强制把引擎构建、推理、串口、GUI主循环四件事的线程模型先画在纸上再写代码这四件事的边界一旦混了后面排查耗时是写代码的十倍。这套资源作为毕设底座是完全够用的关键是把每一层的边界吃透。希望帮到你。本文还有配套的精品资源点击获取