MuJoCoでロボットアームが崩れ落ちた。『サーボの力不足』に見えたのは計算の発散だった。見分け方と、わざと垂れさせるテスト

課題

空き時間で、小さなロボットアームをキーボードで動かす工作を進めている。

以前に書いたロボットアーム部品の調達で、12日前に固めたリストが注文直前に様変わりしていた話で注文したアームのキットは、届いてみたら不良品だった。アームの骨組みになる部品は、そろえ直すことになった。

そこで順番を変えた。骨組みを買う前に、コンピュータの中でアームを組んで動かし、腕の長さを決めてから買う。重さや力を計算して物の動きを再現する「物理シミュレータ」を、設計の道具として先に使う作戦になる。

ところが、AIに作ってもらったシミュレータを最初に動かすと、アームが崩れ落ちた。見た目は「このサーボでは、この長さの腕を支えられない」という結果そのもの。

でも、実際はサーボの力不足ではなく、シミュレータの計算が暴れていただけだった。

解決できるようにすること

• シミュレータで「できない」と出たとき、それが本当に部品の限界なのか、シミュレーションが壊れているのかを見分けられる
• 見分けたあと、同じ取り違えを繰り返さないための「壊れるはずのテスト」を置けるようになる

先に結論

• 最初の結果は、腕を水平に伸ばすとアームが崩れ落ち、全部の関節が力の上限に張り付くというものだった
• 止まった姿勢で重さを支えるのに必要な力を、別の計算で出すと、肩で0.058 N·m。サーボ（SG90）の上限0.176 N·mの約3分の1で、本来は余裕で支えられる
• 原因は、サーボの中の歯車とモーターが持つ「回りにくさ」（armature）がモデルに入っていなかったこと。これを足して計算の間隔を細かくすると、ずれは0.33度に収まり、支える力も別の計算の値と一致した
• 直したあと、「今の長さなら支えられる」テストと対にして、「肩と肘を400mmにした長すぎるアームは垂れる」テストを残した。こちらが落ちるときは、シミュレータの物理が効いていない、という目印になる
• 腕の長さはまだ暫定値で、どの長さにするかは決めていない

この記事でわかること

• シミュレータで「力が足りない」と出たときに、まず確かめる順番
• 力（トルク）を「重さ×距離」で概算するやり方
• 「壊れるはずの条件」をテストに残す理由と置き方

ここで、こう思う人もいるかもしれない。

「シミュレーションで崩れたなら、素直にサーボが弱いと考えるのが普通では？」

たしかに、そう読める結果だった。ただ、今回のシミュレータは「このサーボでこの長さの腕を支えられるか」を見るために作ったもの。崩れ落ちる姿は、その問いへの答えにそのまま見えてしまう。目的どおりの症状に見えるからこそ疑いにくいのでは、と思う。だから、同じ答えを別の方法でも出してみる価値がある。

何をしていたか: 部品を買う前に、シミュレータで腕の長さを決める

アームは4つの関節を持つ小さなもので、根元の回転、肩、肘、手首を、工作でよく使われる小型のサーボモーター（SG90）で動かす。サーボモーターは、角度を指定するとその角度まで回って止まるモーター。

シミュレータは、自分から「3D空間のシミュレータ（物理演算と3D表示）を付けたい」と頼んでいたもの。どう進めるかの選択肢をAIが出し、その中から自分が2つ決めた。

• シミュレータを設計の道具として先に使い、腕の長さを決めてから部品を買う
• 重さや力の計算（物理演算）は、最初から入れる

物理シミュレータには、MuJoCoを使った。当初はPyBulletという別のシミュレータの予定だったけど、開発に使っているMacではインストールできず、AIがMuJoCoに切り替えている。アームの形を特定のシミュレータに依存しない共通の書式（URDF）で書いていたので、切り替えで書き直したのはファイル1つで済んでいる。

肝心の設定は、各関節が出せる力の上限。SG90が止まった状態で出せる最大の力（0.176 N·m）を上限にしてある。トルクは「回す力」のことで、0.176 N·mは、軸から1cm先で約1.8kgの重りを支えられるくらいの力になる。

