智能分拣机器人如何做工程验证：测试数据模型、异常分层与回归策略

机器人完成一次抓取，并不代表系统已经具备工程稳定性。真正可验证的机器人系统，需要能够说明每一步发生了什么、为什么失败、修改后是否改善，以及测试结果能否被重复验证。

前言

我叫张智博，就读于石家庄邮电职业技术学院。

本文来自我参与“供件达人——快递分拣智能供件先锋”相关项目推进、测试流程整理和验证记录建设时的一次工程复盘。

机器人项目最容易展示的是“成功的一次”。

机械臂识别包裹、完成抓取并放到指定位置，几秒钟的视频就可以让人直观看到结果。

但当项目进入工程验证阶段后，真正需要回答的不是“它能不能动”，而是：

• 哪一步成功，哪一步失败；
• 什么条件下更容易失败；
• 连续运行后是否出现性能退化；
• 修改算法或结构后是否真的改善；
• 测试结果能否被其他人复现。

因此，机器人测试不能只保留最终的“成功或失败”，而应建立完整的阶段事件和环境上下文。

---

一、先把一次任务拆成状态机

一次完整的分拣任务可以抽象为：

CREATED
→ DETECTED
→ LOCATED
→ GRASPED
→ TRANSFERRED
→ PLACED
→ COMPLETED

任何阶段都可能进入失败状态：

DETECTION_FAILED
LOCATION_FAILED
GRASP_FAILED
TRANSFER_FAILED
PLACEMENT_FAILED
SAFETY_ABORTED

这样拆分以后，系统不再只有一个模糊的“任务失败”，而是可以回答：

检测是否成功
定位是否成功
夹具是否闭合
物体是否稳定抬起
搬运中是否掉落
放置是否到位

---

二、测试记录不能只有一个布尔值

简化的数据结构如下：

from dataclasses import dataclass
from enum import StrEnum


class Stage(StrEnum):
    CREATED = "created"
    DETECTED = "detected"
    LOCATED = "located"
    GRASPED = "grasped"
    TRANSFERRED = "transferred"
    PLACED = "placed"
    COMPLETED = "completed"
    FAILED = "failed"


@dataclass
class SortingTestRecord:
    run_id: str
    package_type: str
    package_size: str
    surface_material: str
    pose_type: str

    detection_success: bool
    localization_success: bool
    grasp_success: bool
    transfer_success: bool
    placement_success: bool

    total_duration_ms: int
    failed_stage: str | None
    error_code: str | None
    notes: str | None

这里特意保留了包裹类型、尺寸、表面材质和姿态。

因为脱离测试条件的“成功率”信息非常有限。

例如，系统整体表现下降，可能不是算法突然失效，而是本轮测试增加了更多：

• 软包装；
• 反光表面；
• 不规则姿态；
• 边缘遮挡；
• 堆叠物体。

---

三、建立测试矩阵，而不是随机拿几个包裹

测试样本可以按多个维度组合：

维度	示例
尺寸	小型、中型、大型
材质	纸箱、塑料袋、软包装
重量	轻、中、重
姿态	正放、侧放、倾斜
遮挡	无遮挡、部分遮挡
位置	中心、边缘、角落
运行阶段	冷启动、连续运行

测试矩阵不一定要穷举全部组合，但需要明确覆盖原则。

TEST_CASES = [
    {
        "package_type": "box",
        "package_size": "small",
        "surface_material": "cardboard",
        "pose_type": "upright",
    },
    {
        "package_type": "soft_bag",
        "package_size": "medium",
        "surface_material": "plastic",
        "pose_type": "tilted",
    },
]

比起“今天随便测试了一百次”，分层样本更容易定位问题。

---

四、错误码必须对应可执行的排查方向

错误码不应该只是：

E001：任务失败

更有价值的异常体系可以分层：

VISION_*
LOCALIZATION_*
GRIPPER_*
MOTION_*
PLACEMENT_*
SAFETY_*
SYSTEM_*

示例：

ERROR_MESSAGES = {
    "VISION_NO_TARGET":
        "未检测到有效目标",

    "VISION_LOW_CONFIDENCE":
        "目标置信度低于阈值",

    "LOCALIZATION_OUT_OF_RANGE":
        "位姿超出可达范围",

    "GRIPPER_NO_CONTACT":
        "夹具闭合后未检测到有效接触",

    "GRIPPER_SLIP":
        "抬升阶段检测到滑落",

    "MOTION_TIMEOUT":
        "运动规划或执行超时",

    "PLACEMENT_OFFSET":
        "放置位置偏差超过阈值",

    "SAFETY_ESTOP":
        "安全急停触发",
}

一个好的错误码至少应回答：

失败发生在哪一层
是否可以自动恢复
是否需要人工介入
下次回归应重点覆盖什么

---

五、计算分阶段指标，而不是只看最终成功率

假设一次任务包含五个核心阶段，可以分别计算：

检测成功率
定位成功率
抓取成功率
搬运成功率
放置成功率
端到端成功率

