ヒューマノイドロボットにオクラ収穫をやらせて分かった「フィジカルAIの凄さと課題」

はじめに

こんにちは、Orbohの上田です。Orbohはヒューマノイド版FDE（Forward Deployed Engineer）を行う会社です。エンジニアが現場に入り込み、ロボットを実装しています。

最近は自分たちの家を持たず、キャラバン的にお客さんがいる場所へ移動し、ロボットを実装して次の場所へ行くという生活をしています（笑）。

さて、このnoteでは、6月〜9月にトヨタ車体研究所と共同で取り組んだ「ヒューマノイドロボットによるオクラ収穫プロジェクト」を経て、設計や開発に関する気づき、フィジカルAIの凄さと課題をまとめて公開します。「農業×ヒューマノイドロボット」という試みは世界的に見ても珍しく、先行文献がほとんどない中で試行錯誤を続けた結果なので、エンジニア、起業家、投資家などフィジカルAIに関わるすべての人に有用な情報をお伝えできると思います。また、屋外特有の難しさもあります。いいなと思った方はいいねを押していただけると嬉しいです！

プロジェクトの結果としては屋外でオクラを掴みにいくことに成功し、あとはエンドエフェクタだけしっかり作り込めばOKという状態までできました！惜しくも時間切れとなり、カッターを作り込んで収穫することは叶いませんでしたがプロジェクトを全力でやった過程で様々なことを学べたので価値は大きかったと考えています。

ランダムに生えてるオクラに対して、ロボットが対応し、ちゃんと掴みに行けるってすごいことだと思うし、屋外という難しい環境で作動したことがエンジニアとして嬉しかった。フィジカルAIの社会実装は今からでもできると実感したし、社会の役に立てると思いました。屋内の成功率は16/20です。開発日数は、70日です。約40日程度をUMIとDiffusion policy, Flow matching に費やしました。

プロジェクトの概要

プロジェクトの目標はUnitree G1 （ヒューマノイドロボット）を使って、農園のオクラを収穫できるようにすること。具体的な収穫プロセスは、オクラの 検出 → 接近 → 切断把持 → 籠収納 → 次へ移動 です。下記のXの投稿の様にオクラを探しながら、オクラ畑に沿って横移動しています。このプロジェクトでは開発時間も短いので、オクラを2個取れたら成功としています。

本PoCの本質的な狙いは、ここで確立した開発手法を後続PoC(工場や建築現場など)にそのまま転用できる、ソフトウェア基盤をつくることにあります。

今回開発したプログラムはすべてオープンソースとして公開します。ぜひご活用ください。Claudeに読み込ませて内容を理解するのも面白いと思います。

システム設計

システムをハードウェアとソフトウェアに分けて、簡単に説明します。

ハードウェア

G1の胸部にZED-Mステレオカメラを固定し、オクラの検出を行います。ZED-MはRGBの情報に加えて、距離まで取得することができるステレオカメラです。これでオクラまでの距離を測定できます。

右手にはDex1-1ハンドと、カッターを取り付けるためのアタッチメントを装着。左腕にはオクラ収穫用のカゴを固定しています。

背中には100円ショップの金網で作ったカゴを取り付け、その中にJetson Orin 64GBとAnkerのモバイルバッテリーを収納しています。

ソフトウェア

中心となるソフトウェアは Dimensional OS で、収穫フローを下記の画像の様に LangGraph を用いて定義しています。

収穫1サイクルの処理は以下の流れです。

①移動：下半身はUnitreeの歩行ポリシーに目標移動速度を与える LocoClient で移動する（ラジコンと同じ）

②検出：オクラ画像でファインチューニングしたYOLOを用いて、2D画像からオクラを検出／セグメントする

③3D化：検出したオクラを ZED-M の NEURAL_LIGHT で3D点群として取得し、オクラの重心座標を算出する

④座標変換：ZED-Mのカメラ座標から、右腕基準の座標へ変換する

