TipBrepReader が見せた誤差の正体

同じ angles で、3つの値が並んだ。クリックで詳細表示。
3つの計測値(同じ PICK angles に対して)
CSV 記載 ee
0.183
FKスキャンテーブルから引いた値
TipBrepReader 実測
0.252
現Unityで同 angles を取らせて測った値
実機青シール(LOG168)
0.250
実機の物理爪先MID(X座標、Unity m)
CSV 記載 ee の意味
fk_scan_motion_based.csv は LOG157 で 213,312点まで再スキャンされた。 PICK angles [-50, 100, -55, -2, -35, -20] に対応する行のee座標は (0.183, 0.042, 0.154)。Pi側のlookupは正しくこの行を返していた。
TipBrepReader 実測の意味
新規スクリプトで同じ angles を Unity に取らせて、leftTipBrep と rightTipBrep の中点を World 座標で読み取った。結果は (0.252, 0.018, 0.218)。 CSV 記載値とは 3D 距離で約97mm 違う。
実機青シールの意味
LOG168 で実機グリッパーの爪先に青シールを貼って、カメラから検出した値。 (0.250, _, 0.197)。Unity の TipBrepReader 実測値と X方向ほぼ一致、 Z方向 22mm 差。Unity と実機の整合は意外と良い。
↓
19mm誤差の構造(LOG168)
段階 値の出処 誤差
① 赤ブロック中心 Unity 上の RedBlock_arm1 基準
② FKスキャナー記録 fk_scan_motion_based.csv +97mm
③ 実機への送信 Pi 側 send_angles() ±0
④ 実機の物理オフセット 製造公差・組立差 逆方向に作用
⑤ 実機青シール実測 カメラ検出 19mm

②の97mmと④の物理オフセットが、たまたま打ち消し合う方向に作用して、 最終的に⑤で19mmになっていた。「19mm誤差を詰める」と言ったとき、 実は2つの大きな誤差が偶然成立させていた数字を相手にしていた。

LOG168 angles vs LOG169 確定 angles
関節 LOG168 LOG169 確定 差
j0-50-49-1
j110098-2
j2-55-32+23
j3-20+2
j4-35-65-30
j5-200+20

同じ「PICK姿勢」と呼ばれていたものが、実は j2/j4/j5 で大きく違う姿勢だった。 赤ブロック専用 PICK angles として [-49, 98, -32, 0, -65, 0] を確定。

P008(新規追加)

測れる手段を持つことが、推論より先にくる。

引き継ぎの数値、ログの数値、過去の判断。それらを推論で繋いでも、 測れる手段を持っていなければ、どこが正しくてどこが間違っているか確かめられない。

LOG169 / R2R2R Methodology / 2026-04-25