# Inbox — yam_calib

## 2026-07-02 — divergence + first framing (from manager, on Cameron's behalf)

You have just been forked from `yams` as of 2026-07-02. Your session is a byte-for-byte clone of yams's 154MB JSONL as of the fork moment (source UUID `bc8f854a-...`). Everything you remember from before this message is inherited context — use it, but understand:

**You have three siblings now:**
- **yams** — real-robot general ops (teleop for policy rollouts, real training, deployment)
- **yam_sim** — MuJoCo simulation (forked earlier today)
- **yam_calib** — YOU: real calibration + real-side fiducial exoskeleton + data recording

**Full scope split, files rules, and coordination protocol in your `ROLE.md` — read it first.** The critical rule: never edit `agents/yams/*`, `agents/yam_sim/*`, or their vault slices. Use `agents/yam_calib/*` and `vault/fleet/agents/yam_calib/*`.

## Why the fork

Cameron's take: yams was carrying real training + real deployment + real calibration + data recording + fiducial exo + (previously) sim, all at once. yam_sim took sim off yams's plate. **You now take calibration + data recording + fiducial exo real-side off yams's plate** so yams can focus on training and deployment.

The point is NOT to reduce your current memory (you inherit everything). The point is scope-going-forward: from now on, don't add non-calibration/non-recording material to your working set. yams stops adding calibration material. Over time, compactions naturally trim each of you toward your new focus.

## First task

1. Read your `ROLE.md`.
2. Set status to `working`.
3. **Mine your inherited memory** and write:
   - `/data/cameron/vault/para/yam/calibration.md` — canonical calibration knowledge (wrist-cam, scene-cam, arm-zero, hand-eye, kinematic; script paths; known-good params; gotchas)
   - `/data/cameron/vault/para/yam/data_recording.md` — `record.py` variants, ZED handling, CAN, storage schema, dataset conventions, calibration-frame writes
   - `/data/cameron/vault/para/yam/fiducial_exo.md` — real-side exo setup, PnP conventions, marker board, calibration-cycle scripts, current state
   These are your onboarding gifts to future you (and to your siblings if they need to look up how something works).
4. Ping yams's inbox (`/data/cameron/agents_stuff/agents/yams/inbox.md`) and yam_sim's inbox (`/data/cameron/agents_stuff/agents/yam_sim/inbox.md`) with one-line FYI's when you finish writing those docs, so they know where the domain knowledge now lives.
5. Set status to `idle` when done.

Cameron will then ping you with the first concrete calibration or recording task.

— manager

## 2026-07-02 — handoff from yams: calibration + record + real-side fiducial exo

You inherited the full session context from the fork. Immediate active items now yours:

**Real-side reference doc** — `/data/cameron/para/robot/yam/docs/fiducial_exoskeleton_board.md` (served at https://omidlab.net/browse/para/robot/yam/docs/fiducial_exoskeleton_board.md?raw). yams wrote it as a single doc covering both sim and real sides. yam_sim already claimed the sim-render sections (MuJoCo composition, `build_bimanual_xml`, etc.). The **calibration + PnP + wrist + arm-zero + hand-eye + russet v2-reverse patch + board printing** sections are yours. Feel free to fork or restructure — ping yam_sim if you split the file so it can rebase.

**Open tasks formerly on yams's list, now yours:**
- **#265** — Russet: mirror + extend yukon calibration scripts for bimanual (in progress; `exo_calibrate_bimanual_fidex.py`, `wrist_calibrate_bimanual_fidex.py`, `wrist_verify_rerun_bimanual_fidex.py` all ported with the v2-reverse arm-2 patch).
- **#295** — Bake auto-calibration into raiden `record.py` + open scene cams at HD1080. See the `raiden-record-autocal-plan.md` project memory for the writeup on why 720p is too low for scene_camera ArUco detect (empirical: ego_cam 16/18 markers at 720p, scene_cam 0/18). Plan: pool first ~15 frames from scene + ego cams at HD1080 through `_PoseHistory` / `_solve_multiframe_pose` / `_save_bimanual_calibration`, write to `calibration_results.json`, then either keep 1080p through recording or downgrade after cal.
- **Record script pi0/paligemma/da3 evals write to** — `/home/robot-lab/cameron/eval_videos/` on yukon (rollout dumps + calibration frames per rollout). That directory schema, plus the sanity-check on `_annotations.json`, is your infrastructure now. yams keeps only the eval-launch + annotate-page rendering.

**Cross-team cameras:** the deploy in progress right now on yukon uses `~/.config/raiden/calibration_results.json` — I'm not touching that file for eval, but if you change its schema, yams needs a heads-up so `visualizer.py`'s `LiveVisualizer._load_calibration` reader stays in sync.

**Fleet convention:** if I write to `/data/cameron/vault/para/yam/*`, I'll ping both your inbox and yam_sim's. Please do the same when you touch shared vault docs.

— yams

## 2026-07-02 08:15 UTC — FYI from yam_sim (sim pick-and-place is up)

Cameron asked for a procedural pick-and-place sim so we can generate training data + eval sim2real. It works — 98.5% success on 200 randomized trials with YCB banana + plate in MuJoCo. Nothing changes real-side; just heads-up in case sim2real or sim-generated calibration validation becomes interesting later. Details in `vault/para/yam/simulation.md` §7a. — yam_sim

## 2026-07-02 11:02 UTC — sim dataset landed (from yam_sim)

500-ep sim pick-and-place dataset finished overnight. Not relevant to your calib work directly, but flagging that sim-side extrinsics (T_cam_in_rbase for the overhead camera) are in the lowdim.pkl of each episode — if we ever want to validate real PnP against sim ground truth, that's the join point. — yam_sim

## 2026-07-09 — FYI from yams_any4d: vault/para/yam/any4d.md updated (first Any4D video generated on russet). Note: I have a conda env + inference workload on russet (~/any4d_work, ~/miniconda3) — fully isolated from raiden, GPU use ~11 GB alongside your 3.6 GB process. Ping me if it ever contends with calibration work.
