YOLOv5舰船检测工程实战：从数据清洗到RK3568边缘部署

简介：本资源是一套面向计算机视觉初学者与工程实践者的舰船目标检测完整解决方案，聚焦YOLOv5在 maritime 场景下的落地应用，适用于智能航运、海上监控、遥感图像分析等实际任务。资源包含训练完成的多类别舰船检测模型（含舰艇、游轮、帆船、军舰等），mAP超90%，附PR曲线、Loss曲线及PyQt5开发的可视化交互界面，支持图片、视频及实时摄像头检测。压缩包共159个文件，大小769.62MB，涵盖34个Python主程序与工具脚本、27个YOLOv5配置yaml文件、4个UI界面设计文件、4个.pt模型权重、21张标注样图及对应txt/xml标签，另有Dockerfile、训练日志、结果CSV与演示GIF等辅助材料，结构清晰便于复现与二次开发。已有1008人学习下载，提供开箱即用的环境适配方案（兼容标准YOLOv5 PyTorch环境），显著降低部署门槛。

1. 这不是个“玩具项目”，而是一套可直接落地的舰船检测工程闭环

你搜“YOLOv5 舰船检测”，刷出来的大多是零散的GitHub仓库、几页训练日志截图，或者一句“已实现”的模糊描述。但真正跑通一个能用在码头监控、海事巡查、渔政执法场景里的舰船检测系统，远不止“改个yaml文件+跑train.py”这么简单。我过去三年在港口智能监管系统里做过六轮舰船识别迭代，从最初用OpenCV模板匹配误报率47%，到后来基于YOLOv5s部署在RK3568边缘盒子上做到92.3% mAP@0.5，踩过的坑、调过的参数、写过的界面逻辑，全在这套方案里——它不是一个教学Demo，而是一套经过实测验证、能扛住潮气盐雾、支持夜间红外图像、适配国产芯片的完整工程包。

核心关键词已经非常明确：YOLOv5、舰船检测、PyQt界面。这三个词组合起来，意味着你要解决的从来不是单一技术点，而是横跨数据、模型、部署、交互四个层面的系统性问题。比如“几千张标注好的船只检测数据集”这个表述，表面看是资源福利，实则暗藏陷阱：标注质量是否统一？船体遮挡是否处理？小目标比例是否足够？红外与可见光图像是否混杂？这些细节直接决定你训出来的模型在真实码头摄像头下是“看得见”，还是“看得准”。再比如“PyQt界面”，很多人以为只是把detect.py结果画个框，但实际业务中你需要的是：实时视频流低延迟渲染、多路通道切换、检测结果导出为CSV带时间戳、报警阈值动态调节、甚至对接海事AIS数据库做船名回填——这些功能，全得靠PyQt底层信号槽机制和QThread线程管理来稳住。

这套方案适合三类人：一是刚学完YOLOv5基础想练手的真实项目，不是Kaggle式玩具数据；二是需要快速交付港口/海事单位演示系统的集成工程师；三是正在RK3568或RV1106等国产AI芯片上做边缘部署的嵌入式开发者。它不教你Python语法，但会告诉你为什么YOLOv5的anchor设置要按长江口渔船尺寸重聚类；不讲PyQt理论，但会给出QGraphicsView在1080p视频流下卡顿的五种优化路径；不堆砌超参数名词，但会算清楚batch_size=16在V100上显存占用和在RK3568上NPU利用率的关系。接下来所有内容，都来自我在宁波舟山港三期码头现场调试三个月的真实记录。

2. 数据集不是“几千张图”，而是决定模型上限的底层基建

2.1 标注质量：比数量重要十倍的隐形门槛

所谓“几千张标注好的船只检测数据集”，业内常见有三类陷阱：第一类是纯航拍俯视图，船体轮廓清晰但完全缺失侧舷特征，导致模型在岸基固定摄像头（平视角度）下漏检率飙升；第二类是标注框只框船体，忽略桅杆、吊臂、拖轮牵引缆等关键判别特征，结果在密集泊位场景中把起重机误检为船舶；第三类最隐蔽——标注工具用LabelImg默认生成Pascal VOC格式，但坐标未归一化，或保存时用了中文路径，导致YOLOv5 train.py读取时报错“IndexError: list index out of range”，这种错误在Windows环境尤其高频。

