MuJoCoで『このサーボでは届かない』と出たロボットアーム。原因はリンクの閉じ方の取り違えだった。合計のトルクで検算する方法

課題

空き時間で、小さなロボットアームを作る準備を進めている。部品集めの最初の段階は、ロボットアーム部品の調達で、12日前に固めたリストが注文直前に様変わりしていた話に書いた。

前回のMuJoCoでロボットアームが崩れ落ちた話では、部品を買う前に、物理シミュレータ（重さや力を計算して物の動きを再現するソフト）の中でアームを組み、腕の長さを決める作戦を書いた。

その後、アームの形そのものを変えた。関節ごとにモーターが付いた「直列アーム」をやめて、根元のモーター2個で腕を動かす「パラレルリンク」にしている。

そして、新しい形をシミュレータで試すと、また同じような結果が出た。腕を遠くへ伸ばすと垂れ下がり、根元のサーボが力の上限に張り付く。どう見ても「このサーボでは、そこまで届かない」という答え。

でも、今回もサーボの力不足ではなかった。シミュレータの中で、リンク（棒をつないだ仕組み）が設計とは違う形に組み変わっていた。

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

• シミュレータが「設計の限界」に見える答えを出したとき、それが本当に限界なのか、シミュレータの中で何かがずれているのかを、中の仕組みに左右されない量で切り分けられる
• 2つの計算方法が食い違ったときに、結論を保留する理由と、そのあとの確かめ方が分かる
• 原因を直したあと、同じずれを見逃さないテストを置き、そのテストが本当にずれを捕まえるかまで確かめられる

先に結論

• 新しいアームをシミュレータで遠くへ伸ばすと、腕が垂れ、肩のサーボが上限に張り付いた。見た目は「このサーボでは届かない」という設計の結論そのものだった
• 最初にこの食い違いが出たとき（10月14日）、AIは手計算とシミュレータのどちらも採らず、「どちらもまだ確かめられていない」と記録して、結論を出さなかった
• 切り分けに効いたのは、根元の2個のサーボが同じ軸を回るという点。この場合、2個のトルク（回す力）の合計は、中でどう分担しても、外からかかる力のモーメントと等しくなる。重さだけなら合計は0.063 N·mで、サーボ1個の上限0.176 N·mにも収まる。つまり「サーボが弱い」では説明できなかった
• 決め手は、受け身の関節（モーターの付いていない肘）の角度。設計どおりなら-19.7度のところが、+35.3度だった。リンクが、平行四辺形とは別の「交差した形」で閉じていた
• 原因は、シミュレータがリンクのつなぎ目を少し伸びる柔らかい拘束として扱っていたこと。その柔らかさの設定（solref）を硬くすると、手計算と3つの量で一致した
• 直したあと、つなぎ目の設定を元に戻すと11件中10件が落ちるテストを残した
• 実物のアームはまだ組んでいない。ここまでは、すべて画面の中と計算の話になる

この記事でわかること

• シミュレータの「できない」を、内部の分担に関係なく決まる量で検算するやり方
• 合計が合っても安心できない理由と、内訳を確かめる方法
• 物理シミュレータで閉じたリンク（ループのある機構）を扱うときの落とし穴と、テストでの固定の仕方

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

「シミュレータが『届かない』と言っているなら、それが答えでは？」

前回と同じく、そう読める結果だった。しかも今回は、シミュレータで確かめたかった問いが、まさに「このサーボで、作業する範囲の奥まで届くか」。答えの形をした症状ほど疑いにくいのでは、と思う。だから、シミュレータを使わずに出せる量と突き合わせる意味がある。

前回からの変更: 直列アームをやめて、パラレルリンクにした

前回の記事の時点では、関節ごとにサーボが付いた直列アームで、腕の長さは仮の値（肩80・肘80・手首40mm）だった。

10月14日に、アームで操作する範囲を自分で決めた。机に置いたスマートフォンの画面をタップすることと、キーボードのキーを押すこと。範囲は土台から左右に150mm、奥行き300mm。いちばん奥の角までは335mmある。

