LOG130R2R2R2026/4/6

R2R2Rのデータ収集設計を疑った｜mechArm 270 × Unityのフェーズ2開始前に

「ログを取る」という当たり前の作業の前に、何を記録すべきかを問い直した日。

💡 Key Takeaway

「成功率を記録する」だけでは何も改善できない。失敗の種別を記録することで、初めて改善の打ち手が見える。ログは記録ではなく設計素材だ。

やろうとしたこと	実際に起きたこと	判断
CSVログ機能を追加する	「なぜこのデータが必要か」を先に問い直した	暫定リストを設計から作り直した
fail_stepを自動取得する	WiFi競合でSSH自動化が詰まった	手動入力で代替しデータ積み上げを優先した
TP-Link_9824にPiを接続する	Piのスキャンにすら見つからなかった	USB-C Ethernetアダプタを発注して次のステップに委ねた

まず「何を記録するか」を問い直した

— ログ項目のリストを見た瞬間、暫定だとわかった。

Phase 2の最初のタスクはログ機能の追加だった。最初に並べたのはこのリストだ。

日時（timestamp）
試行回数（trial number）
成功/失敗（result）
Red ratio（%）

これを見て、問いが生まれた。このデータが必要な根拠は何か。

Phase 2で答えが出なければならない問いを整理すると、3つに絞れた。このポーズ設定は再現性があるか。カメラ判定は信頼できるか。失敗はどのステップで起きるか。

3つ目の問いに対して、最初のリストは答えを出せない。成功率はわかっても、失敗の種別がわからない。Pick失敗とPlace失敗では原因がまったく違う。まとめてFAILにすると、何を改善すればいいかが見えないままになる。

fail_step を追加することにした。

timestamp, trial_number, result, fail_step, red_ratio

これで「Pick成功率 vs Place成功率」が分離できる。Phase 3でカメラによるリカバリー検出を設計するとき、今のうちに「どんな失敗が何回起きるか」を記録しておくことが、設計の根拠になる。

ログは記録じゃなくて設計素材なんだよ、という話。

fail_stepを取るには構造が必要だった

— pick_and_place_fixed.pyの現在の構造を確認すると、問題が見えた。

現在のスクリプトは、try/exceptが全体を1つで包んでいる。

try:
    Step1 〜 Step11 全部
except Exception as e:
    return False  # どこで落ちたか不明

例外が起きても「どこで落ちたか」がわからない。

解決策はシンプルだった。current_step 変数でどのフェーズにいるかを追跡して、失敗時にそれを返す。

current_step = "init"
try:
    current_step = "pick"
    # Step3〜5
    
    current_step = "place"
    # Step7〜9

except Exception as e:
    return "FAIL", current_step  # fail_stepが返せる

コードの変更量が最小で、fail_stepの粒度も十分。返り値を (result, fail_step) のタプルに変えれば、ループ側で受け取れる。

WiFi競合が、また出てきた

— fail_stepをループ側に自動で渡すには、SSHで呼び出す構造が必要だった。

r2r2r_loop.py の現在の構造を確認すると、subprocessでPiを呼んでいない。MacとPiは独立していて、人間がEnterを押すタイミングで繋がっている。

fail_stepを自動取得するには、MacからSSH経由でPiのスクリプトを呼ぶ構造が必要になる。

Mac: SSH呼び出し → Pi実行 → 返り値受け取り → ログ記録

しかしこれをやろうとすると、解決したはずのWiFi競合が戻ってくる。SSHにはElephantRobotics_APが必要で、IriunにはTP-Linkが必要で、Macはどちらか一方にしか繋げない。

TP-Link接続を試みた

— PiをTP-Linkにも繋げれば競合が解消する。コマンド1本のはずだった。

PiのターミナルからTP-Link_9824への接続を試みた。

Error: Device 'TP-LINK_9824' not found.

スキャンしてみると、Piが見えているWiFiはElephantRoboticsAPだけだった。物理的な距離か、5GHz帯の問題か。いずれにせよ、この方法は詰まった。

有線接続を選んだ

— 競合を根本から解消するには、PiとMacをEthernetで直結するしかない。

Mac（USB-C Ethernetアダプタ）→ Ethernetケーブル → Pi
Mac（WiFi: TP-Link）→ iPhone（Iriun）

この構成なら2つの通信が完全に独立する。Ethernetケーブルは家にあった。USB-C Ethernetアダプタがないだけだった。Amazonで発注した。

できることをやった

— SSH自動化はアダプタ待ち。でも動かせるものはあった。

自動化は保留にして、手動構造のままログ機能だけ追加した。

r2r2r_loop.py に2つの変更を加えた。カメラ判定の後、FAILのときだけ fail_step の入力を求めること。そしてCSVに記録すること。

最初の実装では fail_step の入力タイミングが間違っていた。pick_and_place.py の実行前に「失敗しましたか？」と聞く設計になっていたのだ。まだ実行していないのに失敗ステップを聞いている。カメラ判定後、FAIL確定のときだけ聞く順序に修正した。

# FAIL確定後にだけ聞く
else:
    fail_step_input = input("失敗したステップを入力 (pick / place / none): ").strip()
    fail_step = fail_step_input if fail_step_input in ["pick", "place"] else None
    write_log(attempt, "FAIL", fail_step, red_ratio_percent)

ループを1回回した。

[Attempt 1/3] Red ratio: 17.7% → OBJECT DETECTED ✓
📝 ログ記録: trial=1 result=SUCCESS fail_step=None red_ratio=17.7%
=== Loop Complete: SUCCESS ===

CSVを確認した。

timestamp,trial_number,result,fail_step,red_ratio
2026-04-06 18:35:56,1,SUCCESS,,17.7

データが積み上がり始めた。

Phase 2の最初の1行が書かれた。USB-C Ethernetアダプタが届いたら、SSH自動化に切り替えてデータ収集を本格化する。次のステップは「何回回せるか」だ。

※ プロジェクト名「R2R2R」は、UC Berkeley・Toyota Research Instituteの研究「Real2Render2Real」（Yu, Fu et al., 2025）の概念に触発されています。現実空間をデジタルツイン化し、仮想空間での試行から得た知見を実世界のモーター駆動へ還元する——その設計と実装過程を毎日記録しています。技術アプローチおよび目的は独自のものです。