尧图网页设计 
简介船舶吃水线实时监测是港口安全管理中的关键环节这套基于YOLOv8的预警系统是围绕该场景设计的完整毕设方案面向计算机视觉、人工智能方向的学生与开发者可直接用于毕业设计、课程设计或项目初期立项演示。压缩包共收录97个文件以70个Python源码脚本为主体涵盖模型训练、检测服务、可视化界面等模块另含4个PT模型权重文件、5个XML配置以及演示视频整体体积仅24.21MB结构紧凑且易于部署。目前已有59人在线学习浏览项目经过完整测试、运行成功后才上传可靠性有保障。资源内置完整数据集和可视化页面可生成混淆矩阵、F1分数曲线、精确率-召回率曲线、标签分布图等核心评价图表并附带README部署说明按步骤操作即可复现适合需要快速完成高质量毕设或课设项目的同学参考。1. 港口船舶吃水线监测为什么常规目标检测接不住这个场景值班室的监控墙上有二十几路画面船靠泊、离泊、装卸货都在上面。真要让值班员盯住某一艘船的水线有没有超载超过三分钟眼睛就花了更别说夜间画面里水面和船体都是一团黑。基于YOLOv8的港口船舶吃水线实时监测预警系统解决的就是把这个“目测”动作替换成机器判读用模型在画面里找到船体和吃水线位置把像素坐标换算成真实吃水值超过阈值直接弹报警归档记录整套流程带可视化界面。标题里的源码、完整数据集、部署教程三件套齐全属于拿到就能跑的工程化项目特别适合毕设、课程设计出完整作品也适合港航信息化团队拿去做概念验证。下面按一条可落地的路径讲清楚怎么跑通、怎么训练自己的数据集、坑在哪里。2. 从物理场景到算法选型YOLOv8做吃水线检测的可行性边界2.1 吃水线检测为什么难小目标、遮挡与光照的三重挑战吃水线在图像上不是一条清晰锐利的线。船体侧舷与水面的交界区域受波浪起伏、水花飞溅、水面反光的影响在像素层面上是一段低对比度的过渡带。拿传统边缘检测或者阈值分割去处理水面上的波纹、油污、漂浮物都会产生大量伪边缘阈值调一次只能用半天换个天气就得重新调这种方案在现场基本活不过一周。真正的难点有三个。第一是小目标特性一条几十米长的散货船在港区监控画面里侧舷区域往往只有几百像素高水线位置对应的检测框高宽比极端属于典型的小目标场景。第二是光照变化剧烈正午强光下水面反光严重水线附近亮度接近高光傍晚逆光时船体背光面和水面灰度几乎融为一体夜间靠辅助照明时阴影干扰更明显。第三是动态遮挡波浪拍打船壳产生的水花、系泊缆绳、岸桥设备都可能短暂遮住水线区域。所以在做算法选型之前先要明确一点这套系统检测的其实是两个部件一个是水线边界用来做粗定位和实时预警另一个是船体侧舷的吃水标尺就是船头船舷上那串刻度数字用来做高精度读数。标尺在画面里更小、更局部但纹理特征比水线稳定适合作为精修依据。单一模型同时输出这两类目标后续预警逻辑才有数据可算。2.2 从“检测整体”到“检测部件”YOLOv8选型理由与替代方案YOLOv8能成为这类项目的事实标准不是因为它在某个榜单上分数最高而是因为它把训练、验证、导出、部署的路径压缩到了极短。如果你画过yolov8的网络结构图会看到它的主干是CSPDarknet53的改进版C2f结构检测头换成了Anchor-Free的Decoupled Head分类和回归分支解耦。这两个结构变化对吃水线检测有直接意义C2f在保持计算量基本不变的前提下提升了梯度流小目标特征传递更充分Anchor-Free则让模型对目标形状不再敏感不需要预设法先锚框。对比之下YOLOv5的Anchor-Based检测头在目标长宽比极端分布时需要手动调anchor尺寸否则Recall上不去而传统图像处理路线在前面已经说过连稳定的边缘都提不出来。R-CNN系列检测精度可以但推理速度撑不住多路视频流实时分析。因此在这类“现场摄像头实时预警”的场景里YOLOv8是最稳的起点。实际工程里还有一种两阶段方案值得知道先用YOLOv8检测船体侧舷和标尺区域在这个区域内再用局部梯度分析精修水线位置。检测模型解决“水线在哪一片”传统CV解决“水线精确到哪一行像素”。这套组合能把吃水值误差从十厘米级压到厘米级代价是每帧多花几毫秒后面第6章讲吃水值换算时会展开。2.3 系统架构采集、检测、预警、展示四层怎么协作一个能拿到现场演示的监测系统至少分四层采集层、检测层、预警层、展示层。采集层负责对接海康、大华这类厂商的RTSP视频流或者本地USB摄像头检测层用训练好的YOLOv8权重逐帧跑推理输出目标类别、置信度、检测框坐标预警层把检测框底边的像素位置换算成真实吃水值和船型档位的安全吃水阈值做比较超限后写入报警记录展示层把检测框、吃水数字、报警状态画在画面上提供人工复核入口。这四层之间用异步队列通信而不是同步调用。摄像头推流是持续的检测推理要跟得上的话不能每帧都做全流程处理吃水线变化是缓慢过程没必要在报警判定上也逐帧硬算。实际部署时检测线程独立运行结果放进队列预警线程每2到3秒取一次队列里的最新值做判定展示线程只管刷新界面。后面第3章的第3节会给出具体的线程模型这里是先把架构定下来。3. 跑通最小监测系统环境安装、推理主流程与可视化界面3.1 环境准备Ubuntu与Windows两条路线的安装清单先给结论有NVIDIA显卡用GPU版PyTorch没有显卡用CPU版也能跑只是实时性预期要放低。win系统注意路径不要带中文Ubuntu 20.04是这套项目最常见的部署系统按下面顺序装基本不会翻车。# 创建Python虚拟环境避免把系统Python搞乱 python3 -m venv yolov8_env source yolov8_env/bin/activate # 安装PyTorch CPU版无显卡的机器用这个 pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu # 安装ultralytics这是YOLOv8训练和推理的官方库 pip install ultralytics # 验证安装 yolo predict modelyolov8n.pt sourcehttps://ultralytics.com/images/bus.jpg有显卡的机器把torch安装命令换成对应CUDA版本的index-url即可安装后用nvidia-smi确认驱动版本和显存大小。CPU版本跑yolov8n推理一张640分辨率的图片大约需要200到400毫秒跑1280分辨率会到1秒以上。做实时监测建议至少用一张8G显存的显卡GTX 1660 Ti级别的卡够跑yolov8s模型再大的模型帧率会掉下来。3.2 用训练好的best.pt跑通第一帧检测项目里训练好的权重一般放在runs/waterline_s/weights/best.pt这个路径。拿到权重后先用单张图片验证推理链路再接视频流。from ultralytics import YOLO # 加载训练好的权重best.pt是验证集指标最优的权重 model YOLO(runs/waterline_s/weights/best.pt) # 单张图片推理确认模型能正确框出船体和水线 results model.predict( sourcetest.jpg, imgsz1280, # 输入尺寸吃水线是小目标1280比640召回率高 conf0.35, # 置信度阈值低于该值的框被丢弃 iou0.5, # NMS的IoU阈值框重叠多时调高 classes[0, 1, 2], # 只检测waterline、draft_mark、hull三个类别 verboseFalse ) # 画框结果保存到runs目录供人工检查 results[0].save(output.jpg)imgsz参数决定模型输入分辨率用1280时小目标的召回率会明显好于640代价是推理时间翻倍。工程上建议先用1280训练推理时如果显卡紧张再降回960或640。conf调低能找回漏检但误报也会变多配合后面的时序滤波才能压住。3.3 可视化界面QT桌面端与Web端怎么选这个项目的可视化界面通常有两种形态选型逻辑很简单一个人用、要答辩演示、不想碰前端选QT桌面端多人同时看、要部署在值班室大屏上选Web端。形态技术栈优势主要改动点QT桌面端PyQt5/PySide6 QThread离线运行、依赖少、答辩现场不容易出网络问题用QThread跑推理信号回传画面Web端FastAPI/Flask WebSocket多终端访问、可对接值班室大屏推理服务独立前端只负责展示QT界面最容易犯的错误是把推理直接写在主线程里。点“开始监测”后窗口白屏转圈等推理完才恢复然后被判定“界面卡死”。正确做法是单独开一个工作线程负责推理界面只接收结果信号from PyQt5.QtCore import QThread, pyqtSignal from ultralytics import YOLO class InferenceThread(QThread): # 每帧结果通过信号发出携带原始画面和检测框坐标 frame_ready pyqtSignal(object, list) def __init__(self, model_path, source): super().__init__() self.model YOLO(model_path) self.source source def run(self): # streamTrue表示逐帧产出结果不会等整段视频处理完 for result in self.model.predict( sourceself.source, streamTrue, imgsz1280, verboseFalse ): boxes result.boxes.xyxy.cpu().numpy() self.frame_ready.emit(result.orig_img, boxes)记得在窗口关闭时调用thread.terminate()或设置退出标志否则子线程还在跑程序退出时会报“QThread: Destroyed while thread is still running”。3.4 接入现场摄像头RTSP地址与参数归一化现场摄像头接入用RTSP协议海康和大华的默认端口都是554。常见的地址格式是rtsp://用户名:密码摄像头IP:554/Streaming/Channels/101具体路径各家厂商不一样登录摄像头管理页面能看到预览地址。接入后把码流调成子码流分辨率720P或1080P、帧率10到15帧因为吃水线检测不依赖高帧率主码流只会白白增加解码压力。# 接现场RTSP流实时监测 rtsp_url rtsp://admin:password192.168.1.100:554/Streaming/Channels/101 for result in model.predict( sourcertsp_url, streamTrue, imgsz1280, conf0.35, classes[0, 1], # 现场吃水值计算只需要waterline和draft_mark verboseFalse ): # 每帧拿到结果交给预警逻辑处理 process_frame(result)注意RTSP流断线是常态摄像头重启、网络波动都会导致流中断。程序的容错逻辑要做在采集层断线后自动重连重连间隔从5秒开始指数退避最多1分钟一次避免崩溃或无限重试。4. 制作自己的吃水线数据集并完成训练标注转换与关键参数4.1 数据集的目录结构与类别定义标题里的“完整数据集”拿到手后先确认目录结构是否符合YOLO规范images目录放图片labels目录放同名txt标注文件两边都按train、val、test划分。图片是JPG或PNG标注是YOLO格式的纯文本每行对应一个目标框格式是class_id cx cy w h四值都是相对图片宽高的归一化坐标0到1之间。类别定义上建议设三个类waterline水线边界、draft_mark吃水标尺、hull船体侧舷。不理解为什么标hull的人训练完会发现水线框经常飘到背景里去——模型没有船体作为参照就不知道水线应该贴在什么物体上。hull类别解决了这个上下文问题也方便后续做“先找船体、再精修水线”的两阶段处理。4.2 Labelme标注转YOLO格式转换脚本与坐标保护数据标注一般用Labelme画多边形框它能精确表达水线这种弯曲细长的目标。但YOLO训练需要的是矩形框所以必须做格式转换。转换逻辑里最容易出问题的是Labelme允许标注点拉到画面外转出来的归一化坐标会出现大于1的非法值训练时直接中断。import json import os from glob import glob def convert_labelme_to_yolo(json_path, out_dir, class_map): with open(json_path, r, encodingutf-8) as f: data json.load(f) img_w data[imageWidth] img_h data[imageHeight] txt_name os.path.splitext(os.path.basename(json_path))[0] .txt out_path os.path.join(out_dir, txt_name) lines [] for shape in data[shapes]: label shape[label] if label not in class_map: continue pts shape[points] if len(pts) 3: continue xs [p[0] for p in pts] ys [p[1] for p in pts] x_min, x_max min(xs), max(xs) y_min, y_max min(ys), max(ys) cx ((x_min x_max) / 2) / img_w cy ((y_min y_max) / 2) / img_h w (x_max - x_min) / img_w h (y_max - y_min) / img_h # 坐标截断到0-1之间防止越界值导致训练中断 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{class_map[label]} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) with open(out_path, w) as f: f.write(\n.join(lines)) class_map {waterline: 0, draft_mark: 1, hull: 2} out_dir ./datasets/ship_waterline/labels/train os.makedirs(out_dir, exist_okTrue) for json_file in glob(./labelme_jsons/*.json): convert_labelme_to_yolo(json_file, out_dir, class_map)这里的class_map里数字和类别名的对应关系必须和后面数据配置文件里的names一一对应错一位整套训练就白跑。坐标clip这行别删现场标注时框稍微拖出画面边缘太常见了不保护一下就是随机中断训练。另外提醒一个标注习惯水线是细长目标用一个外包矩形框会把大量水面背景包进来模型学到的是“一片水面中间贴一条线”的上下文。更好的做法是把水线沿船壳方向拆成两到三段分别标框每段框的长宽比更接近常规目标训练稳定性好很多。这也是标尺类目标标注的通用经验。4.3 训练数据yaml、命令与每个参数的含义先建一个数据配置文件指向数据集路径和类别定义# ship_waterline.yaml # 路径使用相对路径相对你执行训练命令的工作目录 train: datasets/ship_waterline/images/train val: datasets/ship_waterline/images/val test: datasets/ship_waterline/images/test nc: 3 names: 0: waterline 1: draft_mark 2: hull注意yaml文件里不能出现tab字符路径末尾不要带斜杠nc和names的数量必须和标注txt里的class_id对上。训练命令和关键参数如下yolo detect train \ modelyolov8s.pt \ dataship_waterline.yaml \ imgsz1280 \ epochs300 \ batch8 \ patience30 \ project./runs \ namewaterline_smodelyolov8s.pt用的是预训练权重做迁移学习比从头训练收敛快得多。imgsz1280是这套项目最关键的参数之一吃水线和标尺都属于小目标640分辨率下大量小目标在特征图里只剩几个像素召回率上不去升到1280会有明显改善代价是显存占用翻4倍8G显存只能带batch8。epochs300配合patience30的意思是验证集指标连续30轮没有提升就提前停止防止后期过拟合白算。训练结束时目录里会同时生成best.pt和last.ptlast.pt是最后一轮的权重best.pt是验证集精度最优的权重部署只认best.pt。4.4 损失曲线怎么读三个指标决定能不能用训练过程会实时产出损失曲线保存在训练输出目录的results.csv和results.png里。手动画曲线用一段简单的Python脚本就能搞定import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/waterline_s/results.csv) plt.figure(figsize(10, 6)) plt.plot(df[epoch], df[train/box_loss], labeltrain box_loss) plt.plot(df[epoch], df[val/box_loss], labelval box_loss) plt.xlabel(epoch) plt.ylabel(loss) plt.legend() plt.grid(True) plt.savefig(loss_curve.png, dpi150)看曲线只需要回答三个问题val/box_loss有没有持续下降到平台期val/recall召回率有没有到0.8以上precision精确率和recall之间是否均衡。如果val/box_loss降到一半开始反弹、train/box_loss还在下降说明模型开始背训练集早停机制会自动截住。如果loss全程纹丝不动先别调参检查数据集有没有空标注文件、图片有没有损坏、类别数量是不是严重不均衡——大多数训练翻车都是数据问题模型本身很少是黑匣子。5. 吃水线监测的4个高频踩坑现场现象、原因与解法5.1 夜间与逆光时段检测框抖动甚至消失现象白天阳光充足时检测正常傍晚逆光或夜间辅助照明场景里水线检测框开始剧烈抖动严重时整帧丢失。原因训练集大多是白天顺光照片模型学到的水线特征是船壳和水面的强边缘对比。逆光时船体背光面变成暗色水面反光变成亮色灰度对比反转特征失效。夜间更极端两个区域都沉到暗部。解决第一个办法最直接——按时间段补数据清晨、傍晚、夜间各补充不少于总样本量20%的图片模型见过这些场景才能稳定输出。第二个办法是换检测策略夜间不用水线类改用hull类框出船体侧舷再在框内用局部灰度梯度找水面边界。船体轮廓在夜间比水线清晰得多把“检测线”降级为“检测区域”鲁棒性反而上来。5.2 波浪水花被当成水线单帧误报的时序滤波解法现象有风浪时波浪拍打船壳溅起的水花形成一条亮色边缘模型把这条边缘误判成水线吃水值瞬间上跳几十厘米触发误报警。原因模型在单帧画面上看到的是局部纹理水花边缘和水线边缘在特征上确实无法区分。单帧判定天然不可靠这是所有图像监测系统的通病。解决引入时序滤波核心规则是“连续N帧取5到10吃水值变化不超过±5厘米才更新水位”。YOLOv8集成了ByteTrack跟踪能力可以直接用跟踪轨迹的ID做逐船数据平滑取轨迹中位数而不是单帧结果。这里有一个取舍要说清楚滤波越强误报越少但真实超载报警也会延迟几秒。预警线程和显示线程要分离显示线程继续实时刷新画面预警线程用平滑后的数据做阈值判定两边互不干扰。5.3 坐标越界、损坏图片导致训练中断现象训练跑到中途日志突然报错类似“corrupt JPEG”或loss计算出来是NaN训练进程直接退出。原因Labelme标注时框拖出了画面边界转换脚本又没有做坐标保护归一化后出现大于1的浮点值或者数据集里混入了截断的损坏图片ultralytics的数据加载器在解码时抛异常。解决转换脚本里对cx cy w h统一做clip是第一步更稳妥的做法是在训练前跑一遍数据清洗扫描所有标注txt过滤掉宽度或高度小于0.01的相对值这类碎片框几乎全是误标用PIL打开每一张图片确认能解码删除打不开的文件。数据清洗脚本加起来不到50行跑一次两分钟能省出至少两天的调参时间。5.4 界面卡死与内存上涨线程模型不对现象点击“开始监测”后界面无响应过几秒恢复期间无法停止长时间运行后内存持续增长直到系统变卡。原因把推理循环直接写在了UI主线程里推理是阻塞操作画面刷新自然被卡住内存上涨通常是每帧的result对象没释放帧率赶不上处理速度时队列无限堆积。解决用上一章给的QThread方案把推理挪出主线程结果通过信号回传。内存问题在推理循环里不要保存每一帧的原始图像只保留检测框坐标和必要的截图用queue.Queue(maxsize10)做有界队列满了就丢最旧的一帧保证系统长时间运行不被拖垮。这条对Web端同样适用推理服务单独进程部署别和前端服务混在一起。5.5 换摄像头后检测框错位标定参数不是一次到位的现象训练好的模型在自己测试视频上效果很好换到现场另一台摄像头后吃水值整体偏大或偏小检测框位置正确但换算出来的数值不对。原因每个摄像头的安装高度、俯仰角度、焦距都不一样像素坐标到真实吃水值的映射关系成了未知数。模型负责找到目标标定参数负责把像素变成米后者是独立的现场工程问题。解决把pixels_per_meter和offset这类标定参数抽到配置文件里不要写死在代码中。每次换点位部署时必须重新标定一次具体做法是找船体上已知长度的参照物比如吃水标尺的两个刻度间距量出它在画面里占多少像素用实际米数除以像素数得到比例系数。这是现场最容易被跳过的一步跳过之后系统看起来能跑但数据全不可信属于典型的“部署跑通了、业务全不对”。6. 把像素变成米吃水值换算、预警门限与边缘端加速6.1 线性和offset标定用一次实拍把像素坐标换算成吃水值检测框输出的底边像素位置不是真实吃水值中间隔着相机成像的缩放和透视偏移。现场最实用的换算是线性模型draft_m (y_bottom - y_ref) / pixels_per_meter offset。y_ref是水面参考线在画面中的像素位置pixels_per_meter用标尺刻度标定offset修正船体弧形外板和吃水线不重合带来的系统偏差。换现场必须重标这个习惯能救你一命。6.2 三档预警逻辑与人工复核入口等级判定条件界面反馈正常吃水值低于安全吃水线绿色边框状态栏显示实时数值关注超过安全吃水但低于满载吃水黄色边框每分钟记录一次趋势数据报警超过满载吃水或连续10帧保持超限红色边框声音提示自动截取证据图报警逻辑务必保留人工复核入口值班员确认后报警才正式归档。纯自动报警在恶劣天气下误报率压不到零人工确认这一步是现场能长期运行的关键。6.3 TensorRT与rknn导出边缘端部署形态# 导出成TensorRT engine推理速度比PyTorch原生快3到5倍 yolo export modelruns/waterline_s/weights/best.pt formatengine device0 halfTrue导出后的best.engine只能在同一代显卡上运行换显卡需要重新导出。要在rk3588这类边缘板子上跑走的是rknn-toolkit2转换流程先把权重转ONNX再转rknn精度会有轻微下降验证时需要注意对比。我每次换一个码头部署都会重新做一次像素比标定顺手检查摄像头有没有被遮挡遮住半面镜头再强的模型都是白搭。希望这个思路能帮到你。本文还有配套的精品资源点击获取 基于YOLOv8的港口船舶吃水线实时监测系统实现与部署
简介船舶吃水线实时监测是港口安全管理中的关键环节这套基于YOLOv8的预警系统是围绕该场景设计的完整毕设方案面向计算机视觉、人工智能方向的学生与开发者可直接用于毕业设计、课程设计或项目初期立项演示。压缩包共收录97个文件以70个Python源码脚本为主体涵盖模型训练、检测服务、可视化界面等模块另含4个PT模型权重文件、5个XML配置以及演示视频整体体积仅24.21MB结构紧凑且易于部署。目前已有59人在线学习浏览项目经过完整测试、运行成功后才上传可靠性有保障。资源内置完整数据集和可视化页面可生成混淆矩阵、F1分数曲线、精确率-召回率曲线、标签分布图等核心评价图表并附带README部署说明按步骤操作即可复现适合需要快速完成高质量毕设或课设项目的同学参考。1. 港口船舶吃水线监测为什么常规目标检测接不住这个场景值班室的监控墙上有二十几路画面船靠泊、离泊、装卸货都在上面。真要让值班员盯住某一艘船的水线有没有超载超过三分钟眼睛就花了更别说夜间画面里水面和船体都是一团黑。基于YOLOv8的港口船舶吃水线实时监测预警系统解决的就是把这个“目测”动作替换成机器判读用模型在画面里找到船体和吃水线位置把像素坐标换算成真实吃水值超过阈值直接弹报警归档记录整套流程带可视化界面。标题里的源码、完整数据集、部署教程三件套齐全属于拿到就能跑的工程化项目特别适合毕设、课程设计出完整作品也适合港航信息化团队拿去做概念验证。下面按一条可落地的路径讲清楚怎么跑通、怎么训练自己的数据集、坑在哪里。2. 从物理场景到算法选型YOLOv8做吃水线检测的可行性边界2.1 吃水线检测为什么难小目标、遮挡与光照的三重挑战吃水线在图像上不是一条清晰锐利的线。船体侧舷与水面的交界区域受波浪起伏、水花飞溅、水面反光的影响在像素层面上是一段低对比度的过渡带。拿传统边缘检测或者阈值分割去处理水面上的波纹、油污、漂浮物都会产生大量伪边缘阈值调一次只能用半天换个天气就得重新调这种方案在现场基本活不过一周。真正的难点有三个。第一是小目标特性一条几十米长的散货船在港区监控画面里侧舷区域往往只有几百像素高水线位置对应的检测框高宽比极端属于典型的小目标场景。第二是光照变化剧烈正午强光下水面反光严重水线附近亮度接近高光傍晚逆光时船体背光面和水面灰度几乎融为一体夜间靠辅助照明时阴影干扰更明显。第三是动态遮挡波浪拍打船壳产生的水花、系泊缆绳、岸桥设备都可能短暂遮住水线区域。所以在做算法选型之前先要明确一点这套系统检测的其实是两个部件一个是水线边界用来做粗定位和实时预警另一个是船体侧舷的吃水标尺就是船头船舷上那串刻度数字用来做高精度读数。标尺在画面里更小、更局部但纹理特征比水线稳定适合作为精修依据。单一模型同时输出这两类目标后续预警逻辑才有数据可算。2.2 从“检测整体”到“检测部件”YOLOv8选型理由与替代方案YOLOv8能成为这类项目的事实标准不是因为它在某个榜单上分数最高而是因为它把训练、验证、导出、部署的路径压缩到了极短。如果你画过yolov8的网络结构图会看到它的主干是CSPDarknet53的改进版C2f结构检测头换成了Anchor-Free的Decoupled Head分类和回归分支解耦。这两个结构变化对吃水线检测有直接意义C2f在保持计算量基本不变的前提下提升了梯度流小目标特征传递更充分Anchor-Free则让模型对目标形状不再敏感不需要预设法先锚框。对比之下YOLOv5的Anchor-Based检测头在目标长宽比极端分布时需要手动调anchor尺寸否则Recall上不去而传统图像处理路线在前面已经说过连稳定的边缘都提不出来。R-CNN系列检测精度可以但推理速度撑不住多路视频流实时分析。因此在这类“现场摄像头实时预警”的场景里YOLOv8是最稳的起点。实际工程里还有一种两阶段方案值得知道先用YOLOv8检测船体侧舷和标尺区域在这个区域内再用局部梯度分析精修水线位置。检测模型解决“水线在哪一片”传统CV解决“水线精确到哪一行像素”。这套组合能把吃水值误差从十厘米级压到厘米级代价是每帧多花几毫秒后面第6章讲吃水值换算时会展开。2.3 系统架构采集、检测、预警、展示四层怎么协作一个能拿到现场演示的监测系统至少分四层采集层、检测层、预警层、展示层。采集层负责对接海康、大华这类厂商的RTSP视频流或者本地USB摄像头检测层用训练好的YOLOv8权重逐帧跑推理输出目标类别、置信度、检测框坐标预警层把检测框底边的像素位置换算成真实吃水值和船型档位的安全吃水阈值做比较超限后写入报警记录展示层把检测框、吃水数字、报警状态画在画面上提供人工复核入口。这四层之间用异步队列通信而不是同步调用。摄像头推流是持续的检测推理要跟得上的话不能每帧都做全流程处理吃水线变化是缓慢过程没必要在报警判定上也逐帧硬算。实际部署时检测线程独立运行结果放进队列预警线程每2到3秒取一次队列里的最新值做判定展示线程只管刷新界面。后面第3章的第3节会给出具体的线程模型这里是先把架构定下来。3. 跑通最小监测系统环境安装、推理主流程与可视化界面3.1 环境准备Ubuntu与Windows两条路线的安装清单先给结论有NVIDIA显卡用GPU版PyTorch没有显卡用CPU版也能跑只是实时性预期要放低。win系统注意路径不要带中文Ubuntu 20.04是这套项目最常见的部署系统按下面顺序装基本不会翻车。# 创建Python虚拟环境避免把系统Python搞乱 python3 -m venv yolov8_env source yolov8_env/bin/activate # 安装PyTorch CPU版无显卡的机器用这个 pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu # 安装ultralytics这是YOLOv8训练和推理的官方库 pip install ultralytics # 验证安装 yolo predict modelyolov8n.pt sourcehttps://ultralytics.com/images/bus.jpg有显卡的机器把torch安装命令换成对应CUDA版本的index-url即可安装后用nvidia-smi确认驱动版本和显存大小。CPU版本跑yolov8n推理一张640分辨率的图片大约需要200到400毫秒跑1280分辨率会到1秒以上。做实时监测建议至少用一张8G显存的显卡GTX 1660 Ti级别的卡够跑yolov8s模型再大的模型帧率会掉下来。3.2 用训练好的best.pt跑通第一帧检测项目里训练好的权重一般放在runs/waterline_s/weights/best.pt这个路径。拿到权重后先用单张图片验证推理链路再接视频流。from ultralytics import YOLO # 加载训练好的权重best.pt是验证集指标最优的权重 model YOLO(runs/waterline_s/weights/best.pt) # 单张图片推理确认模型能正确框出船体和水线 results model.predict( sourcetest.jpg, imgsz1280, # 输入尺寸吃水线是小目标1280比640召回率高 conf0.35, # 置信度阈值低于该值的框被丢弃 iou0.5, # NMS的IoU阈值框重叠多时调高 classes[0, 1, 2], # 只检测waterline、draft_mark、hull三个类别 verboseFalse ) # 画框结果保存到runs目录供人工检查 results[0].save(output.jpg)imgsz参数决定模型输入分辨率用1280时小目标的召回率会明显好于640代价是推理时间翻倍。工程上建议先用1280训练推理时如果显卡紧张再降回960或640。conf调低能找回漏检但误报也会变多配合后面的时序滤波才能压住。3.3 可视化界面QT桌面端与Web端怎么选这个项目的可视化界面通常有两种形态选型逻辑很简单一个人用、要答辩演示、不想碰前端选QT桌面端多人同时看、要部署在值班室大屏上选Web端。形态技术栈优势主要改动点QT桌面端PyQt5/PySide6 QThread离线运行、依赖少、答辩现场不容易出网络问题用QThread跑推理信号回传画面Web端FastAPI/Flask WebSocket多终端访问、可对接值班室大屏推理服务独立前端只负责展示QT界面最容易犯的错误是把推理直接写在主线程里。点“开始监测”后窗口白屏转圈等推理完才恢复然后被判定“界面卡死”。正确做法是单独开一个工作线程负责推理界面只接收结果信号from PyQt5.QtCore import QThread, pyqtSignal from ultralytics import YOLO class InferenceThread(QThread): # 每帧结果通过信号发出携带原始画面和检测框坐标 frame_ready pyqtSignal(object, list) def __init__(self, model_path, source): super().__init__() self.model YOLO(model_path) self.source source def run(self): # streamTrue表示逐帧产出结果不会等整段视频处理完 for result in self.model.predict( sourceself.source, streamTrue, imgsz1280, verboseFalse ): boxes result.boxes.xyxy.cpu().numpy() self.frame_ready.emit(result.orig_img, boxes)记得在窗口关闭时调用thread.terminate()或设置退出标志否则子线程还在跑程序退出时会报“QThread: Destroyed while thread is still running”。3.4 接入现场摄像头RTSP地址与参数归一化现场摄像头接入用RTSP协议海康和大华的默认端口都是554。常见的地址格式是rtsp://用户名:密码摄像头IP:554/Streaming/Channels/101具体路径各家厂商不一样登录摄像头管理页面能看到预览地址。接入后把码流调成子码流分辨率720P或1080P、帧率10到15帧因为吃水线检测不依赖高帧率主码流只会白白增加解码压力。# 接现场RTSP流实时监测 rtsp_url rtsp://admin:password192.168.1.100:554/Streaming/Channels/101 for result in model.predict( sourcertsp_url, streamTrue, imgsz1280, conf0.35, classes[0, 1], # 现场吃水值计算只需要waterline和draft_mark verboseFalse ): # 每帧拿到结果交给预警逻辑处理 process_frame(result)注意RTSP流断线是常态摄像头重启、网络波动都会导致流中断。程序的容错逻辑要做在采集层断线后自动重连重连间隔从5秒开始指数退避最多1分钟一次避免崩溃或无限重试。4. 制作自己的吃水线数据集并完成训练标注转换与关键参数4.1 数据集的目录结构与类别定义标题里的“完整数据集”拿到手后先确认目录结构是否符合YOLO规范images目录放图片labels目录放同名txt标注文件两边都按train、val、test划分。图片是JPG或PNG标注是YOLO格式的纯文本每行对应一个目标框格式是class_id cx cy w h四值都是相对图片宽高的归一化坐标0到1之间。类别定义上建议设三个类waterline水线边界、draft_mark吃水标尺、hull船体侧舷。不理解为什么标hull的人训练完会发现水线框经常飘到背景里去——模型没有船体作为参照就不知道水线应该贴在什么物体上。hull类别解决了这个上下文问题也方便后续做“先找船体、再精修水线”的两阶段处理。4.2 Labelme标注转YOLO格式转换脚本与坐标保护数据标注一般用Labelme画多边形框它能精确表达水线这种弯曲细长的目标。但YOLO训练需要的是矩形框所以必须做格式转换。转换逻辑里最容易出问题的是Labelme允许标注点拉到画面外转出来的归一化坐标会出现大于1的非法值训练时直接中断。import json import os from glob import glob def convert_labelme_to_yolo(json_path, out_dir, class_map): with open(json_path, r, encodingutf-8) as f: data json.load(f) img_w data[imageWidth] img_h data[imageHeight] txt_name os.path.splitext(os.path.basename(json_path))[0] .txt out_path os.path.join(out_dir, txt_name) lines [] for shape in data[shapes]: label shape[label] if label not in class_map: continue pts shape[points] if len(pts) 3: continue xs [p[0] for p in pts] ys [p[1] for p in pts] x_min, x_max min(xs), max(xs) y_min, y_max min(ys), max(ys) cx ((x_min x_max) / 2) / img_w cy ((y_min y_max) / 2) / img_h w (x_max - x_min) / img_w h (y_max - y_min) / img_h # 坐标截断到0-1之间防止越界值导致训练中断 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{class_map[label]} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) with open(out_path, w) as f: f.write(\n.join(lines)) class_map {waterline: 0, draft_mark: 1, hull: 2} out_dir ./datasets/ship_waterline/labels/train os.makedirs(out_dir, exist_okTrue) for json_file in glob(./labelme_jsons/*.json): convert_labelme_to_yolo(json_file, out_dir, class_map)这里的class_map里数字和类别名的对应关系必须和后面数据配置文件里的names一一对应错一位整套训练就白跑。坐标clip这行别删现场标注时框稍微拖出画面边缘太常见了不保护一下就是随机中断训练。另外提醒一个标注习惯水线是细长目标用一个外包矩形框会把大量水面背景包进来模型学到的是“一片水面中间贴一条线”的上下文。更好的做法是把水线沿船壳方向拆成两到三段分别标框每段框的长宽比更接近常规目标训练稳定性好很多。这也是标尺类目标标注的通用经验。4.3 训练数据yaml、命令与每个参数的含义先建一个数据配置文件指向数据集路径和类别定义# ship_waterline.yaml # 路径使用相对路径相对你执行训练命令的工作目录 train: datasets/ship_waterline/images/train val: datasets/ship_waterline/images/val test: datasets/ship_waterline/images/test nc: 3 names: 0: waterline 1: draft_mark 2: hull注意yaml文件里不能出现tab字符路径末尾不要带斜杠nc和names的数量必须和标注txt里的class_id对上。训练命令和关键参数如下yolo detect train \ modelyolov8s.pt \ dataship_waterline.yaml \ imgsz1280 \ epochs300 \ batch8 \ patience30 \ project./runs \ namewaterline_smodelyolov8s.pt用的是预训练权重做迁移学习比从头训练收敛快得多。imgsz1280是这套项目最关键的参数之一吃水线和标尺都属于小目标640分辨率下大量小目标在特征图里只剩几个像素召回率上不去升到1280会有明显改善代价是显存占用翻4倍8G显存只能带batch8。epochs300配合patience30的意思是验证集指标连续30轮没有提升就提前停止防止后期过拟合白算。训练结束时目录里会同时生成best.pt和last.ptlast.pt是最后一轮的权重best.pt是验证集精度最优的权重部署只认best.pt。4.4 损失曲线怎么读三个指标决定能不能用训练过程会实时产出损失曲线保存在训练输出目录的results.csv和results.png里。手动画曲线用一段简单的Python脚本就能搞定import pandas as pd import matplotlib.pyplot as plt df pd.read_csv(runs/waterline_s/results.csv) plt.figure(figsize(10, 6)) plt.plot(df[epoch], df[train/box_loss], labeltrain box_loss) plt.plot(df[epoch], df[val/box_loss], labelval box_loss) plt.xlabel(epoch) plt.ylabel(loss) plt.legend() plt.grid(True) plt.savefig(loss_curve.png, dpi150)看曲线只需要回答三个问题val/box_loss有没有持续下降到平台期val/recall召回率有没有到0.8以上precision精确率和recall之间是否均衡。如果val/box_loss降到一半开始反弹、train/box_loss还在下降说明模型开始背训练集早停机制会自动截住。如果loss全程纹丝不动先别调参检查数据集有没有空标注文件、图片有没有损坏、类别数量是不是严重不均衡——大多数训练翻车都是数据问题模型本身很少是黑匣子。5. 吃水线监测的4个高频踩坑现场现象、原因与解法5.1 夜间与逆光时段检测框抖动甚至消失现象白天阳光充足时检测正常傍晚逆光或夜间辅助照明场景里水线检测框开始剧烈抖动严重时整帧丢失。原因训练集大多是白天顺光照片模型学到的水线特征是船壳和水面的强边缘对比。逆光时船体背光面变成暗色水面反光变成亮色灰度对比反转特征失效。夜间更极端两个区域都沉到暗部。解决第一个办法最直接——按时间段补数据清晨、傍晚、夜间各补充不少于总样本量20%的图片模型见过这些场景才能稳定输出。第二个办法是换检测策略夜间不用水线类改用hull类框出船体侧舷再在框内用局部灰度梯度找水面边界。船体轮廓在夜间比水线清晰得多把“检测线”降级为“检测区域”鲁棒性反而上来。5.2 波浪水花被当成水线单帧误报的时序滤波解法现象有风浪时波浪拍打船壳溅起的水花形成一条亮色边缘模型把这条边缘误判成水线吃水值瞬间上跳几十厘米触发误报警。原因模型在单帧画面上看到的是局部纹理水花边缘和水线边缘在特征上确实无法区分。单帧判定天然不可靠这是所有图像监测系统的通病。解决引入时序滤波核心规则是“连续N帧取5到10吃水值变化不超过±5厘米才更新水位”。YOLOv8集成了ByteTrack跟踪能力可以直接用跟踪轨迹的ID做逐船数据平滑取轨迹中位数而不是单帧结果。这里有一个取舍要说清楚滤波越强误报越少但真实超载报警也会延迟几秒。预警线程和显示线程要分离显示线程继续实时刷新画面预警线程用平滑后的数据做阈值判定两边互不干扰。5.3 坐标越界、损坏图片导致训练中断现象训练跑到中途日志突然报错类似“corrupt JPEG”或loss计算出来是NaN训练进程直接退出。原因Labelme标注时框拖出了画面边界转换脚本又没有做坐标保护归一化后出现大于1的浮点值或者数据集里混入了截断的损坏图片ultralytics的数据加载器在解码时抛异常。解决转换脚本里对cx cy w h统一做clip是第一步更稳妥的做法是在训练前跑一遍数据清洗扫描所有标注txt过滤掉宽度或高度小于0.01的相对值这类碎片框几乎全是误标用PIL打开每一张图片确认能解码删除打不开的文件。数据清洗脚本加起来不到50行跑一次两分钟能省出至少两天的调参时间。5.4 界面卡死与内存上涨线程模型不对现象点击“开始监测”后界面无响应过几秒恢复期间无法停止长时间运行后内存持续增长直到系统变卡。原因把推理循环直接写在了UI主线程里推理是阻塞操作画面刷新自然被卡住内存上涨通常是每帧的result对象没释放帧率赶不上处理速度时队列无限堆积。解决用上一章给的QThread方案把推理挪出主线程结果通过信号回传。内存问题在推理循环里不要保存每一帧的原始图像只保留检测框坐标和必要的截图用queue.Queue(maxsize10)做有界队列满了就丢最旧的一帧保证系统长时间运行不被拖垮。这条对Web端同样适用推理服务单独进程部署别和前端服务混在一起。5.5 换摄像头后检测框错位标定参数不是一次到位的现象训练好的模型在自己测试视频上效果很好换到现场另一台摄像头后吃水值整体偏大或偏小检测框位置正确但换算出来的数值不对。原因每个摄像头的安装高度、俯仰角度、焦距都不一样像素坐标到真实吃水值的映射关系成了未知数。模型负责找到目标标定参数负责把像素变成米后者是独立的现场工程问题。解决把pixels_per_meter和offset这类标定参数抽到配置文件里不要写死在代码中。每次换点位部署时必须重新标定一次具体做法是找船体上已知长度的参照物比如吃水标尺的两个刻度间距量出它在画面里占多少像素用实际米数除以像素数得到比例系数。这是现场最容易被跳过的一步跳过之后系统看起来能跑但数据全不可信属于典型的“部署跑通了、业务全不对”。6. 把像素变成米吃水值换算、预警门限与边缘端加速6.1 线性和offset标定用一次实拍把像素坐标换算成吃水值检测框输出的底边像素位置不是真实吃水值中间隔着相机成像的缩放和透视偏移。现场最实用的换算是线性模型draft_m (y_bottom - y_ref) / pixels_per_meter offset。y_ref是水面参考线在画面中的像素位置pixels_per_meter用标尺刻度标定offset修正船体弧形外板和吃水线不重合带来的系统偏差。换现场必须重标这个习惯能救你一命。6.2 三档预警逻辑与人工复核入口等级判定条件界面反馈正常吃水值低于安全吃水线绿色边框状态栏显示实时数值关注超过安全吃水但低于满载吃水黄色边框每分钟记录一次趋势数据报警超过满载吃水或连续10帧保持超限红色边框声音提示自动截取证据图报警逻辑务必保留人工复核入口值班员确认后报警才正式归档。纯自动报警在恶劣天气下误报率压不到零人工确认这一步是现场能长期运行的关键。6.3 TensorRT与rknn导出边缘端部署形态# 导出成TensorRT engine推理速度比PyTorch原生快3到5倍 yolo export modelruns/waterline_s/weights/best.pt formatengine device0 halfTrue导出后的best.engine只能在同一代显卡上运行换显卡需要重新导出。要在rk3588这类边缘板子上跑走的是rknn-toolkit2转换流程先把权重转ONNX再转rknn精度会有轻微下降验证时需要注意对比。我每次换一个码头部署都会重新做一次像素比标定顺手检查摄像头有没有被遮挡遮住半面镜头再强的模型都是白搭。希望这个思路能帮到你。本文还有配套的精品资源点击获取