旧設計 / BEFORE
問題点 / PROBLEM
新設計 / AFTER
旧設計 — Mac/Pi 二段階変換
MAC SIDE
pixel 検出
iPhoneカメラ → HSV赤検出 → 重心座標(px, py)
↓
MAC SIDE
homography 変換
homography.npy → World座標(mm)
基準: ロボットベース原点 / マット目盛り
↓ SSH送信
PI SIDE
変換式で Robot座標を計算
robot_x = -world_x + OFFSET_X
robot_y = -world_y + OFFSET_Y
↓
PI SIDE
send_coords()
mechArm ファームウェアがIKを計算してアームを動かす
mechArm 270-Pi
問題点 — 二つの座標系が混在
Camera World座標
基準: マット目盛り
原点: ロボットベース中心
X+: 右方向
Y+: 手前方向

例: (-267.7, 137.0)
mechArm Robot座標
基準: ファームウェア定義
原点: mechArm独自
方向: 独自定義
スケール: 独自

例: (95.8, -153.2)
確認した事実
同一のブロック位置に対して、カメラのWorld座標は (-267.7, 137.0)、 フリームードで実測したRobot座標は (95.8, -153.2)。 両者の間に単純な線形関係(オフセット)は成立しない。 1点キャリブレーションから導出したオフセット値は別の位置で破綻する。
さらに発覚した問題
camera_pick_mac.py が Piへ送る値は「World座標」。 camera_pick_pi.py はそれを受け取って「また変換しようとする」。 homography.npy はMac側にしか存在しない。 変換が2箇所に分散し、どちらが何をしているか曖昧になっていた。
新設計 — Mac側で変換を完結させる
MAC SIDE
pixel 検出
iPhoneカメラ → HSV赤検出 → 重心座標(px, py)
↓
MAC SIDE — 変換完結
homography → Robot座標 直接出力
キャリブレーション時にRobot座標で4点入力。
homography.npy が pixel → Robot座標 の変換行列になる。
変換はここだけ
↓ SSH送信(Robot座標のまま)
PI SIDE — 変換なし
受け取った値をそのまま使う
robot_x = received_x
robot_y = received_y
変換式なし
↓
PI SIDE
send_coords()
mechArm ファームウェアがIKを計算してアームを動かす
mechArm 270-Pi
次の確認課題
現在の homography.npy が「pixel → Robot座標」として正しく機能しているかを 直接確認する。確認後、camera_pick_mac.py / camera_pick_pi.py を新設計に合わせて修正する。