同一个控制器，两个物理引擎：启元 Q1 的 MuJoCo 与 PyBullet Sim2Sim 对比实录

一句话导读：把在 MuJoCo 里调好的 PD 站位控制器原样搬进 PyBullet，机器人直接摔了。这篇文章记录整个排查过程——三个引擎行为差异的坑、一套两引擎对齐的方法、以及最终"同一控制器跨引擎误差只差 0.004°"的对齐结果。Sim2Real 之前，先过 Sim2Sim 这一关。所有数据来自本机一次运行，代码与结果可复现。

题图｜对齐完成后，同一个 22 关节 PD 控制器在 MuJoCo（蓝）与 PyBullet（橙）里的站位跟踪误差：峰值 0.511° 对 0.515°，曲线几乎重合。这是本文全部排查工作的终点，也是起点——对齐之前，两者一个站着、一个摔着。

1. 为什么要做 Sim2Sim

我写的《让启元 Q1 在仿真里站起来》在 MuJoCo 里完成了一套完整实验：PD 站位、刚度扫描、50 N 抗扰、蹲起轨迹。结尾留了一个尾巴——仿真里的控制器离真机还差什么。

差的第一关不是真机，是另一个仿真。这是具身智能开发里越来越现实的场景：强化学习普遍在 Isaac Gym / Isaac Lab 里训练，部署验证常用 MuJoCo 或 PyBullet；开源策略的复现往往撞上"论文用 A 引擎、我只有 B 引擎"的问题。**控制器从一个物理引擎迁移到另一个，行为会变吗？变多少？哪里要改？**这组问题就是 Sim2Sim，它比 Sim2Real 便宜得多——不涉及任何硬件，却能提前暴露大部分"换环境就崩"的问题。

本文的实验设定刻意做到最苛刻：两边的机器人模型都是启元官方文件（MuJoCo 用官方 MJCF，PyBullet 用官方 URDF，一个字节都不改）；控制器是同一套关节空间 PD，增益、目标角、力矩限幅完全相同；重力、初始姿态（骨盆 0.419 m 全零关节角）、地面接触全部对齐。剩下的差异，就全是引擎和模型管线的了。

先给结论：

1. 模型层：两份官方文件描述的是同一台机器人（总质量 16.917 kg、22 个可动关节、连杆几何逐项一致），但 MJCF 的关节带 armature=0.004（转子惯量），URDF 没有——这个 4 克·平方米的差异最终决定了控制器能不能直接迁移。
2. 引擎层：PyBullet 的 URDF 加载有默认速度电机（会吞掉力矩指令）、默认摩擦 0.5（MuJoCo 是 1.0）、getLinkState[0] 返回质心而不是连杆坐标系——三个坑每一个都足以让对比实验得出错误结论。
3. 对齐结果：同步长 0.5 ms + 踝/腰 kd 适配后，准静态任务（站位、刚度扫描）两引擎逐项一致，动态任务（蹲起）出现可解释的分化。

2. 环境与模型：先确认两边是同一台机器人

MuJoCo 端沿用上一篇环境：Windows 11 x64、Python 3.12.10、MuJoCo 3.17.0、NumPy 2.5.4。PyBullet 端有一个现实问题：PyBullet 从不发 Windows 预编译包，pip 安装会现场编译、要求 Visual C++ Build Tools（几个 GB）。绕开方式是 conda-forge 的预编译包：

:: 安装 Miniforge（用户级，无需管理员）后：
mamba create -y -n q1pb -c conda-forge python=3.11 pybullet numpy matplotlib

装好的是 bullet-cpp 3.25 引擎 + pybullet 绑定。两套解释器各管各的引擎，主脚本负责调度。

模型检查是第一道关口。PyBullet 加载官方 urdf/q1_v3.urdf（SHA-256 a4e0f017…），MuJoCo 用官方 xml/q1_v3_mc.xml（SHA-256 d9442f0d…，与上一篇同一份）：

图 1｜PyBullet 端模型检查输出：22 个可动关节、总质量 16.917 kg——与 MuJoCo 端逐项一致。两份官方文件描述的是同一台机器人。

交叉核对还做了更深的一层：用 MuJoCo 直接编译官方 URDF，与官方 MJCF 对比零位连杆坐标——髋、膝、踝的相对位置逐项相同（髋 +0.0214 m、膝 −0.1885 m、踝 −0.3785 m，骨盆坐标系）。结论：模型运动学等价，两份文件只差引擎特有的参数（MJCF 有 armature，URDF 有速度限位字段，后面都会讲到它们的影响）。