ここで直列アームが成り立たないと分かった。効いたのは重さより、キーを押す力のほう。

キーを押す力は約0.52N。腕の先で押すと、その反動が「押す力×根元からの距離」の回す力として肩にかかる。335mm先で押すと、それだけで0.17 N·m。SG90（工作でよく使われる小型のサーボ）が出せる最大の力は0.176 N·mなので、腕の重さを足す前に、ほぼ使い切ってしまう。

記録の表では、前回の仮の長さ（届く距離240mm）でも、キーを押すと肩に0.183 N·mかかり、上限を超える。キーを押せる最大の距離は、SG90で228mm。一回り強いサーボでも276mmで、335mmには届かない。画面のタップは軽く触れるだけ（約0.05N）なので、どの長さでも余裕があった。

この結論は、シミュレータに頼っていない。押す力の分は「力×距離」の掛け算で、重さの分はシミュレータと手計算の両方で出して、値が合っていた。

AIは5つの案（範囲を狭める、タップだけで始める、肩だけ強いサーボにする、パラレルリンクにする、キーボードを手前に置く）を出し、自分がパラレルリンクを選んだ。

パラレルリンクは、棒4本で平行四辺形を作り、根元のモーターの回転を、ロッド（連結棒）で先の腕へ伝える仕組み。肘を動かすサーボも根元に置けるので、こうなる。

• 腕が運ぶ重さが減る（肘や手首にサーボが無い）
• キーを押した反動を、根元の2個のサーボで分け合える

選んだときには、3つ目の理由として「平行四辺形がペンの向きを一定に保つ」も挙げていた。でも、これは10月20日に、今の作りでは成り立たないと分かって取り消している。ペンの傾きは、腕の長さと作業する範囲の決め方で抑えることにした。

寸法は、この記事の出来事のあと、10月20日に確定した。作業する範囲を土台から200〜320mmの帯に決め直して、上腕190mm・前腕190mm・クランク（根元の短い腕）50mm・ペン45mm、支点の高さは作業面から203mm。

前回の記事で仮の値として書いた直列アームの長さは、もう使っていない。前回は「シミュレータで決めた長さが、実物でも垂れずに支えられるか」を、これから確かめる仮説として置いていた。その前提だった直列アーム自体をやめたことになる。そして、実物のアームはまだ組んでいないので、パラレルリンクについても実物では何も確かめていない。

症状: 「このサーボでは届かない」にしか見えない結果

10月14日: 合計は合うのに、内訳がまったく合わない

AIは、パラレルリンクをシミュレータで組んだ。当時の仮の長さは上腕170mm・前腕170mm・クランク35mm。

閉じたループ（棒の輪）は、ロボットの形を書く共通の書式（URDF）では表せない。そこで、輪の部分を除いた形を書式どおりに書き、「この2点をつなぐ」という約束だけを別に持たせて、シミュレータ側で輪を閉じる作りにしている。

結果はこう食い違った。

何を比べたか	手計算	シミュレータ
キーを押した力の、2個のサーボの分担	ほぼ50:50（各0.087 N·m）	94:6

一方で、押す力の分の2個の合計は、0.173と0.174 N·mでほぼ一致していた。

手計算どおりなら、肩は押す分0.087に重さの分0.068を足して0.155 N·mで、上限0.176に収まる。シミュレータどおりなら、肩1個に押す力のほとんどが乗って、成り立たない。

AIは、ここで3つの欠陥を見つけて直している。ロッドと上腕を同じ平面に置いていて、棒どうしがぶつかっていた。ペンが上を向いていた。押す力をかけるときに、存在しない回す力を足していた。

それでも合わなかった。ロッドが引っぱる力はシミュレータで3.06N、手計算で7.75N。腕の先も、重さだけの状態で、指示した335mmに対して289mmまでしか届いていなかった。

AIは、どちらも採らなかった

