ALOHA的ACT算法论文看起来很优雅，但我在真机上跑了三天后才明白它为什么需要200个演示

我不是做硬件出身的，但去年组里要快速搭建一个能做精细家务的服务机器人 demo，预算卡在 3 万美元。当时斯坦福那帮人刚把 ALOHA 开源，我一看 BOM 和论文里的视频——拉衣服拉链、放电池，直接被打动。更让人心跳的是，他们用的模仿学习框架 ACT 看起来也没那么复杂，一个 Transformer 吃下图像和关节状态，吐出一小段动作序列，整个 pipeline 干净得不像是在搞机器人。

我花了两周把硬件搭起来，MuJoCo 里也跑通了训练，仿真成功率 93%。可等到真机上叠毛巾，第一天就掉了链子：双臂对不准，布料滑脱，标定误差让末端位置偏了快 2 厘米。这篇分享，我就想用自己这几个月踩过的坑，把 ALOHA 在仿真和真机之间那条沟画出来，给同样打算低预算复现的工程师一个诚实的参照。

一台能稳定做精细操作的双臂机器人，到底要花多少钱？

ALOHA 的 BOM 为什么敢标 2 万美元

ALOHA 论文（Zipeng Fu 等，2023）里列了一张很诚实的物料清单：两个 ViperX 300 臂，总价约 12,000 美元；两个 WidowX 250 作为从臂，约 6,000 美元；再加上相机、夹具、支架、3D 打印件，全部加在一起约 19,000 美元。这个数字不含 GPU 工作站，但即便加上一台 4090，也能控制在 25,000 美元以内。对于一个能自主完成叠毛巾、开瓶盖的双臂系统来说，这个成本比工业协作臂便宜一个数量级。

可我实际采购时发现，BOM 里的价格像是给美国本土学生用的。国际快递、关税、某些零件停产后的替代品，让我的账单最后停在 23,000 美元左右。更要命的是，ViperX 300 的出货周期在那时候拖到了 8 周，等得我差点被老板怀疑在摸鱼。所以我后来做了另一件事：用 Waveshare 的舵机臂 + 自研结构件搭了一套丐版，总成本压到 6,000 美元，但负载和精度掉了不少，只能说勉强跑通 demo，不是这次的重点。（延伸阅读：多机协作搬运仿真97%成功率，实测71%：我的ROS2多智能体事件驱动架构踩坑报告）

我的建议是，如果你在国内复现，别死磕原版 BOM，直接用 T-Motor 的 AK 系列关节电机自己搭，能省 30% 左右，控制难度会上去，但你的机械背景只要过得去，一个周末差不多能调通。关键是你得到了一个完全自定义的连杆长度，对后面的逆运动学会友好得多。

硬件架构里最容易被低估的东西：主从臂的通讯延迟

ALOHA 的设计精髓在于主从遥操作：你做数据收集时，操作者直接抓着从臂（leader arm）末端移动，两只从臂（follower arm）实时跟随。这个环节里，论文里反复强调“低成本”，却没大谈通讯总线的坑。原版用 USB 转 X-series 控制器，循环频率能到 100Hz，但实际上 USB 的 jitter 在某些主板上大到离谱。我开始用一台 AMD 的工控机跑 ROS，发现关节指令偶尔冒出 15ms 的延迟尖峰，这在精细对齐布料时是致命的——末端抖一下，布料就歪了。

我的解法是换用一台 Intel NUC 12 Extreme，并且把 ROS2 的 DDS 切到 CycloneDDS，用 Real-Time 内核打了补丁，终于把抖动压到 2ms 以内。这个点论文没提，但我认为是整个系统能否用于精细操作的前提，否则你收集的演示数据本身就带高频噪声，学出来的策略只会更差。（延伸阅读：我们用H100烧了18个月模型，等Blackwell等到差点把厂子烧了——10万卡集群TCO账本大白于天下）

