mechArm 270 Pi、まだやれることが結構ある

ROS2は必要かと聞いたら、最後に「業界標準への憧れがあるかも」と認めていた。技術判断のはずがポジショニングの話に着地し、その先で「単腕の限界に到達した」と思っていたものが「まだやれることがある」に書き換わった。Motion UXという領域が、単腕のまま手に入る場所として見えてきた記録。これは自分への申し送り。

「ROS2は必要ですか」と聞いた本当の理由

ROS2の接続についてはだいぶ前に動かしていますが、一旦今の動的追従に集中しています。ROS2は現段階では必要ないとの見解もありましたが、やはり必要でしょうか？

—— なぜ今、その問いを？

国産ヒューマノイドを開発しているスタートアップのポストを見ていた流れで、業界標準スキルの話になっていた。NVIDIA Isaac / MuJoCo、PyTorch / TensorFlow、強化学習、Sim2Real。並べられたスキル要件のどれにも、自分は当てはまっていない。

「動的追従に集中している」と書いたのは事実だけれど、その下に別の問いが沈んでいた。自分は今、正しい場所に立っているのか。

Claudeの返しはシンプルだった。

結論から言うと、今のフェーズではROS2は必要ありません。

判断基準も明示された。「今やっていることの実現にROS2が必要か？」と問えばいい。 答えがNoなら、入れない。

動的追従は今のUnity + ArticulationBody中心のスタックで実現可能。ROS2を挟むとUbuntu必須、ノード起動の手間、デバッグの複雑さ、というレイヤーが増えて検証速度が落ちる。「iPhoneひとつで始められる」という低コスト化の思想にも逆行する。

ROS2が必要になる4つのタイミング

今ではなく、こういう状況になったとき。

1. 業界の人と共同実装する話が出たとき

2. MoveIt2の経路計画やSim2Realが、自前実装より明らかに有利になったとき

3. 論文や登壇で「業界標準でも動かしました」と言う必要が出たとき

4. 複数のロボットや既製センサーを統合する段階になったとき

今はどれにも該当しない。後回しでいい。過去にROS2接続をやった経験があるので、必要になったときはゼロから始めるわけではない。「いつでも取りに行ける状態」をキープしているだけで十分。

「スタートできていない」と思っていたこと

双腕、ROS2の導入が出来て、はじめてロボティクスUXデザイナーとしてなにをすべきか？がスタートできるというイメージがあるけどどう思いますか？

これを送ったとき、自分のなかでは素直な認識だった。双腕構成を作って、ROS2が動いて、業界標準のスタックが揃ったら、そこからロボティクスUXデザイナーとして本格的に動き始められる。そう思っていた。

返ってきた答えは、半分肯定、半分否定だった。

その認識は、半分正しくて半分危険だと思います。

危険な部分として指摘されたのは、「これができてからスタート」という考え方は、永遠にスタートしない罠だということ。

LOG165を超えて、すでに毎日ロボティクスUXデザイナーとしての仕事をしている。今やっていることそのものが、すでにそのスタートラインの先にある、と。

—— 具体的には、何を指して「すでにスタートしている」と言っている？

• iPhone 3D scanという入り口の設計 = UX設計そのもの

• 「精度より体験の成立を優先する」という設計哲学の言語化 = UXデザイナーの最重要スキル

• DAY logのバイリンガル発信 = ロボットを社会に接続するUX実装

• ハコブくんの4コマ漫画によるHRI概念伝達 = 誰もやっていないUX手法

• 「8:2の法則」「来訪神としてのナマハゲ」など = 世界観設計もUX領域

これらは全部、双腕やROS2なしでやっていること。すでにロボティクスUXデザイナーとして稼働している証拠。

読みながら、んんん、と思った。確かに自分は「スタートできていない」と思い込んでいたけれど、外から見たら違う絵が見えているらしい。

業界標準への憧れを認める

なるほど。そこまでの考えはなかった。業界標準みたいなものへの憧れはあるかもね。実際に今評価されるのは業界標準のスキルが高い人たちだろうし。

これを書いたとき、自分でも少し驚いた。憧れがあると認めるのは、抵抗があるはずだったのに、すっと出た。

Claudeの整理はこうだった。「今評価されるのは業界標準スキルの人」というのは、半分本当で半分嘘。

評価軸は複数ある。上3つは業界の内側、下3つは業界の境界・外側。自分が立とうとしているのは下3つで、ここでは業界標準スキルは必要条件ですらない。

