水位读数不准、现场环境恶劣、模型识别偶尔抽风——这些都是做水尺视觉识别项目时绕不开的坎。我最近基于 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内识别水尺上的每个数字，输出类别和坐标。这里我用了0～9十个数字类别，加上一个“E”符号类别用于零位辅助定位。数字类别直接作为读数，省去再接一套OCR模型的麻烦。最后是水位推算。拿到数字框的坐标和类别后，结合水面线位置、刻度间距先验值，按比例换算得到水位读数。第三步才是整个项目真正的门槛，后面我会专门展开讲。提示：三个环节的误差是逐级累积的。第一级的框偏了，第二级裁出来的图就偏，数字坐标也跟着偏，最终读数自然不准。所以每一级的质量都要盯紧，不能只管模型MAP好看。2. 数据采集与标注规范2.1 数据采集：长期无人值守场景下的样本覆盖目标检测项目里有一句话叫“有多少数据就有多少能力”，在水尺场景下尤其成立。如果训练集全是晴天的清晰照片，部署到现场遇到雨夜就会直接翻车。我按以下维度控制了数据分布。时间段上，白天、黄昏、夜晚、凌晨都要覆盖。白天数据好采，夜晚数据必须有补光条件才能采到可用画面。如果摄像头本身带红外夜视，夜晚数据的可用性会大幅提高。天气上，晴天、阴天、雨天、雾天尽量都收。雨天特别关键，雨滴造成的反光、水尺湿滑后的镜面效应、水面线的模糊，都是模型必须见过的模式。水位状态上，从低水位到高水位覆盖水尺的全量程。这个点容易忽略，因为某段水位可能整个月都不会出现，只能靠长期挂机累积。我建议有条件的站点做视频录像，按水位高低分桶存档，隔一段时间抽帧补充训练集。设备端我一般设置为1～2秒抽帧一次，一天的录像大约能积累几千帧有效样本。拍摄角度上，正规安装的相机基本都是正对水尺，但现场总会有安装偏差。训练集里加入小角度侧视、仰视的样本，能让模型对视角变化更宽容。2.2 标注类别和框规则标注方案直接影响模型的识别上限，这里没有捷径。我使用的类别体系如下：类别含义说明water-gauge整个水尺外框第一级检测，定位ROIdigit-0～digit-9水尺上的单个数字第二级检测，类别即读数mark-E水尺顶部“E”符号辅助定位零位water-line水面线与水尺的交界位置辅助水位推算数字拆分到10个独立类别而不是统一做一个“数字”类别，这个决策经历过实测验证。统一数字类别虽然能让框更聚焦数字本身，但读数时还得再走一遍OCR，多一个步骤就多一层误差。直接分类到0～9，模型输出的类名就是数字值，省事又直观。标注框的规则上，我总结了几条容易踩雷的点：数字框必须贴紧数字主体，不要把旁边的刻度线、刻度间格包进去。框内杂质越多，类别特征越被稀释。框的尺寸比例要一致。水尺数字是竖向排列，框比例统一在0.8～1.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逐个说明关键参数的选择逻辑。imgsz=640是速度和精度的折中点。水尺数字属于小目标，如果用纯GPU服务器训练且推理端算力充足，可以尝试1024或1280，小目标召回率会有明显提升。但嵌入式设备推理大分辨率图像会让耗时成倍增加，所以我建议先从640起步，后续根据设备性能逐步上调。batch=16在单卡12GB显存下能跑起来，显存吃紧就降到8，同时适当提高学习率。注意batch减半后loss曲线走势会有变化，不要直接照搬原学习率。epochs=200在数据量2000张以内足够收敛。数据量更大时可以降到150左右，数据量更少时建议先靠数据增强撑规模，而不是盲目加epoch，否则过拟合会来得很早。close_mosaic=10这个细节容易被忽略。Mosaic增强在前中期能提升模型的鲁棒性，但也让模型在拼接图的“假分布”上学习。最后10个epoch关闭，相当于给模型一段时间回到真实数据分布做精修，收敛更稳。3.3 训练监控与结果评估训练期间重点盯验证集上的box_loss和cls_loss，两条曲线本该平稳下降。如果验证损失在后期反弹，说明过拟合已经开始，果断早停，不要硬跑完所有epoch。目标检测还有一个绕不开的度量对：mAP50和mAP50-95。mAP50看识别是否准确，mAP50-95则更苛刻，要求框的位置定位足够精细。水位识别场景两者都要看，因为水位推算极度依赖框位置的准确性。我在最终模型上mAP50约为0.95，mAP50-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转engine（FP16）→ 嵌入式设备推理。转换过程用onnx模型先跑一遍基准，确认输出与PyTorch一致再进TensorRT，这一步能提前拦下大量算子兼容问题。在嵌入式设备上，YOLOv9m的FP16推理单帧约15～25ms，加上预处理和前后处理，整体在30ms以内。水位站常规的采样频率是1～5秒一次，这个性能余量很充足，甚至能并发处理多路摄像头。部署架构上我把所有环节收敛在单进程内：拉流、预处理、检测、水位推算、上报。不做跨进程通信，减少消息丢失和延迟。读数和现场抓拍图通过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. 实操总结与个人体会这套方案从算法验证到现场落地，我最大的感触是：模型训练只是其中一环，真正决定项目成败的是数据质量、标注规范、现场标定和推算逻辑的闭环。很多团队把精力全投到刷模型精度上，结果部署到现场，读数依然不准。原因往往不是模型不行，而是零点没标好、相机畸变没校正、水尺安装角度太随意。给准备上马类似项目的团队一个建议：优先把现场安装规范化。相机和水尺的相对位置固定、角度垂直、避免正对强光源，这些做到位，后续算法工作量和数据需求会明显下降。后续我想在这个方案上继续扩展的方向有两个：一是把单帧检测升级为端到端的语义分割，直接输出水面线像素位置，减少中间环节；二是接入时序信息，用水位变化的连续性做异常检测和趋势预测。这些扩展都建立在当前这条稳定链路之上，先把基础打牢，后面才有条件谈优化。最后分享一个实操中非常管用的小习惯：每完成一次现场调优，就把当天的抓拍图、标注版本、模型版本、参数配置统一打标签归档。几个月后回头迭代模型时你会发现，有这套完整记录，能省下大量重新摸索的时间。
水位读数不准、现场环境恶劣、模型识别偶尔抽风——这些都是做水尺视觉识别项目时绕不开的坎。我最近基于 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内识别水尺上的每个数字，输出类别和坐标。这里我用了0～9十个数字类别，加上一个“E”符号类别用于零位辅助定位。数字类别直接作为读数，省去再接一套OCR模型的麻烦。最后是水位推算。拿到数字框的坐标和类别后，结合水面线位置、刻度间距先验值，按比例换算得到水位读数。第三步才是整个项目真正的门槛，后面我会专门展开讲。提示：三个环节的误差是逐级累积的。第一级的框偏了，第二级裁出来的图就偏，数字坐标也跟着偏，最终读数自然不准。所以每一级的质量都要盯紧，不能只管模型MAP好看。2. 数据采集与标注规范2.1 数据采集：长期无人值守场景下的样本覆盖目标检测项目里有一句话叫“有多少数据就有多少能力”，在水尺场景下尤其成立。如果训练集全是晴天的清晰照片，部署到现场遇到雨夜就会直接翻车。我按以下维度控制了数据分布。时间段上，白天、黄昏、夜晚、凌晨都要覆盖。白天数据好采，夜晚数据必须有补光条件才能采到可用画面。如果摄像头本身带红外夜视，夜晚数据的可用性会大幅提高。天气上，晴天、阴天、雨天、雾天尽量都收。雨天特别关键，雨滴造成的反光、水尺湿滑后的镜面效应、水面线的模糊，都是模型必须见过的模式。水位状态上，从低水位到高水位覆盖水尺的全量程。这个点容易忽略，因为某段水位可能整个月都不会出现，只能靠长期挂机累积。我建议有条件的站点做视频录像，按水位高低分桶存档，隔一段时间抽帧补充训练集。设备端我一般设置为1～2秒抽帧一次，一天的录像大约能积累几千帧有效样本。拍摄角度上，正规安装的相机基本都是正对水尺，但现场总会有安装偏差。训练集里加入小角度侧视、仰视的样本，能让模型对视角变化更宽容。2.2 标注类别和框规则标注方案直接影响模型的识别上限，这里没有捷径。我使用的类别体系如下：类别含义说明water-gauge整个水尺外框第一级检测，定位ROIdigit-0～digit-9水尺上的单个数字第二级检测，类别即读数mark-E水尺顶部“E”符号辅助定位零位water-line水面线与水尺的交界位置辅助水位推算数字拆分到10个独立类别而不是统一做一个“数字”类别，这个决策经历过实测验证。统一数字类别虽然能让框更聚焦数字本身，但读数时还得再走一遍OCR，多一个步骤就多一层误差。直接分类到0～9，模型输出的类名就是数字值，省事又直观。标注框的规则上，我总结了几条容易踩雷的点：数字框必须贴紧数字主体，不要把旁边的刻度线、刻度间格包进去。框内杂质越多，类别特征越被稀释。框的尺寸比例要一致。水尺数字是竖向排列，框比例统一在0.8～1.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逐个说明关键参数的选择逻辑。imgsz=640是速度和精度的折中点。水尺数字属于小目标，如果用纯GPU服务器训练且推理端算力充足，可以尝试1024或1280，小目标召回率会有明显提升。但嵌入式设备推理大分辨率图像会让耗时成倍增加，所以我建议先从640起步，后续根据设备性能逐步上调。batch=16在单卡12GB显存下能跑起来，显存吃紧就降到8，同时适当提高学习率。注意batch减半后loss曲线走势会有变化，不要直接照搬原学习率。epochs=200在数据量2000张以内足够收敛。数据量更大时可以降到150左右，数据量更少时建议先靠数据增强撑规模，而不是盲目加epoch，否则过拟合会来得很早。close_mosaic=10这个细节容易被忽略。Mosaic增强在前中期能提升模型的鲁棒性，但也让模型在拼接图的“假分布”上学习。最后10个epoch关闭，相当于给模型一段时间回到真实数据分布做精修，收敛更稳。3.3 训练监控与结果评估训练期间重点盯验证集上的box_loss和cls_loss，两条曲线本该平稳下降。如果验证损失在后期反弹，说明过拟合已经开始，果断早停，不要硬跑完所有epoch。目标检测还有一个绕不开的度量对：mAP50和mAP50-95。mAP50看识别是否准确，mAP50-95则更苛刻，要求框的位置定位足够精细。水位识别场景两者都要看，因为水位推算极度依赖框位置的准确性。我在最终模型上mAP50约为0.95，mAP50-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转engine（FP16）→ 嵌入式设备推理。转换过程用onnx模型先跑一遍基准，确认输出与PyTorch一致再进TensorRT，这一步能提前拦下大量算子兼容问题。在嵌入式设备上，YOLOv9m的FP16推理单帧约15～25ms，加上预处理和前后处理，整体在30ms以内。水位站常规的采样频率是1～5秒一次，这个性能余量很充足，甚至能并发处理多路摄像头。部署架构上我把所有环节收敛在单进程内：拉流、预处理、检测、水位推算、上报。不做跨进程通信，减少消息丢失和延迟。读数和现场抓拍图通过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. 实操总结与个人体会这套方案从算法验证到现场落地，我最大的感触是：模型训练只是其中一环，真正决定项目成败的是数据质量、标注规范、现场标定和推算逻辑的闭环。很多团队把精力全投到刷模型精度上，结果部署到现场，读数依然不准。原因往往不是模型不行，而是零点没标好、相机畸变没校正、水尺安装角度太随意。给准备上马类似项目的团队一个建议：优先把现场安装规范化。相机和水尺的相对位置固定、角度垂直、避免正对强光源，这些做到位，后续算法工作量和数据需求会明显下降。后续我想在这个方案上继续扩展的方向有两个：一是把单帧检测升级为端到端的语义分割，直接输出水面线像素位置，减少中间环节；二是接入时序信息，用水位变化的连续性做异常检测和趋势预测。这些扩展都建立在当前这条稳定链路之上，先把基础打牢，后面才有条件谈优化。最后分享一个实操中非常管用的小习惯：每完成一次现场调优，就把当天的抓拍图、标注版本、模型版本、参数配置统一打标签归档。几个月后回头迭代模型时你会发现，有这套完整记录，能省下大量重新摸索的时间。