我接手过一个标称“5200张”的舰船数据集，实际清洗后只剩3172张可用图。清洗流程必须包含四步硬核检查：

1. 图像完整性校验：用OpenCVcv2.imread()逐张加载，过滤掉损坏的JPEG（常见于手机拍摄后微信压缩二次转存）；
2. 标注框合理性审计：遍历所有txt标签文件，剔除宽高为0、坐标超出图像边界的异常框（脚本核心逻辑：if x_center < 0 or x_center > 1 or y_center < 0 or y_center > 1: discard）；
3. 类别一致性对齐：将原始标注中的“渔船”“货轮”“游艇”“军舰”等12个细分类，按海事监管需求合并为三级体系——一级“民用船舶”（含渔船/货轮/客轮）、二级“特种作业船”（拖轮/引航船/ dredger）、三级“非船舶目标”（浮标/栈桥/集装箱），因为YOLOv5在小数据量下，类别越少收敛越快；
4. 光照与视角分布统计：用ExifTool提取每张图的拍摄时间、GPS经纬度、镜头焦距，建立热力图确认数据集覆盖了晨雾、正午强光、黄昏逆光、夜间红外四种典型工况——这点常被忽略，但直接决定模型在青岛港凌晨三点的误报率。

提示：清洗后的数据集建议按7:2:1划分train/val/test，但test集必须包含至少200张从未参与训练的“盲测图”，且需人工复核每张图的标注框是否覆盖船体全部可见部分（尤其注意船尾螺旋桨区域常被忽略）。

2.2 小目标攻坚：舰船检测真正的技术分水岭

在港口监控场景中，85%以上的待检目标属于小目标：1080p画面中船体高度不足32像素，YOLOv5默认的P3/P4/P5三层检测头对此类目标召回率极低。单纯增加输入分辨率（如640→1280）会导致显存爆炸，我在V100上实测batch_size必须从32降到8，训练速度下降60%且mAP提升仅1.2%。真正有效的解法是三管齐下：

第一，Anchor重聚类：不用YOLOv5自带的k-means，而是用港口实拍图的GT框做聚类。具体操作：先用python tools/general.py --task multi --data data/ship.yaml --weights yolov5s.pt --img 640生成所有训练图的GT框尺寸分布直方图，发现长江口渔船长宽比集中在3.2:1（因船体狭长），而远洋货轮接近6.8:1（因甲板宽阔）。据此定制anchor：

anchors: - [12,18, 24,36, 48,72] # P3层（小目标专用） - [36,54, 72,108, 144,216] # P4层 - [108,162, 216,324, 432,648] # P5层（大目标专用）

这个配置让小目标AP提升4.7%，且避免了P5层因anchor过大导致的误检。

第二，添加SPPF模块增强感受野：在models/yolov5s.yaml的Backbone末尾插入：

- [-1, 1, SPPF, [512, 5]], # kernel=5提升小目标定位精度

实测在测试集上对<20px目标的召回率从63.4%升至79.1%，且推理速度仅慢0.8ms。

第三，Mosaic增强策略调整：默认Mosaic将四图拼接，但港口图像存在大量天空/水面大面积单色区域，拼接后产生虚假边缘。改为仅对含船区域做局部Mosaic：用OpenCV的cv2.findContours()提取每张图的船体掩膜，确保拼接时只融合船体周边30像素内的背景，此改动使训练收敛速度加快22%，且val loss曲线更平滑。

2.3 数据增强的实战取舍：哪些该开，哪些必须关

YOLOv5的augmentations.yaml里有12项增强选项，但在舰船检测中必须做精准开关：

• 必开项：
  hsv_h: 0.015（色调微调应对不同天气）
  hsv_s: 0.7（饱和度拉高突出船体金属反光）
  perspective: 0.0001（极小透视变换模拟摄像头安装角度差异）

• 慎开项：
  translate: 0.1（平移增强）——需关闭mosaic: 1.0，否则船体被切到画布外；
  scale: 0.5（缩放增强）——仅对train阶段启用，val阶段必须设为0，否则mAP计算失真。

• 必关项：
  shear: 0.0（剪切变形）——船体结构刚性极强，剪切后形态失真；
  flipud: 0.0（上下翻转）——海上无“倒船”，翻转后破坏物理常识；
  erasing: 0.0（随机擦除）——易擦除船体关键特征如船名、国旗。

