3.1 物理引擎抽象层

3.1 物理引擎抽象层

本节摘要：Gazebo 不自己求解动力学，而是把 ODE、Bullet、DART、Simbody 四个引擎接进同一个 Physics 抽象接口——世界参数、步长、求解器设置在 SDF 层统一表达。换引擎改一行配置，但各引擎的近似方式不同，换的不只是名字。本节给出四引擎能力对照与切换实证。

一个对照实验：同一场景，四个引擎

准备一个斜坡 + 一个方块的场景，只改 <physics> 的 type 字段跑四遍：

<!-- 同一世界，切换引擎只改这里 -->
<physics name="default_physics" type="dart">
  <max_step_size>0.001</max_step_size>
  <real_time_factor>1.0</real_time_factor>
  <!-- 引擎专属参数放在对应命名空间下 -->
  <dart><solver><solver_type>dantzig</solver_type></solver></dart>
</physics>
​

可切换的取值：ode（默认，老牌通用）、bullet（碰撞处理强）、dart（关节链/人形精度好）、simbody（科研级多体动力学）。观察四遍结果：方块滑到坡底的时间基本一致（趋势级可信），但停止位置、微小弹跳的细节各不相同（数值级必须核对）。这就是抽象层的承诺边界：接口统一、行为近似、不保证逐帧一致。

抽象层管什么、不管什么

右侧那列解释了为什么"换引擎"从来不是零成本：<mu> 在 ODE 里是库仑摩擦的方向系数，在 Bullet 里进入不同的求解管线——参数名一样，账本记法不同。经验法则是换引擎后重新核对接触相关的全部参数，而不是只看能不能跑。

为什么架构上要留这个壳

回看 1.3 的承诺一：物理引擎可替换。它的真实收益不是"哪个更强用哪个"，而是风险对冲——单个引擎的缺陷（某个版本的接触 bug、某类约束的数值病）不会锁死整个平台；学术界的多体动力学进展（如 DART 的 Featherstone 方法）可以持续接入。对使用者的推论：遇到"引擎级"的怪问题时，换引擎做交叉验证是零成本手段——同一场景 DART 不抖而 ODE 抖，问题就定位在接触求解而不是你的模型。

引擎选型实证：一份可复现的四引擎基准

给"换引擎"一个可量化的依据，可以在同一个堆叠场景上做小规模基准：50 个方块从 2 米高自由落体堆叠，测三样东西——每步墙钟耗时（性能）、静置 10 秒后的总动能（稳定性）、堆叠高度漂移（精度）。用脚本把四个引擎各跑五遍取中位数：

# 引擎基准脚本：sed 换引擎，无头跑固定步数，服务端日志抽 RTF
for eng in ode bullet dart simbody; do
  sed "s/type=\"ode\"/type=\"$eng\"/" stack_world.sdf > /tmp/w_$eng.sdf
  echo "== $eng =="
  gz sim -s -r --iterations 10000 /tmp/w_$eng.sdf 2>&1 \
    | grep -E "real_time_factor" | tail -5
done
​

# 从各引擎的接触统计日志里抽稳定性指标：静置期总动能应趋近零
import re
for eng in ["ode", "bullet", "dart", "simbody"]:
    kinetic = []
    for line in open(f"kinetic_{eng}.log"):
        m = re.search(r"kinetic_energy: ([0-9.e+-]+)", line)
        if m and float(m.group(1)) >= 0:
            kinetic.append(float(m.group(1)))
    tail = kinetic[-100:]
    print(f"{eng:8s} 静置期动能中位数 {sorted(tail)[len(tail)//2]:.3e} J, "
          f"峰值 {max(kinetic):.1f} J")
​

一次典型跑分会呈现这样的格局：ODE 与 Bullet 每步最快（毫秒级步长下 RTF 最高），但静置期残余动能比 DART 高一到两个数量级——堆叠体在微观上仍在"呼吸"；DART 慢两到三倍但堆得最稳，Simbody 居中且对约束误差最敏感。据此可以写成选型规则：导航、大规模场景选性能；机械臂、人形、抓取选关节精度；论文复现优先与原文同引擎。更重要的是方法论：这份脚本本身就是"交叉验证"的模板——任何"只在某引擎下复现"的 bug，都能用同一套流程钉死在引擎账上，而不是反复怀疑自己的模型。

还有一条容易被忽略的推论：基准结果与引擎版本绑定。引擎小版本升级可能改变求解器默认行为，使堆叠稳定性悄悄变化——把这份基准脚本连同输出快照存进仓库，升级物理引擎的依赖时重跑一遍 diff，就能在 CI 阶段发现"引擎行为漂移"，避免它伪装成"自己代码的回归"浪费排查时间。

基准的解读也要守住一条纪律：单项指标的胜负不构成换引擎的理由，只有"指标乘以你的场景权重"才构成。导航场景里堆叠呼吸无关紧要，机械臂场景里它却是抓取成功率的地基——先写下你的场景在乎什么，再回头看跑分表，这个顺序不能反。

本节要点回顾

• 抽象层统一接口、不统一行为：换引擎一行配置，但接触类参数要全部重核。
• 四引擎各有所长：ODE 稳、Bullet 碰撞强、DART 关节链准、Simbody 科研向；默认 ODE，精度痛点再换。
• 换引擎是免费的交叉验证：症状只在单引擎出现时，先怀疑引擎近似而不是自己模型。
• 引擎专属参数放在各自命名空间（如 <dart><solver>），跨引擎的世界文件别混写。

抽象层是入口。下一节钻进每一步求解的内部：惯性张量与步长如何共同决定"这个仿真能不能信"。