ロボット操作 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、固定時間刻み、サブステップ	トンネリング、衝突時刻、衝突インパルス
押し付け・把持・挿入	接触剛性・減衰、摩擦、位置拘束反復	侵入量、接触力、関節トルク、滑り遷移
組立・準静的操作	接触コンプライアンス、収束許容値、時間刻み	力の再現性、拘束残差、軌道の収束
積み重ね・多接触	ソルバー方式、反復回数、時間刻み	ドリフト、拘束残差、計算時間
モデルベース制御	積分器、拘束ソルバー、接触パラメータ	制御入力と接触応答の再現性

収束試験の進め方

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

自然言語からロボット行動へ：3Dグラウンディングと実行制約の設計

Mon, 28 Sep 2026 14:09:11 +0900

自然言語の「右側」や「隣」が、ロボットにとってどの座標と距離を意味するのかが気になるテーマです。

先に結論

ロボットに自然言語を直接モータ指令として渡すのは適切ではありません。「赤い箱を棚の右側へ置く」のような指示は、対象物、参照表現、空間関係、3D目標、座標系、許容誤差、動作前提、禁止条件、完了条件へ分解し、構造化された中間表現に変換するべきです。

VLMやLLMは、指示の意味解釈や操作候補の生成に使います。一方、実行前には物体の再同定、座標変換、到達可能性、衝突、視認性、把持可能性などを別の検証段階で確認します。意味の確信度が高くても、3D測位や軌道計画が成立するとは限りません。不確実性が大きければ、実行せずに確認質問、追加観測、再計画へ切り替える構成が基本になります。

なぜ3Dグラウンディングが必要か

自然言語には、ロボットがそのまま利用できる座標が含まれていません。「右側」は何を基準にした右側か、「隣」はどの距離までか、「それ」はどの物体を指すのかを決める必要があります。さらに、対象を認識できても、把持姿勢やアームの可動範囲、周囲の障害物を考慮しなければ行動には変換できません。

3D-LLMやSpatialVLM系の研究は、3Dシーン理解、視覚グラウンディング、物体間の距離や方向、相対位置の推論を扱います。ただし、3D上の参照対象を得られることは、安全な軌道や実行可能な把持姿勢を得たことと同じではありません。空間推論の評価結果を、そのまま実機操作の成功や安全性として扱うこともできません。

中間表現に含める情報

実装上は、言語理解の結果を一つの曖昧な文字列として保持せず、次の情報を分けて管理します。

対象物の同一性、検出された物体の候補、参照表現
「右側」「隣」などの空間関係と、その基準となる物体・座標系
目標となる3D位置、3D領域、または物体姿勢
許容誤差、把持や配置に必要な動作前提、禁止条件
言語解釈の確信度、対象同定の確信度、3D測位の不確実性
完了条件と、条件を満たさなかった場合の再計画方針

これは業界標準として確立した形式ではありません。実際にはロボット、センサ、タスクに合わせて設計する必要があります。重要なのは、意味解釈、幾何情報、実行可否を分離し、どの段階で不確実性が生じたかを追跡できることです。

変換の仕組み

処理は、おおむね次の段階に分けられます。まずVLMやLLMが、指示から対象物、操作、空間関係、候補となるスキル列を生成します。SayCanは、LLMによる言語的なタスク分解に、現在のロボット状態で各スキルを実行できるかを示すアフォーダンス値を組み合わせる方式です。言語的にもっとも自然な手順ではなく、環境で実行可能な候補を選ぶ点に意味があります。

次に、画像、点群、深度、ロボット状態などから作られた3Dシーンへ、対象と関係を接地します。VoxPoserは、物体や空間関係を3Dボクセル上の価値マップとして表現し、複数の価値マップを合成して操作や経路計画へ利用する枠組みを示しています。3D目標を一点だけでなく領域や価値として持てるため、配置や経路の条件を計画器へ渡しやすくなります。

その後、カメラ座標系などで得た情報をロボット基準の座標系へ変換し、目標位置・姿勢と動作条件を検証します。到達できるか、衝突しないか、対象を視認し続けられるか、把持できるか、速度や力の制約を満たすかを確認してから、モーションプランナーへ渡します。実行中も観測を更新し、状態が想定から外れれば停止、再観測、再計画へ分岐させます。

flowchart LR
  A["自然言語指示"] --> B["対象物・操作・空間関係・スキル候補の生成"]
  B --> C["候補集合の作成と参照表現の解決"]
  C --> D{"対象が一意か"}
  D -- "いいえ" --> Q["確認質問または追加観測"]
  Q --> C
  D -- "はい" --> E["3Dシーンへグラウンディング"]
  E --> F["構造化中間表現の生成"]
  F --> F1["対象・基準物体・座標系・3D目標・許容誤差・禁止条件"]
  F1 --> G["座標変換と状態統合"]
  G --> H["到達可能性・衝突・視認性・把持・速度・力の検証"]
  H --> I{"実行条件を満たすか"}
  I -- "いいえ" --> R["停止・再観測・再計画"]
  R --> E
  I -- "はい" --> J["モーション計画"]
  J --> K["ロボット実行"]
  K --> L["実行中の観測更新"]
  L --> M{"完了条件を満たすか"}
  M -- "はい" --> N["完了"]
  M -- "いいえ" --> R

言語モデルの出力を直接モータ指令に接続せず、3D目標と実行制約を検証してからロボットへ渡す処理の流れ。

参照表現は候補集合として扱う

