Sim-to-Real on Physical AI Hub

接触作業向けロボットシミュレーションの選び方：物理エンジンと接触計算を比較する

Sat, 31 Oct 2026 14:18:48 +0900

接触計算は、エンジンの名称よりも評価方法で結果が変わる点が気になります。

先に結論

接触を伴うロボットシミュレーションに、普遍的に最適な物理エンジンや時間刻みはありません。高速衝突、持続接触・準静的操作、多接触・閉ループ拘束にタスクを分類し、接触力、侵入量、摩擦遷移、拘束残差、衝突時刻、計算時間で比較するのが基本です。

高速衝突では、連続衝突検出（CCD）と細かい固定時間刻み、またはサブステップを候補にします。押し付け、把持、挿入、組立では、見た目の安定性だけでなく、接触力や静止摩擦から滑りへの遷移を確認します。積み重ねや多接触では、ソルバー反復回数と時間刻みを別々に変え、収束性とコストの組み合わせを評価します。

なぜエンジン名だけで選べないのか

物理エンジンの速度、精度、安定性は、エンジン名だけでは決まりません。接触状態、形状や質量などのモデル、評価指標、積分器、時間刻み、接触ソルバー、反復回数、収束許容値、接触の柔らかさや剛性、摩擦モデルが相互に影響します。あるシーンで安定した設定が、別のロボットや材質でも同じ結果になるとは限りません。

また、異なるエンジンの「反復回数」や「摩擦係数」は、同じ数値でも同じ意味を持ちません。設定値をそろえることは比較条件の一つですが、物理挙動がそろうことを意味しないため、接触力誤差、侵入量、拘束残差、滑り判定、計算時間などの出力で比較します。

前提となる用語

時間刻みは、シミュレーションを一度進める時間幅です。固定時間刻みは再現性や制御周期との関係を確認しやすい一方、細かくするほど計算量が増えます。サブステップは、制御側の経過時間を複数の小さな計算に分ける方法です。

接触ソルバーは、物体の貫通を抑え、摩擦や拘束条件を満たすための数値計算を担います。反復回数を増やすと拘束残差やドリフトが改善する可能性がありますが、計算量も増えます。CCDは、離散的な衝突判定だけでは見落としやすい高速物体や薄い形状を扱うための仕組みです。CCD、固定時間刻み、サブステップは異なる機構であり、単純な代替策ではありません。組み合わせや代替の効果は対象タスクで確認します。

エンジンごとの設定項目

本稿で参照する範囲は、PhysX 5.4.1、MuJoCo stable documentation（リリース番号は資料上で固定されていない）、Bullet3 master の User Manual（参照コミットは資料上で固定されていない）です。MuJoCoとBulletについては、再現性のために利用する実装のリリースやコミットを別途固定してください。固定されていない資料から、特定版同士の性能順位を断定することはできません。

MuJoCoでは、時間刻みと積分器に加え、Newton、CG、PGSなどの拘束ソルバー、反復回数、収束許容値を設定できます。接触をソフトな制約として扱い、solref、solimp、摩擦パラメータ、接触形状も調整対象です。モデルベース制御で接触パラメータを明示的に調整したい場合の候補ですが、設定値を他エンジンへそのまま移植できるとは限りません。

PhysX 5.4.1では、PGSとTGS、位置方向・速度方向のソルバー反復回数、接触オフセット、静止オフセット、CCDを個別に設定できます。既存基盤に合わせてこれらを調整したい場合の候補ですが、TGSの特徴から他エンジンを含む総合順位を推定してはいけません。

Bulletでは、stepSimulation の maxSubSteps と fixedTimeStep により、経過時間を固定時間刻みに分割できます。ソルバー反復回数や連続衝突検出も設定対象です。Bullet3 master はコミット未固定の資料であるため、実装を比較に使う場合は対象コミットを記録します。