そして印象に残った指摘がもう一つ。

業界標準スキルの高い人たちは見えやすい。論文を出し、カンファレンスで登壇し、有名企業に所属し、技術記事で名前が知られている。承認の信号が分かりやすい形で返ってくる。一方、エイイチさんがやっていることは評価軸が確立していない。「ロボティクスUXデザイナー」という肩書きを評価する制度がまだない。だから承認の信号が不規則で、見えにくい。

見えやすい評価軸に憧れるのは弱さではなく、自然な反応。これを読んで、少し肩の力が抜けた。

前に海外のHCI研究者が、日本語で書いている自分のサイトを検索エンジンで見つけて連絡してきたことがある。業界標準を完璧に習得した日本人エンジニアの英語サイトでは、たぶん彼は反応しなかった。業界標準から外れているからこそ届いた、という構造がそこにはあった。評価軸が複数あるという話は、抽象論ではなく、自分の身に起きていることだった。

「単腕の限界に到達した」と思っていたこと

ここからが、この対話で一番認識が動いた場所。

動的追従はLOG204、Log#17まで来ていて、上カメラと横カメラを使ったブロックのPick動作があと一歩、Riseは難易度が低いので短期で完成する見込み。単腕でやれることはここで一区切りつく、と思っていた。

mechArm 270 Piはホビーグレード。ペイロード250g常用、リーチ270mm、繰り返し精度±0.5mm、連続稼働500時間。中身の入ったコーヒーカップ約600gは、単腕では運べない。これはハードウェアの仕様的天井で、ソフトウェアでは超えられない。

だから次は双腕、と考えていた。LOG201で「動的追従の、その先」として、非対称双腕の構想は既に出している。mechArm × 2 で約12万円、mechArm + myCobot Pro 630 で約120万円のレンジ。コーヒー注ぎを具体タスクに据えて、POUR ARM(注ぐアーム)とSUPPORT ARM(支えるアーム)で役割分担する構図。

ところがClaudeに「mechArm 270 Piの性能限界はどこまで」と改めて調査させたら、自分の認識が浅かったことが分かった。

まだやれることがある

Claudeが返してきたリストを見て、んんん、となった。

• ドラッグティーチング — 手で動かして動作を教える、再生する

• 電流ベースの力覚センサー・トルク検知 — 専用センサーなしで「触れた」を検出

• Drag-and-Teach + 模倣学習 — 教えた動作データで学習させる。mechArm 270 PiはLinux上で1:1のROSシミュレーションモデルを構築可能

• 動的視点 — 補助役にカメラを持たせて視点を動的に提供する発想

• 業界の双腕模倣学習(ALOHA系)への接続 — myArm M&Cという双腕テレオペキットをElephant Robotics自身が販売、「Validating ALOHA Robot Motion」と公式に明記されている

「mechArm 270 Pi、まだ結構できるね」と返した。

「単腕の限界に到達した」と思っていたのは、Pick & Placeという単一タスクの限界だった。 Motion UXという領域に踏み込むと、単腕のままできることがまだ大量に残っている。

これは双腕に行く前のフェーズとして、別軸の探索が成立するということ。順序を組み替える必要が出てきた。

pymycobotのAPIを精査して分かったこと

GitHubの https://github.com/elephantrobotics/pymycobot/blob/main/docs/MechArm_270_en.md を当たって、APIをひとつずつ見ていった。

ドラッグティーチング系は予想通り標準で揃っていた。

release_all_servos()       # 全関節のトルクを切る(手で動かせる状態)
focus_all_servos()         # 全関節のトルクを入れる

これで「手で動かせる状態にする → 関節角度を連続取得 → 保存 → 再生」という流れが、追加投資ゼロで書ける。動作の記録・再生の専用APIは見当たらないけど、get_angles() を周期的に呼んで自分で時系列保存・再生コードを書くだけ。難易度は低い。

問題はここから先。力覚センサーは標準搭載されていないと思っていた。専用の6軸FTセンサーは別売で30〜100万円、というのが業界の常識。だから諦めて飛ばすつもりだった。

ところが get_servo_status() の戻り値の説明を見ていて、「あれ?」となった。

get_servo_status()   # 電圧 / センサー値 / 温度 / 電流 / 角度 / 過負荷状態

current(電流値)が普通に取れる。

