丸テーブルでの空振り後の再把持を立て直す――実機で検証した2つの対策

丸テーブルでタオルをつかみ損ねると、直後の再把持も空振りに終わります。実機でのタオル畳みでは、丸テーブルからタオルを持ち上げて畳み作業面に置く工程がしばしばボトルネックです。1回目の把持が外れると、その後の再把持は通常の1回目の把持よりも失敗しやすくなります（両経路のベースラインで、条件付き再把持成功率は 19〜29% 程度にとどまります）。前回の記事 ^[1] では、空振りの原因を知覚の崩壊ではなくプレフィックス慣性に求め、2つの対策を提案しました。本稿はその続編として、丸テーブルで空振りした後の再把持について、両方の対策を実機で検証します。条件付き再把持成功率は学習側で約 19.2% から 58.8% に、運用側で約 29.4% から 66.7% に上がり、成功エピソードの平均完了時間は約 4 秒短くなりました。

1. はじめに：丸テーブルでの再把持は立て直しにくい――検証する2つの対策

著者と仕事の進め方。 私は池云昊（Yunhao Chi）です。おもてなしロボティクスの創業時に加わった初期の機械学習エンジニアです。本研究は、空振りについてチームが得た機序の結論を実機に持ち込み、丸テーブルで失敗した後の再把持に対する対策を診断・設計・検証するものです。私はまず失敗の動画と動作／状態の曲線から自分で仮説を立て、次に AI に同じ材料を独立に読ませて、2つの見方をぶつけながら探索の方向を絞り込みます。方向ごとに私がアイデアと実験計画の草案を書き、AI に弱点の指摘と抜けの補完を求めます。ログの掘り起こし、スクリプト作成、レビュー、結果の集計は AI に大きく頼り、診断と実験の主線は人が主導します。以下は、このループをロボットの上で回した記録です。

タスクとシステム。 私たちのステーションは、俯瞰カメラと左右の手首カメラを備えた双腕ロボットです。タオル畳みの工程では、左腕が円形の供給テーブルからタオルを取り上げて畳み作業面に置き、その後の畳みはそれが済んで初めて完了します。ポリシーは π₀ 型のフローマッチング視覚・言語・行動（VLA）モデル ^[2] で、視覚と言語を共通の表現に符号化したうえで、アクションエキスパートが数ステップ先までの行動チャンクを生成します。実機の制御には Real-Time Chunking（RTC）^[3] を使います。現在のチャンクを実行しながら、直前に実行したステップをクリーンなプレフィックス（ノイズのない確定済みのステップ）として書き込み、次の生成の条件にします。運用ではこのプレフィックス長を最大 9 ステップに制限しているので、後で長さ 9 と長さ 0（クリア）を比べるとき、前者がオンラインの既定値、後者が割り込み後のクリーン再生成に当たります。

前回の記事 ^[1] では、空振りの最中も視覚表現と融合表現は把持の成否を符号化し続けている（AUROC 0.88〜0.95）一方で、RTC の動作履歴プレフィックスが生成を「閉じる」方向に固定してしまうことを示し、2つの対策を仮説として挙げました。(a) 学習側で復帰の実演を足す、(b) 空振りを検知したらプレフィックスをリセットする、です。これらはまだ実機で検証されていませんでした。

現場で繰り返し見られる現象があります。1回目の閉じが空振りだと、開いてもう一度つかみ直しても失敗することが多いのです。定量的にも、どちらの対策経路もベースラインは弱く、復帰データなしの学習ベースラインでは条件付き再把持成功率は 19.2%（5/26）、実行時の介入なしの運用ベースラインでは 29.4%（5/17） にとどまります。1回目の把持が失敗すると、再把持は簡単には自己修正できません。本稿では、同じ機序が丸テーブルでの再把持の失敗も支配しているかを確かめたうえで、学習側のデータレシピと運用側の実行時検知器という2つの経路を実機に実装して検証します。

