一条命令完成跨仿真迁移：Isaac Gym 策略搬进 Mujoco 的 Unitree RL GYM 实操

一条命令完成跨仿真迁移：Isaac Gym 策略搬进 Mujoco 的 Unitree RL GYM 实操

【免费下载链接】unitree_rl_gym项目地址: https://gitcode.com/GitHub_Trending/un/unitree_rl_gym

Isaac Gym 里跑得稳的行走策略，换个仿真器就站不稳，PD 参数还得重新摸。Unitree RL GYM 的跨仿真迁移把这件事压成一条命令：核对好一个 yaml，Mujoco 里的力矩控制、观测维度自动对齐，Isaac Gym 导出的策略原样加载就能跑，不用重训。

跨仿真迁移省下的不是代码，是重复调参

一条命令 + 一个 yaml 到底做了什么

三句话讲清方案：deploy_mujoco.py用torch.jit.load加载 Isaac Gym 导出的策略；每个控制步按 yaml 里的kps/kds算 PD 力矩、按同一套 scale 拼观测喂给策略；控制频率、观测维度都对齐后，策略无需重训即可在 Mujoco 中运行。

关键在"参数照表核对"而非"逐项试错"：

Isaac Gym 转 Mujoco 前，先定位这 3 个关键文件

部署入口 deploy_mujoco.py：整个迁移的驱动循环

deploy_mujoco.py 是迁移的执行主体。它加载 xml 场景、加载策略、进入被动 viewer 主循环：每control_decimation个仿真步做一次策略推理、更新目标关节位置，再持续用 PD 力矩驱动物理。你改配置、看现象，都围绕这个文件。

机器人策略迁移配置：yaml 里 PD 参数和观测 scale 的总表

g1.yaml 一张表说清迁移需要的一切：policy_path、xml_path、kps/kds、default_angles、action_scale、各观测scale、num_actions/num_obs、初始指令cmd_init。G1/H1/H1_2 各有一份，都在deploy/deploy_mujoco/configs/下。

预训练模型 motion.pt：策略权重从哪来

默认策略在deploy/pre_train/g1/motion.pt（该目录按型号分 g1、h1、h1_2 三份）。自训模型用 play 导出后，把 yaml 的policy_path指过去即可。

🔧 跨仿真迁移实操：配置、加载、验证三步跑通

配置：yaml 里的 kps/kds 为什么必须和训练时一致

这段是 g1.yaml 的真实参数，对应 G1 在 Isaac Gym 训练时的那套 PD 增益和动作缩放。

simulation_dt: 0.002 control_decimation: 10 # simulation_dt * control_decimation = 0.02 -> 50Hz kps: [100, 100, 100, 150, 40, 40, 100, 100, 100, 150, 40, 40] kds: [2, 2, 2, 4, 2, 2, 2, 2, 2, 2, 2, 2] default_angles: [-0.1, 0.0, 0.0, 0.3, -0.2, 0.0, -0.1, 0.0, 0.0, 0.3, -0.2, 0.0] action_scale: 0.25 ang_vel_scale: 0.25 dof_pos_scale: 1.0 dof_vel_scale: 0.05 cmd_scale: [2.0, 2.0, 0.25] num_actions: 12 num_obs: 47 cmd_init: [0.5, 0, 0]

这些值不是拍的：kps/kds与训练侧 g1_config.py 的stiffness/damping逐关节一致（hip 100、knee 150、ankle 40，damping 2/4/2），default_angles、action_scale也逐项对应。策略是在这套控制律下学出来的，换环境就照抄，控制行为才不变。control_decimation按 yaml 注释保持simulation_dt * control_decimation = 0.02，即 50Hz 控制频率。

加载：torch.jit.load 与 PD 力矩转换

这段pd_control来自部署入口，是把"位置目标"翻译成"Mujoco 力矩"的核心。

def pd_control(target_q, q, kp, target_dq, dq, kd): """Calculates torques from position commands""" return (target_q - q) * kp + (target_dq - dq) * kd

Isaac Gym 训练时control_type = 'P'，动作经action * action_scale + default_angles变成位置目标再走 PD；Mujoco 侧target_dof_pos = action * action_scale + default_angles，再交给上面这个函数出力矩。两边控制链一致，策略输出才"认"。

验证：跑起来后看什么

这段是 G1 的运行命令，其余型号把参数换成h1.yaml/h1_2.yaml。

python deploy/deploy_mujoco/deploy_mujoco.py g1.yaml

跑起来后重点看三点：机器人是否按cmd_init（前向 0.5 m/s）行走而不摔；关节是否平滑、无高频抖动；步态相位周期是否与训练一致（代码里period = 0.8，与训练侧h1_env.py的 0.8s 相同）。num_obs=47（G1）/41（H1）必须与训练侧num_observations相等，否则观测向量对不上。

⚠️ 翻车自救：抖动、加载失败、观测不匹配的对症清单

先对照这张三列表

调 PD 参数怎么从抖到稳

抖动先降kps再微调kds，而不是两者同时动。目标不是"越大越稳"，而是让 Mujoco 的力矩响应贴近 Isaac Gym 训练时的stiffness/damping；对齐了，抖动自然消失。

从 Sim2Sim 到 Sim2Real：这一步为什么值得做

为什么先过 Mujoco 再上真机

• 验证泛化：README 把流程定为Train → Play → Sim2Sim → Sim2Real，Mujoco 用来确认策略没过度依赖 Gym 的物理特性。
• 风险前置：在 CPU 的 Mujoco 里暴露的问题，比真机上摔倒更早、代价更低。
• 配置复用：Mujoco 验证过的kps/kds与观测 scale，可直接服务 deploy_real 的真机部署，减少二次调参。

行动清单：

1. 核对 yaml 的kps/kds/default_angles/action_scale与训练侧 config 逐项一致
2. 确认num_obs、num_actions与训练num_observations/num_actions相等
3. 保持simulation_dt * control_decimation = 0.02（50Hz）
4. 先用torch.jit.load验证policy_path可加载，再跑起来看是否按cmd_init行走
5. 抖动就降kps对齐训练stiffness，不要同时乱动kds

【免费下载链接】unitree_rl_gym项目地址: https://gitcode.com/GitHub_Trending/un/unitree_rl_gym