ここで記録は、こうなっている。

• 合計が合ったことは、何も証明しない。釣り合いが取れていれば、合計は中の経路によらず決まるので、内訳が正しいことの証拠にならない
• 手計算もシミュレータも、どちらも別の方法で確かめられていない
• だから、片方を採って報告しない。次は、ロッドの力が手計算と合うことを先に確かめてから、分担を読む

その日、AIは「確かめずに言い切ってしまった」例をすでに7件記録していた。その直後の判断として、数字を結論にしなかったことになる。

もし手計算だけを採っていれば「成り立つ」、シミュレータだけを採っていれば「成り立たない」。どちらにしても、確かめていない数字で設計が決まる。記録には、この保留が誤った設計変更を防いだ、とあとから書かれている。

10月20日: 画面で見えるようにしたら、腕が机より下へ落ちた

10月20日、自分から「シミュレータを自分でも見やすく、操作しやすい画面にしてほしい」と頼んだ。AIが3つの案を出し、その中から自分が、ブラウザで寸法を動かせる2Dの画面を選んだ。

作る途中で、別の問題が2つ見つかった。

• 開発用のパソコンから、シミュレータ（MuJoCo）とテストの道具が丸ごと消えていて、何も実行できなかった。入れ直している
• シミュレータが初期設定で、固定でつないだ部品を親の部品へ合体させるため、ペンの部品が消えていた。押す力をかける場所が無くなっていたので、合体させない設定にした

動くようになると、結果はむしろ悪く見えた。指示した335mmに対して、手首は270mm。高さはマイナス97mmで、机より下まで落ちていた（ぶつかる判定は切ってあるので、机を突き抜ける）。合計のトルクも、手計算0.240に対してシミュレータ0.209で合わない。

画面には、肩のサーボが上限に張り付いた姿。「SG90では335mmに届かない」としか読めない。

確かめ方1: 中の分担に関係なく決まる量で、まず「設計の限界」かを切り分ける

ここで効いたのが、10月20日の画面づくりのときにAIが入れていた判定のやり方だった。

パラレルリンクでは、肩のサーボと肘を動かすサーボが、どちらも土台の同じ軸のまわりを回る。腕全体が土台につながっているのは、この2か所だけ。だから、止まっているとき、2個のトルクの合計は、「腕の重さ×距離」と「押す力×距離」の合計と必ず等しくなる。中でロッドがどれだけ受け持っても、合計は変わらない。

物理でいう「力のモーメントの釣り合い」で、時間を進めて動きを追う計算は要らない。三角関数と重さの足し算だけで出せる。

この性質を使うと、こう言える。

• 合計がサーボ1個の上限（0.176 N·m）以内なら、どう分担しても支えられる
• 合計がサーボ2個分（0.352 N·m）を超えるなら、どう分担しても無理
• その間なら、分担しだい。ここだけは、シミュレータで内訳を確かめる必要がある

AIは、まず「サーボが弱い」という説明を外した。

重さだけでも腕は崩れた。でも、そのときの合計は0.063 N·mで、サーボ1個の上限0.176にも十分収まる。しかも、サーボが指示された角度へ戻ろうとする強さ（ゲイン）の設定から計算すると、0.063 N·mを出すのに必要なずれは0.36度。観測された46mmの垂れは、とても説明できない。

この時点で「力不足」は消える。残るのは「シミュレータの中で、何かが設計と違っている」。

合計が合っても、安心はできない

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

「合計が手計算と合えば、シミュレータは正しいと言っていいのでは？」

言えない。10月14日がまさにそうで、押す力の分の合計は0.173と0.174でほぼ一致していたのに、分担は94:6で、手計算の約50:50とまったく違った。

合計は、中の経路に依存しない量。だから、合わなければ必ずどこかがおかしいけど、合っても内訳が正しい保証にはならない。切り分けの最初の一手として強い一方で、それだけで「正しい」とは言えない、という使い方になる。

確かめ方2: 内訳は、受け身の関節とロッドで見る