我曾因开启flipud导致模型在测试时将停泊的渡轮误检为“倾覆船舶”，被海事部门质疑算法可靠性。记住：工业级检测不是追求学术指标，而是让模型理解现实世界的物理约束。

3. 模型训练不是调参游戏，而是工程妥协的艺术

3.1 YOLOv5版本选择：为什么锁定v6.1而非最新v8.x

当前网络热词频繁提及“yolov5下载”“yolov5安装步骤”，但很多新手直接pip install yolov5装最新版，结果在RK3568部署时崩溃。根本原因在于：YOLOv5 v7.0+全面转向TorchScript导出，而瑞芯微官方NPU SDK（RKNN-Toolkit2）仅支持PyTorch 1.10.0 + ONNX 1.10.0，v8.x的导出接口已变更。经实测，YOLOv5 v6.1是最后兼容RK3568/RV1106的稳定版本，且其COCO预训练权重在舰船数据上迁移效果最佳。

安装命令必须精确：

git clone https://github.com/ultralytics/yolov5.git cd yolov5 && git checkout v6.1 pip install -r requirements.txt # 关键：降级torch以适配RKNN pip install torch==1.10.0+cpu torchvision==0.11.0+cpu -f https://download.pytorch.org/whl/torch_stable.html

注意：若用CUDA训练，务必确认nvidia-smi显示驱动版本≥470，否则v6.1的AMP混合精度训练会报错“CUDA error: no kernel image is available”。

3.2 超参数设计：每个数字背后的物理意义

YOLOv5的hyp.scratch-low.yaml里23个超参数，多数人盲目复制，但舰船检测需针对性调整：

• lr0: 0.01（初始学习率）：比默认0.001高10倍，因舰船纹理特征明显，模型初期需快速收敛；
• lrf: 0.1（终学习率比例）：设为0.1而非0.01，避免后期过拟合——港口图像背景重复度高（大片水面），过低学习率会让模型死记背景噪声；
• warmup_epochs: 3（热身轮数）：必须设为3，因小目标检测需要梯度平稳过渡，实测warmup_epochs=1时loss前10轮震荡剧烈；
• box: 0.05（定位损失权重）：提高至0.05（默认0.05），因船体边界定位精度直接影响后续AIS匹配；
• cls: 0.5（分类损失权重）：降至0.3，因海事监管首要任务是“有没有船”，其次才是“什么船”。

最关键的batch_size选择：

• 在V100上：设为32（显存占用14.2GB），此时workers=8达到IO瓶颈，需将pin_memory=True；
• 在RK3568上：必须设为1（NPU内存限制），此时需用--cache参数将数据预加载到RAM，否则训练速度暴跌70%。

3.3 训练过程监控：不止看mAP，更要盯住这五个指标

YOLOv5的results.csv里有12列数据，但舰船检测只需重点关注五项：

我遇到过一次诡异现象：mAP@0.5达0.86但BR仅0.71，排查发现是验证集里有37张图的船体被栈桥遮挡50%以上，而标注框只框了可见部分。解决方案不是删图，而是用albumentations添加RandomShadow增强，模拟遮挡场景，使BR升至0.89。

4. PyQt界面不是“做个GUI”，而是工业级人机交互系统

4.1 架构设计：为什么放弃QMainWindow而选QDialog

网络热词“python pyqt界面封装成exe”常引导新手用QMainWindow做主窗口，但在舰船检测场景中这是灾难性选择。QMainWindow的centralWidget机制导致视频流渲染时CPU占用率飙升至95%，且无法优雅处理多路摄像头切换。我们采用QDialog+QGraphicsView架构，核心优势有三：

• 零拷贝视频渲染：QGraphicsView的setPixmap()直接接收OpenCV的cv2.cvtColor()结果，避免Qt QImage转换开销；
• 多线程安全：QDialog可独立创建QThread处理检测逻辑，主线程专注UI响应；
• EXE封装友好：PyInstaller打包时QDialog依赖库比QMainWindow少37%，生成EXE体积缩小2.1MB。

主窗口类定义精简到23行：

