Diffusion Policy 实战：从零把扩散模型机器人策略跑通并部署，附我踩过的 7 个坑

Diffusion Policy 实战：从零把扩散模型机器人策略跑通并部署，附我踩过的 7 个坑

【免费下载链接】diffusion_policy[RSS 2023] Diffusion Policy Visuomotor Policy Learning via Action Diffusion项目地址: https://gitcode.com/gh_mirrors/di/diffusion_policy

你有没有过这种经历：费尽心思让机械臂学会"推一个 T 形块"，传统方法要么在任务稍有变化时就翻车，要么动作僵硬得像提线木偶？我最初的方案是训练一个"输入状态、直接输出动作"的网络，结果它在多模态动作分布面前彻底摆烂——同一个起点，明明该向左绕，它却总在中间"和稀泥"。直到我遇到 Diffusion Policy，这个来自 RSS 2023 的视觉运动策略方法，才真正体会到什么叫"动作也能用扩散生成"。这篇实战复盘，我从模拟环境一路干到真实 UR5 机械臂，把每个关卡的关键点都记下来了。

Diffusion Policy 到底是什么：一句话版

简单说，Diffusion Policy 把"机器人该输出什么动作"这件事，从"直接猜一个答案"变成了"从一团噪声里逐步打磨出答案"——就像画家不是一笔画出全貌，而是从模糊轮廓层层细化。类比到开车：普通策略是"看到路口就猛打方向盘"的莽撞新手，Diffusion Policy 则像一位会预判路况的老司机，基于最近几帧观测，推演出接下来一小段连贯的驾驶轨迹再执行，天然更平滑、更抗干扰，还能处理"同样场景有多个合理走法"的多模态情况。

动手前，先对照这份门槛清单

• 硬件：一台带 NVIDIA GPU 的 Linux 机器（模拟实验最低门槛）；若要复刻真实机器人部分，还需 UR5（支持 RTDE 接口）、2 台 RealSense D415、SpaceMouse 遥操作设备
• 软件：Ubuntu 20.04、Mambaforge/conda、RealSense SDK、spacenavd 守护进程
• 知识储备：PyTorch 基础、diffusion model 的直觉理解（知道"前向加噪、反向去噪"即可，不必深究数学）、会用 Hydra 配置
• 心态：准备好面对"第一次训练曲线不涨"的现实，这很正常

第一关：20 分钟跑通最小示例，先看到第一个结果

这一关的目标只有一个：让模型在模拟的 Push-T 任务里学会推块，并在终端看到成功率数字。别急着上真机，模拟环境是你最快建立信心的沙盘。

先克隆仓库并安装环境（参考conda_environment.yaml与 README 的安装指引）：

git clone https://gitcode.com/gh_mirrors/di/diffusion_policy cd diffusion_policy sudo apt install -y libosmesa6-dev libgl1-mesa-glx libglfw3 patchelf mamba env create -f conda_environment.yaml conda activate robodiff

接着按 README 指引把官方提供的 pusht 训练数据下载并解压到data/目录（数据体积不大，训练时会整体读入内存）。然后启动训练：

python train.py --config-name=train_diffusion_unet_lowdim_workspace

这条命令背后发生了什么？train.py通过 Hydra 加载diffusion_policy/config/train_diffusion_unet_lowdim_workspace.yaml，它会自动带上pusht_lowdim任务配置，构造数据集、策略网络和训练循环。预期看到：每 50 个 epoch 自动做一次 rollout 评估，日志里出现test/mean_score稳步爬升，最终逼近 0.9 以上；同时在data/outputs/下生成带时间戳的目录，里面躺着 checkpoints 和评估视频。

可能卡在哪：训练前若未执行wandb login，日志上报会报错中断——可以先登录，或把配置里logging.mode改为offline。另外提醒一句，num_epochs默认 5000，但一般几百个 epoch 就能看到明显效果，不必死等。