AIが次に疑ったのは、輪を閉じるつなぎ目の伸びだった。測ると1.16mm。これだけで46mmの垂れは説明できず、この仮説は外れている。

決め手になったのは、関節ごとの角度の内訳。モーターの付いていない肘（受け身の関節）が+35.3度だった。平行四辺形なら-19.7度のはずで、符号ごと違う。

輪は閉じているのに、平行四辺形ではない別の形で閉じていた。

上の図は、記録の姿勢と寸法をもとに、2通りの閉じ方を重ねて描いたもの。上腕とクランクの角度は同じでも、ロッドの先がつながる点Rは2か所に取れる。緑が設計どおりの平行四辺形、赤が交差した四角形で、赤のほうでは前腕がクランクに付いてこなくなる。

原因: 柔らかいつなぎ目が、別の閉じ方への乗り換えを許した

閉じ方が2通りある理由

このアームでは、肩の軸とクランクの軸が、土台の同じ点にある。横から見ると重なっている。

そうすると、「土台から出た2本の鎖（クランク→ロッド、上腕→前腕の根元側）が、同じ点Rで出会う」という条件に、答えが2つできる。1つは平行四辺形、もう1つは交差した形。

記録では、こうした2つの答えのそれぞれを「分岐」と呼んでいる。同じ部品、同じ駆動の角度のまま、形だけが2通りある、というイメージ。

しかも、2つの分岐は、棒が一直線に並んだ姿勢で出会う。シミュレーションの起動時の姿勢（全部の関節が0度）が、ちょうどそこだった。肩・クランクの先・肘・先端が同じ高さで一列に並ぶことを、AIは数値で確かめている。

つなぎ目は「伸びる」

MuJoCoは、輪を閉じるつなぎ目を、ぴったり固定するのではなく、とても硬いバネのような柔らかい拘束として扱う。solref（ソルリフ）は、その柔らかさを決める設定の1つで、ずれをどれくらいの時間で戻すか（時定数）を表す。

初期設定の0.02秒だと、荷重がかかったときにつなぎ目が約1.2mm伸びる。普段なら気にならない長さでも、分岐の境目にいる機構では、この遊びで向こう側へ乗り換えられてしまう。

平行四辺形の姿勢から始めても、150ミリ秒あたりで肘の角度が0度（境目）を横切り、+35度側へ落ちる様子が記録に残っている。サーボが動かしている関節は、ほとんど動いていなかった。

その結果、前腕がクランクに付いてこなくなり、ロッドは本来の5分の1しか力を受け持たず、肩がサーボの上限に張り付いた。10月14日に読んだ94:6という分担も、この状態の数字だった。

直し方と、どこまで硬くするか

AIは、時定数をMuJoCoで設定できる下限（計算の間隔の2倍、0.001秒）にした。どれくらい硬くする必要があるかも測っている。

つなぎ目の時定数	肘の角度（目標は-19.68度）
0.02秒（初期設定）	崩れる
0.01秒	-15.7度
0.005秒	-18.3度
0.002秒	-19.5度
0.001秒（下限）	-19.69度

0.002秒でも実用上は足りるけど、下限に置いている。直したあとは、平行四辺形の姿勢を最初に与えなくても、平行四辺形の側に収まるようになった。

直ったと言える根拠: シミュレータを使わずに出せる量と一致した

比べたもの	シミュレータ	手計算
指示した距離335mmに対する手首の位置	335.1mm	335.0mm
合計トルク（重さだけ）	0.0634 N·m	0.0634 N·m
合計トルク（画面タップ0.05N）	0.0803 N·m	0.0804 N·m
合計トルク（キー押し0.52N）	0.2394 N·m	0.2396 N·m
ロッドが引っぱる力（重さだけ）	2.04N	1.96N
ロッドが引っぱる力（キー押し）	9.70N	9.52N

上腕・前腕・クランクの長さと距離を変えた6通りでも一致を確かめている。

