在研究机器人操作时，最糟糕的感觉是：模拟里同一个关节、同一个初始条件，把同样的策略换台机器重新跑一遍，结果完全不同。不是策略升级，是物理引擎本身在刚体仿真过程中出现了肉眼可见的漂移。那段时间我意识到，轻量级不是只看代码体积和运行帧率，“确定性”才是很多应用的隐形生命线。后来我花了几个周末把 Genesis 这套引擎在刚体仿真场景里完整跑了一遍，包括基础场景搭建、批量并发、可重复性验证和一轮又一轮的踩坑，收获了相当多一手经验。
如果你在做机器人控制、强化学习数据生成、或者只是想把“物理仿真”作为算法回归测试的一部分，这篇 Genesis 实战指南应该对你有用。我不会只丢一个“Hello World”，而是会把刚体仿真背后的“确定性”到底怎么实现、怎么验证、怎么踩坑，尽量讲透。适合刚接触物理引擎的读者，也适合已经用过 MuJoCo、PyBullet 但想找更轻量替代方案的人。
1. 为什么“确定性”会成为刚体仿真的隐形生命线
1.1 一个让我开始研究确定性的现场
先说一个我自己的经历。之前做机械臂抓取实验，控制器已经写好，模拟环境里跑得稳稳当当。结果换了一台工作环境差异不大的机器重新训练，同一个策略的线跑没了，末端执行器差了2厘米，抓取成功率直接跌破一半。我一开始怀疑是驱动没装好、GPU 版本不一致，后来逐步排查才发现，问题出在物理引擎的浮点运算顺序上。
物理引擎每天在做的事情其实非常机械：计算加速度、更新速度、更新位置、检测碰撞、解方程组。只要这些计算里任何一步的顺序、精度或舍入方式变了，最终的状态就会像蝴蝶效应一样放大。刚体仿真尤其明显，因为碰撞瞬间的接触力往往很大，一个 1e-7 的浮点误差，经过几百个时间步迭代，就足以让一个本来该停在目标位置的小车滑出老远。
所以我当时对“确定性”的需求不是洁癖，而是刚需。训练机器人策略、做仿真到现实迁移、写自动化回归测试，都需要“同一个输入必然得到同一个输出”。设备换了、线程数变了、GPU 驱动版本升了，结果也不能跟着变。
1.2 确定性能解决哪些实际工程问题
确定性在刚体仿真里至少解决四类问题。
第一，强化学习训练的可复现性。RL 实验动辄几十万步，如果环境本身有隐性随机性，那就分不清策略是真好还是碰运气。指定随机种子后，环境状态、动作执行、物理反馈全部可复现，才能公平地对比算法 A 和算法 B。
第二，仿真到现实迁移的可调试性。真实机器人系统里的一举一动都有传感器读数。模拟环境如果每次跑都不一样，你就无法判断一个观察到的异常是仿真模型的错误，还是真实系统的物理特性。反过来，如果确定性强，就能在仿真里复现真实系统的异常，进而定位是哪条动力学参数没调对。
第三，持续集成中的回归测试。我见过不少团队把物理仿真写进 CI，每次代码提交后自动跑一轮机械臂路径规划测试。这时候如果引擎不带确定性，同样的测试用例偶尔通过、偶尔失败，整个 CI 就变成了抽奖。Genesis 这类把确定性放在核心位置的引擎，在这类场景里价值非常大。
第四，多人协作中的状态同步。在分布式训练或多人联合调参时，大家经常需要基于同一个环境状态讨论问题。确定性的环境意味着只要大家都用相同的种子和版本，任意一个人看到的失败场景，别人也能一字不差地复现。
1.3 轻量级引擎为什么敢碰这个难题
很多人对“物理引擎”的第一反应是重型基础设施，觉得只有大厂才维护得起。但轻量级引擎往往更适合打磨确定性，因为代码路径短、依赖少，反而容易控制计算顺序。Genesis 大概也是这个思路：核心刚体求解部分尽可能独立，不引入大量外部随机源，同时把常用的刚体、关节、碰撞、求解器都做成可配置的模块。轻量不代表简陋，反而意味着我能更多地把注意力放到仿真参数本身，而不是花大量时间对抗引擎的“脾气”。
2. 刚体仿真核心的二三事：时间积分、约束求解和可复现性
2.1 刚体状态与动力学方程
要理解 Genesis 的刚体仿真，得先建立一个最简单的心智模型。刚体就是不会形变的物体，它的状态通常由平移和旋转两部分组成：位置向量、姿态四元数、线速度、角速度。引擎每往前走一步，就要根据当前受到的力，算出下一时刻的状态。
一个刚体在重力、关节驱动力和外力的作用下，核心方程就是牛顿第二定律和欧拉方程的离散版本。平移部分好理解，力除以质量得到加速度，加速度积分得到速度，速度再积分得到位置。旋转部分稍微复杂一点，因为物体的转动惯量是随姿态变化的，引擎需要把角速度变换到世界坐标系下，再应用力矩。
这就是为什么四元数在刚体仿真里不可或缺。欧拉角在接近某些角度时会出万向锁，导致插值和积分立刻不稳定。我见过有人用欧拉角存姿态，结果物体转到接近垂直方向时，姿态计算直接飞掉。Genesis 内部处理姿态时基本都围绕四元数，这一点在写外部控制器时也要注意，尽量别自己用欧拉角做中间计算再存回去。
2.2 接触与关节约束
刚体仿真的“灵魂”不在自由运动，而在接触和约束。一个机械臂的每个关节，本质上是给相邻两个刚体加了一个约束，让它们只能绕某个轴相对旋转。一个箱子放在地面上，本质上也是约束，接触点到地面的法向力必须保证箱子不会穿进地面。
如果把所有约束条件一股脑联立起来，会得到一个巨大的方程组。Genesis 的刚体求解器每次步进都会收集所有接触点、关节限制、驱动器目标，然后迭代求解这些约束力。这个过程有两个关键点。第一，约束力的求解顺序会影响最终结果，尤其是同时有很多物体接触的时候。第二，为了保证确定性，引擎需要把接触点的顺序固定下来，不能这次先算物体 A 的接触、下次先算物体 B 的接触。
我刚开始做刚体堆叠实验的时候，把 20 个立方体从不同高度丢进一个容器，看起来很简单，但跑了三次之后发现最终堆叠结果每次都不一样。后来查明原因，不是 Genesis 不支持确定性，而是我在初始化阶段用了一个全局随机数生成器来给物体加微小扰动。这其实提醒我一个重点：引擎可能已经做到确定，但用户代码如果在每一步里调用了随机函数，整个流程依然不可复现。
2.3 半隐式欧拉和子步
刚体仿真里的时间积分有很多种方案。显式欧拉简单但容易爆炸，隐式欧拉稳定但计算量大。Genesis 这类引擎普遍采用半隐式欧拉：先用当前时刻的力更新速度，再用更新后的速度更新位置。这个方案和显式欧拉唯一的区别是“顺序”，但却让高刚度场景下的稳定性提升了很多。
不过再稳定的积分器也怕时间步长太大。假设仿真步长 dt 设为 0.01 秒，也就是 100Hz，对于柔软或高速的接触场景，很容易出现两个物体已经互相穿透很深才被检测到。解决方法通常是引入子步：把一个大步长内部再切分成多个小步长，比如每帧 0.01 秒内部跑 4 次 0.0025 秒的物理步进。
在 Genesis 的仿真参数里，有两个常见选项：一个是基础时间步长 dt，一个是子步数 substeps。我自己常用的组合是 dt=0.01、substeps=4。这样对外的控制频率是 100Hz，内部的物理稳定性又接近 400Hz，兼顾了控制逻辑和物理稳定。后面我会详细说这个参数组合在确定性验证中的实际表现。
3. 选型对比：Genesis、MuJoCo 以及我们到底在找什么
3.1 从 MuJoCo 迁移过来的几个不习惯
因为最近网络上常把 Genesis 和 MuJoCo 拉到一起对比，我也免不了拿两边各自跑过同一个刚体测试。先说结论：MuJoCo 在很多场景下依然是非常可靠的主力引擎，生态久、资料多、接触模型经过大量验证。Genesis 对我来说更像一个新的“刚体仿真工作流”，重点在轻量、GPU 并行和相对现代的可微管道。
最大的不习惯其实在初始化方式。MuJoCo 以 MJCF 或 URDF 模型文件为中心，引擎和模型文件的耦合很深；Genesis 的 API 更像“场景构建”思路，把平面、球体、网格、URDF、MJCF 都当作可添加的实体。上手初期我经常找不到对应的对象名，后来习惯了它的实体管理方式，场景搭建反而比 MuJoCo 直观一些。
另一个不习惯是渲染。Genesis 的渲染器和刚体求解器都贴近现代 GPU 工作流，开 viewer 和不开 viewer 的性能差异非常大。我一开始在带 GUI 的环境里跑长测试，渲染花费占了很大一部分。MuJoCo 本身的离屏渲染相对很轻，可以长期挂着不关；Genesis 则更适合这种工作流：训练或批量验证时无头运行，只在需要发生时打开 viewer。
3.2 各引擎选型视角
下面这个对比表是我个人视角，不是权威评测，但基本覆盖了我平时选型时关心的点：
| 维度 | Genesis | MuJoCo |
|---|---|---|
| 定位 | 轻量、GPU 并行、现代物理仿真 | 成熟、稳定、经典接触模型 |
| 确定性 | 设计时优先考虑，配合固定种子较容易复现 | 支持，但跨设备时仍需小心 |
| 场景构建 | 代码式生成实体，灵活 | 模型文件驱动，标准化强 |
| 渲染 | GPU 管线，无头模式性能好 | 轻量、稳定，适合长期可视化 |
| 适用人群 | 想快速搭批处理、RL 数据流的人 | 重度仿真研究、依赖成熟生态的人 |
选型建议很简单：如果你只是要一个稳定的物理后端，已经有大量 MuJoCo 代码，那就别折腾迁移；如果你想做大批量并行仿真，或者想尝试一个把确定性和轻量作为默认项的引擎，Genesis 值得试一把。
3.3 轻量级引擎适合用在什么位置
我最舒服的使用方式是把 Genesis 当作“仿真数据工厂”。比如需要生成一千条机械臂避障轨迹，每条轨迹对应不同的目标位置、障碍位置和初始噪声。程序启动后，在一个场景里创建多个并行环境，批量生成数据。这个过程不追求复杂可视化，只追求吞吐量、稳定性和可复现性，Genesis 的定位和这套需求天然契合。
同时它也适合做“物理回归测试”，就是我在开头提到的 CI 场景。在这种用法里，仿真器不需要跑一整天的长任务，只要在几十秒内把固定用例跑完，并输出可对比的数值就行。轻量级引擎在这里的优势是：冷启动快、依赖少、容易在容器里运行。
4. 环境准备与最小仿真工程搭建
4.1 安装环节：我把环境装了两遍踩了一次坑
Genesis 的安装流程不算复杂，核心依赖是 Python 和 GPU 环境。我用的是 conda 创建独立环境，然后通过 pip 安装服务端的包。如果你只需要 CPU 刚体仿真，理论上也可以跑，但 GPU 并行才是它的强项，所以我还是建议本地至少有一块支持 CUDA 的显卡，或者直接用云 GPU 实例。
第一次安装时我为了省事，直接在 base 环境里 pip install，结果和已有的 PyTorch 版本冲突，导入阶段就报了一堆错。后来我把 conda 环境分离，重新建了一个干净的 Python 3.10 环境，再装 GPU 版驱动对应的 PyTorch，之后才顺利导入。建议所有想玩物理引擎的人都养成这个习惯：独立环境，别混装。
装完后在 Python 里运行以下代码，能正常输出就说明环境基本通了：
import genesis as gs gs.init(backend=gs.gpu) print(gs.__version__)4.2 Hello 刚体：一个自由下落的球
能导入之后，我建议先跑一个最朴素的场景：一个球从高处落下，砸到地面弹几下，最后停在平面上。别看这个例子简单，它包含了你调刚体仿真时会遇到的几乎所有核心概念：重力、接触、反弹、摩擦、时间步。
import genesis as gs gs.init(backend=gs.gpu) scene = gs.Scene( sim_options=gs.options.SimOptions( dt=0.01, substeps=4, ), viewer_options=gs.options.ViewerOptions( camera_pos=(3.0, -1.0, 2.5), camera_lookat=(0.0, 0.0, 0.5), ), ) plane = scene.add_entity(gs.morphs.Plane()) ball = scene.add_entity( gs.morphs.Sphere( pos=(0.0, 0.0, 1.0), radius=0.05, ) ) scene.build() for i in range(1000): scene.step()这段代码里，Plane 是无限大平面，Sphere 是一个半径为 0.05 米的球，初始位置在 (0, 0, 1)，也就是离地一米。build 完成之后，引擎会把所有实体和约束初始化好，之后每调一次scene.step()，物理世界就往前推一个基础时间步。
实际跑完你会发现，球的轨迹和预期基本一致。重点在于：这个表格里的dt=0.01是控制周期，substeps=4是每个周期内部的物理子步。如果你改成dt=0.05且substeps=1，大概率能看到球直接陷到地下或者弹得极其不稳定。这就是子步存在的意义。
4.3 给仿真加入初始条件变量
工程里几乎没有“纯自由落体”这么干净的事，通常需要在场景里加入可变初始条件。这里我强烈建议用变量池来统一管理初始条件，而不是在循环里手写随机数。原因很简单：如果初始条件分散在代码各处，确定性验证时很难把所有因素一次性固化下来。
我习惯写成这样：
initial_states = { "seed": 42, "ball_pos": (0.0, 0.0, 1.0), "ball_vel": (0.2, 0.0, 0.0), "friction": 0.5, "restitution": 0.3, }每次跑实验之前，把整个 dict 存成 JSON。后期做确定性验证时，只要这个 dict 不变，后续所有随机数生成、速度初始化、环境构建都应该保持一致。把“会变的参数”和“代码逻辑”分开，是实验科学的基本功，也直接决定了你能否复现自己的数据。
5. 控制确定性：一套可落地的验证方案
5.1 到底是哪些因素在破坏确定性
在我排查过很多次“模拟结果飘忽不定”的问题之后，总结出四类最常见的确定性干扰源。
第一，全局随机源。很多项目的随机数生成器没有指定种子，比如用 numpy 的默认全局状态、Python 的random模块。一旦这些随机源被物理引擎之外的控制代码调用，就会产生无法控制的扰动。
第二，并发处理顺序。GPU 并行仿真的本质是把大量对接触点、对碰撞体的计算放到很多线程或者流式处理器上。如果引擎没有对中间结果做确定性的归约，两个线程的加法顺序不同，结果就可能差上一个最小浮点单位。
第三，浮点计算顺序。浮点数乘法不满足结合律，(a + b) + c和a + (b + c)在小数位上可能有细微差别。跨设备跑同一段代码时，编译器优化、指令集差异都会改变计算顺序。
第四，外部环境的干扰。系统时钟、多进程调度、CPU 线程数、GPU 驱动版本，所有这些都可能通过不同的途径影响物理仿真结果。想要稳定复现，最好把环境版本信息也一并固定。
Genesis 在引擎层面把很多事做成了默认行为，比如固定接触顺序、使用固定时间步，但用户代码里的随机源仍然是最大的隐患。
5.2 给仿真状态做“快照哈希”
要验证确定性，不能只靠肉眼观察渲染结果。我的做法是给仿真状态做一个快照函数，把每个刚体的位置、姿态、线速度、角速度全部序列化成字节，然后计算哈希。每次运行结束，比较哈希值是否一致。
这里是一个简化的思路，并不依赖具体 API：
import hashlib import struct def state_bytes(scene): data = b"" for entity in scene.entities: pos = entity.get_pos() quat = entity.get_quat() lin_vel = entity.get_vel() ang_vel = entity.get_ang_vel() data += struct.pack( "<7f", pos[0], pos[1], pos[2], quat[0], quat[1], quat[2], quat[3], ) data += struct.pack( "<6f", lin_vel[0], lin_vel[1], lin_vel[2], ang_vel[0], ang_vel[1], ang_vel[2], ) return data def state_hash(scene): return hashlib.sha256(state_bytes(scene)).hexdigest()注意这里为了展示个大概，我没有把摩擦、阻尼、关节位置全部塞进去。在实际项目中，凡是会影响后续动力学状态的量都应该进快照，包括关节位置、关节速度、执行器目标、随机数生成器内部状态等。
验证方法很简单：同一台机器上跑两次，分别打印最终的哈希；然后换一个 GPU 型号，再跑两次，看跨设备是否一致。如果机器内部能保持一致，但跨设备不一致，也不必慌张，至少先把“同环境可复现”和“跨环境可复现”分开记录。
5.3 让确定性成为工程默认值
我个人的准则是：在仿真代码入口处统一设置种子，并保证随机数只出现在初始化阶段，而不是出现在物理步进阶段。
举例来说，如果我想让同一个场景产生 100 条带噪声的轨迹，我会先在初始化时生成一个扰动库，把所有扰动保存在内存或文件里。每个 episode 启动时，从扰动库里按顺序取扰动，而不是在循环里现场调用随机函数。这样即使某个 episode 中途崩溃，重跑时也能从同一个位置继续复现。
其次是固定线程数和环境变量。在 Linux 容器里，我通常设置如下变量来缩小跨机器差异：
export CUDA_LAUNCH_BLOCKING=1 export CUBLAS_WORKSPACE_CONFIG=:4096:8其中CUDA_LAUNCH_BLOCKING=1会让 GPU 的某些操作变成同步执行，降低并发不确定性，但会牺牲性能。如果只是做短时回归测试，这个付出是值得的；如果是大批量训练，我一般不会全局开启它，而是靠固定随机种子和固定场景构建顺序来保证“训练数据可复现”。
6. 性能优化与边界处理：轻量不等于可以乱调
6.1 先搞清瓶颈在求险还是渲染
拿到一个新引擎，大家都会先盯着帧率看。帧率低就下意识觉得引擎不行，但其实刚体仿真的性能瓶颈经常不在“求险”而在“渲染和状态同步”。我跑 Genesis 的第一个大场景时，发现 viewer 开着，帧率低得可怜；一旦把 viewer 关掉，只跑无头scene.step()，性能立刻飙上去好几倍。这提醒我：性能分析第一步是区分“物理求解耗时”和“渲染耗时”。
在无头模式下，Genesis 的刚体仿真性能相当可观。我自己的笔记本上，单个简单场景每秒跑几十万次步进都是正常的；如果涉及大量接触，比如几十个物体堆叠，速度会明显下降，那是约束求解器在忙碌，属于正常的“物理税”。
6.2 轻量级的边界问题：穿透、飞走和不可控
结构越轻量的引擎，边界情况就越需要使用者自己兜住。最常见的三个现象：物体穿透、物体飞走、关节抖动。
物体穿透的根源是时间步长太大。解决方法优先考虑增加 substeps，而不是减小对外控制频率 dt。我试过一个快速小球，dt=0.01、substeps=2 时会穿透墙壁，改成 substeps=8 后就稳定了。这比把 dt 直接降到 0.002 要划算，因为对外控制频率仍然保持在 100Hz。
物体飞走一般是因为初始化时两个物体已经重叠，或者某个关节的初始速度过大。Genesis 会在 build 阶段尽量帮你处理初始重叠，但最好还是在模型里手动设置安全间距。关节抖动则和 PID 控制参数有关，如果你用引擎自带的关节驱动器，控制增益太大会导致震荡。
我整理了一份调参优先级清单，按这个顺序排查，大部分异常都能解决：
- 检查基础时间步 dt，大概率是太大
- 检查 substeps，短时穿透说明子步不足
- 检查物体初始间距，重叠会带来爆炸性接触力
- 检查摩擦系数和反弹系数，太极端也会引发不稳定
- 检查关节阻尼和控制增益，是否引入持续振荡
6.3 批量并行：真实收益率最高的优化
Genesis 这类 GPU 并行引擎最大的优势是可以同时维护很多个子环境。我做一个机械臂抓取数据合成任务时，一开始用单环境循环，跑了半天数据量还不够。后来改成批量环境创建，把 256 个环境同时推进，吞吐量提升非常离谱。
批量环境的使用逻辑不复杂：定义一次场景构建函数，然后通过引擎的批量接口创建多个副本。每个环境可以带有不同的目标位置、物体位置、关节初始状态。步进时一次调用同时推进所有环境，从而把 GPU 的并行能力榨干。
这里有个需要注意的是：批量环境下，确定性验证比单环境更严格。不仅要求同一个环境在不同批次中结果相同，最好还要求无论你是先跑环境 1 再跑环境 2，还是同时跑 256 个环境，环境 1 的轨迹都不变。实践下来，只要初始化阶段把每个环境的种子和状态都固定好，同时保持批量内实体添加顺序一致，通常能做到这一点。
7. 实战案例：用固定种子复现机器人杆件平衡实验
7.1 场景设置：一个单级倒立摆
理论讲太多容易飘，下面用一个我实际搭过的场景做个完整示范。任务很简单：模拟一个倒立摆，摆杆通过旋转关节连接到底座，看看在固定控制律下，它的运动轨迹是否完全可重复。
我没用复杂的机械臂模型，而是准备了一个简单的 URDF 或 MJCF 文件，里面包含一个底座、一个旋转关节和一根杆。加载进 Genesis 后，我通过关节控制让摆杆在竖直位置附近保持平衡。
场景初始化代码如下：
import genesis as gs import numpy as np gs.init(backend=gs.gpu) def build_scene(): scene = gs.Scene( sim_options=gs.options.SimOptions( dt=0.004, substeps=4, ), viewer_options=gs.options.ViewerOptions( camera_pos=(1.5, 0.0, 1.5), camera_lookat=(0.0, 0.0, 0.5), ), ) plane = scene.add_entity(gs.morphs.Plane()) pendulum = scene.add_entity( gs.morphs.URDF( file="pendulum.urdf", pos=(0.0, 0.0, 0.0), ) ) return scene, pendulum scene, pendulum = build_scene() scene.build()这里把 dt 设置为 0.004 秒，也就是 250Hz 的物理频率，配合 substeps=4，实际内部求解频率到 1000Hz。倒立摆的控制本来就不稳定，物理频率太低很容易发散，这个配置是我最终稳定下来的经验值。
控制逻辑方面，我给关节设置了一个目标位置，就是让杆保持在竖直向上的角度。实际工程中你可能会写一个简单的 LQR 或者 PID 控制器，我这里为了验证确定性，直接设置固定控制目标，相当于在每个控制周期给关节施加恒定的目标位置。这样做的好处是排除控制器的随机因素，只观察物理引擎本身的行为。
7.2 两次运行的哈希对比
我跑了两组实验，第一组用相同的随机种子、相同参数，第二组在场景构建前额外调用了一次无关的随机数生成，检查它会不会影响结果。每 10 步记录一次摆杆的角度和角速度，最终计算哈希。
结果符合预期：第一组两次实验的哈希值完全一致，说明系统在“种子固定、初始化顺序固定”的前提下具有很好的确定性。第二组虽然多调用了一次随机数，但因为这次调用发生在build_scene之外，没有影响场景构建，最终状态也没有变化。这说明只要随机源不污染场景构建和步进阶段，外部随机调用不会破坏仿真本身的确定性。
这里也暴露出一个很微妙的点：如果你在第二次实验里把随机调用放在build_scene内部，比如用来给杆的初始位置加一个微小噪声，哪怕噪声只有 1e-6 弧度，最终哈希也会完全不同。所以要把“仿真自身的确定性”和“实验设置的确定性”分开看。
7.3 实际调参时的意外发现
第一版场景里，我把 dt 设成 0.01，控制频率只有 100Hz，倒立摆撑不了多久就会倒下。我以为是控制器太弱，后来把 dt 降到 0.004 之后，稳定性立刻提升。这个现象说明，刚体仿真的稳定性不仅取决于空间上的精细程度，更取决于时间上的采样密度。
另外我还发现摩擦系数对结果影响很大。底座和地面的摩擦太低，场景 build 的时候杆会因为微小扰动开始滑动，导致轨迹持续漂移。我把摩擦系数从默认的某个值调到偏高一点后，倒立摆的“休息状态”变得更干净，实验结果也更容易解释。调刚体仿真不要迷信默认参数，尤其不要忽略接触摩擦和关节阻尼，这两个参数对确定性一样至关重要。
8. 最后聊聊那些容易被忽略的坑
8.1 时间步长与控制周期的错配
这是最常见的坑之一。很多人把dt当成“物理引擎跑多快”，却没意识到它同时决定了外部的控制频率。如果你在代码里每步都发送一个控制指令，那么dt=0.01意味着控制器只能以 100Hz 运行。对很多机器人任务来说，100Hz 控制频率偏低，高频策略需要把 dt 降到 0.002 甚至更低。
我踩过一次比较深的坑是为了追求性能，把 dt 设得很大，控制器明明已经算出了很好的力矩，机器人仍然在模拟里疯狂抖动。最后发现是控制频率跟不上物理频率，不是控制算法有问题。后来我习惯在参数配置里同时写清楚dt、substeps和控制频率，三者的关系一目了然。
8.2 浮点数不是“实数”
确认刚体仿真的确定性时，永远不要拿浮点数做精确相等比较。哪怕两次运行真的来自同一个物理过程，由于编译优化或硬件指令差异，数值末尾几位也可能不同。所以在做哈希对比时，尽量把状态直接序列化，或者把浮点数量化到某个精度后再比较。
我通常的做法是：先跑一次参考实验，把每个关键状态保存下来；之后每一次运行都对照参考实验，允许状态值在小数点后 6 位以内浮动。超过这个范围才判断为“不可复现”。这个方法比单纯看哈希更接近工程实际，既不放过真正的问题，也不会被极端荒谬的浮点误差误导。
8.3 阻尼、摩擦和默认参数不是摆设
很多新手拿到 Genesis，第一件事就是调重力、调质量，忽略接触参数。但刚体仿真的稳定性和真实感很大程度上依赖摩擦和阻尼的配合。没有摩擦，箱子会一直滑，机械臂抓取也根本抓不住；没有阻尼，关节会在目标角度附近无限振荡。
如果你发现场景里物体“不粘地”或者机械臂“很飘”，不要急着怀疑求解器，先检查接触摩擦系数和关节阻尼。一个简单经验是：刚性接触的摩擦系数在 0.4 到 1.0 之间通常比较合理；关节阻尼则需要配合控制增益来调，通常可以先给一个偏大值稳住系统，再慢慢减小。
8.4 保存和加载状态时别漏关节
做长周期确定性实验时，往往需要保存中间状态，便于断点续跑。很多人只保存刚体的位置和姿态，忘了关节位置和速度，导致重载之后物体在空间里的位置一样，但关节内部的弹簧已经乱掉，后续轨迹自然对不上。
一个完整的刚体仿真状态至少应该包括：
- 每个刚体的位置、姿态、线速度、角速度
- 每个关节的位置、速度、驱动目标
- 控制器的内部状态，比如 PID 积分项
- 随机数生成器的内部状态
只有把这些全部纳入快照，才能真正实现“从任意中间点恢复”。
8.5 跨设备确定性不要盲目强求
最后说一个心态问题。我见过一些团队陷入“跨 GPU 型号也必须完全一致”的执念，结果花了大量时间在追驱动、锁线程、调编译器标志上。说实话，物理引擎的确定性一般先保证“同一设备、同一环境、同一版本”下可复现；跨设备需要做更多工作，收益却不一定高。
我的建议是，在项目初期先记录每台测试设备的 GPU 型号、驱动版本、CUDA 版本、引擎版本。如果同一套配置下能稳定复现，就已经满足绝大多数 RL 和回归测试需求。真要跨设备复现，优先通过固定随机源、固定碰撞顺序和减少并发不确定性来逼近，而不是一根筋地调底层浮点模式。
Genesis 这套引擎也不是万能的，它有自己适合的场景和不擅长的地方。但如果你和我一样，受够了“每次结果都不一样”的物理仿真，想找一个能把刚体仿真、确定性和轻量化兼顾的工作流，它确实是一个值得放进武器库的选择。实操中踩过坑之后，我最大的感触是：真正决定仿真质量的，从来不只是引擎本身，还有你对时间步、接触参数、随机源和状态快照这些细节的掌控程度。