第二关：接入真实数据，把策略从模拟搬到现实

模拟跑通只是热身。真正的分水岭在于：你手里的数据来自真实机器人，观测是相机画面而不是精确坐标，动作还带着延迟。这一关我会拆成两半讲，先说数据采集，再说为什么"延迟"是真实部署的核心矛盾。

用 SpaceMouse 采集演示数据

项目提供了demo_real_robot.py采集脚本，逻辑非常简单：按C开始录制，你用 SpaceMouse 推着机械臂演示，按S停止，一条演示就存进了data/demo_pusht_real/replay_buffer.zarr。这个 zarr 文件的结构值得记住：

• data/action：每个时间步的机械臂动作
• data/color、data/robot_state：多相机画面与机器人状态
• meta/episode_ends：标记每条演示在哪结束

为什么用 zarr 而不是一堆 png？因为训练时要按"观测窗口 + 动作窗口"切片采样，连续数组配合meta/episode_ends才能高效定位每条演示的边界。这个设计在diffusion_policy/common/replay_buffer.py里实现，是理解整个数据管线的钥匙。

理解延迟：真实部署的核心矛盾

真实机器人和模拟器最大的区别是异步。gym里step()一步一停的同步模式在真机上根本跑不动——相机采集、模型推理、关节插补各自有耗时。项目用两条共享内存结构化解了这个问题（见diffusion_policy/shared_memory/）：

• SharedMemoryRingBuffer（FILO）：5 个相机进程持续往里面写帧，主进程随时能取到"最近几帧"——这就是观测来源；
• SharedMemoryQueue（FIFO）：策略预测出的整段动作序列，一次性丢给RTDEInterpolationController，机器人按时间戳顺序平滑执行。

这套设计让"观测"和"执行"彻底解耦，策略不必等机械臂做完动作才能看下一眼，这也是 Diffusion Policy 能跑到 10Hz 控制频率的底气。

真实部署的训练命令长这样，重点在于用task.dataset_path指到你刚采集的数据：

python train.py --config-name=train_diffusion_unet_real_image_workspace task.dataset_path=data/demo_pusht_real

关键配置项背后的为什么：diffusion_policy/config/task/real_pusht_image.yaml里定义了shape_meta，它声明了策略"看得见什么、动作是什么形状"——你换了相机布局，第一件事就是改这里；camera_serial_numbers必须和你realsense-viewer里看到的序列号一一对应，否则数据根本录不进去；obs_image_resolution建议保持与采集时一致，分辨率一变等于换了一个任务。

预期看到：训练 loss 下降，rollout 视频里机器人真的把 T 块推进目标区。可能卡在哪：最常见的是spacenavd没启动导致 SpaceMouse 无响应（systemctl status spacenavd检查），以及相机序列号写错导致录制脚本直接退出。

第三关：把策略调优到"真正可用"

模型能跑只是及格，要做到"成功率稳定、动作不抖"才算真正可用。我实践下来，优先级最高的调优点就三个：

1. 动作窗口（horizon / n_action_steps）决定"视野"默认horizon: 16、n_action_steps: 8的意思是：策略看 2 帧观测（n_obs_steps: 2），预测未来 16 步，但只执行前 8 步就重新规划。这就像开车只看前面 50 米，但每 25 米就重新评估一次路况。窗口拉长，轨迹更连贯但反应变慢；窗口缩短，反应快但容易抖。Push-T 场景下，8 步执行 + 滚动规划是性价比很高的组合。

2. 推理步数（num_inference_steps）是精度与延迟的权衡默认 100 步去噪，效果最好但真机上可能拖慢控制频率。如果机器人动作明显迟钝，可以逐步降到 50 步、甚至 20 步，配合 EMA 模型（配置里的ema段）做推理，往往能保住大部分精度。记得在diffusion_policy/policy/diffusion_unet_lowdim_policy.py里确认推理用的是ema_model而非原始权重。