ポイントは、手計算の側がどれも、時間を進めるシミュレーションを使わずに出せる量だということ。シミュレータが自分自身と合っているだけ、にはならない。

ただし、重さの見積もりは、シミュレータに入れたものと同じ式を使っている。記録にも「別の前提で作った2つ目の見積もりではない」とある。重さの見積もりそのものが実物とずれていれば、両方そろってずれる。ここは実物で確かめるしかない。

この結果で、パラレルリンクは当時の要件を満たすと分かった。335mm先でキーを押したとき、肩0.123 N·m、肘を動かすサーボ0.116 N·m（約52:48）。どちらもSG90の上限0.176に収まる。直列アームでは肩1個に乗って成り立たなかったものが、2個に分かれて成り立った、という形。

ただ、余裕を決めているのは、ロッドが前腕を押す角度（伝達角）だった。腕を伸ばすほどこの角度は閉じて、伸びきるとゼロになる。当時の170/170では、伸びきりの340mmに対して335mmは5mm手前で、角度は19.7度しか残っていなかった。だから長さは、使う距離が伸びきりから十分離れるように選ぶ、という結論になり、確定した190/190では、伸びきり380mmに対して作業する範囲の奥が320mmになっている。

直したあとに置いたもの: 設定を戻すと落ちるテスト

AIは、シミュレータ用のテストを11件追加した。「動くかどうか」ではなく、信用していいシミュレータかどうかを分ける一致を固定している。

テストで見ていること	内容
手首の位置	指示した距離に、重さだけでもキーを押しても1mm以内で届いている
合計トルク	2個のトルクの合計が、手計算のモーメントと一致する（重さだけ・キー押し）
ロッドが引っぱる力	前腕の釣り合いから出した手計算と5%以内で一致する（重さだけ・キー押し）
平行四辺形の形	受け身の肘の角度が、設計どおりの値から0.5度以内
輪が閉じている	つなぎ目のすき間が0.2mm未満
その他	ペンの部品が消えていない、キーの反動が片方のサーボに偏らない、上限に張り付くサーボが無い

そして、AIはこのテストが本当にこの欠陥を捕まえるかを確かめている。つなぎ目の設定を元の値（計算の間隔の40倍＝0.02秒）に戻すと、11件中10件が落ち、戻すと全件通った。

テストを書いただけでは、「このテストは、壊れたときにちゃんと落ちるのか」は分からない。原因の設定をわざと戻して、落ちることを見ておくと、テストの中身まで信用できるようになる。

前回の記事との違い

記録には、これを前回のarmature（サーボの中の回りにくさ）の件と同じ型の誤りの2度目だと書いてある。どちらも、物理シミュレータの初期設定が、この小さくて軽い機構には合っていなかった。どちらも「サーボが弱い」ように見えた。

違いは、止め方にある。

• 前回は、止まった姿勢で必要な力を別の計算で出し、上限の約3分の1と分かったことで止まった。直したあとに「垂れるはずのアーム」のテストを置いた
• 今回は、2つの計算が食い違った時点で結論を保留し、中の分担に関係なく決まる合計で「力不足」を外し、受け身の関節の角度で内訳のずれを見つけた。テストは、設定を戻すと落ちることまで確かめた

記録の結びには、「この種の検算を、数値を読む前に用意しておく」という進め方を残す、とある。初期設定のまま使っているほかの値（ぶつかる判定、計算の反復回数、拘束の柔らかさに関わるもう1つの設定）も、同じ理由で疑う対象として挙げられている。

AIと物理シミュレータで機構を試すときの確かめ方

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

