箱子和托盘目标检测实战：从数据集清洗到YOLOv8部署全流程

简介：目标检测是计算机视觉的基础任务之一，广泛应用于工业自动化场景。在物流仓储领域，箱子和托盘的精准识别更是无人叉车、AGV及智能监控系统的公共前置模块。实际工程中，模型精度不仅依赖网络结构，更受数据质量与场景覆盖度的制约。面对光照不均、堆叠遮挡、类别不平衡等问题，如何高效清洗VOC格式标注、转换为YOLO训练所需格式，并按场景合理划分数据集，成为模型落地效果的关键。本文将围绕箱子和托盘检测这一典型场景，从数据集解读、质量验证、格式转换、模型训练到推理部署，完整梳理一条可复用的工程链路，帮助初学者与工程师避开常见坑点，快速构建稳定可靠的仓储视觉方案。 做无人叉车视觉避障那段时间，我被仓库里的一摞纸箱和一个蓝色托盘折腾得够呛。箱子和托盘这两类目标，单看谁都觉得简单，随便拉个检测模型都能跑，但等真正往仓库里一放，光照不均、箱子堆叠遮挡、纸箱颜色和地面几乎融为一体、托盘上的缠绕膜反射高光……这些场景能瞬间把一个“二分类检测”变成大型翻车现场。好在后面拿到了一份带标注的箱子和托盘目标检测数据集，从数据清洗、格式转换、模型训练到部署验证，把整个链路完整跑了一遍，踩了不少坑，也沉淀了不少心得。这篇就按实际操作顺序，把从拆开zip到模型上线的过程全部写出来，适合刚拿到数据集不知道从哪入手的初学者，也适合正在做物流仓储视觉项目的工程师参考。

1. 先解读数据集：箱子和托盘检测到底在解决什么问题

1.1 箱子和托盘在仓储自动化里的角色

很多人第一次听说“箱子和托盘目标检测”，第一反应是：这有什么好检测的？不就是两类目标吗？但真去物流仓库看一圈就明白了，这是整个仓储自动化里出现频率最高、也是需求量最大的感知需求之一。

托盘是整个物流环节中最标准的载具，几乎所有货物在运输、存储时都会先码放在托盘上。无人叉车要叉取货物，第一步就是识别托盘的位置和叉孔，检测框的准确度直接决定叉车能不能对准。而箱子是更细粒度的物流单元，DWS动态称重扫码系统要测量包裹体积，摆渡车避障、机械臂抓取、库位空满检测，都需要先定位箱子。再往外延伸，立体仓库的盘点机器人、AMR自主移动机器人，也需要识别箱子码放的边界和托盘是否在位。可以说，箱子和托盘检测是整个仓储物流自动化视觉方案里的“地基性”需求，不是针对某个特定场景的定制功能，而是很多上层应用的公共前置模块。

这类数据集的价值就在于它踩中了仓储领域最通用的感知场景。实际项目里，大家通常不会重新花几个月去采集标注一套托盘和箱子数据，拿到一份覆盖了不同仓库环境、不同拍摄角度、不同光照条件的数据集，在它基础上做二次清洗和模型微调，就能少走很多弯路。尤其是对无人叉车厂商、AGV厂商和做仓储监控的团队来说，这种基础数据集几乎是起步必备。

1.2 zip包里到底有什么：目录结构和数据规模

就数据集本身来说，解压zip之后，里面的目录结构大概率是这样：

pallet_box_dataset/ ├── images/ │ ├── warehouse_001_001.jpg │ ├── warehouse_001_002.jpg │ ├── warehouse_002_001.jpg │ └── ... └── annotations/ ├── warehouse_001_001.xml ├── warehouse_001_002.xml ├── warehouse_002_001.xml └── ...

图片和标注一一对应，文件名前缀相同，标注格式是VOC XML。图片数量在8000张左右，类别只有两个，我用英文简称的话就是box和pallet，分别对应箱子和托盘。这个规模在工业场景数据集中算中等偏实用：比学术实验用的几千张多不少，覆盖的场景多样性足够支撑真实项目，又不至于大到光传输和清洗就耗掉半天。