こうしておけば、長すぎる腕は支えきれずに垂れ下がる。部品を買う前に、机の上ではなくコンピュータの中で失敗できる、という狙い。

今の長さは、肩80mm、肘80mm、手首40mm、先端のペン40mm。どれも仮置きの値で、どの長さにするかの判断はまだしていない。この値を試して決めることが、まさにこれからの作業になる。

最初の結果: アームが崩れ落ち、全部の関節が力の上限に張り付いた

AIが最初に、全部の関節を「腕を水平に伸ばした姿勢」にするよう指示して動かしたところ、アームは崩れ落ちた。画面で見たのではなく、関節の角度と力の数値での話。全部の関節が、力の上限（プラスマイナス0.176 N·m）に張り付いていた。

読み方は1つしかないように見える。「SG90では、この長さの腕は支えられない」。

これを信じると、次は「腕を短くする」「もっと強いサーボを買う」という部品の判断に進む。記録には、この誤った結論を、そのまま部品選びに持ち込みかねなかった、と残っている。

見分け方1: 必要な力を、別の計算で出す

AIはここで、止まった姿勢で重さを支えるのに必要な力（静的なトルク）を計算した。時間を進めながら動きを追う計算とは別に、「この姿勢で止まっているには、各関節にどれだけの力が要るか」だけを出す計算になる。

結果はこう。

関節	必要な力	SG90の上限に対して
肩	0.058 N·m	約3分の1
肘	0.028 N·m	約6分の1
手首	0.008 N·m	ごくわずか

物理的には、余裕で支えられるはずだった。つまり、崩れ落ちたのは設計の問題ではない。シミュレーションのほうを疑う番になる。

「重さ×距離」なら、電卓でも出せる

記録では、この値をシミュレータに備わっている「止まった姿勢で重力と釣り合う力」を出す機能で計算していた。同じモデルの中の計算ではあるけど、時間を進めないので、動きの計算が暴れていても影響を受けない。

この記事を書くにあたって、AIに同じ値を手計算でも出してもらった。腕を水平に伸ばしたとき、肩にかかる力は「各部品の重さ×肩からその部品の真ん中までの距離」を足し合わせたものになる。

部品	重さ（モデル上の値）	肩からの距離	重さ×距離
肩〜肘の腕（80mm）	11.9g	40mm	478
肘〜手首の腕（80mm）	11.9g	120mm	1,433
手首から先の腕（40mm）	10.5g	180mm	1,885
ペン先（40mm）	9.7g	220mm	2,128
合計			5,923 g·mm

5,923 g·mmは0.005923 kg·m。これに重力の9.81を掛けると、約0.058 N·m。記録の値と一致した。肘と手首も、同じやり方でそれぞれ0.028、0.008になる。

部品の重さは、板の大きさと樹脂の重さから計算したモデル上の値。モデルでは、腕とペン先の部品それぞれに、サーボ1個分の9gを足している。実物は量っていない。それでも「上限の3分の1か、上限を超えるか」くらいの差なら、この概算で十分見分けられると思う。

見分け方2: 「力不足」と「計算の暴れ」は、症状の形が違う

AIは次に、関節が指示された角度に戻ろうとする強さ（ゲイン）を上げてみた。本当に力が足りないだけなら、強さを上げても上限に張り付くだけのはず。

戻ろうとする強さ（kp）	指示した角度とのずれ
5	38.8度
20	30.2度
50	17.8度

強さを上げるとずれは減ったけど、どれも大きくずれたまま。決め手になったのは、力の向きだった。関節の力の符号（プラスとマイナス）が、行ったり来たりしていた。AIはこれを見て、重さに負けているのではなく、計算が暴れている（発散している）と判断している。

一般的な目安として、重さに負けているなら、力は重さに逆らう一方向の上限に張り付いて、腕はそのまま垂れる。上限のプラスとマイナスを往復しているなら、関節が行き過ぎては戻りすぎる、を繰り返している。後者は、部品の力ではなく計算の問題を疑う形だと思う。

原因: サーボの中の「回りにくさ」（armature）が入っていなかった

原因は、armature（アーマチュア）という値が抜けていたことだった。

