reconstruct_foundation_stereo.sbatch는 checkpoint가 있어도 FoundationStereo를 호출하지 않고 exit 0로 조용히 끝나는 구조였음 — exit 2 명시적 가드로 교체blocked로 공식 전환260915 카드(las2_stereo_model_evaluation)에서 FoundationStereo 공식 checkpoint가 Google Drive rate-limit으로 실패해 LAS2-M을 대안으로 도입했지만 채택은 보류됐다. 오늘 카드(scene_camera_correspondence_chain)의 24단계 진단에서도 SDK vs LAS2 depth가 서로 다른 지오메트리를 지지해 교착 상태에 빠졌다 — 제3의 독립적인 depth 소스(FoundationStereo)가 없으면 이 교착을 풀 수 없다는 것이 명확해졌다. 이번 세션은 그 제3 소스를 실제로 가동 가능하게 만드는 엔지니어링 작업이었다.
기존 scripts/reconstruct_foundation_stereo.sbatch(SHA adcadf52...)를 감사한 결과, checkpoint가 없으면 SGBM으로 fallback해 exit 0, checkpoint가 있어도 FoundationStereo를 호출하는 코드 경로 자체가 없어 그냥 EOF로 끝나는 구조였다. GPU까지 불필요하게 요청하고 있었다. 이를 명시적 exit 2 가드로 교체:
개인 venv .venv-stereo/runtime에서 순차적으로 발견된 누락 모듈을 수리:
| 단계 | 에러 | 해결 |
|---|---|---|
| 1 | ModuleNotFoundError: trimesh | trimesh 4.5.3, joblib 1.4.2, pandas 2.2.3, open3d 0.19.0, numpy 1.26.4 설치 (65 패키지 resolve) |
| 2 | torchvision 이중 메타데이터(0.22.1+cu128 / 0.29.0) | no-deps 재설치로 단일 레코드화 |
| 3 | OSError: libGL.so.1: cannot open shared object file | 기존 .venv-source-ik/runtime-libs에서 libGL.so.1/libGLX.so.0/libGLdispatch.so.0 3개를 파일명 그대로 복사 (시스템 라이브러리 미변경) |
최종 검증에서 8/8 모듈 import 성공: numpy 1.26.4, torch 2.14.0+cu130, torchvision 0.29.0+cu130, cv2 4.11.0, timm 1.0.15, omegaconf 2.3.0, core.foundation_stereo, dinov2.hub.backbones. 상태 라벨은 명시적으로 CPU_IMPORTS_ONLY_NOT_MODEL_READINESS.
r2s/foundation_offline.py: 업스트림 생성자 호출을 pretrained=False로 대체하되, 이후 완전한 checkpoint state가 모든 항목을 채워야만 유효하도록 strict=True loader 구현. TorchHub 원격 호출 대신 번들된 DINOv2 factory를 직접 호출해 네트워크 접근 차단(Python 소켓 tripwire). Key-prefix 보정, fallback, partial state 로딩은 전부 금지.
이전 시도 이후 48시간 이상 경과 후, cfg/weights 파일 각각에 대해 정확히 1회씩 공식 URL + gdown 5.2.0(쿠키 비활성화)으로 재요청. 둘 다 exit 1, 동일한 quota 메시지:
r2s/foundation_pair.py: checkpoint 2개 파일의 SHA256이 OFFICIAL_PAIR_SHA256에 pin되기 전까지는 torch import 이전에 무조건 실패하도록 설계. Forward+reverse(mirror) 양방향 추론, ≤1px LR consistency mask, atomic 완료 마커(hard-link, no-clobber) 등 구현. GPU 실행 조건(1 GPU, own QOS, UID/host 일치)까지 검증하지만 checkpoint가 없어 실제 추론은 0회.
| 산출물 | 테스트 | 실행 상태 |
|---|---|---|
| Launcher 가드 교체 | 4 tests pass (0.015s) | 완료 (exit 2 가드 동작 확인) |
| Import 의존성 수리 | 7 tests pass (0.019s) | 완료 (8/8 모듈 import) |
| Offline 생성 helper | 12+8 tests pass (0.019s/0.031s) | 완료 (fixture 기반, 실모델 미검증) |
| Pair runner | 36 tests pass (0.398s), 22개 pair 전용 | 구현 완료, 추론 0회 (checkpoint 없음) |
| Checkpoint 재요청 | 2/2 시도 | 둘 다 실패 (동일 quota 오류) |
| Goal | 현재 증거 | 상태 |
|---|---|---|
| G001 입력 감사 | observed-core 0-102 bounded, exposure timing 미확정 | IN PROGRESS |
| G002 전체 지오메트리/캘리브레이션 | SDK/LAS 불일치, FoundationStereo 비교 미실행 | BLOCKED (외부) |
| G003 로봇/원본 액션 | source-IK 개선되었으나 lift/stack 미복구 | IN PROGRESS |
| G004 접촉 물리 | joint-target replay만 stack 성공, 10ms contact gate 실패 | IN PROGRESS |
| G005 시각 딜리버리/리뷰 | Cycles 렌더 존재, appearance mismatch 지속 | IN PROGRESS |
omx ultragoal checkpoint --status blocked 공식 실행, 후속 get_goal로 blocked 상태 확인.이번 세션은 "checkpoint만 받으면 바로 돌아가는" 완결된 파이프라인을 만들어뒀다는 점에서 실질적 진전이다 — 예전에는 launcher 자체가 조용히 아무것도 안 하고 성공한 척 하는 상태였는데, 이제는 정직하게 실패하고(exit 2), import/offline-construction/pair-inference 세 단계가 모두 독립적으로 테스트로 검증된 상태다. 남은 유일한 블로커는 코드가 아니라 외부 파일(Google Drive 파일 2개)이다.
동시에 오늘 카드(scene_camera_correspondence_chain)가 보여준 SDK/LAS 교착을 고려하면, 이 checkpoint 확보는 단순 "하나 더 있으면 좋은 옵션"이 아니라 G002 전체 지오메트리 트랙의 유일한 명확한 다음 수다.
Google Drive 파일 소유자 rate-limit은 우리 쪽에서 제어 불가능한 외부 조건이다. 반복 재시도는 동일 응답만 낼 뿐 상태를 바꾸지 않는다는 것이 이미 3턴 연속으로 확인됐다.
1) 사용자에게 공식 checkpoint 파일을 직접 확보해 전달하거나(예: 다른 경로로 이미 받아둔 매칭 pair), Drive 소유자에게 접근 재시도할 시점(24h+ 경과 후)을 문의. 2) checkpoint 확보 즉시 --preflight → snode --json 용량 확인 → 1-GPU own worker에서 native 720p forward/reverse 1회 실행 → SDK/LAS와 3-way 비교. 3) 그 전까지는 다운로드 재시도나 import 테스트 반복을 "진행"으로 보고하지 않는다 — ultragoal 상태는 blocked로 유지.