如果你是从阶段 1 一路跟过来的老读者应该还记得我前几篇里从头搭 robomimic 环境、下载 Lift-PH 数据集、跑通低维状态行为克隆的那些记录。这篇是整套复现流程的第七篇主题落在 Vision BC用图像作为主要观测输入让策略通过视觉编码器自己决定下一步动作。对于刚点进来的新朋友也不用慌我会把数据构建、视觉编码、正式训练、故障恢复和评估这五件事按我实际操作的先后顺序完整写一遍你可以把这篇当成一份独立的操作指南来用。先交代一个背景Lift-PH 是 robomimic 内置的经典基准之一任务是让七自由度的机械臂在仿真环境里把桌面上的方块抓起来并抬升到指定高度PH 代表训练数据来自熟练人类演示Proficient Human。前面几个阶段我们把数据跑通、把低维状态下的 BC 和故障排查做了但 robomimic 官方 benchmark 的核心评价场景其实大量依赖视觉输入——毕竟真实机器人上你不可能总拿到完美的关节角状态图像才是更接近实际部署的观测模态。所以阶段 7 的重点很明确让策略学会“看”。这篇文章的实操环境假设是 Ubuntu 20.04、一张 12GB 显存左右的 NVIDIA 显卡、已经装好 robomimic 和对应依赖。如果你的显存更小也没关系我在训练资源部分会给出降级方案。接下来从数据侧开始讲因为 Vision BC 和低维 BC 在大框架上很像但恰恰是数据构建这一步最容易埋雷。1. 为什么会走到阶段 7Vision BC 在 Lift-PH 流程中的位置1.1 前面六个阶段做了什么Lift-PH 到底考什么很多人第一次接触 robomimic 时容易把它当成一个单纯的“调包跑模型”的库实际上它更像一套完整的模仿学习实验框架数据管理、算法训练、策略回放、指标统计都封装好了。Lift-PH 作为入门任务数据集不大通常几百条演示动作空间是 7 维臂关节加 1 维夹爪观测空间则分两种路线——只用低维状态关节角、末端位姿、夹爪开合度或者叠加上相机图像。我在前六个阶段做的事情大致可以归纳成这么几件搭建 conda 环境和 robomimic 源码安装把 Lift-PH 数据集下载下来并理解它的 HDF5 层级结构用官方配置跑通一次低维 BC 训练确认环境没装错接着做了基于状态输入的评估理解了成功率、平均回报这些指标是怎么算出来的再往后是一些调参和日志解读让低维 BC 的成功率稳定在一个可接受的范围。之所以单独把阶段 7 拎出来写是因为“加上图像”这件事远没有看起来那么轻描淡写。低维 BC 里观测是几十维的向量丢进 MLP 就能学而图像是 H×W×C 的高维张量必须经过视觉编码器压缩成低维特征再和低维状态拼接后进策略网络。这个“压缩”环节设计得好不好直接决定了策略能不能在测试环境里稳定复现训练时的动作。换句话说Vision BC 的难点不在 BC 本身而在“看”这件事。1.2 视觉编码是这道关卡的分水岭我在阶段 6 结束的时候特意做了一个对照实验把低维 BC 里训练好的策略放到新的随机种子环境里跑发现成功率掉了一截。这个现象不奇怪因为纯状态输入没有把视觉信息纳入闭环策略对物体的位置变化非常敏感。而在真实的机器人部署场景里物体每次摆放都会有偏差你必须让策略通过相机看到物体实际在哪这就是 Vision BC 的价值。robomimic 把视觉编码器的选择做成了配置项理论上你可以很轻松地在 ResNet、ViT、R3M 这些编码器之间切换。但“能够切换”和“知道为什么这样切”是两回事。我在这一阶段花了最多时间的反而不是训练本身而是确定用哪种编码器、用什么预训练权重、图像要不要裁剪增强、特征维度压到多少。这些决策如果拍脑袋定后面每调一次都要重新训练好几个小时。所以这篇文章的叙事线会尽量贴近我实际的推进过程先把数据搞清楚再选编码器再谈训练和恢复最后看评估结果怎么反推下一步。整条链路里我会反复强调一件事——在机器人模仿学习里80% 的问题出在数据和组织数据的方式上模型本身反而很少闹脾气。2. 数据构建从 HDF5 到可训练视觉数据集的完整链路2.1 先搞清楚数据集里到底有什么robomimic 的数据集统一用 HDF5 格式存储文件后缀是 .hdf5。第一次接触这个格式的读者可以把它理解成一个自带层级目录的字典每个 group 相当于一个文件夹dataset 里的每一个 demo 相当于一个子文件夹里面按时间轴存着每一步的观测、动作、奖励和终止标志。我在拿到 lift_ph.hdf5 之后做的第一件事从来不是直接开训而是先写一段脚本把数据集的“体检报告”打出来。下面这段代码可以帮你快速确认数据集的关键信息import h5py with h5py.File(path/to/lift_ph.hdf5, r) as f: print(顶层 keys:, list(f.keys())) demo_keys list(f[data].keys()) print(演示数量:, len(demo_keys)) demo demo_keys[0] print(单条轨迹的字段:, list(f[data][demo].keys())) print(观测字段:, list(f[data][demo][obs].keys())) print(图像 shape:, f[data][demo][obs][agentview_image].shape) print(动作 shape:, f[data][demo][actions].shape) print(总步数:, f[data].attrs.get(total_timesteps, N/A)) print(环境参数:, f[data].attrs.get(env_args, N/A))拿 Lift-PH 数据集来说观测字段里通常会有 agentview_image 和 eye_in_hand_image 两组图像前者是工作台上方视角后者是手眼相机视角低维观测则包括关节状态、末端执行器位置/姿态、夹爪开合量。动作通常是关节位置增量或者末端执行器的位置/姿态增量具体取决于数据集录制时的控制器类型。这一步的核心价值在于你得确认图像键名、图像尺寸、通道数、动作维度并且和后面配置文件里写的观测模态完全对应。我见过太多人在这一步翻车——配置文件里写了 agentview_rgb但数据里存的键叫 agentview_image训练一启动就直接报错白白浪费十几分钟排查。2.2 图像预处理与键名对齐最容易翻车的地方Vision BC 的数据构建里有一个非常容易被忽略的点robomimic 在读取图像时并不会傻乎乎地把整张大图直接塞进网络而是会按照配置里的 crop 参数先做裁剪。裁剪的好处有两个一是大幅减少计算量二是相当于一种数据增强让策略对物体位置的微小变化不那么敏感。我在配置里通常会把图像缩放到一个固定的观测量级比如 224×224 或者更小的 160×160然后开启随机裁剪。注意这里的随机性只在训练时生效评估时用的是中心裁剪保证结果可复现。还有一个细节是像素值归一化robomimic 内部会处理但你心里要有数网络吃进去的不是 0-255 的原始像素而是归一化后的张量这会影响你对 loss 数值的判断。键名对齐这块我单独列一条经验在写配置之前先把数据集里实际的 obs 键名抄到一张纸上然后一行一行对着配置写不要凭记忆写。特别是眼睛里有多个相机视角的情况agentview 和 eye_in_hand 的顺序、命名都不能错。robomimic 在多视角处理上会把所有图像观测拼成一个更大的 batch 维度如果视角顺序和训练时不一致模型看到的就是完全错位的信息loss 可能并不会爆炸但成功率会诡异地低。2.3 训练前的数据体检三个硬指标数据集的键名没问题不代表数据本身没问题。我在每次开始训练之前会固定跑三个检查项你可以把它们理解为“数据健康度”的硬指标第一个是轨迹长度分布。Lift-PH 的演示有人类操作的自然差异有的轨迹 100 步就完成了有的可能磨蹭到 300 步。如果长度差异悬殊训练时每个 batch 里的轨迹长度会很不均匀robomimic 默认会做 padding但 padding 比例过高会稀释有效梯度。一般在配置里把 horizon 卡在一个合理的上限即可。第二个是动作范围。打印一下所有 demo 的 actions min/max如果某个维度的范围异常大或者出现非常突兀的尖峰很可能录制时夹爪开合或者关节运动有抖动这种轨迹会在训练时给策略带来错误引导。我一般会把明显异常的轨迹单独筛出来看。第三个是图像的时间连续性。用 OpenCV 或者直接抽帧的方式快速浏览几条轨迹的图像序列。人类演示里偶尔会出现帧跳变、画面遮挡或者其他脏数据这些在指标上不一定体现得出来但策略学出来的动作会很怪。Lift-PH 这种标准基准数据一般不会有这种问题但如果你自己录数据这一步绝对不能省。数据体检做完训练前的准备工作就完成了一大半。接下来要做的决定是选择视觉编码器这也是我在这篇文章里想重点展开的部分。3. 视觉编码选型从 ResNet 到 R3MLift-PH 的实践取舍3.1 robomimic 里的视觉编码器家族robomimic 把视觉编码器的实现集中在 VisualCore 这个抽象类下面你只需要在配置里指定 backbone_class 和 pool_class框架就会自动把图像观测编码成固定维度的特征向量。我整理了一下我实际用过的几种组合连同我的使用感受一起放在表格里编码器组合核心思路参数量与开销在 Lift-PH 上的实践感受ResNet18 SpatialSoftmax卷积提取特征再用空间 Softmax 得到关键点坐标中等单卡 12GB 可跑最稳的默认选择收敛快对数据量要求不高ResNet18 Global Avg Pool卷积后全局平均池化得到特征向量中等同上特征丢失空间信息Lift 任务表现略逊于 SpatialSoftmaxViTVision Transformer图像切 patch 后走 Transformer较大训练慢效果好但需要更多数据和更精细的调参教学复现不建议新手直接用R3M / MVP 预训练模型用互联网视频预训练好的视觉表征冻结或微调权重文件大显存占用高在小数据场景有优势但需要额外准备权重文件链路更长从这张表能看出来我最终在阶段 7 选的是 ResNet18 SpatialSoftmax 这个组合也就是 robomimic 文档里常说的 RSS 编码器。理由很朴素Lift-PH 的训练数据量属于“中等偏小”ResNet18 在这种规模下不容易过拟合训练速度快而 SpatialSoftmax 相比全局平均池化保留了空间位置信息——抓取任务恰恰非常依赖“物体在画面哪个位置”这个信息。3.2 预训练权重用不用冻结还是微调这里有一个在社区里经常吵起来的问题ResNet 的 backbone 要不要加载 ImageNet 预训练权重加载之后是冻结还是微调我的实践结论是加载预训练权重并且让 backbone 参与微调但把 backbone 的学习率调得比策略网络低一些。为什么加载预训练权重因为 Lift-PH 的图像虽是仿真渲染但底层的边缘、纹理、形状特征和自然图像有共通之处。预训练权重相当于给网络一个“已经会看基础视觉特征”的起点从这一步开始学抓取比从随机初始化开始学要快得多。为什么不全冻结因为仿真图像的颜色分布、渲染风格和 ImageNet 差距不小完全冻结会导致特征偏移策略对仿真环境的过拟合反而更严重。在具体实现上你可以在配置里给 backbone 单独设置共享学习率倍数。我用的方案是策略网络主学习率 1e-4backbone 的学习率倍率设为 0.1相当于 backbone 每步只走 1e-5。这样既能利用预训练特征又不会因为大学习率把预训练权重冲乱。3.3 编码器配置文件怎么写一段可复制的核心配置下面是我在阶段 7 实际使用的编码器配置整体符合 robomimic 的 JSON 配置规范。具体字段在不同版本里可能稍有出入但结构是大致固定的observation: { modalities: { obs: { low_dim: [ robot0_eef_pos, robot0_eef_quat, robot0_gripper_qpos ], image: [ agentview_image, robot0_eye_in_hand_image ] } }, encoder: { image: { core_class: VisualCore, core_kwargs: { backbone_class: ResNet18Conv, backbone_kwargs: { pretrained: true, input_coord_conv: false }, pool_class: SpatialSoftmax, pool_kwargs: { num_kp: 32, learnable_temperature: false, temperature: 1.0 }, flatten: true, feature_dimension: 64 } } }, crop_randomization: true, crop_height: 160, crop_width: 160 }几个字段我解释一下num_kp 是 SpatialSoftmax 输出的关键点数量32 在 Lift 上是一个比较中庸的值关键点太少模型“看不太清”太多容易过拟合feature_dimension 是最终每个视角输出的特征维度我设为 64两个视角一共 128 维再拼接低维状态对后面 MLP 来说输入规模非常友好。crop_randomization 打开后训练时每个 step 的裁剪位置会随机相当于免费的数据增强。提示不要小看 feature_dimension 这个字段。它决定编码器输出和策略网络输入之间的接口维度改一次意味着整个网络结构都要重新训练。在动手之前想清楚比你训到一半再改要省时得多。4. 正式训练配置、启动、监控中的关键细节4.1 一份完整的 Vision BC 训练配置有了编码器配置剩下的训练参数就好办了。我把训练相关的配置也一并列出来你可以直接把这些和上面的 encoding 配置合到同一个 JSON 文件里{ experiment: { name: lift_ph_bc_vision, output_dir: ../../results, save_interval: 1, rollout: { enabled: true, n: 30, horizon: 500, rate: 50 } }, train: { num_epochs: 200, batch_size: 64, optimizer: { type: adamw, lr: 0.0001, weight_decay: 0.0001 }, data: { dataset: ../../datasets/lift/ph/lift_ph.hdf5 }, num_data_workers: 4 }, algorithm: { type: bc, bc: { loss: { type: l2 } } } }这里有个很关键的设计experiment.rollout.enabled 设为 true意思是训练过程中每隔一定 epoch 就在仿真环境里自动做一次 rollout用当时的策略去跑若干条新轨迹实时记录成功率。这个功能是我在阶段 5 之后才养成的习惯——与其等到 200 个 epoch 全训完才发现策略发散不如让训练过程每隔一阵就告诉你“现在这个策略行不行”。rollout.rate 控制每多少个 epoch 做一次评估我一般设 50也就是说第 50、100、150、200 个 epoch 都会自动跑一次评估日志里看趋势非常直观。4.2 训练启动命令与日志解读配置写好后训练启动命令非常简单cd /path/to/robomimic python train.py --config configs/lift_ph_bc_vision.jsonrobomimic 会在 output_dir 下按实验名生成一个带时间戳的目录里面包含 config.json 备份、日志文件、模型权重和 rollout 的视频。日志同时会走 TensorBoard你可以用tensorboard --logdir ../../results/lift_ph_bc_vision然后在浏览器里看训练曲线。我重点看的指标有三个BC loss、gradient norm、以及 rollout 成功率。BC loss 在训练初期通常会快速下降然后进入一个平台期这是正常的你要警惕的是 loss 突然反弹或者剧烈震荡。gradient norm 则是一个很好的“健康信号”如果它突然飙到很大的数值通常意味着学习率偏高或者 batch 里有异常样本。再强调一次 rollout 成功率和训练 loss 的关系BC 是一种监督学习方法loss 反映的是“模型输出动作和演示动作的差距”但 loss 低不代表策略在环境里表现好——有可能模型只是学会了所有训练轨迹的平均动作而在真实 rollout 时一个方块都抓不起来。这也是我不厌其烦要求开 rollout.enabled 的原因它让你在一个训练过程中就能同时看到“模仿精度”和“任务表现”两个维度。4.3 训练资源规划与显存优化Vision BC 的显存压力主要来自图像 batch。12GB 显存跑 batch_size 64、图像 160×160 是稳的如果你的显卡只有 8GB我建议优先把 batch_size 降到 32其次是 crop 尺寸降到 128×128。记住一个原则先保 rollout 能跑再保训练速度最后再考虑精度。num_data_workers 这个参数也值得说一下。它控制 DataLoader 用几个子进程来读 HDF5 数据。图像数据读取是 IO 密集型的worker 太少会导致 GPU 经常空转太多则可能因为数据搬运开销反而变慢。我在 16 核机器上通常设为 4 到 8具体可以自己扫一遍。还有一个容易踩的坑是日志和视频写入占满磁盘。robomimic 在 rollout 时会保存视频如果 rollout.n 设得比较大、视频分辨率又高跑几十个 epoch 之后 output 目录可能膨胀到几个 GB。我一般会在训练前用 df -h 看一眼磁盘余量并且定期清理旧视频只保留有代表性的几条。5. 故障恢复训练中断、OOM、NaN 和数据集异常的排查清单5.1 从断点续训说起checkpoint 的正确用法训练到一半断了这是所有深度学习项目里最常见也最恼火的问题robomimic 的故障恢复能力其实做得不错但你得知道它把信息保存在哪里。权重文件默认保存在实验目录下的 checkpoint 子目录里文件名为 model.pt 或者带 epoch 后缀的模型文件。恢复训练的命令是python train.py --config configs/lift_ph_bc_vision.json \ --resume ../../results/lift_ph_bc_vision/timestamp/checkpoints/model.pt注意--resume 接收的是 .pt 权重文件路径robomimic 会从里面恢复模型参数、优化器状态、当前 epoch 数以及一些训练进度信息。恢复之后你会发现日志里的 epoch 从断点继续而不是从头开始。这里有一个很容易疏忽的点如果你在断点之后修改了配置文件再 resumerobomimic 会尝试用新配置继续训练。大多数配置项可以安全修改但和网络结构相关的字段——比如 feature_dimension、num_kp、图像 crop 尺寸——一旦改了旧权重就加载不上了。所以我的习惯是配置写完后复制一份到实验目录做备份中途只调学习率这类不影响结构的参数结构相关的改动一律开新实验。5.2 三个我在阶段 7 里真实踩过的故障第一个是 CUDA out of memory。这个报错最常见的形式是训练跑了一小段之后突然崩掉提示 CUDA OOM。我遇到的原因不是 batch_size 太大而是 rollout 和训练同时启动时显存叠加。解决方法是把 rollout.n 调小或者把 rollout 的评估挪到训练结束后单独跑。如果你在训练过程中必须开 rollout至少把 batch_size 留出 20% 的显存余量。第二个是 loss 变成 NaN。这在视觉任务里比低维任务更容易发生因为图像特征的值域天然比状态向量大。我排查的顺序是先看是不是学习率过高把 lr 从 1e-4 降到 3e-5再看数据里有没有 NaN 或者 Inf打印数据集的统计量确认最后检查是否开启了 weight_decay 且数值过大。90% 的 NaN 问题出在数据或学习率上。第三个是观测键不匹配。前面提到过配置文件里的图像键名和数据集里的实际键名必须完全一致。报错信息通常会明确告诉你是哪个键找不到但有一种隐蔽情况是两个视角的顺序反了模型不会报错成功率却莫名其妙低。排查方法很简单在训练前写一小段脚本加载数据集把配置里的 obs 键逐一对一遍最稳妥。5.3 故障恢复的操作顺序清单我把故障恢复的排查流程整理成固定顺序每次出问题就按这个顺序过一遍效率比随机尝试高很多步骤检查项具体操作1磁盘空间df -h 查看 output 目录所在分区清理过期视频和日志2数据集完整性重新运行数据体检脚本确认图像、动作、键名正常3日志定位打开 TensorBoard 或文本日志确认故障发生前的最后一个正常 step4资源占用nvidia-smi 查看显存确认没有其他进程占卡5配置对比和实验目录下备份的 config.json 对比确认没有误改结构字段6降级启动先关 rollout、减 batch_size确认训练能稳定跑起来再逐步加回来这个顺序背后的逻辑是先排除环境问题再排除数据问题最后才是模型和配置问题。我在这个阶段至少省下了两三个小时的无效排查时间。6. 评估与回放Rollout 指标解读和策略迭代闭环6.1 跑一次正式评估的正确姿势训练结束后robomimic 会自动保存最终的模型权重最靠谱的评估方式是用它自带的 run_trained_agent.py 脚本在独立于训练过程的环境里做一次干净的 rolloutpython run_trained_agent.py \ --agent ../../results/lift_ph_bc_vision/timestamp/checkpoints/model.pt \ --episodes 50 \ --horizon 500 \ --video_path ./eval_videos/lift_ph_bc_vision.mp4这里有几个参数值得解释。episodes 是一次评估里跑多少条新轨迹这个数字不能太小我说一个最直观的理由如果成功率是 80%跑 10 条轨迹可能会有 8 条成功但也会有 2 条失败跑 50 条你才能比较有信心地说这个策略的“真实水平”接近 80%。我一般至少跑 50 条条件允许的话跑 100 条。horizon 是每条轨迹的最大步数上限。Lift 任务正常的成功轨迹通常在几十步内完成500 步的 horizon 已经足够宽松主要是给那些卡住的策略一个“超时判负”的出口。评估脚本会输出每个 episode 的累计回报、是否成功、步数等信息最后汇总成一个统计表。6.2 指标怎么读成功率之外还要看什么面对评估输出第一反应肯定是看成功率但只看成功率会漏掉很多信息。我习惯把下面三个指标组合起来读成功率是最直观的定义为 50 条轨迹里完成任务的比例。平均累计回报能反映“虽然没有成功但策略离成功有多近”如果一个策略成功率只有 30% 但平均回报很高说明它明白大致该怎么做只是最后一步不精确这种策略有救。轨迹长度分布则暴露策略的效率问题——如果平均要 400 步才完成而演示平均只要 80 步说明策略是在“磨”而不是在“做”。还有一个被很多人忽略的信号是失败模式。你最好把评估视频保存下来然后花一点时间逐条看失败的轨迹。我在阶段 7 第一次跑完评估的时候成功率只有 50% 出头看视频发现失败轨迹几乎都卡在同一个位置——机械臂能到达方块上方但夹爪张开时机太晚导致与方块擦肩而过。这个信息从任何数值指标里都看不出来但它直接决定了你下一步该怎么调。6.3 从评估结果反推修改方向评估结果不是终点而是下一轮迭代的起点。我会按下述逻辑决定下一步动作如果成功率低于三成优先怀疑数据或编码器。先做一组消融把图像分辨率调高、把裁剪关闭试试如果还是不涨换更大的预训练 backbone 或者换 R3M 权重但要做好训练变慢的心理准备。如果成功率中等但轨迹长、动作犹豫优先怀疑 loss 设置或者学习率。BC 的 L2 loss 鼓励“平均动作”如果演示里同一个场景有不同风格的动作模型可能学出一个中间值导致动作缓慢。可以试试把 loss 换成负对数似然NLL或者在数据里过滤掉步骤数过长、风格过于极端的轨迹。如果成功率不错但少数轨迹出现诡异的震荡优先怀疑图像增强。crop_randomization 虽然能提升泛化但裁剪范围过大可能让模型看到不完整的工作台。把裁剪幅度调小通常能像止痛药一样立竿见影。我自己的阶段 7 最终迭代路径是第一轮训练成功后成功率在 50%通过看视频锁定夹爪时机问题第二轮把 num_kp 从 32 提到 48并把 crop 幅度略微调小成功率到了 75% 左右第三轮降低 backbone 学习率到原来的三分之一训练多跑了 50 个 epoch最终稳定在了 80% 以上的水平。这个水平虽然和官方 benchmark 里一些更强算法的成绩还有差距但作为教学型复现已经达到了我想要的目的——它证明了视觉信息确实能被 BC 策略有效利用也验证了从数据到评估这条链路本身是通的。最后再分享一个我个人的工作习惯。在阶段 7 之后我每跑一个实验都会在 results 目录下新建一个 notes.md用两三句话记录当前实验改了哪个字段、成功率是多少、看视频发现了什么现象。这个习惯帮我避免了很多“这个实验之前好像跑过但忘了结果”的尴尬尤其是当你要在编码器、学习率、关键点数量这几个维度上反复横跳的时候一个清晰的实验日志比任何高级工具都管用。
如果你是从阶段 1 一路跟过来的老读者应该还记得我前几篇里从头搭 robomimic 环境、下载 Lift-PH 数据集、跑通低维状态行为克隆的那些记录。这篇是整套复现流程的第七篇主题落在 Vision BC用图像作为主要观测输入让策略通过视觉编码器自己决定下一步动作。对于刚点进来的新朋友也不用慌我会把数据构建、视觉编码、正式训练、故障恢复和评估这五件事按我实际操作的先后顺序完整写一遍你可以把这篇当成一份独立的操作指南来用。先交代一个背景Lift-PH 是 robomimic 内置的经典基准之一任务是让七自由度的机械臂在仿真环境里把桌面上的方块抓起来并抬升到指定高度PH 代表训练数据来自熟练人类演示Proficient Human。前面几个阶段我们把数据跑通、把低维状态下的 BC 和故障排查做了但 robomimic 官方 benchmark 的核心评价场景其实大量依赖视觉输入——毕竟真实机器人上你不可能总拿到完美的关节角状态图像才是更接近实际部署的观测模态。所以阶段 7 的重点很明确让策略学会“看”。这篇文章的实操环境假设是 Ubuntu 20.04、一张 12GB 显存左右的 NVIDIA 显卡、已经装好 robomimic 和对应依赖。如果你的显存更小也没关系我在训练资源部分会给出降级方案。接下来从数据侧开始讲因为 Vision BC 和低维 BC 在大框架上很像但恰恰是数据构建这一步最容易埋雷。1. 为什么会走到阶段 7Vision BC 在 Lift-PH 流程中的位置1.1 前面六个阶段做了什么Lift-PH 到底考什么很多人第一次接触 robomimic 时容易把它当成一个单纯的“调包跑模型”的库实际上它更像一套完整的模仿学习实验框架数据管理、算法训练、策略回放、指标统计都封装好了。Lift-PH 作为入门任务数据集不大通常几百条演示动作空间是 7 维臂关节加 1 维夹爪观测空间则分两种路线——只用低维状态关节角、末端位姿、夹爪开合度或者叠加上相机图像。我在前六个阶段做的事情大致可以归纳成这么几件搭建 conda 环境和 robomimic 源码安装把 Lift-PH 数据集下载下来并理解它的 HDF5 层级结构用官方配置跑通一次低维 BC 训练确认环境没装错接着做了基于状态输入的评估理解了成功率、平均回报这些指标是怎么算出来的再往后是一些调参和日志解读让低维 BC 的成功率稳定在一个可接受的范围。之所以单独把阶段 7 拎出来写是因为“加上图像”这件事远没有看起来那么轻描淡写。低维 BC 里观测是几十维的向量丢进 MLP 就能学而图像是 H×W×C 的高维张量必须经过视觉编码器压缩成低维特征再和低维状态拼接后进策略网络。这个“压缩”环节设计得好不好直接决定了策略能不能在测试环境里稳定复现训练时的动作。换句话说Vision BC 的难点不在 BC 本身而在“看”这件事。1.2 视觉编码是这道关卡的分水岭我在阶段 6 结束的时候特意做了一个对照实验把低维 BC 里训练好的策略放到新的随机种子环境里跑发现成功率掉了一截。这个现象不奇怪因为纯状态输入没有把视觉信息纳入闭环策略对物体的位置变化非常敏感。而在真实的机器人部署场景里物体每次摆放都会有偏差你必须让策略通过相机看到物体实际在哪这就是 Vision BC 的价值。robomimic 把视觉编码器的选择做成了配置项理论上你可以很轻松地在 ResNet、ViT、R3M 这些编码器之间切换。但“能够切换”和“知道为什么这样切”是两回事。我在这一阶段花了最多时间的反而不是训练本身而是确定用哪种编码器、用什么预训练权重、图像要不要裁剪增强、特征维度压到多少。这些决策如果拍脑袋定后面每调一次都要重新训练好几个小时。所以这篇文章的叙事线会尽量贴近我实际的推进过程先把数据搞清楚再选编码器再谈训练和恢复最后看评估结果怎么反推下一步。整条链路里我会反复强调一件事——在机器人模仿学习里80% 的问题出在数据和组织数据的方式上模型本身反而很少闹脾气。2. 数据构建从 HDF5 到可训练视觉数据集的完整链路2.1 先搞清楚数据集里到底有什么robomimic 的数据集统一用 HDF5 格式存储文件后缀是 .hdf5。第一次接触这个格式的读者可以把它理解成一个自带层级目录的字典每个 group 相当于一个文件夹dataset 里的每一个 demo 相当于一个子文件夹里面按时间轴存着每一步的观测、动作、奖励和终止标志。我在拿到 lift_ph.hdf5 之后做的第一件事从来不是直接开训而是先写一段脚本把数据集的“体检报告”打出来。下面这段代码可以帮你快速确认数据集的关键信息import h5py with h5py.File(path/to/lift_ph.hdf5, r) as f: print(顶层 keys:, list(f.keys())) demo_keys list(f[data].keys()) print(演示数量:, len(demo_keys)) demo demo_keys[0] print(单条轨迹的字段:, list(f[data][demo].keys())) print(观测字段:, list(f[data][demo][obs].keys())) print(图像 shape:, f[data][demo][obs][agentview_image].shape) print(动作 shape:, f[data][demo][actions].shape) print(总步数:, f[data].attrs.get(total_timesteps, N/A)) print(环境参数:, f[data].attrs.get(env_args, N/A))拿 Lift-PH 数据集来说观测字段里通常会有 agentview_image 和 eye_in_hand_image 两组图像前者是工作台上方视角后者是手眼相机视角低维观测则包括关节状态、末端执行器位置/姿态、夹爪开合量。动作通常是关节位置增量或者末端执行器的位置/姿态增量具体取决于数据集录制时的控制器类型。这一步的核心价值在于你得确认图像键名、图像尺寸、通道数、动作维度并且和后面配置文件里写的观测模态完全对应。我见过太多人在这一步翻车——配置文件里写了 agentview_rgb但数据里存的键叫 agentview_image训练一启动就直接报错白白浪费十几分钟排查。2.2 图像预处理与键名对齐最容易翻车的地方Vision BC 的数据构建里有一个非常容易被忽略的点robomimic 在读取图像时并不会傻乎乎地把整张大图直接塞进网络而是会按照配置里的 crop 参数先做裁剪。裁剪的好处有两个一是大幅减少计算量二是相当于一种数据增强让策略对物体位置的微小变化不那么敏感。我在配置里通常会把图像缩放到一个固定的观测量级比如 224×224 或者更小的 160×160然后开启随机裁剪。注意这里的随机性只在训练时生效评估时用的是中心裁剪保证结果可复现。还有一个细节是像素值归一化robomimic 内部会处理但你心里要有数网络吃进去的不是 0-255 的原始像素而是归一化后的张量这会影响你对 loss 数值的判断。键名对齐这块我单独列一条经验在写配置之前先把数据集里实际的 obs 键名抄到一张纸上然后一行一行对着配置写不要凭记忆写。特别是眼睛里有多个相机视角的情况agentview 和 eye_in_hand 的顺序、命名都不能错。robomimic 在多视角处理上会把所有图像观测拼成一个更大的 batch 维度如果视角顺序和训练时不一致模型看到的就是完全错位的信息loss 可能并不会爆炸但成功率会诡异地低。2.3 训练前的数据体检三个硬指标数据集的键名没问题不代表数据本身没问题。我在每次开始训练之前会固定跑三个检查项你可以把它们理解为“数据健康度”的硬指标第一个是轨迹长度分布。Lift-PH 的演示有人类操作的自然差异有的轨迹 100 步就完成了有的可能磨蹭到 300 步。如果长度差异悬殊训练时每个 batch 里的轨迹长度会很不均匀robomimic 默认会做 padding但 padding 比例过高会稀释有效梯度。一般在配置里把 horizon 卡在一个合理的上限即可。第二个是动作范围。打印一下所有 demo 的 actions min/max如果某个维度的范围异常大或者出现非常突兀的尖峰很可能录制时夹爪开合或者关节运动有抖动这种轨迹会在训练时给策略带来错误引导。我一般会把明显异常的轨迹单独筛出来看。第三个是图像的时间连续性。用 OpenCV 或者直接抽帧的方式快速浏览几条轨迹的图像序列。人类演示里偶尔会出现帧跳变、画面遮挡或者其他脏数据这些在指标上不一定体现得出来但策略学出来的动作会很怪。Lift-PH 这种标准基准数据一般不会有这种问题但如果你自己录数据这一步绝对不能省。数据体检做完训练前的准备工作就完成了一大半。接下来要做的决定是选择视觉编码器这也是我在这篇文章里想重点展开的部分。3. 视觉编码选型从 ResNet 到 R3MLift-PH 的实践取舍3.1 robomimic 里的视觉编码器家族robomimic 把视觉编码器的实现集中在 VisualCore 这个抽象类下面你只需要在配置里指定 backbone_class 和 pool_class框架就会自动把图像观测编码成固定维度的特征向量。我整理了一下我实际用过的几种组合连同我的使用感受一起放在表格里编码器组合核心思路参数量与开销在 Lift-PH 上的实践感受ResNet18 SpatialSoftmax卷积提取特征再用空间 Softmax 得到关键点坐标中等单卡 12GB 可跑最稳的默认选择收敛快对数据量要求不高ResNet18 Global Avg Pool卷积后全局平均池化得到特征向量中等同上特征丢失空间信息Lift 任务表现略逊于 SpatialSoftmaxViTVision Transformer图像切 patch 后走 Transformer较大训练慢效果好但需要更多数据和更精细的调参教学复现不建议新手直接用R3M / MVP 预训练模型用互联网视频预训练好的视觉表征冻结或微调权重文件大显存占用高在小数据场景有优势但需要额外准备权重文件链路更长从这张表能看出来我最终在阶段 7 选的是 ResNet18 SpatialSoftmax 这个组合也就是 robomimic 文档里常说的 RSS 编码器。理由很朴素Lift-PH 的训练数据量属于“中等偏小”ResNet18 在这种规模下不容易过拟合训练速度快而 SpatialSoftmax 相比全局平均池化保留了空间位置信息——抓取任务恰恰非常依赖“物体在画面哪个位置”这个信息。3.2 预训练权重用不用冻结还是微调这里有一个在社区里经常吵起来的问题ResNet 的 backbone 要不要加载 ImageNet 预训练权重加载之后是冻结还是微调我的实践结论是加载预训练权重并且让 backbone 参与微调但把 backbone 的学习率调得比策略网络低一些。为什么加载预训练权重因为 Lift-PH 的图像虽是仿真渲染但底层的边缘、纹理、形状特征和自然图像有共通之处。预训练权重相当于给网络一个“已经会看基础视觉特征”的起点从这一步开始学抓取比从随机初始化开始学要快得多。为什么不全冻结因为仿真图像的颜色分布、渲染风格和 ImageNet 差距不小完全冻结会导致特征偏移策略对仿真环境的过拟合反而更严重。在具体实现上你可以在配置里给 backbone 单独设置共享学习率倍数。我用的方案是策略网络主学习率 1e-4backbone 的学习率倍率设为 0.1相当于 backbone 每步只走 1e-5。这样既能利用预训练特征又不会因为大学习率把预训练权重冲乱。3.3 编码器配置文件怎么写一段可复制的核心配置下面是我在阶段 7 实际使用的编码器配置整体符合 robomimic 的 JSON 配置规范。具体字段在不同版本里可能稍有出入但结构是大致固定的observation: { modalities: { obs: { low_dim: [ robot0_eef_pos, robot0_eef_quat, robot0_gripper_qpos ], image: [ agentview_image, robot0_eye_in_hand_image ] } }, encoder: { image: { core_class: VisualCore, core_kwargs: { backbone_class: ResNet18Conv, backbone_kwargs: { pretrained: true, input_coord_conv: false }, pool_class: SpatialSoftmax, pool_kwargs: { num_kp: 32, learnable_temperature: false, temperature: 1.0 }, flatten: true, feature_dimension: 64 } } }, crop_randomization: true, crop_height: 160, crop_width: 160 }几个字段我解释一下num_kp 是 SpatialSoftmax 输出的关键点数量32 在 Lift 上是一个比较中庸的值关键点太少模型“看不太清”太多容易过拟合feature_dimension 是最终每个视角输出的特征维度我设为 64两个视角一共 128 维再拼接低维状态对后面 MLP 来说输入规模非常友好。crop_randomization 打开后训练时每个 step 的裁剪位置会随机相当于免费的数据增强。提示不要小看 feature_dimension 这个字段。它决定编码器输出和策略网络输入之间的接口维度改一次意味着整个网络结构都要重新训练。在动手之前想清楚比你训到一半再改要省时得多。4. 正式训练配置、启动、监控中的关键细节4.1 一份完整的 Vision BC 训练配置有了编码器配置剩下的训练参数就好办了。我把训练相关的配置也一并列出来你可以直接把这些和上面的 encoding 配置合到同一个 JSON 文件里{ experiment: { name: lift_ph_bc_vision, output_dir: ../../results, save_interval: 1, rollout: { enabled: true, n: 30, horizon: 500, rate: 50 } }, train: { num_epochs: 200, batch_size: 64, optimizer: { type: adamw, lr: 0.0001, weight_decay: 0.0001 }, data: { dataset: ../../datasets/lift/ph/lift_ph.hdf5 }, num_data_workers: 4 }, algorithm: { type: bc, bc: { loss: { type: l2 } } } }这里有个很关键的设计experiment.rollout.enabled 设为 true意思是训练过程中每隔一定 epoch 就在仿真环境里自动做一次 rollout用当时的策略去跑若干条新轨迹实时记录成功率。这个功能是我在阶段 5 之后才养成的习惯——与其等到 200 个 epoch 全训完才发现策略发散不如让训练过程每隔一阵就告诉你“现在这个策略行不行”。rollout.rate 控制每多少个 epoch 做一次评估我一般设 50也就是说第 50、100、150、200 个 epoch 都会自动跑一次评估日志里看趋势非常直观。4.2 训练启动命令与日志解读配置写好后训练启动命令非常简单cd /path/to/robomimic python train.py --config configs/lift_ph_bc_vision.jsonrobomimic 会在 output_dir 下按实验名生成一个带时间戳的目录里面包含 config.json 备份、日志文件、模型权重和 rollout 的视频。日志同时会走 TensorBoard你可以用tensorboard --logdir ../../results/lift_ph_bc_vision然后在浏览器里看训练曲线。我重点看的指标有三个BC loss、gradient norm、以及 rollout 成功率。BC loss 在训练初期通常会快速下降然后进入一个平台期这是正常的你要警惕的是 loss 突然反弹或者剧烈震荡。gradient norm 则是一个很好的“健康信号”如果它突然飙到很大的数值通常意味着学习率偏高或者 batch 里有异常样本。再强调一次 rollout 成功率和训练 loss 的关系BC 是一种监督学习方法loss 反映的是“模型输出动作和演示动作的差距”但 loss 低不代表策略在环境里表现好——有可能模型只是学会了所有训练轨迹的平均动作而在真实 rollout 时一个方块都抓不起来。这也是我不厌其烦要求开 rollout.enabled 的原因它让你在一个训练过程中就能同时看到“模仿精度”和“任务表现”两个维度。4.3 训练资源规划与显存优化Vision BC 的显存压力主要来自图像 batch。12GB 显存跑 batch_size 64、图像 160×160 是稳的如果你的显卡只有 8GB我建议优先把 batch_size 降到 32其次是 crop 尺寸降到 128×128。记住一个原则先保 rollout 能跑再保训练速度最后再考虑精度。num_data_workers 这个参数也值得说一下。它控制 DataLoader 用几个子进程来读 HDF5 数据。图像数据读取是 IO 密集型的worker 太少会导致 GPU 经常空转太多则可能因为数据搬运开销反而变慢。我在 16 核机器上通常设为 4 到 8具体可以自己扫一遍。还有一个容易踩的坑是日志和视频写入占满磁盘。robomimic 在 rollout 时会保存视频如果 rollout.n 设得比较大、视频分辨率又高跑几十个 epoch 之后 output 目录可能膨胀到几个 GB。我一般会在训练前用 df -h 看一眼磁盘余量并且定期清理旧视频只保留有代表性的几条。5. 故障恢复训练中断、OOM、NaN 和数据集异常的排查清单5.1 从断点续训说起checkpoint 的正确用法训练到一半断了这是所有深度学习项目里最常见也最恼火的问题robomimic 的故障恢复能力其实做得不错但你得知道它把信息保存在哪里。权重文件默认保存在实验目录下的 checkpoint 子目录里文件名为 model.pt 或者带 epoch 后缀的模型文件。恢复训练的命令是python train.py --config configs/lift_ph_bc_vision.json \ --resume ../../results/lift_ph_bc_vision/timestamp/checkpoints/model.pt注意--resume 接收的是 .pt 权重文件路径robomimic 会从里面恢复模型参数、优化器状态、当前 epoch 数以及一些训练进度信息。恢复之后你会发现日志里的 epoch 从断点继续而不是从头开始。这里有一个很容易疏忽的点如果你在断点之后修改了配置文件再 resumerobomimic 会尝试用新配置继续训练。大多数配置项可以安全修改但和网络结构相关的字段——比如 feature_dimension、num_kp、图像 crop 尺寸——一旦改了旧权重就加载不上了。所以我的习惯是配置写完后复制一份到实验目录做备份中途只调学习率这类不影响结构的参数结构相关的改动一律开新实验。5.2 三个我在阶段 7 里真实踩过的故障第一个是 CUDA out of memory。这个报错最常见的形式是训练跑了一小段之后突然崩掉提示 CUDA OOM。我遇到的原因不是 batch_size 太大而是 rollout 和训练同时启动时显存叠加。解决方法是把 rollout.n 调小或者把 rollout 的评估挪到训练结束后单独跑。如果你在训练过程中必须开 rollout至少把 batch_size 留出 20% 的显存余量。第二个是 loss 变成 NaN。这在视觉任务里比低维任务更容易发生因为图像特征的值域天然比状态向量大。我排查的顺序是先看是不是学习率过高把 lr 从 1e-4 降到 3e-5再看数据里有没有 NaN 或者 Inf打印数据集的统计量确认最后检查是否开启了 weight_decay 且数值过大。90% 的 NaN 问题出在数据或学习率上。第三个是观测键不匹配。前面提到过配置文件里的图像键名和数据集里的实际键名必须完全一致。报错信息通常会明确告诉你是哪个键找不到但有一种隐蔽情况是两个视角的顺序反了模型不会报错成功率却莫名其妙低。排查方法很简单在训练前写一小段脚本加载数据集把配置里的 obs 键逐一对一遍最稳妥。5.3 故障恢复的操作顺序清单我把故障恢复的排查流程整理成固定顺序每次出问题就按这个顺序过一遍效率比随机尝试高很多步骤检查项具体操作1磁盘空间df -h 查看 output 目录所在分区清理过期视频和日志2数据集完整性重新运行数据体检脚本确认图像、动作、键名正常3日志定位打开 TensorBoard 或文本日志确认故障发生前的最后一个正常 step4资源占用nvidia-smi 查看显存确认没有其他进程占卡5配置对比和实验目录下备份的 config.json 对比确认没有误改结构字段6降级启动先关 rollout、减 batch_size确认训练能稳定跑起来再逐步加回来这个顺序背后的逻辑是先排除环境问题再排除数据问题最后才是模型和配置问题。我在这个阶段至少省下了两三个小时的无效排查时间。6. 评估与回放Rollout 指标解读和策略迭代闭环6.1 跑一次正式评估的正确姿势训练结束后robomimic 会自动保存最终的模型权重最靠谱的评估方式是用它自带的 run_trained_agent.py 脚本在独立于训练过程的环境里做一次干净的 rolloutpython run_trained_agent.py \ --agent ../../results/lift_ph_bc_vision/timestamp/checkpoints/model.pt \ --episodes 50 \ --horizon 500 \ --video_path ./eval_videos/lift_ph_bc_vision.mp4这里有几个参数值得解释。episodes 是一次评估里跑多少条新轨迹这个数字不能太小我说一个最直观的理由如果成功率是 80%跑 10 条轨迹可能会有 8 条成功但也会有 2 条失败跑 50 条你才能比较有信心地说这个策略的“真实水平”接近 80%。我一般至少跑 50 条条件允许的话跑 100 条。horizon 是每条轨迹的最大步数上限。Lift 任务正常的成功轨迹通常在几十步内完成500 步的 horizon 已经足够宽松主要是给那些卡住的策略一个“超时判负”的出口。评估脚本会输出每个 episode 的累计回报、是否成功、步数等信息最后汇总成一个统计表。6.2 指标怎么读成功率之外还要看什么面对评估输出第一反应肯定是看成功率但只看成功率会漏掉很多信息。我习惯把下面三个指标组合起来读成功率是最直观的定义为 50 条轨迹里完成任务的比例。平均累计回报能反映“虽然没有成功但策略离成功有多近”如果一个策略成功率只有 30% 但平均回报很高说明它明白大致该怎么做只是最后一步不精确这种策略有救。轨迹长度分布则暴露策略的效率问题——如果平均要 400 步才完成而演示平均只要 80 步说明策略是在“磨”而不是在“做”。还有一个被很多人忽略的信号是失败模式。你最好把评估视频保存下来然后花一点时间逐条看失败的轨迹。我在阶段 7 第一次跑完评估的时候成功率只有 50% 出头看视频发现失败轨迹几乎都卡在同一个位置——机械臂能到达方块上方但夹爪张开时机太晚导致与方块擦肩而过。这个信息从任何数值指标里都看不出来但它直接决定了你下一步该怎么调。6.3 从评估结果反推修改方向评估结果不是终点而是下一轮迭代的起点。我会按下述逻辑决定下一步动作如果成功率低于三成优先怀疑数据或编码器。先做一组消融把图像分辨率调高、把裁剪关闭试试如果还是不涨换更大的预训练 backbone 或者换 R3M 权重但要做好训练变慢的心理准备。如果成功率中等但轨迹长、动作犹豫优先怀疑 loss 设置或者学习率。BC 的 L2 loss 鼓励“平均动作”如果演示里同一个场景有不同风格的动作模型可能学出一个中间值导致动作缓慢。可以试试把 loss 换成负对数似然NLL或者在数据里过滤掉步骤数过长、风格过于极端的轨迹。如果成功率不错但少数轨迹出现诡异的震荡优先怀疑图像增强。crop_randomization 虽然能提升泛化但裁剪范围过大可能让模型看到不完整的工作台。把裁剪幅度调小通常能像止痛药一样立竿见影。我自己的阶段 7 最终迭代路径是第一轮训练成功后成功率在 50%通过看视频锁定夹爪时机问题第二轮把 num_kp 从 32 提到 48并把 crop 幅度略微调小成功率到了 75% 左右第三轮降低 backbone 学习率到原来的三分之一训练多跑了 50 个 epoch最终稳定在了 80% 以上的水平。这个水平虽然和官方 benchmark 里一些更强算法的成绩还有差距但作为教学型复现已经达到了我想要的目的——它证明了视觉信息确实能被 BC 策略有效利用也验证了从数据到评估这条链路本身是通的。最后再分享一个我个人的工作习惯。在阶段 7 之后我每跑一个实验都会在 results 目录下新建一个 notes.md用两三句话记录当前实验改了哪个字段、成功率是多少、看视频发现了什么现象。这个习惯帮我避免了很多“这个实验之前好像跑过但忘了结果”的尴尬尤其是当你要在编码器、学习率、关键点数量这几个维度上反复横跳的时候一个清晰的实验日志比任何高级工具都管用。
