Hugging Face Blogに載ってたStrands RobotsとLeRobotの記事、読んで「あ、これ自分が個人開発で感じてたやつだ」ってなった。
ロボット系のワークフローって、今まで本当にバラバラだった。デモ収録・学習・シミュレーション・ハードウェアへのデプロイ・複数台の調整、それぞれ別ツール・別スクリプトで「一応動くけど全然喋ってない」状態。自分はロボット触ってるわけじゃないけど、LLMとAPIサービスを組み合わせてる個人開発でも同じ地獄を何度も経験してる。ツール同士が疎結合で、全部つなぐ糊コードを自分が書かされる。
Strands Robots、設計の肝が2点あって、どっちも刺さった。
1つ目は、Robot(\"so100\") がデフォルトでMuJoCo backed simulationを返す点。mode=\"real\" に変えると実機になる。エージェントのコードは一切変えなくていい。
もう1つは、DatasetRecorderがsimとhardwareで共通フォーマット (LeRobotDataset) を書き出すこと。シミュレーションで収録したデータと、実機のSO-101で収録したデータが、ディスク上で同じフォーマットに並ぶ。
これを見たとき、ちょっと声が出た。5行で1ループ。しかもsimから実機への切り替えがキーワード1つ。
自分が最近やってる個人開発で、Claudeのstreaming APIと自前のキャッシュ層をつなぐとき、環境変数をゴリゴリ切り替えて「local/staging/prod」を分岐してた。似た思想を感じる。ただ自分の実装はまだ引数1つで済まなくて、ちょっとみっともない。
policy inferenceのinterfaceが共通化されてて、GR00TとLerobotLocalが同じIFで差し替えられる。MolmoAct2のcheckpointもLerobotLocalのpathを通る。
こういう「共通interfaceの裏に実装を隠す」設計、チームのコードレビューでも毎回話題になる。うちのチームは3人で、最近新しく入ったメンバーが実装をinterfaceに直してくれたPRがあって、あれが正直めちゃくちゃ良かった。abstract classに寄せるだけでtest書きやすさが全然違う。
複数ロボットの協調はZenohのpeer meshで実現してて、agentが全台にブロードキャストできる。Zenohって名前は知ってたけどroboticsで使われてるの初めて見た。
あと実際に動かすのにハードルが低い。記事曰く「No hardware, no GPU, no Hugging Face credentials needed for the default path」。これはとりあえず試してみるときに神。環境構築でハマってやる気無くなるやつを最初から排除してくれてる。
ロボット触る予定は今のところないけど、Strands AgentTools自体の設計パターンは普通にLLMのagent構築でも参考になる。
自分が直したいのは、今の個人プロジェクトでtoolの呼び出しがif分岐で汚くなってる箇所。Strandsみたいに「toolをリストで渡してagentが判断する」構造に寄せれば、環境切り替えも楽になるはず。
まず examples/lerobot/hub_to_hardware.py をcloneして、sim-only・Mock-policyで動かしてみるつもり。Python 3.12とApple Siliconはどっちも手元にある。週末に試して、tool compositionの部分だけ自分のプロジェクトに持ち込めないか確認したい。彼女との予定が日曜に入ってるから、土曜の午前中にやり切る算段。
「pieces work on their own. They don't talk to each other.」という一文が一番刺さった。自分のコードの現状そのままで、笑えない。
ロボット系のワークフローって、今まで本当にバラバラだった。デモ収録・学習・シミュレーション・ハードウェアへのデプロイ・複数台の調整、それぞれ別ツール・別スクリプトで「一応動くけど全然喋ってない」状態。自分はロボット触ってるわけじゃないけど、LLMとAPIサービスを組み合わせてる個人開発でも同じ地獄を何度も経験してる。ツール同士が疎結合で、全部つなぐ糊コードを自分が書かされる。
「1キーワード引数で実機に切り替わる」設計がえぐい
Strands Robots、設計の肝が2点あって、どっちも刺さった。
1つ目は、Robot(\"so100\") がデフォルトでMuJoCo backed simulationを返す点。mode=\"real\" に変えると実機になる。エージェントのコードは一切変えなくていい。
もう1つは、DatasetRecorderがsimとhardwareで共通フォーマット (LeRobotDataset) を書き出すこと。シミュレーションで収録したデータと、実機のSO-101で収録したデータが、ディスク上で同じフォーマットに並ぶ。
from strands_robots import Robot
from strands import Agent
arm = Robot(\"so100\") # デフォルトはsim。mode=\"real\"で実機
agent = Agent(tools=[arm])
agent(\"Pick up the red cube\")これを見たとき、ちょっと声が出た。5行で1ループ。しかもsimから実機への切り替えがキーワード1つ。
自分が最近やってる個人開発で、Claudeのstreaming APIと自前のキャッシュ層をつなぐとき、環境変数をゴリゴリ切り替えて「local/staging/prod」を分岐してた。似た思想を感じる。ただ自分の実装はまだ引数1つで済まなくて、ちょっとみっともない。
GR00T・MolmoAct2・Zenoh meshと固有名詞が連打される安心感
policy inferenceのinterfaceが共通化されてて、GR00TとLerobotLocalが同じIFで差し替えられる。MolmoAct2のcheckpointもLerobotLocalのpathを通る。
こういう「共通interfaceの裏に実装を隠す」設計、チームのコードレビューでも毎回話題になる。うちのチームは3人で、最近新しく入ったメンバーが実装をinterfaceに直してくれたPRがあって、あれが正直めちゃくちゃ良かった。abstract classに寄せるだけでtest書きやすさが全然違う。
複数ロボットの協調はZenohのpeer meshで実現してて、agentが全台にブロードキャストできる。Zenohって名前は知ってたけどroboticsで使われてるの初めて見た。
あと実際に動かすのにハードルが低い。記事曰く「No hardware, no GPU, no Hugging Face credentials needed for the default path」。これはとりあえず試してみるときに神。環境構築でハマってやる気無くなるやつを最初から排除してくれてる。
自分のコードのどこに引きつけるか
ロボット触る予定は今のところないけど、Strands AgentTools自体の設計パターンは普通にLLMのagent構築でも参考になる。
自分が直したいのは、今の個人プロジェクトでtoolの呼び出しがif分岐で汚くなってる箇所。Strandsみたいに「toolをリストで渡してagentが判断する」構造に寄せれば、環境切り替えも楽になるはず。
まず examples/lerobot/hub_to_hardware.py をcloneして、sim-only・Mock-policyで動かしてみるつもり。Python 3.12とApple Siliconはどっちも手元にある。週末に試して、tool compositionの部分だけ自分のプロジェクトに持ち込めないか確認したい。彼女との予定が日曜に入ってるから、土曜の午前中にやり切る算段。
「pieces work on their own. They don't talk to each other.」という一文が一番刺さった。自分のコードの現状そのままで、笑えない。