人形机器人为什么该先把灵巧操作做成闭环:从遥操作、数据采集到版本验收的实作指南

这篇文章解决的问题是:当你资源有限、还做不起一台真正可长期跑的双足 humanoid 时,应该先把什么做成闭环。如果你的目标是让机器人尽快进入真实任务验证,而不是先做一个“会走几步”的展示样机,那么更值得优先投资的往往不是 walking,而是灵巧操作闭环:任务定义、上肢与末端、遥操作、数据采集、训练、回放和版本验收。最关键的工程判断是,先把“手上能稳定做成一件事”做出来,再决定值不值得把整机复杂度扩到双足动态移动

这篇适合谁

  • 正在规划第一代 humanoid 原型的小团队,想决定资源先投下肢还是先投操作能力
  • 已经有双臂、灵巧手、固定底座或轮式底盘,想尽快做出可训练、可验证的任务闭环
  • 打算用遥操作或示教数据做 imitation learning,但不知道该先把哪些基础设施搭稳
  • 担心项目长期卡在 walking demo,迟迟没有真正能验收的任务输出

先纠正几个很常见的误区

  • 误区 1:做人形机器人,必须先把双足走稳才算进入正题。
    真实工程里,很多最先能形成商业和技术闭环的能力来自抓取、搬运、插接、整理、按压、旋拧和双手协同,而不是自由行走本身。
  • 误区 2:灵巧操作只是上层算法问题,等本体成熟了再补就行。
    恰恰相反,灵巧操作会逼你尽早把相机、标定、末端控制、延迟预算、示教链路、回放日志和失败分类全都拉通。
  • 误区 3:先做 walking 更“完整”,所以路线更先进。
    如果 walking 没有直接服务当前任务,它只会更快暴露下肢稳定性和跌倒保护的复杂度,却不能替你回答“这台机器人到底能不能稳定做事”。
  • 误区 4:只要能采到演示数据,操作能力自然会长出来。
    数据质量、动作分辨率、相机视角、任务分段和验收脚本没做好,训练只会把坏习惯放大。

关键实现判断:先做“灵巧操作最小闭环”,不要先做“全能 humanoid 幻觉”

我更建议把第一阶段目标写成下面这种形式,而不是“做一台会走会抓的人形机器人”:

  • 在固定工位或有限移动范围内,稳定完成 1 到 2 个双手或单手任务
  • 任务必须有清晰的成功判据,比如插头插入深度、物体放置姿态、抽屉闭合程度、按钮触发、工具接触到位
  • 任务必须能被遥操作完成,并能留下可训练、可回放的数据
  • 任务必须能重复 20 到 50 次,且每次失败都能被归类,不只是“这次没做好”

这个思路和很多高价值外部工程案例是一致的。Mobile ALOHA 证明了,哪怕硬件成本受限,只要先把 whole-body teleoperation 和双手任务收窄,几十条高质量示教就能显著提高复杂任务成功率。Open-TeleVision 则说明,遥操作系统是不是让操作者“看得清、跟得上、对得准”,会直接决定数据可用性。LeRobot 的现实教程也很直白,真正可落地的链路不是“直接训模型”,而是“先校准,再遥操作,再录数据,再训练,再评估”。

分步实践指南

第 1 步,先把任务收缩到一个可量化的操作单元

优先选下面这类任务:

  • 桌面或腰部高度,视觉遮挡有限
  • 目标物种类少,姿态变化可控
  • 动作链长度在 5 到 20 秒内
  • 成功与失败可以直接量化,而不是靠主观感觉

比如:

  • 把两种不同尺寸的盒子分拣到指定框内
  • 打开柜门后把目标物放入指定层
  • 双手扶正工件,再完成插入或按压动作
  • 从托盘抓取物品并放到输送带治具中

不要一开始就做“厨房助理”“家庭全能整理”这类任务。任务一旦过宽,你会同时踩进感知泛化、路径规划、接触控制、异常恢复和长期记忆的坑里,项目节奏马上失控。

第 2 步,平台选择优先级通常是:固定上肢 > 轮式移动操作 > 双足 walking

如果你的目标是尽快做出可训练、可验收的灵巧操作,最现实的硬件顺序通常是:

  1. 固定底座 + 单臂或双臂 + 简化末端,把相机、控制、示教、训练链路先跑通。
  2. 轮式底盘 + 双臂,增加局部移动和多工位过渡,但仍保持系统稳定。
  3. 双足本体,只在任务真的要求跨地形、上下台阶、窄空间穿行时再加。

这不是“保守”,而是把复杂度按验证价值排序。walking 会引入接触切换、状态估计、跌倒保护、热降额和整机供电峰值这些额外变量。一旦任务本身还没收住,问题会多到根本分不清该先修什么。

第 3 步,把遥操作链路当成产品主干,而不是临时调试工具

很多团队把 teleop 当“前期凑合用”的东西,这是个典型失误。真正有效的灵巧操作项目,往往把遥操作系统当成三件事的共同底座:

  • 人类先把任务做通
  • 机器人采集高质量演示数据
  • 自动策略失败时,人能快速接管和标注问题

