正しい動きと、いい動き | Motion UX の二層構造

計算は、正しい動きを導ける。逆運動学も、補間も、速度プロファイルも、外にある正解を当てにいく作業だ。だが「いい動きかどうか」は、計算の外にある。ここを分けて考えると、ロボットの動きの設計が二つの層に見えてくる。

滑らかさは、目で気づく

きっかけは、ある研究チームが公開していたロボットの動作の映像だった。双腕のアームがマッチを擦って蝋燭に火をつける。その動きが、明らかに滑らかだった。説明を読む前に、映像を見た瞬間に分かるレベルで。

これは動画見てすぐ気づいたところだったね。動きが非常に滑らかだったな。

なぜ、目で一発で分かるのか。

人間の目は、速度の不連続よりも加速度の不連続に敏感だ。動きが「ガクッ」と見える瞬間は、速度が急に変わった時ではなく、加速度がジャンプした時に立ち上がる。アームが一定の速さで動いていても、その「速さの変わり方」が滑らかでなければ、人はそこに違和感を覚える。

この映像で滑らかに見えたのは、動作のセグメントとセグメントの継ぎ目で、加速度が飛ばないように繋がれていたからだ。逆に言えば、多くのロボットがカクついて見えるのは、この継ぎ目に加速度のスパイクが出ているからになる。映像で気づいた滑らかさは、感覚的な印象ではなく、加速度の連続性という測れる性質の話だった。

研究チームが論文で示していた図は、ある関節の位置・速度・加速度を並べたものだった。位置だけ見れば、どの手法もそれらしく動く。差が出るのは加速度のところだ。継ぎ目で加速度が跳ねるかどうか。人の目が拾っていたのは、まさにそこだった。設計者が見るべき指標は、位置でも速度でもなく加速度にある。

平滑化は、答えではない

ここで素朴な発想が浮かぶ。継ぎ目がカクつくなら、均してしまえばいい。複数の予測を平均すれば滑らかになるはずだ、と。

研究チームの論文は、この発想を否定していた。継ぎ目を単純に平均する手法を試すと、滑らかになるどころか、ロボットが激しく振動して保護停止が作動するほどだったという。人為的に遅延を足した条件では、その手法は動作すらしなかった。理由は単純で、有効な動きの平均は、有効な動きとは限らないからだ。障害物を上から避ける軌道と、下から避ける軌道。この二つを平均すると、障害物に突っ込む軌道になる。

では、その論文はどう解いたのか。平均ではなかった。

すでに実行が確定した動きを固定し、その続きを「それと整合する有効な動き」として生成し直す。動いている途中で次の動作を作るとき、もう実行が決まっている部分はそのまま動かさず、残りをその確定部分と地続きになるように埋める。画像の欠けた部分を、周囲と整合するように描き足すのと同じ発想だという。さらに、確定部分の直後だけでなく、その先の重なる区間にも少しずつ重みをかけて参照する。継ぎ目の直前だけを合わせると、その先で戦略が切り替わって不連続が残るからだ。

結果として、その手法は推論の遅延に対して頑健だった。予測の三割を超えるような遅延が出ても、マッチを擦って火をつけるような精密な動作が成立し、同じ動きを停止なしで実行するぶん速くもなった。停止して次を待つ方式は、待っている間にロボットのダイナミクスが学習時と変わり、そのズレ自体が動きを乱す。停止をなくすことは、速さだけでなく動きの正しさにも効いていた。

中途半端に滑らかに動くなら、カクカクしてた方が人は安心するかもだよね。

以前の考察で書いた、動きの不気味の谷と同じことを言っている。半端に均すと谷に落ちる。単純な平均は、滑らかにしようとして逆に不気味で危なっかしい動きを生んだ。整合性を保ったまま作られた滑らかさは、谷を越えて自然さの側に着地した。同じ「滑らか」でも、作り方が違うと結果が真逆になる。不連続を均したから滑らかなのではなく、不連続を生む構造そのものを作らなかったから滑らかだ。

計算で動きを作るということ

ここまでは、よその研究の話だ。手元の mechArm に視点を戻す。

Pixels to Motors のいまの動きは、計算で導いている。iPhone カメラで捉えたブロックの位置を、ホモグラフィで座標に変換する。その座標から、512,087 点の FK lookup table を引いて関節角度を決める。send_angles で角度を送る。send_coords の逆運動学が位置によって暴れたので、角度を直接指定する方式に切り替えた経緯がある。位置に応じて確実に届くことを、テーブルと角度指定で担保している。

このやり方は、動きを計算で「導出する」アプローチだ。正しい角度、正しい軌道という正解が外にあって、それを計算で当てにいく。逆運動学、補間、速度プロファイル ── どれも、最適解や妥当解が数式の側にあって、それを求める作業になる。