从场景角度看，这份数据集的多样性是它最值钱的地方。图片里包含了多个仓库环境，拍摄角度覆盖了平视、俯视和斜视，这很关键——因为无人叉车上的相机通常是平视或轻微俯视，而高位货架上的监控相机则是明显的俯视。光照条件也很多样，有白天自然光、仓库日光灯、逆光甚至夜间低照度，这一点在实际部署时尤为重要，很多模型白天精度很高，晚上或逆光环境就垮掉，往往是训练数据里光照多样性不够。另外箱子的状态也做了区分：单层、多层堆叠、带缠绕膜、不带缠绕膜，托盘则分了空托盘、载货托盘和带破损的托盘。

拿到zip之后的第一个建议是：先别急着解压训练，先看看压缩包的文件大小和下载说明里的校验值。很多人在解压时遇到“file is not a zip file”或者“could not find eocd”这类报错，其实就是zip文件没下载完整或者下载到的根本不是zip，这个问题我在后面专门有一节讲，千万别忽略。

2. 动手前先验证：数据质量决定了模型精度的上限

2.1 用脚本盘点类别分布和图片状态

很多初学者拿到数据集就开训，结果模型训练到一半发现loss异常，或者eval的时候mAP奇低，回头排查才发现是数据本身有问题。所以我强烈建议，解压后第一件事是给数据集做一次“体检”。

我用Python脚本快速统计了类别分布和图片基本信息，核心思路也就几十行代码，主要是三件事：确认所有图片能正常打开、统计每张图标注的box和pallet数量、记录图片的分辨率分布。下面是简化版脚本：

import os import cv2 import xml.etree.ElementTree as ET images_dir = "pallet_box_dataset/images" annotations_dir = "pallet_box_dataset/annotations" class_count = {"box": 0, "pallet": 0} img_with_ann = 0 error_list = [] for xml_name in os.listdir(annotations_dir): if not xml_name.endswith(".xml"): continue xml_path = os.path.join(annotations_dir, xml_name) img_name = xml_name.replace(".xml", ".jpg") img_path = os.path.join(images_dir, img_name) # 检查图片是否可读 img = cv2.imread(img_path) if img is None: error_list.append(f"图片无法读取: {img_path}") continue # 统计标注类别 tree = ET.parse(xml_path) root = tree.getroot() for obj in root.iter("object"): cls = obj.find("name").text if cls in class_count: class_count[cls] += 1 # 统计有标注的图片数（即非空标注） objs = list(root.iter("object")) if objs: img_with_ann += 1 print("类别统计:", class_count) print("有标注图片数:", img_with_ann) print("错误列表:", error_list[:10])

我跑完之后发现两个问题：第一，box和pallet的标注数量差距悬殊，box标注数量将近两万多个，pallet只有三千多个，存在明显的类别不平衡；第二，有一小部分图片因为文件头损坏无法正常读取，需要单独清理掉。

关于类别不平衡，后面训练配置里要专门处理，不能无视。如果直接用原始分布去训，模型会偏向数量多的box类别，pallet的召回率会明显偏低——托盘漏检在无人叉车项目里是非常危险的，叉车没识别到托盘继续前进或者叉空，都会造成事故。

2.2 可视化验证：把标注画到原图上

统计类别只是第一步，更直观的验证方式是把标注框画到原图上，用眼睛看一遍。这一步很多人会跳过，但我建议至少抽查几百张。代码很简单：