class ShipDetectionDialog(QDialog): def __init__(self): super().__init__() self.setWindowTitle("智能舰船监测系统 v2.3") self.resize(1280, 720) self.video_label = QLabel() # 承载视频流 self.result_table = QTableWidget() # 实时检测列表 layout = QVBoxLayout() layout.addWidget(self.video_label) layout.addWidget(self.result_table) self.setLayout(layout) self.init_detector() # 加载YOLOv5模型 self.start_video_thread() # 启动视频采集线程

4.2 视频流优化：解决PyQt卡顿的五大硬招

PyQt视频卡顿是高频痛点，根源在于OpenCV与Qt事件循环冲突。我的解决方案：

1. 帧率硬限：在VideoCapture线程中加入time.sleep(0.033)强制30FPS，避免GPU满载；
2. 双缓冲机制：用QPixmapCache缓存最近5帧，当检测耗时>33ms时自动回退到缓存帧；
3. ROI裁剪：对1080p视频流，只截取下方60%区域（船体集中区），分辨率降至1920x648，CPU占用率从82%降至41%；
4. 异步绘制：重写paintEvent()，用QPainter.drawPixmap()替代setPixmap()，减少Qt内部重绘；
5. 硬件加速：在QApplication初始化时添加QApplication.setAttribute(Qt.AA_UseOpenGLES)，启用OpenGL后端。

实测对比：未优化时1080p视频CPU占用79%，优化后稳定在32%，且检测延迟从210ms降至85ms。

4.3 功能模块实现：超越基础检测的业务逻辑

PyQt界面必须承载真实业务需求，以下是三个关键模块的实现要点：

报警联动模块：
当检测到“特种作业船”且连续5帧出现时，触发声光报警。代码核心：

self.alarm_timer = QTimer() self.alarm_timer.timeout.connect(self.trigger_alarm) self.alarm_count = 0 def on_detect(self, results): if "tugboat" in results and len(results["tugboat"]) >= 1: self.alarm_count += 1 if self.alarm_count >= 5: self.alarm_timer.start(500) # 每500ms响一次 else: self.alarm_count = 0

AIS数据对接模块：
通过TCP socket连接本地AIS接收器（IP:127.0.0.1:10110），解析NMEA-0183协议：

def parse_ais(self, nmea_line): if nmea_line.startswith('$GPGLL'): # 提取经纬度，与检测框中心坐标比对 lat, lon = self.extract_position(nmea_line) for box in self.current_boxes: if self.haversine_distance(box.center, (lat, lon)) < 0.001: box.ship_name = self.get_ship_name_by_mmsi(mmsi) # 查MMSI数据库

报表导出模块：
导出CSV时必须包含时间戳、船体尺寸（像素）、置信度、方位角（通过船首朝向计算）：

def export_report(self): with open(f"report_{int(time.time())}.csv", "w") as f: f.write("timestamp,ship_type,width_px,height_px,confidence,heading\n") for det in self.detections: f.write(f"{det.timestamp},{det.type},{det.w},{det.h},{det.conf:.3f},{det.heading}\n")

5. 部署与封装：从开发机到码头边缘设备的全链路

5.1 EXE封装避坑指南：PyInstaller的六个致命陷阱

“python pyqt界面封装成exe”看似简单，实则充满雷区：

• 陷阱1：图标丢失
  pyinstaller --icon=app.ico main.py无效，必须用--add-data "app.ico;."并修改spec文件中console=False；

• 陷阱2：OpenCV DLL缺失
  在.spec文件中添加：

  a = Analysis(...) # 在binaries列表中手动加入 binaries=[('C:\\path\\to\\opencv_world455.dll', 'opencv')]

• 陷阱3：YOLOv5模型路径错误
  torch.hub.load()默认从网络下载，EXE运行时需改为本地加载：

  model = torch.load('./weights/best.pt', map_location='cpu')

• 陷阱4：PyQt插件路径失效
  添加--add-binary "C:/Python38/Lib/site-packages/PyQt5/Qt/plugins/platforms;PyQt5/Qt/plugins/platforms"；

• 陷阱5：中文路径乱码
  在main.py开头强制设置：

  import sys import locale locale.setlocale(locale.LC_ALL, 'Chinese_China.936')

• 陷阱6：RK3568兼容性
  必须用pyinstaller --onefile --platform linux-armv7l交叉编译，且需提前在RK3568上安装libglib2.0-0和libsm6。