# 检查 USB 延迟的一个小脚本，我在遥操作前必跑
import usb.core
import time

dev = usb.core.find(idVendor=0x1a86, idProduct=0x7523)  # 你需替换为实际 VID/PID
if dev is None:
    raise ValueError('Device not found')

latencies = []
for _ in range(100):
    start = time.perf_counter()
    dev.ctrl_transfer(0x40, 0x01, 0, 0, [0x00])  # 发一条控制请求
    end = time.perf_counter()
    latencies.append((end - start) * 1000)  # ms

print(f"平均延迟: {sum(latencies)/len(latencies):.2f} ms, 最大波动: {max(latencies) - min(latencies):.2f} ms")

ACT 策略：为什么分块预测能解决精细操作，但又在真机上那么脆弱

模仿学习在长时序任务里的困局，ACT 用“动作分块”硬解

斯坦福的 ACT 论文（Action Chunking with Transformers for Robot Learning）其实比 ALOHA 早一点出来，但正是这个算法的优雅，让 ALOHA 的演示看起来几乎不需要强化学习。传统的行为克隆一次只预测下一时刻的动作，结果误差在长序列里像滚雪球一样累积，布料这种柔性物体更是灾难。ACT 的做法是，把未来一小段时间内的联合动作打包成一个“chunk”，让 Transformer 的 decoder 一次吐出 100 个动作（100Hz 控制频率下对应 1 秒）。

我读原文时，觉得这个想法像极了 NLP 里的序列生成，区别只是 token 变成了关节角度。他们用 ResNet-18 编码四个视角的图像（两个手腕相机 + 两个全局相机），把特征序列送进 Transformer encoder，再将关节状态的嵌入拼接进去，最后靠 learned positional embedding 让 decoder 预测整个 chunk。训练时用 smooth L1 loss 同时监督 chunk 内所有动作，推理时只取前 10 步执行，然后重新预测，这样既平滑又抗噪。

论文里的表格很好看，在拉链和放电池任务上成功率超过 85%，甚至比一些需要在线 RL 的方法还好。但我自己在仿真里复现时发现，chunk 长度 K 这个超参，在 MuJoCo 里用 100 完全没问题，一上真机，K=100 导致末端在布面上画小圈，怎么都对不齐。直觉很好理解：真实世界的布料形变比仿真复杂，模型预测的长时间动作很快就会偏离实际状态，但重新预测的频率又没赶上变形速度。我最后是把 K 砍到 60，配合更高的重规划频率，才让毛巾折叠任务稳定下来。（延伸阅读：VS Code 1.95 AI代码审查：从理论到实践的跨越）

数据量：论文说 50 个演示就够，真机却要 200 个

ACT 论文在仿真里确实用 50 条演示就能让成功率到 90% 以上，他们甚至强调“data efficiency”。但真机实验部分其实暴露了真相：拉链任务用了 200 条，放电池用了 350 条，叠衬衫用了 400+。这不是作者不诚实，而是精细操作的随机性在真实世界被放大了。布料初始褶皱不同、光照变化、机械臂温漂，都会导致同一条演示轨迹的分布发生偏移。

我按论文推荐，先采集了 80 条毛巾折叠演示，仿真微调后迁移到真机，成功率只有 40%。后来一步步加到 200 条，成功率跳到 72%，再加到 280 条，到了 81%，提升开始钝化。这个过程最折磨人的是，收集数据本身就很耗时——每叠一次毛巾需要手动复位，一个人一天最多采 100 条，双臂的操作者还很容易疲劳，导致后 50 条的质量肉眼可见地下降。

这里有一个工程上的技巧：我后来用仿真数据做数据增强，把 MuJoCo 里生成的 500 条仿真毛巾操作，和 120 条真机数据混合训练，成功率竟然拉到了 85%，而且真机演示数量需求降了一半。这一点 ACT 论文里没有展开，但对预算紧张的人意义重大。（延伸阅读：我让Copilot Agent单挑了一个4年前的数据库竞态bug——账面省下$37,000人力成本，但我开始焦虑Agent的定价陷阱）

