基于YOLOv9m的水尺水位识别方案实践与部署指南

水位读数不准、现场环境恶劣、模型识别偶尔抽风——这些都是做水尺视觉识别项目时绕不开的坎。我最近基于 YOLOv9m 完成了一套水位计水位识别方案从数据采集、标注、训练一路推到嵌入式设备部署中间踩了不少坑也总结了不少经验。这套方案的核心思路很直接用目标检测模型定位水尺区域、识别刻度数字再通过几何换算推算出实际水位值。相比传统的人工读尺和液位计方案它不需要改造水尺本体不依赖供电通讯线路改造适合存量站点快速智能化升级也适合新建的无人值守水位站。无论你是做水利信息化开发的工程师还是高校里做视觉检测方向研究的同学这篇实践记录应该都能提供一些可复现的参考。1. 方案核心思路与选型拆解1.1 水位识别的问题本质水位计在水尺上的读数本质上是一个“小目标密集检测几何定位”问题。水尺上的数字通常只有几百个像素高在整幅画面中占比很小而且刻度密集排列、背景水渍泥污混杂。这意味着模型不仅要识别出“数字是什么”还要精确回答“数字在哪里”。两年前我在一个泵站项目里试过传统方案用颜色分割找刻度线、用霍夫直线检测定位数字边缘结果一到雨天就破功。镜头上的雨滴、水面的波纹、水尺上的青苔都会让边缘检测结果面目全非。那次经历让我彻底转向了基于深度学习的目标检测路线。目标检测模型对光照变化、轻微遮挡、复杂背景的鲁棒性远好于传统图像处理方法。而YOLO系列模型又是工程落地里最成熟的选择——推理速度快、部署资料多、社区生态完善。到了YOLOv9这一代backbone和neck的结构经过重构小目标检测能力相比v5和v8有了明显提升正好契合水尺数字这种小目标密集场景。1.2 YOLOv9m的选型理由在YOLOv9系列里有t、s、m、c、e几个规格。我最终选了m版本没有选更轻的s也没有选更重的c/e原因很简单算力和精度的平衡点。先看精度需求。水尺数字的检测如果精度不足后续水位推算必然连锁出错。s模型在精度上虽然能用但在夜间和雨天场景下margin偏小一旦光照剧烈变化就容易漏检。再看算力约束。我部署的目标平台讲嵌入式设备显存和算力都有限。c和e模型虽然AP更高但推理延迟和显存占用对边缘设备不够友好。m版本在两者之间取了一个很舒服的位置COCO指标比s高出一截推理耗时又不会让嵌入式平台捉襟见肘。另一个实际考虑是模型体积。m权重约50MB出头在传输、存储、加载上都方便。传统水位站点的网络条件不一定好模型太大光是OTA升级到现场设备都费劲。50MB这个量级通过4G网络也能比较顺畅地推送。1.3 总体检测流程设计整个系统不是训练一个模型就直接出水位而是拆成两级检测加一步几何换算。第一级是水尺区域定位。先在整帧图像里找到水尺的外接框把检测范围限制在ROI内。这一步的价值在两方面一是排除水尺周边大量无关背景的干扰二是为第二级检测缩小搜索范围减少算力消耗。第二级是刻度数字检测。在ROI内识别水尺上的每个数字输出类别和坐标。这里我用了09十个数字类别加上一个“E”符号类别用于零位辅助定位。数字类别直接作为读数省去再接一套OCR模型的麻烦。最后是水位推算。拿到数字框的坐标和类别后结合水面线位置、刻度间距先验值按比例换算得到水位读数。第三步才是整个项目真正的门槛后面我会专门展开讲。提示三个环节的误差是逐级累积的。第一级的框偏了第二级裁出来的图就偏数字坐标也跟着偏最终读数自然不准。所以每一级的质量都要盯紧不能只管模型MAP好看。2. 数据采集与标注规范2.1 数据采集长期无人值守场景下的样本覆盖目标检测项目里有一句话叫“有多少数据就有多少能力”在水尺场景下尤其成立。如果训练集全是晴天的清晰照片部署到现场遇到雨夜就会直接翻车。我按以下维度控制了数据分布。时间段上白天、黄昏、夜晚、凌晨都要覆盖。白天数据好采夜晚数据必须有补光条件才能采到可用画面。如果摄像头本身带红外夜视夜晚数据的可用性会大幅提高。天气上晴天、阴天、雨天、雾天尽量都收。雨天特别关键雨滴造成的反光、水尺湿滑后的镜面效应、水面线的模糊都是模型必须见过的模式。水位状态上从低水位到高水位覆盖水尺的全量程。这个点容易忽略因为某段水位可能整个月都不会出现只能靠长期挂机累积。我建议有条件的站点做视频录像按水位高低分桶存档隔一段时间抽帧补充训练集。设备端我一般设置为12秒抽帧一次一天的录像大约能积累几千帧有效样本。拍摄角度上正规安装的相机基本都是正对水尺但现场总会有安装偏差。训练集里加入小角度侧视、仰视的样本能让模型对视角变化更宽容。2.2 标注类别和框规则标注方案直接影响模型的识别上限这里没有捷径。我使用的类别体系如下类别含义说明water-gauge整个水尺外框第一级检测定位ROIdigit-0digit-9水尺上的单个数字第二级检测类别即读数mark-E水尺顶部“E”符号辅助定位零位water-line水面线与水尺的交界位置辅助水位推算数字拆分到10个独立类别而不是统一做一个“数字”类别这个决策经历过实测验证。统一数字类别虽然能让框更聚焦数字本身但读数时还得再走一遍OCR多一个步骤就多一层误差。直接分类到09模型输出的类名就是数字值省事又直观。标注框的规则上我总结了几条容易踩雷的点数字框必须贴紧数字主体不要把旁边的刻度线、刻度间格包进去。框内杂质越多类别特征越被稀释。框的尺寸比例要一致。水尺数字是竖向排列框比例统一在0.81.2之间避免模型学到错误的比例先验。被水面线截断、被水渍覆盖一半的数字不要删除。这种“半残样本”恰恰是真实场景的常态模型必须见过才能稳。2.3 数据增强别让模型学习错误的物理规律数据增强是提高泛化能力的常规手段但不能盲目照搬通用配置。水位场景有一个特殊性水尺是物理物体数字不会上下颠倒也不会左右翻转。默认增强里的水平翻转如果开着会生成“数字镜像”的样本——这种样本在语义上是错的会干扰模型学习正确的方向特征。我实测过一组对比默认增强配置下验证集mAP50在0.85附近调整后关闭水平翻转、限制旋转角度mAP50提升到0.93左右。增强配置如下Mosaic开启训练后期最后10个epoch关闭让模型在接近真实分布的图像上精修。水平翻转关闭。旋转0±5°模拟相机安装的角度偏差。HSV扰动亮度±20%饱和度±10%模拟不同天气和光线。随机擦除开启模拟泥污和污渍遮挡。这套组合既保留了常见的泛化手段又避免了破坏物理语义的错误增强。调参的时候多想一下“这个增强在真实场景里会不会出现”能省掉很多无效试错。3. 模型训练与调参实践3.1 依赖环境与数据组织环境方面没有特别冷门的需求基础配置如下Python 3.8 PyTorch 1.10推荐2.0以上版本 torchvision opencv-python numpy pyyaml代码基于官方开源仓库进行二次开发。数据按YOLO格式组织dataset/ ├── images/ │ ├── train/ │ ├── val/ ├── labels/ │ ├── train/ │ ├── val/ └── data.yamldata.yaml里面写类别数、类别名称、训练集和验证集路径。数据划分上我固定8:2并且固定随机种子保证每次训练的数据划分一致便于对比实验。3.2 关键训练参数及理由我用的训练配置如下可以用作参考起点task: detect mode: train model: yolov9m.yaml data: data.yaml hyp: hyp.scratch-low.yaml epochs: 200 batch: 16 imgsz: 640 device: 0 workers: 8 optimizer: SGD lr0: 0.01 weight_decay: 0.0005 warmup_epochs: 3 close_mosaic: 10逐个说明关键参数的选择逻辑。imgsz640是速度和精度的折中点。水尺数字属于小目标如果用纯GPU服务器训练且推理端算力充足可以尝试1024或1280小目标召回率会有明显提升。但嵌入式设备推理大分辨率图像会让耗时成倍增加所以我建议先从640起步后续根据设备性能逐步上调。batch16在单卡12GB显存下能跑起来显存吃紧就降到8同时适当提高学习率。注意batch减半后loss曲线走势会有变化不要直接照搬原学习率。epochs200在数据量2000张以内足够收敛。数据量更大时可以降到150左右数据量更少时建议先靠数据增强撑规模而不是盲目加epoch否则过拟合会来得很早。close_mosaic10这个细节容易被忽略。Mosaic增强在前中期能提升模型的鲁棒性但也让模型在拼接图的“假分布”上学习。最后10个epoch关闭相当于给模型一段时间回到真实数据分布做精修收敛更稳。3.3 训练监控与结果评估训练期间重点盯验证集上的box_loss和cls_loss两条曲线本该平稳下降。如果验证损失在后期反弹说明过拟合已经开始果断早停不要硬跑完所有epoch。目标检测还有一个绕不开的度量对mAP50和mAP50-95。mAP50看识别是否准确mAP50-95则更苛刻要求框的位置定位足够精细。水位识别场景两者都要看因为水位推算极度依赖框位置的准确性。我在最终模型上mAP50约为0.95mAP50-95约为0.78实际部署中读数稳定性已经可以接受。超参数搜索这块工业项目里我一般不做大规模调参。训练一轮基线模型再根据失败样本手动微调一两轮效果足够。时间成本上更划算也容易控制。4. 水位推算逻辑与部署实践4.1 从检测框到水位读数几何换算详解模型检测完数字业务系统要的是一串带单位的数值。这个换算过程是项目最容易出错的地方我把具体步骤拆开讲。先在检测结果里找当前水面线下方最近的那个数字框。这里水面线位置有两种获取方式一是单独训练一个water-line类别二是从标定好的底部基准推算。我项目里是两者结合优先用模型检测的水面线缺失时退回底部推算。再用相邻数字框做比例内插公式如下水位 下方数字值 (水面线纵坐标 - 下方数字中心纵坐标) / 相邻数字中心像素距 × 刻度间距举例水尺刻度每2cm一格里数字为84、86。检测到84框中心纵坐标320像素86框中心纵坐标280像素水面线纵坐标300像素。相邻数字中心像素距 320 - 280 40 像素 比例 (320 - 300) / 40 0.5 水位 84 0.5 × 2 85.0 cm公式本身不复杂但三个前提缺一不可检测框确实配对到相邻刻度数字框中心点能代表刻度位置相机光轴与水尺面接近垂直。任何一条不满足误差都会线性放大。4.2 相机畸变和零点标定工业相机出图不带畸变校正时画面边缘的坐标偏移能有几个像素。水尺这种线条密集的场景几个像素误差换算成水位读数就是好几厘米完全不可接受。所以部署前必须做一次完整的相机标定。畸变标定用棋盘格加OpenCV的cv2.calibrateCamera即可。标定完拿到内参和畸变系数推理前对整帧做cv2.undistort。边缘变形不严重时也可以只在检测到的水尺ROI区域内做校正能省一些嵌入式设备上的算力。零点标定是把视觉坐标映射到真实高程。最稳妥的做法是在安装现场用水准仪测量水尺零点对应的高程然后对比多组人工读数和视觉读数得到偏移量。后续每次视觉读数加偏移量就是上报水位。这一步做完一定要人工复核一次马虎就会污染整条数据链路。4.3 多帧滤波压掉读数跳变水位是缓慢变化的物理量但单帧检测偶尔会跳。水波导致水面线抖动、飞鸟短暂遮挡、反光造成的漏检都会让单帧读数瞬间偏差巨大。部署时我加了两层滤波。第一层是滑动窗口内取中位数窗口通常10帧。中位数相比均值的好处是天生抵抗离群值——哪怕一帧给你读了个离谱的数也不会拖垮整窗口。第二层是变化速率限制。设定每秒允许的最大变化量如果当前帧读数与前值差超出阈值判断为异常帧沿用上一帧有效值。这两层叠加之后输出读数非常平滑实际交付时基本不需要再做二次平滑。4.4 推理优化与部署架构模型导出与部署链路PyTorch训练完毕 → 导出ONNX → TensorRT转engineFP16→ 嵌入式设备推理。转换过程用onnx模型先跑一遍基准确认输出与PyTorch一致再进TensorRT这一步能提前拦下大量算子兼容问题。在嵌入式设备上YOLOv9m的FP16推理单帧约1525ms加上预处理和前后处理整体在30ms以内。水位站常规的采样频率是15秒一次这个性能余量很充足甚至能并发处理多路摄像头。部署架构上我把所有环节收敛在单进程内拉流、预处理、检测、水位推算、上报。不做跨进程通信减少消息丢失和延迟。读数和现场抓拍图通过HTTP POST或者MQTT上报平台本地保留最近一段时间的抓拍图方便后续人工复核和模型迭代。5. 典型问题与排查实录5.1 水位读数频繁跳变这是上线初期最常被反馈的问题。排查时按顺序看三处先看数字框是否稳定。如果同一个数字的框位置在相邻帧之间来回漂说明模型对目标定位不自信。改善手段是提升推理分辨率、补充该场景的样本。再看水面线检测是否稳定。水面波动大的时候水面线类别的框会上下抖多帧滤波能压住大部分抖动。如果滤波之后还跳就得增加水面线类别的样本量提高模型对这个目标本身的稳定度。最后看反光。强反光会让部分数字漏检导致参与计算的数字对时有时无。这时候优先调整补光角度尽量避免正对水尺的强反射。5.2 夜间低光照检测下降夜间补光不均匀时水尺部分数字过暗检测率明显下跌。两个有效手段一是在训练集中加入真实夜晚数据这是最直接的二是在预处理环节加自适应直方图均衡化CLAHE拉高局部对比度。两个手段结合夜间mAP能比裸模型提升约5个百分点。5.3 水尺被泥污部分遮挡长期无人值守的站点水尺长满苔藓甚至被淤泥覆盖是必然会发生的事情。模型再怎么训练也读不出被完全覆盖的数字这时候靠的是“插值自救主动告警”。插值自救只要还能检测到部分数字就能结合刻度等间距先验外推缺失位置。比如只识别到80和88中间缺失82、84、86也依然能用水面线和这两个已知数字推算水位。主动告警检测到的数字数量低于阈值时上报“水尺遮挡/需清洁”事件。这个功能让运维从“等故障被发现”变成“主动收到提醒”价值很大。5.4 ONNX导出与部署的坑训练环境到部署环境的版本不一致是导出问题的第一来源。经验做法是导出时锁定torch和onnx版本导出后立刻用onnxruntime验证输出一致性再转TensorRT。另外TensorRT engine不跨版本兼容升级TensorRT必须重新生成engine不能图省事拿旧文件复用。6. 实操总结与个人体会这套方案从算法验证到现场落地我最大的感触是模型训练只是其中一环真正决定项目成败的是数据质量、标注规范、现场标定和推算逻辑的闭环。很多团队把精力全投到刷模型精度上结果部署到现场读数依然不准。原因往往不是模型不行而是零点没标好、相机畸变没校正、水尺安装角度太随意。给准备上马类似项目的团队一个建议优先把现场安装规范化。相机和水尺的相对位置固定、角度垂直、避免正对强光源这些做到位后续算法工作量和数据需求会明显下降。后续我想在这个方案上继续扩展的方向有两个一是把单帧检测升级为端到端的语义分割直接输出水面线像素位置减少中间环节二是接入时序信息用水位变化的连续性做异常检测和趋势预测。这些扩展都建立在当前这条稳定链路之上先把基础打牢后面才有条件谈优化。最后分享一个实操中非常管用的小习惯每完成一次现场调优就把当天的抓拍图、标注版本、模型版本、参数配置统一打标签归档。几个月后回头迭代模型时你会发现有这套完整记录能省下大量重新摸索的时间。