这里顺便记录本次排查中最迷惑的一个假差异：最初对比零位连杆高度时，PyBullet 显示骨盆比 MuJoCo 高 4.9 cm，一度怀疑两份模型的运动学不一致。查了两小时才发现——PyBullet 的 getBasePositionAndOrientation 和 getLinkState[0] 返回的是连杆质心（COM），不是 URDF 连杆坐标系；骨盆的惯性原点恰好偏移 +0.049 m（URDF 里写着 inertial origin z=0.049044），三个连杆的"错位"全部对上。URDF 坐标系在 getLinkState[4]。跨引擎量几何，先统一坐标系口径，否则会得出"引擎运动学不一致"的假结论。

另外两个环境坑也值得记下（Windows 用户会遇到）：中文路径下 PyBullet 的 C++ 层同样打不开 URDF（与 MuJoCo 同款问题，用 ASCII 目录副本解决）；Path.resolve() 会把 junction 目录还原成中文真实路径，所以实验脚本里用 Path.absolute() 而不是 resolve()。

3. 三个引擎行为差异：每一个都足以让实验翻车

3.1 默认速度电机：力矩指令被静默吞掉

第一个坑来自 PyBullet 的 URDF 加载行为。零输入基线实验（22 关节全零力矩）在 PyBullet 里机器人纹丝不动地站着，俯仰只晃 7.8°；同样的实验在 MuJoCo 里 0.6 秒摔倒。机器人不该站着——除非每个关节都被抱死。

原因：PyBullet 加载 URDF 后，每个可动关节默认挂着一个速度保持电机（目标速度 0，最大力矩取自 URDF 的 effort 字段，Q1 是 36 N·m）。不显式关闭，关节实际处于"抱死"状态：

# 正确姿势：先关默认电机，再用力矩控制
p.setJointMotorControl2(robot, j, p.VELOCITY_CONTROL,
                        targetVelocity=0, force=0)     # 解除抱死
p.changeDynamics(robot, j, linearDamping=0.0, angularDamping=0.0)
...
p.setJointMotorControl2(robot, j, p.TORQUE_CONTROL, force=tau)

验证实验：固定基座下对单个髋偏航关节挂 1 N·m 恒定力矩——关闭默认电机后关节加速摆到限位（+1.5708 rad，符合自由摆预期）；不关闭则角度恒为 0，力矩被默认电机完全抵消。MuJoCo 没有这个行为：data.ctrl 写什么就是什么。这个差异在 Bullet 的官方文档里有提到，但不踩一次很难有体感。

3.2 默认摩擦：脚底打滑

对齐默认电机后，零输入恢复正常（0.43 s 摔倒），但 PD 站位仍然失败，且失败模式是扭转：髋偏航关节误差 28°、躯干偏航角持续增长——机器人原地拧麻花。MuJoCo 里同样的 PD 误差不超过 0.01°。

嫌疑锁定摩擦：Bullet 默认滑动摩擦 0.5，MuJoCo 默认 1.0。站立平衡本质上靠脚底摩擦力矩撑住，摩擦减半意味着支撑力矩减半。把地面和全部连杆的 lateralFriction 统一设为 1.0 后，扭转消失——失败模式变成向前倾倒（下一节的正主）。

3.3 armature 缺失：kd=8 在 Bullet 里数学上就不稳定

这是本文最有价值的一个发现，值得完整展开。

摩擦对齐后 PD 站位还是倒，末端俯仰 86°。固定基座测试显示踝关节俯仰误差发散到 32°，关节速度尖峰 1500 rad/s——典型的数值振荡。逐项排查：求解器迭代数（50→200）无改善、接触刚度软硬两端都试过无改善、加大 kd 更糟。最后对比两引擎的踝关节等效惯量：

• MuJoCo（MJCF）：dof_M0 = 0.006744 kg·m²，其中包含 armature = 0.004（官方 MJCF 给每个关节配的转子惯量），连杆自身贡献只有 0.0027；
• Bullet（URDF）：没有 armature 概念，等效惯量就是连杆自身的 0.0027。

显式/半隐式积分下，关节 PD 的阻尼项有一个离散稳定边界：kd < 2M/dt。代入数字：