def safe_rate(
    success_count: int,
    total_count: int,
) -> float:
    if total_count == 0:
        return 0.0

    return success_count / total_count


def calculate_stage_metrics(
    records: list[SortingTestRecord],
) -> dict:
    total = len(records)

    return {
        "detection_rate": safe_rate(
            sum(
                record.detection_success
                for record in records
            ),
            total,
        ),
        "localization_rate": safe_rate(
            sum(
                record.localization_success
                for record in records
            ),
            total,
        ),
        "grasp_rate": safe_rate(
            sum(
                record.grasp_success
                for record in records
            ),
            total,
        ),
        "transfer_rate": safe_rate(
            sum(
                record.transfer_success
                for record in records
            ),
            total,
        ),
        "placement_rate": safe_rate(
            sum(
                record.placement_success
                for record in records
            ),
            total,
        ),
    }

如果检测成功率稳定，但抓取率下降，就应该重点排查夹具、接触点和抓取策略，而不是盲目调整识别模型。

---

六、事件时间线可以定位“慢在哪里”

除了成功与失败，每个阶段还应记录时间。

CREATE TABLE test_events (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    run_id TEXT NOT NULL,
    stage TEXT NOT NULL,
    event_type TEXT NOT NULL,
    event_time TEXT NOT NULL,
    duration_ms INTEGER,
    error_code TEXT,
    payload_json TEXT
);

事件示例：

09:00:01.120  DETECTED
09:00:01.280  LOCATED
09:00:02.450  GRASPED
09:00:03.800  TRANSFERRED
09:00:04.160  PLACED

有了阶段耗时，可以区分：

• 识别变慢；
• 路径规划变慢；
• 机械动作变慢；
• 异常重试导致总时长增加。

---

七、连续运行测试不能只记录最后结果

连续运行的目标不是简单增加测试次数，而是观察随时间变化的趋势。

建议记录：

运行序号
累计运行时间
阶段耗时
成功状态
异常类型
设备状态
人工干预次数
恢复耗时

可以按窗口观察失败率：

def rolling_failure_rate(
    values: list[bool],
    window_size: int,
) -> list[float]:
    rates: list[float] = []

    for index in range(len(values)):
        start = max(
            0,
            index - window_size + 1,
        )

        window = values[
            start:index + 1
        ]

        failures = sum(
            not value
            for value in window
        )

        rates.append(
            failures / len(window)
        )

    return rates

当失败率在连续运行后逐渐升高时，可能需要排查：

• 机械部件松动；
• 夹具表面磨损；
• 相机位置偏移；
• 温度变化；
• 缓存或内存增长；
• 通信延迟累积。

---

八、回归测试必须固定基线样本

修改识别模型、抓取参数或机械结构后，需要重新测试。

但如果前后使用的样本完全不同，结果就无法比较。

因此应保留一组固定基线：

基础纸箱样本
软包装样本
倾斜姿态样本
边缘位置样本
历史高频失败样本

每次重要修改后，先跑固定基线，再扩展到随机样本。

回归结果至少包括：

版本号
提交哈希
配置版本
测试样本集版本
各阶段指标
失败用例
与上一版本的变化

---

九、测试记录应该与代码版本关联

同一套机器人代码，在不同参数和模型版本下可能表现不同。

测试记录中应加入：

from dataclasses import dataclass


@dataclass
class RuntimeVersion:
    software_commit: str
    model_version: str
    config_version: str
    hardware_revision: str

最终每条测试数据都能回答：

哪一个代码版本
哪一个模型版本
哪一套参数
哪一版硬件
在什么样本上
产生了什么结果

这才具备真正的可复现性。

---

十、测试报告应保存失败样本，而不是只展示成功结果

失败样本通常比成功样本更有价值。

建议每次失败保留：

原始图像
识别框或分割结果
目标位姿
抓取点
错误码
设备状态
运行日志
人工备注

文件目录可以按运行批次组织：

runs/
└── 2026-07-18-batch-001/
    ├── metadata.json
    ├── success/
    └── failure/
        └── run-00034/
            ├── source.jpg
            ├── detection.jpg
            ├── result.json
            └── runtime.log

这样修改算法后，可以直接使用历史失败样本做回归。

---

十一、总结

机器人项目从演示走向工程验证，关键变化是：

从一次结果
→ 变成阶段事件

从随机测试
→ 变成测试矩阵

从任务失败
→ 变成异常分层

从最终数字
→ 变成版本化回归

从口头结论
→ 变成结构化记录

我在智能分拣项目中逐渐认识到，测试并不是项目完成后的附加步骤，而是连接问题、修改和结果的核心系统。

一个能够稳定运行的机器人，不只是“抓到了”，还应该能够说明它在什么条件下抓到、为什么失败、修改后改善了什么，以及这些结论能否被重复验证。

---

关于作者

张智博，石家庄邮电职业技术学院学生，参与过智能分拣、产品设计、网站建设和工程化实践，主要关注 AI 工具应用、项目运营与测试验证。

个人作品集：张智博的思考空间

个人官网：https://www.zzb9.cn

GitHub：https://github.com/zzb99