无人机视角船只检测实战：YOLO11海上搜救模型部署与调优

简介：面向无人机航拍视角下的水上目标识别与海上搜救任务，资源包提供了一套基于YOLO11的完整船只检测方案与配套资料。压缩包共2000个文件，约676.5MB，以1059个txt标注文件、377个md说明文档、284张jpg评价曲线图与演示图、169个py训练推理脚本为主体，同时包含88个yaml配置、sh辅助脚本及cpp部署示例，目录划分清晰，便于按模块取用与二次开发。数据集已标注为YOLO格式txt与VOC格式xml，预先划分train/val/test子集，附有data.yaml，可直接用于YOLOv5、YOLOv8至V12等算法训练，类别为boat（船只），贴合海上搜救场景。还提供使用教程、模型评价指标曲线图及训练好的模型权重，可直观对比精度与召回率，快速加载模型进行船只检测，辅助调优和部署。当前已有89人学习下载，适合希望快速开展无人机水面目标检测实验、验证YOLO系列算法或推进海上搜救项目落地的开发者、研究人员。

1. 无人机视角船只检测，凭什么用YOLO11做海上搜救

搜救无人机飞出去，图传里一块小小的橡皮艇可能只占几十像素，操作员盯图传屏十分钟就累，漏看一次就得重飞整个区域。标题这个压缩包就是在解决这个问题：提供已标注数据集和训练好的YOLO11权重，把“无人机视角船只检测”这件事变成一个可以马上跑起来的工作流。

它适合要给无人机加水面检测模块的开发者、做海上搜救系统的算法工程师，也适合研究航拍小目标的学生。我的结论很直接：选哪个模型版本不玄学，真正决定好用与否的是入口分辨率、阈值策略和后处理；下面按推理、训练、避坑的顺序把这条链路一次讲透。

2. 从YOLOv8到YOLO11：海上搜救场景为什么选这个模型

2.1 无人机俯拍的成像规律：小目标、弱纹理、动态背景

无人机看船和地面摄像头看车是两种任务。地面平视时车辆占画面比例大、纹理清晰、背景相对静止；无人机俯视海面时，一条几米长的橡皮艇在1080P画面里可能只占30到60像素高，再经过模型输入尺寸的缩放，留给特征层的有效信息只剩几个像素。这是无人机水面检测的第一条约束：输入图像不能无脑降采样，否则小目标在特征图上直接消失。

第二条约束是背景欺骗性极强。海面波光、浪花、船尾航迹都是“浅色小区域”，云影和太阳反光造成明暗突变，船体轮廓在这些干扰中经常断断续续。船本身没有车窗、文字这类强纹理，模型真正能依赖的是轮廓比例、边缘锐度和运动连续性。所以依赖单帧纹理特征的检测器，在海上天生吃亏。

还有一条常被忽略：搜救视频里大部分帧没有目标。目标出现是稀疏事件，而海面包含大量疑似区域。如果只在单帧里找“像船的东西”，误报会淹没真报警；所以搜救场景几乎必须结合多帧信息，这也是后文后处理反复出现的原因。

2.2 YOLO11与YOLOv8的差异，以及为什么不是两阶段模型

YOLO11是ultralytics框架里的新一代检测模型，结构上延续了anchor-free输出头——直接回归目标中心点和宽高，不需要预设锚框，对不同长宽比的船只更友好；主干和特征融合层相对YOLOv8做了调整，模型参数与计算量在相近精度下更可控。这对机载算力是实打实的收益，因为无人机平台需要考虑供电、散热和算力上限，模型每小一点，留给其他任务的空间就多一分。

为什么不选两阶段检测器？两阶段网络先提候选框再逐框分类，小目标精度理论上更好，但一次前向需要两遍扫描，时延翻倍；搜救无人机要持续处理1080P以上画面，算力又受限，很难跑起来。为什么不选传统帧差法和形态学？海面一直在动，浪花涌动生成大量假前景，帧差法在风浪条件下基本不可用，只能当辅助。

选型对比可以看这张表：

结论是：实时搜救视频流这条主线路，YOLO11是综合成本最低的起点。离线需要逐帧精细复查时，再用两阶段模型也不迟。

另外，之所以强调用训练好的模型而不是从零训练，是因为无人机视角数据获取成本高，手工标注小目标又累。预训练权重已经包含自然图像的通用特征，比如边缘、纹理、形状，在此基础上做迁移学习，几百张船图就能看到可用效果；从随机权重起步，同样数据量就很难收敛。