• MuJoCo：kd < 2 × 0.0067 / 0.001 = 13.4，kd=8 ✓ 稳定；
• Bullet（1 ms）：kd < 2 × 0.0027 / 0.001 = 5.4，kd=8 ✗ 发散。

也就是说，上一篇调好的 kd=8 之所以能工作，部分功劳属于 MJCF 里的 armature——它把踝关节惯量提高了 2.5 倍，撑大了稳定边界。这个参数在"写控制器"时完全隐形，只在"换引擎"时显形。

4. 对齐方案：同步长 + 一处增益适配

按稳定边界倒推对齐方案：

1. 步长统一到 0.0005 s（两引擎一致）。Bullet 端边界变为 kd < 10.8，kd=8 理论上过线，但实测自由站立在 kd≥5 时仍发散——脚底接触约束与关节阻尼耦合后，实际安全界比理论更紧。
2. 踝/腰 kd 8→4（仅 Bullet 端）。扫描验证：kd=9/8/6/5 全倒，kd=4 稳定，且站位误差 0.515°，与 MuJoCo 的 0.511° 几乎重合。其余增益（髋膝 150/12、肩肘 40/3、踝腰 kp=100）两引擎完全一致。
3. 摩擦、默认电机、坐标系口径按 3.1/3.2 节处理。

这套适配的真实含义值得说清楚：它不是"为了让 Bullet 不摔而乱调参"，而是把"控制器针对哪个动力学模型整定"这件事显式化了。真机迁移时会发生同样的事——真机关节有转子惯量和减速器摩擦，等效惯量比 URDF 描述大，仿真里调好的 kd 到真机可能偏大或偏小。Sim2Sim 的意义正是提前量化这个差距：本文里它表现为踝部 kd 的 2 倍适配。

5. 实验 1：零输入自由运动——分化的被动动力学

对齐后的第一组实验是零输入：不给任何控制，机器人从站立姿态自由倒下。这一组没有控制器掺和，纯粹对比引擎的被动动力学。

图 2｜零输入实验的终端输出：MuJoCo 0.605 s 躯干俯仰超 45°，末态仰卧（-174.6°，骨盆停在 0.240 m）；PyBullet 0.43 s 越过 45°，末态趴地（骨盆 0.083 m）。

图 3｜两引擎的躯干俯仰曲线：0~0.3 s 段几乎重合（都向前倾），0.3 s 后分化——MuJoCo 在 0.5 s 附近被脚掌/腿部结构缓冲成一个"半仰卧"姿态，Bullet 则一路前扑贴地。虚线为 ±45° 跌倒判据。

数字上的差异：倒地判据（|俯仰|>45°）触发时刻 0.605 s 对 0.43 s，差 0.18 秒；末态一个仰卧一个趴地。同一个初始姿态、同一份重力，被动倒地过程在两个引擎里从 0.3 秒后开始分叉——起因是接触求解（脚-地接触的约束形成方式）与积分器的细微差别，被倒立摆的指数不稳定性迅速放大。这个实验给所有后续对比定了基调：无控制时两引擎行为本来就不同，"对齐"只能针对闭环任务谈。

顺带验证了上一篇的结论稳健性：步长从 1 ms 改 0.5 ms 后，MuJoCo 的跌倒时刻 0.605 s 与第一篇的 0.60 s 一致。

6. 实验 2：PD 站位——对齐后误差只差 0.004°

站位是上一篇的核心任务：目标角 = 零位（直立），PD 全身锁住，跑 10 秒。

图 4｜对齐后的站位对比：左图跟踪误差两条曲线几乎重合（峰值 0.511° vs 0.515°）；右图骨盆高度各稳各的——MuJoCo 0.4194 m，Bullet 报告值 0.4685 m，差的 0.049 m 正是骨盆质心偏移（坐标系口径差），不是物理差异。

图 5｜站位对比的终端输出：MuJoCo 俯仰峰值 0.00°、误差 0.511°；Bullet 俯仰 0.054°、误差 0.515°。判定均为稳定站立。

这一组的结果可以总结为：对齐之后，准静态闭环行为跨引擎一致。误差峰值的 0.004° 差异远小于工程意义；重力静差（~0.5°，PD 比例控制的必然产物）在两个引擎里一模一样。站在 Sim2Sim 的角度，这说明"站位保持"这类以姿态稳定为目的、不涉及大幅动态的任务，控制器跨引擎迁移的代价主要在增益适配（第 4 节那一步），而非重新设计。

