2つの成果物、1つのネットワーク：

• 訓練チェックポイント — PyTorchの.pt（rsl_rl ActorCritic）。マイルストーンはcheckpoints/ppo_pick_rkl_dr_868.pt。
• デプロイ可能なポリシー — ONNXの.onnx。.ptからexport_onnx.pyで書き出し → exports/fr5_pick_rkl_dr.onnx、deploy/rl-policies/fr5_pick_policy.onnxとしてデプロイ。

ONNXこそが製品です：単純なMLP、入力29個の浮動小数点 → 出力7個の浮動小数点、約5万パラメータ、193KB。ブラウザデモはONNXを動かし、実機も同じONNXを動かします。.ptはその訓練可能な形にすぎません。

ループはすでに存在します：reactive_runtime.py（FairinoServoJArmControllerクラス）。IPC上ではonnxruntime（.onnxを読み込む、.ptではない — Isaac/torch不要）とFAIRINO SDKでPythonを実行します。各制御ティック（約50Hz）：

obs = observe() # 29個の数値（実機 + カメラ読み取りから） action = onnx_policy(obs) # 6関節のΔq (rad) + 1グリッパー move_to_delta(action) # q_next = GetActualJointPosDegree(1) + rad2deg(0.05·Δq) # robot.MoveJ(q_next) (M3コンベアではServoJストリーミング)

observe()は実機の読み取りから29個の数値を組み立てます：joint_pos = deg2rad(GetActualJointPosDegree(1)) − ready、joint_vel、グリッパー、YOLO(カメラ) → ハンドアイ → ベース座標系 のdetected_puck、tcp_to_puck、tcp_to_bin。

要点： ポリシーはモータ電流を出力しません。出力するのは関節位置の差分で、FAIRINOコントローラ自身のサーボループがそれをアクチュエータ信号に変換します。ポリシーは高レベルの反応的な関節プランナーです。

状態： この実機バックエンドはスタブです — 全メソッドがTODO M3（実機未到着、約1か月）。正確なSDK呼び出しはコード内に記述済み；検証用にはシミュレーションバックエンドが今日動きます。

両者は異なる役割で、補完的です：

• Isaac Sim / Isaac Lab（NVIDIA） — GPU物理 + RLの学習環境。GPU上で2,048体のロボットを並列に、完全な接触物理とドメインランダム化付きで実行。訓練できる唯一のもの（大規模並列ロールアウト） — そう、これが「NVIDIAの学習環境」です。
• FAIRINO SimMachine — ベンダー製の実FR5ファームウェアを動かすデジタルツイン（CTL v3.9.6）。1体のロボット、実コントローラ挙動、学習なし、並列なし、RTX物理なし。役割は書き出したプログラムのファームウェア精度の検証。

SimMachineでは訓練できません：並列環境なし、GPU物理なし、ドメインランダム化なし — RLは何年もかかり、そもそも学習フレームワークではなくコントローラエミュレータです。よって：Isaac=学習、SimMachine=実ファームウェアでの検証。両方使いました — Isaacで訓練し、書き出しをSimMachineで再生（誤差0.0002°）。

scripted_expert.pyは手書きの状態機械（ML不使用）：DiffIKのエンドエフェクタ経由点 — 接近 → 下降 → 把持 → 持ち上げ → 搬送 → 配置 — を関節差分に逆算。Isaac環境内で動作し約96.9%成功します。collect_demos.pyが成功エピソードごとの（観測, 行動）ペアをdemos/fr5_pick_demos.npzに記録。このバッファが教師データで、行動クローニング（bc_pretrain.py）がそれを模倣 → bc_init.pt、その後PPOが超えていきます。人による遠隔操作なし、実機データなし。

両方ともはい。仕分けは別のポリシー（ppo_sort_src.pt → fr5_sort_policy.onnx）で、32次元の観測（class_onehot(3) + tcp_to_correct_binを追加） — 29次元のピックネットワークでは文字通り動かせません。