2.3 搜救任务的评价标准：先保recall，再控precision

模型包如果只给一个mAP，用于搜救是不够的。搜救场景漏检一个真实目标，代价是航线重飞、时间浪费，而误报一次只是多看一眼。所以优先级是：先保证召回率，在召回达标的前提下压误报。

我习惯的做法是先跑一遍val，把置信度阈值放低到0.001，让模型尽量把所有候选都吐出来，观察PR曲线形态。这一步不是部署配置，而是探明模型能力的真实下限。验证代码很常规：

from ultralytics import YOLO model = YOLO("best.pt") # 换成zip里训练好的权重文件 model.val( data="data.yaml", # 数据配置，路径要与当前环境一致 conf=0.001, # 阈值放低，只为画出完整PR曲线 iou=0.45, # NMS合并阈值，重叠超过0.45的框合并 plots=False, # 关闭绘图，只取指标数值 )

conf=0.001的意义是让模型在最低门槛下输出所有预测，recall上界才能被估出来；实际部署时不会用这么低的值，否则每帧都是一堆误报。实际部署我把conf放在0.25到0.35之间，具体数值取决于后处理能压掉多少误报。iou=0.45是NMS的合并阈值，同一个目标被多个框框住时，重叠高于这个值就合并成一个框。

val出来之后，我主要看三个数：recall@0.5、precision@0.5、以及误报集中区域的位置分布。如果误报都集中在画面边缘或某个特定光照方向，说明模型学到的是光照特征而不是船的特征，这时要回去补数据而不是调阈值。这一步是判断“这个训练好的模型适不适合我的视频数据”的关键。

3. 把模型包跑起来：YOLO11推理的最小命令与输出解读

3.1 解压后先找三样东西：权重、数据配置、标注目录

拿到zip，我一般先解压并快速看目录结构：

unzip ultralytics-yolo11无人机视角船只检测-*.zip -d sea_detect cd sea_detect find . -maxdepth 2 -type f | head -30

如果解压后结构不符合预期，也不用慌，先确认三样东西在不在：模型权重文件（比如best.pt或yolo11n.pt）、data.yaml、以及一份标注样本（随便打开一个images和labels目录看看）。权重用于推理和继续训练，data.yaml告诉ultralytics类别名字和数据路径，标注样本用于判断这个模型训练时的数据分布。核心是先找到best.pt，其他东西都能靠命令行参数补上。

3.2 推理的最小代码：加载权重、读取视频、输出标注

下面这段是完整可跑的推理脚本，适合作为项目模板的第一版：

from ultralytics import YOLO model = YOLO("weights/best.pt") # 加载打包里的权重 results = model.predict( source="sea_video_001.mp4", # 无人机拍的视频或图片目录 conf=0.25, # 部署起始阈值，误报多就调到0.3 iou=0.45, # NMS合并阈值 imgsz=1280, # 输入边长，小目标场景用1280 device=0, # GPU编号，CPU环境改字符串"cpu" save=True, # 保存带标注框的视频/图片 save_txt=True, # 额外保存YOLO格式的预测文件 )

这段代码的逻辑是：读入一段视频，按帧缩放成固定输入尺寸，这里指定1280，前向推理得到框和置信度，经过NMS合并重叠框，最终把标注画到原分辨率画面并落盘。save_txt会在输出目录里按帧生成同名txt文件，每行是“类别 cx cy w h conf”，给后续数据统计和后处理用；部署到机载端时可以不开，省一点I/O。

参数值得说三点。

第一，imgsz=1280而不是640，是海上搜救场景最重要的一个决定。无人机俯拍的小目标在640输入下可能只剩两三个像素，模型根本看不出形状；提高到1280是让模型在“看得见”的前提下跑推理，代价是GPU推理时间大概翻倍。如果你的平台跑不动，先用640跑通，再逐步加到960和1280，对比recall变化。

第二，conf从0.25起步，是因为训练好的模型在它的原始数据分布上通常有不错的精度。但换海域、换天气后，置信度分布会改变，不要迷信某个固定值，跑一段视频后看输出再调。

第三，device=0要显式写。我排过不少“推理只有3帧”的问题，最后发现是环境变量没设好，模型回退到了CPU。明确指定设备能少踩一个坑。

3.3 换一个海域前，先做数据健康检查

直接拿训练好的权重对新视频跑推理，很容易得到“看起来能用”的错觉。我习惯在正式接任务前做一个快速健康检查：取500到1000帧包含不同光照和海况的视频，跑一遍推理，再看三件事。

