# R2R2R の考え方を π0.5 に活かす計画：敵対的検証報告

検証日：2026-11-07／検証者：Codex

**総合判定：❌ 計画のまま実機で段階0を始めることは勧めない。位置の違うお手本を増やす仮説は残るが、それが現在の主原因だという証拠は不足している。評価位置・無補正の定義・既存コードの危険箇所・評価用の未学習位置を先に確定する。** 学習をせず現状を測る方針自体は妥当。ただし、まず記録と安全条件を整えた小規模な基準測定にする。

## 検証範囲と読み方

以下で `D` は `/Volumes/KIOXIA/r2r2r-data/`、`S` は `/Users/shimazueiichi/r2r2r-scripts/`、`P` はこのフォルダの親 `PixelstoMotors/` を表す。行番号は今回読んだ現行ファイルの1始まり。JSON・NPZの全件集計は、ファイル名とキー・配列を証拠とし、再現用スクリプトと結果を `_codex_tmp_20261107/` に残した。

書き込みは本報告と指定一時フォルダだけ。対象コードの実行・インポート、学習、実機接続、daemon、SSH、シリアル、gitコマンドは実行していない。禁止された鍵・トークンファイルは開いていない。SSD全体の内容検索は行わず、必要なディレクトリに限定した。履歴は `.git/logs/HEAD` をテキストとして読んだもので、完全な `git log` の代わりとは扱っていない。

主な実行コマンド：

```sh
python3 _codex_tmp_20261107/audit.py
python3 _codex_tmp_20261107/further.py > _codex_tmp_20261107/further.txt
python3 _codex_tmp_20261107/metrics.py > _codex_tmp_20261107/metrics.txt
python3 _codex_tmp_20261107/statistics.py > _codex_tmp_20261107/statistics.txt
```

これらは対象のJSON・NPZ・CSV・画像を読み、一時フォルダにだけ集計・画像を書き出す。集計結果は `summary.json`、`episodes.json`、`runs.json`、`teach.json`、`grid.json`、`recording_metadata.json`。PDFはmacOSのPDFKitで全文抽出し、12・13ページを画像化して目視照合した（`pdftext.swift`、`render.swift`、`paper.txt`、`paper_page_12.png`、`paper_page_13.png`）。画像の一覧は `contact.jpg`、失敗動画の抽出一覧は `video_checks.json` と `failures_0.jpg`・`failures_6.jpg`。

本報告は「手元の記録から何が言えるか」の検証であり、実機の到達性・衝突回避を保証する試験ではない。記録にない原因を推定だけで確定しない。

## A1. 今の手元の値

**⚠️ 要注意：本数などは合うが、「補正11本がすべてゲームパッド」は誤り。記録10Hzと実測10Hzも区別が必要。**