「赤い箱の隣」「それを持ち上げて」のような表現を、最初から単一の物体へ決め打ちするのは危険です。検出された物体、過去の行動履歴、3Dシーン内の空間関係を使って候補集合を作り、候補が一意になるかを確認します。

ロボット学習の合成データ戦略：実機データとの境界をどう設計するか

Wed, 15 Apr 2026 00:45:58 +0900

合成データを増やせば実機データを減らせる、という単純な関係ではない点が気になるテーマです。

先に結論

ロボット操作向けの合成データは、実機データを一律に置き換えるものではない。視覚的なばらつきや、シミュレータで正確に生成できる状態・ラベルが成否を左右するなら、視覚認識の事前学習や一部の方策学習で実機データを代替できる。一方、摩擦、接触順序、柔軟性、センサー雑音、アクチュエータ遅延などが支配的な操作では、実機の成功・失敗例を基準データとして残し、合成データで拡張したうえで実機微調整と独立評価を行うべきだ。

したがって、設計の単位は「合成データ何％」ではなく、視覚・物理・センサー・ラベルという要因ごとの再現可能性である。タスクを分解し、実機で固定すべき分布と、シミュレーションで広げる分布を決めることが出発点になる。

なぜ代替条件の切り分けが必要か

合成データは、実機では収集しにくい大量の画像、状態、軌道を生成できる。しかし、生成量が増えても、シミュレータに含まれない失敗要因は学習できない。反対に、現実の一例へ過度に合わせたシミュレーションは、別の照明、背景、物体配置、物理条件で性能を落とす可能性がある。

また、先行研究の「合成データ」は同じものではない。画像のドメインランダム化、物理パラメータのランダム化、実機デモンストレーションから生成した合成軌道など、方式と目的が異なる。そのため、研究間の性能値を単純に並べて、普遍的な混合比率を導くことはできない。

前提となる用語

ドメインランダム化は、テクスチャ、照明、姿勢、背景、物体配置などをシミュレーション中に変化させ、実環境の見え方に対する頑健性を学習させる方法である。シミュレーション画像だけで学習した物体認識モデルを実環境へ移転した実証がある。

ダイナミクスランダム化は、質量、摩擦、遅延などの力学パラメータを変化させる方法である。単一の物理モデルへ過適合することを避け、複数の条件に対応する方策を学習する。研究対象となったロボット制御タスクでは、追加の実機学習なしで実機へ移転した例も報告されている。

実機アンカーとは、実際のカメラ、物体、治具、ロボットで取得した成功・失敗データを、学習や評価の基準として使う考え方である。シミュレーションの分布を広げる場合でも、現実にどのような見え方や接触が起きるかを判断する基準になる。

合成データが機能する仕組み

視覚認識では、実運用で起こり得る照明、背景、姿勢、物体配置を広くランダム化することで、特定の画像条件への依存を抑える。物体の位置や形状をシミュレータが管理していれば、認識対象のラベルも一貫して生成できる。この領域では、実機画像を使わずに学習したモデルの実環境移転が示されている。

制御では、質量や摩擦、遅延といったパラメータを一つに固定せず、分布として扱う。さらに、接触を伴う器用な手内操作についても、視覚と物理ダイナミクスをランダム化して学習した方策を実機で評価した事例がある。ただし、これらは特定のロボット、タスク、ランダム化設定での実証であり、別の構成にそのまま一般化できるとは限らない。

別の方法として、少数の実機による人間デモンストレーションを種データにし、シミュレーション内で物体配置や軌道を変換してデモンストレーションを増やす方式がある。これは実機データを排除するのではなく、現実の操作構造を保ったまま合成データで規模と多様性を補う設計である。

flowchart LR
  A["タスクを要因に分解"] --> B{"シミュレータで再現・ラベル生成しやすいか"}
  B -->|"比較的しやすい"| C["視覚認識・照明・背景・姿勢・状態ラベル"]
  C --> D["合成データ中心を検討"]
  B -->|"一部は再現可能"| E["質量・摩擦・遅延を含む制御"]
  E --> F["ダイナミクスランダム化と実機移転確認"]
  B -->|"再現しにくい要因が支配的"| G["接触順序・柔軟性・センサー雑音・固有差"]
  G --> H["実機アンカーと実機微調整を重視"]
  D --> I["独立した実機評価"]
  F --> I
  H --> I
  I --> J["失敗モードと未カバー領域を確認"]

合成データの比率ではなく、視覚・物理・センサー・接触など各要因の再現可能性でデータの役割を判断する。

要因別に見る選択基準

対象要因・タスク	合成データの役割	実機データの扱い	初期判断
視覚認識、照明・背景・姿勢のばらつき	ドメインランダム化で広く拡張	独立した実機評価に使用	合成中心を検討
物体配置や状態ラベル	状態とラベルを大量生成	実機分布との対応を確認	代替可能性が比較的高い
質量・摩擦・遅延を含む制御	ダイナミクスランダム化で条件を拡張	実機の移転性能と失敗を確認	タスク依存で併用
接触豊富な把持・手内操作	視覚・物理条件をランダム化	成功・失敗例をアンカーにする	混合を基本にする
柔軟物、摩擦、接触順序が支配的な操作	稀な条件や失敗条件を補う	実機データと実機微調整を重視	実機併用が必要
実機デモからの軌道生成	配置や軌道を変換して拡張	少数の種データを保持	ハイブリッドを検討

この表は固定的な処方箋ではない。特に、カメラの視野・ノイズ、アクチュエータの遅延、物体や治具の公差、柔軟性をシミュレータがどの程度表現できるかで判断は変わる。