5.2 RK3568部署：从PyTorch到RKNN的三步转化

“rv1106搭建yolov5模型”与“yolov5在rk3568上”本质相同，均需完成模型转换：

Step1：ONNX导出

python export.py --weights weights/best.pt --include onnx --opset 11 # 关键参数：--opset 11（RKNN仅支持≤11），--dynamic（启用动态batch）

Step2：RKNN转换

from rknn.api import RKNN rknn = RKNN() rknn.config(channel_mean_value='128 128 128 128', reorder_channel='0 1 2') rknn.load_onnx(model='best.onnx', inputs=['images'], input_size_list=[[1,3,640,640]]) rknn.build(do_quantization=False) # 先不量化，调试用 rknn.export_rknn('./best.rknn')

Step3：C++推理加速
在RK3568上用C++调用RKNN API，比Python快3.2倍：

// 初始化RKNN rknn_context ctx; rknn_init(&ctx, "best.rknn", 0); // 输入预处理（BGR2RGB + 归一化） cv::Mat input = cv::Mat::zeros(640, 640, CV_8UC3); cv::resize(frame, input, input.size()); input.convertScaleAbs(input, input, 1.0/255.0); // 推理 rknn_inputs inputs[1]; inputs[0].index = 0; inputs[0].buf = input.data; inputs[0].size = 640*640*3; rknn_outputs outputs[1]; rknn_run(ctx, inputs, 1, outputs, 1);

5.3 现场部署 checklist：码头环境下的生存法则

最后交付给客户前，必须完成这份清单：

• [ ]防水防盐雾：所有接线端子涂三防漆，机箱IP65等级；
• [ ]断电保护：UPS续航≥4小时，断电时自动保存最后10分钟视频；
• [ ]网络自愈：检测到RTSP流中断，自动重连3次，失败后切换备用摄像头；
• [ ]温度适应：在-10℃~55℃环境实测，模型推理延迟波动<5%；
• [ ]权限管控：管理员密码采用AES-256加密存储，操作日志留存180天；
• [ ]一键恢复：U盘插入自动还原系统镜像（基于Buildroot定制）。

我在舟山港部署时，曾因忽略“温度适应”测试，导致盛夏正午设备过热降频，检测帧率从25FPS跌至8FPS。后来在散热片加装温控风扇，设定55℃启动，问题彻底解决。

6. 常见问题与排查技巧实录：那些没写在文档里的真相

6.1 训练问题速查表

6.2 PyQt界面问题急救包

• 问题：视频窗口显示黑屏，但控制台无报错
  原因：OpenCV VideoCapture默认使用MSMF后端，在某些USB摄像头下失效。
  解决：强制指定后端cap = cv2.VideoCapture(0, cv2.CAP_DSHOW)（Windows）或cv2.CAP_V4L2（Linux）。

• 问题：点击按钮无响应，CPU占用100%
  原因：在主线程执行model.predict()阻塞了Qt事件循环。
  解决：必须用QThread封装检测逻辑，通过moveToThread()迁移。

• 问题：导出EXE后中文乱码
  原因：PyInstaller未正确打包字体文件。
  解决：在.spec中添加datas=[('C:/Windows/Fonts/msyh.ttc','fonts')]，并在代码中QFontDatabase.addApplicationFont()。

6.3 边缘部署血泪经验

• RV1106 NPU利用率始终<30%：不是模型太小，而是输入分辨率未对齐NPU硬件要求——RV1106要求输入宽高必须为16的倍数，640×640合规，但608×608会导致NPU闲置。
• RK3568上检测延迟>500ms：检查是否启用了--quantized量化，未量化模型在NPU上反而更快，因量化引入额外校准开销。
• 多路视频同时推理崩溃：RK3568的NPU不支持多实例并发，必须用threading.Lock()串行化推理请求。

最后再分享一个小技巧：在码头现场调试时，随身带一台安卓手机装Termux，用adb connect直连RK3568，比用VNC流畅十倍。我至今保留着那个贴着盐霜的Termux终端截图——上面还留着一行没删干净的调试命令：rknn.eval_perf(ctx, inputs)。这行命令帮我揪出了NPU内存带宽瓶颈，也让我明白：所有炫酷的AI模型，最终都要跪在码头咸湿的海风里接受检验。

本文还有配套的精品资源，点击获取