そして今日時点で本当に弱いです：私たち自身のM2評価で約39.7%の正解仕分け。ニュアンス — ルーティングは完璧（誤仕分け0；常に正しいビンを狙う）；失敗は配置完了で、これはReverse-KL修正前にピックを抑えていた、まさにその精度の天井です。だからあなたの経験は私たちのデータと一致します。

M1の勝ちレシピ（Reverse-KLアンカー + 密な段階的配置報酬 + DRカリキュラム）を適用した再訓練が必要 → より良い新しいfr5_sort_policy.onnxへ。M2は環境・エキスパート・BC・ベースラインPPOを出荷済み；85%以上への引き上げは、ピックで既に行ったのと同じ再訓練です — まだ未実施。

2つを混同しないこと：

• 90%以上はシミュレーション研究のトラックであり、ハードウェアではありません。 訓練プログラムはすでに存在します — RTX 3060開発機上のtools/isaac_rl/train.py。作るのではなく、構造的な変更を加えて再実行（約25分）します：agents/rsl_rl_ppo_cfg.py内のより豊かな/再帰的（LSTM）アクター、加えてゴール近接カリキュラムと密な配置報酬。実機は不要。85%のM1目標を超えると収穫逓減 — だから「任意」。
• 実機の設置は別タスク（M3 / ハードウェア立ち上げ）：FairinoServoJArmControllerスタブを実装し、既存ONNXをデプロイし、実リアリティギャップを測定。質問2と7を参照。

カメラは現在スタブの2つの経路を解放します：

• 知覚入力。 今日detected_puckはシミュレーションの真値 + シミュレートしたYOLOノイズです。実機ではobserve()を次のように配線：カメラフレーム → YOLO11s（B6検出器、mAP50 0.986） → ハンドアイ変換（tools/vision/handeye.py） → ベース座標系。ハンドアイ校正はシミュレーションで0.07mmまで実証済み；実物のChArUcoボード撮影が1回必要です。
• 把持確認（最大の信頼性向上）。 confirm_grasp() — グリッパーを閉じた後、手首カメラで撮影し、物体が実際に爪の中にあるか確認し、空ならピックを再試行。これが「掴み損ねたのに気づかない」失敗モードを潰します。現在はTrue（保持と仮定）を返します。

検出器とコード経路は存在します（B6ビジョン）；実カメラ、ハンドアイ撮影、スタブ解除が必要です。

Two artifacts, one network:

• Training checkpoint — a PyTorch .pt (the rsl_rl ActorCritic). The milestone is checkpoints/ppo_pick_rkl_dr_868.pt.
• Deployable policy — an ONNX .onnx, exported from the .pt by export_onnx.py → exports/fr5_pick_rkl_dr.onnx, deployed as deploy/rl-policies/fr5_pick_policy.onnx.

The ONNX is the product: a plain MLP, 29 input floats → 7 output floats, ~50k params, 193 KB. The browser demo runs the ONNX; the real robot will run the same ONNX. The .pt is just its trainable form.

The loop already exists: reactive_runtime.py (class FairinoServoJArmController). On the IPC you run Python with onnxruntime (which loads the .onnx, not the .pt — no Isaac/torch needed) plus the FAIRINO SDK. Every control tick (~50 Hz):

obs = observe() # 29 floats, from live robot + camera reads action = onnx_policy(obs) # 6 joint Δq (rad) + 1 gripper move_to_delta(action) # q_next = GetActualJointPosDegree(1) + rad2deg(0.05·Δq) # robot.MoveJ(q_next) (ServoJ streaming for M3 conveyor)

observe() assembles the 29 numbers from real reads: joint_pos = deg2rad(GetActualJointPosDegree(1)) − ready, joint_vel, gripper, detected_puck from YOLO(camera) → hand-eye → base frame, tcp_to_puck, tcp_to_bin.

