4.4 멀티레이트 센서 시간 정합

4.4.1 네 개의 시간

하나의 메시지에도 여러 시간이 존재할 수 있다.

1. 센서 노출/측정 시각
2. 드라이버가 메시지를 만든 시각
3. middleware가 수신한 시각
4. 애플리케이션이 처리한 시각

동기화에는 가능한 한 측정 시각을 header에 기록한다. 수신 시각을 대신 쓰면 네트워크 jitter가 물리적인 시간 차이처럼 섞인다. 장치 clock을 호스트 clock으로 변환했다면 offset 추정법과 불확실성을 기록한다.

학습 도식. 측정 시각은 물리 현상이 일어난 때를 나타내고, 나머지 시각의 차이는 드라이버·전송·처리 지연을 진단하는 단서다.

4.4.2 ExactTime과 ApproximateTime

서로 다른 센서는 timestamp가 정확히 같지 않으므로 ApproximateTimeSynchronizer가 유용하다. 알고리즘은 queue 안에서 timestamp 차이가 허용 범위(slop) 안인 조합을 찾는다. 이는 시간 여행을 보정하는 것이 아니라 가까운 메시지를 짝짓는 것이다.

30 fps 영상의 프레임 간격은 약 33.3 ms이고, 50 Hz 관절 상태는 20 ms다. 예를 들어 slop 15 ms는 가까운 상태를 찾을 가능성이 높지만, 시스템 jitter가 더 크면 pair가 사라진다. slop을 100 ms로 키우면 pair 수는 늘지만 빠른 동작에서 공간 오차가 커진다.

그림 4-3. 근사 동기화는 가장 가까운 이산 표본을 고르고, 보간은 이미지 시각 양쪽 관절 표본으로 같은 시각의 상태를 계산한다.

message_filters의 모든 Subscriber는 호환되는 QoS를 사용해야 한다. sensor-data publisher가 best-effort인데 subscriber만 reliable이면 연결되지 않을 수 있다. queue size는 최대 지연과 rate로 추정하되, 무한히 키워 오래된 데이터를 쌓지 않는다.

4.4.3 선형 보간

이미지 timestamp $t$를 사이에 두는 관절 상태 $(t_0,\mathbf{q}_0)$, $(t_1,\mathbf{q}_1)$가 있으면

$$\alpha=\frac{t-t_0}{t_1-t_0},\qquad \mathbf{q}(t)=(1-\alpha)\mathbf{q}_0+\alpha\mathbf{q}_1$$

로 보간한다. 회전 관절이 $-\pi$와 $+\pi$ 경계를 지날 때는 unwrap 후 보간한다. 쿼터니언은 선형 보간보다 SLERP가 적합하다.

실시간 정책에서는 미래 표본 $t_1$을 기다릴 수 없으므로 보간이 지연을 추가한다. 오프라인 데이터셋 정렬에서는 양쪽 표본을 쓸 수 있지만, 학습 입력에 미래 행동이나 미래 관측이 섞이지 않도록 feature timestamp를 엄격히 관리한다.

code/interpolate_joint_state.cpp는 관절 timestamp를 단조 증가로 검사하고 두 표본 사이를 선형 보간하는 독립 C++17 예제다.

잠깐 점검 — 가까운 표본이면 충분할까?

1. 오프라인 데이터셋에서는 이미지 시각 양쪽의 관절 표본을 쓸 수 있지만, 실시간 제어에서 같은 보간을 사용하면 어떤 비용이 생기는가?
2. ApproximateTime의 slop을 크게 하면 callback 수는 늘어난다. 그런데 빠른 로봇 동작에서는 왜 데이터 품질이 나빠질 수 있는가?

확인 포인트: 실시간 양방향 보간은 미래 표본을 기다리는 만큼 지연(latency)을 추가한다. 큰 slop은 서로 다른 물리 시각의 영상과 관절 상태를 한 쌍으로 묶어 공간 정합 오차를 숨길 수 있다.

4.4.4 품질 지표

에피소드마다 다음을 계산한다.

• 예상 프레임 대비 실제 프레임 수와 drop rate
• timestamp 차이 $|t_{image}-t_{joint}|$의 p50/p95/max
• timestamp 역전 수
• 관절별 속도·가속도·jerk의 이상치
• TF lookup 실패율
• 영상 decode 실패와 해상도 변화
• 명령과 관측의 지연 분포

단순히 “파일이 열린다”는 데이터 품질 검사가 아니다.