YOLOv8番茄成熟度检测实战：从数据标注到边缘部署

简介一份面向图像识别与智能农业场景的YOLO番茄成熟度检测项目包基于YOLOv8实现目标定位与成熟度分级可区分未成熟、半成熟、成熟等状态。资源仅6个文件约5.41MB内部包含2个Jupyter Notebook示例一个演示流程、一个小组v8训练脚本、训练好的PyTorch权重best.pt、可独立运行的app.py部署脚本、requirements.txt依赖清单以及README.md项目说明。已有44人学习浏览。读者拿到压缩包后可直接加载best.pt进行推理也可参照Notebook逐步了解数据准备、模型训练与验证流程app.py则便于将模型封装成应用或服务适合初学者快速上手也适合农业检测项目做二次开发。整体小而精文件结构清晰兼顾演示、训练、部署与文档说明适合农业AI方向研究参考。1. 番茄成熟度YOLO检测从一筐青果到分级发货的视觉方案农业视觉里番茄成熟度检测是最容易“看着简单、做起来翻车”的项目你打开一个名为“番茄成熟度YOLO检测.zip”的工程包里面既要有能直接跑的模型权重也要有从数据标注到训练部署的完整链条。真正多光谱相机和温室大棚里最缺的恰恰是把一串红绿相间的番茄按成熟度逐颗分好级的自动化手段——人工分拣一小时两三百斤顶天了还容易因为疲劳看走眼。这个方向能解决的核心问题就一个用目标检测模型同时完成番茄的定位和成熟度分类让机器人或分拣线知道“哪颗是绿的、哪颗转色了、哪颗该摘了”。适合谁做农业院校的研究生、做采摘机器人的初创团队、搞智慧农业方案的系统集成商以及想拿一个小而完整的YOLO项目练手的算法工程师。下文按数据、选型、训练、部署、排错的路径把它拆透。2. 番茄成熟度检测的数据基础分级标准、采集规范和标注规则2.1 成熟度分级先定标签再谈模型别把连续过程当离散状态番茄从坐果到完熟是连续变化但目标检测的输出必须是离散类别。从业界通行做法来看四分类就够了绿熟期果实全绿但已停止膨大、转色期果面出现10%~30%变色、半熟期变色面积30%~90%果面红绿相间、完熟期果面基本全红或全黄。分太细模型学不住分太粗现场没法用——三分类绿/转色/红会让半熟果在标注时犹豫现实操作里我见过不少项目最后都倒回四分类。这个分级标准直接决定标注效率。实际采摘场景里同一串果往往同时存在三个成熟度这是番茄区别于黄瓜、辣椒的地方——它给检测模型带来了天然的密集小目标问题。标注时别只画框要把被叶子遮挡超过1/3的果实单独标记为“遮挡样本”这类样本对后期调NMS阈值和置信度阈值至关重要。2.2 采集规范光照、角度和背景决定了你的模型能不能下地采集阶段的问题几乎都出在光照上。温室大棚里正午强光下绿熟果发白、完熟果反光阴天和傍晚完熟果在阴影里拍出来偏暗偏褐和半熟果肉眼难分。这是番茄成熟度检测数据采集的第一条准则在多种光照条件下采集同一批果实。我一般会建议这样布置采集采集场景矩阵每个成熟度至少覆盖以下条件 - 光照晴天上午/正午/傍晚、阴天、补光LED、遮阴处 - 角度俯视45°、水平、仰视、随机倾角 - 距离近距单果占画面1/3、中距5~10颗/帧、远距整串 - 背景绿叶、土壤、塑料薄膜、编织袋、传送带这个矩阵不是教条——你的推理场景是分拣线还是田间机器人背景就按你实际部署环境来收。手里有手机就先用手机1080p起步别用720p后续做数据增强压缩后质量会崩。固定在支架上拍别手持视频抽帧运动模糊会让标注框边缘毛糙模型第一个epoch就学歪。2.3 标注工具与数据划分从零到可训练集的操作步骤标注工具选LabelImg和X-AnyLabeling都可以但建议直接用LabelImg的YOLO模式省一次格式转换。标注界限是绿熟期框整个果实轮廓转色期和半熟期按“主导颜色面积”定类别超过50%面积变红才算半熟否则算转色期。这个规则要在标注前写成文档分发给所有标注员否则一个人一个标准训练出来的模型在转色/半熟边界上会反复横跳。标注完成后做数据划分。这里有两条常见路径一是随机划分适用于成熟度分布均衡的数据集二是按大棚/时段划分适用于从多个产地采集的数据——按棚划分能测出模型的跨场景泛化能力。划分脚本import os import random import shutil # 输入images/ 和 labels/ 同级目录YOLO格式标注 img_files [f for f in os.listdir(images) if f.endswith(.jpg)] random.seed(42) random.shuffle(img_files) train_ratio, val_ratio 0.8, 0.15 split_train int(len(img_files) * train_ratio) split_val int(len(img_files) * (train_ratio val_ratio)) os.makedirs(train/images, exist_okTrue) os.makedirs(train/labels, exist_okTrue) os.makedirs(val/images, exist_okTrue) os.makedirs(val/labels, exist_okTrue) os.makedirs(test/images, exist_okTrue) os.makedirs(test/labels, exist_okTrue) for f in img_files[:split_train]: shutil.move(fimages/{f}, ftrain/images/{f}) shutil.move(flabels/{f[:-4]}.txt, ftrain/labels/{f[:-4]}.txt) # val/test 同理...random.seed(42)保证划分结果可复现这是后面复现训练结果的地基。val 集至少 15%test 集留 5%~10% 做最终验证千万别把测试集在训练期间反复拿来调参那等于作弊。3. 模型选型与硬件匹配YOLO 版本怎么选、预训练权重怎么用3.1 从 YOLOv8 到 YOLO11为什么主流方案都围绕 v8 生态展开YOLO 家族的迭代速度让新入场者容易懵。当前做番茄成熟度检测的主流选择是 YOLOv8其次是 YOLO11新版本延续了 v8 的架构习惯。v8 的优势不在单模型精度碾压而在生态完整Ultralytics 仓库把训练、验证、导出、部署一次性串起来了对农业项目这种小团队、短周期的场景非常友好。YOLOv8n/s/m/l/x 五个规格怎么选番茄果实属于中小目标但不像无人机航拍那样小到几个像素所以模型容量不用顶配。我实测过的经验是n 适合树莓派、RK3588 这类边缘设备精度在 mAP50 上比 s 低 3~5 个点s 是温室固定摄像头方案的甜点档位m 以上适合有独立 GPU 的分拣线精度收益边际递减推理延迟翻倍。预训练权重这东西建议直接用 Ultralytics 提供的 COCO 预训练权重作为起点。COCO 里没有番茄成熟度这个类别但特征提取层学到的是通用纹理和形状能力迁移过来后收敛速度比从头训练快一个数量级。3.2 关键参数设置imgsz、epochs、batch 确定策略训练参数直接决定这个项目是三天跑完还是三周跑不完。番茄目标在原图中占比约 5%~15%训练分辨率建议从 640 起步。分辨率上调到 1280 能小涨 1~2 个点 mAP但显存占用翻倍、推理速度减半得不偿失。Epochs 方面从 COCO 预训练权重微调时100~150 个 epoch 足够收敛。判断标准不是固定回合而是看 val 集 loss 是否连续 20 个 epoch 不再下降——早停比硬跑满更有效。Batch size 的设置显存够的话尽量开 16 或 32小 batch 会让 BN 层统计不稳定这是后面要讲的“BN 崩溃”问题的根源之一。学习率用默认的 0.01 配合 SGD 就行AdamW 可以调到 0.001。3.3 损失函数和混淆矩阵训练日志里到底要看什么YOLOv8 的损失由三部分组成边界框回归损失CIoU 加 DFL、分类损失BCE、以及可选的置信度损失。训练日志里 loss 曲线整体下降box_loss 和 cls_loss 同步下降才算健康。如果看到 cls_loss 降到 0.01 以下但 mAP 还在涨说明模型在“过拟合到标注噪声上”这时候回查标注质量比继续堆 epoch 有效。混淆矩阵要重点看“转色期 - 半熟期”这一对相邻类别。这是番茄成熟度检测里最容易混淆的边界因为标注本身主观性就强。矩阵对角线占比低于 80% 的两个相邻类别说明标注规则需要重审而不是模型不行。顺带说一句YOLO 日志里混淆矩阵每行总和不为 1 是正常的——紫红色块代表未分类样本真正要关注的是每一行里非对角线元素的分布。注意类别不平衡在番茄数据里几乎必然存在。完熟期果实最容易采到绿熟期次之转色期样本最少。训练时开启class_weights或在采样时对转色期做过采样比改损失函数省事。4. 跑通番茄成熟度 YOLO 训练全流程从配置文件到权重导出4.1 数据集目录结构和 YAML 配置从网上下载到的“番茄成熟度YOLO检测”类工程包目录结构通常长这样。没有也没关系自己按 YOLO 规范组织即可dataset/ ├── train/ │ ├── images/ │ └── labels/ ├── val/ │ ├── images/ │ └── labels/ ├── test/ │ ├── images/ │ └── labels/ └── data.yamldata.yaml 是关键配置定义类别名称和路径。实际填写时注意路径用绝对路径最省心但换机器就要改用相对路径要保证执行训练命令时的工作目录在 dataset 的上一级。我的习惯是直接写绝对路径配一个环境变量的映射来兼容不同机器。# data.yaml path: /path/to/dataset train: train/images val: val/images test: test/images names: 0: green # 绿熟期 1: breaker # 转色期 2: half_ripe # 半熟期 3: ripe # 完熟期类别顺序一旦确定后续训练、部署、推理的 class index 必须保持一致。我在项目里吃过大亏训练完觉得顺序不好看改了 names 顺序忘了同步改标注文件的 class id整个模型相当于重新学了一遍。4.2 执行训练命令与参数逐一说明确认环境无误后开始训练。核心命令yolo detect train \ --model yolov8s.pt \ --data dataset/data.yaml \ --epochs 120 \ --imgsz 640 \ --batch 16 \ --device 0 \ --workers 8 \ --optimizer SGD \ --lr0 0.01 \ --cosine \ --project runs/tomato \ --name ripe_v1参数说明--model yolov8s.pt会优先加载同目录下的预训练权重没有则自动下载--cosine让学习率按余弦曲线衰减相比固定步长衰减能多挤 1 个点左右--workers 8是数据加载线程数高配 GPU 上开到 16 也行但 Windows 下开太高容易报 DataLoader 错误。训练过程中观察终端输出的 P/R/mAP 指标每 10 个 epoch 去runs/tomato/ripe_v1/目录看一眼验证集的可视化预测图比盯着 loss 数字有用得多。训练中途停下来的后悔药是先跑 20 个 epoch 判断收敛方向方向对了重新跑全量而不是在错误配置上硬等 120 个 epoch 跑完。4.3 验证与导出best.pt 怎么用、ONNX 导出要过几道关训练完成后目录里会有best.pt和last.pt。best.pt是 val 集 mAP 最高的权重用于后续所有推理和部署。导出的工作流是# 1. 在测试集上做最终评估 yolo detect val \ --model runs/tomato/ripe_v1/weights/best.pt \ --data dataset/data.yaml \ --split test # 2. 导出 ONNX 格式部署到 CPU/GPU 服务 yolo export \ --model runs/tomato/ripe_v1/weights/best.pt \ --format onnx \ --opset 12 \ --imgsz 640 # 3. 导出 RKNN 格式部署到瑞芯微 NPURK3588 等 yolo export \ --model runs/tomato/ripe_v1/weights/best.pt \ --format rknn \ --imgsz 640ONNX 导出后必须做一次推理比对用同一张图分别跑 PyTorch 权重和 ONNX 权重输出框和类别要完全一致。数值误差大于 1e-3 时检查是否开了 AMP 混合精度训练导出时半精度权重转单精度浮点偶尔会引入偏差。5. 番茄成熟度检测的避坑指南常见问题与现场排查5.1 BN 崩溃loss 突然变 NaN训练直接报废现象训练到第 30 个 epochloss 变成 NaN后续所有验证指标归零已训练的权重半废。原因BN 层统计量崩了。常见诱因有三个batch size 太小4 或 8导致 BN 统计不稳定学习率设置过高导致梯度爆炸数据集里混入了损坏的图片或空标注文件。解决先检查标注文件labels目录下是否存在 0 字节的 txt然后降低lr0到 0.001 或换 AdamW最后把 batch 提到 16 以上。如果前 5 个 epoch 就出现 NaN优先怀疑数据问题别在超参数上浪费时间。5.2 强光和阴影下误检率飙升训练集指标好看到了现场就翻车现象测试集 mAP50 有 0.92实地部署后强光下绿熟果漏检 20%阴影里完熟果被误判成半熟。原因数据采集时没覆盖极端光照条件。温室里的光照变化远比户外剧烈正午强光会让果实表面高光溢出模型学到的纹理特征直接失效。解决回采集阶段补数据重点补三类——逆光果实、阳光直射叶片缝隙下的果实、遮阴处果实。如果补采来不及先用数据增强硬撑HSV 变换加大饱和度扰动、亮度扰动范围从 ±20% 扩到 ±40%、加入随机高斯噪声模拟传感器差异。5.3 密集果实互相遮挡导致漏检NMS 阈值和标注规范的双重问题现象一串番茄三四个果实挤在一起模型只检出 1~2 个剩下的框被 NMS 抑制掉了。原因YOLO 默认 NMS 阈值 0.45密集重叠场景下相邻果实的高 IoU 预测框被当成了重复检测。此外标注阶段如果放任遮挡严重的果实不标注模型根本没有机会学习“被挡住的番茄长什么样”。解决推理时将--nms-iou-threshold从 0.45 降到 0.3允许更多高重叠预测框共存训练阶段保留部分遮挡样本并正常标注。如果遮挡太严重超过 1/2 面积宁可跳过不标省得给模型传递错误信息。5.4 转色期和半熟期的分类边界漂移标注规则的个体差异现象同一颗番茄标注员 A 标为半熟标注员 B 标为转色期模型在这两类上的分类头反复震荡训练曲线收敛后 mAP50 也在 0.85 上下波动。原因标注规则里的“30%~90% 变色面积”没有量化到可执行的程度人工判断受主观经验影响。解决出标注规范时给每个阶段配标准色卡和样例图标注完成后做二次抽检计算标注一致性训练时把转色期和半熟期的分类权重抬高让模型更愿意区分这对难分样本。5.5 边缘设备部署后精度骤降INT8 量化掉点怎么兜回来现象PC 上 mAP50 是 0.91导出 RKNN INT8 量化模型后掉到 0.82成熟度分类尤其受影响。原因量化对纹理和颜色细节敏感番茄成熟度恰恰依赖颜色和表面纹理量化误差直接打中模型痛点。解决第一选择不用 INT8保留 FP16 推理RK3588 的 NPU 对 FP16 支持很好如果必须 INT8做量化感知训练QAT给训练过程加量化噪声让模型适应量化校准集要覆盖全部成熟度类别和不同光照条件数量不小于 500 张。6. 成熟度检测的进阶玩法用帧间平滑把单帧检测变成稳定分级单帧检测在实时视频流里会有抖动同一颗番茄在连续 10 帧里可能被识别为“半熟→转色→半熟”分拣线看到这种输出会直接疯掉。常见的解法是给检测结果加一个滑动窗口投票机制。from collections import deque class MaturityVoter: def __init__(self, window_size10, min_votes7): self.window deque(maxlenwindow_size) self.min_votes min_votes def vote(self, class_id): self.window.append(class_id) if len(self.window) self.window.maxlen: return None # 缓存未满暂不输出 from collections import Counter counts Counter(self.window) top_class, top_count counts.most_common(1)[0] if top_count self.min_votes: return top_class return None # 窗口内不稳定丢弃这帧结果这段代码解决的是成熟度分类的抖动问题。窗口大小 10 帧要求 7 帧投票一致才输出现场识别稳定性立刻上一个台阶。代价是延迟增加约 300ms30fps 下对采摘机器人来说可以接受对高速分拣线需要缩到 5 帧窗口。我自己的习惯是框架写完后先背着电脑去菜市场买十斤不同成熟度的番茄摆一排用手机当着太阳、背光、夜间补光的各种角度反复扫一遍感受模型哪些场景会露怯。数据永远比模型更能回答“你这套方案到底能不能用”。这套流程跑通之后换作物只是换数据的事——黄瓜、辣椒、草莓都是同一个套路只改类别名、重采集、微调。希望帮到你。本文还有配套的精品资源点击获取