前阵子有个做市政道路养护的朋友找我说他们单位现在还在靠人工翻监控视频统计路面标线的磨损情况一个人盯一天屏幕下来眼都是花的问我能不能做个自动检测的小工具。我想了想与其临时拼凑一个脚本给他不如直接整理出一套完整的方案于是就有了这套基于YOLOv8的路面标志线检测与识别系统。它包含了完整的Python源码、PyQt5图形界面、可训练的数据集和训练代码从数据标注到模型训练再到界面封装一整条链路都是通的不是那种只能跑通演示demo的半成品。这篇博文我就把整个项目的设计思路、关键代码、踩坑经验全部写出来无论你是要做毕业设计还是想把手头的人工统计工作自动化都能直接照着抄作业。1. 系统整体设计与技术选型很多人拿到一个目标检测项目就急着跑代码结果代码能跑但换个场景就废了。这套系统之所以能用在路面标线场景核心不在于代码多花哨而在于选型和架构一开始就是对着真实需求去的。我先把设计逻辑拆开讲清楚你后面改造成别的检测任务也能套用这套思路。1.1 检测模型为什么选YOLOv8而不是其他方案路面标志线检测本质上是一个典型的目标检测任务候选方案有传统的图像处理方案颜色分割、边缘检测、Hough变换直线检测和深度学习方案。传统方案在固定机位、固定光照下或许能凑合用但一遇到阴影遮挡、路面反光、标线磨损就彻底失效。深度学习方案里工业上常用的是YOLO系列而YOLOv8是目前综合性价比最高的选择。拿YOLOv8和上一代YOLOv5比最大的变化是它从Anchor-Based范式彻底转到了Anchor-Free范式。用大白话说YOLOv5需要预先定义一堆固定大小的锚框再让模型去“猜”目标相对于锚框的偏移而YOLOv8直接预测目标中心点到四条边的距离省掉了锚框聚类这一大堆超参数。表面看只是一个检测头的变化实际训练和调参时省了太多事——你不用再去纠结K-Means聚类出来的锚框尺寸是否合理也不用在换数据集时重新算一遍锚框。在主干网络和特征融合上YOLOv8用到了C2f模块替代之前的C3模块。C2f借鉴了CSPNet的分流思想把输入特征图分成两支其中一支经过更多层的残差连接再合并这样做的好处是梯度回传路径更丰富网络加深后信息不容易丢失。对路面标线这种小目标来说特征保持能力直接决定了小箭头、小虚线能不能被检出来。实测下来在同一批路标数据上YOLOv8s的mAP比YOLOv5s大约高2到3个百分点而推理速度几乎没有下降。另外还值得一提的是ultralytics官方库的工程化程度。它把训练、验证、推理、导出封装成几行命令就能搞定日志、权重保存、损失曲线可视化都是自带的。相比之下你要是去读YOLOv5的源码仓库里还散落着一堆历史遗留代码YOLOv8的接口设计明显更现代适合我们这种以“解决业务问题”为目标而不是以“研究网络结构”为目标的开发者。1.2 界面层PyQt5解决了什么实际问题模型本身做得再好如果只有命令行输出这东西在真实项目中根本交付不出去。道路养护部门的人不会用命令行他们需要的是双击打开、选一个视频文件、看到画好框的界面、最后导出一份统计表。界面层我选PyQt5而不是Web框架核心原因有三个。第一个原因是部署成本。Flask/FastAPI做Web界面模型得放在服务端前端还得处理推流和延迟最后还要找一个服务器一直开着。PyQt5是桌面应用直接双击.exe或者跑Python脚本就能用拿一台带显卡的普通电脑就能部署完全不需要额外维护服务器。第二个原因是OpenCV和Qt之间的数据交换非常顺。OpenCV读出来的是numpy数组格式的帧PyQt5的QImage可以直接从内存数据构造中间不需要序列化没有Web方案里那种base64传输的开销。处理视频流时这种零拷贝式的数据传递是保证实时性的关键。第三个原因是PyQt5的信号槽机制非常适合处理“耗时任务”和“界面更新”的并发问题。模型推理是GPU上的密集计算如果直接写在界面按钮的点击回调里UI线程被卡住整个窗口就会出现“未响应”。PyQt5的QThread加信号槽可以很优雅地把推理放到子线程检测完的帧通过信号发回UI线程刷新显示。这套模式我在后面第3章会给出完整的代码框架。1.3 功能模块拆解一个完整的检测系统应该包含什么这套系统的功能模块划分如下你在设计自己的界面时也可以参考这个清单看看有没有遗漏图片检测选择一张路面图片模型推理后把检测框、类别标签、置信度画在图上。视频检测选择一段行车记录仪视频按帧读取、逐帧推理、实时显示结果。摄像头实时检测调用本机USB摄像头或RTSP网络摄像头实现实时路面标线识别。检测结果统计按类别统计当前画面中各类标志线数量以表格或柱状图形式展示。模型权重管理在界面上切换不同的训练权重文件例如白天模型、夜晚模型、雨天模型。结果导出将检测结果类别、坐标、置信度导出为CSV文件便于后续统计和存档。模块划分的原则很朴素一个功能对应一个独立的类界面逻辑和推理逻辑彻底分离。这样做的好处是即使哪一天你想把PyQt5换成Tkinter或者把桌面应用改成Web服务推理部分的代码完全不用动只需要重写界面层。2. 环境配置、数据集制作与训练参数详解这一章是整个项目的实操核心。很多同学的项目最后效果差不是模型结构选得不好而是数据和训练参数出了问题。我会把你从零到一训练一个路面标线模型的全过程捋一遍包括环境坑、标注格式、参数调优这些常规文档里不会写细的内容。2.1 环境配置从Python版本到显卡驱动的一次性踩坑汇总先说最基础的环境版本组合。这套系统我当时用的是Python 3.10 PyTorch 2.1.2 CUDA 11.8 ultralytics 8.1.x的组合跑了几个月的训练和推理稳定性很理想。Python版本不建议上3.12因为部分依赖库的预编译轮子更新不及时装起来会遇到一堆源码编译报错纯属浪费时间。安装PyTorch时如果你的显卡是NVIDIA的建议用官方指定的CUDA版本安装命令不要直接pip install torch那样默认装CPU版训练慢到怀疑人生# CUDA 11.8版本 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # CUDA 12.1版本 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完确认一下GPU是否可用import torch print(torch.cuda.is_available()) # 输出True才算正常 print(torch.cuda.get_device_name(0)) # 输出你的显卡型号接着安装YOLOv8依赖库和PyQt5pip install ultralytics pip install pyqt5 pyqt5-tools这里有个容易踩的坑是显卡驱动版本与CUDA版本不匹配。驱动版本太老PyTorch即使装对了也调用不了GPU。解决办法是把NVIDIA驱动更新到较新版本新驱动对旧CUDA是向下兼容的但旧驱动不支持新CUDA。针对热搜里大家常问的“GTX 1660Ti跑YOLOv8可以吗”实测下来完全没问题。我用的显卡就是1660Ti 6GB显存用yolov8s模型图像尺寸640x640batch size设为8训练150个epoch大约耗时四五个小时。推理阶段实时性也够单帧推理耗时在40到60毫秒之间做视频检测差不多能跑到15到20帧每秒完全够用。2.2 路面标线数据集的制作标注格式与数据划分训练一个有效的标线检测模型数据比模型结构重要得多。路面标志线的类别定义我这里给出一个常用方案你可以根据实际需求增减类别ID类别名称说明0straight直行箭头1left左转箭头2right右转箭头3straight_left直行或左转箭头4stop_line停止线5crosswalk人行横道斑马线6double_yellow双黄线7dashed_line车道虚线数据来源有两类一是开源数据集比如BDD100K里的部分路面元素但需要筛选过滤因为开源数据集标注归类不一定和你的业务完全一致二是用行车记录仪自己采集。我个人更建议自己采集一部分因为实际场景里的标线磨损程度、拍摄角度、道路材质只有真实场景才能覆盖到。采集时注意覆盖晴天、阴天、雨天、逆光、夜间等各种光照情况。标注工具我用的是LabelImg界面虽然是老古董但胜在轻量好用。安装方式pip install labelimg labelimg标注时务必选择YOLO格式保存生成的是同名的.txt文件每行对应一个标注框格式为class_id x_center y_center width height这里有个无数新手栽过跟头的地方x_center、y_center、width、height全部是归一化坐标数值范围在0到1之间用标注框的实际像素坐标除以图片的宽或高得到。你可以在LabelImg里看到这些数值如果训练出来的模型完全检测不到目标十有八九是坐标没归一化或者类别ID从1开始而不是从0开始。数据集目录结构固定如下ultralytics框架训练时只认这个格式road_mark_dataset/ ├── images/ │ ├── train/ # 训练图片 │ └── val/ # 验证图片 ├── labels/ │ ├── train/ # 训练标签 │ └── val/ # 验证标签 └── data.yaml # 数据集配置文件data.yaml内容也列出来train: road_mark_dataset/images/train val: road_mark_dataset/images/val nc: 8 names: [straight, left, right, straight_left, stop_line, crosswalk, double_yellow, dashed_line]数据划分建议训练集和验证集按8比2划分划分时注意不要有同一段视频的连续帧既出现在训练集又出现在验证集否则验证集指标会虚高。我一般写个脚本按视频文件维度来划分确保同一个视频的帧只进其中一个集合。2.3 训练参数的选择逻辑对照显存和数据集规模来定训练参数不是拍脑袋乱设的每一项背后都有实打实的逻辑。下面这份参数表是我在1660Ti上反复调出来的推荐配置附带说明为什么这么设参数推荐值说明modelyolov8s.pt预训练权重起步迁移学习收敛快imgsz640平衡精度和速度标线不算极小目标640够用epochs150配合早停实际训练中100轮后基本收敛batch86GB显存的上限附近如果爆显存就降到4workers4数据加载进程数视CPU核心数调整device0指定使用第一张GPUlr00.005用预训练权重时学习率不宜太大freeze0数据量充足时不需要冻结数据少可冻结前10层对应的训练命令是yolo detect train dataroad_mark_dataset/data.yaml modelyolov8s.pt epochs150 imgsz640 batch8 workers4 device0 lr00.005这里着重说两个参数。第一个是freeze。如果你只有一两百张图片做训练完整微调所有层极易过拟合模型会背下训练集的特征而泛化不了。这时候可以在命令里加上freeze10冻结主干网络前10层的参数相当于把主干当作一个固定的特征提取器只训练后面的检测头。实测数据量少的情况下冻结策略可以让验证集的mAP提升好几个点。第二个是imgsz不要盲目往大了调。虽然大分辨率对小目标友好但显存占用是按平方增长的640调到1280显存占用差不多翻4倍1660Ti直接爆显存。训练开始后工作目录下会生成runs/detect/train目录。里面最重要的文件是results.csv和results.png。results.png包含每轮的box_loss、cls_loss、dfl_loss以及验证集的mAP50、mAP50-95曲线。想看原始数值就打开results.csv每一行对应一个epoch的完整指标。损失函数曲线怎么判断训练状态这里给一个我的经验判断表曲线表现状态判断应对措施train loss下降但val loss不降反升过拟合增加数据增强降低epoch数或冻结更多层train loss和val loss都平稳不动学习率过小或模型容量不足调大lr0或换yolov8m模型loss震荡剧烈学习率过大或batch太小降低lr0适当增大batchmAP50稳定在0.8以上但mAP50-95偏低框定位精度不足增大imgsz或延长训练至收敛训练完成后有两个权重文件best.pt是按验证集指标保存的最优权重last.pt是最后一轮权重。推理和部署一律用best.ptlast.pt基本没有使用的价值。2.4 数据增强小数据集救星当你的数据量攒不够几千张时数据增强是提升泛化能力最有效的手段。ultralytics框架在训练时默认开启Mosaic4增强也就是把4张图随机裁剪拼接成一张新图。这招对小目标特别有效因为每张图里目标的尺寸被缩小了模型被迫学会在更小的尺度上识别标线相当于免费的“多尺度训练”。除了框架自带的增强你还可以在data.yaml同级目录里放一个augment.yaml自定义HSV色域扰动、旋转、平移、缩放等参数。以路面标线为例有一个无比重要的增强项是亮度对比度扰动。不同时间段的阳光角度差异极大早上顺光、中午强反光、傍晚逆光标线的视觉表现完全不同。建议把hsv_h、hsv_s、hsv_v扰动范围调大一点让模型见过各种曝光条件下的标线实测能明显降低晴天训练的模型在阴天场景下的掉点幅度。3. PyQt5界面开发与YOLOv8模型集成界面层是整个系统的门面也是绝大多数初学者最头痛的部分。我见过太多项目模型训练得好好的一写界面就崩溃要么卡死要么内存不断暴涨。这一章我就把完整的架构设计和关键代码写出来你只要按这个思路来界面层和推理层的坑基本都能避开。3.1 界面布局设计怎么排布才符合使用直觉PyQt5界面我采用的是典型的左右分栏布局。左侧是控制面板宽度固定280像素从上到下依次排列模型权重选择下拉框、检测模式切换按钮图片/视频/摄像头、置信度阈值滑块、检测结果统计表格、导出CSV按钮。右侧是显示区图片检测模式下用一个QLabel视频和摄像头模式下用一个自定义的VideoWidget控件。这个布局逻辑就是“左边操作右边看结果”完全符合人的直觉。置信度阈值滑块做出实时调节效果拖动的过程中下一次推理立即生效这样用户在检测效果不佳时能马上找到一个合适的阈值不用重启程序。控制面板底部还要放一个状态栏用来显示当前的推理帧率、每帧推理耗时、GPU使用率。这个信息在调试时非常有用你能直观地看到哪个环节是性能瓶颈。3.2 用QThread解决界面卡死多线程架构的核心这是整个界面层最重要的一块。YOLOv8推理在一个普通视频上每帧大约耗时50毫秒如果这段推理代码直接写在按钮回调里界面的刷新就被阻塞了窗口直接变成“未响应”状态。解决这个问题就靠QThread。思路拆开很清晰UI主线程只负责接收控件事件、刷新界面推理线程负责读视频帧、跑模型、把结果帧通过信号发给UI线程。两个线程之间通过信号槽通信完全解耦。import cv2 import numpy as np from PyQt5.QtCore import QThread, pyqtSignal from ultralytics import YOLO class DetectThread(QThread): # 定义信号发送处理完的帧和检测结果 frame_ready pyqtSignal(np.ndarray, list) fps_updated pyqtSignal(float) def __init__(self, model_path, source, conf_thres0.35): super().__init__() self.model YOLO(model_path) self.source source # 可以是图片路径、视频路径或摄像头索引 self.conf_thres conf_thres self.running True self.type image if source.lower().endswith((.jpg, .png, .bmp)) else video def run(self): if self.type image: frame cv2.imread(self.source) results self.model(frame, confself.conf_thres) self.frame_ready.emit(frame, results) return cap cv2.VideoCapture(self.source) fps_counter 0 start_time cv2.getTickCount() while self.running and cap.isOpened(): ret, frame cap.read() if not ret: break results self.model(frame, confself.conf_thres) self.frame_ready.emit(frame, results) # 计算FPS fps_counter 1 if fps_counter 10: end_time cv2.getTickCount() time_diff (end_time - start_time) / cv2.getTickFrequency() current_fps fps_counter / time_diff self.fps_updated.emit(current_fps) fps_counter 0 start_time cv2.getTickCount() cap.release() def stop(self): self.running False self.wait()这里通过pyqtSignal(np.ndarray, list)直接把OpenCV读到的原始帧和YOLO的检测结果对象发到主线程。主线程接收后负责画框和显示。信号参数用numpy数组不需要额外的类型转换Qt内部会序列化传参实测性能开销完全可以忽略。3.3 图像显示与结果绘制从OpenCV到Qt的格式转换主线程收到帧和检测结果后要做的第一件事是把YOLO返回的结果转换成坐标和类别信息。YOLOv8的result对象结构是Results里面boxes属性包含xyxy坐标、置信度和类别ID。遍历并画框的代码这样写def draw_results(self, frame, results): for box in results[0].boxes: x1, y1, x2, y2 box.xyxy[0].tolist() conf float(box.conf[0]) cls_id int(box.cls[0]) # 坐标转成int类型OpenCV画图不支持float坐标 x1, y1, x2, y2 int(x1), int(y1), int(x2), int(y2) class_name self.class_names[cls_id] # 画框 cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) label f{class_name} {conf:.2f} cv2.putText(frame, label, (x1, y1 - 8), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 255, 0), 1) return frame画好框后要把这个OpenCV格式的BGR帧转换成PyQt5能显示的格式。这一步容易出错的地方是通道顺序OpenCV是BGRQt的QImage默认是RGB如果直接转会得到颜色偏蓝的画面。正确做法是先把BGR转RGB再构造QImage最后转成QPixmap放到QLabel里from PyQt5.QtGui import QImage, QPixmap def update_display(self, frame): rgb_frame cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) h, w, ch rgb_frame.shape bytes_per_line ch * w qt_img QImage(rgb_frame.data, w, h, bytes_per_line, QImage.Format_RGB888) pixmap QPixmap.fromImage(qt_img) # 按显示区域大小缩放保持宽高比 scaled_pixmap pixmap.scaled(self.video_label.size(), Qt.KeepAspectRatio, Qt.SmoothTransformation) self.video_label.setPixmap(scaled_pixmap)这里有一个隐藏的大坑QImage(rgb_frame.data, ...)只是引用了numpy数组的内存地址一旦该数组在后续被回收或改写显示画面就会出现花屏。解决方法是构造QImage时用copy()复制一份数据QImage(rgb_frame.data.copy(), ...)。虽然多了一次内存拷贝但安全得多尤其是在视频流场景里帧数据会被反复覆盖。3.4 完整推理流程的信号槽接线别在回调函数里做重活主线程里的槽函数要遵守一个铁律能不干活就不干活只做显示和状态更新。有的同学喜欢在槽函数里再调用一次模型推理或者做数据统计存数据库这些都是错误示范。槽函数运行在UI线程一旦开始处理耗时逻辑界面照样卡。正确顺序是推理线程emit(frame, results) - 槽函数draw_results画框 - update_display显示 - 更新统计表格。整套流程耗时在几毫秒以内界面丝般顺滑。统计表格的更新逻辑是遍历检测结果里每个类别计数然后写到QTableWidget里def update_statistics(self, results): class_counts {} for box in results[0].boxes: cls_id int(box.cls[0]) class_name self.class_names[cls_id] class_counts[class_name] class_counts.get(class_name, 0) 1 self.table_widget.setRowCount(len(class_counts)) for row, (name, count) in enumerate(class_counts.items()): self.table_widget.setItem(row, 0, QTableWidgetItem(name)) self.table_widget.setItem(row, 1, QTableWidgetItem(str(count)))导出CSV的功能在另一个线程里做还是可以在UI线程做数据量小的时候几百行UI线程里写文件也就十几毫秒问题不大但如果你要导出整段视频的检测结果可能上万行就必须放到子线程否则界面会顿一下。我建议统一把导出操作放到QThreadPool的全局线程池里执行代码不复杂但体验提升明显。4. 常见问题与排查技巧实录这套系统从开发到实际使用我前前后后调试了一个多月踩过的坑比写代码的时间还长。这一章我把问题症状、原因、解决方法整理成速查表再挑几个典型问题进行详细复盘希望能让你少走弯路。4.1 训练阶段的典型问题问题现象根本原因解决方法训练时loss一直是nan学习率过大梯度爆炸把lr0降到0.001以下或开启warmupmAP始终为0标注坐标未归一化、类别ID越界检查labels目录下的txt文件内容坐标是否在0-1之间训练集loss很低但验证集几乎检测不到严重过拟合增加数据量加数据增强或用freeze冻结主干不同类别的mAP差异巨大某类样本数过少对该类做过采样复制或用增强手段扩样本训练速度极慢GPU利用率很低workers设太小CPU喂不上数据调大workers到4或8确认硬盘是SSD抽两个最典型的细说。第一个是“mAP为0”。这个问题90%的情况是标签文件和图片对不上。用LabelImg保存YOLO格式时生成的txt文件名必须和图片名完全一致但如果你是从某个开源数据集拷过来的很可能出现图片是JPEG后缀而标签是JPG后缀的情况比如road_001.jpg对应road_001.JPG.txt这样的标签ultralytics根本找不到。排查方法很简单写个脚本遍历图片目录和标签目录打印出两边文件名集合的差集一眼就看出来了。第二个是“训练loss下降但mAP不稳”。这个现象很常见我在一次雨天数据不足时遇到过。原因是验证集的场景分布和训练集差异过大模型在训练集上拟合得不错但一遇到没见过的雨天场景就拉胯。解决思路不是盲目加epochs而是增加雨天的训练样本哪怕只有几十张配合Mosaic增强效果都会好很多。我当时的做法是收集了几段雨天行车视频每隔10帧抽一帧标注后总共增加了80多张雨天数据mAP50直接涨了5个百分点。4.2 PyQt5界面运行阶段的典型问题问题现象根本原因解决方法界面启动后黑屏或报OpenGL错误显卡驱动问题或Qt OpenGL渲染异常安装最新显卡驱动设置环境变量QT_OPENGLsoftware强制软件渲染点击打开摄像头后程序崩溃摄像头索引错或分辨率设置过高try/except捕获先用默认分辨率640x480测试视频播放一段时间后内存暴涨每帧都new了QImage且没有释放检查是否对QImage调用了copy()确保旧的QPixmap被重新赋值而非叠加推理结果出来了但画面还是旧帧信号槽连接方式错误确认connect用的是DirectConnection还是QueuedConnection跨线程必须用QueuedConnection点击按钮后界面假死几秒推理代码写在了UI线程改造成QThread方案把推理全部挪到子线程“PyQt5界面无显示”这个问题在热搜里出现了不止一次。究其原因很多是PyQt5和OpenCV在初始化时对OpenGL上下文的争抢导致的。我遇到过一次在虚拟机里运行完全黑屏的情况最后通过设置环境变量QT_OPENGLsoftware解决了。但注意软件渲染帧率会明显下降如果做摄像头实时显示最好还是升级显卡驱动来兼容硬件渲染软件渲染只是临时保底方案。另外一个界面层的高频问题是用QTimer定时器去读取视频帧。初学者很容易这么写QTimer每隔30毫秒触发一次在回调里cap.read()然后推理。这个方案的隐患在于如果某次推理耗时超过30毫秒定时器事件就会堆积界面卡顿越来越严重。正确做法就是第3章介绍的QThread方案把读帧和推理放到一个循环里靠帧率自然控制节奏而不是靠定时器去强行驱动。4.3 检测效果不理想时的调优方向当你训练出来的模型在实际使用时发现漏检、误检先别急着重新训练按下面的顺序排查一下先看置信度阈值。模型输出的每个框都带一个置信度默认阈值设在0.25到0.35之间。如果你发现检测出了很多乱七八糟的框把滑动条往上调到0.5误检会明显减少如果你发现该检出来的标线漏掉了一半把阈值降下来到0.15试试。这个调参在界面上就是拖动滑块的事几十秒就能试出经验值。再看NMS非极大值抑制的IoU阈值。YOLOv8本身内置了NMS但如果同一个目标被重复画出多个框说明NMS的IoU阈值设置偏大可以调小到0.4左右。如果两个相邻的真实目标被合并成了一个框说明阈值偏小调到0.7左右看看。最后看训练数据本身。模型检测不到某种标线最直接的原因是该类别在训练集里的样本太少或者特征太单一。比如你的训练集里斑马线都是完好的实际场景中斑马线被磨损后颜色变浅、形状残缺模型自然认不出来。解决办法是去网上爬一些不同磨损程度的路面图片补充进训练集。4.4 模型导出与部署扩展训练好的best.pt如果只在本机用PyQt5调用那还挺省事。但如果你想把模型部署到其他环境比如嵌入式设备或者做成C服务ultralytics框架也提供了非常完善的导出功能# 导出为ONNX格式 yolo export modelbest.pt formatonnx # 导出为TensorRT引擎仅限NVIDIA GPU速度最快 yolo export modelbest.pt formatengine device0TensorRT导出后在英伟达显卡上的推理速度能提升2到3倍我用1660Ti实测yolov8s从45毫秒一帧优化到22毫秒一帧。如果你要把模型部署到RK3588这类边缘设备上可以先用ONNX导出再转换成RKNN格式。整个流程里最容易出问题的是算子的兼容性像一些自定义的激活函数在转换时可能报错这时候需要回到ultralytics的配置里把对应算子替换成标准算子。5. 写在最后的几点实用建议这套系统做完以后我个人的体会是目标检测项目的难点从来不在“跑通一个现成模型”而在数据和工程化。YOLOv8本身已经足够成熟网上教程铺天盖地但你真要做一个能交付的东西数据采集标注、界面交互、异常处理、性能优化每一块都要花力气。如果你是想拿这个项目做毕设我建议把重点放在“为什么这么选型”和“如何优化效果”上讲解清楚这几个点答辩时老师问什么你都能接住。如果你是工作中要用我建议优先把你手头的标注数据整理好模型架构不必折腾yolov8s已经能扛住大多数场景。最后再分享一个小技巧训练时最好给每个实验设置不同的name参数比如yolo detect train ... nameexp_rain_v2这样每次实验的日志和权重都会单独存一个文件夹方便横向对比。千万别所有实验都堆在同一个目录里不然跑完一轮你根本分不清哪个权重对应哪次实验。这个小习惯能帮你节省的调试时间比任何花哨的调参技巧都管用。
基于YOLOv8与PyQt5的路面标志线检测识别系统
前阵子有个做市政道路养护的朋友找我说他们单位现在还在靠人工翻监控视频统计路面标线的磨损情况一个人盯一天屏幕下来眼都是花的问我能不能做个自动检测的小工具。我想了想与其临时拼凑一个脚本给他不如直接整理出一套完整的方案于是就有了这套基于YOLOv8的路面标志线检测与识别系统。它包含了完整的Python源码、PyQt5图形界面、可训练的数据集和训练代码从数据标注到模型训练再到界面封装一整条链路都是通的不是那种只能跑通演示demo的半成品。这篇博文我就把整个项目的设计思路、关键代码、踩坑经验全部写出来无论你是要做毕业设计还是想把手头的人工统计工作自动化都能直接照着抄作业。1. 系统整体设计与技术选型很多人拿到一个目标检测项目就急着跑代码结果代码能跑但换个场景就废了。这套系统之所以能用在路面标线场景核心不在于代码多花哨而在于选型和架构一开始就是对着真实需求去的。我先把设计逻辑拆开讲清楚你后面改造成别的检测任务也能套用这套思路。1.1 检测模型为什么选YOLOv8而不是其他方案路面标志线检测本质上是一个典型的目标检测任务候选方案有传统的图像处理方案颜色分割、边缘检测、Hough变换直线检测和深度学习方案。传统方案在固定机位、固定光照下或许能凑合用但一遇到阴影遮挡、路面反光、标线磨损就彻底失效。深度学习方案里工业上常用的是YOLO系列而YOLOv8是目前综合性价比最高的选择。拿YOLOv8和上一代YOLOv5比最大的变化是它从Anchor-Based范式彻底转到了Anchor-Free范式。用大白话说YOLOv5需要预先定义一堆固定大小的锚框再让模型去“猜”目标相对于锚框的偏移而YOLOv8直接预测目标中心点到四条边的距离省掉了锚框聚类这一大堆超参数。表面看只是一个检测头的变化实际训练和调参时省了太多事——你不用再去纠结K-Means聚类出来的锚框尺寸是否合理也不用在换数据集时重新算一遍锚框。在主干网络和特征融合上YOLOv8用到了C2f模块替代之前的C3模块。C2f借鉴了CSPNet的分流思想把输入特征图分成两支其中一支经过更多层的残差连接再合并这样做的好处是梯度回传路径更丰富网络加深后信息不容易丢失。对路面标线这种小目标来说特征保持能力直接决定了小箭头、小虚线能不能被检出来。实测下来在同一批路标数据上YOLOv8s的mAP比YOLOv5s大约高2到3个百分点而推理速度几乎没有下降。另外还值得一提的是ultralytics官方库的工程化程度。它把训练、验证、推理、导出封装成几行命令就能搞定日志、权重保存、损失曲线可视化都是自带的。相比之下你要是去读YOLOv5的源码仓库里还散落着一堆历史遗留代码YOLOv8的接口设计明显更现代适合我们这种以“解决业务问题”为目标而不是以“研究网络结构”为目标的开发者。1.2 界面层PyQt5解决了什么实际问题模型本身做得再好如果只有命令行输出这东西在真实项目中根本交付不出去。道路养护部门的人不会用命令行他们需要的是双击打开、选一个视频文件、看到画好框的界面、最后导出一份统计表。界面层我选PyQt5而不是Web框架核心原因有三个。第一个原因是部署成本。Flask/FastAPI做Web界面模型得放在服务端前端还得处理推流和延迟最后还要找一个服务器一直开着。PyQt5是桌面应用直接双击.exe或者跑Python脚本就能用拿一台带显卡的普通电脑就能部署完全不需要额外维护服务器。第二个原因是OpenCV和Qt之间的数据交换非常顺。OpenCV读出来的是numpy数组格式的帧PyQt5的QImage可以直接从内存数据构造中间不需要序列化没有Web方案里那种base64传输的开销。处理视频流时这种零拷贝式的数据传递是保证实时性的关键。第三个原因是PyQt5的信号槽机制非常适合处理“耗时任务”和“界面更新”的并发问题。模型推理是GPU上的密集计算如果直接写在界面按钮的点击回调里UI线程被卡住整个窗口就会出现“未响应”。PyQt5的QThread加信号槽可以很优雅地把推理放到子线程检测完的帧通过信号发回UI线程刷新显示。这套模式我在后面第3章会给出完整的代码框架。1.3 功能模块拆解一个完整的检测系统应该包含什么这套系统的功能模块划分如下你在设计自己的界面时也可以参考这个清单看看有没有遗漏图片检测选择一张路面图片模型推理后把检测框、类别标签、置信度画在图上。视频检测选择一段行车记录仪视频按帧读取、逐帧推理、实时显示结果。摄像头实时检测调用本机USB摄像头或RTSP网络摄像头实现实时路面标线识别。检测结果统计按类别统计当前画面中各类标志线数量以表格或柱状图形式展示。模型权重管理在界面上切换不同的训练权重文件例如白天模型、夜晚模型、雨天模型。结果导出将检测结果类别、坐标、置信度导出为CSV文件便于后续统计和存档。模块划分的原则很朴素一个功能对应一个独立的类界面逻辑和推理逻辑彻底分离。这样做的好处是即使哪一天你想把PyQt5换成Tkinter或者把桌面应用改成Web服务推理部分的代码完全不用动只需要重写界面层。2. 环境配置、数据集制作与训练参数详解这一章是整个项目的实操核心。很多同学的项目最后效果差不是模型结构选得不好而是数据和训练参数出了问题。我会把你从零到一训练一个路面标线模型的全过程捋一遍包括环境坑、标注格式、参数调优这些常规文档里不会写细的内容。2.1 环境配置从Python版本到显卡驱动的一次性踩坑汇总先说最基础的环境版本组合。这套系统我当时用的是Python 3.10 PyTorch 2.1.2 CUDA 11.8 ultralytics 8.1.x的组合跑了几个月的训练和推理稳定性很理想。Python版本不建议上3.12因为部分依赖库的预编译轮子更新不及时装起来会遇到一堆源码编译报错纯属浪费时间。安装PyTorch时如果你的显卡是NVIDIA的建议用官方指定的CUDA版本安装命令不要直接pip install torch那样默认装CPU版训练慢到怀疑人生# CUDA 11.8版本 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # CUDA 12.1版本 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完确认一下GPU是否可用import torch print(torch.cuda.is_available()) # 输出True才算正常 print(torch.cuda.get_device_name(0)) # 输出你的显卡型号接着安装YOLOv8依赖库和PyQt5pip install ultralytics pip install pyqt5 pyqt5-tools这里有个容易踩的坑是显卡驱动版本与CUDA版本不匹配。驱动版本太老PyTorch即使装对了也调用不了GPU。解决办法是把NVIDIA驱动更新到较新版本新驱动对旧CUDA是向下兼容的但旧驱动不支持新CUDA。针对热搜里大家常问的“GTX 1660Ti跑YOLOv8可以吗”实测下来完全没问题。我用的显卡就是1660Ti 6GB显存用yolov8s模型图像尺寸640x640batch size设为8训练150个epoch大约耗时四五个小时。推理阶段实时性也够单帧推理耗时在40到60毫秒之间做视频检测差不多能跑到15到20帧每秒完全够用。2.2 路面标线数据集的制作标注格式与数据划分训练一个有效的标线检测模型数据比模型结构重要得多。路面标志线的类别定义我这里给出一个常用方案你可以根据实际需求增减类别ID类别名称说明0straight直行箭头1left左转箭头2right右转箭头3straight_left直行或左转箭头4stop_line停止线5crosswalk人行横道斑马线6double_yellow双黄线7dashed_line车道虚线数据来源有两类一是开源数据集比如BDD100K里的部分路面元素但需要筛选过滤因为开源数据集标注归类不一定和你的业务完全一致二是用行车记录仪自己采集。我个人更建议自己采集一部分因为实际场景里的标线磨损程度、拍摄角度、道路材质只有真实场景才能覆盖到。采集时注意覆盖晴天、阴天、雨天、逆光、夜间等各种光照情况。标注工具我用的是LabelImg界面虽然是老古董但胜在轻量好用。安装方式pip install labelimg labelimg标注时务必选择YOLO格式保存生成的是同名的.txt文件每行对应一个标注框格式为class_id x_center y_center width height这里有个无数新手栽过跟头的地方x_center、y_center、width、height全部是归一化坐标数值范围在0到1之间用标注框的实际像素坐标除以图片的宽或高得到。你可以在LabelImg里看到这些数值如果训练出来的模型完全检测不到目标十有八九是坐标没归一化或者类别ID从1开始而不是从0开始。数据集目录结构固定如下ultralytics框架训练时只认这个格式road_mark_dataset/ ├── images/ │ ├── train/ # 训练图片 │ └── val/ # 验证图片 ├── labels/ │ ├── train/ # 训练标签 │ └── val/ # 验证标签 └── data.yaml # 数据集配置文件data.yaml内容也列出来train: road_mark_dataset/images/train val: road_mark_dataset/images/val nc: 8 names: [straight, left, right, straight_left, stop_line, crosswalk, double_yellow, dashed_line]数据划分建议训练集和验证集按8比2划分划分时注意不要有同一段视频的连续帧既出现在训练集又出现在验证集否则验证集指标会虚高。我一般写个脚本按视频文件维度来划分确保同一个视频的帧只进其中一个集合。2.3 训练参数的选择逻辑对照显存和数据集规模来定训练参数不是拍脑袋乱设的每一项背后都有实打实的逻辑。下面这份参数表是我在1660Ti上反复调出来的推荐配置附带说明为什么这么设参数推荐值说明modelyolov8s.pt预训练权重起步迁移学习收敛快imgsz640平衡精度和速度标线不算极小目标640够用epochs150配合早停实际训练中100轮后基本收敛batch86GB显存的上限附近如果爆显存就降到4workers4数据加载进程数视CPU核心数调整device0指定使用第一张GPUlr00.005用预训练权重时学习率不宜太大freeze0数据量充足时不需要冻结数据少可冻结前10层对应的训练命令是yolo detect train dataroad_mark_dataset/data.yaml modelyolov8s.pt epochs150 imgsz640 batch8 workers4 device0 lr00.005这里着重说两个参数。第一个是freeze。如果你只有一两百张图片做训练完整微调所有层极易过拟合模型会背下训练集的特征而泛化不了。这时候可以在命令里加上freeze10冻结主干网络前10层的参数相当于把主干当作一个固定的特征提取器只训练后面的检测头。实测数据量少的情况下冻结策略可以让验证集的mAP提升好几个点。第二个是imgsz不要盲目往大了调。虽然大分辨率对小目标友好但显存占用是按平方增长的640调到1280显存占用差不多翻4倍1660Ti直接爆显存。训练开始后工作目录下会生成runs/detect/train目录。里面最重要的文件是results.csv和results.png。results.png包含每轮的box_loss、cls_loss、dfl_loss以及验证集的mAP50、mAP50-95曲线。想看原始数值就打开results.csv每一行对应一个epoch的完整指标。损失函数曲线怎么判断训练状态这里给一个我的经验判断表曲线表现状态判断应对措施train loss下降但val loss不降反升过拟合增加数据增强降低epoch数或冻结更多层train loss和val loss都平稳不动学习率过小或模型容量不足调大lr0或换yolov8m模型loss震荡剧烈学习率过大或batch太小降低lr0适当增大batchmAP50稳定在0.8以上但mAP50-95偏低框定位精度不足增大imgsz或延长训练至收敛训练完成后有两个权重文件best.pt是按验证集指标保存的最优权重last.pt是最后一轮权重。推理和部署一律用best.ptlast.pt基本没有使用的价值。2.4 数据增强小数据集救星当你的数据量攒不够几千张时数据增强是提升泛化能力最有效的手段。ultralytics框架在训练时默认开启Mosaic4增强也就是把4张图随机裁剪拼接成一张新图。这招对小目标特别有效因为每张图里目标的尺寸被缩小了模型被迫学会在更小的尺度上识别标线相当于免费的“多尺度训练”。除了框架自带的增强你还可以在data.yaml同级目录里放一个augment.yaml自定义HSV色域扰动、旋转、平移、缩放等参数。以路面标线为例有一个无比重要的增强项是亮度对比度扰动。不同时间段的阳光角度差异极大早上顺光、中午强反光、傍晚逆光标线的视觉表现完全不同。建议把hsv_h、hsv_s、hsv_v扰动范围调大一点让模型见过各种曝光条件下的标线实测能明显降低晴天训练的模型在阴天场景下的掉点幅度。3. PyQt5界面开发与YOLOv8模型集成界面层是整个系统的门面也是绝大多数初学者最头痛的部分。我见过太多项目模型训练得好好的一写界面就崩溃要么卡死要么内存不断暴涨。这一章我就把完整的架构设计和关键代码写出来你只要按这个思路来界面层和推理层的坑基本都能避开。3.1 界面布局设计怎么排布才符合使用直觉PyQt5界面我采用的是典型的左右分栏布局。左侧是控制面板宽度固定280像素从上到下依次排列模型权重选择下拉框、检测模式切换按钮图片/视频/摄像头、置信度阈值滑块、检测结果统计表格、导出CSV按钮。右侧是显示区图片检测模式下用一个QLabel视频和摄像头模式下用一个自定义的VideoWidget控件。这个布局逻辑就是“左边操作右边看结果”完全符合人的直觉。置信度阈值滑块做出实时调节效果拖动的过程中下一次推理立即生效这样用户在检测效果不佳时能马上找到一个合适的阈值不用重启程序。控制面板底部还要放一个状态栏用来显示当前的推理帧率、每帧推理耗时、GPU使用率。这个信息在调试时非常有用你能直观地看到哪个环节是性能瓶颈。3.2 用QThread解决界面卡死多线程架构的核心这是整个界面层最重要的一块。YOLOv8推理在一个普通视频上每帧大约耗时50毫秒如果这段推理代码直接写在按钮回调里界面的刷新就被阻塞了窗口直接变成“未响应”状态。解决这个问题就靠QThread。思路拆开很清晰UI主线程只负责接收控件事件、刷新界面推理线程负责读视频帧、跑模型、把结果帧通过信号发给UI线程。两个线程之间通过信号槽通信完全解耦。import cv2 import numpy as np from PyQt5.QtCore import QThread, pyqtSignal from ultralytics import YOLO class DetectThread(QThread): # 定义信号发送处理完的帧和检测结果 frame_ready pyqtSignal(np.ndarray, list) fps_updated pyqtSignal(float) def __init__(self, model_path, source, conf_thres0.35): super().__init__() self.model YOLO(model_path) self.source source # 可以是图片路径、视频路径或摄像头索引 self.conf_thres conf_thres self.running True self.type image if source.lower().endswith((.jpg, .png, .bmp)) else video def run(self): if self.type image: frame cv2.imread(self.source) results self.model(frame, confself.conf_thres) self.frame_ready.emit(frame, results) return cap cv2.VideoCapture(self.source) fps_counter 0 start_time cv2.getTickCount() while self.running and cap.isOpened(): ret, frame cap.read() if not ret: break results self.model(frame, confself.conf_thres) self.frame_ready.emit(frame, results) # 计算FPS fps_counter 1 if fps_counter 10: end_time cv2.getTickCount() time_diff (end_time - start_time) / cv2.getTickFrequency() current_fps fps_counter / time_diff self.fps_updated.emit(current_fps) fps_counter 0 start_time cv2.getTickCount() cap.release() def stop(self): self.running False self.wait()这里通过pyqtSignal(np.ndarray, list)直接把OpenCV读到的原始帧和YOLO的检测结果对象发到主线程。主线程接收后负责画框和显示。信号参数用numpy数组不需要额外的类型转换Qt内部会序列化传参实测性能开销完全可以忽略。3.3 图像显示与结果绘制从OpenCV到Qt的格式转换主线程收到帧和检测结果后要做的第一件事是把YOLO返回的结果转换成坐标和类别信息。YOLOv8的result对象结构是Results里面boxes属性包含xyxy坐标、置信度和类别ID。遍历并画框的代码这样写def draw_results(self, frame, results): for box in results[0].boxes: x1, y1, x2, y2 box.xyxy[0].tolist() conf float(box.conf[0]) cls_id int(box.cls[0]) # 坐标转成int类型OpenCV画图不支持float坐标 x1, y1, x2, y2 int(x1), int(y1), int(x2), int(y2) class_name self.class_names[cls_id] # 画框 cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 255, 0), 2) label f{class_name} {conf:.2f} cv2.putText(frame, label, (x1, y1 - 8), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 255, 0), 1) return frame画好框后要把这个OpenCV格式的BGR帧转换成PyQt5能显示的格式。这一步容易出错的地方是通道顺序OpenCV是BGRQt的QImage默认是RGB如果直接转会得到颜色偏蓝的画面。正确做法是先把BGR转RGB再构造QImage最后转成QPixmap放到QLabel里from PyQt5.QtGui import QImage, QPixmap def update_display(self, frame): rgb_frame cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) h, w, ch rgb_frame.shape bytes_per_line ch * w qt_img QImage(rgb_frame.data, w, h, bytes_per_line, QImage.Format_RGB888) pixmap QPixmap.fromImage(qt_img) # 按显示区域大小缩放保持宽高比 scaled_pixmap pixmap.scaled(self.video_label.size(), Qt.KeepAspectRatio, Qt.SmoothTransformation) self.video_label.setPixmap(scaled_pixmap)这里有一个隐藏的大坑QImage(rgb_frame.data, ...)只是引用了numpy数组的内存地址一旦该数组在后续被回收或改写显示画面就会出现花屏。解决方法是构造QImage时用copy()复制一份数据QImage(rgb_frame.data.copy(), ...)。虽然多了一次内存拷贝但安全得多尤其是在视频流场景里帧数据会被反复覆盖。3.4 完整推理流程的信号槽接线别在回调函数里做重活主线程里的槽函数要遵守一个铁律能不干活就不干活只做显示和状态更新。有的同学喜欢在槽函数里再调用一次模型推理或者做数据统计存数据库这些都是错误示范。槽函数运行在UI线程一旦开始处理耗时逻辑界面照样卡。正确顺序是推理线程emit(frame, results) - 槽函数draw_results画框 - update_display显示 - 更新统计表格。整套流程耗时在几毫秒以内界面丝般顺滑。统计表格的更新逻辑是遍历检测结果里每个类别计数然后写到QTableWidget里def update_statistics(self, results): class_counts {} for box in results[0].boxes: cls_id int(box.cls[0]) class_name self.class_names[cls_id] class_counts[class_name] class_counts.get(class_name, 0) 1 self.table_widget.setRowCount(len(class_counts)) for row, (name, count) in enumerate(class_counts.items()): self.table_widget.setItem(row, 0, QTableWidgetItem(name)) self.table_widget.setItem(row, 1, QTableWidgetItem(str(count)))导出CSV的功能在另一个线程里做还是可以在UI线程做数据量小的时候几百行UI线程里写文件也就十几毫秒问题不大但如果你要导出整段视频的检测结果可能上万行就必须放到子线程否则界面会顿一下。我建议统一把导出操作放到QThreadPool的全局线程池里执行代码不复杂但体验提升明显。4. 常见问题与排查技巧实录这套系统从开发到实际使用我前前后后调试了一个多月踩过的坑比写代码的时间还长。这一章我把问题症状、原因、解决方法整理成速查表再挑几个典型问题进行详细复盘希望能让你少走弯路。4.1 训练阶段的典型问题问题现象根本原因解决方法训练时loss一直是nan学习率过大梯度爆炸把lr0降到0.001以下或开启warmupmAP始终为0标注坐标未归一化、类别ID越界检查labels目录下的txt文件内容坐标是否在0-1之间训练集loss很低但验证集几乎检测不到严重过拟合增加数据量加数据增强或用freeze冻结主干不同类别的mAP差异巨大某类样本数过少对该类做过采样复制或用增强手段扩样本训练速度极慢GPU利用率很低workers设太小CPU喂不上数据调大workers到4或8确认硬盘是SSD抽两个最典型的细说。第一个是“mAP为0”。这个问题90%的情况是标签文件和图片对不上。用LabelImg保存YOLO格式时生成的txt文件名必须和图片名完全一致但如果你是从某个开源数据集拷过来的很可能出现图片是JPEG后缀而标签是JPG后缀的情况比如road_001.jpg对应road_001.JPG.txt这样的标签ultralytics根本找不到。排查方法很简单写个脚本遍历图片目录和标签目录打印出两边文件名集合的差集一眼就看出来了。第二个是“训练loss下降但mAP不稳”。这个现象很常见我在一次雨天数据不足时遇到过。原因是验证集的场景分布和训练集差异过大模型在训练集上拟合得不错但一遇到没见过的雨天场景就拉胯。解决思路不是盲目加epochs而是增加雨天的训练样本哪怕只有几十张配合Mosaic增强效果都会好很多。我当时的做法是收集了几段雨天行车视频每隔10帧抽一帧标注后总共增加了80多张雨天数据mAP50直接涨了5个百分点。4.2 PyQt5界面运行阶段的典型问题问题现象根本原因解决方法界面启动后黑屏或报OpenGL错误显卡驱动问题或Qt OpenGL渲染异常安装最新显卡驱动设置环境变量QT_OPENGLsoftware强制软件渲染点击打开摄像头后程序崩溃摄像头索引错或分辨率设置过高try/except捕获先用默认分辨率640x480测试视频播放一段时间后内存暴涨每帧都new了QImage且没有释放检查是否对QImage调用了copy()确保旧的QPixmap被重新赋值而非叠加推理结果出来了但画面还是旧帧信号槽连接方式错误确认connect用的是DirectConnection还是QueuedConnection跨线程必须用QueuedConnection点击按钮后界面假死几秒推理代码写在了UI线程改造成QThread方案把推理全部挪到子线程“PyQt5界面无显示”这个问题在热搜里出现了不止一次。究其原因很多是PyQt5和OpenCV在初始化时对OpenGL上下文的争抢导致的。我遇到过一次在虚拟机里运行完全黑屏的情况最后通过设置环境变量QT_OPENGLsoftware解决了。但注意软件渲染帧率会明显下降如果做摄像头实时显示最好还是升级显卡驱动来兼容硬件渲染软件渲染只是临时保底方案。另外一个界面层的高频问题是用QTimer定时器去读取视频帧。初学者很容易这么写QTimer每隔30毫秒触发一次在回调里cap.read()然后推理。这个方案的隐患在于如果某次推理耗时超过30毫秒定时器事件就会堆积界面卡顿越来越严重。正确做法就是第3章介绍的QThread方案把读帧和推理放到一个循环里靠帧率自然控制节奏而不是靠定时器去强行驱动。4.3 检测效果不理想时的调优方向当你训练出来的模型在实际使用时发现漏检、误检先别急着重新训练按下面的顺序排查一下先看置信度阈值。模型输出的每个框都带一个置信度默认阈值设在0.25到0.35之间。如果你发现检测出了很多乱七八糟的框把滑动条往上调到0.5误检会明显减少如果你发现该检出来的标线漏掉了一半把阈值降下来到0.15试试。这个调参在界面上就是拖动滑块的事几十秒就能试出经验值。再看NMS非极大值抑制的IoU阈值。YOLOv8本身内置了NMS但如果同一个目标被重复画出多个框说明NMS的IoU阈值设置偏大可以调小到0.4左右。如果两个相邻的真实目标被合并成了一个框说明阈值偏小调到0.7左右看看。最后看训练数据本身。模型检测不到某种标线最直接的原因是该类别在训练集里的样本太少或者特征太单一。比如你的训练集里斑马线都是完好的实际场景中斑马线被磨损后颜色变浅、形状残缺模型自然认不出来。解决办法是去网上爬一些不同磨损程度的路面图片补充进训练集。4.4 模型导出与部署扩展训练好的best.pt如果只在本机用PyQt5调用那还挺省事。但如果你想把模型部署到其他环境比如嵌入式设备或者做成C服务ultralytics框架也提供了非常完善的导出功能# 导出为ONNX格式 yolo export modelbest.pt formatonnx # 导出为TensorRT引擎仅限NVIDIA GPU速度最快 yolo export modelbest.pt formatengine device0TensorRT导出后在英伟达显卡上的推理速度能提升2到3倍我用1660Ti实测yolov8s从45毫秒一帧优化到22毫秒一帧。如果你要把模型部署到RK3588这类边缘设备上可以先用ONNX导出再转换成RKNN格式。整个流程里最容易出问题的是算子的兼容性像一些自定义的激活函数在转换时可能报错这时候需要回到ultralytics的配置里把对应算子替换成标准算子。5. 写在最后的几点实用建议这套系统做完以后我个人的体会是目标检测项目的难点从来不在“跑通一个现成模型”而在数据和工程化。YOLOv8本身已经足够成熟网上教程铺天盖地但你真要做一个能交付的东西数据采集标注、界面交互、异常处理、性能优化每一块都要花力气。如果你是想拿这个项目做毕设我建议把重点放在“为什么这么选型”和“如何优化效果”上讲解清楚这几个点答辩时老师问什么你都能接住。如果你是工作中要用我建议优先把你手头的标注数据整理好模型架构不必折腾yolov8s已经能扛住大多数场景。最后再分享一个小技巧训练时最好给每个实验设置不同的name参数比如yolo detect train ... nameexp_rain_v2这样每次实验的日志和权重都会单独存一个文件夹方便横向对比。千万别所有实验都堆在同一个目录里不然跑完一轮你根本分不清哪个权重对应哪次实验。这个小习惯能帮你节省的调试时间比任何花哨的调参技巧都管用。