モーター電流は負荷トルクと相関する。関節に外力が加わると電流が増える。つまり「触れた」「押されている」が、専用センサーなしで取れる可能性がある。

さらに見ていったら、衝突検知は完全に標準搭載されていた。get_error_information() のエラーコード16〜19が Collision protection。何かにぶつかったら検知して止まる、という機能が最初から入っている。

そしてグリッパー側にもこれがあった。

set_HTS_gripper_torque(torque)   # グリッパーのトルク設定(150〜980)

把持力を物に合わせて変えられる。「優しく握る」「しっかり握る」を標準APIで制御できる。

順序が逆になっていた。「専用センサーがないからできない」と思っていたら、最初から別の道で同じことができるようになっていた。

これが戦略的に意味すること

業界の正攻法は専用の6軸FTセンサーを使うこと。30〜100万円する。それを電流値で代替する発想は、業界の常識から外れている。

でもこれはまさに「精度より体験の成立を優先する」「iPhoneを入り口にした低コスト化」というPixels to Motorsの哲学そのもの。「専用センサーなしで実用的な力検知を実装する」こと自体が、独自記事の核になる。

タイトル候補をメモしておく。

• mechArm 270 Pi で専用センサーなしの力検知を実装する

• 電流値だけで「触れた」を検出する:低コストロボティクスの力覚UX

• Implementing force detection on a $799 robot arm without F/T sensor

これは双腕に行く前に、単腕で書ける独自記事のネタ。

ドラッグティーチング vs テレオペレーション

ドラッグティーチングはすぐにでも取り入れたかったから、テレオペとの違いを整理した。

ドラッグティーチングは、ロボット本体を直接手で掴んで動かす。人 → mechArmの腕を握る → 関節を物理的に動かす → ロボットがその動きを記録、という構造。

テレオペレーションは、別の入力デバイスを介してロボットを動かす。人 → リーダーアーム/手袋/VRコントローラ → 信号 → mechArm(フォロワー) → 動く、という構造。

重要なのは、ALOHAは「Leader-Follower方式のテレオペレーション」を使っているということ。リーダー側で人が小型のアームを手で動かし、フォロワー側で本物のアームがリーダーと同じ動きをする。その動作データを記録 → 模倣学習で再生。双腕模倣学習に進む場合、最終的にはテレオペレーションが必要になる。

ここに独自展開の可能性が見えた。ALOHA系は数百万円のセットアップが必要だけど、iPhoneを入力デバイスにしたテレオペレーションなら、リーダーアームを買わずにテレオペが実現できる可能性がある。「iPhoneがリーダー、mechArmがフォロワー」という構成。動的追従の延長線上にこれが見える。

つまり、進む順序はこうなる。

1. ドラッグティーチング(mechArm単体、追加投資ゼロ)で「動きを教える体験」を設計

2. iPhone入力でのテレオペレーション簡易版(mechArm単体、独自構成)

3. 双腕テレオペレーション(myArm M&C 等、ALOHA系の流れに乗る)

双腕は左右同じである必要はない

ここでもう一つ、認識が動いた。

mechArm × 2 ではなくて、mechArm + myCobot Pro 630 のような非対称構成を考えていた理由を、Claudeに精度の話として説明していた。中身の入ったコーヒーカップ約600gは mechArm 270 Pi(ペイロード250g)では持てない。だから精密で大きいアーム1台と、ホビーグレード1台の組み合わせを考えている、と。

そうしたら、Claudeが組み合わせ最適化の話に持っていこうとしたので、それは違うと返した。

これはもちろんロボットアームの組み合わせで出来ることが相当違うはずだけど、問題はそういうことではなくて、双腕といっても両方同じ性能のもの、同じ動作をするものという前提で考える必要はないということ。

業界の双腕事例はBaxter/Sawyer、YuMi、NEXTAGE、Pepper、ALOHA、Mobile ALOHAまで、ほぼ全部が左右対称。業界が暗黙に持っている前提──「双腕 = 左右同じ性能、同じ動作」──を、誰も疑っていない。

その前提を外すと、設計空間が一気に広がる。

• 性能の非対称:高精度+低精度、高速+低速、大ペイロード+小ペイロード、長リーチ+短リーチ

• 動作の非対称:主動作+補助動作、操作+観察、把持+視覚提供

• 機能の非対称:把持専用+カメラ専用、力制御+位置制御