Key point: the policy does not output motor currents. It outputs joint-position deltas; the FAIRINO controller's own servo loop converts those into actuator signals. The policy is a high-level reactive joint planner.

Status: this real-robot backend is a stub — every method is marked TODO M3 (no hardware yet, ~1 month). The exact SDK calls are written in the code; the sim backend runs today for validation.

They do different jobs and are complementary:

• Isaac Sim / Isaac Lab (NVIDIA) — a GPU physics + RL learning environment. It runs 2,048 robot copies in parallel on the GPU with full contact physics and domain randomization. This is the only thing that can train (massive parallel rollouts) — yes, it's the "NVIDIA learning environment."
• FAIRINO SimMachine — the vendor's digital twin running the real FR5 firmware (CTL v3.9.6). One robot, real controller behavior, no learning, no parallelism, no RTX physics. Its job is firmware-accurate verification of exported programs.

You can't train on SimMachine: no parallel envs, no GPU physics, no domain randomization — RL would take years, and it's a controller emulator, not a learning framework. So: Isaac = learn; SimMachine = verify on real firmware. We used both — trained in Isaac, replayed exports on SimMachine (0.0002° error).

scripted_expert.py is a hand-written state machine (no ML): DiffIK end-effector waypoints — approach → descend → grasp → lift → carry → place — inverted to joint deltas. It runs inside the Isaac env and succeeds ~96.9%. collect_demos.py records every successful episode's (observation, action) pairs into demos/fr5_pick_demos.npz. That buffer is the teacher data; behavior cloning (bc_pretrain.py) imitates it → bc_init.pt, then PPO improves past it. No human teleoperation, no real-robot data.

Yes to both. Sort is a separate policy (ppo_sort_src.pt → fr5_sort_policy.onnx) with a 32-dim observation (adds class_onehot(3) + tcp_to_correct_bin) — the 29-dim pick network literally cannot run it.

And it is genuinely weak today: ~39.7% correct-sort in our own M2 eval. The nuance — routing is perfect (0 mis-sorts; it always aims at the right bin); the failure is place-completion, the exact precision ceiling that capped pick before the Reverse-KL fix. So your experience matches our data.

It needs a retrain applying the M1 winning recipe (Reverse-KL anchor + dense graded-placement reward + DR curriculum) → a new, better fr5_sort_policy.onnx. M2 shipped the env, expert, BC, and a baseline PPO; lifting it to ≥85% is the same retrain we already did for pick — not yet done.

Don't conflate two things:

• ≥90% is a simulation research track, not hardware. The training program already exists — tools/isaac_rl/train.py on the RTX 3060 dev box. You don't create it; you re-run it (~25 min) with a structural change: a richer/recurrent (LSTM) actor in agents/rsl_rl_ppo_cfg.py, plus a goal-proximal curriculum and a dense place reward. No physical machine required. It's diminishing returns past the 85% M1 target — hence "optional."
• Setting up the actual machine is a different task (M3 / hardware bring-up): wire the FairinoServoJArmController stub, deploy the existing ONNX, measure the real reality-gap. See questions 2 and 7.

The camera unlocks two currently-stubbed paths:

• Perception input. Today detected_puck is sim ground-truth plus simulated YOLO noise. On hardware, wire observe() to: camera frame → YOLO11s (the B6 detector, mAP50 0.986) → hand-eye transform (tools/vision/handeye.py) → base frame. Hand-eye calibration is already proven in sim to 0.07 mm; it needs one real ChArUco-board capture.
• Grasp confirmation (the biggest reliability win). confirm_grasp() — after closing the gripper, capture the wrist cam, verify the object is actually in the jaws, and retry the pick if empty. This kills the "failed to pick, didn't notice" failure mode. It currently returns True (assume held).

The detector and the code paths exist (B6 vision); they need the real camera, the hand-eye capture, and un-stubbing.