这一步至少要盯住以下工程点:

  • 视角:操作者必须能看清末端接触区,而不只是看全景画面。Open-TeleVision 的经验很值得借鉴,沉浸式双目或低延迟主视角会明显提升精细任务的数据质量。
  • 动作映射:手腕、夹爪、手指的控制分辨率要匹配任务,不然演示轨迹本身就带着抖动和补偿动作。
  • 安全边界:限速、限力、工作空间裁剪、急停、软限位必须在 teleop 阶段就建立,不要等到“上自动策略后再补”。
  • 时间同步:相机帧、关节状态、控制命令、末端触发事件必须能对齐,否则训练后很难解释为什么策略总慢半拍。

第 4 步,录的不是“视频素材”,而是可训练、可审计的数据集

LeRobot 的现实流程值得直接参考,它把“teleoperate → record → train → evaluate”做成了可复现工具链。你自己的数据集至少要带上这些字段:

  • 任务 ID、步骤阶段、操作者 ID、版本号
  • 相机流、关节角、夹爪/手指命令、末端状态
  • 关键事件时间戳,比如接触、抓稳、释放、插入完成
  • 失败标签,比如视角丢失、夹持滑脱、对位偏差、碰撞、超时

如果你只保存一份普通录屏,后面几乎没法做像样的训练分析。真正有价值的数据集,必须让你能回答三个问题:

  1. 这条演示到底成功了没有
  2. 成功或失败发生在动作链的哪一段
  3. 这次失败更像感知问题、控制问题,还是任务设计问题

第 5 步,先做一个“笨但稳定”的 baseline,再谈更强模型

别一上来就把项目压在大模型或 fancy policy 上。更稳的路线是:

  1. 先用规则或有限状态机把任务阶段切开
  2. 每个阶段只学一类动作,比如接近、抓取、插入、释放
  3. 先用 imitation learning 跑出可复现 baseline
  4. 等 baseline 稳了,再考虑多任务共享、语言条件、世界模型或更大策略

Mobile ALOHA 的一个重要启发就是,不要把“任务复杂”误解成“必须先上最复杂模型”。在很多操作任务里,硬件接口清晰、示教质量够高、任务阶段切得好,往往比模型换代更先决定结果。

第 6 步,给灵巧操作定义一个明确的版本验收表

我建议每个任务至少有以下几类验收指标:

  • 任务成功率:连续 20 次或 50 次执行的完成率
  • 恢复能力:轻微偏差后是否允许二次对准,而不是一次失败就整条流程终止
  • 时间稳定性:周期是否收敛,有没有越来越慢的补偿动作
  • 接触质量:抓取后滑脱率、插接后的姿态误差、按压后的触发成功率
  • 可回放性:一次失败能否在 10 分钟内定位到具体时刻和具体原因

如果你连这张验收表都写不出来,那多半说明任务定义还不够收敛,或者系统结构还是“demo 导向”而不是“工程闭环导向”。

第 7 步,再决定 walking 什么时候值得接进来

只有当下面这些条件同时成立时,我才会建议把 walking 提到主线:

  • 当前操作任务已经在固定工位或短距离移动条件下形成稳定闭环
  • 任务价值真的受限于跨区域移动,而不是末端成功率太低
  • 你已经有日志、回放、远程接管和恢复流程,能承受双足调试带来的新故障
  • 团队里有人能真正负责状态估计、接触切换、跌倒保护和热管理,而不是把 walking 当额外 feature

换句话说,walking 不是不能早做,而是不该在任务闭环还没建立时抢走所有预算和注意力。

最容易翻车的地方

  • 任务选得太大。结果就是采了很多演示,但没有哪一段真正足够一致,最后训练什么都学不稳。
  • 遥操作视角和机器人视角不一致。操作者靠脑补完成动作,策略学到的却是错误的视觉依赖。
  • 示教数据没有失败标签。最后只能知道“成功率低”,但不知道低在接近、抓取还是释放。
  • 过早追求手指自由度。很多任务先用更简单但刚性的末端就能完成,盲目加手指只会先把控制和维护成本抬高。
  • 没把 walking 变量隔离掉。本来要查的是末端接触问题,结果每次失败都混着底盘姿态、机身晃动和供电瞬态。

怎么验证你真的搭对了

至少做三层验证,而不是只看一条 demo 视频:

  1. 遥操作层:同一操作者能否连续稳定完成 20 次,且动作分布明显收敛。
  2. 数据层:随机抽 10 条轨迹,是否每条都能回看到关键帧、关键状态和成功/失败标签。
  3. 策略层:在轻度扰动下,比如物体位置偏几厘米、光照略变、初始姿态略偏,成功率是否仍可接受。

如果你有仿真条件,可以参考 RLBench 这类 manipulation benchmark 的思路,不一定照搬它的任务,但很值得借它的做法去建立“任务拆分、成功判据、批量回归、已知 gotchas”这一整套验证纪律。仿真不是为了炫耀任务数量,而是为了提前把 benchmark 结构定清楚。

下一步怎么做

  • 先选一个 5 到 15 秒、成功判据明确的双手或单手任务
  • 用两周时间把 teleop、数据记录、回放和失败标签先打通
  • 先跑出一个能连续执行的小 baseline,不要急着追大而全的模型
  • 等任务闭环稳定后,再决定要不要把轮式移动或双足 walking 接进来

如果你现在还在纠结“要不要先做 walking 才算 humanoid”,我会更直白一点:先让机器人稳定地把手上的事做对,你后面做 walking 才会更有意义,也更有把握。

延伸阅读与参考来源

Share this article

Send it to someone following humanoid robotics, embodied AI, or deployment trends.