DROID stack episode 데이터 감사 — fail-closed gates 현황

TL;DR

불일치 확정: 선정 episode(GuptaLab+553d1bd5+2023-05-19-10h-38m-49s)의 raw H5 105행, MP4 디코드 104프레임, timestamp sidecar 103개, SVO SDK 선언 104/실관측 103이 서로 다름을 8개 감사 모듈로 교차 검증
bounded core 확정: 최종 승인 구간은 0–102(action core는 9–102). held-out 93–102 구간 clock 잔차 p95가 세 카메라 모두 0.5ms 미만
결론 미완: RGB-timestamp 정합 및 stereo metric baseline/rectification 게이트는 여전히 NOT READY — 전체 상태 INCOMPLETE_FAIL_CLOSED

감사 모듈

0–102

승인 core

<0.5ms

held-out clock p95

2/3

게이트 미통과

1 배경 / 목적

R2S 프로젝트는 DROID의 stacking episode 하나("Put the orange block on the green block", scene_id 5235850418)를 geometry/action/contact physics까지 검증 가능한 시뮬레이션 twin으로 만드는 것이 최종 목표다. 5단계 로드맵(A. Data audit → B. Geometry → C. Robot/action → D. Contact physics → E. Appearance → F. 통합 검증) 중 G001(Data audit)이 다른 모든 단계의 선행 조건이다.

기존 한계: raw H5(105행), 각 카메라 left MP4(60fps 컨테이너, 104 디코드 프레임), MP4 timestamp sidecar(103개)의 개수가 서로 다르고, 어느 프레임이 어느 timestamp에 대응하는지 증명된 바 없었다. 이 상태로 geometry/physics fitting을 진행하면 오차의 원인(카메라 노출 시점 vs 실제 물성)을 구분할 수 없다.

2 작업 내용

8개의 독립 감사 모듈을 stdlib/CPU 전용으로 구현하고, 각 모듈은 fail-closed(증명되지 않으면 UNREADY/UNVERIFIABLE로 보고)로 설계했다.

r2s.acquire_sources — SVO 3개 + factory calibration 3개, GCS generation-pinned 읽기, SHA256/CRC32c 확인 (전부 STAGED, `reused`) r2s.video_audit — left/stereo MP4 CPU 디코드(단일 스레드), 프레임 해시, 인접 중복 확인, PTS/컨테이너 메타데이터 r2s.calibration_audit — raw/derived 6개 camera-side transform 비교, RxRyRz vs RzRyRx convention 검증 r2s.candidate_support — 동일 scene 후속 후보 2개(10:39:59 / 11:11:36)의 H5/sidecar prefix 정합 확인 r2s.derived_correspondence — im128 파생본과 raw MP4 콘텐츠 pairwise 유사도(95쌍/카메라) r2s.derived_provenance — convert_droid.py(pinned commit) 라인 레벨 분석: 타임스탬프 dict를 빈 dict로 덮어쓰는 지점, RxRyRz/RzRyRx 혼용 지점 특정 r2s.data_audit — H5/depth/sidecar exact-prefix 검증, robot-host clock affine offset observed_core — job 123473 SDK 트레이스와 위 결과를 결합해 hash-bound 0–102 core 확정

대안이었던 "컨테이너 fps(60)를 그대로 실제 캡처 속도로 채택"은 명시적으로 거부했다 — 파일에서 실측한 control step_start 중앙값(70ms)과 어긋나기 때문이다.

3 결과 (수치 필수)

검증 항목	수치	해석
H5 rows	105	raw 기준. 103–104는 excluded
MP4 디코드 / sidecar	104 / 103	sidecar가 컨테이너 마지막 1프레임의 timestamp 누락
SVO SDK 선언 / 관측	104 / 103 (0–102 EOF)	`SDK_CAPTURED_REJECTED` — 구조적 거부, 완화하지 않음
observed core held-out clock p95	0.4847 / 0.4289 / 0.4683 ms	16291792 / 22246076 / 26638268, 모두 <0.5ms
critical 93–102 구간 p95	0.4797 / 0.4493 / 0.4139 ms	후반 프레임도 정합 유지
held-out RGB MAE (mean/p95)	3.50/3.55, 4.00/4.09, 3.68/3.74	0–255 스케일, 콘텐츠 정합 방증
calibration_audit 회전 오차	22246076: RxRyRz 161.55° / RzRyRx 4.68° 26638268: RxRyRz 95.81° / RzRyRx 2.03°	RzRyRx가 실제 convention임을 강하게 시사
후속 후보 candidate_support	10:39:59 = 135행/133 sidecar, 11:11:36 = 89행/87 sidecar	둘 다 exact-prefix. validation/test 미배정

게이트 현황: rgb_content_timestamp_alignment NOT READY, stereo_metric_baseline_and_rectification NOT READY. time_axis_prefix_join만 READY. 전체 상태는 INCOMPLETE_FAIL_CLOSED로 유지.

핵심 발견: raw row 103–104를 배제한 0–102 bounded core는 세 카메라 모두 held-out(81–92, 93–102) 구간에서 timestamp correspondence p95 <0.5ms를 달성 — 이는 exposure timing은 아니지만 timestamp 신뢰도로는 충분히 강한 근거다.

4 Takeaway

의미

raw H5 마지막 1~2행(103–104)이 구조적으로 신뢰 불가능하다는 것이 SVO SDK 실측(SDK_CAPTURED_REJECTED)까지 3중으로 확인됐다 — H5/sidecar 카운트 불일치, MP4 디코드 개수, SDK EOF가 모두 같은 지점을 가리킨다. 이 0–102 경계는 이제 카드 "ZED SVO SDK 통합"의 export 파이프라인과 "Geometry 복원" 비교 작업의 공식 입력 범위가 됐다. 또한 RzRyRx convention 확정은 로봇 control 파운데이션 쪽 FK 검증(별도 카드)에서 독립적으로 재확인됐다 — 서로 다른 두 경로에서 같은 결론에 도달한 것은 신뢰도를 높인다.

5 Next Steps

미해결 한계

rgb_content_timestamp_alignment는 아직 "디코드된 프레임 콘텐츠가 실제로 그 timestamp의 노출인지"를 증명하지 못한다 — 현재는 timestamp 배열 자체의 정합성만 확인됨. stereo_metric_baseline_and_rectification은 현재 SDK가 보고하는 baseline/intrinsics가 "현재 제조사 값"일 뿐 2023년 캡처 당시 값이라는 증거가 없어서 막혀 있다.

다음 작업

후속 후보 2개(10:39:59, 11:11:36)의 영상/접촉 품질을 감사해 validation/test 역할을 확정하고 configs/eval_split.json을 freeze한다. Geometry/SVO export 카드에서 나온 실측 baseline(62.996mm)이 2023 계산 기준과 일치하는지 별도 corroboration 경로를 찾아야 stereo 게이트를 열 수 있다.