| 項目 | 独立確認の結果 | 判定と証拠 |
|---|---|---|
| 最新データの本数・コマ | 30本、状態4,301行・行動4,301行・JPEG4,301枚。教示19本2,717行、補正入り11本1,584行。補正430行 | ✅ OK。`audit.py` で各 `raw_episodes/*/episode.npz` を開いて配列長を集計。`further.py` で全4,301枚を復号し、全枚216×384×3。README 8–13行とも一致 |
| 補正11本の由来 | 7本は従来の補正、ゲームパッドを記録したものは4本。11本はモデルの動きも含む | ❌ NG。`runs.json` と各試行 `log.jsonl` の補正受理イベントを照合。2026-10-31の4本と11-01の3本には `pad` 行がなく、11-06の4本には順に26・26・19・16行ある。「教示19本＋人の補正入り11本（うちゲームパッド4本）」へ修正 |
| 教えた位置 | 異なる教示ファイル5種類、採用本数1・5・4・5・4 | ✅ OK。ただし正確な物理位置5点の検証とは別。19試行の試行JSON `teach.file`・`teach.waypoints` を独立集計（`teach.json`）。`D/runs/experiments/record_teach_demo/20261019_LOG352/README.md` 10–16行と一致 |
| 画像・カメラ | 上カメラ1系統。学習JPEGは384×216。全30本のメタデータは10Hz | ✅ OK（保存形式として）。全件集計と `S/pi05/openpi_addon/mecharm_policy.py` 4–6、42–55行で有効な画像入力を確認 |
| 実際の観測頻度 | 10Hzの独立した実測画像・角度が毎回あるわけではない | ⚠️ 要注意。LOG352 README 36行は角度実測約1.6〜2Hz。例えば11-06 18:55:54の `recording/top_meta.json` は目標10Hzに対し有効8.249fps、角度8.51Hz。補間・同一画像の再使用を含む学習上の10Hzと区別する |
| 状態・行動 | 7次元、関節6軸＋爪。最新30本では末尾を除いて行動が次の状態と一致 | ✅ OK（生データの定義）。全30本のNPZで数値比較、全件一致。`S/pi05/build_demo_episodes.py` 324–325行。ただし学習時は関節6軸をチャンク先頭状態との差分に変える（後述B4） |
| 指示 | 全30本同じ、赤ブロックを白箱に入れる指示 | ✅ OK。全30個の `meta.json` の `task` を集合化し1種類 |
| 最新モデル | `pi05_mecharm_trim_corr_lora_v3/1499` が存在。学習1,500ステップ。3.13時間はGPUを借りた時間 | ✅ OK（保存と実行記録の範囲）。現存ファイルは由来JSONを含め36個・6,335,852,509バイト。由来JSON3,883バイトを除くと35個・6,335,848,626バイトでログと一致。`D/lab/Log22/train/lab_train_20261106_195143.txt` 606、613–615、630、637–644行。約292円はログ記載の換算見積りで請求明細の検証ではない |
| scripted_v1 | 索引35件中採用20件、実在エピソード20本・6,298コマ | ✅ OK。`index.json` の `used` を集計し実フォルダ・NPZと照合。不採用15件は、把持成功・配置失敗6件、把持成功・配置未判定4件、両方失敗3件、両方未判定2件。「15件すべて物理失敗」ではない |
| scripted_v1の爪ラベル | 開くラベルが約2秒先行する設計が現行コードにも残る | ⚠️ 要注意。注記 `KNOWN_ISSUE_gripper_open_label_2sec_early.md` 7–46行と本線 `run_pick_place.py` 2273–2280、2317–2323行。各動画の全開放イベントを測った結果ではなく、通知順とdaemon待ちに基づく既知問題 |
| FK表 | 1,705,187行。関節6軸と爪先3座標 | ✅ OK（表の構造）。CSVを1回読み込んで件数・列を確認し一時NPYに保持。生成由来・精度はA3参照 |

## A2. 「主原因は置き場所不足」か

**❌ NG：主原因として確定できない。位置と成功率の関係を検証できる記録が不足している。**

`D/runs/pi05_policy/` の実フォルダ130件を調査した。試行要約JSONは36件、把持・配置の人判定が両方あるのは31件。内訳は両方成功19件、両方失敗12件。残る99件は両方の判定が揃わず、失敗と数えられない。全ログのイベントは推論985行、画角確認100行、補正479行、ゲームパッド162行など。要約JSONの最上位キーとログのキーには、ブロックの実測初期座標・格子番号がなかった。画像中に位置情報はあるが、今回それを校正して130件の物理座標に変換してはいない。

成功19件中17件には補正回数が記録されている。補正・巻き戻し0件で成功しているのは `pi05_20261030_184245` と `pi05_20261031_185246` の2件。したがって19/31を「無補正成功率」とは呼べない。また、最新11-06の9試行はv2で、成功5件・失敗4件、全件に補正がある。v3はその日の22時台に保存されており、今回の試行群にはv3のモデル名がない。最新モデルで同じ症状が残るか自体が未測定である。

失敗12件の人判定はすべて把持も配置も失敗。ただしこれは「最初からつかめなかった12件」と同義ではない。例えば `pi05_20261106_184312/...json` 99–109行は両方失敗だが、同試行 `log.jsonl` 11行には閉じる命令がある。閉じる命令は把持成功の証拠ではない。`pi05_20261101_194042/log.jsonl` 13・15行には締め直し補正もある。把持不良・保持不良の両方を疑う余地がある。

