LOG95R2R2R2026/3/15

UnityのArticulationBodyが初めて物理的に正しく動いた｜mechArm 270関節制御の転換点

やろうとしていたことと、実際に起きたことは、全く違った。

発端：Stiffnessが1e+25になっている

朝一番に届いた画像にこんな数値が写っていた。

Stiffness: 1e+25
Damping:   0

以前、コードが毎フレーム drive.stiffness を書き換えていたことで物理が崩壊した経験がある。同じ現象か、と思ったが違った。今回はUnityの仕様だった。

Drive Type = Target のとき、UnityはInspectorの Stiffness 値を無視して内部的に 1e+25（実質無限大）を使う。つまりこれまでずっと「物理の憲法（Stiffness 20,000 / Damping 2,000）」は見せかけだった。

コードを確認すると Start() にこう書かれていた。

drive.driveType  = ArticulationDriveType.Target;
drive.forceLimit = 1000000f;
// stiffness / damping への代入 → 一切なし

Target modeでは stiffness フィールドを書き込んでも無視される。ステートマシンを整備してピックアンドプレースが動くようになった段階で、その土台となるべき憲法値は、物理演算には一切届いていなかった。

解決策は明確だった。Drive Type を Force に変え、コードの全4箇所に憲法値を明示する。

drive.driveType  = ArticulationDriveType.Force;
drive.stiffness  = 20000f;
drive.damping    = 2000f;
drive.forceLimit = 1000000f;

この変更を Start() / LateUpdate() CCD / SyncDriveTargetsToPhysics() / ResetCooldown() の4箇所に適用した。

再生した瞬間、Inspectorに表示された数値は：

Stiffness: 20000  ✅
Damping:   2000   ✅
Drive Type: Force ✅

プロジェクト開始以来初めて、憲法値が本当に物理演算に反映された。

CSVログで関節の実測値を解析すると、j3（link4）が可動域を超過していることが判明した。

j3制限: ±155°
実測値: -162.1°（超過 7.1°）

これは drive.target のClampは機能しているが、Force mode + PD制御のオーバーシュートで jointPosition（実際の角度）が制限を超えてしまう問題だ。

試みた3つのアプローチ：

① PENALTY押し返し（5f / 15f）：超過を検出したら drive.target を逆方向にセット。結果は振動が増えて悪化。-157.4° → -157.8°。

② CCDスキップ方式：超過方向への書き込みをスキップ。他のjointへの負荷が増え、j3が-252.6°まで悪化。IKの自由度を制限すると残された関節への負荷が集中する、という典型的な挙動だった。

3手試して全て悪化。これはCCDアルゴリズムの構造的問題であり、簡単には解決しない。

さらに深刻な問題が再生中に現れた。link1が base から物理的に離脱した。

link1 Position（再生中）: X:0.0811  Y:0.0695  Z:-0.0729

実機ならボルトが引きちぎれた状態に相当する。

再生を止めると元の位置に戻ることを確認した後、Force mode切替前の安定状態に巻き戻してクローズした。安全のための判断だ。

UnityのArticulationBodyはDrive Typeによって全く別の物理エンジンで動いている。

Target modeは「位置を即座に達成する」ことを最優先する。物理的な正確さより到達を優先するため、剛性を無限大にする。これはデモには使いやすいが、実機への移行を前提とした「物理的に正しいロボット制御」には向かない。

Force modeは「PDゲインで目標に向かう力を出す」物理的に自然なモデルだ。実機の電流制御や減速機の挙動に対応する。

「見た目が動いていること」と「物理が正しく動いていること」は全く別だ。その区別を数字で証明した作業記録になった。