3. 学习率与批大小别乱动，但调度器值得调lr: 1.0e-4+ cosine 调度 + 500 步 warmup 是官方验证过的组合，盲目加大学习率最容易让训练直接崩掉。真机上如果数据量少（比如只有几十条演示），可以考虑把batch_size从 256 调小，防止过拟合到个别演示上。

预期看到：成功率突破 90%，机器人动作行云流水。可能卡在哪：调低推理步数后成功率骤降——这说明问题不在步数，而在数据多样性，回去补演示数据更有效。

避坑指南：我踩过的 7 个坑，希望你绕开

1. 训练 loss 变 NaN：配置里variance_type如果用了论文里的fixed_small_log很容易数值爆炸，README 都特意注释了——改成fixed_small即可。
2. 子进程段错误（segfault）：EnvRunner用 fork 起子进程做并行评估，如果环境初始化时创建了 OpenGL 上下文，子进程继承后就会神秘崩溃。解决办法是按 README 提示提供不初始化 OpenGL 的dummy_env_fn。
3. 成功率"看起来"很高但行为很怪：九成是归一化（normalization）出了问题。LinearNormalizer的 scale/bias 参数是随 checkpoint 一起保存的，排查时直接打印这两个向量，看是不是出现了异常大的值。
4. 录制时机器人不动：先确认spacenavd在跑，再用realsense-viewer确认相机被识别，最后才怀疑代码——硬件问题占了八成。
5. 真实评测时动作延迟明显：别急着调推理步数，先检查是不是SharedMemoryRingBuffer的容量太小导致观测总是旧的，适当调大max_obs_buffer_size。
6. 换了新任务后训练不收敛：先检查shape_meta里的观测/动作维度是否与你的任务一致，维度对不上，网络结构再先进也白搭。
7. 评估输出目录已存在：eval.py会弹出交互式确认，脚本化运行时容易卡住——提前用不存在的目录路径即可。

效果说话：数据不会骗人

以 Push-T 任务为例，这是官方在低维状态输入下的评估数据（详见项目论文与实验日志）。multimodal_sim.png展示了不同策略在同一场景下的轨迹对比，效果差异一目了然：

用官方预训练 checkpoint 跑eval.py，输出的eval_log.json里test/mean_score能到0.915，对应成功率约 87%+；而官方完整训练在模拟 Push-T 上成功率可达 90% 以上。作为对比，传统显式策略在同类任务上通常只有 60%-70%。这套机制对比图能帮你快速理解为什么扩散策略更优：

进阶方向：这三个玩法值得深挖

• 换骨架：把 1D U-Net 换成 Transformer 做扩散（见diffusion_policy/model/diffusion/transformer_for_diffusion.py），长时序动作预测能力更强，官方有对应的 hybrid workspace 配置可以直接试。
• 图像输入而非坐标：把观测换成多相机 RGB（参考diffusion_policy/policy/diffusion_unet_hybrid_image_policy.py），配合随机裁剪增强，泛化性会有质的提升。
• 多任务扩展：仓库的架构把 Task 与 Method 解耦（dataset/env_runner/policy/workspace四层），照着diffusion_policy/config/task/里的模板加一个新任务，比想象中简单得多。

写在最后

我常对新人说一句话：别在模拟器里待太久，也别在真机上赌运气。Diffusion Policy 的价值恰恰在于——它在模拟里训练出的直觉，能近乎无损地迁移到真实机器人上，这种"模拟到现实"的顺滑感，是它最打动我的地方。

下一步很明确：克隆仓库，跑通第一关的模拟训练，让test/mean_score跳到 0.9 以上。当你亲眼看到那台机械臂流畅地把 T 形块推进目标区时，你会回来感谢此刻行动的自己。

【免费下载链接】diffusion_policy[RSS 2023] Diffusion Policy Visuomotor Policy Learning via Action Diffusion项目地址: https://gitcode.com/gh_mirrors/di/diffusion_policy