⑤接近：逆運動学IK（Inverse Kinematics）でDex1-1ハンドをオクラの重心座標まで伸ばす。逆運動学とは、ハンドをある座標まで動かしたい時にハンドの目標座標から、腕の各関節をどの様に動かせばいいのか計算することです。matlabの記事の方が正確に説明しているのでこちらを参照ください

https://jp.mathworks.com/discovery/inverse-kinematics.html

下記の動画は、逆運動学（IK）だけでオクラまで手を伸ばした時の動画です。スムーズに動くので一度ご覧ください。

⑥位置合わせ：オクラ農園は風や日光が強く、葉でオクラが見えないなど様々な対応が必要になる。そこでIKでハンドがオクラ近くまで到達した後、Diffusion Policyを用いて、ハンド先のカッターがオクラの茎を挟める位置まで移動させる。Diffusion Policyは、ロボットの今の関節状態とカメラ情報から次のロボットの動きを出力するAIの一種です。これについては、別途noteを書いて説明させていただく予定です。一旦、AIでオクラを掴めるようになるんだとイメージしていただければ大丈夫です。

⑦切断把持：ハンドの開度を100%→0%に変えるプログラムを実行し、オクラの切断と把持を行う。切断までを上述したDiffusion Policy で行わなかったのは、切断データを収集する必要がある＝オクラを少なくとも500個以上は収穫しないといけないということです。せっかくなら一つのオクラから何個も収穫データが取れた方がいいので、分ける設計をしています。

⑧収納：オクラをカゴに入れるモーションを実行し、次のオクラ収穫へ向かう

このループを繰り返します。

開発プロセス

上記ではロボット自体の設計を説明しました。ここからは、「どうやってにその設計を実現するのか？」という開発プロセスについて説明させていただきます。

① システム設計

• 周囲のオープンソースを調べる

• TTP（徹底的にパクる先）文献のリサーチ
  今回参考にしたのは、UMIを屋外環境様に改造し、ペッパーをロボットアームで収穫する論文です。
  https://arxiv.org/pdf/2411.09929

② オクラを認識できるようにする

• オクラの写真をひたすら集める。今回はオクラ農園でスマホで写真を300枚程度撮影しています。

• オクラの写真を人力でラベル付けする。ラベル付にはRoboflowというツールが便利です。web上でできるので初心者にも簡単です。とても時間がかかる作業ですが、人が一番正確にオクラをラベル付けできます。

• ラベル付したオクラ写真をSAM2を使ってセグメントする。SAM3が最新でSAM3なら人力のラベリングもいらないそうですが、ライセンスをMetaからもらう必要があります。SAM2ならすぐに使えるので、今回はラベル付けを人力で行い、SAM2によるセグメンテーションを自動で行いました。精度はめちゃめちゃいいです。

• セグメント済みの画像を使ってyoloをフィアンチューニングします。今回ファインチューニングした時に使用したデータセットは

③ オクラ切断点までハンド先端のカッターを接近できるようにする。

データ収集

フィジカルAIでオクラ切断点までハンド先端を動かすためには、人間がオクラ切断点までハンドを動かすデータを作り、AIに学習させる必要があります。AIの種類は、VLA, Diffusion Policy, ACT, Flow matchingなど様々な種類があります。データ取得方法は今回下記の2種類用いました。
・テレオペレーション
人間の関節情報をロボットの関節情報に変換して、ロボットに入力することで人間の動きをロボットがコピーできる技術のこと。下記の動画を見た方がわかりやすいのでぜひ見てください。VRゴーグル（Apple vision Pro）で人間の手の関節情報を取得しています。

ポリシーを実行したらこんなふうにAIが自動でオクラを掴んで、カゴに入れることができる！