2. 再把持に固有の検証

以下の2つの対策を実機で試す前に、丸テーブルでの再把持の失敗が1回目の把持の失敗と同じプレフィックス慣性の機序に支配されているのか、それとも1回目と2回目の把持のあいだで何か別のものが壊れているのかを確かめます。再把持に固有の問いを2つ検証します。

第一に、立て直しにくいのは「失敗した1回目の閉じと再把持の閉じのあいだに、左腕がすでに成功型と失敗型の異なるモードを歩んでいるから」でしょうか。64 本の1回目失敗軌道について、1回目の閉じのピークから再把持の閉じのピークまでの左腕の 7 次元関節軌道を切り出し、再把持の成否で比べました。ラベル並べ替え検定では群間距離は極端ではなく（p≈0.53、有意でない）、一個抜き交差検証の分類精度は常に失敗と答える多数派ベースライン（約 53%）とほぼ同じでした。左腕の実行が分岐しているという仮説は支持されません。

第二に、再把持のウィンドウでは、視覚／融合プローブの AUROC は約 0.96 / 0.94 を保っており、「再把持の瞬間に知覚が崩れた」ことを支持しません。クリーンなプレフィックスを長さ 9 から 0 に縮めると、オフラインの行動チャンククリティック（オフラインで生成した行動チャンクの特徴を入力に、0〜1 の「成功しそうか」のスコアを出す浅い読み出し器）のウィンドウ集約した予測スコアは約 0.64 から約 0.75 に上がります（平均差 +0.106、対応ありの検定で p=0.00014）。プレフィックスの有無で、生成された行動から成否を読み取れる度合いは同程度です（0.858 対 0.860）。プレフィックスは読み取り可能性を消すわけではありませんが、誤った閉じを固定してしまうことはあります。クリティックのスコアはオフラインの順位付けのスコアであり、校正された成功確率ではなく、実機でグリッパーがすでにタオルをつまんでいることとも同じではありません。

一言でまとめると、再把持ウィンドウでの証拠は前回の記事と一致します。ボトルネックは依然としてプレフィックス慣性であり、知覚の崩壊でも腕の軌道の分岐でもありません。以下の2つの経路は、それぞれ学習データと実行時の介入に働きかけます。

指標の読み方と実験の範囲

• 条件付き再把持成功率： 丸テーブルでの1回目の把持がすでに失敗したエピソードのうち、2回目の把持が成功した割合。タスク全体の成功率ではありません。
• 完了時間と効率： 成功エピソードの開始・終了時刻は、カメラ映像から自動評価器が判定します（たとえばタオルが作業面に置かれたか）。完了時間、スループット、人の介入頻度はその境界から計算します。人の介入頻度は、作業者が単位時間あたりに能動的に介入した回数です（たとえばタオルを受け止める、手でリセットする）。検知器が起動するクリーン再生成（現在のチャンクを捨てて空のプレフィックスで再生成すること）とは別物です。
• 2つの経路は、それぞれの内部でしか比較できません： §3（学習側）と §4（運用側）は、別々にファインチューニングした2つのポリシーで評価しています。それぞれ自分のベースラインとだけ比べ、絶対値を経路どうしの比較として扱わないでください。主要な指標は条件付き再把持成功率と1回目把持の失敗率です。条件付き再把持は、失敗した1回目の把持を立て直せるかを測ります。1回目把持の失敗率は、学習側では同時に得られた改善であり、運用側では介入が1回目の把持を悪化させていないことの確認です。完了時間などのタスク効率の数字は、経路内での副次的な証拠です。

3. 学習側の経路：「失敗→成功」の短い実演を混ぜる

前回の記事の §7 では、「誤ったプレフィックスのもとでの復帰の実演を足す」ことをすでに提案していました。本節では、その実機での実装と結果を示します。