7. 实验 3：刚度扫描——稳定域边界一致

把 kp 等比扫 8 档（0.25×~8×），看两引擎的稳定/摔倒边界是否一致。这组实验回答的是"增益的适用范围是否跨引擎"：

图 6｜刚度扫描对比（对数坐标）：0.25× 处两引擎都倒（红字"倒"），0.5× 起都稳；静差随刚度反比下降的曲线两条几乎重合。Bullet 在 8× 处的误差反而略低于 MuJoCo（0.067° vs 0.078°），差异来自接触求解的微小刚度差别。

图 7｜刚度扫描终端输出的逐档数字：0.9975° 对 1.0084°、0.2598° 对 0.2613°——大部分档位误差前三位有效数字一致。

数据表（节选）：

kp 倍率	MuJoCo 误差 (°)	MuJoCo 判定	Bullet 误差 (°)	Bullet 判定
0.25	10.26	摔倒	37.55	摔倒
0.5	0.998	稳定	1.008	稳定
1	0.511	稳定	0.515	稳定
2	0.260	稳定	0.261	稳定
8	0.078	稳定	0.067	稳定

上一篇用倒立摆估算过 MuJoCo 的临界刚度（mgh ≈ 50 N·m/rad 附近）：两只踝并联 kp 合计 200 N·m/rad，乘 0.25 后 50 N·m/rad 正好压线。Bullet 端 0.25× 同样摔倒——稳定域的物理边界（重力负刚度 vs 关节刚度）跨引擎成立，两引擎都尊重同一个物理。

8. 实验 4：蹲起——动态任务暴露对齐的代价

最后一个实验把难度拉高：上一篇的两连杆解析 IK 蹲起轨迹（膝角 κ 峰值 1.4 rad、周期 4 s）原样给两个引擎跟踪。这是四组实验里唯一的动态任务，踝关节要持续输出时变力矩。

图 8｜蹲起对比：MuJoCo（实线）完成完整蹲起，骨盆最低 0.347 m（下降 7.18 cm）、躯干俯仰 0.001°；Bullet（虚线）只蹲到 0.392 m（下降 2.74 cm），腿部跟踪误差峰值 13.8°（MuJoCo 6.8°），躯干俯仰峰值 18.9°。灰线为膝角参考。

图 9｜蹲起对比的终端输出，两组 summary 并排：下降量、误差、俯仰三个指标全面分化。

这个"不完美"的结果是本文最诚实的收获。分化原因可以直接归因到第 4 节那处适配：蹲起过程中踝关节补偿角摆到 −42.6°（逼近 URDF 限位 −45°），需要的踝部力矩接近 22 N·m 上限；Bullet 端 kd 被迫降到 4（MuJoCo 是 8），阻尼弱了一半，深蹲负载下位置跟踪自然变松——膝误差翻倍、躯干前倾 19°、蹲深只有三分之一。

换句话说：准静态任务上"对齐"可以做到几乎完美，动态任务上对齐的代价会以性能损失的形式回来。这不是哪一方"错了"——两个引擎都在自己的模型参数下给出了合理行为。要消除这个分化，正路是把 Bullet 端的踝关节等效惯量补齐（URDF 加拟似的转子惯量，或 Bullet 修改源码级参数），而不是继续调 kd。这个留作后续工作，也是 Sim2Sim 方法论的一部分：先归因，再决定改控制器还是改模型。

8.5 彩蛋：把 Sim2Sim 搬进浏览器——双引擎实时对比实验台

第一篇的调参实验台让我尝到甜头，这次直接升级成双引擎版：一个页面里左右两个 3D 画面，左边 MuJoCo（蓝框）、右边 PyBullet（橙框），同一份目标轨迹、各自积分器同步推进；下方是两引擎的最大关节误差曲线实时叠加。三个模式可切：站立、下蹲-起立、零输入。

架构上有个绕不开的问题：MuJoCo 和 PyBullet 各自跑在两个 Python 环境里（3.12/3.11），不能共存于一个进程。解决办法是主服务器（MuJoCo 端）持有页面和物理主循环，Bullet 端作为子进程 worker（conda 环境解释器）通过 stdio JSON 协议收发指令——每帧主端推 66 步（0.5 ms × 66 ≈ 33 ms），worker 同步推进同样步数并回传状态，两端画面以 base64 帧流送到浏览器。