録画あり36件の `top_meta.json` も読んだ。失敗12本の動画から各25%・50%・90%の計36枚を復号・目視確認した。ブロックが爪付近にある途中画像、爪から離れてマットにある画像、箱のそばまで腕が動いている画像が混在する。上からの静止画では高さ・保持力・落下瞬間が分からず、疎な抽出なので「つかむ前／つかんだ後」の件数は確定しない。全動画の連続再生・全イベントへの時刻対応までは行っていない。この限界を残して、位置だけの原因にまとめない。

2026-10-17の見立ては旧scripted系19本に対するもの。`P/デジタルツイン学習R2R2R/フィジカルAI研究室を作る/LOG348_article.md` 424–447、622–664行には、同じ置き場所でも爪が奥へずれること、学習回数を増やしても改善しないこと、夕方と夜の見え方の比較がある。これは位置不足の仮説を支持しても、現在の教示5位置＋補正入りモデルにそのまま適用できる因果証拠ではない。

**順番の修正：** v3の同一既知位置で再現性を先に測り、初期ブロック座標・箱座標・物体の見え方・閉じる時刻・持ち上げ後の保持・落下・接触を記録する。同じ位置でも失敗するなら、画角、実測と入力状態の差、爪タイミング、指令制限を先に疑う。既知位置が安定して近傍だけ落ちる場合に位置の拡張を主実験にする。

## A3. FK表の由来と実機との差

**⚠️ 要注意：Unity由来という理解は支持される。ただし「実機との差が一律何mm」とは言えない。**

`P/site_archive/code/r2r2r-content/articles/DAY177_article.md` 266–280行にはUnityのFK→CSV→実機という由来がある。計画の「LOG177」に対応する手元資料はこのDAY177の記事写しだった。CSVだけには生成来歴がなく、この写しから現在のv2全行の生成過程まで追跡できたわけではない。

この記事13行は約40mmのオフセットを述べるが、214–250行では肩120°などの命令を送り「下がらない」ことを根拠にしている。LOG352で分かった肩88°超の命令破棄が交絡する。**この記事だけで40mmを純粋なFK誤差の確定値とするのは不適切。**

近傍の `DAY179_article.md` 97–105行はFK予測と視覚実測の水平差54.5mm、124–136行は43.1mm、補正後のブロックとの距離13.5mmを記録している。こちらも当時の命令は肩110°・98°などで、現在の安全条件を満たす精密な校正試験ではない。視覚検出・命令未到達・座標原点の差を含む観測として扱う。

`D/diag/correction_memory.json` は38セル。保存補正ベクトルの大きさは中央値8.81mm、最大158.51mm。例は同ファイル12–15行のほぼZ方向−23.98mm、37–45行の約44.9mmと158.5mm。これは学習された補正値で、残差分布・FKの測定誤差ではない。現行本線1489–1498行では読み出した補正を上限処理して目標から引いている。保存された最大値がそのまま動作に使われるとも限らない。

直し方：Unity表は候補姿勢を探す道具と明記する。安全な命令範囲で「送った角度・到達実測角・視覚の爪先位置」を揃えて誤差を取り直し、それまでは補正記憶をそのまま案Bへ流用しない。

## A4. scriptedからteachへ切り替えた理由と案A

**❌ NG：案Aの「新しいコードがほぼ不要」は、前の詰まりを解消した説明になっていない。**

LOG348記事654–688行は、スクリプトで成功データが集まる範囲が狭いこと、外側ではつかめずデータが作れないことを述べ、手で要所を教えて再生する方針に移っている。これとは別に爪ラベル約2秒先行の問題もある。`D/lab/Log10/README.md` は教示19本へ切り替え、旧モデルの続きではなく基盤モデルから学習し直した記録。実験READMEは肩超過・動作中の爪・検出誤りも示す。

履歴はgitコマンドを避け `S/.git/logs/HEAD` を直接読んだ。94–103行にはデモ記録導入、記録中のPLACE高さ記憶更新停止、肩安全制限・データ検査追加が並ぶ。ここには切替理由を直接確定する記述はなく、記事と実験記録を主証拠とした。

