学習とデプロイ

Microduck のポリシーはロボット本体のリポジトリではなく、隣の microduck_rl で学習されます。MuJoCo Warp と PPO、ONNX に書き出し、ロボット上のランタイムが読み込みます。

全体の流れ

ポリシーは 50 Hz で学習され、オンボードの制御ループも 50 Hz です。これは偶然ではありません。両端の周波数が一致していることが、シミュレーションで学んだタイミングが実機でも成立する条件のひとつです。

最短ルート

CUDA GPU があれば、4 つのコマンドで一巡します。

git clone https://github.com/pollen-robotics/microduck_rl && cd microduck_rl

# 4096 環境で、使える歩容までおよそ 1〜2 時間
uv run train Mjlab-Velocity-Flat-MicroDuck --env.scene.num-envs 4096

uv run scripts/export.py Mjlab-Velocity-Flat-MicroDuck --wandb-run-path <...>

# ロボット無しで、書き出したポリシーを CPU 版 MuJoCo で操作する
uv run scripts/infer_policy.py --walking output.onnx

GPU が無い場合は、任意の train コマンドに --hf-jobs を付けると Hugging Face Jobs 上で実行されます。

実機に載せるのにリリースは要らない

思われているより簡単です。.onnx をボードに置き、設定ファイルから指すだけです。

[policy]
walk = "/home/radxa/my_walking.onnx"

sudo systemctl restart robotd

このパスはシステム更新を越えて残ります。 リリースが置き換えるのは同梱のバイナリとポリシーであって、別の場所を指すこの設定ではありません。行を消せば元に戻ります。

読み込めなかったポリシーは unhealthy を報告し、robotctl health と robotctl monitor の下端の両方が理由を示します。

sim2real を決めるもの

シミュレーションでは綺麗に歩くのに実機で転ぶ、というのは事故ではなく通常の結果です。microduck_rl はそのレシピを誰かの経験ではなくリポジトリに符号化しています。4 つあります。

1. アクチュエータを理想化できない。 Dynamixel XL330 に対する BAM の M6 モデル（電圧制御則、逆起電力、クーロン/ストライベック/負荷依存摩擦）。サーボを理想トルク源として扱うと、学習した歩容は実際には得られない応答に依存します。
2. ランダム化するのは物理パラメータであって観測ノイズではない。 バッテリー電圧、負荷時の電圧降下、指令遅延、摩擦の大きさ。観測にガウスノイズを足すのとは別物です。
3. バックラッシュを正しい側にモデル化する。 実機のエンコーダは遊びの出力側にあるため、シミュレーションの観測もそれを通して読む必要があります。入力側にモデル化すると、ポリシーは関節位置を正確に知っていると信じ込みます。この誤差は関節が反転するまで表に出ません。
4. 61 次元の共有観測契約。 これがあるから、歩行・復帰・技のポリシーが任意の瞬間にロボットを引き継げます。

学習できるタスク

主タスクは Mjlab-Velocity-Flat-MicroDuck。ほかに転倒復帰、立ち上がり、着座、拾い上げ、ボールキック、前転、そして受動輪のためのローラータスク群があります。

主タスクにはそれぞれ、各関節に ±1° の歯車遊びを入れて学習する Backlash の双子があります。

次に読む

• 学習環境を整える — 動作要件、4 つのコマンド、GPU が無い場合
• 学習タスク一覧 — 各タスクの id・地形・用途
• sim2real のレシピ — 実機に移せるかどうかを決める 4 つのこと