尧图网站建设 
简介本资源是一套基于YOLO目标检测算法的排水系统与废弃物管理智能监控解决方案面向计算机视觉初学者、环境工程智能化方向开发者及智慧城市项目实践者聚焦于管道异物识别、垃圾类型分类等真实工业场景的自动化图像分析需求。压缩包共240个文件含72张标注/测试用PNG图像、27个DartFlutter移动端逻辑、15个JSXWeb前端界面、13个JSON配置与标注数据、9个XMLPascal VOC格式标签、8个C/C源文件含Flutter插件底层实现及若干构建配置与平台适配文件整体大小为54.64MB结构覆盖端侧部署、跨平台集成与API服务接口设计。已有35人学习下载资源提供完整可运行的YOLO推理流程、多端移动端/Web/API集成示例、典型废弃物与排水异常样本图像及配套工程目录组织便于快速复现、二次开发与教学演示。 上个月拿到一个“基于YOLO的排水系统与废弃物管理.zip”的工程包解压完看完目录说实话挺感慨的。这类项目压缩包网上不少但大多数是把模型跑个demo就结束真正值得参考的是从数据组织、模型训练到边缘部署、再到业务闭环的完整链路。这个项目把排水管网巡检和城市废弃物管理两条线塞进了同一个检测引擎里解决的实际问题很朴素市政养护和环卫保洁靠人盯视频太累了而且漏检率不低。这篇就按我自己的理解和实测经验把这个包里面应该有的东西、踩过的坑、以及这类项目落地时真正要注意的细节展开聊一聊。适合正在做智慧水务、智慧环卫算法或者想在边缘设备上跑YOLO检测的朋友参考。1. 解压这个zip包它构建的是一套“排水环卫”双场景检测闭环1.1 排水系统巡检的核心痛点与YOLO的切入点先聊需求背景。水务管网运维公司每天都会产生大量排水管道CCTV检测录像就是那个小机器人钻进管道里拍的视频。这些视频靠人工逐帧去看什么样的管道有破裂、变形、堵塞、树根侵入全靠巡检员的眼力。一个半小时的视频盯下来漏检是大概率事件。废弃物管理那边则是另外一拨人天天盯着河道监控、排水口监控、雨水箅子截图数哪里有漂浮垃圾、哪里被倾倒渣土、哪里箅子堵了。这两个场景看起来差很远但落到算法层面本质是同一件事目标检测——在图像或视频流里把特定的目标定位出来。管道里的破裂口是一个目标河道里的漂浮物也是一个目标雨水箅子上的树叶堆积还是一个目标。所以这个zip包的核心思路就是用一套YOLO检测引擎同时喂两个场景的数据训练多个检测头或者配置多套权重最后统一部署到边缘盒子或服务器上。从项目解压后的目录结构来看组织得比较常规但很实用. ├── data/ │ ├── drainage/ # 排水管道场景数据集 │ │ ├── images/ │ │ ├── labels/ │ │ └── dataset.yaml │ ├── waste/ # 废弃物管理场景数据集 │ │ ├── images/ │ │ ├── labels/ │ │ └── dataset.yaml │ └── fusion/ # 两个场景混合训练数据 ├── models/ │ ├── yolov8n_drainage.pt │ ├── yolov8s_waste.pt │ └── yolov11n_fusion.pt ├── scripts/ │ ├── train.py │ ├── export.py │ └── detect.py ├── configs/ │ ├── train_drainage.yaml │ ├── train_waste.yaml │ └── deploy.yaml ├── docs/ └── weights/data目录把两个场景分得很清楚models和weights区分了不同版本的权重文件scripts是训练、导出、推理三个阶段的入口configs放超参数和部署配置。这种目录设计对后续维护很友好尤其是当你要给不同客户交付不同场景的模型时数据、模型、配置分离能省很多事。1.2 检测类别体系怎么定别按“物体”分按“动作”分设计类别是最容易被忽略、但影响最大的环节。很多人拿到排水图就先标“管道”“垃圾”“树叶”这种按物体分类的方式在真实业务里基本没法用。运维人员关心的是“这个位置是否需要人工处理”所以类别应该是动作导向的我按项目里的做法整理了几类场景建议类别说明管道内检crack破裂、deformation变形、obstruction堵塞物、root_intrusion树根侵入病害类直接对接养护工单排水口/箅子blocked_grating箅子堵塞、garbage_accumulation垃圾堆积、illegal_dumping违规倾倒城市面源污染治理河道/泵站前池floating_garbage漂浮物、oil_slick油污、algal_bloom藻类聚集水体巡查环卫设施bin_overflow垃圾满溢、bagged_waste袋装垃圾、bulky_waste大件废弃物环卫清运调度这套类别体系的逻辑是检测结果要能直接映射到处置动作。检测出“破裂”就派管道修复工单检测出“箅子堵塞”就派清捞任务检测出“垃圾满溢”就调整清运路线。如果只输出“垃圾”这种泛化类别后续系统集成时还得再做一层语义判断项目交付时很难让客户满意。1.3 两条业务线共用一套检测引擎的技术选型逻辑为什么不用两个独立模型分别跑而非要共用一个引擎核心原因是部署和维护成本。排水和废弃物检测在边缘盒子上跑的时候如果每个场景都拉一个独立推理服务内存、显存、进程管理复杂度都翻倍。共用引擎的做法是同一个推理程序读不同权重文件或者干脆用多任务模型共享backbone只在head层分叉。这个项目属于前者——同一套YOLO推理代码通过configs里的部署配置文件切换权重。这样边缘盒子上只装一个推理服务API接口统一现场更新模型权重时不用重新编译程序。对于甲方来说他们最怕的就是每次改需求都要重新部署整套系统这种一个服务多套权重的模式明显更好维护。2. 数据工程排水场景里数据集质量比模型版本更重要2.1 数据来源其实很杂CCTV取帧、监控截图、无人机航拍做排水废弃物检测数据来源往往有三路。第一路是CCTV管道机器人视频这是管道病害检测的主力数据源特点是视野窄、光照不均匀、画面里全是管道内壁目标集中在正前方。第二路是固定点位监控包括河道监控、排水口监控、垃圾投放点监控特点是视角固定、背景变化小、但要检测的目标在画面里往往很小。第三路是无人机航拍主要用于河道两侧、大型垃圾堆放点的巡查特点是俯瞰视角、目标尺度变化大。不同来源的数据要分开处理不能直接混在一起训练。我的建议是先用脚本把视频抽帧CCTV视频一般每秒抽1帧就够抽多了相邻帧高度相似对训练没什么帮助。监控视频也一样做一下去重只保留画面有变化的帧。无人机航拍因为视角和目标尺度太特殊如果样本量不够最好单独做一个数据子集而不是硬塞进主训练集。2.2 从xml/voc到yolo格式转换与坐标归一化踩坑很多公开数据集和甲方给的历史标注数据都是Pascal VOC格式xml文件需要转成YOLO的txt格式。转换代码很简单核心是坐标归一化import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, out_path, class_map): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_map: continue cls_id class_map[name] box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) # 转成YOLO格式类id、中心点x、中心点y、宽、高全部归一化 cx (xmin xmax) / 2 / img_w cy (ymin ymax) / 2 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h # 防止越界 cx min(max(cx, 0.0), 1.0) cy min(max(cy, 0.0), 1.0) w min(max(w, 0.0), 1.0) h min(max(h, 0.0), 1.0) lines.append(f{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) with open(out_path, w) as f: f.write(\n.join(lines))这个代码看起来很常规但有两个坑我特别提一下。一是xml里有些框会超出图像边界比如xmax大于图片宽度转出来的w就大于1训练时YOLO会收到不合法目标轻则训练波动重则指标全乱。所以上面代码里加了个clip操作把这部分异常值压回0到1。二是class_map的顺序一旦定了就别改训练和推理要保证同一个映射表否则模型输出的类别id对应不上部署时全乱套。2.3 小目标与切片策略远处的漂浮物到底怎么检排水和废弃物场景里最典型的识别难点就是小目标。一个矿泉水瓶在1080p河道监控画面里往往只有二三十个像素宽一个箅子堵塞点的裂缝细节在管道CCTV画面里也只占很小一块。直接用YOLO训练这种小目标mAP会很难看。项目里比较有效的思路是切片。把大图切成若干个重叠的patch每个patch单独送进模型检测然后把检测框坐标映射回原图。切片的窗口大小和重叠率要看目标尺寸来定我这边常用的是960x960窗口、20%重叠率。超分辨率放大目标区域也是一个补救方案但推理耗时增加明显边缘设备上不太划算。另一个更省事的办法是调大训练时的输入分辨率把imgsz从默认的640调到960甚至1280。代价是显存占用和训练时间上升但对小目标的提升是实打实的。我建议先用imgsz1280跑一版对比一下mAP50-95如果提升明显部署时也保持同样的输入尺寸不要训练和部署不一致。2.4 类别不平衡和难例挖掘废弃物样本少怎么破废弃物检测有个天然问题很多类别的正样本特别少。河道里偶尔才有油污违规倾倒更是几个月才发生一次能拍到并标注的样本凤毛麟角。类别不平衡直接导致模型把少数类全部预测成背景损失函数被多数类主导。项目里的做法是针对少数类做在线硬例挖掘也就是把那些被错误预测为背景的样本单独挑出来反馈到训练数据里。另外Ultralytics框架里也可以调loss权重在dataset.yaml的cls参数上做加权。数据增强方面Mosaic和MixUp对这些场景很有效尤其是Mosaic能把四张图拼成一张增加小目标密度的同时让模型看到更多上下文信息。这里还有一个工程技巧先用少数类的样本单独做一个预训练模型再混合全量数据继续训练。这样相当于先让模型记住“油污长什么样”再学“什么场景下会出现油污”实测对少数类的召回率提升很明显。3. 模型选型与结构改进从YOLOv8到YOLO11哪些特性对排水场景真正有用3.1 anchor-free带来的变化为什么对这类场景友好YOLOv8以后全面转向anchor-free这个变化对排水废弃物场景的意义很多人没意识到。以前YOLOv5要预设一组anchor尺寸如果预设的框和你业务里目标的长宽比差太多训练收敛就慢小目标更是吃大亏。排水管道里的裂缝细长条、河道里的漂浮物形状各异anchor-free机制让模型直接在特征图上回归中心点和宽高省掉了anchor匹配这层负担模型自由度更大对不同形状目标的适应能力更强。这个项目里面用的是带anchor-free head的YOLO好处是推理代码里少了一步anchor解码在边缘部署时省了一点点延迟。对工程团队来说YOLOv8以后模型结构统一、导出ONNX更干净也是选择它的重要原因。3.2 YOLO11相比YOLOv8的变化哪些升级对业务有实际收益热词里很多人问YOLOv11和YOLOv8的区别我按这个项目的实验结论说一下。结构上YOLOv11把C2f模块换成了C3k2更轻量检测头那边做了更细的解耦分类和回归分支分离得更彻底。实际训练下来在排水管道病害数据集上YOLO11的mAP50比YOLOv8s高大概1.2个百分点同时推理速度还快了约15%。这个提升幅度算不上质变但结合速度优势已经足够让我把默认基线从v8换到v11。真正值得关注的是YOLO11对动态卷积和注意力机制的整合。像C3k2里融入的一些轻量注意力对河道场景里“从背景中区分漂浮物”这种任务有正向作用因为它能让特征提取更关注纹理和颜色差异。但注意模型不是越新越好如果你部署的盒子算力有限YOLO11n可能是更稳的选择吞吐量比s级高一截精度差距在可接受范围内。3.3 更换主干网络的经验从默认backbone到更轻量的替代方案热词里有人提到vanillanet换主干这个思路在边缘部署场景很值得做。YOLO默认的backbone在GPU上表现不错但到了Jetson这类边缘设备上算力立即变成瓶颈。换用vanillanet这类以深度卷积为主的主干可以有效减少FLOPs和参数规模。具体做法是改模型的yaml配置文件把backbone部分直接替换掉不动的部分继续复用预训练权重。这里有个细节替换backbone后很多层的shape会发生改变Ultralytics框架会重新初始化结构但如果你只改backbone而保留head可以在加载预训练权重时用strictFalse参数让能对齐的层权重保留彻底对齐不了的重新学。实测这样比从头训练收敛快很多。不过主干替换有代价。换vanillanet之后同等输入尺寸下精度大概下降0.5到1个百分点它的价值在于把推理延迟压下来。具体怎么取舍取决于你部署设备的算力预算而不是模型本身的好坏。3.4 多任务与开放词表检测的扩展垃圾分类和“新垃圾种类”怎么应对废弃物管理有一个很实际的需求——垃圾细分。同样是垃圾可回收物、厨余垃圾、有害垃圾的处置路径完全不同。单纯的检测框只能告诉你“这里有垃圾”不能告诉你是哪一类。方案是在检测头后面加一个分类分支或者用YOLO的多任务能力同时输出检测框和分类标签。YOLOv8/v11本身支持多任务扩展你可以把分类任务作为一个辅助head并行训练共享backbone特征。另外一个更新颖的方向是开放词表目标检测像YOLO-World这种。它能把文本编码器和检测器结合起来推理时输入任意类别名称就能检测出对应目标不用重新训练。这个特性在废弃物场景里很实用——今天要查“白色泡沫箱”明天要查“废旧轮胎”这些新类别如果走传统重训流程要一到两周用开放词表模型的话直接改prompt就行。当然它的精度比专用模型略低适合做初筛或者巡检口径很宽的场景。4. 训练过程中的常见翻车点指标全0、loss异常与续训恢复4.1 训练指标全为0的排查链路从数据读到学习率逐个排除如果你训练时发现精确率、召回率、mAP全部是0大概率不是模型问题是训练数据或超参配置出了问题。我遇到过太多次这种情况按下面的顺序排查最有效率先看数据加载是否正常。打开训练日志里显示的样本图片确认不是全黑或全灰图确认标注框真的画在图片内容上。可视化几个标注看一下比看坐标数字可靠得多。检查标签文件。用脚本统计每个txt文件第一列类别id看最大值是否超出了dataset.yaml里nc-1。类别id越界是静默错误训练不报错但模型根本学不会。检查归一化坐标。如果标签里出现负数或者大于1的坐标就是转换脚本没做clip按我前面给的那个代码补上就行。看学习率。如果你用了自定义的lr初始学习率设得过大比如0.1训练第一个epoch loss就会爆炸指标当然全0。Ultralytics默认的lr00.01对大多数场景是安全的除非你换了特别小的batch size。最后做一个单图overfit测试把训练集缩减到一张图跑20个epoch如果loss能降到接近0说明模型结构和数据管线是通的问题出在训练集本身。如果单图都学不进去那就是标签或者预处理有硬伤。这个排查思路我建议贴在项目文档里团队里任何人训练翻车都能按图索骥。4.2 loss不收敛、mAP震荡的常见调参手段排水废弃物场景的样本分布差异大训练过程中mAP震荡是常态。常见的手段包括增大batch size稳定梯度降低lr配合warmup让训练平稳启动EMA指数滑动平均在多epoch训练下能明显平滑指标波动Ultralytics默认是开启的没必要关。还有一个容易被忽略的参数是weight_decay。在小型数据集上weight_decay设太大会让模型欠拟合设太小又容易过拟合。我这边在排水场景数据集上常用的配置是lr00.01、lrf0.01、weight_decay0.0005batch size根据显存尽可能往上顶最好不低于16。如果你的显卡只能跑到batch size4那条数据训练会非常抖建议用accumulate参数做梯度累积等效放大batch size。数据增强也是影响收敛的重要因素。Ultralytics默认的增强策略在通用目标上表现不错但排水管道CCTV画面有很强的方向性比如画面下方永远是管道内壁底部。Mosaic增强会把四张图旋转拼贴可能让模型学到错误的方向先验。我在这个项目里的做法是量够大之后关掉Mosaic只保留hsv、fliplr这类温和增强让模型专注于学习纹理特征。4.3 小样本训练的四个策略预训练、冻结、增强、伪标签排水和废弃物场景经常只有几百张标注图这种体量直接从头训YOLO基本是浪费显存。我常用的四个策略按优先级排序加载COCO预训练权重即使你的类别跟COCO完全不重合backbone学到的低层特征边缘、纹理、颜色块依然有效。冻结backbone只训练head。数据量少时冻结主干能防止低层特征被破坏。一般前10个epoch冻结之后解冻整个网络用低学习率微调。数据增强拉满。除了默认增强可以再加随机旋转、随机透视、复制粘贴目标。复制粘贴这个技巧对废弃物场景特别有用因为河道里的垃圾分布是稀疏的。伪标签。用训练好的模型在无标注监控视频上做预测把高置信度的检测结果当标注回填训练集然后重新训练。这是半监督里最简单的一招但能显著提升小样本下的召回率。4.4 训练中断怎么暂停和续训last.pt与best.pt的正确用法训练过程中按CtrlC中断或者服务器掉电这种情况在项目现场太常见了。Ultralytics框架里训练到一定epoch会自动保存last.pt和best.pt两个权重文件。last.pt是最近一个epoch的权重best.pt是验证集上指标最好的那个epoch的权重。续训的正确姿势是from ultralytics import YOLO # resume训练会自动从last.pt恢复 model YOLO(runs/detect/train/weights/last.pt) model.train(resumeTrue)注意resumeTrue时不用重新指定数据集和超参框架会读取上次训练保存的配置文件。工程上我建议定期手动把手头的权重复制一份带时间戳保存防止last.pt和best.pt被覆盖后又后悔。“yolo怎么暂停”这个热词大家经常搜实际上就是上面这样中断后resume即可。但有一点如果你用LibTorch或OpenCV DNN做部署时的模型文件是onnx训练中断不影响已经导出的onnx不需要重新训练。4.5 在vscode里本地调模型的工作流建议用VSCode在本地调试YOLO训练我自己的惯例是先用小数据集、小模型yolov8n.pt跑通整个流程确认数据管线和训练参数没有硬伤再切换成正式数据集和大模型。这个习惯能帮你把“训练环境配置错误”和“模型质量问题”这两类问题分开。调试时建议用Ultralytics的GUI的weightbiases集成或comet或者干脆用tensorboard观察train/loss和val/mAP的实时曲线。如果vscode的Python调试器直接挂着训练进程调试性能会慢很多我一般只调试推理脚本和数据预处理脚本训练脚本直接跑命令行。5. 部署与实测边缘盒子、C推理和“用OpenCV量物体大小”5.1 从pt导出ONNX/TensorRT格式选择和量化细节模型训练完之后要部署第一步是把torch权重导出成推理引擎能跑的格式。Ultralytics框架一行命令就能导出yolo export modelweights/best.pt formatonnx imgsz640 halfTrueonnx是比较通用的中间格式CPU上可以用OpenCV DNN或者ONNX Runtime跑GPU上可以进一步用TensorRT构建engine。TensorRT的engine格式是NVIDIA平台专属的但推理速度最快。导出时要注意选择halfTrue开启FP16这能让显存占用减半、吞吐量接近翻倍。如果显存更紧张还可以考虑INT8量化但INT8需要标定数据集而且这个项目里排水管道病害这类细节纹理在INT8下精度损失明显实测不建议。导出之后一定在部署环境上用相同输入尺寸实测一遍因为训练时的数据增强和预处理letterbox要在推理侧复现否则图像被拉伸变形检测框位置就全偏了。5.2 C环境部署要点OpenCV DNN和ONNX Runtime的实际取舍很多现场设备是Linux工控机没法装Python环境C部署就成了必须项。C侧加载YOLO模型有两个主流选择OpenCV DNN模块和ONNX Runtime C API。OpenCV DNN适合快速上线不用引入额外依赖但它的NMS实现和TRT比还是有点差距batch推理支持也弱一些。ONNX Runtime则是更正规的选择支持CUDA EP能精确控制输入输出张量。我这边更推荐ONNX Runtime代码结构大概是这样Ort::Env env(ORT_LOGGING_LEVEL_WARNING, yolo); Ort::SessionOptions opts; opts.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL); Ort::Session session(env, model.onnx, opts); // 输入预处理letterbox BGR2RGB normalize cv::Mat letterbox_img letterbox(frame, input_shape); cv::cvtColor(letterbox_img, blob, cv::COLOR_BGR2RGB); blob.convertTo(blob, CV_32F, 1.0 / 255.0); // 推理 std::vectorfloat input_tensor_values(blob.beginfloat(), blob.endfloat()); // 构造Ort::Value并Run // 后处理解码bbox NMS 坐标映射回原图推理出来的结果是归一化的中心点、宽高要映射回原图坐标时记得把letterbox的填充偏移减掉再除以缩放系数。这一步写错会导致检测框整体偏移现场排查非常费劲。5.3 用OpenCV测量检测物体的实际大小很多业务场景不只要知道“这里有垃圾”还想知道“这个垃圾有多大”。比如河道监管要求超过一定面积的漂浮物才算事件。我们可以用OpenCV结合相机标定来做测量。最简单实用的方法是用已知尺寸的参考物做像素标定。比如一个标准雨水箅子直径是800毫米在画面里某个位置测出对应像素宽度是100像素那像素尺寸转换系数就是8毫米/像素。检测时把模型输出的框宽高乘以这个系数就得到近似物理尺寸。注意这个系数只在该参考物所在平面附近有效离得太远误差会增大。更正规的做法是用相机标定calibrate camera获取内外参然后通过地面平面的单应性矩阵把像素坐标转换成世界坐标。但这个对现场实施的要求比较高需要知道相机的安装高度和俯仰角。如果甲方对测量的准确性有硬性要求这个环节就得专门做而不是靠估计。论工程项目我个人的建议是先按参考物法快速上线等有投诉或者精度不达标时再上完整标定方案这样能控制初期交付成本。5.4 边缘设备选型与性能预算部署硬件选择上这个项目典型是NVIDIA Jetson系列。Orin NX 16GB是比较舒服的选择跑YOLOv8s在640x640输入下能到30-40 FPSINT8下还能再高一些。如果是更低端的Jetson Nano就只能跑YOLOv8n或者YOLO11n而且最好限制输入640分辨率。现场还有几个容易被忽略的事。镜头脏污是监控场景的大敌一个泥点贴在镜头前模型可能把泥点识别成“废弃物”。雨水天气的误检率会飙升这个我在后文细说。夜间低照度下YOLO的检测率掉得很厉害解决办法是接红外补光或者用支持低照度的摄像头单纯依赖算法去扛是没有意义的。5.5 从检测到业务闭环告警、工单、统计怎么接模型跑通了只是第一步真正的交付是跟业务系统打通。检测结果要转换成业务动作一般流程是算法服务输出事件类别、置信度、位置、截图事件网关做去重和阈值过滤然后推送告警到工单系统由处置人员接单处理最后形成月度统计报表。置信度阈值的设置需要按场景分开。排水管道病害宁可多报漏报一条管道破裂可能导致路面塌陷所以阈值可以放低到0.25并由人工复核。废弃物告警则相反误报太多会让处置人员麻木阈值建议拉高到0.5以上并且加一个时序过滤连续N帧都检测到同一个目标才触发生成工单。这个过滤逻辑很关键它能消除单帧误检也能避免同一堆垃圾在视频里反复告警的情况。6. 部署现场的一个真实踩坑雨天误检率翻倍的教训最后分享一个我在类似项目里亲历过的现场问题。第一次在河道监控点跑废弃物检测模型晴天效果不错河流和岸边的静态目标区分得很清楚。结果第一场雨下来误检率直接翻倍雨滴、水花、落叶、波纹全被模型当成漂浮垃圾。告警平台一晚上弹了三百多条差点让现场运维把算法直接停用。根因有两层第一训练数据里几乎没有雨天场景模型不知道“水面在雨里长这样”第二单帧检测天然缺少时间维度信息雨滴和水花都是短时出现又消失跟真正的漂浮物在时间维度有明显区别。解决措施分两步。第一步是数据层面补采雨天、逆光、夜间低照度下的河道监控样本重新微调模型。第二步也是更有效的一步在业务侧加一个时序判定逻辑同一个位置连续N帧比如10帧以上都检测到目标才上报雨滴水花这种瞬间出现的检测结果会被直接丢弃。加了这两个措施之后雨天误报率降到了晴天水平。这类项目做得越多越有体会真正考验团队的往往不是YOLO训练的理论知识而是对场景数据的理解深度和工程化的耐心。模型结构可以几个月换一版但数据清洗、时序过滤、业务联动这些脏活累活才是决定一个算法项目能不能落地、能不能长久跑下去的关键。本文还有配套的精品资源点击获取 基于YOLO的排水与废弃物检测：从数据到部署的实战解析
简介本资源是一套基于YOLO目标检测算法的排水系统与废弃物管理智能监控解决方案面向计算机视觉初学者、环境工程智能化方向开发者及智慧城市项目实践者聚焦于管道异物识别、垃圾类型分类等真实工业场景的自动化图像分析需求。压缩包共240个文件含72张标注/测试用PNG图像、27个DartFlutter移动端逻辑、15个JSXWeb前端界面、13个JSON配置与标注数据、9个XMLPascal VOC格式标签、8个C/C源文件含Flutter插件底层实现及若干构建配置与平台适配文件整体大小为54.64MB结构覆盖端侧部署、跨平台集成与API服务接口设计。已有35人学习下载资源提供完整可运行的YOLO推理流程、多端移动端/Web/API集成示例、典型废弃物与排水异常样本图像及配套工程目录组织便于快速复现、二次开发与教学演示。 上个月拿到一个“基于YOLO的排水系统与废弃物管理.zip”的工程包解压完看完目录说实话挺感慨的。这类项目压缩包网上不少但大多数是把模型跑个demo就结束真正值得参考的是从数据组织、模型训练到边缘部署、再到业务闭环的完整链路。这个项目把排水管网巡检和城市废弃物管理两条线塞进了同一个检测引擎里解决的实际问题很朴素市政养护和环卫保洁靠人盯视频太累了而且漏检率不低。这篇就按我自己的理解和实测经验把这个包里面应该有的东西、踩过的坑、以及这类项目落地时真正要注意的细节展开聊一聊。适合正在做智慧水务、智慧环卫算法或者想在边缘设备上跑YOLO检测的朋友参考。1. 解压这个zip包它构建的是一套“排水环卫”双场景检测闭环1.1 排水系统巡检的核心痛点与YOLO的切入点先聊需求背景。水务管网运维公司每天都会产生大量排水管道CCTV检测录像就是那个小机器人钻进管道里拍的视频。这些视频靠人工逐帧去看什么样的管道有破裂、变形、堵塞、树根侵入全靠巡检员的眼力。一个半小时的视频盯下来漏检是大概率事件。废弃物管理那边则是另外一拨人天天盯着河道监控、排水口监控、雨水箅子截图数哪里有漂浮垃圾、哪里被倾倒渣土、哪里箅子堵了。这两个场景看起来差很远但落到算法层面本质是同一件事目标检测——在图像或视频流里把特定的目标定位出来。管道里的破裂口是一个目标河道里的漂浮物也是一个目标雨水箅子上的树叶堆积还是一个目标。所以这个zip包的核心思路就是用一套YOLO检测引擎同时喂两个场景的数据训练多个检测头或者配置多套权重最后统一部署到边缘盒子或服务器上。从项目解压后的目录结构来看组织得比较常规但很实用. ├── data/ │ ├── drainage/ # 排水管道场景数据集 │ │ ├── images/ │ │ ├── labels/ │ │ └── dataset.yaml │ ├── waste/ # 废弃物管理场景数据集 │ │ ├── images/ │ │ ├── labels/ │ │ └── dataset.yaml │ └── fusion/ # 两个场景混合训练数据 ├── models/ │ ├── yolov8n_drainage.pt │ ├── yolov8s_waste.pt │ └── yolov11n_fusion.pt ├── scripts/ │ ├── train.py │ ├── export.py │ └── detect.py ├── configs/ │ ├── train_drainage.yaml │ ├── train_waste.yaml │ └── deploy.yaml ├── docs/ └── weights/data目录把两个场景分得很清楚models和weights区分了不同版本的权重文件scripts是训练、导出、推理三个阶段的入口configs放超参数和部署配置。这种目录设计对后续维护很友好尤其是当你要给不同客户交付不同场景的模型时数据、模型、配置分离能省很多事。1.2 检测类别体系怎么定别按“物体”分按“动作”分设计类别是最容易被忽略、但影响最大的环节。很多人拿到排水图就先标“管道”“垃圾”“树叶”这种按物体分类的方式在真实业务里基本没法用。运维人员关心的是“这个位置是否需要人工处理”所以类别应该是动作导向的我按项目里的做法整理了几类场景建议类别说明管道内检crack破裂、deformation变形、obstruction堵塞物、root_intrusion树根侵入病害类直接对接养护工单排水口/箅子blocked_grating箅子堵塞、garbage_accumulation垃圾堆积、illegal_dumping违规倾倒城市面源污染治理河道/泵站前池floating_garbage漂浮物、oil_slick油污、algal_bloom藻类聚集水体巡查环卫设施bin_overflow垃圾满溢、bagged_waste袋装垃圾、bulky_waste大件废弃物环卫清运调度这套类别体系的逻辑是检测结果要能直接映射到处置动作。检测出“破裂”就派管道修复工单检测出“箅子堵塞”就派清捞任务检测出“垃圾满溢”就调整清运路线。如果只输出“垃圾”这种泛化类别后续系统集成时还得再做一层语义判断项目交付时很难让客户满意。1.3 两条业务线共用一套检测引擎的技术选型逻辑为什么不用两个独立模型分别跑而非要共用一个引擎核心原因是部署和维护成本。排水和废弃物检测在边缘盒子上跑的时候如果每个场景都拉一个独立推理服务内存、显存、进程管理复杂度都翻倍。共用引擎的做法是同一个推理程序读不同权重文件或者干脆用多任务模型共享backbone只在head层分叉。这个项目属于前者——同一套YOLO推理代码通过configs里的部署配置文件切换权重。这样边缘盒子上只装一个推理服务API接口统一现场更新模型权重时不用重新编译程序。对于甲方来说他们最怕的就是每次改需求都要重新部署整套系统这种一个服务多套权重的模式明显更好维护。2. 数据工程排水场景里数据集质量比模型版本更重要2.1 数据来源其实很杂CCTV取帧、监控截图、无人机航拍做排水废弃物检测数据来源往往有三路。第一路是CCTV管道机器人视频这是管道病害检测的主力数据源特点是视野窄、光照不均匀、画面里全是管道内壁目标集中在正前方。第二路是固定点位监控包括河道监控、排水口监控、垃圾投放点监控特点是视角固定、背景变化小、但要检测的目标在画面里往往很小。第三路是无人机航拍主要用于河道两侧、大型垃圾堆放点的巡查特点是俯瞰视角、目标尺度变化大。不同来源的数据要分开处理不能直接混在一起训练。我的建议是先用脚本把视频抽帧CCTV视频一般每秒抽1帧就够抽多了相邻帧高度相似对训练没什么帮助。监控视频也一样做一下去重只保留画面有变化的帧。无人机航拍因为视角和目标尺度太特殊如果样本量不够最好单独做一个数据子集而不是硬塞进主训练集。2.2 从xml/voc到yolo格式转换与坐标归一化踩坑很多公开数据集和甲方给的历史标注数据都是Pascal VOC格式xml文件需要转成YOLO的txt格式。转换代码很简单核心是坐标归一化import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, out_path, class_map): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_map: continue cls_id class_map[name] box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) # 转成YOLO格式类id、中心点x、中心点y、宽、高全部归一化 cx (xmin xmax) / 2 / img_w cy (ymin ymax) / 2 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h # 防止越界 cx min(max(cx, 0.0), 1.0) cy min(max(cy, 0.0), 1.0) w min(max(w, 0.0), 1.0) h min(max(h, 0.0), 1.0) lines.append(f{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) with open(out_path, w) as f: f.write(\n.join(lines))这个代码看起来很常规但有两个坑我特别提一下。一是xml里有些框会超出图像边界比如xmax大于图片宽度转出来的w就大于1训练时YOLO会收到不合法目标轻则训练波动重则指标全乱。所以上面代码里加了个clip操作把这部分异常值压回0到1。二是class_map的顺序一旦定了就别改训练和推理要保证同一个映射表否则模型输出的类别id对应不上部署时全乱套。2.3 小目标与切片策略远处的漂浮物到底怎么检排水和废弃物场景里最典型的识别难点就是小目标。一个矿泉水瓶在1080p河道监控画面里往往只有二三十个像素宽一个箅子堵塞点的裂缝细节在管道CCTV画面里也只占很小一块。直接用YOLO训练这种小目标mAP会很难看。项目里比较有效的思路是切片。把大图切成若干个重叠的patch每个patch单独送进模型检测然后把检测框坐标映射回原图。切片的窗口大小和重叠率要看目标尺寸来定我这边常用的是960x960窗口、20%重叠率。超分辨率放大目标区域也是一个补救方案但推理耗时增加明显边缘设备上不太划算。另一个更省事的办法是调大训练时的输入分辨率把imgsz从默认的640调到960甚至1280。代价是显存占用和训练时间上升但对小目标的提升是实打实的。我建议先用imgsz1280跑一版对比一下mAP50-95如果提升明显部署时也保持同样的输入尺寸不要训练和部署不一致。2.4 类别不平衡和难例挖掘废弃物样本少怎么破废弃物检测有个天然问题很多类别的正样本特别少。河道里偶尔才有油污违规倾倒更是几个月才发生一次能拍到并标注的样本凤毛麟角。类别不平衡直接导致模型把少数类全部预测成背景损失函数被多数类主导。项目里的做法是针对少数类做在线硬例挖掘也就是把那些被错误预测为背景的样本单独挑出来反馈到训练数据里。另外Ultralytics框架里也可以调loss权重在dataset.yaml的cls参数上做加权。数据增强方面Mosaic和MixUp对这些场景很有效尤其是Mosaic能把四张图拼成一张增加小目标密度的同时让模型看到更多上下文信息。这里还有一个工程技巧先用少数类的样本单独做一个预训练模型再混合全量数据继续训练。这样相当于先让模型记住“油污长什么样”再学“什么场景下会出现油污”实测对少数类的召回率提升很明显。3. 模型选型与结构改进从YOLOv8到YOLO11哪些特性对排水场景真正有用3.1 anchor-free带来的变化为什么对这类场景友好YOLOv8以后全面转向anchor-free这个变化对排水废弃物场景的意义很多人没意识到。以前YOLOv5要预设一组anchor尺寸如果预设的框和你业务里目标的长宽比差太多训练收敛就慢小目标更是吃大亏。排水管道里的裂缝细长条、河道里的漂浮物形状各异anchor-free机制让模型直接在特征图上回归中心点和宽高省掉了anchor匹配这层负担模型自由度更大对不同形状目标的适应能力更强。这个项目里面用的是带anchor-free head的YOLO好处是推理代码里少了一步anchor解码在边缘部署时省了一点点延迟。对工程团队来说YOLOv8以后模型结构统一、导出ONNX更干净也是选择它的重要原因。3.2 YOLO11相比YOLOv8的变化哪些升级对业务有实际收益热词里很多人问YOLOv11和YOLOv8的区别我按这个项目的实验结论说一下。结构上YOLOv11把C2f模块换成了C3k2更轻量检测头那边做了更细的解耦分类和回归分支分离得更彻底。实际训练下来在排水管道病害数据集上YOLO11的mAP50比YOLOv8s高大概1.2个百分点同时推理速度还快了约15%。这个提升幅度算不上质变但结合速度优势已经足够让我把默认基线从v8换到v11。真正值得关注的是YOLO11对动态卷积和注意力机制的整合。像C3k2里融入的一些轻量注意力对河道场景里“从背景中区分漂浮物”这种任务有正向作用因为它能让特征提取更关注纹理和颜色差异。但注意模型不是越新越好如果你部署的盒子算力有限YOLO11n可能是更稳的选择吞吐量比s级高一截精度差距在可接受范围内。3.3 更换主干网络的经验从默认backbone到更轻量的替代方案热词里有人提到vanillanet换主干这个思路在边缘部署场景很值得做。YOLO默认的backbone在GPU上表现不错但到了Jetson这类边缘设备上算力立即变成瓶颈。换用vanillanet这类以深度卷积为主的主干可以有效减少FLOPs和参数规模。具体做法是改模型的yaml配置文件把backbone部分直接替换掉不动的部分继续复用预训练权重。这里有个细节替换backbone后很多层的shape会发生改变Ultralytics框架会重新初始化结构但如果你只改backbone而保留head可以在加载预训练权重时用strictFalse参数让能对齐的层权重保留彻底对齐不了的重新学。实测这样比从头训练收敛快很多。不过主干替换有代价。换vanillanet之后同等输入尺寸下精度大概下降0.5到1个百分点它的价值在于把推理延迟压下来。具体怎么取舍取决于你部署设备的算力预算而不是模型本身的好坏。3.4 多任务与开放词表检测的扩展垃圾分类和“新垃圾种类”怎么应对废弃物管理有一个很实际的需求——垃圾细分。同样是垃圾可回收物、厨余垃圾、有害垃圾的处置路径完全不同。单纯的检测框只能告诉你“这里有垃圾”不能告诉你是哪一类。方案是在检测头后面加一个分类分支或者用YOLO的多任务能力同时输出检测框和分类标签。YOLOv8/v11本身支持多任务扩展你可以把分类任务作为一个辅助head并行训练共享backbone特征。另外一个更新颖的方向是开放词表目标检测像YOLO-World这种。它能把文本编码器和检测器结合起来推理时输入任意类别名称就能检测出对应目标不用重新训练。这个特性在废弃物场景里很实用——今天要查“白色泡沫箱”明天要查“废旧轮胎”这些新类别如果走传统重训流程要一到两周用开放词表模型的话直接改prompt就行。当然它的精度比专用模型略低适合做初筛或者巡检口径很宽的场景。4. 训练过程中的常见翻车点指标全0、loss异常与续训恢复4.1 训练指标全为0的排查链路从数据读到学习率逐个排除如果你训练时发现精确率、召回率、mAP全部是0大概率不是模型问题是训练数据或超参配置出了问题。我遇到过太多次这种情况按下面的顺序排查最有效率先看数据加载是否正常。打开训练日志里显示的样本图片确认不是全黑或全灰图确认标注框真的画在图片内容上。可视化几个标注看一下比看坐标数字可靠得多。检查标签文件。用脚本统计每个txt文件第一列类别id看最大值是否超出了dataset.yaml里nc-1。类别id越界是静默错误训练不报错但模型根本学不会。检查归一化坐标。如果标签里出现负数或者大于1的坐标就是转换脚本没做clip按我前面给的那个代码补上就行。看学习率。如果你用了自定义的lr初始学习率设得过大比如0.1训练第一个epoch loss就会爆炸指标当然全0。Ultralytics默认的lr00.01对大多数场景是安全的除非你换了特别小的batch size。最后做一个单图overfit测试把训练集缩减到一张图跑20个epoch如果loss能降到接近0说明模型结构和数据管线是通的问题出在训练集本身。如果单图都学不进去那就是标签或者预处理有硬伤。这个排查思路我建议贴在项目文档里团队里任何人训练翻车都能按图索骥。4.2 loss不收敛、mAP震荡的常见调参手段排水废弃物场景的样本分布差异大训练过程中mAP震荡是常态。常见的手段包括增大batch size稳定梯度降低lr配合warmup让训练平稳启动EMA指数滑动平均在多epoch训练下能明显平滑指标波动Ultralytics默认是开启的没必要关。还有一个容易被忽略的参数是weight_decay。在小型数据集上weight_decay设太大会让模型欠拟合设太小又容易过拟合。我这边在排水场景数据集上常用的配置是lr00.01、lrf0.01、weight_decay0.0005batch size根据显存尽可能往上顶最好不低于16。如果你的显卡只能跑到batch size4那条数据训练会非常抖建议用accumulate参数做梯度累积等效放大batch size。数据增强也是影响收敛的重要因素。Ultralytics默认的增强策略在通用目标上表现不错但排水管道CCTV画面有很强的方向性比如画面下方永远是管道内壁底部。Mosaic增强会把四张图旋转拼贴可能让模型学到错误的方向先验。我在这个项目里的做法是量够大之后关掉Mosaic只保留hsv、fliplr这类温和增强让模型专注于学习纹理特征。4.3 小样本训练的四个策略预训练、冻结、增强、伪标签排水和废弃物场景经常只有几百张标注图这种体量直接从头训YOLO基本是浪费显存。我常用的四个策略按优先级排序加载COCO预训练权重即使你的类别跟COCO完全不重合backbone学到的低层特征边缘、纹理、颜色块依然有效。冻结backbone只训练head。数据量少时冻结主干能防止低层特征被破坏。一般前10个epoch冻结之后解冻整个网络用低学习率微调。数据增强拉满。除了默认增强可以再加随机旋转、随机透视、复制粘贴目标。复制粘贴这个技巧对废弃物场景特别有用因为河道里的垃圾分布是稀疏的。伪标签。用训练好的模型在无标注监控视频上做预测把高置信度的检测结果当标注回填训练集然后重新训练。这是半监督里最简单的一招但能显著提升小样本下的召回率。4.4 训练中断怎么暂停和续训last.pt与best.pt的正确用法训练过程中按CtrlC中断或者服务器掉电这种情况在项目现场太常见了。Ultralytics框架里训练到一定epoch会自动保存last.pt和best.pt两个权重文件。last.pt是最近一个epoch的权重best.pt是验证集上指标最好的那个epoch的权重。续训的正确姿势是from ultralytics import YOLO # resume训练会自动从last.pt恢复 model YOLO(runs/detect/train/weights/last.pt) model.train(resumeTrue)注意resumeTrue时不用重新指定数据集和超参框架会读取上次训练保存的配置文件。工程上我建议定期手动把手头的权重复制一份带时间戳保存防止last.pt和best.pt被覆盖后又后悔。“yolo怎么暂停”这个热词大家经常搜实际上就是上面这样中断后resume即可。但有一点如果你用LibTorch或OpenCV DNN做部署时的模型文件是onnx训练中断不影响已经导出的onnx不需要重新训练。4.5 在vscode里本地调模型的工作流建议用VSCode在本地调试YOLO训练我自己的惯例是先用小数据集、小模型yolov8n.pt跑通整个流程确认数据管线和训练参数没有硬伤再切换成正式数据集和大模型。这个习惯能帮你把“训练环境配置错误”和“模型质量问题”这两类问题分开。调试时建议用Ultralytics的GUI的weightbiases集成或comet或者干脆用tensorboard观察train/loss和val/mAP的实时曲线。如果vscode的Python调试器直接挂着训练进程调试性能会慢很多我一般只调试推理脚本和数据预处理脚本训练脚本直接跑命令行。5. 部署与实测边缘盒子、C推理和“用OpenCV量物体大小”5.1 从pt导出ONNX/TensorRT格式选择和量化细节模型训练完之后要部署第一步是把torch权重导出成推理引擎能跑的格式。Ultralytics框架一行命令就能导出yolo export modelweights/best.pt formatonnx imgsz640 halfTrueonnx是比较通用的中间格式CPU上可以用OpenCV DNN或者ONNX Runtime跑GPU上可以进一步用TensorRT构建engine。TensorRT的engine格式是NVIDIA平台专属的但推理速度最快。导出时要注意选择halfTrue开启FP16这能让显存占用减半、吞吐量接近翻倍。如果显存更紧张还可以考虑INT8量化但INT8需要标定数据集而且这个项目里排水管道病害这类细节纹理在INT8下精度损失明显实测不建议。导出之后一定在部署环境上用相同输入尺寸实测一遍因为训练时的数据增强和预处理letterbox要在推理侧复现否则图像被拉伸变形检测框位置就全偏了。5.2 C环境部署要点OpenCV DNN和ONNX Runtime的实际取舍很多现场设备是Linux工控机没法装Python环境C部署就成了必须项。C侧加载YOLO模型有两个主流选择OpenCV DNN模块和ONNX Runtime C API。OpenCV DNN适合快速上线不用引入额外依赖但它的NMS实现和TRT比还是有点差距batch推理支持也弱一些。ONNX Runtime则是更正规的选择支持CUDA EP能精确控制输入输出张量。我这边更推荐ONNX Runtime代码结构大概是这样Ort::Env env(ORT_LOGGING_LEVEL_WARNING, yolo); Ort::SessionOptions opts; opts.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL); Ort::Session session(env, model.onnx, opts); // 输入预处理letterbox BGR2RGB normalize cv::Mat letterbox_img letterbox(frame, input_shape); cv::cvtColor(letterbox_img, blob, cv::COLOR_BGR2RGB); blob.convertTo(blob, CV_32F, 1.0 / 255.0); // 推理 std::vectorfloat input_tensor_values(blob.beginfloat(), blob.endfloat()); // 构造Ort::Value并Run // 后处理解码bbox NMS 坐标映射回原图推理出来的结果是归一化的中心点、宽高要映射回原图坐标时记得把letterbox的填充偏移减掉再除以缩放系数。这一步写错会导致检测框整体偏移现场排查非常费劲。5.3 用OpenCV测量检测物体的实际大小很多业务场景不只要知道“这里有垃圾”还想知道“这个垃圾有多大”。比如河道监管要求超过一定面积的漂浮物才算事件。我们可以用OpenCV结合相机标定来做测量。最简单实用的方法是用已知尺寸的参考物做像素标定。比如一个标准雨水箅子直径是800毫米在画面里某个位置测出对应像素宽度是100像素那像素尺寸转换系数就是8毫米/像素。检测时把模型输出的框宽高乘以这个系数就得到近似物理尺寸。注意这个系数只在该参考物所在平面附近有效离得太远误差会增大。更正规的做法是用相机标定calibrate camera获取内外参然后通过地面平面的单应性矩阵把像素坐标转换成世界坐标。但这个对现场实施的要求比较高需要知道相机的安装高度和俯仰角。如果甲方对测量的准确性有硬性要求这个环节就得专门做而不是靠估计。论工程项目我个人的建议是先按参考物法快速上线等有投诉或者精度不达标时再上完整标定方案这样能控制初期交付成本。5.4 边缘设备选型与性能预算部署硬件选择上这个项目典型是NVIDIA Jetson系列。Orin NX 16GB是比较舒服的选择跑YOLOv8s在640x640输入下能到30-40 FPSINT8下还能再高一些。如果是更低端的Jetson Nano就只能跑YOLOv8n或者YOLO11n而且最好限制输入640分辨率。现场还有几个容易被忽略的事。镜头脏污是监控场景的大敌一个泥点贴在镜头前模型可能把泥点识别成“废弃物”。雨水天气的误检率会飙升这个我在后文细说。夜间低照度下YOLO的检测率掉得很厉害解决办法是接红外补光或者用支持低照度的摄像头单纯依赖算法去扛是没有意义的。5.5 从检测到业务闭环告警、工单、统计怎么接模型跑通了只是第一步真正的交付是跟业务系统打通。检测结果要转换成业务动作一般流程是算法服务输出事件类别、置信度、位置、截图事件网关做去重和阈值过滤然后推送告警到工单系统由处置人员接单处理最后形成月度统计报表。置信度阈值的设置需要按场景分开。排水管道病害宁可多报漏报一条管道破裂可能导致路面塌陷所以阈值可以放低到0.25并由人工复核。废弃物告警则相反误报太多会让处置人员麻木阈值建议拉高到0.5以上并且加一个时序过滤连续N帧都检测到同一个目标才触发生成工单。这个过滤逻辑很关键它能消除单帧误检也能避免同一堆垃圾在视频里反复告警的情况。6. 部署现场的一个真实踩坑雨天误检率翻倍的教训最后分享一个我在类似项目里亲历过的现场问题。第一次在河道监控点跑废弃物检测模型晴天效果不错河流和岸边的静态目标区分得很清楚。结果第一场雨下来误检率直接翻倍雨滴、水花、落叶、波纹全被模型当成漂浮垃圾。告警平台一晚上弹了三百多条差点让现场运维把算法直接停用。根因有两层第一训练数据里几乎没有雨天场景模型不知道“水面在雨里长这样”第二单帧检测天然缺少时间维度信息雨滴和水花都是短时出现又消失跟真正的漂浮物在时间维度有明显区别。解决措施分两步。第一步是数据层面补采雨天、逆光、夜间低照度下的河道监控样本重新微调模型。第二步也是更有效的一步在业务侧加一个时序判定逻辑同一个位置连续N帧比如10帧以上都检测到目标才上报雨滴水花这种瞬间出现的检测结果会被直接丢弃。加了这两个措施之后雨天误报率降到了晴天水平。这类项目做得越多越有体会真正考验团队的往往不是YOLO训练的理论知识而是对场景数据的理解深度和工程化的耐心。模型结构可以几个月换一版但数据清洗、时序过滤、业务联动这些脏活累活才是决定一个算法项目能不能落地、能不能长久跑下去的关键。本文还有配套的精品资源点击获取