flowchart TD
  A["接触タスクを分類"] --> B{"主な接触レジームは？"}
  B -->|"高速衝突・飛翔物体"| C["CCD、固定時間刻み、サブステップを確認"]
  C --> D["トンネリング、衝突時刻、衝突インパルスを比較"]
  B -->|"持続接触・押し付け・把持・挿入"| E["接触剛性・減衰、摩擦、位置拘束反復を確認"]
  E --> F["侵入量、接触力、関節トルク、滑り遷移を比較"]
  B -->|"準静的操作・組立"| G["接触コンプライアンス、収束許容値、時間刻みを確認"]
  G --> H["力の再現性、拘束残差、軌道の収束を比較"]
  B -->|"多接触・積み重ね"| I["ソルバー方式、反復回数、時間刻みを確認"]
  I --> J["反復回数と時間刻みを独立に変えて収束試験"]
  D --> K["同じモデル、初期条件、制御入力で比較"]
  F --> K
  H --> K
  J --> K
  K --> L["実機パラメータを校正し、許容する挙動と計算コストで選択"]

接触レジームごとに確認すべき設定と評価指標を分け、共通条件で比較する選定フロー。

用途別の選定基準

接触レジーム	優先して確認する設定	主な評価指標
高速衝突・飛翔物体	CCD、固定時間刻み、サブステップ	トンネリング、衝突時刻、衝突インパルス
押し付け・把持・挿入	接触剛性・減衰、摩擦、位置拘束反復	侵入量、接触力、関節トルク、滑り遷移
組立・準静的操作	接触コンプライアンス、収束許容値、時間刻み	力の再現性、拘束残差、軌道の収束
積み重ね・多接触	ソルバー方式、反復回数、時間刻み	ドリフト、拘束残差、計算時間
モデルベース制御	積分器、拘束ソルバー、接触パラメータ	制御入力と接触応答の再現性

収束試験の進め方

時間刻みは、単一の推奨値から決めません。基準値を置き、それを半分にした条件を作ります。各条件で軌道、接触力、最大侵入量、イベント時刻、実行速度を記録し、結果の変化が許容範囲に収まる値を候補にします。具体的な許容値は、タスクと実機の計測系に依存するため、資料だけから共通の閾値を設定できません。

ロボット制御を実機に合わせる：アクチュエーター制約をモデル化して計画へ反映する方法

Mon, 05 Oct 2026 14:22:52 +0900

実機でだけ現れる追従誤差は、制御器の調整不足だけでなく、制約の表現方法にも原因があります。

結論：制約は一つの上限値にまとめない

ロボットの軌道がシミュレーションでは追従できるのに、実機では誤差が増えたり停止したりする場合、アクチュエーターの非理想特性を層ごとに分けて扱う必要があります。基本となる流れは、指令値、量子化、出力制限、伝達機構、実機状態を分離してモデル化し、シミュレーターと低レベル制御器の両方に同じ制約を適用することです。

上位計画には、位置だけでなく速度、加速度、ジャーク、動力学から得られるトルク制約を入れます。さらに、量子化による誤差やバックラッシュの不確実性は、安全余裕、方向反転の回避、またはロバストな可到達集合として反映します。

問いが重要な理由

幾何学的に正しい経路でも、時間の割り当てが速すぎれば、必要なトルクや加速度が実機の能力を超えます。また、指令値を細かく変化させても、通信や制御テーブルの分解能を下回れば、実際の出力は変化しません。減速機などにバックラッシュがあれば、方向を反転した直後の指令が出力軸の運動に直結しないこともあります。

これらを低レベル制御だけで吸収すると、上位計画が「実行できない軌道」を生成し続けます。制約を計画層まで伝えることで、軌道生成の段階で実行可能性を判定できます。

前提となる用語

飽和は、入力または出力が上限・下限に達し、それ以上増えない状態です。制御入力のクリップ、アクチュエーター内部で生成できる力・トルクの制限、関節へ実際に伝達される力・トルクの制限は、同じものではありません。

量子化は、連続値を有限の刻みで表現する処理です。指令値側とセンサー側を分け、量子化幅、丸めまたは切り捨て、ゼロ次ホールド、サンプリングや遅延を確認します。

バックラッシュは、伝達機構の遊びによって入力と出力の関係が方向依存になる現象です。単純な加法ノイズではなく、入力方向、相対変位、接触状態を持つヒステリシスやプレイ演算子として扱うのが適切です。

内部の仕組み：制約を層に分解する