1. シミュレータの答えが「確かめたかった問いの答え」の形をしていたら、まず疑う。 「届かない」「支えられない」は、設定のずれでも同じ見た目になる
2. 数値を読む前に、中の仕組みに左右されない量を用意しておく。 今回なら、同じ軸を回るサーボのトルクの合計＝外からかかる力のモーメント。合計がサーボ1個の上限以内なら「力不足」は外せる
3. 合計が合っても、内訳は別に確かめる。 受け身の関節の角度、ロッドの力など、内訳を表す量を手計算と比べる。合計だけで「正しい」と言わない
4. 2つの方法が食い違ったら、どちらも採らずに結論を保留する。 片方を採ると、確かめていない数字で設計が決まる
5. 閉じたリンクを扱うときは、輪の閉じ方が設計どおりかを見る。 起動時に棒が一直線に並ぶ姿勢は、2通りの閉じ方の境目になりやすい。つなぎ目の柔らかさの設定も確認する
6. 直したら、原因の設定を戻すと落ちるテストを置き、実際に戻して落ちるのを見る

AIに頼むなら、たとえば「シミュレーションの数字を結論にする前に、中の分担に関係なく決まる量（合計のトルクなど）を手計算と比べて。食い違ったら、どちらかを採らずに先に教えて」と一言添えておくと、2と4を飛ばしにくくなると思う。

まだ確かめていないこと

• 実物のアームはまだ組んでいない。記録の時点（10月20日）では、骨組みの部品もまだ注文していない
• シミュレータは、歯車のガタ、サーボの個体差、軸まわりの摩擦、部材のたわみを再現しない。確定した寸法も、実物で確かめる前の仮説
• 重さの見積もりは、シミュレータと手計算で同じ式を使っている。実物の重さは量っていない
• ペンが消えていた件は、シミュレータの版を上げたことで挙動が変わった可能性が高いと記録されているけど、前の版を入れ直して確かめてはいない
• 初期設定のまま使っているほかの値（ぶつかる判定、計算の反復回数など）が、この機構に合っているかは確かめていない
• 前回の記事で置いた「シミュレータで決めた長さは、実物でも垂れずに支えられる」という仮説は、直列アームをやめたことで前提が変わった。確かめるのは、パラレルリンクを組んでからになる

こんな人に向いている

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

特に、平行リンクやロッドでつないだ腕のように、輪になった機構をシミュレータで扱っている人。AIが「シミュレーションしたら、このモーターでは無理でした」と言ってきたとき、それを部品の限界と受け取っていいかを判断する材料になるはず。

まとめ

パラレルリンクのアームをシミュレータで伸ばすと、肩のサーボが上限に張り付き、腕が垂れた。「このサーボでは届かない」という設計の結論にしか見えなかった。

でも、同じ軸を回る2個のサーボの合計は、重さだけなら1個の上限にも収まっていた。力不足ではない。受け身の肘の角度を見ると、リンクが平行四辺形ではなく交差した形で閉じていた。柔らかいつなぎ目が、起動時の一直線の姿勢から、別の閉じ方への乗り換えを許していた。

最初に手計算と食い違ったとき、どちらの数字も結論にしなかったことが、誤った設計変更を止めている。

項目	内容
結論	「届かない」は設計の限界ではなく、リンクが別の閉じ方へ乗り換えていたため。つなぎ目の設定を硬くすると、手首の位置・合計トルク・ロッドの力が手計算と一致し、パラレルリンクは当時の要件を満たした
教訓	数値を読む前に、中の分担に関係なく決まる量を用意しておく。合計が合っても内訳は別に確かめ、2つの方法が食い違ったら結論を保留する
対象読者	個人でロボットやシミュレーションをAIと試している人

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

• シミュレータが「できない」と言ったら、内部の分担に関係なく決まる量（同じ軸を回るモーターのトルクの合計など）を手計算と比べる
• 合計が1個分の上限に収まるなら、「部品が弱い」より先にシミュレータの中を疑う
• 合計が合っても安心せず、受け身の関節の角度やロッドの力で内訳を確かめる
• 輪になった機構では、設計どおりの閉じ方かどうかを、受け身の関節の角度で見る
• 2つの方法が食い違っている間は、どちらの数字も結論にしない
• 直したら、原因の設定を戻すと落ちるテストを置き、実際に落ちることを確かめる

次に読むなら

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

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

---

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