シミュレーション・制御・実機

MuJoCo 3.14はなぜ布の接触に貫通しない方式を足したのか

2026/10/3

🤖 AIが執筆しています

MuJoCo 3.14のipcモードは、更新を確定する前に経路を調べる

MuJoCoは、Google DeepMindが開発するオープンソースの物理シミュレータである¹。MuJoCoは、布やシートのような変形する物体をflexという要素で表す。2026年9月22日公開の3.14.0は、flexの接触に貫通（物体どうしが重なった状態）を起こさないための実験的な接触モードとして、ipcという設定（フラグ）を加えた¹。以下、この設定を有効にした状態をipcモードと呼ぶ。作り手は、確定するすべての位置の更新を連続衝突判定で交差なしと確かめるので、flexの接触は通り抜けないと書く¹。この確かめ方で保たれるのは、確定される位置がつねに交差していない、という点である。交差が見つかったときの扱いは、作り手の文書には書かれていない。MuJoCoのソースの注記は、連続衝突判定が許す割合だけ位置を進めると書く³。

ipcの名は、IPC（Incremental Potential Contact）に由来する。IPCは、Minchen Liほかが2020年にACM Transactions on Graphics（SIGGRAPH）で発表した接触の計算方式である⁴。IPCは各時間刻みで、物体の変形と慣性のエネルギーに接触の条件を合わせた一つの最小化問題を解き、交差しない位置だけを採る。IPCの実装は一般に、位置の更新の候補を連続衝突判定で調べ、交差が見つかれば更新の幅を縮める。IPCの論文は、この方式が材料の値や時間刻みの大きさによらず、交差のない軌道を保つと書く⁴。

MuJoCoのipcモードは、各刻みで、接触の条件を線形化したうえで一つの最小化問題を解く。IPCの論文は平滑化したbarrier（障壁関数）で解くが⁴、ipcモードはbarrierを使わない拡張ラグランジュ法で解く¹。この拡張ラグランジュ法は、Juntian Zheng、Zhaofeng Luo、Minchen Liが2026年にACM Transactions on Graphicsで発表した、barrierを使わない方式である⁵。MuJoCoのソースの注記は、この論文を実装の出典として挙げる³。作り手は、このモードが実験的であると明記している²。IPCの論文が書く保証は論文の方式についてのもので、MuJoCoの作り手がこのモードについて挙げる根拠は、確定する更新を連続衝突判定で確かめることである¹。

ipcモードが解く接触は、flexどうしと、flexと静止した平面・球・カプセル・箱・メッシュとの接触である²。対応するflexは面状（dim-2）のものである。設定は模型全体に掛かり、対応するflexはすべてこの方式で接触を解く²。動く物体とflexの接触と、剛体どうしの接触は、制約ソルバー（MuJoCoが接触の力を求めてきた従来の解法）が扱う²。ただし剛体もipcモードの刻みの中で進められ、2次元のflexを持たない模型もこの刻みを通る²。2次元のflexを持つ模型では、mj_forward の後の qacc は制約の力を含まない自由飛行の加速度になる²。たたんだ布の層どうしの接触はflexどうしなのでこのモードの対に入るが、動く指と布の接触は入らない。

Genesisは同じ方式をlibuipcに任せ、扱う物体の範囲が違う

Genesisは、ロボット学習向けのオープンソースの物理シミュレータである⁶。Genesisは、IPCの計算を自分で実装せず、外部ライブラリlibuipcに任せる。libuipcは、IPCをGPUで実装したライブラリで、香港大学、カーネギーメロン大学、Genesis AIなどの研究者が開発し、著者にはIPCの原論文の著者であるMinchen Liが入る⁷。本稿がMuJoCoと並べて取り上げるのは、別の作り手がIPCに由来する方式を別の形で組み込み、何を保証し何を外したかを一次資料に書いているからである。

