설계안 — dual_arms 멀티카메라 시각정보 싱크 품질 개선 계획

• 작성: Mojo (RTX 4070, moosjiny/dual_arms 담당)
• 배경: 사령관 질의 — "카메라 위치(마운트)는 이미 올바른데, 시각정보의 싱크 품질을 올리기 위한 계획이 있는가?"
• 선행 자료: OpenGraph Labs 조사 노트

1. 현재 상태

config/dual_arm_config.yaml에는 카메라 3대(top/left_wrist/right_wrist)가 opencv index 0/1/2로만 정의돼 있고, 실제 캡처·타임스탬핑·다중 스트림 정렬 로직은 아직 구현되어 있지 않다. 즉 이번 계획은 버그 수정이 아니라 신규 설계다.

2. 문제 재정의

카메라 위치(외부 파라미터, extrinsics)가 정확하다는 것은 공간 정렬 문제가 없다는 의미이며, 남은 과제는 순수한 시간 정렬(temporal sync) 문제다. 3개 카메라 + CAN-FD 팔로워암 2개 + Dynamixel 리더암 2개, 총 6개 스트림이 각자 다른 폴링 주기와 드라이버 지연으로 들어오는데, 현재 이를 하나의 시간축으로 정렬해주는 장치가 없다.

3. 개선 계획 (5단계)

3.1 공통 시각 기준선 도입

모든 스트림을 time.monotonic() 기준으로 타임스탬프한다. wall clock(NTP 점프 위험)은 쓰지 않는다. 단일 머신(4070)에서 전부 캡처하면 이것으로 충분하지만, 리더암을 3060 (TELEOP_DOCKER)에서 읽는 구성이라면 머신 간 clock sync(chrony/PTP)가 추가로 필요하다 — 현재 리더암이 어느 머신에서 읽히는지 먼저 확인이 필요하다.

3.2 카메라 타임스탬프를 grab() 시점에 고정

OpenCV retrieve()가 아니라 grab() 직후 타임스탬프를 찍어야 디코딩 지연이 섞이지 않는다. 다만 UVC 웹캠은 OpenCV Python API로 하드웨어 노출 시작 시각을 읽을 수 없다 — SyncField 같은 SDK가 존재하는 이유다. 3카메라가 전부 같은 드라이버(uvcvideo)를 쓰는지, 롤링셔터/글로벌셔터가 섞여 있는지부터 점검이 필요하다(섞여 있으면 카메라마다 지연 특성이 달라 보정이 어려워진다).

3.3 SyncField SDK 실채택

syncfield-python(Apache-2.0)을 도입해 정밀 타임스탬핑을 직접 재구현하지 않는다. 신규 캡처 스크립트(가칭 scripts/capture_multistream.py)를 이 SDK 위에 작성한다.

3.4 CAN/Dynamixel 텔레메트리도 같은 시간축에

SocketCAN은 SO_TIMESTAMP로 커널 수신 시각을 서브밀리초 단위로 이미 제공한다 — 활용 여부만 확인하면 된다. Dynamixel은 read 호출 직후 monotonic 타임스탬프를 붙인다.

3.5 검증 — 플래시/클랩 테스트

LED를 한 번 깜빡이거나 손뼉을 쳐서 3카메라 프레임 인덱스에서 해당 이벤트가 몇 프레임 차이로 나타나는지 측정해 카메라별 고정 오프셋을 실측 캘리브레이션한다. 이를 주기적 헬스체크로 자동화하면 시간이 지나며 생기는 드리프트도 잡아낼 수 있다.

4. 참고 — SyncField의 실사용 맥락 (미검증, 참고용)

사령관 전언에 따르면 OpenGraph Labs(SyncField 개발사)가 MicroAGI에 데이터 수집용 인프라를 공급하고 있다고 한다. 웹 검색으로 교차 확인을 시도했으나, 이 특정 공급 관계를 명시적으로 확인해주는 공개 자료는 찾지 못했다 — 다만 MicroAGI는 "물리적 AGI(end-to-end physical AGI)"를 다루는 데이터 리서치 랩으로 확인되며, OpenGraph Labs와 동일한 문제 영역(로봇 학습용 실세계 데이터 수집)에 있다는 점에서 정황상 개연성은 있다.

이 항목은 사실관계 미확정으로 표시한다. 검증 여부와 무관하게 3장의 개선 계획 자체는 SyncField의 오픈소스 SDK(Apache-2.0, GitHub 실측 확인됨)에만 의존하므로 채택 타당성에는 영향을 주지 않는다. 다만 실제 로봇 학습 데이터 랩들이 SyncField류 인프라를 채택하고 있다는 정황은, 이 방향이 우리만의 특수한 필요가 아니라 업계 공통의 페인포인트라는 근거로 참고할 수 있다.

5. 다음 단계

이 설계안에 대한 팀 검토 후, 승인되면 scripts/capture_multistream.py 구현에 착수할 예정이다.