・UMI(Universal Manipulation Interface)
ロボットを直接動かしてデータを取得するテレオペレーションは、正確なデータが取得できますが、ロボットを直接動かす必要があり、かなり時間がかかってしまいます。そこでロボットを動かさずに手軽にデータをとるためのツールがUMI(Universal Manipulation Interface)です。簡単に説明すると、GoProというカメラで「手元の映像」と「IMUデータ」から、手の軌道データを取得するツールです。

図のようにカメラで映像を撮るだけなので格段にデータ収集スピードが早い一方で、テレオペに比べて精度が落ちてしまうことが課題です。UMIについてはかなりノウハウが必要なので、このnoteでまとめると長くなり過ぎてしまいます。UMIに関しては別のnoteでまとめるので、こちらをご覧ください。

UMIで収集した画像とIMUデータから生成した軌道をHugging Faceにアップロードしているので確認してください。
⚠️オクラ農園ではなく、公園の草むらで取得したデータです。

UMIで収集したデータはこのようになっています。詳しくは別noteで。

Policyの学習

上記の手法でデータを集めたら、そのデータを使ってPolicyのトレーニングを行います。AWSのG5.4xlargeを使ってトレーニングしました。だいたい学習時間は12時間くらいです。学習の精度や進捗を確認するためにW&Bを使用するのがおすすめです。

同じデータからACT, VLA, Diffusion Policy, VLAなど様々なポリシーを学習させることができるので、AWSのインスタンスを複数用意して並列でポリシーを作って試すこともおすすめです。

④ シミュレーションで全体の収穫フローを検証する

周囲の環境を3Dスキャンする装置を使い、ロボットが動く正確な環境をシミュレーションの中に再現する。シミュレーション環境では、様々な設定を調整しながら現実に近い空間を作る必要があります。

今回は3Dスキャナーでラボ環境とオクラばたけの2環境をIsaac sim上に追加しました。下記のGoogle Driveからダウンロードできます。

今回は高価な3Dスキャナーが手元にあったので使用しましたが、スマホのカメラやロボットのカメラ・センサーを使って3Dデータを取得する方法もあるので試して見てください。

⑤ 実機で収穫フローのフルプロセスを検証する

シミュレーションで検証した内容を実機で試します。オクラの見え方や実機特有のノイズ、照明の違いなど様々なSim2Real Gapを確認します。室内の模擬環境でできても、本番のオクラ農園でできないなど様々な課題があるので試行錯誤が必要です。

以上で開発プロセスの説明は終了です。

開発で諦めたこと

• SLAMおよびコストマップを用いた周囲の環境認知と行動生成（オクラ畑を探索し、周囲の障害物を避けながらオクラまで移動し、オクラ苗を踏まないように移動する）

• 全てのプロセスをVLAもしくはDiffusion Policyで行うこと

• テレオペレーションだけで把持データを集めること

• ACTによるオクラ収穫

プロジェクトを踏まえて分かったこと

AIに任せる範囲を絞りきること

AIに任せる範囲を大きくすると不確実性が上がり、データ収集にかかる時間が格段に増加して開発コストが上がります。事前にロボットを動かすフローを決めきり、「本当にAIに任せないといけない範囲はどこか？」を絞ること。そうすることで、決まったことをやり切る古典制御と、様々なシチュエーションに対応できるフィジカルAIの適材適所を実現できます。

古典的な制御方法にはそれなりに良いところがあり、フィジカルAIの制御方法にも良いところがある。社会実装には、それぞれをうまく組み合わせるべきです。

「フィジカルAIのデータが足りない」とよく言いますが、そもそも全部の作業をAIでやる必要があるのか？古典制御でできることはそのままやればいいし、安全の観点からしても、出力が不確定なAIはすぐに社会実装できません。ベースは固定して、部分的にAIを使うことが、いち早くロボットを社会実装するために大事になります。

把持データの品質はしっかり管理すること