復帰クリップは、実機でのタオル畳みタスクの自律ロールアウトのログから取ったもので、人の遠隔操作ではありません。左グリッパーの閉じ度（関節指令の第 6 次元、約 50 Hz、1 に近いほど閉）について2つの閉じのピークに印を付け、丸テーブルでの1回目の把持が失敗し、直後の再把持が成功した軌道だけを残します。通常のファインチューニングデータは、復帰クリップを含まないベースラインと同じです。同じタスクの成功実演 2 バッチ（約 65 万フレーム）だけで、他のタスクは含みません。ベースラインに対してこのファインチューニングが足しているのは、この短いクリップだけです。

クリップは2つの閉じのピークのあいだで切り出し、エピソード全体は使いません。1回目の閉じのピーク t_peak は、左グリッパーの閉じ度が 0.95 以上になる最初の局所最大です（連続するピークは 30 フレーム以上離す）。再把持のピーク t_peak2 は、グリッパーがいったん 0.5 未満まで開いた後、次に 0.95 を超えて上がり始める最初のフレームとします。長い保持プラトー上の任意の高い点ではなく、閉じの始まりです。2つのピークの間隔が 6 秒未満の速い復帰だけを残します。切り出す閉区間はちょうど [t_peak, t_peak2] で、失敗した閉じから成功した再把持の閉じまで、それ以上は含めません。これらのクリップは約 1.7〜6 秒で、中央値は約 3.2 秒です。短いクリップには失敗した閉じとその後の修正しか含まれないため、通常の学習がその中からランダムにウィンドウを取ると、見えるのは一度も失敗しなかった畳み全体ではなく、その復帰です。

253 本の速い復帰クリップを学習に入れます。ローダーには独立した混合重みが無いので、このクリップ集合を 3 回並べ、繰り返さない通常の成功実演と連結します。フレーム数で見ると、この繰り返しの後、末尾のパディングされた開始フレームを落としたうえで、復帰クリップは混合の約 12% です。ファインチューニングはベースラインの重みから続けます。

実機 100 エピソードで、条件付き再把持成功率は 58.8%（10/17） となり、復帰データなしのベースラインの 19.2% を上回りました。失敗後に修正することを学んだと見て矛盾しません。同じ評価で、1回目把持の失敗率はベースラインの 26.0% から 17.0%（17/100） に下がりました。1回目の把持の改善と条件付き再把持の改善は、同時に得られた2つの改善です。

タスク効率では、成功エピソードの平均完了時間は 70.3 秒（ベースライン 74.7 秒）、中央値 62.2 秒（ベースライン 71.3 秒）。スループットは 32.5 枚/時（ベースライン 32.0）、介入頻度は 12.0 回/時（ベースライン 11.5、わずかに増）。丸テーブル序盤での無駄な時間が減ったことと整合します。

4. 運用側の経路：空振り検知後のクリーン再生成

前回の記事の §7 では、「空振りを検知したらプレフィックスをリセットして復帰を促す」ことも提案していました。本節では、再学習の要らない実機での介入を示します。空振りを検知したら、現在の行動チャンクを捨て、空のプレフィックスでクリーン再生成します。

4.1 ラベル付けウィンドウと検知器

グリッパーが開いた状態から閉じてタオルをつかみに行くとき、閉じ度の曲線を見ます。0 が全開、1 が全閉（正規化した関節指令）です。0 から 1 へ上がるのが閉じる動きで、開く動きではありません。オフラインのラベル付けでは、把持全体ではなく、これから閉じるがまだ割り込める区間にラベルを付けたいのです。設計目標は、注釈された失敗時刻をできるだけ覆うこと、そして「真の失敗の約 80% を報告する」動作点（再現率 ≈ 0.8）で、ある程度のリードタイムを保ちつつ誤検知を減らすことです。