案Aは同じスクリプトで9位置に置くだけなら、狭い成功範囲という選択の偏りを再現する。新位置ごとの撮影・検出・到達・把持・配置を先に確かめ、失敗や不明を除外する必要がある。さらに通知順の修正または映像と対応した派生ラベル生成が必要。単に全試行へ2秒を足してはいけない（既知問題の注記64–73行は2回開放時の曖昧さを指摘）。

## A5. 論文メモの数字

**✅ OK（数字の転記）。⚠️ 要注意（適用範囲と原論文内の不整合）。**

ローカル原文PDFの12・13ページを抽出し、ページ画像でも表3〜5を確認した。メモ58–60行と照合：

| 条件 | PDFの結果 |
|---|---|
| 動きを作り直す処理を外す、生成1,000本 | π0-FAST 80.0→0.0%、Diffusion Policy 53.3→6.7% |
| 背景・机の変更を強める、各1,000本 | π0-FAST 73.3→35.3%、Diffusion Policy 53.3→33.3% |
| 実150本・生成1,000本・両方 | π0-FAST 73.3／80.0／73.3%、Diffusion Policy 40.0／53.3／86.7% |

35.3%は原文にもあるためメモの転記ミスではない。ただし表4の説明は15試行で、35.3%は15回の単純成功率の刻みに合わない。原文だけで理由は分からない。表5本文はπ0-FASTの単独生成と混合を同程度と述べる一方、表の単独生成は80.0%、混合73.3%。厳密には「混ぜれば良くなる」は支持されない。

対象はマグをコーヒーメーカーに置く課題で、mechArmでもπ0.5でもない。位置への適応が重要という着想は使えるが、現在の主原因が位置不足であることや57本で改善することの根拠にはならない。

## B1. 3×3の到達性とカメラ

**❌ NG：計画には9位置の座標・間隔・高さがなく、実機で全部届くとは判定できない。以下は候補表の存在を調べた計算である。**

CSV全1,705,187行のうち、肩j1≤88°は1,158,083行。さらに本線 `fk_lookup.py` 83–86行のPICK高さ帯10〜40mmに絞ると165,345行。表の座標はUnityのメートルで、水平はX・Z、高さはY。安全候補の水平外接範囲はX −325.824〜305.350mm、Z −110.343〜335.988mm。ただし外接長方形内部がすべて届くという意味ではない。

検証用にX={140,180,220}mm、Z={180,220,260}mmの候補格子を置き、高さ帯と肩制限を満たす行から水平最近傍を選んだ。指定されていない格子をこちらで仮定したもので、計画の確定位置ではない。

| X mm | Z mm | 表内の水平残差 mm | 表の高さY mm | 肩j1 ° | CSV行 |
|---:|---:|---:|---:|---:|---:|
|140|180|0.015|16.095|59.89|1349473|
|140|220|0.450|29.526|72.39|1522701|
|140|260|3.075|23.863|88.00|720323|
|180|180|0.083|24.237|67.39|1529590|
|180|220|0.094|38.110|77.39|1642941|
|180|260|0.419|30.868|87.74|19031|
|220|180|0.236|38.109|77.39|1530094|
|220|220|3.837|27.959|87.74|19066|
|220|260|16.688|36.133|87.74|16582|

最外点は16.7mm残る。表内誤差に実機誤差が加わり、高さも16〜38mmと一定でない。この検索は爪の向き・開口・腕の経路・衝突を条件に入れていない。本線の既定距離許容は45mm（`fk_lookup.py` 85行）で、候補が返ることと小さいブロックを挟めることは別である。

少し内側のX={120,160,200}、Z={180,220,260}mmなら、同じ検索の残差は全点0.23〜3.69mmになる。実機確認の候補としてはこちらがましだが、実機で届く証明ではない。全関節・爪姿勢・上空姿勢と経路を含めて確かめ、合わない点を除いて不規則な9位置にしてもよい。

視認性は教示5位置の各先頭画像を目視確認（`contact.jpg`）。位置1〜4ではブロックと箱が見え、位置5はブロックが腕・爪の陰にほぼ隠れる。LOG352記事14593行とも一致する。箱も動作中には腕で隠れる。未設置の9点全部が見える証拠はない。位置の採否はカメラ画像384×216で行い、物理到達性とは別に確認する。大きな格子印は新たな画像の違いにもなるため、初回基準測定から同じ印・照明・画角を使う。