从 MuJoCo 到真实世界的迁移，你以为的误差其实是整个系统在拒绝你

为什么我的仿真毛巾叠得像艺术品，真机却像在揉面团

我在仿真里搭 ALOHA 环境时，选了 robomimic 框架，用 MuJoCo 2.3.3 渲染。毛巾我用的是 flex 库模拟布料，动摩擦系数设为 0.5，阻尼很高，非常听话。训练了不到两小时，仿真里双臂协作行云流水，对折、抚平、再对折，每一步都像论文视频里那样优雅。然后我把 checkpoint 直接拷到真机上，噩梦开始。

第一个问题是相机视角。仿真里四个相机的内外参是完美标定的，图像里没有畸变、没有运动模糊、没有环境光变化。真机上的 RealSense D435 装得稍微歪一点，图像传到模型里就认不出毛巾边缘，末端位置预测偏差能到 1.5 厘米。我后来用 charuco 板花了半天重新标定，并做了硬同步触发，才把重投影误差从 0.8 像素降到 0.15 像素。

第二个问题是力控缺失。ACT 只输出关节位置，靠底层的 PID 追踪，但真实接触布料时，没有力反馈，机械臂就像闭着眼在捅。一个典型的失败模式是：左臂按住了布料，右臂本该轻轻掀起，结果 PID 过冲直接推跑。我后来在夹爪上装了薄膜压力传感器，把接触力映射成末端速度缩放因子，这个 hack 让成功率提升了 13%，但论文里根本没提力感知这回事，因为他们演示的任务对力要求不高。（延伸阅读：Optimus分拣仿真99.2%，实测71.3%——我复现端到端模仿学习后，发现Sim2Real的三个死穴）

下面这张表概括了我从仿真到真机迁移过程中主要失败原因的变化：

标定流程我后来做成一个脚本，每次启动真机前必跑一遍，包括手眼标定和底座相对位姿计算。关键代码片段贴在下面，这部分如果不自动化，每天手动调参的时间足够你怀疑人生。

import cv2
import numpy as np
from scipy.spatial.transform import Rotation as R

# 手眼标定：使用 Aruco board 在夹具末端和相机间求解变换
aruco_dict = cv2.aruco.getPredefinedDictionary(cv2.aruco.DICT_4X4_50)
board = cv2.aruco.CharucoBoard((5,7), 0.04, 0.02, aruco_dict)

all_corners, all_ids = [], []
for i in range(30):  # 采集 30 张图像
    frame = capture_from_camera(0)  # 自定义函数
    gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
    corners, ids, _ = cv2.aruco.detectMarkers(gray, aruco_dict)
    if ids is not None:
        _, charuco_corners, charuco_ids = cv2.aruco.interpolateCornersCharuco(
            corners, ids, gray, board)
        if charuco_corners is not None:
            all_corners.append(charuco_corners)
            all_ids.append(charuco_ids)

# 执行标定
ret, mtx, dist, rvecs, tvecs = cv2.aruco.calibrateCameraCharuco(
    all_corners, all_ids, board, gray.shape[::-1], None, None)

# 计算手眼变换（此处简化为基于已知末端位姿的求解）
# 实际需要记录机器人末端在基座下的位姿 T_base_ee，并求解 AX=XB
# 此处省略完整 AX=XB，仅示意提取变换
print("重投影误差:", ret)
np.savez('cam_calib.npz', mtx=mtx, dist=dist)

为什么我最后用了一点模仿学习+残差学习的小技巧

ACT 有一个让我很难受的局限：它假设专家演示覆盖了所有关键状态。但毛巾折叠时初始褶皱千变万化，你不可能靠演示穷举。我在被逼无奈下做了一个非论文做法——在 ACT 输出的基础上加了一个残差网络，这个残差网络在真实环境里用 PPGA（Population-Based Gradient Ascent）在线微调了 50 步，专门补偿布料偏移。虽然这违背了纯模仿学习的初衷，但将成功率从 81% 推到 89%。我甚至觉得，任何低成本的精细操作最终都绕不开一点在线自适应，只是看你怎么包装。