第一に、コントローラーが生成した指令を量子化します。指令単位が粗い場合、微小な補正は同じ離散値に丸められます。第二に、速度リミッターや電流リミッター、入力範囲の制限を適用します。第三に、アクチュエーターが生成できる力・トルクを制限します。最後に、減速機などの伝達機構を通して関節へ出力される力・トルクを計算します。

この分離が必要なのは、入力をクリップしても、実際の出力トルクが同じ割合で制限されるとは限らないためです。MuJoCoのアクチュエーター機構でも、制御入力、生成力、関節へ伝達される力が別の段階として扱われています。一方、標準的なロボット制御インターフェースでは、位置・速度・加速度・ジャーク・努力量などは扱えても、量子化幅やバックラッシュ状態まで標準化されているとは限りません。伝達機構とハードウェア固有の非線形性は、追加のモデルとして実装します。

計画側では、経路上の位置を時間パラメータ化し、速度・加速度と動力学的なトルク制約を同時に評価します。時間スケーリングを遅くすれば、必要トルクが下がる場合がありますが、速度依存の限界や制御遅延があるため、単純に低速化すれば十分とは限りません。

flowchart LR
  P["上位計画"] -->|"位置・速度・加速度・ジャーク・トルク制約を適用"| T["時間パラメータ化された軌道"]
  T --> C["低レベル制御器"]
  C --> Q["指令値量子化"]
  Q --> R["速度・入力範囲の制限"]
  R --> E["電流・努力量の制限"]
  E --> A["アクチュエーターの生成力・トルク制限"]
  A --> B["バックラッシュ・伝達機構モデル"]
  B --> J["関節出力"]
  J --> M["実機状態"]
  M --> S["センサー量子化・サンプリング・遅延"]
  S --> C
  M --> I["実機同定・検証"]
  I -.->|"制約値と不確実性を更新"| P
  I -.->|"層ごとのモデルを更新"| Q

制約を入力、アクチュエーター、伝達機構、観測の層に分け、同じモデルを計画器と低レベル制御器に反映する流れ。

計画に反映する選択肢

対象	推奨するモデル	上位計画への反映
連続トルク限界	通常運転で継続可能な値	基本の動力学制約として使用
短時間ピーク限界	時間や条件付きの上限	短い区間に限定し、連続値と分離
指令値量子化	指令単位、丸め、保持	微小な指令変化を実行可能とみなさない
センサー量子化	観測値の刻みと更新周期	状態推定の不確実性や余裕に反映
バックラッシュ	プレイ演算子、ヒステリシス、伝達機構モデル	方向反転回避、余裕、ロバスト計画
温度・電圧・速度依存	条件ごとの限界値	運転状態に応じて保守的な制約を選択

制約値は、定格値、連続許容値、短時間ピーク値を区別します。メーカーが示す最大トルクや最大電流は瞬間的なピーク値の場合があり、計画にそのまま使うと連続運転で余裕を失う可能性があります。通常の計画には、同定誤差と制御遅延を含む保守的な連続許容値を使い、ピーク値は時間や条件を限定して扱います。

Sim-to-Realの性能劣化を分解する：物理パラメータ・センサー・制御の補正手順

Sat, 14 Feb 2026 00:12:29 +0900

シミュレーション上の成功が実機で崩れるとき、物理モデルだけを疑う前に、ログと時間の整合性を確認したくなります。

先に結論

Sim-to-Realで性能が落ちたとき、いきなり摩擦や質量を調整するのは得策ではありません。まず単位、座標系、アクションスケール、時刻、制御周期などのインターフェースを確認し、次にセンサーと遅延、アクチュエータと低レベル制御、剛体・運動学、接触・環境の順で補正します。その後、残る不確実性に対してダイナミクスランダム化、実機データによる分布更新、オンライン適応、方策の再調整を検討します。

この順序は、すべてのロボットやタスクで保証された標準手順ではありません。各段階で学習に使っていない実機ログを検証し、残差のパターンが変わったかを確認することが前提です。

なぜ原因分解が必要か

実機で方策が失敗すると、物理モデルが間違っていると考えがちです。しかし性能差は、観測・レンダリング、時間同期と通信遅延、アクチュエータと低レベル制御、剛体・接触ダイナミクス、環境分布、方策の汎化誤差に分かれます。複数の要因が同じ軌道誤差を生むこともあるため、単一種類のログだけではパラメータを一意に決められない場合があります。