## B2. 案A・B・Cの実装と危険箇所

**⚠️ 要注意：既存部品は使えるが、どの案もそのまま27本収集へ進めない。特にBは姿勢の連続性と静止確認が不足。**

| 案 | 使える部分 | 必要な追加・修正 |
|---|---|---|
| A | `S/dynamic_tracking_limits/place/place_modules/run_pick_place.py` の検出・lookup・視覚補正・記録、`pi05/build_demo_episodes.py` の変換 | A4の成功範囲の確認、爪通知と画像の同期修正、採否の確定。補正記憶・高さ記憶の状態を試行ごとに固定・記録し、モデル比較中に変化させない |
| B | 教示JSONの要所抽出、`record_teach_demo.py` の再生・到達記録・撮影、`fk_lookup.py` の制約付き検索 | 教示の関節→爪先推定、物体位置の差分変換、姿勢を保つ候補選択、全区間の経路確認、範囲外の拒否、書き換えた要所を再生器へ渡す入力形式、位置別の実機調整が必要。既存表の最近傍検索だけでは足りない |
| C | `run_policy_client.py` のゲームパッド補正と記録、`build_correction_episodes.py` の変換 | HOMEからの全行程を確実に記録できる操作手順・位置ID・初期状態の統一。現行はモデルと人の区間が混じる設計なので、人だけの全行程取得を事前確認。新位置の安全範囲を既存データ由来のまま制限しない |

Bの具体的な穴：

- 肩88°制限は既存lookupの候補除外で利用できる（`fk_lookup.py` 161–166行）。しかし教示再生の基礎 `waypoint_replay.py` 96–103行の肩上限は123°であり、同じガードではない。作った全要所・中間目標に88°制限を明示的に適用する必要がある。88°へ切り詰めるだけでは位置が変わるので不適合を返す。
- XYZだけ一致しても爪の向きは決まらない。元の関節に近い枝・爪姿勢・降下方向を保つ制約が必要。持ち上げ要所もPICKの移動に追従させ、固定した箱のPLACEへは安全な上空でつなぐ。全行程の平行移動は箱の目標までずらしてしまう。
- 再生器の爪前静止確認は安全停止を保証しない。`record_teach_demo.py` 2855–2868行は最大待ち後、確認できなくても警告だけで爪を動かす。未到達でも進む運用があるので、案Bに流用するなら「静止未確認時は人の確認まで次へ進まない」扱いが必要。
- 同ファイル2830–2854行では爪通知を呼び出し後へ変更済みだが、開放の自動読取り確認は取りやめ、人が判断する方針。データセットの旧注記82–84行の自動確認説明は現行コードと食い違う。古い説明だけを見て安全機能があると扱わない。
- 補正記憶は本線の狙い座標へ適用する設計（本線1489–1498行）で、教示再生器へ自動で効くものではない。FK表の系統誤差と、姿勢を変えたBの誤差が同じとも限らない。まず1位置1動作を実測し、補正の妥当性を判断する。

## B3. 動きの癖が違うデータの混合

**⚠️ 要注意：時間処理を揃えず混ぜる比較では、置き場所の効果を分離できない。**

NPZから各エピソードの数値を計算し、下表はその中央値。停止率は隣接状態の最大関節変化が0.1°未満（10Hz換算1°/秒未満）。速度も6関節中最大の差を10倍した値であり、爪先の速度ではない。補間・停止除去後の学習時系列の比較で、実機の真の速度とは区別する。

| データ | 本数 | 長さ 秒 | 停止率 | 速度中央値 °/秒 | 速度90%点 °/秒 | 閉じる／開く時刻 秒 |
|---|---:|---:|---:|---:|---:|---|
| scripted_v1 |20|28.8|25.9%|6.57|32.74|8.2／18.4|
| teach_v1（途中停止除去前） |19|20.8|37.3%|12.74|29.48|7.8／16.6|
| 最新データの教示部分 |19|14.0|7.6%|17.52|30.09|4.9／10.9|
| 最新データの補正入り部分（全体） |11|13.5|14.0%|12.40|30.00|5.4／12.0|
| うち従来補正の試行 |7|12.6|17.1%|12.43|30.00|5.0／11.4|
| うちゲームパッド補正の試行 |4|18.3|6.1%|11.47|31.87|6.15／14.55|

