1. 项目背景与需求拆解草莓大棚里最让农技员头疼的不是浇水施肥而是采摘。草莓成熟期集中、果实娇嫩、茎秆又短又脆人工采摘一天下来弯腰几百次效率上不去损耗还高。这几年智慧农业喊得凶但真正落到自动采摘这一步卡点就卡在视觉识别上——机器人得知道草莓在哪儿、红没红、该从哪儿下剪子这一连串问题本质上都在问一件事图像分割识别到底能不能做到又快又准。这个项目做的就是这件事用基于深度学习的YOLO26算法对草莓采摘点做图像分割识别把果实定位、成熟度判断、采摘点坐标计算一条龙打通。YOLO26这个名字可能有人觉得陌生它本质上是YOLO系列检测加分割范式的一个项目内部版本代号延续了一阶段检测的实时性优势同时引入实例分割分支输出每个草莓的轮廓mask再结合后处理算出精准的剪切位置和夹取位置。整套方案不只服务采摘机器人也可以反过来做草莓生长状态监测比如统计不同成熟度的果实数量、预测采摘窗口期最终把大棚管理变成一个数据驱动的闭环系统。适合谁参考准备做农业机器人视觉方案的技术团队、想用深度学习解决果实采摘问题的研究生、以及已经在做智慧农业但卡在模型落地环节的一线开发者。下面我会把这套方案从数据、训练、部署到田间踩坑按实操顺序完整拆开来讲。2. 数据准备与标注策略比模型本身更影响成败的工程环节很多团队一上来就急着调模型实际做了之后才明白深度学习项目里最花时间、最决定上限的往往是数据。草莓采摘识别这种细粒度分割任务尤其如此田间和温室环境杂乱、光照变化大、果实互相遮挡如果数据质量跟不上换再强的backbone也很难救回来。2.1 采集设计覆盖真实采摘场景而不是好看的照片我见过不少项目拿网上公开数据集训练效果看着还行一到现场全废问题就出在数据分布和真实场景不一致。草莓机器人的工作场景是温室或大棚光照从晴天的直射到阴天的散射都有果实有的正面朝外有的藏在叶子后面有的半遮半掩只露出一半。这些场景必须靠自己在目标大棚里采。采集这块建议分三路走。第一路是固定机位拍摄模拟机械臂末端摄像头从多个角度观察草莓的视角第二路是手持相机扫拍覆盖不同垄间、行距、光线条件下的图像第三路是刻意制造困难样本——把叶子拨到果实前面制造遮挡、把果实转成背光角度、让相机产生轻微模糊这些别扭样本在后续训练中能显著提升模型鲁棒性。设备方面不需要太奢侈某型号工业相机配适当光源就能干活。但要注意一个关键点采集图像的分辨率要和部署时的实际摄像头输出保持一致或者至少要保证模型推理输入尺寸能够容纳果实细节。草莓从绿果到成熟果大小差异可能有两三倍小果在640像素输入下可能只有二三十个像素这种情况必须考虑高分辨率输入或者多尺度训练。2.2 标注类别设计不只标草莓还要标茎和剪断点标注类别设计是采摘任务和其他分割任务最大的不同点。不能只标一个strawberry类别因为机器人既要判断果实能不能摘成熟度还要知道在哪儿下剪子采摘点更要避免夹爪抓到茎秆伤害果柄。所以我在项目中把标注对象拆成三个子类草莓果实本体进一步按成熟度拆分绿果、白果、半熟果、成熟果果柄/茎秆采摘时需要避开的区域采摘点关键位置果柄与果实连接处的临界断裂点这样设计的目标是让模型同时输出语义信息和关键点位后期后处理可以直接基于果实mask和果柄mask的空间关系来计算剪切点而不是只靠一个粗糙的检测框去猜。成熟度拆分方面我建议至少分成未成熟和成熟可摘两个优先级如果人力充足再细化到四级。因为自动采摘系统的核心动作是只摘该摘的分级越细后续决策才能越精准。标注工具用常见的标注软件即可这里重点说几个标注原则果实边缘紧贴轮廓标注不要把叶子包进mask半遮挡果实只标可见区域同时单独标注遮挡级别属性无遮挡/轻度遮挡/重度遮挡方便后面做分层评估多个果实重叠时相接边界要按照视觉轮廓自然分界不能含糊果柄标注要有延续性被叶子完全遮挡的部分可以不标但可见部分要连贯。这套标注规范看起来琐碎实际训练时就会发现它的价值。分类是否严格、边界是否干净直接决定mask损失能不能收敛到位。2.3 数据增强与集划分把温室变成了虚拟雨季数据增强解决的是模型泛化问题。果园和温室里同一种草莓在不同光照下成像差异非常大靠收集真实数据覆盖所有情况不现实必须靠增强去模拟。我用了三组增强策略分别针对光照、几何和目标遮挡。第一组是颜色抖动随机调整亮度、对比度、饱和度、色相模拟不同天气和早晚光照第二组是几何变换随机旋转、平移、缩放、翻转模拟机械臂从不同高度和角度观察第三组是Copy-Paste和Mosaic增强把不同果实区域拼贴到一起增加单张图像的目标密度让模型在密集场景下也能稳定输出。光照方面还可以加一个Gamma校正和CLAHE直方图均衡化这两种方式对改善反光和阴影效果非常明显。数据集的划分大家通常习惯按811做训练/验证/测试但农场景象有时间特性一个成熟周期要几周前期采的数据可能都是青果后期全是红果。如果随机切分训练集里两种状态都有还好但测试集可能因为随机性过高或过低。更稳的做法是按采集日期分组切分前80%时间采集的数据做训练和验证后20%单独做测试这样能测出模型面对未来新数据的真实表现。3. 模型选型与训练细节YOLO26在算力受限设备上的适配思路YOLO26从名字延续了YOLO系列的迭代习惯。熟悉这块的读者都知道YOLO家族一直在平衡速度快和精度高这对矛盾。采摘机器人对实时性的要求非常高——视觉推理速度直接决定机械臂能不能跟上运动节奏所以我选型时把能在边缘设备跑实时作为硬约束把mask精度高作为优化目标。3.1 网络结构解析为什么一阶段分割适合采摘场景YOLO26模型整体还是Backbone Neck Head的框架。Backbone负责从图像里抽取特征一阶段模型普遍采用类似CSP结构的跨阶段连接方式保证特征提取过程中梯度更顺畅同时降低计算量Neck部分用特征金字塔结构把不同尺度的特征融合起来解决草莓大小不一的问题Head部分输出两个分支——检测分支给出每颗草莓的框和类别分割分支给出对应的像素级mask。有一点需要特别说明采摘场景里的草莓通常不会特别小但密集度高一株上挤着好几颗互相遮挡。这种场景用一阶段检测加分割的优势在于推理快一个小模型在嵌入式AI计算平台上可以跑到30帧以上缺点是遮挡严重时mask边缘容易模糊。基于此我在模型中加了注意力机制模块让网络更关注果实和果柄交界处的细节纹理代价是推理耗时增加不到10%但mask边界质量提升非常明显。具体结构参数我用了一个轻量版配置输入分辨率1280x1280考虑到小果实和果柄细节Backbone以轻量卷积为主通道数控制在64到512之间分割分支的mask输出尺寸是160x160。这个设计的逻辑是4096个mask格子覆盖一颗草莓每个格子大约对应果实表面的几个毫米区域对后续采摘点计算足够了。3.2 训练配置与关键参数一组可以直接抄作业的基础配置训练时的参数设置对最终效果影响极大我直接给出一份经实测调过的配置参考配置项数值说明输入分辨率1280x1280保留小目标细节比640提升约5-8% mask mAPbatch size16边缘设备显存有限按需可降为8优化器SGD momentum 0.937 weight_decay 5e-4比AdamW更稳初始学习率0.01配合warmup 3 epochs再余弦衰减到0.001训练轮数200 epochs实测120轮左右趋于平稳200轮全量收敛损失权重box 0.05 / cls 0.5 / seg 1.0分割是核心任务权重最高训练过程中要留意几个坑。首先是学习率问题如果训练曲线在50轮以后仍然剧烈波动优先把余弦衰减的周期改短或者降低初始学习率不要急着改模型结构。其次是分割分支的损失容易出现类别不平衡——背景像素远远多于果实像素mask损失被背景主导导致果实边界学不干净。解决办法是给mask分支加上Focal Loss或者把前景背景的比例在损失函数里做一个动态平衡。第三YOLO26的anchor设置虽然是自动生成的但草莓的形状偏椭圆和通用目标的先验差异大建议训练前先跑一遍k-means聚类看看anchor分布必要时手动修正。3.3 模型优化与裁剪让边缘设备跑得动训练好的模型直接部署到嵌入式平台往往跑不动推理延迟可能超过100毫秒这个速度根本跟不上机械臂的闭环控制。我在实际项目中做了两层优化。第一步是导出ONNX格式并做TensorRT加速。这一套下来推理时间通常能压到原来的五分之一到三分之一。关键操作包括把BN层融合进卷积层、用FP16精度推理、关闭动态shape、固定输入尺寸。实测效果十分明显。第二步是模型剪枝和通道裁剪。很多通道的激活值在推理时接近零这些通道没有实际贡献裁剪掉可以减小模型体积。我在分割分支裁掉了约40%通道mAP只掉了1个点左右推理速度却提升了约20%。如果项目对精度要求极高这一步可以跳过直接在FP16加速层面就够了。4. 图像分割识别实操流程从一帧图像到机械臂坐标模型训好只是第一步要把一个模型变成采摘引导系统中间还有一条完整的工程链路。很多团队就是在这个环节栽跟头模型指标很高但机器人下爪总是差一点。下面把整个推理与后处理流程拆开讲。4.1 推理管线的完整拆解整个系统每帧的处理流程是图像采集 → 预处理 → 模型推理 → 后处理 → 坐标映射输出。预处理阶段要做三件事缩放、归一化和颜色校正。缩放用letterbox方式把原始图像等比缩放并补边到1280避免图像变形归一化就是把像素值从0-255映射到0-1颜色校正是很多人忽略的一步温室里钠灯和太阳光色温差异大如果相机白平衡不稳定模型输入的颜色分布会漂移。我的做法是在预处理里加一个基于HSV空间的色偏矫正让红色通道在特定光照下自动回归。模型推理阶段输出的是检测框坐标、置信度、类别、分割mask二值图和类别概率。NMS阈值我一般设在0.5置信度设0.25-0.3。要注意的是草莓密集场景下如果NMS阈值过严重叠草莓会被严重抑制掉后面机械臂就会漏摘。坐标映射阶段要把模型输出的mask坐标还原到原图坐标这个看似简单实际操作中有个关键点不能直接把缩放系数乘回去因为letterbox补边会让坐标偏移。必须先减掉padding再除以缩放系数否则坐标会整体偏移十来个像素。十像素偏移对采摘来说就意味着夹爪蹭到果实表皮造成损伤。4.2 采摘点计算核心算法与常见失败模式采摘点计算是本项目的核心。很多人以为草莓采摘点就是果实中心那对机器人的末端执行器设计来说太天真了。实际上草莓采摘的关键是找到果柄和果实连接的脆弱点通常位于果实顶部的小凹陷处和果柄的交界线。我用了这样一套计算流程根据分割出来的果实mask找到mask的重心点再沿重心垂直向上寻找mask顶端轮廓的弧线中心在果实顶部生成一个环形搜索区域将果柄mask与该区域求交交集中心就是最终的采摘点坐标同时计算出果柄的角度方向供机械臂调整夹爪姿态。这个方法的关键在于利用了两类mask的空间关系。如果果柄被叶子完全遮挡导致没有果柄mask算法会自动退回到果实顶部预测点加固定偏置的模式虽然精度略降但至少不会让机械臂空跑。实际测试中采摘点识别成功率在无遮挡果实上可以达到95%以上半遮挡情况下会降到85%左右严重遮挡时基本失效——这种情况本来也不应该去摘因为夹爪可能碰到旁边的果实。4.3 成熟度判定与采摘优先级排队草莓不是同时成熟的一棵植株上可能同时挂着绿果、白果、半红果和成熟红果。机械臂如果见一个摘一个第二天再来这批果就废了。所以系统要把成熟度判定做到采摘决策里。我的方法是对每颗果实的分割mask区域做颜色统计计算红色像素占比。阈值分三级红色占比超过70%判定为成熟可摘40%-70%判定为近熟待定低于40%判定为未熟暂不摘。同时结合果形数据——成熟草莓通常是圆锥形未熟果更偏向球形果形特征可以辅助颜色判定避免因光照偏色导致误判。采摘优先级方面系统会在每个决策周期内把成熟果按位置可达性和遮挡程度排序优先处理无遮挡且位于机械臂行程中央的果实最大程度减少机械臂路径规划难度和碰撞风险。5. 系统部署与智慧农业管理闭环从单点算法到完整平台很多团队把模型跑通就以为项目结束了但真正的工程挑战在于怎么把它装进一台能在大棚里长期运行的设备里并且和其他系统联动起来。这部分讲一讲我在部署和集成层面的方案。5.1 硬件平台选型与现场安装注意事项硬件方案我推荐边缘计算设备 工业相机 补光灯的组合。边缘计算平台不需要顶配关键是支持TensorRT加速且接口丰富算力大致相当于几十TOPS级别即可满足单路相机的实时推理。工业相机选择时注意两点一是帧率不低于30fps二是具备自动曝光/自动白平衡功能温室光照变化快手动调参根本忙不过来。安装位置方面有几条实测经验相机固定在机械臂末端时需要做手眼标定eye-in-hand标定方法可以用张氏棋盘法但一定要考虑草莓果实表面的反光干扰补光灯不要用普通白光直射果实表面会形成高光spot反光区域会让mask分割出现空洞。改用低角度漫射光加偏振镜可以有效缓解设备外壳要做好防潮防尘处理。大棚里早晚湿度大电路板结露会导致推理卡顿甚至设备损坏我至少见过两次因为防水没做好导致系统短路的。5.2 与采摘机械臂的联动坐标变换与通信视觉系统输出采摘点坐标后需要转换到机械臂的基坐标系下才能执行。这里涉及一个刚体变换链像素坐标 → 相机坐标 → 机械臂末端坐标 → 机械臂基坐标。变换参数来自手眼标定结果理论上标定一次就能用但实际上机械臂关节磨损、负载变化都会让标定参数慢慢漂移最好每隔一段时间做一次自动复核。通信方面我用的是轻量级消息协议在边缘设备上运行视觉推理节点在机械臂控制器上运行执行节点两者通过局域网通信。视觉节点每完成一帧处理输出一次结果包括目标ID、采摘点坐标、果柄角度和置信度机械臂节点只接收置信度高于阈值的指令。整套链路延迟实测在15毫秒左右视觉推理约30毫秒机械臂动作决策约10毫秒总延迟可以控制在60毫秒内这个水平对低速采摘动作来说完全够用。5.3 从识别果实到管理果园数据反向赋能种植这套系统最有价值的地方是它不仅服务一台采摘机器人还能变成整个草莓园的数字眼。运行过程中系统会持续记录每个区域的草莓成熟度分布、果实密度、采摘量。这些数据聚合到管理平台后可以做几件很实在的事第一是产量预测结合当前成熟果数量和近几天的成熟速率预测未来48小时可采摘数量方便安排人员或者调度机器人作业计划。第二是异常预警如果某垄连续多天成熟数量极低而另一垄又集中爆果说明温室的温差、灌溉或通风可能存在区域差异管理者可以直接针对性地查问题。第三是采摘记录追溯每一颗被摘走的草莓都有图像记录存档一旦发生食品安全或质量纠纷可以精准回溯到是哪一块田、哪一株、什么时间摘的。这些数据功能不需要额外开发太多算法核心依赖的模型输出本身就是结构化的——只要在部署时把每帧推理结果落库再写几个统计查询接口就够了。但正是这个顺手为之的数据层让项目从机器换人变成了数据指导种植价值提升了一个量级。6. 常见问题与排查技巧实录温室环境中的那些坑这一段我把自己实际调试过程中踩过的坑、以及身边同行遇到的高频问题整理成速查表希望能帮后来者少走弯路。现象可能原因排查/解决方式成熟草莓mask出现内部空洞表面反光导致高光区域特征丢失补光加偏振片图像预处理加局部直方图增强训练数据增加高光样本温室强光下检测框抖动自动曝光频繁波动固定曝光参数采用HDR模式取帧果实重叠处分割粘连两个实例边界特征太相似提高mask损失权重增加边缘感知损失使用更细的mask输出远距离小果漏检目标在输入图上像素过少调高输入分辨率到1280以上对图像分块推理再拼接SAHI方案推理速度不达标模型过大 / 未做加速导出ONNX后做TensorRT FP16加速通道剪枝蒸馏到轻量结构机械臂下爪位置偏上或偏下手眼标定参数漂移重新标定在系统增加定期自动标定程序检查相机安装是否有松动果柄mask时有时无果柄过细分割模型学习不充分单独提升果柄类别的损失权重使用切片放大推理连续雨天模型表现骤降训练数据晴天占比过高收集或合成阴雨天样本增强里加大亮度/对比度扰动强度训练loss曲线在epoch 80后震荡学习率过大提前触发余弦衰减或降低初始lr延长warmup6.1 反光和光线突变问题反光是草莓视觉任务里最烦人的干扰源没有之一。成熟草莓表面光滑在补光灯下会形成一个高亮的镜面反射区分割模型在这个区域经常给出错误输出。第一个解决思路是从硬件层面出发改变光源角度、加柔光罩或偏振片。我实测过偏振片方案效果最直接但会损失部分进光量需要相应提高曝光时间或ISO。第二种思路是从算法层面对抗。在训练集的增强管线里刻意加入模拟高光操作随机选取果实区域把局部像素值拉高并加上白色斑点噪声。这样模型会学着忽略高光区域而不是把它们当成异常特征。经过增强训练后高光区域造成的mask空洞比例下降了大概六成。如果还不满意可以在后处理里对mask做一个孔洞填充用面积阈值判断哪些小空洞需要补上。6.2 遮挡场景的决策策略草莓大棚里完全无遮挡的果实其实是少数多数果实不是被叶子挡了一角就是和其他果实挤在一块。系统在遮挡场景下不能硬摘也不能全放弃关键是要建立遮挡程度的量化指标。我用一个简洁实用的算法来评估取果实检测框的面积和果实mask面积的比值fill ratio可以理解为果实露出程度。比值接近1说明几乎无遮挡低于0.5说明遮挡严重。系统设定0.6作为安全采摘阈值也就是说只要露出面积超过60%就可以尝试采摘——配合机械臂的柔性夹爪实际成功率仍然很高低于这个阈值则跳过该果实等待下一轮巡检时再评估。这套策略的优点在于它不追求所有果实都精确分割而是用工程可判定的方式处理不确定性。很多模型指标看似完美但落地时真正提升采摘成功率的恰恰是这些工程决策规则。6.3 模型迭代与数据回流机制模型上线后不能一劳永逸。大棚环境的季节变化、品种更换、光照模式改变都会让模型性能缓慢下降。我从项目启动第一天就建立了一个数据回流闭环每台部署设备都会自动把低置信度推理结果截图上报到一个数据池每周定时人工筛选一部分进行补充标注然后增量训练模型再灰度发布到部分设备上对比效果。增量训练有个细节要特别注意不能只用新数据训练否则模型会遗忘旧场景的特征。我在每个增量训练周期里都会混合抽取20%-30%的原始训练数据和新增样本一起进入训练集。这个回放机制是防止灾难性遗忘的关键实测引入回放后模型在旧场景上的表现几乎不下降。7. 写在最后的一点体会这套系统从数据集搭建到最终上车部署整个过程最大的感受是深度学习模型在其中的占比远没有很多人想象的那么高。模型结构选型、训练参数调优当然重要但真正决定项目能不能用的往往是数据标注是否细致、后处理规则是否贴合机械结构、坐标变换标定是否精准、以及现场遇到反光和遮挡时有没有一套稳住的预案。草莓采摘识别这类农业视觉任务和城市里做自动驾驶或者工业质检有一个本质差异——它的目标物体是活的、是变化的、是长在复杂的自然环境里的。果实不会等着你调整好光线再变红叶子永远在挡路温室里的湿度和温度在一天之内可以横跨好几个季节。能在这种环境下稳定运行的开发者靠的永远不是某一次完美的训练而是持续的迭代和现场观察。如果让我给后来者一条最具操作性的建议那就是从一开始就为数据回流做设计而不是等项目上线后再补。在系统架构里留好数据落盘、低置信度上报、增量训练这三条通道后面所有优化都会快很多。等你的模型在真实大棚里稳稳跑完一个完整采摘周期看见机械臂精准避开绿果、只摘那一颗刚好红透的草莓时你会觉得前面所有调试到凌晨的夜晚都值了。