• コストの非対称:産業用入門機(myCobot Pro 630、約100万円、ペイロード2kg、リーチ630mm、繰り返し精度±0.1mm)+ホビー機(mechArm 270 Pi、約10万円)

メインの作業は産業用入門機、補助作業はホビー機。トータルコストは産業用2台より遥かに低く、できることは産業用1台より広い。これは「ロボット導入のコスト構造を再設計する提案」になる。

LOG201で出した「POUR ARM + SUPPORT ARM」の構図は、まさにこの非対称設計だった。POURは精密な動作が必要 → myCobot Pro 630(±0.1mm精度)、SUPPORTはカップを保持するだけ → mechArm 270 Pi(精度は不要、安定保持できればOK)。役割の経済合理性に基づく非対称構成。

組み合わせ最適化の前に、探索が必要

ただし、「mechArm + myCobot Pro 630 が最適」と決め打つのは順序が逆。

もちろん最終的には最適化するけど、どの組み合わせがいいか大枠わからないのに最適化も進まないよね？

今やるべきは、双腕の組み合わせ空間を探索して、有望な大枠を見定めること。最適化はその後。

探索シリーズの構想をメモしておく。これは机上の思考で書けるから、実装より先に出せる。

• 非対称双腕の組み合わせ地図 vol.1 性能軸

• 非対称双腕の組み合わせ地図 vol.2 機能軸

• 非対称双腕の組み合わせ地図 vol.3 コスト軸

• 非対称双腕の組み合わせ地図 vol.4 タスク軸

LOG201で「双腕の前提を疑う」を出した。その続編として、組み合わせ空間の探索を概念記事として書く。実装(2台目の購入、ROS2構築)はその後でいい。

フェーズの再構築

今までは「単腕の限界 → 双腕へ」という流れで考えていた。今回の対話で、間にもう1つフェーズが挟まることが見えてきた。

1. Pick & Place完成(残り1〜1.5ヶ月)

2. 単腕でのMotion UX探索(新規。ドラッグティーチング、電流ベース力検知、動的視点、iPhone入力テレオペ、模倣学習の最小実装)

3. 双腕構想の具体化(非対称双腕の組み合わせ地図シリーズ)

4. 双腕実装(ROS2導入はここから)

2を挟むことで、双腕に行く頃には技術的土台が遥かに豊かになっている。そして「双腕に行く必然性」がさらに強くなる。「単腕ではこれだけやった、それでも届かないから双腕に行く」と言えるようになる。

ROS2の位置づけも自動的に決まった。フェーズ2(Motion UX探索)ではROS2は要らない。ドラッグティーチングも力検知も動的視点も、全部pymycobotだけで実装できる。ROS2の本格導入はフェーズ4(双腕実装)の頭。mechArm 2台目購入と同時。

今やる必要は本当にない。フェーズ2を挟むことで、ROS2導入のタイミングはむしろ後ろにずれる。それでいい。動的追従とMotion UXという独自性の核を磨くフェーズが、想像していたより長く続く。

当面のアクション

自分への指示として整理しておく。

• pymycobotのドキュメントを精読、release_all_servos() と get_servo_status() を実機で叩く

• ドラッグティーチングの最小実装を書く(数十行で済む)

• 電流値を連続取得して「触れた瞬間」を判定するロジックを試す

• Pick & Place完成後に「単腕でやれることの境界線」総まとめ記事を書く(双腕への橋渡し)

• 「非対称双腕の組み合わせ地図」シリーズを机上で書き始める

• ALOHA、Mobile ALOHA、LeRobotの論文・動画チェック

• 「自分は何屋か」の一行は宿題として持ち越す(別DAYで)

書き換わった2つのこと

LOG205で動いたのは、技術判断ではなかった。

ひとつは、自分の現在地の見積もり。「双腕とROS2ができてからスタート」と思っていたものが、「既にスタートしていて、必要に応じて道具を取りに行く」に書き換わった。順序が逆になっていた。

もうひとつは、mechArmの限界の意味。「単腕の限界に到達した」と思っていたものは、Pick & Placeという単一タスクの限界だった。Motion UXという領域に踏み込むと、単腕のままで深掘りできる場所が想像より広く残っている。

業界標準への憧れは否定しない。見えやすい評価軸に憧れるのは自然な反応で、それを認めたうえで、自分の戦場は別にある。

道具が必要になったら取りに行く。先に道具を揃えてから動こうとした瞬間、自分の戦場を失う。