第一，目标框是否连续。同样一条船在连续帧里，框应该稳定出现在相近位置，横跳幅度超过框宽的三分之一就要警惕。第二，误报是否集中在某一区域。海上搜救的误报经常出现在浪花带、反光带，如果在坐标分布里看一下，一眼能看出来。第三，小目标漏检比例。统计输出框的宽高分布，再看原始视频里有没有大量人工可见但模型没框出的目标。下面是统计推理结果的小脚本：

from pathlib import Path import numpy as np txt_dir = Path("runs/detect/predict/labels") all_boxes = [] for txt in txt_dir.glob("*.txt"): for line in txt.read_text().strip().splitlines(): cls, cx, cy, w, h, conf = map(float, line.split()) all_boxes.append([cls, cx, cy, w, h, conf]) arr = np.array(all_boxes) print("总检测框数:", len(arr)) print("框宽分布(像素占比):", np.percentile(arr[:, 3], [10, 50, 90]))

这段代码读predict输出的txt，把所有框的类别、中心点、宽高、置信度汇总成数组，输出框宽的10%/50%/90%分位。通过宽百分比可以判断：如果大量框的宽度偏小，说明模型只对大目标敏感，小目标被系统性漏掉了；结合框中心的分布能发现误报聚集区。

健康检查这一步非常值得做，它可能决定你要不要继续用训练好的模型。如果检查结果不理想，下一步就应该进入第四章，用自带数据集重新fine-tune。

4. 训练自己的海上搜救模型：数据集、标注和必调参数

4.1 读懂YOLO标注格式：一行一个目标的归一化坐标

自带数据集的标注是YOLO txt格式。每个txt与一张图片同名，放在labels目录，每行代表一个目标：

class_id center_x center_y width height

四个坐标都是归一化的，取值0到1，用真实像素位置除以图片宽高得到。可以用下面命令随机抽几个样本检查标注质量：

find datasets/labels -name "*.txt" | head -5 | while read f; do echo "== $f" head -3 "$f" done

输出大概长这样：

== datasets/labels/sea_001.txt 0 0.523001 0.712345 0.021000 0.018000 0 0.412000 0.523000 0.090000 0.060000 1 0.870000 0.123000 0.012000 0.011000

看到这个格式，有两点要立刻检查：第一，类别编号从0开始，必须和data.yaml里的names顺序一致，否则训练时类别错位；第二，宽高很小的框在归一化坐标系里对应原图几十个像素，这种小目标有多少个、标得是否准确，直接决定模型对小目标的敏感度。很多数据集是自动标注或人工漏标过的，小目标漏标问题很常见，训练前花半小时抽检，能省几小时训练时间。

4.2 data.yaml怎么写：路径是第一个坑

ultralytics训练需要一份data.yaml，内容如下：

path: /home/user/sea_detect/datasets # 数据集根目录，建议写绝对路径 train: images/train # 训练图片相对根目录的位置 val: images/val # 验证图片位置 names: 0: ship 1: boat 2: rubber_raft 3: floating_object

path字段是第一大坑。写相对路径时，训练脚本的工作目录一变就找不到数据，报错信息又不直观，只提示“No labels found”之类。我建议在这里写绝对路径，或者干脆把数据集和训练脚本放在固定目录，避免在不同机器上反复改配置。train和val指向的是图片目录，ultralytics会自动去同级labels目录找标注，不需要在yaml里写labels路径。

如果自带数据集的类别已经定好，就不要改动names顺序。类名之后可以改，编号不能动，因为标注txt里存的编号是按原数据集顺序写的。

4.3 训练命令：用预训练权重做迁移学习

训练好的权重可以直接接着训练。常见做法是拿YOLO11的s版本权重做种子，在自带数据集上fine-tune，而不是从头训练。迁移学习的好处是：新数据量少也能收敛，训练时间短，泛化性好于随机初始化。

yolo detect train \ model=yolo11s.pt \ data=data.yaml \ epochs=100 \ imgsz=640 \ batch=16 \ patience=20 \ device=0

这里几个参数说清楚：epochs=100对几百张图片的数据集足够，配合早停；patience=20表示验证指标连续20轮不提升就停止，防止过度训练；imgsz=640是训练输入尺寸，训练用640不代表推理也用640，小目标问题主要靠推理时的高分辨率解决；batch=16在主流16GB显存上没问题，显存小就降到8，梯度不稳定时先看batch。