图 10｜站立模式：两引擎都稳定站住，误差曲线（下方）蓝橙两条贴在一起——与第 6 节正式实验"准静态等价"的结论一致。

图 11｜下蹲-起立模式进行中的一幕：左边的 MuJoCo 正常完成蹲起（误差稳定在 0.5°），右边的 PyBullet 已经躺平（误差爬到 36°）。需要说明：实验台的 Bullet 端用的是官方 URDF 原样碰撞（未加正式实验里的踝部 kd 适配之外的任何修改），它复现的正是第 3、4 节描述的"未完全对齐状态下的动态任务失败"。这张图比任何文字都直观——Sim2Sim 的差距不是表格里的数字，而是"一个在蹲、一个在躺"。

图 12｜零输入模式：不给控制，两引擎各自倒下——过程与第 5 节的正式实验互为印证（被动动力学天然分化）。

这个实验台的意义不在工具本身，而在它把第 4 节的结论变成了可交互的直觉：增益适配后准静态等价（图 10）、动态任务分化（图 11）、被动动力学天然不同（图 12），三个结论在页面上各有一个按钮对应。

9. 三个坑的排查方法论

把第 3 节的三个坑串起来，排查路径其实有共性，值得抽象成 checklist 给遇到同样问题的读者：

1. 先看指令是否到达执行器。PyBullet 的默认速度电机会吞掉 TORQUE_CONTROL 指令——固定基座 + 单关节恒力矩的"最小复现"实验，10 分钟就能定位"指令没生效"类问题。
2. 再查观测量口径。getLinkState[0] 是质心、[4] 才是连杆坐标系；getBasePositionAndOrientation 是质心、与 MuJoCo freejoint 的 qpos 差一个惯性原点。跨引擎对比高度、姿态前，先写一个"两边都量同一个物理点"的小脚本。
3. 最后算数值稳定边界。PD 发散先看 kd·dt/M：等效惯量 M 用引擎接口读出来（MuJoCo dof_M0，Bullet 可用 calculateInverseDynamics 反推），别凭感觉调参。本文的 kd=8 发散，笔算两分钟就能预判。

这套流程的成本极低，但能把"换引擎就崩"的玄学调试压缩成几小时内的确定性排查。

10. 环境实录：PyBullet 的 Windows 安装路径与两解释器调度

第 2 节用了三行带过 PyBullet 的安装，实际过程有一个岔路口值得展开，因为它决定了这台机器上能走哪条路。

岔路口：pip 还是 conda。 PyPI 上的 pybullet 只发源码包（最新 3.2.7 的 10 个发布文件里没有任何 Windows 轮子，翻了 3.2.5/3.2.6 历史版本也没有），pip install pybullet 会现场编译，需要 Visual C++ Build Tools——本机没有，装它要数 GB 下载。第二条路是 conda-forge：它维护着 bullet-cpp 的 Windows 预编译包，Miniforge 用户级安装（151 MB，清华镜像下载，静默装进用户目录）后一条命令建好环境：

mamba create -y -n q1pb -c conda-forge python=3.11 pybullet numpy

中间还遇到一个 conda 自身的 bug：conda create 在"创建入口点"阶段报 An unexpected error has occurred（matplotlib 的控制台脚本生成失败），换成 mamba 命令直接成功——同一个求解器、同一份包，只是链接阶段的实现不同。遇到 conda 莫名失败时先换 mamba 重试，是个省时间的习惯。

两套解释器的调度。 由此本仓库跑在两个 Python 上：MuJoCo 端 3.12（venv），Bullet 端 3.11（conda q1pb）。四个对比实验（站位/扫描/零输入/蹲起）都拆成"runner + 主脚本"的结构：runner 只 import 本端引擎，接收参数、跑仿真、写 CSV；主脚本在系统 Python 里依次用 subprocess 调两个解释器执行 runner，再汇总画图。这个结构有两个好处：引擎依赖彻底隔离，不会出现"同一个进程里 MuJoCo 和 pybullet 抢 OpenGL 上下文"的麻烦；每个 runner 单独可跑可测，主脚本只做纯数据汇总。