この確実性には、はっきりした価値がある。物理的なリスクのある動作で、入力に対して出力が確定しているのは安全に効く。外部レビューを挟み、send_angles に限定し、一点ずつ到達を確認しながら動かす。いまの慎重な運用は、この確実性の上に成り立っている。確定論的であることは、古さではなく安全性の根拠だ。

ただし、これはエンジニアリング寄りのアプローチでもある。ここで戦うと、精度と計算資源の勝負になる。計算で動きを正しくする競争には、桁違いの資源を持つプレイヤーがいる。同じ土俵で速さや精度を競っても、勝ち目の薄い勝負になる。ソロで公開ログを続ける個人が、正面から立てる場所ではない。

手で動きを入れるということ

別のやり方がある。手で動かして、動きを教える。

ドラッグティーチングと呼ばれる方法だ。関節のトルクを切ってアームを手で自由に動かせる状態にし、その間の関節角度を連続して記録する。再生はトルクを戻して、記録した角度を順に送るだけ。pymycobot の標準 API でこれが実行できることは、以前の調査で確認済みだ。トルクを切る、戻す、関節角度を取得する ── 必要な機能は揃っている。動作の記録・再生そのものは専用 API がないので、角度を時系列で保存して順に送り返すコードを自分で書く必要があるが、難易度は低い。手で動かして角度を貯め、貯めた角度を送り返す。それだけで最小限の教示再生は動く。

ここで起きていることは、計算とは発想が逆だ。正しい動きを導出するのではなく、「この動きがいい」という判断を手で入力している。

何がいい動きかは、外に正解があるわけではない。掴まれる物の立場、置く時の丁寧さ、その動きを見ている人が感じる安心感。これらは数式が決めるものではなく、文脈で決まる。これはUXの設計判断そのものだ。手で動かすという行為は、その判断を直接アームに通す経路になる。

計算でやるのもいいけど、それはあくまでもエンジニア的アプローチ寄り。あくまでもデザイナーとして UX 視点で考えて設計していくことは発信内容としても価値がある。

論文が「有効な動きの平均は有効な動きとは限らない」と数式で示したことを、手で動かしながら「この均し方は気持ち悪い、こっちが自然」と判断できる。計算では出しにくく、人間には一発で分かる。映像で気づいたあの滑らかさの正体は、この判断の側にある。29年デザインをやってきた仕事と、ここは地続きだ。手の動きはもともと連続しているから、教えた軌道には人間の連続性がそのまま入る。滑らかさの基準が、最初から人の手の側にある。

一本の軌道を、どう増やすか

ただし、手で教えた動きには、はっきりした弱点がある。固定された一本の軌道でしかない、ということだ。

教えたその動きを、そのまま再生するだけ。ブロックがどこにあっても、同じ動きをする。いまの mechArm がやろうとしているのは、iPhone で位置を見て、その位置に応じて掴みにいく動作だ。教示再生は、この「見て、位置に応じて動く」部分を持っていない。一本の軌道を覚えて繰り返すだけでは、毎回違う場所のものは掴めない。滑らかさと引き換えに、視覚で位置を捉えて動くという、プロジェクトの核そのものを失うことになる。

ここで、対話の中で出てきた発想が効いてくる。

ドラッグティーチングは手で教えた軌道の再生の動作データをベースに、Unity でデジタルツイン学習させて大量で多様な動作データを生成したらどう？

これは、プロジェクト名の元になった Real2Render2Real の構造そのものだ。手で教えた滑らかな軌道を、再生するためではなく、学習データの種として使う。実機から少数の軌道を取り(Real)、それを Unity のデジタルツインに持ち込んで、物体の位置や姿勢、アームの初期姿勢を振って大量・多様な軌道に増やし(Render)、その合成データで動作を学習して実機に戻す(Real)。

こうすると、固定軌道の弱点が消える。種になる軌道は人間の手の動きだから、滑らかさの基準が最初から入っている。それを位置を振って増やせば、「いろいろな位置のブロックに対して、それぞれ滑らかに掴みにいく軌道」のデータセットになる。学習したものは、位置を見て、滑らかに動く、という両方を持つ。固定軌道の再生(位置に対応できない)と、計算による導出(滑らかさは別に作り込む必要がある)の、両方の弱点を同時に埋める発想になっている。

トレードオフは明確だ。いまの確定論的なやり方から、確率的な模倣学習へ移ることでもある。得るものと引き換えに、手放すものが三つある。

• 確実性は下がる。いまのホモグラフィと FK lookup は、入力に対して出力が決まる。学習したものは確率的で、同じ入力でも軌道が揺れ、学習データの外では予測しにくい動きをする。物理リスクのある動作で「何が出てくるか確定しない」のは、いまの慎重な運用と相性を見極める必要がある。

• シミュレーションと実機の差が、新しい不確実性として乗る。Unity で増やした軌道が実機でそのまま滑らかに動く保証はない。デジタルツインの物理と実機のダイナミクスの差が、再現性に効く。

