로봇 센서 시간 동기화는 장치 시계·NIC의 PTP Hardware Clock·운영체제 시계·ROS timestamp가 같은 기준을 따르게 만드는 작업입니다. Offset·drift·jitter를 구분하고 PTP와 NTP, 하드웨어 타임스탬프의 경계를 검증해야 센서 융합과 데이터 기록이 실제 측정 순서를 보존합니다.
아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.
센서 융합 오류는 좌표가 아니라 시계에서 시작될 수 있다
카메라·LiDAR·IMU·엔코더가 같은 움직임을 봐도 timestamp 기준이 다르면 서로 다른 순간의 값을 합치게 됩니다. 로봇 센서 퓨전 글이 시간·좌표 정렬의 결과를 다뤘다면, 이 글은 여러 clock domain을 실제로 맞추고 검증하는 기반을 설명합니다.
빠른 로봇에서는 몇 ms의 오차도 물체 위치와 관절 각도를 다른 장면으로 만들 수 있습니다. 따라서 네트워크가 연결됐는지보다 측정 순간의 시각이 어떤 clock에서 생성됐고 어디에서 변환됐는지를 추적해야 합니다.
Clock domain을 목록으로 만들지 않으면 동기 대상을 알 수 없다
한 호스트에도 system realtime, monotonic, NIC의 PTP Hardware Clock(PHC), GPU·카메라·센서 내부 시계가 존재할 수 있습니다. ROS 메시지 header stamp가 어느 시계에서 만들어졌는지 드라이버별로 다를 수 있습니다.
인벤토리에는 시계 이름, 기준 단위, epoch, 조정 주체, timestamp 생성 위치, 재부팅 동작과 다른 시계로의 변환 경로를 적습니다. 장치 tick을 UTC처럼 해석하거나 monotonic 값을 벽시계와 직접 비교하는 오류를 먼저 제거할 수 있습니다.
Offset·drift·jitter는 서로 다른 실패를 뜻한다
Offset은 같은 순간 두 시계가 가리키는 값의 차이, drift는 시간이 지나며 그 차이가 변하는 속도, jitter는 짧은 구간의 불규칙한 변동입니다. 시작 때 offset이 작아도 oscillator drift가 크면 장시간 운용 중 다시 벌어집니다.
네트워크 부하와 소프트웨어 timestamp는 지연 변동을 jitter로 만들 수 있습니다. 평균 offset만 기록하지 말고 시간에 따른 추세, P95·P99·최대, 시간 점프와 보정 이벤트를 함께 봐야 안정성을 판단할 수 있습니다.
| 지표 | 의미 | 대표 영향 |
|---|---|---|
| Offset | 현재 시각 차이 | 센서 프레임 오정렬 |
| Drift | offset 변화율 | 장시간 오차 증가 |
| Jitter | 짧은 변동 | 추정 노이즈·꼬리 지연 |
| Step | 불연속 시각 변경 | 역행·timeout·bag 왜곡 |
NTP와 PTP는 이름보다 timestamp 위치와 네트워크 조건이 다르다
IETF NTPv4 표준 RFC 5905는 분산 시스템 시계를 동기화하는 프로토콜과 알고리즘을 정의합니다. 일반 네트워크의 호스트 시각 관리에 널리 쓰이지만 경로 지연 비대칭과 소프트웨어 처리 변동이 정밀도를 제한할 수 있습니다.
PTP는 네트워크 장비와 NIC의 하드웨어 timestamp 지원을 활용해 패킷 처리 지점을 전선 가까이 옮길 수 있습니다. 그렇다고 PTP가 항상 더 정확한 것은 아니며 grandmaster, transparent·boundary clock, NIC·드라이버와 토폴로지가 모두 지원해야 합니다.
PTP grandmaster와 도메인 설계가 기준 시계를 정한다
linuxptp ptp4l 문서는 IEEE 1588 PTP를 Linux에서 구현하고 하드웨어·소프트웨어 timestamp 모드를 제공합니다. 포트 상태와 best master clock 선택에 따라 grandmaster와 client 역할이 바뀔 수 있습니다.
로봇 셀에서는 어느 시계가 우선 기준인지, grandmaster 상실 때 누가 승계하는지, 다른 PTP domain과 섞이지 않는지 정합니다. 네트워크 스위치가 PTP 메시지를 어떻게 처리하는지와 링크 비대칭도 토폴로지 문서에 포함해야 합니다.
하드웨어 타임스탬프는 패킷이 NIC를 지나는 지점을 기록한다
Linux 커널 PTP Hardware Clock 문서는 PHC와 socket timestamping을 통해 사용자 공간 PTP 프로그램이 하드웨어 시계를 다루는 기반을 설명합니다. 소프트웨어 timestamp보다 스케줄링과 queue 변동의 영향을 줄일 수 있습니다.
NIC가 기능을 지원해도 드라이버 설정과 실제 timestamp mode가 software로 떨어지면 기대 정밀도가 나오지 않습니다. 인터페이스 capability, ptp4l 로그, PHC 장치 매핑과 패킷 timestamp 유형을 런타임에서 확인해야 합니다.
ptp4l과 phc2sys는 서로 다른 시계를 맞춘다
phc2sys 공식 문서는 보통 ptp4l이 동기화한 PHC를 system clock과 맞추는 역할을 설명합니다. ptp4l 상태가 정상이어도 phc2sys 경로가 없으면 응용이 읽는 CLOCK_REALTIME은 따로 움직일 수 있습니다.
동기 방향을 잘못 설정하면 좋은 기준 시계를 나쁜 시계에 맞출 수 있습니다. grandmaster 역할 변화, UTC와 PTP time scale 차이, leap second offset 처리와 system clock 조정 정책을 구성·로그에서 확인합니다.
센서 하드웨어 timestamp는 노출·샘플링 순간과 가까워야 한다
카메라 timestamp가 드라이버 콜백 도착 시점에 찍히면 USB·Ethernet 전송과 queue 시간이 측정 시각에 섞입니다. 센서가 frame start, exposure midpoint 또는 packet 시점에 찍는 하드웨어 timestamp를 제공한다면 그 의미를 문서로 확인해 사용하는 편이 좋습니다.
여러 카메라의 trigger 동기와 clock 동기는 별개일 수 있습니다. 같은 트리거로 촬영해도 시각 표현이 다른 domain이면 변환이 필요하고, 같은 PTP 시계를 써도 exposure 시점 정의가 다르면 일정한 bias가 남습니다.
ROS timestamp 변환은 드라이버 경계에서 검증한다
ROS header stamp를 만드는 순간에는 센서 tick 또는 PHC 값을 ROS가 사용하는 시간 기준으로 변환합니다. TF2 시간 버퍼 글처럼 lookup은 같은 시간축이라는 전제에서 동작하므로 잘못된 epoch와 clock jump는 extrapolation 오류로 나타납니다.
드라이버가 timestamp를 덮어쓰는지, 수신 시각을 쓰는지, 시뮬레이션 time을 따르는지 설정별로 확인합니다. 원시 장치 timestamp와 변환된 ROS stamp를 함께 로그에 남기면 변환 bias와 역행을 재구성할 수 있습니다.
동기 검증은 유휴·부하·단절·재복구 네 구간에서 한다
유휴 상태에서 offset 기준선을 만들고, 센서·네트워크·CPU 부하를 높여 jitter와 꼬리를 봅니다. 그다음 grandmaster 또는 링크를 끊어 holdover drift와 경보를 확인하고, 재연결 때 시간 step·역행·재수렴 시간을 측정합니다.
비교 기준은 같은 PPS 또는 외부 계측 신호, PHC cross timestamp, 장치별 동시 사건처럼 측정 지점에 가까운 방법을 선택합니다. 애플리케이션 로그끼리만 비교하면 두 로그가 공유한 잘못된 system clock을 정상으로 오판할 수 있습니다.
| 단계 | 조건 | 기록 |
|---|---|---|
| 1. 유휴 | 정상 네트워크 | offset·drift 기준선 |
| 2. 부하 | 센서·CPU·트래픽 최고 | jitter·P99·drop |
| 3. 단절 | GM·링크 상실 | holdover·경보 |
| 4. 복구 | 재선출·재연결 | step·역행·재수렴 |
시간 동기 실패는 데이터 품질과 제어 지연으로 함께 나타난다
학습 데이터 품질 검수에서는 센서·행동 정렬과 실패 라벨 시각이 흔들리고, 추론 지연 예산에서는 음수 지연이나 비정상적으로 큰 구간이 나타날 수 있습니다. 같은 timestamp 문제를 모델·네트워크 문제로 오판하지 않아야 합니다.
모니터링에는 PTP port state, master identity, PHC–system offset, 센서별 timestamp age, 역행과 clock step을 넣습니다. 임계값을 넘을 때 데이터를 폐기할지 로봇을 감속·정지할지 작업 위험과 추정기 허용범위로 결정합니다.
운영 인수 기준은 정확도 숫자와 복구 행동을 함께 포함한다
요구 정확도는 가장 빠른 센서와 로봇 속도, 융합 알고리즘 민감도에서 역산합니다. 정상 평균만 아니라 최대 offset, drift, 부하 P99, 단절 후 허용 holdover 시간과 재동기 중 출력 정책을 명시해야 합니다.
장비 교체·펌웨어·스위치 설정·커널 업데이트는 timestamp 경로를 바꿀 수 있으므로 같은 시험을 재실행합니다. 어떤 grandmaster와 domain에 연결됐는지부터 sensor frame의 실제 측정 시각까지 증거가 이어질 때 시간 동기화를 완료했다고 판단합니다.
로봇 시간 동기화에서 자주 묻는 질문
PTP를 켜면 모든 센서 timestamp가 자동으로 맞나요?
아닙니다. NIC의 PHC와 system clock, 센서 내부 시계와 드라이버 변환이 모두 같은 경로로 연결돼야 합니다.
NTP와 PTP 중 무엇을 써야 하나요?
요구 정확도, 네트워크와 하드웨어 지원에 따라 다릅니다. 일반 호스트 시각에는 NTP가 적합할 수 있고 정밀 센서 정렬에는 하드웨어 timestamp PTP가 유리할 수 있습니다.
Offset이 작으면 동기화가 안정적인가요?
한 시점의 offset만으로는 부족합니다. 장시간 drift, 부하 jitter, 최대 오차와 grandmaster 단절 뒤 holdover를 함께 봐야 합니다.
ptp4l만 실행하면 system clock도 맞나요?
하드웨어 timestamp 구성에서는 보통 ptp4l이 PHC를 맞추고 phc2sys가 PHC와 system clock을 동기화합니다. 실제 동기 방향과 상태를 확인해야 합니다.
시간이 다시 맞으면 중간 데이터도 사용해도 되나요?
동기 상실과 재수렴 구간에는 timestamp jump와 큰 오차가 남을 수 있습니다. 상태 플래그와 임계값으로 해당 구간을 표시하거나 제외해야 합니다.
시간 동기화의 허용 오차는 로봇 속도·센서율·융합 알고리즘과 안전 요구에 따라 달라집니다. PTP·NTP 구성은 네트워크 관리자와 장비 제조사 사양을 함께 확인해야 합니다.