import cv2 import xml.etree.ElementTree as ET def draw_annotations(img_path, xml_path, output_dir): img = cv2.imread(img_path) tree = ET.parse(xml_path) root = tree.getroot() colors = {"box": (0, 255, 0), "pallet": (0, 0, 255)} for obj in root.iter("object"): cls = obj.find("name").text bndbox = obj.find("bndbox") xmin = int(float(bndbox.find("xmin").text)) ymin = int(float(bndbox.find("ymin").text)) xmax = int(float(bndbox.find("xmax").text)) ymax = int(float(bndbox.find("ymax").text)) cv2.rectangle(img, (xmin, ymin), (xmax, ymax), colors.get(cls, (255, 0, 0)), 2) cv2.putText(img, cls, (xmin, ymin - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.6, colors.get(cls, (255, 0, 0)), 2) out_path = os.path.join(output_dir, os.path.basename(img_path)) cv2.imwrite(out_path, img)

肉眼检查时重点关注这么几类问题：

• 标注框是否和物体边缘贴合：框明显偏大或偏小都会对训练造成干扰，偏大导致模型学到过多背景，偏小导致模型漏掉物体的边缘特征。
• 是否有阻挡严重但没标注的目标：这在堆叠场景里很常见，后面的箱子被前面的挡住一大半，有的标注员会标整箱，有的只标可见部分。这种标注规则不一致会让模型训得很纠结。
• 是否有类别混标：比如把未拆塑料包装的托盘标成了box，或者把箱子堆整体标成pallet。这些错标样本量少的时候影响不大，多了就会把精度拉下来。

我在抽查的时候发现，部分图片中远处小尺度的托盘并没有被标注，这是因为标注规范里可能规定了“疑似目标不标”或者“过小目标不标”，这种规则本身没毛病，但如果训练图片里大量存在未标注的漏检目标，模型会误把“没标”当成“背景”，到了推理阶段，真正检测到这些目标时反而会被抑制掉。

2.3 必须处理的坐标异常与脏数据

VOC格式标注里最常见的数值问题集中在bndbox这四个坐标上。可能出现的情况包括：xmin和ymin是负数、xmax和ymax超出图片宽高、甚至xmin大于xmax这种逻辑错误。这些异常如果在训练前不清理，轻则拉低收敛速度，重则训练时直接报错。

我在清洗时写了一个过滤逻辑：

import os import xml.etree.ElementTree as ET def check_and_fix_xml(xml_path, img_w, img_h): tree = ET.parse(xml_path) root = tree.getroot() for obj in root.iter("object"): bndbox = obj.find("bndbox") xmin = float(bndbox.find("xmin").text) ymin = float(bndbox.find("ymin").text) xmax = float(bndbox.find("xmax").text) ymax = float(bndbox.find("ymax").text) # 越界修复 xmin = max(0, min(xmin, img_w - 1)) ymin = max(0, min(ymin, img_h - 1)) xmax = max(0, min(xmax, img_w - 1)) ymax = max(0, min(ymax, img_h - 1)) # 如果修复后宽高为0，跳过该目标 if xmax - xmin < 1 or ymax - ymin < 1: root.remove(obj) continue # 回写 bndbox.find("xmin").text = str(xmin) bndbox.find("ymin").text = str(ymin) bndbox.find("xmax").text = str(xmax) bndbox.find("ymax").text = str(ymax) tree.write(xml_path, encoding="utf-8")

这里我做了两件事：把越界坐标截断到图片边界内，并移除宽高小于1像素的无效目标。截断而不是直接删除，是因为很多目标只是标注时手滑超出边界几像素，完全删掉反而损失信息。截断操作本身不影响模型学习真实目标的位置分布。

多提一句，torchvision在读取标注时如果遇到超出图像的框，会在计算loss时因为目标框面积算出负数而产生NaN，排查起来很麻烦。所以这种数据清洗工作，宁可在训练前多花半小时，也别在训练报错之后才回头找原因。

3. 格式转换与数据划分：让数据集适配YOLOv8

3.1 VOC、COCO、YOLO三种标注格式怎么选

拿到手的数据集是VOC XML格式，而主流目标检测训练框架里，YOLO系列需要的是txt格式，Detectron2和MMDetection常用COCO JSON格式。三种格式的差异可以简单概括：

我最后选择了YOLO txt格式，原因很直接：YOLOv8是目前工业项目里部署最方便、社区资料最多、训练成本也相对低的方案，而YOLO系列框架原生支持txt格式，不需要再依赖任何中间层。另外txt格式一个图片对应一个文件，增删样本很方便，不像COCO那样所有标注堆在同一个JSON里，加一行数据就要重新dump整个文件。

如果你是做学术对比实验，或者后续要对比Mask R-CNN这类实例分割模型，那转成COCO格式更合理；但在物流仓储场景的实际落地里，YOLO+txt几乎就是默认选择。

3.2 VOC转YOLO格式的完整脚本

转换的核心逻辑就是从XML里读出目标框的绝对坐标，再除以图片宽高得到归一化坐标，最后按“类别id 中心x 中心y 宽 高”的格式写入txt文件。下面这个脚本可以直接抄：

import os import xml.etree.ElementTree as ET # 类别顺序即类别id，必须固定 CLASSES = ["box", "pallet"] def voc_to_yolo(xml_path, output_label_path, image_w, image_h): tree = ET.parse(xml_path) root = tree.getroot() lines = [] for obj in root.iter("object"): cls_name = obj.find("name").text if cls_name not in CLASSES: print(f"未知类别 {cls_name} 跳过") continue cls_id = CLASSES.index(cls_name) bndbox = obj.find("bndbox") xmin = float(bndbox.find("xmin").text) ymin = float(bndbox.find("ymin").text) xmax = float(bndbox.find("xmax").text) ymax = float(bndbox.find("ymax").text) # 转成归一化中心坐标 + 宽高 x_center = (xmin + xmax) / 2.0 / image_w y_center = (ymin + ymax) / 2.0 / image_h width = (xmax - xmin) / image_w height = (ymax - ymin) / image_h # 防止归一化后出现0或1边界值 x_center = min(max(x_center, 0.0), 1.0) y_center = min(max(y_center, 0.0), 1.0) width = min(max(width, 0.0), 1.0) height = min(max(height, 0.0), 1.0) lines.append(f"{cls_id} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}") with open(output_label_path, "w") as f: f.write("\n".join(lines))

注意一个关键点：转换时必须知道图片的真实宽高。如果某些XML里没有size节点，需要直接用cv2去读图片拿到实际的宽高。我遇到过一个仓库的部分XML里没有写size节点，如果统一用默认宽高算，所有标注框位置都会偏。所以更稳妥的做法是用图片本身的分辨率来做归一化，而不是相信XML里写的size字段。

最后把转换好的txt按下面的目录结构放好：

datasets/ └── pallet_box/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ └── labels/ ├── train/ ├── val/ └── test/

这是YOLO系列约定的标准结构，images和labels下一级必须同名，否则训练时找不到对应的标注文件。

3.3 按场景切分，避免验证集泄漏

数据切分看起来是个小事，实际上对模型评估的影响非常大。很多人在这一步图省事，直接对整个数据集做随机8:1:1切分。但如果这份数据集是从视频逐帧抽取的，或者同一个仓库场景连续拍了多张，相邻帧之间高度相似，随机切分就会导致训练集和验证集之间出现内容重叠，也就是所谓的验证集泄漏（val leak）。

验证集泄漏的典型表现是：训练时验证精度非常高，loss曲线也下降得很好，但一到真实场景测试就大幅缩水。原因很简单，模型“见过”了验证集里目标的背景和纹理，评估结果虚高，不能反映真实泛化能力。

我采用的切分策略是按仓库场景或者拍摄批次进行分组，比如把warehouse_001和warehouse_002的所有图片整体放进训练集，warehouse_003整体放进验证集。这样验证集里出现的场景是模型训练时完全没见过的，得到的mAP才有参考价值。

具体的切分脚本可以用一张表来维护：

如果数据集本身没有按仓库分组的前缀，那我建议你通过图片文件名或者EXIF里的拍摄时间做分组，实在不行再按文件名哈希取模来分组，保证同一个时间段连续采集的图片不会散落在两个集合里。

4. 训练配置与参数调优：把精度跑上去

4.1 环境准备与训练启动

训练环境我用的就是最常规的组合：Python 3.10、PyTorch 2.x、Ultralytics YOLOv8。安装一句话就搞定：

pip install ultralytics

显卡方面，这张数据集用一张8G显存左右的卡就能玩得转，yolov8s模型在batch_size=16、imgsz=640的情况下大概需要6G左右显存，如果你的显卡显存比较小，可以把batch降到8或者用yolov8n打底。

训练前需要写一个data.yaml文件，指定数据集路径和类别信息：

# data.yaml train: datasets/pallet_box/images/train val: datasets/pallet_box/images/val test: datasets/pallet_box/images/test nc: 2 names: ['box', 'pallet']

然后启动训练：

yolo detect train data=data.yaml model=yolov8s.pt epochs=100 imgsz=640 batch=16 device=0

这一步如果不出意外，跑完100个epoch大概需要几个小时，具体时长取决于显卡型号和图片数量。第一次跑的时候建议别直接上yolov8x，先用s模型把整套流程跑通，确认数据没问题之后，再根据精度需求决定要不要换更大的模型。

4.2 关键超参数和类别不平衡处理

先说我实际用下来比较稳的一组超参数组合：

关于imgsz的选择，有一点要说明：如果仓库相机安装得比较高，画面里的箱子普遍很小，640的分辨率可能不足以保留小目标的特征，这时可以考虑用896甚至1280训练，代价是训练时间和显存明显上升。我在实际项目里如果遇到DWS那种60cm高箱子在2米外拍到的场景，一般会先试640，如果小目标漏检严重再升分辨率。

类别不均衡是这份数据集的另一个核心问题。box和pallet的实例数量差别很大，如果不做任何处理，模型会偏向检测样本量大的box。实际做法有两种：一是给pallet类别增加损失权重，让模型对pallet的误检更敏感；二是在数据层面做过采样，也就是让包含pallet的图片在每轮训练里多次出现。YOLOv8官方没暴露太细的类别权重参数，所以我更倾向于用第二种方式，在制作训练集时把包含pallet的图片复制一到两份进训练目录，简单粗暴但很有效。

还有一个小技巧是关闭或修改mosaic增强。YOLOv8默认开了Mosaic，就是把四张图拼成一张，这对丰富背景多样性很有帮助，但在托盘检测这种需要精确定位的任务里，Mosaic拼接会导致目标被切断，尤其是托盘出现在两张图的拼接边界时，标注框会被截到只剩一半。如果训练过程中发现pallet的框总是偏小或者定位不精确，可以试试把mosaic关闭，或者只在训练后期关闭（YOLOv8本身有close_mosaic参数），让模型在最后阶段专注于学习完整目标。

4.3 训练过程监控：loss和mAP怎么看

训练启动后，YOLOv8会自动在runs/detect/train目录下生成训练日志和曲线图。我一般只看三个文件：results.png、confusion_matrix.png、以及训练结束后自动保存的best.pt和last.pt。

results.png里包含了box_loss、cls_loss、dfl_loss以及precision、recall、mAP50、mAP50-95这几个关键指标的曲线。关注点主要有两个：第一，验证集loss在训练后期是否还在下降，如果验证集loss开始回升而训练集loss还在降，基本就是过拟合，可以考虑早停或者加强数据增强；第二，mAP50是否达到了可接受的水平。

对于箱子和托盘这种两种类别的检测，在场景差异较大的评估集上，mAP50至少应该到0.85以上才算合格，mAP50-95能到0.7左右就说明模型泛化能力不错了。如果mAP50-95远低于0.6，优先怀疑两个方向：标注本身是否存在大量不一致，或者数据划分时出现了场景偏差导致验证集过于困难。

我在训练过程中还习惯看一眼confusion_matrix.png，重点确认pallet类别有没有被大量误判成box。如果误判很严重，说明两个类别在视觉特征上存在混淆，通常是因为托盘上堆满箱子时，模型看到的主体其实是箱子堆而不是托盘结构，这时就要考虑是不是某些标注把载货托盘的整体框标得太大了。

5. 推理验证与踩坑实录

5.1 推理验证与置信度调优

训练结束后，先用测试集对best.pt做一次推理，看看实际效果：

yolo detect predict model=runs/detect/train/weights/best.pt source=datasets/pallet_box/images/test save=True

测试集是训练时完全没见过的仓库场景，出来的效果才有参考价值。推理结果默认会保存到runs/detect/predict目录下，我在人工检查时主要看三类情况：漏检、误检和重复框。

重复框问题可以通过调节NMS的iou阈值来控制，YOLOv8默认是0.7。如果发现同一个目标被框了两次，可以稍微下调到0.6；如果发现两个挨得很近的真实目标被合并成一个框，就上调到0.75左右。不过这类问题对最终精度影响没那么大，更重要的是置信度阈值的选择。

我实际测试下来，仓储场景的置信度阈值要根据用途定。如果只是做库位空满检测或者区域监控，conf设0.35左右可以减少误报；但如果做无人叉车托盘对准，宁可多检几个候选框让上层去判断，也别把置信度抬太高导致漏检。我做叉车项目时conf会放到0.2甚至0.15，再通过后续的叉孔几何校验来过滤假目标，这样真实召回率是最稳的。

5.2 高频问题速查：从zip损坏到推理偏差

这个数据集相关的报错和问题，我在整个流程里遇见不少，这里整理一个速查表，方便大家直接对照排查：

关于zip文件损坏这里多说两句。“could not find eocd”里的EOCD是End of Central Directory Record，位于zip文件的最末尾，相当于整个压缩包的目录索引。解压工具先读文件末尾的EOCD，才能知道里面有哪些文件以及各自的位置。如果文件下载不完整，尾部记录缺失，解压工具就会直接报这个错。这种情况最容易出现在网络不稳定的环境下，比如用浏览器默认下载器下载大文件时中途断线但下载器没报错。

我自己的处理习惯是：下载数据集后先对照下载页给的SHA256或文件大小，确认无误再解压。如果下载页面没提供校验信息，就用sha256sum data.zip算一下并记录，先把大文件校验这一步养成习惯，能省掉很多和文件损坏纠缠的时间。

还有一个容易被骗过的情况：从网盘或者GitHub下载URL拿到的东西，文件名叫xxx.zip，但用file命令一看是HTML document，这就是下载到了跳转页或错误页。这种时候别想着修复，直接重新获取正确的下载链接才是正路。

5.3 部署时容易被忽略的细节

模型训练完成不代表就万事大吉。从测试集推理到实际部署，中间还有几个细节值得留意。

第一个是模型导出。YOLOv8训练出来的是PyTorch权重，部署到边缘设备时通常需要转成ONNX或TensorRT格式。导出命令很简单：

yolo export model=runs/detect/train/weights/best.pt format=onnx imgsz=640 yolo export model=runs/detect/train/weights/best.pt format=engine device=0

转成TensorRT engine之后，模型在Jetson这类边缘设备上的推理速度可以提升一个档次，很多场景能直接跑到实时。如果部署的相机是固定角度，建议你导出模型时保留原训练分辨率，不要在推理时随意缩放，否则小目标精度会下降。

第二个是输入图像的预处理。仓库相机的视频流往往直接用来做画面显示和录像，分辨率可能是1920x1080，但模型输入是640x640。YOLOv8会自动做letterbox填充，也就是等比缩放并填充灰边，这个没问题。但如果你在推理管线的前面自己做了resize，没有保持宽高比，那目标会变形，检测框精度也会跟着下降。

第三个是ROI裁剪。这一点在无人叉车项目里特别实用。叉车的相机安装角度和位置是固定的，托盘只会出现在画面中下部的一块区域，就没必要把整张图输入模型，可以先用一个固定ROI把画面裁出来再送检。模型只在高概率区域搜索，误检和漏检都会减少，推理时间也明显缩短。

第四个是标注框后续使用的扩展。如果检测结果要对接机械臂抓取或叉车叉取，检测框只给出了目标的大致范围，机械臂末端需要的是托盘的中心点和叉孔位置，这时候可以在检测框的基础上做几何计算，比如根据托盘的先验尺寸推算叉孔区域。不过这个已经超出目标检测数据集本身的范畴了，属于上层应用逻辑，但我在做项目时发现很多人对这一步预期过高，以为检测框出来就能直接抓取，实际还是需要做不少后处理的。

最后分享一个我个人的小技巧：训练结束之后，别只看mAP指标，把模型在真实仓库拍的一段视频上跑一轮，逐帧检查一下。很多模型在图像测试集上指标很好，但放到连续视频流上就会出现目标抖动、闪烁、或者相邻帧检测结果不稳定。出现这种问题，通常不是模型结构的问题，而是置信度阈值设置和NMS策略的取舍问题。把阈值适当调低，配合跟踪算法做时间维度的平滑，效果会比盲目追求单帧精度好很多。

我在完成这份数据集的实际训练之后，最大的感受是：数据集的干净程度和场景覆盖度，对最终模型的影响往往比换更大的模型结构更明显。箱子和托盘检测本身不是高难度的学术问题，它的难点几乎全在真实场景的多样性上——光照、遮挡、堆叠、不同状态的托盘、不同材质的箱子。这些细节处理到位了，一个中等规模的模型就足够稳定，而那才是物流自动化项目里真正需要的东西。

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