双手折叠毛巾：从采集一条演示到任务跑通的全记录

任务定义和演示的收集策略

毛巾折叠我拆成了三个子动作：展开抚平、对折一次、再次对折。每个子动作大约 5-8 秒，总任务约 20 秒。在收集演示时，我发现必须刻意引入多样性：毛巾初始位置随机偏移 ±10cm，角度随机偏转 ±30°，以及故意留下一些微小褶皱。否则训练出来的策略对初始条件极其敏感，换一条新毛巾就失败。

我用了 ALOHA 原生的遥操作界面，操作者双手握着从臂的末端移动，脚踏板控制夹爪开合。整个过程没有力反馈，全靠眼睛估算，所以我的操作水平其实直接影响数据质量。团队里两个人的演示效果相差巨大，我的同事手更稳，成功率比我高 12%，这个现象在论文里被回避了——ACT 策略的性能上限其实是操作者的技能。

训练时的两个救命参数：Dropout 和 Temporal Aggregation

ACT 原论文里用的是 transformer 常规配置，dropout 0.1，训练 15,000 epoch。我在真机数据上发现过拟合非常严重：训练集 loss 降到 0.0004，验证集却停在 0.002 不动。我把 dropout 调到 0.3，同时开启了权重衰减 1e-4，立刻缓解。另一个论文里提到的 temporal aggregation 技巧——推理时把多次预测的 chunk 用指数加权平均平滑，对减少抖动特别有效，我把它设成了 0.9 的衰减系数。

训练环境我用一张 RTX 4090 跑 PyTorch 2.1，batch size 128，大约 4 小时收敛。如果你用 A100，大概 40 分钟，但这个成本就偏离了我们低预算的初衷。

最后贴一个 ACT 推理循环中平滑输出的代码片段，这个改动虽小，但直接决定了末端是否画圈：

# 推理时的 temporal aggregation
chunk_size = 60
predicted_chunks = []  # 缓存最近几次预测
smoothing_factor = 0.9
for t in range(episode_length):
    with torch.no_grad():
        img = preprocess_images(get_curr_frames())
        joint_state = get_joint_states()
        pred_chunk = model(img, joint_state)  # shape: (chunk_size, 14)
        predicted_chunks.append(pred_chunk)

        if len(predicted_chunks) > 3:
            predicted_chunks.pop(0)

        weights = [smoothing_factor**(len(predicted_chunks)-1 - i) for i in range(len(predicted_chunks))]
        weights = [w / sum(weights) for w in weights]
        smoothed = sum(w * c for w, c in zip(weights, predicted_chunks))

        action = smoothed[0].cpu().numpy()  # 取第一个动作
        send_joint_command(action)
        time.sleep(0.01)  # 100Hz

实验笔记

这篇 ACT 论文最让我兴奋的地方是它把长时序精细操作的问题抽象成了一个简单的生成式建模，甚至不需要 reward 设计。但复现之后，我最大的疑问是：动作分块的长度 K，对机械臂的固有频率和任务动态特性都极其敏感，没有一个原则性的办法去设定它。论文里给的是经验值 1 秒，但在我的折叠任务上 K=60（0.6 秒）远好于 K=100。我怀疑 K 的最优值实际上与接触动力学有关——有布料的场景可能天然需要更短的分块，因为状态变化更快。

接下来我打算联合训练仿真里的布料参数和真实视频帧的对比误差，让模型在仿真里自动搜索一个合适的 K 和动作频率，而不是靠我一个个去试。如果这条路走通，也许可以不再需要 200 个演示，50 个就够——那样的话，ALOHA 才能真的在低预算下推开。