実際には、閉じ度が約 0.1 を初めて超える時刻（閉じの開始、t_rise）と、閉じが終わって曲線が高いプラトーに入る時刻（t_peak、閉じのピーク）を求めます。学習用と評価用のラベルをオフラインで切り出すためのラベル付けウィンドウは [t_rise − 20, t_peak − 8]（フレーム）、すなわち閉じの開始の約 0.4 秒前から閉じのピークの約 0.16 秒前まで（約 50 Hz）です。ウィンドウの終端は閉じ切る直前に置き、始端は閉じの開始の少し前まで覆って、ラベル区間にリードタイムを含めます。より広い対照ウィンドウ [t_rise − 50, t_peak − 8] と比べて、このウィンドウは再現率 ≈0.8 の動作点で誤検知が少なくなります。オンラインではこのウィンドウをスライドさせません。検知器はポリシーの推論ごとに手首カメラの視覚特徴からスコアを出し、スコアがしきい値を超え、かつ指令チャンクがグリッパーを閉じようとしているときに、現在のチャンクを捨てて空のプレフィックスでクリーン再生成します。将来の t_peak は要りません。

検知器は、独立に収集した失敗／成功ウィンドウ（学習用約 164 本、同分布の検証用 41 本、汎化確認用に別の収集から約 100 本）で学習します。運用では手首カメラの視覚特徴に浅いヘッドを載せて使います。オンラインでの再現率と誤検知率は個別には測っていません（限界を参照）。

4.2 即時のクリーン再生成

実行時の介入なしの同一ポリシーのベースラインでは、条件付き再把持成功率は 29.4%（5/17）、1回目把持の失敗率は 17.0%（17/100） です。空振り検知器を有効にし、現在のチャンクを即座に捨てて空のプレフィックスでクリーン再生成すると、条件付き再把持成功率は 66.7%（12/18） になりました。1回目把持の失敗率は 18.0%（18/100） でベースラインと同水準で、「介入は失敗を検知した後の生成に働く」ことと整合します。

タスク効率では、成功エピソードの平均完了時間は 69.9 秒（ベースライン 73.6 秒）、中央値 64.4 秒（ベースライン 70.2 秒）。スループットは 35.7 枚/時（ベースライン 34.5）、介入頻度はどちらも 10.0 回/時。完了時間の短縮は、検知器が発火したときの割り込みと再把持で説明でき、人の介入頻度は増えていません。

5. 結果のまとめと限界

限界

• 条件付き再把持の分母は十数件の規模であることが多く、点推定は揺れます。
• 学習側では1回目把持の失敗率も下がる（26.0% → 17.0%）ため、条件付き再把持の分母となる母集団が変わります。2つの率は、完全に同質な失敗サンプルで計算したものではありません。
• プローブの成否ラベルは人の修正に依存しており、ラベルの定義はまだ揺れる余地があります。
• 空振り検知器は、別のファインチューニング済みポリシーにそのまま載せることはできません。新しいモデルには、同じ手順で学習し直した対応する検知器が要ります。
• オンラインでの検知器の再現率と誤検知率は個別には測っていません。§4 の実機の数字は、介入後のタスク結果です。

6. おわりに

前回の記事の続編として、本稿では丸テーブルで失敗した後の再把持についてプレフィックス慣性のボトルネックを再確認し、実機での2つの対策を検証しました。学習側で「失敗→成功」の短い実演を混ぜる（条件付き再把持 約 19.2% → 58.8%）、運用側で空振り検知後にクリーン再生成する（約 29.4% → 66.7%）、の2つです。2つの経路は異なる箇所に働くので、原理的には重ねられますが、重ねたときの性能はまだ実機で検証していません。

成功エピソードの完了時間も短くなり（学習側 74.7 秒 → 70.3 秒、運用側 73.6 秒 → 69.9 秒）、丸テーブル序盤での無駄な時間が減ったことと整合します。人の介入頻度は運用側で横ばい、学習側でわずかに増えました。次の段階は、2つの経路を重ねた検証と、オンラインでの検知器の再現率／誤検知率の統計です。