サーボモーターの中には、小さなモーターと歯車が入っている。速く回るモーターの回転を歯車で落として、強い力を出す仕組み。逆に言うと、外から関節を回そうとすると、中のモーターを何倍もの速さで回すことになる。だから関節は、腕の見た目の重さ以上に回りにくい。この「中のモーターの分の回りにくさ」がarmatureになる。

今回の腕は小さくて軽い。そこにこの回りにくさが入っていなかったので、シミュレータの中の関節は、ほとんど抵抗なく回る扱いになっていた。記録によると、この状態では制御が硬くなりすぎて（わずかなずれにも強く反応しすぎて）、普通の計算の間隔では発散する。少し押すと行き過ぎ、戻そうとしてまた行き過ぎる、というイメージ。

しかも、ロボットの形を書く共通の書式（URDF）には、この値を書く欄が無い。形の書式どおりに書いただけでは、どうしても抜け落ちる値だった。そこで、シミュレータ側のコードで与える形にしている。

直し方は2つ。

• armatureを1e-4（0.0001）にした
• 計算の間隔（時間刻み）を0.5ミリ秒にした。1秒を2,000回に分けて計算する細かさ

結果、指示した角度とのずれは0.33度で落ち着いた。そして、各関節が支えている力は、前の節で出した静的な計算の値（0.058、0.028、0.008）と一致した。別の計算と答えが合ったことで、今度の結果は信じていい、と判断できる。

直したあとに置いたもの: 垂れるはずのアームのテスト

ここで、こう思う人もいるかもしれない。

「直って、計算とも一致したなら、もう確認は要らないのでは？」

今回はそこで終わらせず、テストを2つ、対にして残した。

テスト	条件	合格の基準
今の長さなら支えられる	今の暫定寸法	指示した角度とのずれが2度未満
長すぎるアームは垂れる	肩と肘を400mm（今の5倍）	肩のずれが5度より大きい

2つ目が、壊れるはずの対照。記録には「後者が落ちるときは、物理が効いていないことを意味する」と書いてある。

なぜ対で置くのか。自分なりに整理すると、1つ目のテストだけでは、シミュレータの物理が何かの理由で効かなくなっても、気づけない。力の上限がかかっていなかったり、重さが計算されていなかったりすれば、腕はむしろ「支えられている」ように見えて、1つ目は合格してしまう。2つ目は、物理が正しく効いているときにしか合格しない。

前に載せたグラフのいちばん下は、記事を書くときにこの400mmのアームを同じやり方で手計算してもらった値で、肩に約0.35 N·m。上限の約2倍で、垂れるのが当然の条件になっている。テストは、MuJoCoを入れた環境で全96件が合格している。つまり、この対照のアームは実際に5度より大きく垂れた（何度垂れたかは記録に無い）。

もう1つ実用的な点。MuJoCoは開発用のパソコンだけに入れて、Raspberry Pi（アームを実際に動かす小さなコンピュータ）には入れない前提にしている。そのため、シミュレータを使うテストは、MuJoCoが無い環境では自動で飛ばす（スキップする）ようにしてある。MuJoCoが無い環境で試すと、87件が合格、1件がスキップだった。

描画の速さを測った話との違い

少し前に、ブラウザで平らな絵を重ねる試作の速さを測ったときも、確実に重いはずの処理（対照）を一緒に測って、測り方そのものを確かめた（平らな絵を重ねる試作の記事で書いた話）。記録には、今回の件も「対照を持たない1つの測定を信じた」という同じ型だと残っている。

ただ、順番は違う。あのときは、測り方を何度か直したあとに対照を置き、最終的な測り方が描画を捉えていることを確かめた。今回、最初の取り違えを止めたのは対照ではなく、静的な力の計算という別の方法だった。対照は、直したあとに「次に同じことが起きたら気づけるように」テストとして置いた。

1回目は別の計算で止め、2回目以降は対照で止める。この2段構えが、シミュレータを設計に使うときの基本形になりそう、というのが今の見立て。

AIにシミュレーションを任せるときの確かめ方

今回の流れを、ほかの場面でも使える形にまとめるとこうなる。

