(센서 타임스탬프, 보정, 지연 문제까지 정리)
대상: LiDAR·Camera·IMU 등 여러 센서를 동시에 사용하는 자율주행 시스템을 개발하는 ROS2 사용자
환경: Ubuntu 22.04 + ROS2 Humble/Foxy, Autoware 또는 커스텀 센서 퓨전 시스템
1. 문제/주제 요약
자율주행 차량에는 다음과 같이 다양한 센서가 동시에 장착됩니다:
- LiDAR (거리·형상)
- Camera (시각 정보)
- IMU (가속도·각속도)
- GPS (위치)
- Radar (속도)
이 데이터들이 하나라도 시간이 어긋나면,
센서 퓨전이나 경로 추정(Localization)에서 정확한 공간 인식이 불가능해집니다.
즉,
“같은 순간의 세상을 본 데이터만” 결합해야
자율주행 시스템이 일관된 인식을 할 수 있습니다.
그래서 시간 동기화(Time Synchronization)는
센서 퓨전의 출발점이자 자율주행의 신뢰도를 결정짓는 핵심 기술입니다.
2. 왜 시간이 어긋나는가? (비동기 센서의 현실)
각 센서는 독립된 하드웨어로, 자체적인 클록(clock)을 가집니다.
이 때문에 다음과 같은 문제가 발생합니다:
| 원인 | 설명 |
|---|---|
| 센서별 주기 차이 | LiDAR: 10Hz, Camera: 30Hz, IMU: 100Hz — 동일한 시점이 없음 |
| 하드웨어 지연 (latency) | 이미지 처리, 포인트 클라우드 생성 시간 등 |
| 통신 지연 | CAN, Ethernet, USB 등 인터페이스별 전송 시간 차이 |
| 시스템 클록 불일치 | 각 장치의 내부 시계(clock)가 미세하게 다름 |
| ROS2 메시지 큐 지연 | 토픽 발행 후 스케줄링 오버헤드로 타임스탬프 밀림 |
3. 시간 동기화의 목적
시간 동기화의 목표는 간단히 말해 **모든 센서 데이터를 “같은 시간선 위에 놓는 것”**입니다.
시각 T0 기준으로 본 세상
Camera Frame @ T0
LiDAR Scan @ T0
IMU Reading @ T0
이렇게 정렬되어야
센서 퓨전(Fusion), SLAM, Localization, Planning이 일관성 있는 결과를 얻습니다.
4. 자율주행에서 시간 동기화가 중요한 이유
(1) 센서 퓨전의 정확도
LiDAR + Camera를 결합할 때,
0.05초만 어긋나도 차량의 속도(10m/s) 기준으로 50cm 오차가 생깁니다.
→ Bounding Box가 어긋나거나, FreeSpace 계산이 틀려집니다.
(2) Localization (위치 추정)
IMU와 LiDAR 데이터를 융합할 때
IMU가 예전 상태를 기준으로 보정하면 지도 상 위치가 튀는 현상이 발생합니다.
→ Extended Kalman Filter(EKF)의 예측 단계가 잘못된 시점의 데이터를 사용하게 됩니다.
(3) Planning 및 Control 지연
Perception 결과가 늦게 들어오면
Planning이 “이미 지나간 객체”를 기준으로 경로를 계산할 수 있습니다.
→ Control 단계에서 지각-계획 지연(latency) 으로
차량이 제때 반응하지 못하는 문제가 발생합니다.
5. 시간 동기화 방식 (ROS2 기준)
ROS2에서는 센서 데이터를 동기화하기 위해 다음 세 가지 접근을 사용합니다.
(1) 소프트웨어 기반 동기화
a. ROS2 message_filters 사용
from message_filters import ApproximateTimeSynchronizer, Subscriber
cam_sub = Subscriber('/camera/image_raw', Image)
lidar_sub = Subscriber('/lidar/points_raw', PointCloud2)
sync = ApproximateTimeSynchronizer([cam_sub, lidar_sub], queue_size=10, slop=0.05)
sync.registerCallback(callback)
slop=0.05→ 0.05초 이내의 타임스탬프를 동일한 시점으로 간주ExactTimeSynchronizer도 있지만, 센서 주기가 다르면 거의 실패함
✅ 장점: 간단히 구현 가능
⚠️ 단점: 하드웨어 오차를 완벽히 보정할 수 없음
(2) 하드웨어 기반 동기화
a. Trigger 신호 (Hardware Sync Pulse)
- LiDAR가 “Trigger Out” 신호를 내보내면
카메라가 그 신호를 받아 같은 시점에 프레임 캡처 - IMU와 GPS도 PPS(Pulse Per Second) 신호로 기준을 공유
b. GNSS 기반 시간 동기화 (PTP / NTP / PPS)
- GPS 수신기의 1PPS 신호를 ROS2 시스템 클록 기준으로 사용
chrony+ntpd로 OS 레벨 시간 동기화 가능
sudo apt install chrony
sudo systemctl enable chronyd
sudo chronyc sources -v
✅ 장점: 센서 간 실제 물리적 클록 일치
⚠️ 단점: 추가 하드웨어 필요, 세팅 복잡
(3) 타임스탬프 보정 (Timestamp Compensation)
센서 드라이버에서 “데이터가 실제로 수집된 시간”을 명시적으로 보정합니다.
예: 카메라 드라이버에서 프레임 생성 시간(frame_start_time)으로 타임스탬프 설정
msg->header.stamp = rclcpp::Time(frame_start_time);
LiDAR의 경우 회전 스캔 시간(scan_start_time, scan_end_time)을 보정해
포인트별로 시간 보간(interpolation) 수행합니다.
6. 지연(Latency)와 타임 오차의 누적 효과
| 항목 | 오차 예시 | 영향 |
|---|---|---|
| LiDAR – Camera 오차 | 50~100ms | 객체 위치 불일치 |
| IMU – LiDAR 오차 | 10~20ms | Localization 흔들림 |
| GPS – 시스템 클록 오차 | 1초 이상 | 전역 좌표 오차 수십 m |
| Planning – Control 지연 | 100ms 이상 | 곡선 진입 타이밍 불일치 |
🚫 자율주행에서는 100ms 이상 지연이 누적되면
차량이 “지난 프레임의 세상”을 기준으로 반응하는 상태가 됩니다.
7. ROS2에서 시간 검증 방법
ros2 topic echo /camera/image_raw/header/stamp
ros2 topic echo /lidar/points_raw/header/stamp
ros2 topic echo /imu/data/header/stamp
또는 rqt_plot으로 타임스탬프 비교 그래프를 확인합니다.
RViz2에서도 /tf 프레임 지연(Transform delay)이 표시됩니다.
8. 실제 적용 예 (Autoware + LGSVL)
- LGSVL 시뮬레이터에서 센서 데이터는 모두 가상 GPS 시간(PPS) 에 맞춰 발행됩니다.
- Autoware에서는
/use_sim_time=true로 설정하여
시뮬레이터 시간에 맞춰 동기화 수행.
ros2 param set /use_sim_time true
이 덕분에 LiDAR, Camera, IMU, GPS 데이터가 모두 동일한 기준 시간에 정렬됩니다.
9. 추가 팁 / 자주 하는 실수
- USB 카메라는 하드웨어 동기화 불가 — 실험용으로만 사용
- LiDAR와 IMU의 PPS 신호 미연결 → Localization 흔들림 발생
- ROS2 메시지 큐 overflow → 오래된 데이터가 뒤늦게 도착 (timestamp 역전 현상)
- /use_sim_time 설정 누락 → 시뮬레이터 연동 시 시간 mismatch 발생
🔧 Tip: 실제 차량에서는
PTP(Precision Time Protocol)기반 클록 동기화를 권장합니다.
(Ethernet 지원, µs 단위 정확도 확보 가능)
10. 정리
시간 동기화는 자율주행 시스템의 보이지 않는 기반 기술입니다.
핵심 요약:
1️⃣ 각 센서는 독립된 시계를 가지므로 시간 오차가 필연적으로 존재
2️⃣ 정확한 퓨전과 제어를 위해 타임스탬프 정렬 및 보정이 필수
3️⃣ ROS2에서는 message_filters + 하드웨어 트리거 + GNSS 동기화 조합이 이상적
결국 “모든 센서가 같은 순간의 세상을 바라보게 하는 것”이
정확한 인식, 안정적인 제어의 첫걸음입니다.