YOLOv11智慧农业实战:作物生育期识别与精准施肥系统 简介文档围绕智慧农业中的作物生长阶段识别与精准施肥决策展开以YOLOv11作为核心技术路线面向目标检测学习者、农业信息化从业者及高校相关专业学生适合进行项目落地与技术方案选型参考。资源共37页内容覆盖YOLOv11基础架构、作物数据集构建与标注、模型训练优化、精准施肥决策算法设计、系统集成与部署并以实践案例展示识别准确率评估与肥料利用率提升方案可帮助读者建立从数据采集到模型应用再到决策落地的完整认知。文档从智慧农业背景出发对比传统识别方法的局限讲解YOLOv11单阶段检测在速度与精度上的优势同时针对数据增强、超参数调整、施肥决策模型建立等关键环节给出可借鉴的工程化经验。压缩包内为1个PDF文件大小2.3MB支持目录章节跳转与大纲快速定位阅读体验完整。已有54人学习下载适合借助具体农业场景快速掌握YOLOv11在实际项目中的落地方法。1. YOLOv11 在智慧农业里最值钱的用法,是作物生长阶段识别YOLOv11 在智慧农业里最值钱的用法,是把作物生长阶段识别变成可批量执行的视觉任务。施肥决策最难的从来不是买肥,而是确定作物当前处于哪个生育期:同一块麦田,苗期追氮和拔节期追氮,增产效果差一倍,看错阶段肥白撒,还要赔上倒伏风险。传统做法靠农技员下田目测,一人一天看不了几百亩,判读标准因人而异。用 YOLOv11 替代这套人工巡检,输入无人机或田间摄像头照片,输出生育期类别和株数,再映射成 N-P-K 处方图,这就是精准施肥决策的入口。适合正在做智慧农业落地的算法工程师和系统集成工程师,新手也能按步骤复现最小方案。2. YOLOv11 网络结构选型与本地环境搭建2.1 C3k2 与 C2PSA:V11 相比 V8 改了什么YOLOv11 是 Ultralytics 在 2024 年底发布的检测、分割、姿态一体系列,代码仓库与 v8 共用,迁移成本低。它没有重做检测头,改动集中在 backbone 和 neck:把 v8 的 C2f 替换成 C3k2。C3k2 保留跨层拼接的结构,同时把分支里的瓶颈卷积拆成 k3 的两个 3×3 卷积,在相同计算量下提升了高分辨率特征图的表达能力;backbone 顶层在 SPPF 之后接入 C2PSA 模块,把位置注意力放进 C2 结构,让网络可以编码作物成行排列这类空间先验,对航拍视角下密集排列的作物行是有实际帮助的。结构改动带来的直接收益是:相同推理耗时下,v11 的 mAP 比 v8 高半个到一个点,推理速度还有小幅提升。但对作物生育期识别来说,网络结构只是地基。苗期和分蘖期远看都是绿色,抽穗期和成熟期远看都是黄褐色,真正可分的差异在叶型、株高、穗形态这些细节上;细节能不能被学出来,取决于训练集里每个阶段有没有足够多样且有代表性的样本,而不是网络层数。所以本章先把环境跑通,第三、四章集中解决数据和小目标问题。2.2 最小可复现环境:conda 装 ultralytics 的一条命令链常见做法是用 conda 建一个干净的 Python 3.10 环境,再装 ultralytics,训练、验证、推理、导出全在这一个包里完成。安装顺序有讲究:先装与 CUDA 匹配的 PyTorch,再装 ultralytics,顺序反了 pip 可能自动装成 CPU 版。conda create -n agri-yolo python3.10 -y conda activate agri-yolo pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install ultralytics python -c from ultralytics import YOLO; mYOLO(yolo11s.pt); print(ok)第一行创建独立环境,避免污染系统 Python;第三行的 cu121 对应 CUDA 12.1,驱动只支持 11.8 时把链接后缀改成 cu118;最后一行为验证步骤,联网下载 yolo11s.pt 预训练权重并打印 ok,说明环境就绪。没有 NVIDIA 显卡的机器也能跑,但训练 imgsz1280 会慢一个数量级,建议先用小数据集跑通流程,再上 GPU。2.3 模型规格:n/s/m/l/x 按部署端选型规格参数量约COCO mAP50-95 约常见部署位置yolo11n2.6M39.5田间摄像头、边缘盒子yolo11s9.4M47.0摄像头实时识别yolo11m20.1M51.5无人机影像批量处理yolo11l25.3M53.4服务器高精度任务yolo11x56.9M54.7离线精细分析表格数据是官方文档在 COCO 验证集上的参考值,实际农业数据 mAP 只会更低,选型看的是相对差距而不是绝对值。边缘盒子跑 n 档能勉强实时,服务器批量处理航片用 m 档性价比最高,摄像头定点识别用 s 档。项目起步我一般先拿 yolo11s 把数据闭环跑通,等验证集 mAP 稳定后再决定是否升级到 m 或 l;一上来就上 x,迭代慢,收益不成比例。3. 按农学标准建生育期数据集,再谈 YOLOv11 训练参数3.1 生育期类别直接照抄农学定义作物生育期是农学里定义好的阶段,以小麦为例:出苗期、分蘖期、拔节期、抽穗期、开花期、灌浆期、成熟期。类别名直接照抄,不要自创小苗、中苗、大苗。原因是后面的施肥决策要跟农艺师协作,他们对拔节期追氮、抽穗期补钾有现成的用量经验,类别体系对不上,决策逻辑整个没法落地。每个生育期至少采集 800 到 1000 张代表性样本,覆盖不同光照、不同品种、不同种植密度。大田场景最常见的坑是某个阶段的照片集中在同一天同一地块拍完,模型学到的其实是那天的光照和土壤底色,而不是阶段特征。采集按同阶段多地块多时刻原则;划分训练集和验证集时必须按地块分,不能按图片随机分,同一地块的相邻照片高度相关,随机划分会让 mAP 虚高十几甚至二十个点。3.2 标注策略:单株框和整片框怎么配合生育期识别有两条标注路线:框住整片田块给一个阶段标签,或者框住单株/单丛给阶段标签。整片框省事,但大田里经常同时存在两个阶段,比如田边早熟、田心晚发,一个框只能有一个标签,边界样本直接把模型教坏;单株框标注量大,却能同时输出株数,而株数密度正是后面施肥决策里密度修正项的输入。常见做法是低空影像标单株用于训练,高空正射影像只做推理供分区统计。标注工具用 LabelImg 或 X-AnyLabeling 都可以,导出 YOLO 格式,每行 class x y w h 四个归一化坐标。类别 id 的顺序必须在 data.yaml 里固定,中途增删会让旧标签全部作废,这是个低频但杀伤力很大的事故。3.3 训练命令和关键参数表3.3.1 data.yaml 必须写对的三个字段data.yaml 是训练入口,三个字段最容易错:train 和 val 要用绝对路径,相对路径在换机器后一定失效;nc 必须和类别数一致,多一个少一个都会在训练时报维度错误;names 列表的下标要和标注工具的类别 id 对应,顺序错了模型学到的标签就是错位的。3.3.2 先跑通再调参的训练命令先跑官方最小数据集确认环境没装错,再换自己的数据训练。两步命令如下:yolo detect train datacoco8.yaml modelyolo11s.pt epochs2 imgsz640 yolo detect train data/data/agri/agri.yaml modelyolo11s.pt epochs150 imgsz640 batch16 patience30第一条只验证安装,epochs2 跑完不报错就行;第二条是正式训练,patience30 表示验证集 mAP 连续 30 轮不涨就早停,可以省下不少卡时。参数常用值调整说明imgsz640 起步大田小目标建议训练时直接上 1280batch按显存8G 显存配 yolo11s 建议 16,imgsz1280 时降到 4patience30验证 mAP 连续 30 轮不涨自动停optimizerautov11 默认按模型自动选,先不动pretrainedyolo11s.pt迁移学习比随机初始化收敛快得多训练期间盯 runs/detect/train 目录里的 loss 曲线,确认分类、回归、DFL 三项损失都在下降;结束后部署用 weights/best.pt,不要用 last.pt。第一步只追求稳定收敛,不调参;收敛有问题再回头看数据,而不是先动学习率。4. YOLOv11 小目标优化:大田航拍精度上不去的三个改法4.1 imgsz 从 640 提到 1280,先看代价无人机在 30 到 50 米高度拍小麦,单株大约只占 20×20 像素,经过五次下采样,特征图上的目标只剩一到两个像素,检测头基本无从下手。直接把 imgsz 从 640 提到 1280,特征图分辨率翻倍,小目标的可辨识信息显著增加,这是投入产出比最高的改法。代价是显存和时间都接近翻倍,动手前先看这张表:设置显存占用约单轮耗时小目标 mAP 趋势imgsz640,batch1668G基准基准imgsz1280,batch48G 左右约 2 倍明显上升imgsz1280,batch812G 以上约 1.5 倍稳定最好显存不够时可以先训练用 640、验证用 1280,确认提升幅度再决定是否租大显存机器。注意训练和验证必须用同一个 imgsz,否则 mAP 数据不可比。4.2 亿级像素正射影像用滑窗推理输入是拼接好的正射影像时,宽高动辄两三万像素,整图推理在任何显卡上都会爆内存。通行做法是滑窗切块:切成 1280×1280 的小块,块间保留 20% 重叠,逐块推理后用 NMS 合并重叠区域的重复框。这套流程不用自己写,SAHI 库直接封装好了:from sahi import AutoDetectionModel from sahi.predict import get_sliced_prediction model AutoDetectionModel.from_pretrained( model_typeultralytics, model_pathruns/detect/train/weights/best.pt, confidence_threshold0.35, image_size1280, ) result get_sliced_prediction( ortho_tile_042.jpg, model, slice_height1280, slice_width1280, overlap_height_ratio0.2, overlap_width_ratio0.2, )model_type 填 ultralytics,SAHI 会直接加载 YOLO 权重;两个 overlap 参数是重叠比例,太小会漏掉跨块目标,太大会让重复框变多。result.object_prediction_list 里的坐标是原图坐标系,可以直接喂给分区统计。多块推理时注意存储 IO 往往先于 GPU 成为瓶颈,建议把切好的块按序读入、逐块释放。SAHI 对 5 像素以下的极小目标也无能为力,那种情况要回源头提高采集分辨率。4.3 增强和损失层面的微调YOLOv11 默认开启 mosaic 增强,四张图拼一张,对小目标友好,但大田影像内容干净、目标分布均匀,拼接缝反而引入伪特征,可以在训练配置里把 mosaic 概率降一档。类别不均衡常见于灌浆期等后期阶段样本难采的场景,给少数类加权比复制粘贴更稳。更激进的做法是换损失函数,默认 box 损失对密集小目标回归不够敏感,可以试 PIoUv2 这类面向小目标的回归损失,在训练脚本里替换 box loss 模块。这类改动效果因数据而异,必须一次只改一个,跑完验证集 mAP 再决定去留,不要同时调多个参数。5. YOLOv11 批量推理与结果保存的完整写法5.1 predict 参数:save、save_txt、save_conf 各存了什么拿到 best.pt 之后,下一步是对整个田块影像批量推理并保存结果。最常见的坑是只开了 saveTrue,跑完发现只有画框图,回头要统计株数和生育期分布时全得重跑。推荐参数是一次把图和标签都落盘:from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) results model.predict( sourcefield_imgs/, imgsz1280, conf0.35, iou0.45, saveTrue, save_txtTrue, save_confTrue, projectruns/detect, nameagri_predict, ) for r in results: print(r.path, r.boxes.cls.tolist(), r.boxes.conf.tolist()) r.save(archive/ r.path.split(/)[-1])save_txtTrue 会给每张图生成同名 txt,一行一个目标,格式是 class x y w h 归一化坐标;save_confTrue 在行尾追加一列置信度。需要归档时保留 txt,活体统计直接用 r.boxes.cls 在内存里聚合,不必再解析文件。conf 阈值不要设太低,大田里杂草、土块、麦茬都会被当成苗,株数一偏,后面的施肥处方全偏。密植场景可以从 0.35 降到 0.25,稀疏场景反之。需要把结果喂给下游决策服务时,优先在内存里聚合成分区统计,例如按文件名统计每个生育期的检出数:from collections import Counter stage_counter Counter() for r in results: for c in r.boxes.cls.tolist(): stage_counter[model.names[int(c)]] 1 print(stage_counter)model.names 是训练时 data.yaml 里的类别名列表,框的 cls 是类别下标,两者对应起来才能转成分蘖期 1800 株这种决策层能直接消费的格式。5.2 逐块处理航片,注意内存回收处理超大影像时,先把原图尺寸读出来,按 1280 滑窗生成区块的像素坐标,逐块推理、逐块释放。Python 里显式 del 图像对象再调用 gc.collect(),能避免内存只涨不降;不释放的话,处理到第五六块就可能把内存打满。每块的检测框坐标必须加上区块左上角的偏移量,换算回原图坐标,否则后面处方图分区的边界全是错位的。这个错误很隐蔽,因为它不影响单块 mAP,只在最终统计图上暴露。5.3 用混淆矩阵查阶段误判训练自带的 confusion_matrix.png 只能看整体趋势,更有用的是把验证集单独跑一遍,按类别看误判集中在哪里:model YOLO(runs/detect/train/weights/best.pt) metrics model.val(dataagri.yaml, imgsz1280) cm metrics.confusion_matrix.matrix print(混淆矩阵形状:, cm.shape) # (nc1, nc1),最后一行/列是背景重点检查两个方向:相邻生育期是否互相混,比如分蘖被识别成拔节;成熟期干枯植株是否大量落进背景类。互混严重的类,回去补该阶段的样本比调参数有效;背景误检高,检查标注时是否漏标了干株。另外大田时序数据里相邻帧高度相似,做长周期监测时按固定间隔抽帧推理,不要逐帧全跑,既能省算力,也避免同一株苗被重复计数。6. 从 YOLOv11 识别结果到精准施肥决策的闭环6.1 生育期到需肥量:分区统计加查表检测模型输出的是逐框类别,决策层不直接消费检测框,而是把田块按网格分区,统计每个分区内各生育期检出次数,取众数作为当前阶段,再查需肥映射表。下表是小麦各生育期每公顷 N-P-K 纯量的参考值(kg/ha),必须由农艺师按当地土壤养分修正后再用:生育期NP2O5K2O苗期311分蘖期623拔节期836抽穗期513成熟期000FER_TABLE { tillering: {N: 6, P: 2, K: 3}, jointing: {N: 8, P: 3, K: 6}, heading: {N: 5, P: 1, K: 3}, maturity: {N: 0, P: 0, K: 0}, } def prescription(cls_counts, area_ha): stage max(cls_counts, keycls_counts.get) base FER_TABLE[stage] density sum(cls_counts.values()) / area_ha factor min(max(density / 45000, 0.8), 1.1) return stage, {k: round(v * factor, 1) for k, v in base.items()}cls_counts 来自第五章批量推理的分区统计,area_ha 是分区面积。密度因子把苗稀减施、苗密稳施落成线性规则,修正范围先限制在正负 20% 以内,拿到土壤检测数据后再放宽。45000 这个分母代表单位面积的参考株数,换作物要重新标定,别直接复用。6.2 处方图落地与闭环校验每个分区得到一组 N-P-K 后,按变速率施肥机或无人机撒施生成处方图,输出 GeoTIFF 或 shapefile,对接农机作业系统。验收时固定留一块对照区不施肥,记录产量和植株氮含量;下一季把处方、产量、气象做成回归,反推这张需肥表要不要调。整个闭环里 YOLOv11 是眼睛,只有当 5.3 的阶段误判率低于 10% 时,处方误差才处于可接受范围;误判率更高时,花在决策算法上的优化都是白费,先回去补数据和调检测。本文还有配套的精品资源点击获取