osc_goal_bridge.py(synchronized 모드)는 실행 중 자체 검증(verify_goal)에서 RuntimeError: OSC position goal differs from delivered action로 중단v6/v7 stool·drawer 정책이 정밀 삽입 단계에서 반복적으로 실패해온 근본 원인 후보로, furniture_bench/controllers/osc.py의 ee_pos_desired/ee_quat_desired Parameter가 최초 pose로 초기화된 뒤 env.step의 set_goal 호출로 갱신되지 않는다는 코드 레벨 의심이 있었다. v8은 이를 직접 검증하기 위해, 원본 컨트롤러와 수정된 목표-전달 브리지를 각각 격리된 diagnostic job으로 실행해 비교했다.
scripts/policy_harness_v8/probe_goal_delivery.py로 80-step 스크립트 프로브를 두 모드로 각각 1GPU/8CPU/32GB/6분 extra job에 제출.
| 모드 | 상태 | 목표오차 | quat오차 | 비고 |
|---|---|---|---|---|
| original | 완료(버그 확인) | 최대 0.070m | 0.0437 | 최종 target_error 0.00018m는 interpolation이 서서히 근접했을 뿐, 목표 자체는 안 바뀜 |
| synchronized | CRASH | — | — | RuntimeError: OSC position goal differs from delivered action (osc_goal_bridge.py:42, verify_goal) |
original 모드 step-by-step 로그: step1 goal_error 0.070m → step2 0.066m → step3 0.053m → step4 0.041m로 점진 감소하지만, 이는 controller_goal_position이 고정된 채 궤적 보간(interpolation)이 옛 목표와 새 목표 사이를 섞기 때문이며, 실제 요청된 목표로 "도달"한 것이 아니다(checkpoint.json의 interpolation_caveat 참고).
waiting_for_simulator_diagnostics, coordinator_owns_next_advance=true — synchronized가 실패했으므로 coordinator(128535)는 stool/drawer dev 평가(v7 round_02 정책을 부모로, fresh heldout 10101–10110 예정)를 아직 승인하지 않았다.이번 결과는 v6/v7의 정밀 삽입 실패에 실제 근거가 있는 코드 버그가 관여했을 가능성을 수치로 뒷받침하지만, 동시에 "버그를 고치는 것" 자체가 생각보다 까다롭다는 것도 보여준다. bridge의 verify_goal assert가 실패했다는 것은 브리지가 파라미터를 주입하는 시점·좌표계·순서 중 하나가 실제 컨트롤러 내부 흐름과 어긋난다는 뜻 — 단순 패치가 아니라 컨트롤러 호출 순서에 대한 재검토가 필요하다.
osc_goal_bridge.prepare_action이 왜 자기 자신의 verify_goal을 통과하지 못하는지 원인 미확인 — step 순서 문제(env.step 이전/이후 시점)인지, 좌표계 변환(우측곱 quat) 문제인지 구분 필요. interpolation 자체가 delivery 실패를 부분적으로 가리는 효과가 있어 원본 로그만으로는 "실제 물리적 영향 크기"도 아직 불명확.
synchronized crash의 스택트레이스 기준으로 브리지 로직 수정 후 두 diagnostic 재실행 → 둘 다 통과하면 coordinator가 v7 round_02 정책을 v8 브리지로 감싸 fresh heldout(10101–10110)에서 재평가, 이전 카드(v7 stool 0/10)가 목표 전달 버그 때문이었는지 분리 검증.