フィジカルAIモデルを作って実際に動かし、うまくいかなかったとき、「学習データの質が悪かったのか？」「データ数が少なかったのか？」「データ収集時とモデル実行時で環境の変化があったのか？」など、膨大な理由が思いつきます。ポリシーを実行した時に把持データの品質を振り返ることができなければデバックはできません。今までのロボット制御では、動き方が悪ければコードを見ればよかったです。しかし、フィジカルAIの難しさはコードを見てもロボットがどの様に動くか分からないことです。どのようなデータで学習させたのか？を確認することが唯一のデバック方法であり、データを管理できていないとどんなふうに動くか分からないロボットを作っていることになります。

上述しているAIに任せる範囲を絞るべきだと主張している理由の一つにデータ管理の難しさがあります。タスク工程が長くなればなるほど、確認する必要がある範囲が増加し、開発コストが指数関数的に大きくなります。今回のエピソードは2秒でした。仮に学習データが500エピソードだとして、合計1000秒のデータの品質を見れば大丈夫です。しかし、60秒のエピソードにすると30万秒のデータの品質を見る必要があります。しんどすぎる笑 VLAが進化してそんなにエピソード数も要らず、データの品質が悪くてもチューニングできるようになればいいですが、現実世界はカオスでなかなか実現は難しいです。

把持データは relative であること

データ表現の方式には大きく分けて3種類あります。absolute、relative、delta。relativeは「今の状態からどのように動かすか？」というデータであり、位置に依存しないため汎用性が上がります。

グリッパーカメラは魚眼であるほうがよい

魚眼のほうが周囲のコンテキストを集めやすくなります。最初は通常の単眼webcamを使用していましたが、その画像データは下記の写真のように大部分をオクラが占めてしまい、フィジカルAI（ACTやDiffusion）をトレーニングするのに十分なコンテキストを含むことができませんでした。オクラの占める面積をみてほしい！

開発体制・エンジニアリングについて

• AIによって一人ができることがたくさん増えているので、エンジニア一人ができる範囲は幅広い。タスクを振ったり管理する側は、常に5手先のタスクまで考えておく必要がある。結構大雑把にタスクを投げても、AIとディスカッションしながら担当者が動けるので、指針だけ考えればOK

• 外部の開発者と常に交流し、便利な技術のキャッチアップを行うことが大事。フィジカルAIの開発は「どのようなデータを集めたか？」、そしてトレーニング時のデータピラミッドと呼ばれるデータ種類の割合が大事になります。エンジニアの秘伝のタレ方式でノウハウの塊なので、他の開発者とノウハウを共有し合うことが大事です。

• Claude Codeが言っていることを自分の言葉で説明し、Claude Code以上の提案ができるエンジニアが今求められている。Claude Code以上のことが言えないエンジニアは必要ない。その人を採用するコストがあれば、もっとAIに課金できる。

• 中国語、英語、日本語が喋れるトリリンガルエンジニアになる必要がある。

開発環境の課題

フィジカルAIのコミュニティや、フィジカルAIのサポートレイヤー事業に取り組みたい起業家におすすめの情報です。

• ロボット開発ができるように、24時間・土日も含めて開いている場所が必要。人型ロボットは注目を集めるため、見物したい人が多く開発が中断される。コミュニティづくりと開発を止めない環境づくりが大事

• 3Dプリンター、電子部品、ネジやハンドが必要。すぐにプロトタイプを作ってテストをしたいのに、すぐに部品が手に入らない。

• 同じく社会実装をしている起業家やエンジニアが横にいて、すぐに相談ができることが大事。それぞれのエンジニアの経験の違いによって、新しい選択肢が生まれる

今後やりたいこと

下半身が車輪のセミヒューマノイド

2足歩行は、姿勢を安定させたり移動したりすることに多くの電力を消費します。Unitree G1は2時間でバッテリーが切れます（移動をたくさんさせると1時間以下で切れる）。また、何か物を掴むときに下半身が揺らぐとカメラもぶれ、把持成功の確率が大幅に下がってしまいます。