scripts/
├── common_sim2sim.py     # 对齐配置：步长、双端增益表、渲染工具
├── stand_runner.py       # 站位 runner（双端共用，按 argv 切引擎）
├── sweep_runner.py       # 刚度扫描 runner
├── zero_runner.py        # 零输入 runner
├── squat_runner.py       # 蹲起 runner
├── 01_model_check_bullet.py
├── 04_stand_compare.py   # 主脚本：调度 + 出图 + summary
├── 05_kp_sweep.py
├── 06_zero_compare.py
└── 07_squat_compare.py

每个实验的 results/<名字>/ 下都有双引擎各自的 CSV、一张对比图和 summary.json——文章里引用的每个数字都能在对应 JSON 里找到。

11. 复现指南与 checklist

复现本文需要：官方 q1-urdf 仓库（固定提交 562b764a）、两套 Python 环境、以及一份对齐配置。仓库 README 有完整步骤，这里只强调容易踩的三件事：

1. 模型文件不入库。按提交号克隆官方仓库后，把 urdf/ 与 meshes/ 复制到本仓库 models/ 下（脚本按相对路径加载）。Windows 用户注意中文路径问题：MuJoCo 与 PyBullet 的 C++ 层都打不开非 ASCII 路径，用 ASCII 目录（或 8.3 短路径）存放。
2. 先跑模型核对，再跑控制实验。01_model_check_bullet.py 会打印关节表与总质量——必须与 MuJoCo 端一致（22 关节、16.917 kg）才有对比意义。任何一侧版本变了，先重跑核对。
3. 换模型或换增益，重跑稳定边界扫描。本文的踝部 kd=4 只对"URDF 无 armature + 0.5 ms 步长"这组条件成立。换了任何一项，请从 kd·dt < 2M 重新推算，并用固定基座实验验证。

给准备做 Sim2Sim 的读者的最终 checklist：

• 两边模型是否同一来源、同一提交、哈希一致？
• 控制器增益、目标角、力矩限幅是否逐项相同？做过哪几处适配，是否显式记录？
• 步长是否一致？各关节的 kd·dt/M 是否都在稳定边界内（M 用引擎接口读）？
• 摩擦、重力、初始姿态是否对齐？
• 观测量口径是否统一（质心 vs 连杆坐标系、报告的 root_z 差多少）？
• 引擎默认行为是否清点过（Bullet 默认速度电机、默认阻尼、默认摩擦）？
• 准静态任务对齐后，动态任务是否单独验证过？

12. 这次验证了什么，没验证什么

验证了的：

1. 两份启元官方模型文件（MJCF/URDF）运动学等价（零位连杆几何逐项一致）、总质量一致（16.917 kg）、关节数一致（22）；
2. PyBullet URDF 管线的三个行为差异（默认速度电机、默认摩擦 0.5、COM 坐标系口径）及其规避方法；
3. MJCF armature 对 PD 稳定边界的决定性影响：kd=8 在 Bullet 端超出离散稳定边界，踝/腰 kd 适配到 4 后自由站立恢复；
4. 对齐后：PD 站位误差 0.511° vs 0.515°，刚度扫描稳定域边界一致、静差逐档吻合；
5. 未对齐的代价：动态蹲起任务 Bullet 端蹲深只有 39%（2.74 cm vs 7.18 cm），腿部误差翻倍，原因可归因到踝部阻尼弱化。

没有验证的：真机（一如既往）；Gazebo/Isaac 等其他引擎（方法可直接平移，数据需重测）；Bullet 端踝关节等效惯量补齐后的蹲起表现（留作后续）。

另外声明：文中所有数据均为本机一次运行的仿真结果；Bullet 端踝/腰 kd 做了一处显式适配（8→4），其余增益两引擎完全一致，官方模型文件未做任何修改。

13. 参考资料与代码

• 模型：primebot/q1-urdf（固定提交 562b764a，MJCF 与 URDF 同仓库）
• MuJoCo Python 文档：https://mujoco.readthedocs.io/en/stable/python.html
• PyBullet Quickstart Guide：https://pybullet.org/wordpress/index.php/forum-2/
• 本文全部脚本与结果数据整理在 GitCode 仓库 mrdeam/q1mujoco 的sim2sim 分支 https://gitcode.com/mrdeam/q1mujoco/tree/sim2sim

更多启元机器人开发资料可访问启元机器人开发者社区。