1. 結果が「何を買うか」「どう作るか」に直結するときは、同じ量を別の計算で出す。 止まった姿勢の力なら「重さ×距離」の足し算で概算できる
2. 症状の形を見る。 力の向きが行ったり来たりしている、設定を少し変えると結果が大きく動く、という場合は、部品の限界より計算の問題を疑う
3. 直したら、もう一度1の計算と突き合わせる。 合えば、その結果は使っていい
4. 「できるはず」と「壊れるはず」のテストを対で置く。 壊れるはずのほうが壊れなくなったら、シミュレータを疑う合図になる
5. シミュレータが再現しないものを書き出しておく。 今回なら、歯車のガタ、サーボの個体差、軸まわりの摩擦、樹脂の部品のたわみ

AIに頼むなら、たとえば「シミュレーションの結果を設計の結論にする前に、静的な計算で裏を取って。食い違ったら先に報告して」と一言添えておくと、1を飛ばしにくくなると思う。

まだ確かめていないこと

• 腕の長さは暫定値のまま。どの長さにするかの判断は、まだ1つもしていない
• シミュレータは、歯車のガタ、サーボの個体差、軸まわりの摩擦、樹脂の部品のたわみを再現しない。ここで決める長さは仮説で、実物のアームで確かめる段階が別にある
• 骨組みの部品はまだ買っていないので、実物のアームでは何も確かめていない
• シミュレータの画面表示は確認していない。確かめたのは画面なしの計算だけ
• 部品の重さはモデル上の計算値で、実物は量っていない
• 400mmのアームで肩に約0.35 N·mという値は、記事を書くときの手計算で、記録には無い

こんな人に向いている

個人で、ロボットや物理シミュレーションをAIと一緒に試している人に向いている。

特に、シミュレータの結果をもとに「何を買うか」「どれくらいの大きさで作るか」を決めようとしている人。AIが「シミュレーションしたら無理でした」と言ってきたとき、それを部品の限界と受け取っていいかを判断する材料になるはず。

まとめ

シミュレータの中でアームが崩れ落ちたとき、それは「サーボの力不足」にしか見えなかった。でも、止まった姿勢で必要な力を別の計算で出すと、上限の約3分の1。崩れたのは、サーボの中の回りにくさ（armature）が抜けて、計算が暴れていたからだった。

直したあとは、別の計算と答えが合うことを確かめ、さらに「長すぎるアームは垂れる」というテストを残した。垂れるはずのものが垂れなくなったら、シミュレータを疑う。

項目	内容
結論	アームが崩れたのは力不足ではなく計算の発散。必要な力は肩で0.058 N·m（上限0.176の約3分の1）。armatureを足して時間刻みを細かくすると、ずれ0.33度で安定し、支える力も静的な計算と一致した
教訓	シミュレータの結果を設計判断に使う前に、同じ量を別の計算で出す。直したあとは、壊れるはずの条件をテストに残す
対象読者	個人でロボットやシミュレーションをAIと試している人

同じ状況に陥ったときの回避策

• シミュレータが「できない」と言ったら、まず「重さ×距離」で必要な力を概算し、部品の上限と比べる
• 力の向きが振動していないか、設定を変えると結果が大きく動かないかを見る
• 小さく軽い部品を関節で動かすモデルでは、サーボやモーターの中の回りにくさ（armature）が入っているかを確かめる
• 直したら、支える力が概算と一致するかを見る
• 「できるはず」のテストと「壊れるはず」のテストを対で残す
• シミュレータで決めた寸法は仮説として扱い、実物で確かめる段階を別に用意する

次に読むなら

シミュレーションの結果を別の計算で確かめる考え方が分かったら、数字以外も含めて、AIの答えを使う前にどこを確かめるかを一通り押さえておくと、同じ型の見落としを減らしやすい。

• AIの回答を鵜呑みにしないための確認チェックリスト — 数値・出典・矛盾・実行結果を、AIの回答を採用する前にどこで確かめるかをまとめたチェックリスト

---

この記事は、筆者が個人の空き時間で取り組んでいるロボット工作（アーム型ロボットの制御）の開発記録（2026年10月12日）を基に、独自調整したAIが下書きを作成し、筆者が事実確認・編集を行った上で公開しています。本文の説明図と、力の手計算の表は、記録をもとにAIが作成しています。