• 実装の範囲が大きく広がる。学習の基盤、データの形式、評価のループが新しくなる。

種を取る部分、つまり実機でのドラッグティーチングは、標準 API で実行できることが分かっている。詰まりやすいのは、増やす側と学習の側だ。だから、ここは順序の問題になる。

二層で捉える

ここで、計算と設計を対立させたくなる。手で設計する方が上だ、計算は古い、と。それは違う。

正確には、二つは層が違う。

motion 品質＝人間の設計軸、と構造的に一致する。これは非常に大事だね。

計算で確実な骨格を作る。その上に、手で動きの質を設計する。この二層で捉えるのが、いちばん正直で、いちばん強い。

下層がなければ、上層は地面から浮く。手で設計した「いい動き」も、それを安全に・確実に実行する骨格がなければ、現実では成立しない。物理リスクのある動作で確実性を捨てるわけにはいかない。だから計算を捨てる話にはしない。計算の確実性は、デザイン判断を乗せるための土台として要る。模倣学習に進んだ先を考えても、確定論的な骨格は、確率的な動きを安全な範囲に収める枠として効くはずだ。

逆に、下層だけでは「正しい動き」までしか作れない。いい動きには届かない。骨格の上に、手で質を入れて初めて、人が安心して見られる動きになる。

この二層は、先の研究チームの論文の構造とも揃う。論文は、高レベルの計画を担う層と、低レベルの動作生成を担う層を分けていた。計画は低頻度で、動作生成は高頻度で動く。Pixels to Motors の役割分担 ── 計画は AI に、動きの質は人間の設計軸に ── も、構造としては同じ入れ子になっている。計画が「何を、どの順でやるか」を決め、動きの質が「それをどう動かすか」を作る。計算で骨格、手で質、という二層は、その分担を動きの側に翻訳したものだと言える。

なぜ、これが発信になるのか

二層で捉えることには、設計上の意味だけでなく、発信としての意味もある。

「計算で滑らかにしました」は、誰でも言える。そして、より速い計算機を持っている人に勝てない。滑らかさを計算の精度で競う限り、それは資源の勝負になる。

「動きの質を手で設計して、それを位置に応じて使えるようにした」は、なぜその動きなのかを言語化できる人にしか語れない。何を残し、何を諦め、なぜこの速度で、なぜこの軌道なのか。この説明は、計算式からは出てこない。設計判断の積み重ねからしか出てこない。

これは、技術者には書けない種類の語りになる。Motion UX という言葉を、抽象論ではなく「自分は実際にこうやって動きを設計している」という実物で裏打ちできる。同じパイプラインを使っても、研究者がタスクの成功率を見ているところを、こちらは動きの質を見ている。その差分が、立ち位置の独自性になる。

Real2Render2Real ── プロジェクト名の元になった研究も、少数のデモをシミュレーションで大量化して汎化させるパイプラインだった。だが、彼らが見ているのは汎化と成功率だ。動きの質を設計対象として見てはいない。同じ道具立てを、動きの質という別の目的に向ける。成功率の数字の裏で「その成功はどんな動きで達成されたのか」を問う視点は、まだ誰も主戦場にしていない。そこに、立てる場所がある。

着手は先でいい。地図は引いておく

ここまでの話は、すぐ手を動かす話ではない。

あくまでも今の動的追従シリーズの Pick and Place が終わった後に取り組むべきことだけど、今からどのような変化が得られるかを調べておくのは必要なことだと思う。

順序は崩さない。いまは動的追従シリーズの Pick & Place を、確定論的に完走させるのが先だ。ドラッグティーチングを種にした模倣学習も、二層の上層を本格的に作り込むのも、その後の話になる。先走って、まだ固まっていない下層の上に上層を乗せることはしない。

ただ、地図を先に引いておく価値はある。何が得られるかを見立てておけば、いま下層を作っている最中の設計判断が変わるからだ。一番具体的に効くのは、データの残し方だ。カメラで捉えた位置と、そのとき実機に送った角度列を対にして残しておく。観測と動作のペアを記録するだけのことが、二層の上層に進むときの学習データの種になる。いま捨てているログが、後で足場に変わる。

設計判断の言語化も、先に始められる。mechArm の腕を動かしながら、「なぜこの速度なのか」「なぜこの軌道なのか」を、計算の都合ではなくデザイナーの判断として説明する。その言葉を貯めておけば、手で動きを入れる段階に進んだとき、自分が何を入力しているのかが最初から明確になる。地図を持って下層を作るのと、地図なしで作るのとでは、後の効き方が変わる。

締め

計算で骨格を作る作業は、毎日続いている。観測と動作のペアを残し、なぜこの動きなのかを言葉にしていく。その上に何を乗せるのかは、もう考え始めていい。

計算は、正しい動きを導ける。いい動きを決めるのは、その上に立つ設計だ。