2、基础知识：机器人AI系统的基本架构、感知-决策-执行闭环、验收测试与开发测试的区别
在进入机器人AI验收测试的具体指标（识别率、响应速度、动作稳定性）之前，必须先建立一套共同的语言框架。如果对机器人AI系统的内部结构、数据流向以及测试阶段划分缺乏清晰认知，后续讨论“识别率阈值设定”或“响应延迟容忍度”时，极易陷入“盲人摸象”的困境。本章将系统梳理机器人AI系统的三大核心支柱：基本架构、感知-决策-执行闭环，以及验收测试与开发测试的本质区别。这不仅是测试工程师的必修课，也是项目经理、产品经理与甲方验收人员对齐预期的基础。
2.1 机器人AI系统的三层基本架构
现代机器人AI系统虽然形态各异——从工业机械臂到自主移动机器人（AMR），从人形机器人到医疗手术机器人——但其软件与算法架构普遍遵循“三层分离”原则：感知层、决策层、执行层。这种分层设计并非偶然，而是源于对系统复杂性、故障隔离和迭代效率的工程考量。
感知层（Perception Layer）负责将物理世界的原始信号转换为结构化信息。它包含视觉传感器（RGB相机、深度相机）、激光雷达、毫米波雷达、超声波传感器、触觉传感器以及惯性测量单元（IMU）等。感知层不仅涉及硬件驱动，更关键的是算法处理：目标检测（YOLO、Transformer-based模型）、语义分割、点云配准、SLAM（同步定位与建图）、姿态估计等。在验收测试中，感知层的核心关注点是识别率——即在特定光照、遮挡、动态干扰下，系统能否准确输出目标物体的类别、位置和置信度。
决策层（Decision Layer）是机器人的“大脑”，负责根据感知信息做出行动规划。它包含全局路径规划（如A*、Dijkstra）、局部避障规划（如DWA、TEB）、行为状态机、任务调度逻辑，以及近年来引入的大语言模型（LLM）或多模态模型用于高层语义理解。决策层的输出通常是运动指令序列或目标位姿。在验收测试中，决策层的核心关注点是响应速度——从感知数据输入到决策指令输出的端到端延迟，以及决策逻辑在边界条件下的正确性。
执行层（Execution Layer）将决策指令转化为物理动作。它包含电机驱动器、伺服控制器、减速器、编码器反馈回路，以及力/力矩传感器。执行层涉及底层控制算法（PID、模型预测控制MPC、阻抗控制）和硬件接口。在验收测试中，执行层的核心关注点是动作稳定性——包括重复定位精度、轨迹跟踪误差、超调量、稳态误差以及长时间运行后的温漂和机械磨损影响。
2.2 感知-决策-执行闭环：数据流与反馈机制
机器人AI系统不是单向的“感知→决策→执行”流水线，而是一个带有反馈的闭环系统。这个闭环包含两个层次：大闭环（任务级）和小闭环（控制级）。
大闭环的典型流程如下：
- 环境感知：传感器采集原始数据，经过预处理和特征提取，形成环境模型（如占据栅格地图、目标列表）。
- 状态估计：结合IMU、里程计和视觉/激光数据，通过卡尔曼滤波或因子图优化，估计机器人当前位姿。
- 任务决策：根据当前状态和目标，决策层生成下一步动作序列（如“移动到A点，抓取B物体”）。
- 运动规划：生成无碰撞轨迹，包含时间戳和速度约束。
- 底层执行：伺服控制器跟踪轨迹，电机输出力矩。
- 反馈修正：编码器反馈实际位置，视觉伺服（Visual Servoing）检测目标偏移，实时修正轨迹。
小闭环则存在于执行层内部：电机驱动器以1kHz-10kHz的频率读取编码器，计算位置误差，通过PID控制器输出PWM信号。这个闭环的稳定性直接决定了动作稳定性。
| 闭环层级 | 典型频率 | 主要传感器 | 失效后果 |
|---|---|---|---|
| 电流环 | 10-20 kHz | 霍尔传感器/采样电阻 | 电机过流烧毁、力矩波动 |
| 速度环 | 1-5 kHz | 编码器 | 速度振荡、运行不平顺 |
| 位置环 | 100-500 Hz | 编码器/外部视觉 | 定位偏差、轨迹跟踪失败 |
| 任务级闭环 | 10-50 Hz | 相机/LiDAR/力传感器 | 任务失败、碰撞风险 |
在验收测试中，理解闭环的意义在于：识别率、响应速度和动作稳定性三者之间存在强耦合关系。例如，视觉识别率下降会导致决策层等待更长时间（增加响应延迟），或者输出错误目标位置（导致执行层动作偏差）。因此，验收测试不能孤立地测试单一指标，而应设计端到端的联合测试场景。
2.3 验收测试与开发测试的本质区别
许多团队在项目交付时，将开发阶段的测试报告直接作为验收依据，这是典型的误区。验收测试（Acceptance Testing）与开发测试（Development Testing）在目标、环境、执行者和通过标准上存在本质差异。
开发测试是研发团队内部的质量保障活动，目的是发现缺陷、验证算法正确性、回归验证新功能。它通常在仿真环境、实验室或受控场地进行，测试用例由开发人员编写，关注的是“功能是否实现”和“算法是否收敛”。开发测试允许失败，允许反复调试，测试数据可以反复使用。
验收测试是用户或第三方机构对系统进行的正式评估，目的是确认系统是否满足合同规定的技术指标和业务需求。它必须在真实或接近真实的环境中进行，测试用例基于用户需求文档和验收标准，执行者通常是独立的测试团队或用户代表。验收测试的结果直接决定项目是否通过、是否付款、是否进入质保期。
| 对比维度 | 开发测试 | 验收测试 |
|---|---|---|
| 核心目标 | 发现缺陷、迭代优化 | 验证符合度、决定接收 |
| 测试环境 | 仿真、实验室、受控场地 | 真实场景、用户现场 |
| 测试用例来源 | 开发人员设计 | 需求规格书、合同条款 |
| 执行者 | 研发工程师 | 用户代表/第三方检测机构 |
| 失败处理 | 允许失败，修复后重测 | 记录缺陷，限期整改后复验 |
| 通过标准 | 功能完成度、覆盖率 | 量化指标（识别率≥99%、延迟≤200ms） |
| 时间约束 | 弹性，随迭代调整 | 严格，按合同节点执行 |
一个典型的验收测试流程包括：测试准备（确认测试环境、校准设备、准备测试物料）→ 预测试（双方确认测试方法）→ 正式测试（按测试用例逐项执行，记录数据）→ 结果评审（判定是否通过，出具验收报告）→ 缺陷整改（如有不通过项，开发方限期修复）→ 回归测试（对修复项重新测试）。
2.4 案例拆解：某仓储AMR项目的验收测试准备
为帮助理解上述概念，我们拆解一个实际案例：某电商仓储项目采购了20台自主移动机器人（AMR），用于货架搬运。合同规定验收指标为：托盘识别率≥99.5%（光照200-800 lux，距离0.5-3米），任务响应时间≤300ms（从下发指令到机器人开始移动），重复定位精度±10mm。
初始现象与目标：开发团队在仿真环境中测试，识别率99.8%，响应时间250ms，定位精度±8mm，均满足指标。但甲方要求在现场仓库进行验收测试，仓库存在以下干扰：高位货架造成部分区域光照不均（100-1500 lux）、地面有反光标识线、部分托盘存在轻微变形。
关键输入数据与测试设计：验收团队设计了三个测试场景：
- 场景A（标准通道）：光照均匀，托盘标准，测试50次识别和抓取。
- 场景B（低光照角落）：光照约120 lux，托盘有轻微油污，测试30次。
- 场景C（动态干扰）：通道内有叉车经过，测试20次响应时间。
分析判断过程：预测试发现，场景B中识别率仅97.2%，低于合同指标。进一步分析日志发现，感知层在低光照下对托盘边缘的置信度阈值设置过高（0.85），导致部分低质量图像被过滤。决策层等待感知结果超时（500ms），触发了重试机制，进一步增加了响应时间。
实际操作步骤：开发团队调整了感知算法——将置信度阈值降至0.75，并增加了基于深度图像的边缘增强预处理。同时，决策层增加了“感知超时降级策略”：当感知结果置信度在0.7-0.75之间时，机器人减速至0.3m/s并靠近目标重新识别，而不是原地等待。
结果对比：调整后，场景B识别率提升至99.6%，场景C的响应时间从平均420ms降至280ms。但代价是：在极低光照（<80 lux）下，机器人会频繁触发减速策略，导致任务完成时间增加15%。甲方接受了这一折中，因为合同未对任务完成时间做硬性约束。
复盘经验：验收测试不是“走过场”，而是对系统鲁棒性的真实检验。开发测试的通过不等于验收通过，因为现场环境存在大量“未知的未知”。建议在项目早期就让测试团队参与需求评审，将环境边界条件写入验收标准，避免后期扯皮。
2.5 常见误区与总结复盘
在机器人AI验收测试的基础知识层面，以下误区需要特别警惕：
误区一：混淆“测试通过”与“系统可用”。开发测试通过只能说明系统在特定条件下按预期工作，而验收测试通过才代表系统在实际使用中满足业务需求。例如，一个机械臂在空载时重复定位精度±0.5mm，但满载3kg时精度降至±2mm，如果合同未明确负载条件，验收时极易产生纠纷。
误区二：忽视“端到端延迟”的组成。响应速度不是单一模块的延迟，而是感知处理时间+决策计算时间+通信传输时间+执行器启动时间的总和。验收测试应使用时间戳同步工具（如PTP）测量各环节延迟，而不是简单地在指令下发和动作开始处打点。
误区三：将动作稳定性等同于重复定位精度。动作稳定性还包括轨迹平滑度（加速度变化率）、超调量、稳态误差以及多轴协同误差。例如，六轴机械臂在高速运动时，各关节的同步误差可能导致末端抖动，即使重复定位精度合格，实际抓取仍可能失败。