Genesisの剛体の計算と、libuipc側の物体（布、FEMの変形体、剛体）を双方向につなぐ部品が、IPC couplerである。coupler（カップラー）は、二つの計算をつなぐ部品を指す。FEM（有限要素法）は、変形する物体を小さな要素に分けて計算する方法である。GenesisのREADMEは、IPCが布、FEMの変形体、剛体という異なる材料にまたがる、頑健な接触の扱いの統一的な枠組みを与えると書く⁶。READMEの例は、Franka Pandaのロボットアームが変形する立方体をつかむ場面と、布を操作する場面である⁶。確認項目には、接触中に物体どうしのめり込みがないことと、Genesisの剛体の動きがIPC側の物体に影響し、その逆も成り立つことが並ぶ⁶。

libuipcは、剛体、FEMの柔らかい物体、布、糸を一つの場面で扱い、衝突判定、接触の組み立て、線形代数はCUDAで動く⁸。libuipcのREADMEは、位置の更新を連続衝突判定で調べて縮める手順を、連続衝突判定を使う線探索（line search）として挙げる⁸。libuipcの開発者は、このライブラリが正確で貫通のない摩擦接触を保証すると書く⁷。Genesis AIがこの拡張ラグランジュ法による方式（AL-IPC）をlibuipcに取り込んだことも、READMEに書かれている⁸。確定する位置の更新を連続衝突判定で確かめる点は同じでも、方式が扱う物体の範囲と摩擦の有無は、実装ごとに違う。

MuJoCoは摩擦と厳密な再生に、Genesisは対応環境に制限がある

ipcモードが解く接触には、摩擦が効かない²。この接触は面に垂直な力だけを持ち、関わるflexやgeom（MuJoCoで剛体の形状を表す要素）の摩擦の値は適用されない²。この対に入るのは、布どうしが擦れる場面や、布が静止した台の上を滑る場面である。摩擦が無いのはこの実装の制約で、IPCの原論文は摩擦のモデルを含み⁴、libuipcの開発者も摩擦接触を扱うと書く⁷。作り手はモードを実験的と明記しており、この制約が恒久か一時的かは書いていないので、本稿は断定しない。

強化学習で状態を保存して巻き戻す使い方も、ipcモードでは制限される。ipcモードは、接触の乗数（制約を満たすための力の大きさを表す変数）を時間刻みをまたいで保持するが、この乗数は状態の仕様に含まれない。そのため mj_getState と mj_setState は全状態を保存できず、厳密な再生に対応しない¹。この点も、作り手は変える予定を書いていない。

模型の尺度と、使える積分器・ソルバーは固定されている。ipcモードは、discrete積分器（MuJoCoの時間積分の方式の一つ）の接触モードで、他の積分器では使えない¹。ipcモードは、メートル単位の模型とミリ単位の厚さのflexを前提にし、検出帯を3 mm、表面間の静止すき間を1 mm、収束速度を0.05 m/sに固定している²。ソルバー（最小化問題の解法）はCG（共役勾配法）に限られ、fwdinvとsleepのフラグと併用できず、逆動力学の計算にも対応しない²。作り手はソースの注記で、検出帯などの3つの値を1〜2 msの時間刻みで調整したと書く³。同じ注記は、静止すき間を対ごとのflexの半径から求め、検出帯もそれに従わせることを、今後の作業（TODO）として挙げる³。収束速度と、積分器・ソルバーの制限については、ソースの注記にも変える予定は書かれていない。

布を固定する先にも制限がある。flexの頂点を固定できる先は、静止した物体か、slide関節（直線に沿って動く関節）だけでたどれる物体に限られ、その鎖にhinge（回転）・ball（球面）・free（自由）の関節が入るとエラーになる²。hingeの関節の先にある物体には、布の頂点を固定できない。

連続衝突判定が位置を最後まで進めきれない刻みでは、ipcモードは動きの一部だけを確定し、警告を出す³。時間は刻みの分だけ進むので、この症状はスローモーションのように見えると、作り手は書く³。

libuipcの保証にも前提がある。libuipcのREADMEは、貫通しない保証が正しい初期形状と、衝突判定と求解の各ステップの成功に依存すると書く⁸。呼び出しが終わったことを物理的な正確さの証明として扱わず、診断を確かめるよう求めている⁸。Genesisの例が対応する環境は、LinuxまたはWindowsのx86 CPUとNvidiaのGPUに限られ、READMEはその末尾に “for now”（当面）を付ける⁶。解消の時期は書いていない。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。