証拠：`audit.py`・`metrics.py`・`statistics.py`、全対象NPZ。閉開時刻は最初の閉じる切替とその後の開く切替で、元撮影時刻ではない。補正入り11本は7本の従来補正と4本のゲームパッドを合わせたもの。最後の2行も各試行のモデル区間を含むため、人が操作した区間だけの速度比較ではない。4本の違いは位置・撮影日・停止処理とも交絡し、操作方法の因果効果を示さない。

同じ画像・状態の近くで、停止／移動／爪命令が異なる教師が混じると学習目標がばらつく。とくにscriptedの開く時刻は既知の誤ラベルを含む。元のteach19本も停止処理で3,949→2,717コマへ変わっている。したがって「スクリプト由来だから迷う」とは断定せず、まず同期・停止除去・速度・爪の待機条件を統一する。案別に保存し、同じ位置で少数を比較してから混ぜる。単なる30本＋27本ではなくフレーム数と位置ごとの寄与も管理する。

## B4. 正規化

**❌ NG：「平均とばらつきを作り直すか決める」だけでは不十分。現行は分位点による正規化で、行動は差分化後に集計する。**

コード上の経路：

1. `S/pi05/convert_to_lerobot.py` 55–64行は絶対状態・絶対行動をLeRobotへ移す。ここではopenpi用の正規化値を計算しない。
2. `S/pi05/openpi_addon/install_addon.py` 47–56行が関節6軸だけチャンク先頭状態との差分へ変える。爪は絶対値のまま。行動の正規化値を生の絶対角だけから計算してはいけない。
3. `/Users/shimazueiichi/openpi/scripts/compute_norm_stats.py` 89–113行がデータ変換後の状態・行動から統計を作り、設定のassetsとrepo_idの下へ保存する。既存手順 `S/pi05/RUNPOD_TRAIN.md` 103–113行にも計算コマンドがある。
4. ローカルopenpi `training/config.py` 179–195行で読み込み、π0以外は分位点を使う。`training/data_loader.py` 172–188行が学習時に適用、`training/checkpoints.py` 74–76行がチェックポイントassetsへ保存する。
5. `policies/policy_config.py` 59–64、80–86行は推論時にチェックポイントの統計を読み、入力正規化と出力の逆変換に使う。

現行v5の準備スクリプトは再計算しない。`pod_prep_trim_corr.sh` 48–59、89–95行でv2の値をコピーしSHAを固定する。今回v3現物の `1499/assets/local/mecharm_redblock_box_teach_v1_trim2_corr_v5/norm_stats.json` のSHA256は `80346837eb12ffa6e683416f0fa41a196519fa8459d1f0b666b06cd621c7f61b` で、スクリプトの固定値と一致した。

分位点の式は `transforms.py` 141–145行。範囲外は±1を超えるが、ここではクリップされない。したがって「範囲を広げると正規化で必ず切り捨てられる」は誤り。例として状態j0の下上分位点は−61.626°・44.620°で、60°は約1.29になる。爪や速度の変化も、差分行動の分布を変える。

一方、推論クライアント `run_policy_client.py` 182–195、248行以降には学習データの関節範囲＋余裕による指令制限が別にある。こちらは実際に目標を制限する。位置を広げたのに古い `--raw-dir` を使うと、正規化以前に動けない可能性がある。安全範囲と正規化は別々に比較・記録する。

提案：最初の小規模追加では旧統計を維持して継続学習との座標対応を保ち、新データの正規化後の外れ量を診断する。大きく外れる場合だけ、正しい変換経路で統計を再計算する別実験にする。統計だけ差し替えると入力・出力の意味が変わるため、学習と推論で同じ統計を必ず同梱し、再学習して比較する。ローカルopenpiはコード確認用であり、遠隔GPUの現行実装を再実行して確認したものではない。

## B5. 9位置×3回で差を言えるか

**❌ NG：予備的な故障分布を見る回数としては使えるが、任意の改善を判定できる設計ではない。後から合格数を決める点も修正が必要。**