たとえば、定常的な位置や角度のずれはゼロ点や座標系、位相遅れはタイムスタンプ・通信・制御遅延、自由空間での振幅差はゲイン・摩擦・慣性を優先的に疑います。接触時の衝撃や滑りは摩擦、剛性、接触形状の不一致と結び付きやすく、視覚入力時だけ失敗するならカメラやレンダリング分布の差を調べます。

まず確認する用語

システム同定は、実機の入力と状態のログから、質量、摩擦、遅延などのモデルパラメータを推定する考え方です。ダイナミクスランダム化は、質量、摩擦、モーター出力などをエピソードごとに変化させ、単一モデルへの過適合を避ける方法です。視覚系ではテクスチャ、照明、カメラ姿勢、背景、オブジェクト配置などを変化させます。

オンライン適応は、実機の履歴から環境やダイナミクスの潜在状態を推定し、方策を適応させる方法です。固定パラメータの精密化だけでは扱いにくい、時間変化する差への選択肢になります。

実機データでの補正手順

1. ログとインターフェースを監査する

最初に、単位、座標系、アクションのスケール、飽和処理、ログ時刻、制御周期をそろえます。センサー、制御入力、状態推定、時刻情報は同一試験単位で保存し、後から再生できる形にします。ROS 2ではros2 bagに指定トピックを記録・再生できます。

ここが崩れていると、後段で物理パラメータを調整しても、入力と観測の対応がずれたままになります。まず再生ログとシミュレーションの入出力インターフェースが一致するかを確認します。

2. センサー、座標系、時間を合わせる

センサーのバイアス、ゼロ点、外部パラメータ、ノイズ、観測遅延を調べます。視覚入力を使う場合は、テクスチャ、照明、カメラ姿勢、背景、物体配置の差も対象です。実機画像に近い観測分布を作るだけでなく、視覚以外の状態推定値についても、シミュレーションと同じ前処理になっているか確認します。

3. アクチュエータと低レベル制御を合わせる

指令値が同じでも、モーターの応答、トルク制限、内部制御器、フィルタ、遅れによって実際の運動は変わります。脚ロボットなどでは、アクチュエータモデルをシミュレーションに含めることが、剛体パラメータを合わせることとは別の補正対象になります。

4. 剛体・運動学を調整する

質量、重心、慣性、関節減衰などを確認します。重力姿勢や自由空間の運動を使い、剛体モデルと運動学の誤差を切り分けます。MuJoCoのモデル定義では、ボディ、関節、アクチュエータ、センサー、接触・摩擦関連の要素を個別に設定でき、パラメータをカテゴリ別に管理する際の参照になります。

5. 接触と環境を調整する

接触時だけ残差が増える場合は、摩擦、接触剛性、反発、接触形状、床など環境側の条件を調べます。自由空間の運動が合っていても、接触ダイナミクスがずれていれば、滑りや衝撃を再現できません。

flowchart LR
  A["実機で性能劣化"] --> B["残差パターンを観測"]
  B --> C["定常的な位置・角度オフセット"]
  B --> D["位相遅れ"]
  B --> E["自由空間での振幅差"]
  B --> F["接触時の衝撃・滑り"]
  B --> G["視覚入力時だけの失敗"]
  B --> H["時間変化する差"]
  C --> C1["ゼロ点・座標系・初期姿勢"]
  D --> D1["時刻・通信・制御遅延"]
  E --> E1["ゲイン・摩擦・慣性・アクチュエータ"]
  F --> F1["摩擦・剛性・接触形状・環境"]
  G --> G1["カメラ・レンダリング分布・前処理"]
  H --> H1["オンライン適応・履歴からの状態推定"]

実機ログに現れる残差パターンを手掛かりに、優先して確認する原因カテゴリを切り分ける。

6. 不確実性と方策を扱う

点推定したモデルで実機を再現できない場合は、同定値の周囲に不確実性を持たせたダイナミクスランダム化を行います。実機ロールアウトとシミュレーション軌道の差を使い、ランダム化分布やシミュレーションパラメータを更新する方法もあります。それでも時間変化する差が残るなら、オンライン適応や残差方策を追加し、最後に方策自体を再調整します。