一方、下半身が車輪のセミヒューマノイドはバッテリーが6時間程度持ち、姿勢が安定するなどメリットが多い。現段階のエネルギー効率では，社会実装をするときに適切なのは2足歩行じゃないと思います。

エゴセントリックデータの活用

UMIを用いたデータ収集は、テレオペレーションによるデータ収集の3倍以上のスピードがあります。エゴセントリックデータは、それよりもさらに収集スピードが速く手軽で、データ数を稼ぎやすい。

UMI公式のページに載っている比較動画が分かりやすい。テレオペなら１時間に35データ、人がやるなら231データ、UMIなら111データを取得することができる。UMIはテレオペの約3倍の効率だが、エゴセントリックデータならテレオペの約7倍のデータ収集効率がある。

データピラミッドの研究

フィジカルAIのPolicyをトレーニングするためのデータには様々な種類がある。上記で述べた「エゴセントリックデータ」、「テレオペレーションデータ」、「エンドグリッパーだけの軌道データ（UMI）」に加え、インターネット上のデータをPolicyの学習に使用することができます。テレオペレーションデータが一番質がよく一番数を集めにくいので、UMIやエゴセントリックデータで事前学習させて、最後に質の高いテレオペデータでファインチューニングしていきます。これらのデータをどのように調合するかは実際にやって見ないと分からないので、社会実装をしながら最適なデータピラミットの設計を研究していきたいです。もしデータ調合に詳しい人がいたら、お話しさせてください！

VLAを独自開発する

今回はVLAを使用しませんでした。理由は全てローカルで推論させる必要があったことと、素早くロボットを動かして収穫する必要があったからです。既存のVLAはモデルが大きく一回の推論に時間がかかってしまいます。そこで、お客さんやタスクに特化したVLAをゼロから独自で開発することでモデルが巨大化せず汎用性のある動きができるVLAを作れると思います。VLAを独自で作るフレームワークは、TRIがオープンソースで出しているのでこちらを参照ください。このオープンソースはWoven by Toyotaの皆さんから教えていただきました。

Dimensional OS を用いたヒューマノイドロボットの全身制御

工場における車の組み立て作業は、車体の内部に入り込んで部品を取り付けるなど、ヒューマノイドがしゃがんだり狭い空間に入り込んだりする必要があり、全身制御が必要になります。Dimensional OSを使って周囲の環境を理解しながら、LangGraphで全身制御ができるようにしたいと思いました。こういった作業においては、ヒューマノイドである必要があると思っています。

UMIを使った双腕のタスク

今回、Unitree G1用にUMIを改造しました。原理を理解することで、OpenArmなどの双腕のアームに対してもUMIを適用できることが分かったので、工場の仕分け業務など移動を必要としないタスクについて、UMIを使ってデータを集めPolicyをトレーニングしていきます。

関わってくれた方々への感謝

様々な方にお力添えをいただきました．ありがとうございました．

• トヨタ車体研究所の皆様

• 鹿児島県農業開発支援センターの皆様

• 九工大インターン生

• 九工大 西野様

• Woven by Toyota

• Dimensional

• インドからプロジェクトを手伝いに来てくれたカビランさん

最後に「採用とロボット導入のPoC」

Orbohは今後もロボットの社会実装を進めて行きます。お客さんは日本が多いですが、技術のキャッチアップや共同開発で中国・アメリカを飛び回っています。現在、会社はファウンダー３人でやっていて、新しい仲間を探しています。採用基準は、「明日アメリカ行ってきてと言えば行けるフッカルさ」で、「自分の人生に飢えてるハングリー精神がある人」を仲間にしたいと考えています。興味のある方は、私のxかfacebookまでDMしてください！

また、このnoteを見てこの作業をフィジカルAIで自動化できるのかな？と思った方がいらっしゃれば私までご連絡ください。