二項比率の95% Wilson区間をPythonの標準数式で計算した。1位置3回で0成功でも真の成功率の区間は0〜56.1%、3成功でも43.9〜100%。全27回を独立な同一分布と仮定しても、14/27の区間は34.0〜69.3%。位置ごとの成功率が違い同じ日に連続すると、単純な27回合算の仮定にも注意がいる。大きな差なら27回でも検出できる場合はあるが、「明らかに増えた」の保証にはならない。

必要数は期待差による。両側有意水準5%・検出力80%・独立した2群・同数、通常の正規近似なら次の目安になる（端数切上げ、連続性補正なし）。

| 想定成功率の差 | 各モデルに必要な回数 | 9位置へ均等割りする目安 |
|---|---:|---:|
|20%→50%|39|各位置5回＝45|
|50%→70%|93|各位置11回＝99|
|50%→60%|388|各位置44回＝396|

計算式：平均率をm、差をdとして、各群n＝｛1.96√[2m(1−m)]＋0.842√[p0(1−p0)＋p1(1−p1)]｝²/d²。これは全体率の目安で、各位置別に同じ差を言いたいなら位置ごとに必要。格子内の繰り返しや対応ありの比較には別の検出力設計を使う。

**評価漏れもある。** 段階0と学習収集を同じ9点にすると、その9点は学習済み位置になる。段階3だけに足す3点には学習前の基準値がない。未学習位置での改善を主張するなら、この3点も学習前から測り、収集から外す。先に主評価・最小限意味のある差・回数・中止条件を定める。古いモデルと新モデルの順を日・位置の中で交互または無作為にし、補正なしで同じ安全設定を使う。途中で結果を見て合格線を変えない。

## B6. FKで箱の縁を見る処理

**⚠️ 要注意：記録専用としては入れられるが、今ある位置→関節の検索器を逆向きに使うだけでは不十分。**

挿入候補は `S/pi05/run_policy_client.py` 1283行の推論配列取得後と、1289–1298行の中継点計画・記録生成後。生の全チャンクと、制限後に実際に送る中継点を両方記録する。さらに実測現在角から最初の点までと、各送信点間の経路も対象にする。現行のaction horizonは10コマ＝1秒（`install_addon.py` 76行）で、計画の「数十コマ」は現設定とは違う。

`fk_lookup.py` は位置から関節を探す器である。任意の6関節から爪先を返す評価器は別に要る。表を逆検索するなら関節空間での近さ・範囲外判定・推定不確実性を記録し、表にない動作を安全とみなさない。できればURDFの連続FKで評価し、実機の爪先・保持ブロックまでの変換を校正する。

箱の水平位置は上画像の白箱検出＋保存homographyから得られる。既存の `D/mecharm_calibration/teach_poses_LOG352/measure_*.json` に `box_xz_m` とhomographyがあるが、README 38–39行は箱検出の不安定さを認める。古い値を現在の真値として使わない。箱の外周・向き・縁高さ・ブロック寸法・座標原点を測定して保存する必要がある。上カメラの平面変換だけで縁の高さは測れない。本線コメントの箱高さ43mm（92–94行）は参考値で、今回の再測定ではない。

また `fk_lookup.py` 87–92行には、爪先が105.3mmでも前腕が箱に当たった記録がある。爪先だけ高いことは衝突回避の証明にならない。保持ブロック・爪・前腕を含めた形状と余裕が必要。段階4は最初は警告候補の記録に限定し、停止・安全保証と結びつけない。

## C1. より安く効く可能性のある方法

**⚠️ 要注意：ブロックだけの切り貼りは、正しい関節角を作らない。**

画像中のブロックだけを動かし元の行動を付けると、ブロックが移動したのに腕は元の場所へ向かう教師になる。掴んだ後のブロック・爪の重なりや箱への軌道も破綻する。画像の切り貼りだけで新しい位置の実演を増やしたとは扱わない。行動を作り直すなら結局、校正されたFK・姿勢制約・接触段階に応じた物体と腕の整合・実機確認が必要で、安い画像編集だけでは済まない。

優先する対案は以下。

