mechArm 270 Pi 動的追従の、その先を考えた | 双腕協働とコーヒーデモへの構想
「mechArm 270 Pi 動的追従の限界を探る」という連載タイトルで進めてきたパイプラインの先について、AIとの対話の中で輪郭が見えた。記録としてここに残す。
💡 Key Takeaway
単腕の把持を成立させた先に、Pixels to Motors が向かう次のフェーズは「双腕協働」だと見えた。1台の高級機ではなく、安価なアーム2台で複雑タスクを成立させる方向。動きと動きの関係性を Motion UX の新領域として設計する。これがプロジェクトのポジションと完全に一致する。
検討した問い | 出した判断 | 結果 |
|---|---|---|
コーヒーデモは Pixels to Motors の方向性とずれないか | 初期から一貫してコーヒーが目標だった。ハード制約でブロックに切り替えただけ | コーヒー方向は維持。順番を入れ替えただけ |
高級機(ABB CRB15000・約600万円)でコーヒーを淹れるか | ハードのスペックでは大手と勝負しない。設計で勝負する | 1台高級機の選択肢は捨てる |
1台完結型か、複数台協働型か | 複数台協働の方が Pixels to Motors のポジションと整合し、コストも抑えられる | 双腕協働へ進む方針を確定 |
視点を共有するということ
単腕の視覚サーボ・把持を成立させてから双腕に進む。それはもちろん。でも先を常に見ておくという視点をAIと共有するということも大事だと思っている。今行っている作業がどこに向かっているのかを提示することによって全体の計画や必要なことの整理などにも役立つし。
— 行き先が共有されている場合と、目の前のタスクだけ渡される場合では、Claudeの判断が変わる。
たとえば視覚サーボのコードを書くとき。「単腕の把持を成立させたい」だけ知っている Claude は mechArm 専用に最適化したコードを書く。一方で「最終的に双腕協働に進む」と知っている Claude は、関数を「アーム1台分の責務」で切り分け、アームインスタンスを引数で受け取る構造にする。後者のほうが、双腕に拡張するときの書き直しが少なくなる。
「先を見ている」という事実そのものが、目の前のコード設計を変える。Build in Public で語られることは少ないが、AIとの共作では、この視点の共有がコードの寿命を左右する。視点を共有しないと、毎回ローカル最適なコードが量産され、設計の負債が積み上がる。
行き先を提示しておくと、機材の購入判断・Unity シーンの設計・FK スキャンの構造・記事の伏線・失敗の解釈、それぞれの判断が「次のフェーズ」を見越したものになる。視点の共有は、もはや効率の問題ではない。アーキテクチャそのものだ。
コーヒーロボットというヒキ
仕事の内容としてはともかく、一般の人や業界の人に向けてのわかりやすいデモとしてはコーヒーを入れるロボットアームのデモやカフェをスポットで営業するなどはヒキが強そう。
— A〜D層のコアリストに届けるために、ヒキが強いコンテンツを持ち続けるというのは戦略上欠かせない。
Loupe というチャンネルが「The Coffee-Bot」という動画を出している。ABB の CRB15000 という高級協働ロボットでコーヒーを淹れる、美しいデモだ。
CRB15000 の本体参考価格は約 $42,188(およそ600万〜700万円台)。実際に動かすには周辺機器や導入コストが乗るので、トータルでは1,000万円超えも普通にある。「コーヒーを淹れるロボット」という体験は、これだけの投資がないと現状成立しない、というのが業界の認識に近い。
「ロボットがコーヒーを淹れる」は説明ゼロで伝わる。SNSでも記事でも展示でも、業界外の人にPhysical AIを知ってもらえる射程の長いコンテンツになる。スポットカフェの形式で営業すれば、実物を触れた人の記憶に残るし、口コミも生まれる。コアリストに直接届くわけではないが、コアリストが普段見るタイムラインや業界外の知人経由で「あの安いハードでコーヒー淹れてるやつ」として認知が立てば、そこから R&D 契約や引用に繋がる経路は十分にある。
主指標(言葉の被引用・コアリスト内エンゲージ)と副次指標(フォロワー・PV)を対立させて考えていたが、これは雑な整理だった。広い射程と深い射程は二者択一ではない。広い蛇口を閉めれば、深い蛇口も干上がる。コーヒーデモは、Physical AI を一般の文脈へ着地させるための、最強のインターフェースになる。
1台完結型と複数台協働型
仕事の組み立て方は、大きく2つに分かれる。
高級機でやる方向も頭をよぎった。でもそれをやるなら、別に自分じゃなくてもいい気がした。大手とハードのスペックで殴り合っても勝てないし、勝ったところでそれは Pixels to Motors の物語にならない。
方向性 | 設計思想 | コスト構造 | 強み | 弱み |
|---|---|---|---|---|
A:1台完結型 | ハードのスペックでタスクを成立させる | ハード単価が線形に上がる | シンプル・確立された方法論 | 個人発の新規性が出にくい |
B:複数台協働型 | ハードを抑えて、台数と協調動作で解決 | 台数増・合計は抑えられる可能性 | 設計の余白が大きく、新領域 | 同期制御・衝突回避の難易度が上がる |
産業用ロボットの主流は A だ。メーカーが何十年も最適化してきた領域で、ペイロード・精度・リーチを上げる方向で技術が積み上がっている。CRB15000 はその延長線にある。
一方で B は、まだ誰も体系化していない。GEN-1(Generalist)も Toyota Research Institute の LBM 1.0 も Real2Render2Real も、Physical AI の最前線は既に双腕・多腕の構成に動いている。ただし、これらは大手の研究機関が高額ハードで取り組んでいる領域で、個人発・低コストの実装例は決定的に不足している。
ここに Pixels to Motors の入る隙間がある。
なぜ複数台協働がポジションと整合するのか
Pixels to Motors の3つのブランドピラーを、双腕協働の文脈で読み直すとこうなる。
柱 | 単腕の文脈 | 双腕協働の文脈 |
|---|---|---|
UX × AI × Robotics の交差点 | 既存議論に乗りやすい | 誰もいない場所に立てる |
iPhone を入り口にした低コスト化 | mechArm 単体で証明済み | 2台でも合計15万円以下が可能 |
体験から逆算する設計思想 | 動作の品質を語れる | 動作の「関係性」を語れる |
双腕協働は、Pixels to Motors のポジションを単腕構成よりさらに鮮明にする方向の選択肢だ。
1台のロボットの動きは「動作」の議論で終わる。複数台になると、「動きと動きの間の関係性」という新しい設計層が現れる。どっちが先に動くか。どっちが待つか。相手が手を引いた瞬間に動き出すタイミング。衝突しかけて止まる動作の質。失敗したときにどっちがリカバリするか。これは UX デザイナーが何十年もやってきた「人と人の関係を設計する」「画面と人の関係を設計する」と同じ構造の問題で、ロボティクスに固有の文脈で UX 経験が初めて活きる領域になる。
そして「ロボット同士の協働」と「人とロボットの協働」は技術的に地続きだ。2台のロボットを同期させる課題は、1台のロボットと人間を同期させる課題と本質的に同じ。相手の動きをリアルタイムに観測し、意図を予測し、自分の動作を相手に合わせて調整する。mechArm 2台で解いた問題は、そのまま「ロボットと人がコーヒーを淹れる」に転用できる。双腕は人協働への踏み台として機能する。
コーヒーデモが双腕構成で生きてくる
双腕協働でコーヒーデモを組み立て直すと、人間がカフェで2本の手を使ってやっていることが、2台のロボットアームに分解されていく。
1台がカップを支える / もう1台がドリッパーを操作する
1台がコーヒー豆の袋を押さえる / もう1台が注ぐ
1台が温度センサ付きの計測役 / もう1台が湯量制御役
1台高級機では絶対に出ない設計になる。Coffee-Bot は1台のアームで完璧に作業を完結させているが、双腕構成は別の物語を語れる。「人の所作を2台に分解する」というアプローチそのものが、Motion UX の議論を立ち上げる。
順序という考え方
単腕の視覚サーボ・把持を成立させてから双腕に進む。
これは原則として守る。理由は3つ。
まず、単腕で動かないものは双腕でも動かない。1台のアームで赤ブロックを掴めないなら、2台にしたところで状況は悪化する一方だ。基礎が立っていないところに複雑性を乗せると、デバッグ不可能な状態になる。
次に、双腕は単腕の問題が2倍になるのではなく、2乗になる。同期制御・衝突回避・キャリブレーション・座標系の統一・ソフトウェアツールチェーン。それぞれの課題が掛け算で効いてくる。単腕で詰まっている問題を持ち越すと、双腕で表面化する複雑性に飲まれる。
そして何より、単腕の Build in Public のログが、双腕の設計のベースになる。今のパイプラインを完成させる過程で得られる知見(FK スキャン・視覚サーボ・把持成立条件・REFINEプローブ式)は、双腕構成でも前提として効く。早く双腕に行くより、単腕の決着を完璧にする方が、結果的に双腕の立ち上げが速くなる。
把持が成立した瞬間に、「次は2台にする」という決断ができるタイミングが来る。それまでは今のパイプラインを成立させるのが最短ルートだ。
ハードの選択肢
双腕構成に進むときの選択肢は2つに整理できる。
対称構成:mechArm 270 Pi × 2 台 ── 同じ機種・同じ API。コードの共通化が最大化される。両方ともペイロード 150g 程度なので、軽量物のみ。
非対称構成:mechArm 270 Pi + myCobot Pro 630 ── 役割分担を前提にする。Pro 630(ペイロード 2kg)が「持つ」役、mechArm が「操作する」役、などの分業。コストは合計 120 万円程度。
非対称構成は「重い役・軽い役」の分業を実装しやすく、コーヒーカップを持つこともできる。一方で対称構成は、コードの観点ではシンプルで、双腕協働のリファレンス実装としては美しい。
決定は、単腕の把持が成立して、次フェーズの具体的なデモタスクが固まってからでいい。
視点を共有する、それ自体が設計
このセッションで一番大事だったのは、技術的な結論ではない。プロジェクトの中長期方向を AI と共有するという行為自体だった。
行き先が共有されていれば、毎回のコード設計・機材判断・記事の伏線・失敗の解釈、すべての判断が「次のフェーズ」を見越したものになる。Build in Public で語られることは少ないが、AIとの共作では、この視点の共有がコードの寿命を左右する。
視点の共有は、もはや効率の問題ではない。アーキテクチャそのものだ。
いま単腕でやっていることは、双腕への踏み台。双腕でやることは、人協働への踏み台。最終的に向かうのは、動きと動きの関係性を設計する Motion UX という新領域。
