YOLOv5养殖场肉鸡健康状态检测权重与数据集实战指南

简介面向养殖场肉鸡健康状态监测这一实际生产场景提供YOLOv5权重与配套数据集形成了从模型训练到推理验证的完整闭环适合农业AI开发者、计算机视觉初学者以及智慧养殖项目实践者直接参考使用。压缩包共983个文件包括441张jpg原始图像、435个txt格式YOLO标签、29个yaml配置、24个Python脚本及预训练pt权重整体大小约58.62MB数据集已按train、val、test清晰划分并附有data.yaml文件YOLOv5/7/8/9等主流算法均可直接加载训练无需额外整理。已有145人学习/下载该资源。数据集中Abnormal异常与Normal正常两类标注完整随包脚本可辅助数据预处理、训练与推理并包含Dockerfile与TensorBoard训练日志便于快速复现肉鸡健康检测流程、开展迁移学习或算法对比实验也可直接用于实际部署验证或作为课程设计、毕业设计的项目素材。txt标签格式兼容主流YOLO框架配合现成目录配置可显著降低项目启动成本。1. 养殖场肉鸡健康状态检测为什么权重和数据集比模型结构更值钱很多做农业 AI 的人第一次接触这个选题都会默认去找 YOLOv5 的源码然后往里面塞自己的图片。但真正下过养殖场的人会告诉你卡住进度的从来不是模型结构而是两样东西带标注的现场数据集和一组能扛住实际环境干扰的权重。所谓“YOLOv5养殖场肉鸡健康状态检测权重数据集”本质是一套已经跑通的落地组合——权重负责把“鸡看起来不对”这件事变成可量化的坐标和置信度数据集负责让模型见过足够多的鸡舍光照、羽毛颜色、排泄物状态和饲养密度。这篇文章就是围绕这套组合把数据怎么整理、权重怎么训、参数怎么调、部署在哪、坑在哪一条线讲透。适合读这篇文章的人是手里有养殖场资源或者准备接养殖场项目的算法工程师、农业信息化方案商也包括想用 YOLOv5 做动物行为识别但还没摸到门路的研究生。我会默认你已经跑通过 YOLOv5 的基础训练流程但不要求你有养殖场数据。文章里出现的命令和配置全部基于 YOLOv5 官方仓库 v6.0 之后的结构这是目前社区里最稳定的一个版本线。2. 养殖场肉鸡数据集的现场采集与标注光照、羽毛和密集遮挡是三个绕不开的坎2.1 现场拍回来的素材为什么不能直接进训练集养殖场的实际画面和公开数据集里的鸡完全不是一回事。公开数据集里的鸡往往背景干净、光线均匀、单体大而现场画面里最常见的三个干扰是氨气浓度高导致镜头表面起雾、鸡舍内白羽鸡在强光下过曝、以及几千只鸡挤在一起时的密集遮挡。如果你直接把现场视频抽帧丢进标注工具会发现标注员标到一半开始靠猜因为鸡的边界在画面里本来就模糊。我一般建议现场采集按三个维度控制素材质量。第一个维度是时间覆盖必须包含清晨开灯后 30 分钟、中午饲喂时段、傍晚关灯前 1 小时这三个典型光照段每个时间段至少占全天采集量的 20%。第二个维度是机位高度摄像头距离地面 2.5 米到 3 米、俯视角度 30 度到 60 度之间最能同时拍到鸡背部和侧面这个角度下羽毛蓬松、垂翅、缩颈这些健康异常特征最明显。第三个维度是清晰度兜底任何一帧画面里鸡只身体区域小于 32×32 像素的素材直接丢弃这类小目标在 YOLOv5 里即使标了也很难学出稳定特征。采集完成后要做的第一件事不是标注而是抽帧筛选。用 ffmpeg 按每 5 秒一帧抽帧然后拿一个初版模型哪怕是 COCO 预训练权重跑一遍置信度过滤把画面里鸡只数量为 0 或整帧模糊的图片直接淘汰。这个操作能把 3 小时的视频素材压缩成 1500 到 2500 张有效图片为后续标注节省大量时间。2.2 健康状态分类的标签体系怎么定肉鸡健康状态检测不能只分“健康”和“不健康”养殖户需要的是可操作的信号。我在实际项目里用的是四分类标签体系healthy正常、lethargic精神萎靡、abnormal_droppings排泄异常、injured外伤或垂翅。其中 lethargic 是标注难度最高的类因为病鸡早期只是活动量减少、颈部微缩没有明显的肢体变形标注员需要看连续多帧才能确认所以这类目标在标注规范里要求必须用视频片段复核。标签体系一旦定下来训练阶段就不要轻易改。很多团队犯的错是标到一半发现 injured 和 lethargic 边界模糊临时合并类目结果之前标的数据全部作废。如果确实需要调整宁可把模糊样本单独拎出来做二次标注也不要改标签定义。标注格式直接采用 YOLOv5 原生支持的 txt 格式每行一个目标内容是 class_id、x_center、y_center、width、height坐标全部归一化到 0 到 1。标注工具可以用 LabelImg 或者 LabelStudio前者轻量适合单机标注后者支持多人协作和视频抽帧联动适合数据量大的项目。注意标注完成后要做一次坐标越界检查归一化坐标偶尔会因为标注工具的边界拖拽产生大于 1 的小数这类文件训练时会被 YOLOv5 直接忽略导致有效图片数缩水。2.3 数据集目录结构YOLOv5 训练前必须对齐的文件组织方式YOLOv5 对数据集目录的要求很明确不需要写自定义 Dataset 类只要把图片和标签按下面的结构放好训练命令里指定 data.yaml 路径即可。我第一次做的时候在这里栽过跟头images 和 labels 的目录名写成了 image 和 label结果 training 阶段 loss 直接不下降。dataset/ ├── images/ │ ├── train/ │ │ ├── img_001.jpg │ │ └── ... │ └── val/ │ ├── img_301.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── img_001.txt │ │ └── ... │ └── val/ │ ├── img_301.txt │ └── ... └── data.yamldata.yaml 是训练入口配置内容必须包含三个关键字段path 指到 dataset 根目录train 和 val 分别指到 images 下的子目录nc 填类别数names 填类别名列表。这里有个容易踩的细节train 和 val 字段可以直接写 images/train 这种相对路径但如果 path 写的是绝对路径后续换机器训练时整个配置文件就要改一遍。我习惯把 path 写成相对路径配合训练命令里的 --data 参数指向 data.yaml 的实际位置这样项目目录整体拷贝到服务器上不用改任何配置。标签文件和图片必须同名且扩展名不同这个规则看起来简单实际用脚本做数据划分时最容易出错。2.4 数据增强配置养殖场场景的增强参数不能照抄默认值YOLOv5 自带的增强策略已经很完善但养殖场场景有两个特殊性需要额外处理。第一是光照变化剧烈默认的 HSV 增强里 H 通道变化范围太小模拟不了鸡舍里钠灯和自然光交替的色温差异。第二是密集遮挡默认的随机裁剪增强会把大量目标切掉一半反而让模型学到错误特征。我一般会在 yolov5s.yaml 或者训练命令的 hyp 参数里单独调整三个值。hsv_h 从默认的 0.015 提高到 0.02让色相偏移稍大一点模拟不同灯源下的偏色。hsv_s 从 0.7 降到 0.5防止饱和度变化太大导致白色羽毛过曝。flipud 从默认的 0.5 改成 0.1鸡只很少从正上方翻过来垂直翻转概率太高会引入大量不真实姿态。这些参数在 train.py 里通过 --hyp 传入不需要改动源码。如果用的是 YOLOv5 的 roboflow 版用户界面这些参数在 Advanced Settings 里同样能找到对应项。数据量不足一万张时不要开 mosaic1.0 的满概率增强。mosaic 拼接四张图会让小目标尺寸进一步缩小而养殖场画面里本来就有大量密集目标叠加 mosaic 后训练出的模型对小目标召回反而更差。我的经验是 mosaic 概率在 0.3 到 0.5 之间同时开启 mixup 0.1既能丰富背景多样性又不打乱目标尺度分布。3. 训练肉鸡健康检测权重从预训练选择到超参数调优的完整流程3.1 预训练权重怎么选yolov5s.pt 还是自定义数据集迭代YOLOv5 的官方预训练权重有 s、m、l、x 四档对应不同的模型深度和宽度。养殖场肉鸡检测不需要识别精细纹理属于中等难度目标检测任务我通常选 yolov5s.pt 作为起点。s 档推理速度快在边缘设备上能跑到实时帧率而且训练所需显存最小单卡 8GB 就能跑完整个流程。如果用 x 档精度提升有限但训练时间和部署成本都翻倍对于“健康状态检测”这种本身就有模糊边界的任务来说不划算。加载预训练权重时有一件事必须注意源码仓库里的 yolov5s.pt 是在 COCO 数据集上训练的COCO 里没有鸡这个类别但底层的边缘纹理特征仍然有效。训练时用 --weights yolov5s.pt 加载YOLOv5 会自动把最后一层类别数适配成你的 nc 值不需要手动改模型文件。项目做到中期如果有上一轮训练保存的 best.pt我会优先用它做增量训练而不是重新从 COCO 权重开始。增量训练收敛更快且能保留上一轮学到养殖场现场特征。3.2 训练命令的最小可用形态直接抄这份配置下面这份训练命令是我在多个养殖场项目里验证过的起点配置单卡 RTX 3090 或 4090 都能跑batch size 按显存大小调整即可。cd yolov5 python train.py \ --data /path/to/your/data.yaml \ --weights yolov5s.pt \ --img 640 \ --batch-size 16 \ --epochs 100 \ --cache ram \ --device 0 \ --name broiler_health_v1 \ --project /path/to/runs参数说明img 640 是输入分辨率这个尺寸兼顾了鸡只目标的大小和推理速度。如果现场画面里鸡只普遍偏小可以提高到 960但显存占用会变成原来的 2.25 倍训练时间也相应拉长。batch-size 16 在 24GB 显存下比较宽裕如果是 8GB 显存的卡把 batch-size 降到 8、cache 从 ram 改成 disk 也能跑。cache ram 的作用是把图片一次性加载到内存里省去每个 epoch 反复读磁盘的 IO 开销但需要有足够的可用内存建议图片总量小于 8GB 时使用。epochs 100 是基线值。训练过程中要盯两个曲线训练 loss 和验证 mAP。正常情况下到第 40 到 60 个 epochval 精度会进入平台期如果到 80 个 epoch 还在缓慢上升可以再加跑 50 轮。如果到第 30 个 epoch 精度就停滞且 loss 震荡说明学习率设置不合适或者数据本身有问题先不要加训练轮数回去检查标注质量。3.3 超参数调整的优先级学习率、锚框和类别权重怎么动YOLOv5 的超参数在 data/hyps/hyp.scratch-low.yaml 里训练时通过 --hyp 指定。对养殖场任务来说调整优先级依次是学习率、锚框、类别权重。学习率是最容易出效果的一项默认的 lr0 是 0.01如果训练时 loss 在前 10 个 epoch 就出现剧烈震荡把 lr0 降到 0.005同时把 lrf最终学习率系数从 0.01 调到 0.005让后期收敛更稳。锚框这个参数很多人都忽略。YOLOv5 默认会开启自动锚框计算训练开始时会基于你的标注框重新聚类锚框尺寸。养殖场场景里鸡只尺度分布比较集中自动计算出来的锚框通常比 COCO 默认值更贴近实际。如果你发现自动计算后小目标检测效果仍然不好可以手动在模型 yaml 文件里把 anchors 改成三组小尺寸的预设值比如 [10,14, 16,22, 24,32] 这组对应小目标的组合作为自动计算的兜底。类别权重在数据不平衡时用。四分类场景里 lethargic 和 injured 的样本量通常只有 healthy 的十分之一这种情况下需要给少数类加大损失权重。YOLOv5 在 loss 计算里没有直接暴露类别权重参数常见的做法是修改 train.py 里 build_targets 部分的 classify 权重或者通过复制少数类样本做过采样。我试过复制的效果比改损失函数更稳定前提是复制时配合小幅度的图像增强否则模型会过拟合到重复样本上。每类标注数量差距超过 5 倍时这个操作是必须做的。3.4 训练中期的断点续训与权重保存策略养殖场项目的数据集通常分布在多台机器上训练经常被打断。YOLOv5 每次 epoch 结束都会保存 last.pt 和 best.pt断点续训直接用 last.pt 拉起即可。这里有一个关键设置--save-period 参数可以指定每隔多少 epoch 保存一次检查点我习惯设置成 10防止 last.pt 恰好保存了一个过拟合阶段的权重导致无法回滚。best.pt 是以验证集 mAP 为指标保存的最优权重最终部署时用的一律是 best.pt 而不是 last.pt。权重保存路径在 --project 和 --name 组合的目录下形如 /path/to/runs/broiler_health_v1/weights/best.pt。训练完成后先别急着部署做一次回看验证把 best.pt 在验证集上跑一次把检测结果画到图上人工看一遍那些置信度高于 0.5 的目标框是否真的框对了位置和类别。这一步能发现标注规范里的系统性偏差比如标注员把垂翅误标为 injured 而忽略了这个姿态也可能出现在正常争斗中。这个回看动作每次训练后必须做权重大概率不需要回炉但标注规范可以通过这个反馈持续优化。4. 部署到养殖场边缘设备从 PyTorch 权重到可落地的推理服务4.1 权重格式转换pt 转 ONNX 转 RKNN 的完整链路养殖场现场不可能架一台 GPU 服务器做实时推理常见做法是部署在 Jetson Nano、树莓派 4B 或者瑞芯微 RK3588 这类边缘设备上。PyTorch 的 .pt 权重不能直接在这些设备上跑必须先转成 ONNX 再做目标平台的适配。转换用 YOLOv5 自带的 export.py 脚本一条命令完成python export.py \ --weights /path/to/runs/broiler_health_v1/weights/best.pt \ --img 640 \ --batch 1 \ --include onnx \ --simplify \ --opset 12参数说明--img 640 必须和训练时的输入尺寸保持一致如果训练用了 960这里也必须写 960否则模型输入维度不匹配。--simplify 会调用 onnx-simplifier 对计算图做常量折叠和冗余节点清理这一步对后续 RKNN 转换很重要能减少算子不支持的概率。--opset 12 是 ONNX 算子集的版本号RKNN 工具链对高版本 opset 支持不完全锁在 12 是兼容性最稳的选择。转换完成后用 onnxruntime 验证一下输出是否正确。方法是用一张测试图同时跑 .pt 和 .onnx对比两者的输出张量形状和数值差异。YOLOv5 的输出是 [1, 25200, 85] 形状的张量其中 25200 是三个尺度特征图上的锚框总数85 是 4 个坐标 1 个置信度 80 个类别。如果你自己的权重是四分类输出就是 [1, 25200, 9]。数值差异在 1e-3 量级以内是正常的如果差异达到 0.1 以上说明转换过程中有算子被错误映射需要检查 ONNX 模型里的 unsupported 算子。如果目标设备是 RK3588接下来用 RKNN-Toolkit2 把 ONNX 转成 .rknn 格式。转换脚本里的关键参数是量化模式RKNN 默认的量化是 int8一个 640×640 的输入模型量化后精度通常会掉 1 到 3 个百分点在健康状态检测这种场景下可接受。如果你对精度敏感用混合量化只对检测头部分的层保留 float16 精度。量化需要准备一批校准图片我用验证集里的 200 张图覆盖不同光照段即可。量化跑完后会生成一个 acc 评估报告显示每一层的精度损失如果某一层的 cosine similarity 低于 0.99把它单独设成 keep_dtype 为 float16。4.2 推理脚本的输入输出约定不直接输出画框图要输出结构化数据养殖场项目里算法真正要交付的不是图片而是能够驱动业务动作的结构化数据。比如检测到 lethargic 类目标连续出现超过 20 帧需要触发养殖管理系统的告警。所以推理脚本的设计核心是输出类别的目标框坐标、置信度、类别编号和时间戳而不是只保存画了框的 jpg。import cv2 import numpy as np from rknnlite.api import RKNNLite rknn RKNNLite() rknn.load_rknn(/path/to/broiler_health.rknn) rknn.init_runtime() cap cv2.VideoCapture(rtsp://192.168.1.100:554/stream1) fps cap.get(cv2.CAP_PROP_FPS) while True: ret, frame cap.read() if not ret: break # 保持输入尺寸与训练时一致letterbox 方式是关键 img cv2.resize(frame, (640, 640)) outputs rknn.inference(inputs[img]) boxes, classes, scores post_process(outputs) health_alerts [c for c in classes if c in (1, 2, 3)] if len(health_alerts) 3: print(f[ALERT] {time.time():.3f}: {len(health_alerts)} abnormal targets)这段代码的坑在 inference 的输入预处理上。训练时 YOLOv5 会做 letterbox也就是等比缩放加灰条填充让不同宽高比的图片变成统一的 640×640。如果推理时直接 cv2.resize 拉伸目标框坐标会偏移精度直接崩掉。正确做法是把原图按比例缩放到一边等于 640、另一边不足 640 的部分用灰边填充推理后再把坐标按缩放比例映射回原图。我这里为了展示逻辑写成了直接 resize实际部署时必须实现完整的 letterbox 和反变换函数或者用 RKNN 工具链提供的 preprocess 接口。结构化输出的字段里置信度阈值建议设两个档位。过滤告警用 0.5确保误报率低保存统计计数用 0.3宁可多记录一些模糊目标给后端数据分析留余地。这个双阈值做法能显著减少养殖场管理人员对系统的信任度损耗。4.3 推流输入与断流重连的容错设计养殖场的摄像头走 RTSP 协议但现场网络环境经常不稳定断流重连是部署时必须处理的异常。YOLOv5 本身不管 RTSP 的拉流逻辑这部分要自己写。常见做法是封装一个独立的取流线程用 OpenCV 的 VideoCapture 拉流一旦读取失败就销毁当前 capture 并休眠 3 秒重连。实测 GPU 设备上重连时如果直接执行 cap cv2.VideoCapture(url) 而不释放旧对象内存会持续增长几小时后就 OOM 了。这个问题排查了很久最后定位是 RKNN 推理线程和拉流线程的资源没有隔离把拉流改成独立进程并用共享内存传帧问题才稳定解决。边缘设备上还要做好帧率控制。养殖场场景不需要全帧率检测检测频率设成每 2 秒一帧CPU 占用率会大幅下降而且健康状态本身是慢变化过程每秒 25 帧的检测结果绝大部分是重复的。控制方式是在取流后做时间戳判断距离上次检测不足 2 秒就直接丢弃当前帧。这个参数如果设成 5 秒对 lethargic 检测也足够但对外伤出血这种需要快速响应的场景不够建议默认 2 秒。5. 避坑养殖场肉鸡检测从训练到部署的 5 个常见问题与排查记录现象训练时 loss 正常下降但验证集 mAP 始终在 0.3 以下徘徊。原因标注框和图片尺寸不匹配标签 txt 里的坐标是归一化值但标注时误用了绝对像素值。YOLOv5 读取标签时会先做一次越界裁剪越界目标被直接忽略导致大量目标没参与训练。解决写一个检查脚本统计 labels 目录下每个 txt 文件里的坐标是否都在 0 到 1 之间同时对每个 class_id 做分布统计。排查后发现有 300 多张图的标签是绝对坐标重新标注后 mAP 提升到 0.7 以上。现象模型在测试集上精度不错现场部署后经常漏检白羽鸡。原因养殖场的白羽鸡在强光下过曝羽毛区域几乎全白没有纹理特征模型在训练时没见过这么强的过曝样本。测试集的图片大多是正常光照所以没有暴露这个问题。解决现场重新采集正午强光段的视频抽帧后做 gamma 校正和亮度增强作为额外的训练数据同时把训练集里亮度较高的图片单独抽出来做二次增强保证过曝样本占比不低于 10%。现象RKNN 量化后模型在边缘设备上推理结果和 PC 端差异巨大部分目标框偏移明显。原因量化校准图片选择不当200 张校准图全部来自同一光照时段导致量化参数偏向该时段的分布。解决校准图从三个时间段各选 70 张并且包含至少 20 张过曝和 20 张低照度图片覆盖率足够后量化精度基本恢复。教训是校准集组成比数量重要。现象部署后运行一段时间报错 numpy.core._exceptions._ArrayMemoryError进程崩溃。原因RKNN 推理返回的数组在每次调用时都会新建内存没有及时显式释放长时间运行后内存碎片化累积。解决在推理循环里对 outputs 使用后调用 del outputs 和 gc.collect()同时把检测结果只保留结构化字段不保存画了框的大数组。整改后内存占用稳定在 300MB 以内连续运行一周没有复现。现象多路摄像头并发推理时某一路画面卡死其余路正常。原因取流线程和推理线程之间没有设置超时保护某路 RTSP 网络抖动时VideoCapture.read() 阻塞不返回拖住整个线程池。解决给取流线程设置 socket 超时参数或者改用 OpenCV 的 CAP_PROP_OPEN_TIMEOUT_MSEC 和 CAP_PROP_READ_TIMEOUT_MSEC 设置延迟上限超时后自动断开重连。同时对每路摄像头配置独立的取流进程避免单路异常拖垮整体。6. 现场效果验收与再训练策略把检测结果做成养殖户看得懂的报表部署完成后先不要急着验收精度找一个长期驻场的养殖员聊需求。他们想要的不是“检测到 37 只异常鸡”这种数字而是“东侧鸡舍第 3 列区域需要人工巡检”这种能直接行动的信息。所以权重和数据集真正要支撑的是位置语义化检测框坐标落到鸡舍的物理分区把检测结果转成区域级别的告警。实现方式是把鸡舍平面图划分成若干区域每个区域对应固定的像素坐标范围推理框中心点落在哪个区域就归到哪个区域的统计。验证工作分三步走。第一步是离线准确率用新采集的独立视频段不参与训练跑一遍推理统计每类的精确率和召回率重点关注 lethargic 和 injured 两类两者漏检的代价远高于 healthy 误报。第二步是连续稳定性让系统在养殖场现场连续运行 24 小时记录每个小时的检测数波动正常情况下的波动范围应该小于 20%如果波动过大检查是不是光照切换时段导致的误检。第三步是业务一致性把系统检测的异常事件列表和养殖场的伤亡记录做对比排查有没有“漏报当晚死亡鸡只”这类关键事故——这里漏检往往不是因为模型精度不够而是因为死亡鸡只躺倒的姿态在训练集里没有出现过所以建议定期从现场补充视频并做增量训练。增量训练是权重维护的核心动作。养殖场的鸡群批次不同不同批次的羽毛颜色和白羽比例会有差异建议每一批新鸡进场后采集 200 到 300 张图片人工标注后加到训练集里用上一次的 best.pt 做增量训练。这个过程每次只需要跑 30 到 50 个 epoch我一般安排在夜间用现场边缘设备的空闲算力跑。本地部署的 RK3588 上做增量训练不现实比较稳妥的做法是把现场采集的图片定期回传到机房用 GPU 完成训练后再把新权重分发到各边缘节点。回头看我经手的这几个养殖场项目最容易让项目落地失败的往往不是模型精度而是前后端的期望落差。算法这边追求 mAP 涨点数养殖场那边只关心“这东西准不准、烦不烦”。权重和数据集不是一次性的交付物而是需要随养殖批次和生产节奏持续更新的资产。每隔一段时间我会把部署在现场的模型和半年前的版本做一次对比评测用同一段视频跑两边让养殖员自己看差异。当他们能从画面上感受到新模型确实更少误报、更稳的时候项目才算是真正扎下根了。希望这些从现场摸出来的经验能帮你少走几段弯路。本文还有配套的精品资源点击获取