如果想从头开始训练来对比迁移学习的效果，把model参数从.pt改成yolo11s.yaml即可，但我的建议是别这么做。用自带数据量做随机初始化，loss下降慢，最终精度还低，属于花了时间买教训。

4.4 类别不平衡与小目标增强

海上搜救数据有一个绕不开的问题：货船、渔船样本多，橡皮艇、漂浮物样本少，而搜救恰恰要找的是后者。训练前先统计一下类别数量：

from pathlib import Path from collections import Counter counts = Counter() for txt in Path("datasets/labels/train").glob("*.txt"): for line in txt.read_text().strip().splitlines(): counts[int(line.split()[0])] += 1 print(counts)

如果发现两类样本差距在五倍以上，就要做平衡。常用做法有三种：一是对少量类整图复制，增多它的出现次数，简单有效但容易过拟合；二是用ultralytics自带的mixup增强，把少量类和其他图混合，让模型见过更多变体；三是在采样时按类别加权，让每批数据里少量类的占比稳定，而不是等它自然分布。

针对海上小目标，我还会调两个增强参数：scale=0.5让训练时目标随机缩小，模拟更小尺度下的目标；mosaic=1.0默认开启，把多张图拼成一张，提高模型对小目标在不同背景下的适应能力。如果发现训练出的模型对某类特定角度的船全是漏检，检查增强参数是否把原始尺寸拉得太狠，导致目标特征被过度破坏。

提示：如果训练到一半发现loss曲线反复震荡，先检查batch和imgsz是否匹配显存，再考虑把学习率调低一档。不要一上来就怀疑模型结构。

5. 排查海上搜救检测的五个坑：漏检、误报和部署性能

这五个坑来自我处理航拍水面数据时最常遇到的报警电话，它们大多不是模型结构问题，而是数据分布、输入分辨率和部署管线的问题。每条按现象、原因、解决三个环节拆开说，排查时可以直接对照。

5.1 小目标几乎全漏，只有大船能出框

现象：在无人机视频里，货船、集装箱船都能稳定框出，但橡皮艇、落水人员单独在水里时完全没有框，拉高imgsz后稍好一点，依然漏一半。

原因：训练数据里小目标样本不足，或者标注时把很小的目标漏标了，模型学习阶段没见过足够多的小目标正样本。另一个可能是训练imgsz过低，特征图下采样后小目标只剩一两个像素，根本学不到特征。

解决：检查数据集中宽高小于原图2%的标注数量，太少就把它们单独复制增强；训练时开mosaic和scale，让模型适应更小尺度；推理时用1280甚至更高分辨率做输入，必要时按区域切片推理，把整帧切成四块分别检测再合并结果。切片推理是处理小目标漏检的后悔药，代价是耗时成倍增加，只在关键阶段用。

5.2 浪花、反光和云影被反复报成目标

现象：推理结果里出现大量小框，集中在浪花带和太阳反光区域，目标框数量是真实目标的几十倍，操作员直接把报警功能关掉了。

原因：模型学到的不是“船”而是“浅色的、边缘凸起的小区域”，浪花和反光恰好满足这些特征。这通常因为训练集里船类目标多位于亮背景，缺少黑暗海面、阴影遮挡的负样本，模型没用上对比度差异做特征。

解决：在数据集中加入大量“无目标但背景复杂”的负样本帧，标注文件为空txt，让模型知道这些背景不输出框；同时将conf从0.25调到0.35到0.4，配合NMS。如果误报还是多，就加一个区域判据：框中心位于画面边缘固定区域时直接丢弃，很多误报集中在画面边缘的畸变区域。

5.3 训练loss正常下降，但验证集的recall上不去

现象：loss曲线平滑下降，看起来训练正常，但val的recall@0.5只有0.4左右，漏检大量目标。

原因：train和val划分有问题。例如把同一个视频片段的不同帧分到了train和val，视频相邻帧高度相似，验证集指标虚高，但表面虚高掩盖的是模型对陌生场景的真实表现差；如果val集中了更多小目标，recall低就更明显。

解决：先检查两张val图是否和训练图高度相似，如果是，按视频而不是按帧划分数据，避免数据泄漏。其次在val的PR曲线上按目标尺寸分组统计，如果大目标recall高、小目标recall低，问题回到了5.1的增强手段。最后检查标注文件里是否所有目标都被标注了，漏标目标在验证时会被当作误报，既拉低precision又干扰判断。

