二足歩行ロボットを作る(1)｜まずはシミュレーションでバランス制御を作ってみた

なぜ二足歩行ロボットを作るのか

ロボットを作りたい、と思ったとき、最初のゴールは正直「趣味として完成品を手元に置きたい」くらいの軽い動機でした。ただ、せっかく時間をかけるなら、その先にも技術を応用していける方向性が見える形にしたいと思い、二足歩行という難易度の高いテーマを選びました。

二足歩行ロボットのバランス制御は、センサから得た姿勢・接地力の情報をもとに、関節をリアルタイムで制御し続けるという、応用範囲の広い技術的な挑戦です。遠回りに見えるかもしれませんが、実は一番土台になるところから手をつけている感覚があります。

この記事はシリーズ化する予定で、段階を踏みながら実機化まで進めていく過程をそのまま記録していきます。同じようにロボット作りに興味がある方は、ぜひ一緒に進捗を追ってみてください。

中の人

ロボット作りって浪漫だよね。私もこのシリーズ、楽しみに見守ってるよ!

実機ではなくシミュレーションから始めた理由

いきなりサーボを買って組み立てることもできましたが、今回は最初にシミュレーション上でバランス制御のアルゴリズムを作り込むことにしました。理由はシンプルで、実機だと試行錯誤のたびにサーボが壊れる・時間がかかる・電源やノイズに邪魔されるのに対して、シミュレーションなら失敗し放題でイテレーションが速いからです。同じようにロボット製作を検討している方には、まずシミュレーションから始めるのもおすすめです。制御ロジックが固まってから実機に移植する方が、結果的に近道になります。

つまずき1: PyBulletが入らず、MuJoCoに乗り換えた

物理シミュレータの定番としてまずPyBulletを試しましたが、Windows + Python 3.11の組み合わせではビルド済みのwheelが配布されておらず、pip installがソースビルドに突入していきなり止まりました。

error: Microsoft Visual C++ 14.0 or greater is required.
Get it with "Microsoft C++ Build Tools":

Microsoft C++ Build Tools - Visual Studio
visualstudio.microsoft.com

PyPIの配布履歴を調べたところ、PyBulletがWindows向けwheelを出していたのはPython 3.5世代までで、それ以降は基本的にソースビルド前提になっていました。Visual Studio Build Toolsを数GB分入れれば解決はしますが、そこまでの投資は今回のスコープでは過剰だと判断し、代わりにMuJoCoに乗り換えました。同じようにWindows環境でPyBulletのインストールに詰まっている方は、MuJoCoを試してみるのも一つの手だと思います。MuJoCoはPython 3.11向けのWindows wheelが公式に配布されていて、pip install mujocoだけですぐ動きました。

中の人

あるある、環境構築でつまずくのって実機の前からもう始まってるんだね(笑)。動くものを優先する判断、いいと思うよ。

10自由度のモデルを作る

片脚あたり5自由度(股関節ピッチ・股関節ロール・膝ピッチ・足首ピッチ・足首ロール)、両脚で合計10自由度のモデルをMuJoCoのMJCF形式で組みました。全体重量は2.6kgの小型サイズです。骨盤にはフリージョイント(6自由度)を持たせて、外力を受けたときに実際に倒れられるようにしています。

• 骨盤: IMU相当のセンサ(姿勢・角速度・加速度)を搭載
• 各足裏: 接地力センサ(左右独立)
• 各関節: 位置制御アクチュエータ(トルク上限つき)

モデルを組んだ直後は、直立姿勢のはずが足裏が地面から6cm浮いていました。骨盤の初期高さの計算を間違えていたのが原因で、キネマティクスを1段ずつ手計算し直して修正しました。地味ですが、シミュレーションを作る作業の9割はこういう帳尻合わせだと思います。同じように地道な検証作業に付き合っている方も、きっと多いのではないでしょうか。

つまずき2: 押すとむしろ転ぶコントローラができた

バランス制御は、倒立振子モデルの発想で「体が傾いたら(pitch/roll)、その傾きと角速度に比例して関節を補正する」という素直なPD制御から組みました。

ankle_pitch_cmd = -(kp * pitch + kd * pitch_rate)

直感的には「傾いた方向と逆に補正すればいい」ので符号はマイナス、のはずでした。ところが実際にシミュレーションを回すと、押した瞬間から傾きがどんどん大きくなり、そのまま転倒しました。

これは頭の中で図を描いて考えるより、実際に符号を反転させて試した方が早いと判断し、押す→観察する、を関節ごとに繰り返して実測で符号を確定させました。同じように「理屈通りにいかない」ところで詰まっている方は、一度実測で当たりを取りにいくのも手だと思います。

# 検証コードの一部: 符号を反転させて収束するか比較
for k in targets:
    if 'ankle_pitch' in k:
        targets[k] = -targets[k]  # 反転して試す

結果、足首・股関節ともに「素直な直感とは逆の符号」が正解でした。理屈で導出するより、実測で当たりを取りにいく方が早い場面は実機開発でもよくありそうです。

中の人

理屈通りにいかないの、開発あるあるだよね。頭で考えるより実測で確かめる姿勢、見習いたいな。

つまずき3: 膝を曲げただけで立てなくなった

符号を直した後、安定性のマージンを稼ぐために膝を軽く曲げた(クラウチング)姿勢をデフォルトにしてみました。ところが外乱を与えていない、何もしていない状態でもじわじわ前傾していくことに気づきました。

膝を曲げることで重心が足首に対して前方にずれますが、今回のPD制御には定常偏差を消す積分項がないため、この分だけ傾いた姿勢がそのまま「安定した平衡点」になってしまっていました。転倒はしないものの、外乱に対する余力をそのぶん失っていたことになります。膝を伸ばした状態(曲げ角0)に戻すと、この定常偏差はほぼ消えました。

中の人

工夫したつもりが逆効果になるの、ちょっと切ないね…。でもちゃんと原因まで突き止められてるのがすごいよ。

結果: どのくらいの外乱まで耐えられるか

膝を伸ばした状態を基準に、骨盤に一定時間(0.1秒間)水平方向の力を加えて、両足を接地させたまま姿勢を回復できる限界を調べました。

両足を動かさない(足を踏み出さない)前提の制御としては、これが物理的な限界に近いところです。人間も、軽く押されたくらいなら足首とわずかな体幹の動きだけで耐えますが、大きく押されたら一歩踏み出してバランスを取り直します。今回のロボットもちょうどそこに来ています。