1. **記録済みデータの同期と実行条件を確認する。** 爪時刻・停止の長さ・目標状態を入力する設定と実測のずれ・クランプ量・カメラの写り方を点検する。9位置を増やす前に既知位置での失敗原因を小さく切り分ける。
2. **教示A案の狭さを再現しない収集をする。** 視認でき、実機で人が合わせられる近傍位置を2〜3点だけ増やし、既存の教示再生＋必要時の人の調整で質の揃った少数デモを取る。案Bの全自動化はこの効果が出てから投資する。
3. **見た目だけの軽い拡張は位置拡張と分ける。** 明るさ・色・センサー雑音の弱い変化、または画像全体の小さな平行移動なら、物体と腕の相対配置を維持できる。行動ラベルを変えずにカメラの見え方への頑健性を試す用途に限る。大きなクロップ・回転で必要物体が消えるものは除外し、物理位置の一般化の証拠とはしない。
4. **補正の多い状態へ絞って収集する。** 無補正試行のどの段階で外れるかを記録し、その直前状態からの回復を人が示す。新しい場所だけでなく保持・配置のデータが必要な場合にも対応できる。評価時の人の補正は成功へ混ぜない。

これらの費用対効果は今回の実測結果ではなく、実装量と既存の問題に基づく提案である。

## C2. 段階の順番

**❌ NG：現状のまま0→大量収集→学習では、原因と改善を分離しにくい。**

推奨順序は次のとおり。

1. データとモデルの由来を固定し、v3のチェックポイント・正規化SHA・クライアント設定・カメラ配置・補正記憶を記録する。初期座標、保持確認、失敗段階、補正の有無の記録欄を用意する。
2. 視認性と安全な実機到達を人が確認した既知位置で、v3を少数回、補正なしで測る。動作中の爪や未到達時の継続を収集器から持ち込まない。
3. 学習用の位置と未学習の評価位置を先に分け、両方で学習前を測る。27回は予備測定と位置づけ、主評価の回数と合格条件を事前に決める。
4. 失敗が位置依存なら2〜3の新位置で教示・人の調整を使って少数データを取る。原因が保持・箱付近なら、その部分の記録と実行条件を先に直す。
5. 時間処理と統計を揃えて小規模学習を比較する。改善がなければ自動生成27本へ拡大しない。案A・Bは採用率・手直し時間・ラベル品質でも比較する。
6. 旧新モデルを同じ未学習位置・同じ条件で評価する。FKによる箱接近の記録は並行開発できるが、測定前から安全保証には使わない。

## 最終回答

### 1. このまま段階0に進んでよいか

**❌ このままの27回の実機実行は勧めない。** 9位置の座標・実機到達・視認性と、比較する設定が未定。既知位置で最新v3の無補正試行を少数確認する、という修正版の段階0にする。今回の読み取り検証では実機を動かしていない。

### 2. 進む前に直すべき項目（優先順）

1. **実行の安全条件と記録**：肩88°、静止未確認時の爪命令、未到達継続、物体が見えない位置を扱う。モデルv3・実測／目標入力・指令制限・補正なしの定義を固定する。
2. **原因を断定しない**：位置不足は仮説へ戻し、既知位置でも失敗するかと、保持・配置段階を分けて測る。31件の判定と19件の成功を無補正成功率に流用しない。
3. **評価設計**：学習用と未学習評価用の位置を先に分け、追加3位置も学習前から測る。効果の大きさ・必要数・合格条件を事前に決める。
4. **データの説明と同期**：補正入り11本のうちゲームパッドは4本へ訂正。scriptedの爪ラベルを直す前に混ぜない。停止除去と時間軸を統一する。
5. **正規化と安全範囲**：分位点・差分行動の統計、固定SHA、推論assets、`--raw-dir`による指令制限を一組で管理する。
6. **案Bと段階4の過大評価を直す**：FK候補があることを到達・把持・衝突回避と同一視しない。連続姿勢、箱の形状、実機校正を追加する。

### 3. 対案の要点

**まずv3の既知位置で失敗を分解し、見える・届く少数の新位置で、品質を揃えた教示と人の調整を足して比較する。効果が見えたところで自動収集を広げる。** ブロックだけの画像編集で行動を据え置く方法は採らない。描画環境を作るより先に、同期・視認性・実行条件・評価の穴を塞ぐ方が今回の記録には合っている。