5.4 GPU明明存在，推理却只有几帧每秒

现象：代码跑起来了，但处理1080P视频时只有两三帧每秒，任务无法落地。

原因：常见的有三个：一是实际回退到了CPU推理，虽然装了GPU但ultralytics没有识别到，device没指定；二是imgsz开得过高，1280输入在低端GPU上本身就慢；三是视频解码和模型推理在同一线程里互相阻塞，解码耗时占比很高。

解决：在预测参数里显式写device=0并打印model.device确认；imgsz按性能测试结果选择，比较640和1280的实际帧率再定；摄像头采集或视频读取用单独的读取线程，边读边推理，避免一帧一帧阻塞。先确认模型本身的速度，再查解码：

python - <<'EOF' from ultralytics import YOLO import time m = YOLO("best.pt") t0 = time.time() for _ in range(50): m.predict("test.jpg", imgsz=640, device=0) print("50次单帧推理耗时:", time.time() - t0) EOF

这段代码用同一张图连续推理50次，测出纯模型耗时。如果这个耗时就很高，瓶颈在模型输入尺寸或设备回退；如果耗时很低但整段视频处理慢，瓶颈就在视频解码和I/O上。分开计时才能定位问题。

5.5 换了无人机和镜头，模型性能明显下降

现象：同一份权重，在一架无人机上一切正常，换到另一架无人机的广角镜头后误报翻倍、漏检增多。

原因：训练数据的图像分布和新的相机成像特性不一致。不同相机在色彩响应、动态范围、畸变、锐度上的差异，会让模型看到的是另一种风格图像，模型训练时没见过自然表现变差。这是迁移学习的典型场景。

解决：把新相机的图像加入训练集，做针对性微调，不需要全部重新标，只需标注几百张新画面加入原数据集一起训练。推理前对画面做白平衡校正，广角镜头畸变大的先用标定参数做去畸变预处理，再用统一锐度的平滑滤镜处理。这步处理之后模型的性能通常能恢复到原来的八成以上，完全恢复要看新数据量是否够。

6. 上机载算力：TensorRT加速与双模型回退的落地技巧

6.1 转TensorRT engine：先FP16，再考虑INT8

如果目标设备是机载GPU或嵌入式AI开发板，把pt转成engine加速通常是方案的最后一步。转换很简单：

from ultralytics import YOLO model = YOLO("weights/best.pt") model.export(format="engine", half=True, imgsz=640)

第一条经验：imgsz必须和后续推理输入保持一致，转换时用640，推理时也用640，不能训练用1280、导出用640、推理时又传1280，这样会触发额外resize，精度和速度都受影响。第二条经验：FP16一般精度损失很小，优先用；INT8能把模型压得更小、跑得更快，但需要校准集，海上目标又小又暗，校准集选不好精度掉得厉害。先跑FP16，等算力实在不够再考虑INT8。

6.2 双模型回退：小模型低阈值先报警，大模型再确认

这是我在海上场景里用过的最稳的一套流程。机载端算力有限，直接上大模型跑全帧可能撑不住，但小模型低阈值又会有不少误报。方案是两级串联：

model_pre = YOLO("yolo11n.engine") # 小模型，低阈值，跑每一帧 model_ref = YOLO("yolo11m.engine") # 稍大模型，高阈值，只确认疑似目标 for frame in stream: dets = model_pre.predict(frame, conf=0.20, imgsz=640) if len(dets) == 0: continue confirmed = model_ref.predict(frame, conf=0.55, imgsz=1280) if len(confirmed) > 0: alarm(confirmed) # 只有被两级同时确认才报警

逻辑说明：第一级小模型在低阈值下负责“不放过任何可能”，第二级大模型用高阈值和更大分辨率负责“确认到底是不是”。两级的组合让最终报警同时拥有小模型的覆盖率和大模型的准确率。为了防抖，我还会加一个连续确认条件：同一个位置连续三帧以上被确认才报警，避免单帧误报干扰。这套方案在模拟项目X的实时模块里验证过，整体表现远好于单模型反复调阈值。

我之前为减少漏检，把conf一路降到0.1，结果报警响个不停，操作员最后把整个通知关了——方式简单粗暴，这事儿给我上了一课。后来所有海上搜救模块都改成两级确认，先保住覆盖，再控制轰炸，阈值问题就变成了设计问题。换海域、换镜头、换季节都回到第五章那些坑里重新过一遍参数，宁可多测视频也不相信直觉。希望帮到你。

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