🔧 LIO-SAM에서 LiDAR–IMU 타임스탬프 문제 해결 기록

3개의 Python 스크립트와 시간축 보정 로직 정리

---

0️⃣ 한 줄 요약

IMU 센서 시간과 ROS 시간이 서로 다른 시간축을 사용해 발생한 LIO-SAM 동기화 문제를,
IMU 시간의 증가 속도를 ROS 시간에 맞춰 선형 보정하고,
LiDAR와 IMU를 동일한 ROS 시간 기준으로 재스탬프하여
타임스탬프 오차를 100ms 이하로 안정화했다.

---

1️⃣ 문제 배경: 왜 LIO-SAM이 계속 불안정했나?

LIO-SAM은 구조적으로 다음을 전제로 한다.

• LiDAR 포인트가 측정된 시각
• IMU 측정값이 적분되는 시각

이 두 시간이 동일한 시간축에 있어야 한다.

하지만 실제 환경에서는 다음과 같은 문제가 발생했다.

• IMU timestamp
  → 센서 내부 시간 or 드라이버가 생성한 시간
• LiDAR timestamp
  → ROS time (PC 시스템 시간)

즉, 서로 다른 시계를 사용하는 상태였다.

그 결과:

• “IMU data too late / too early”
• deskew 실패
• 시간이 지날수록 누적되는 드리프트

👉 문제의 본질은
절대 시간 오프셋 + 시간 흐름 속도(Hz) 불일치였다.

---

2️⃣ 전체 해결 전략 (3단계)

단계	코드	역할
1	imu_timestamp_fixer.py	IMU 시간 → ROS 시간으로 선형 보정
2	simple_sync.py	LiDAR & IMU를 같은 ROS now 기준으로 통일
3	timestamp_check_synced.py	실제 시간차가 100ms 이하인지 검증

---

3️⃣ 1단계: IMU 시간축을 ROS 시간축으로 보정

(imu_timestamp_fixer.py)

이 단계가 유일하게 ‘시간 계산’을 수행하는 핵심 단계다.

🔹 핵심 아이디어

IMU timestamp를 그대로 쓰지 말고,
IMU 시간의 증가 속도 자체를 ROS 시간에 맞춘다.

---

🔹 기준 시점(anchor) 설정

첫 IMU 메시지가 들어온 순간을 기준점으로 삼는다.

if self.first_sensor_time is None:
    self.first_sensor_time = msg.header.stamp.to_sec()
    self.first_ros_time = rospy.Time.now().to_sec()
    return

• first_sensor_time : IMU가 말하는 “첫 시간”
• first_ros_time : 그 순간의 ROS 시간

👉 “같은 순간을 서로 다른 시계로 기록한 기준점”

---

🔹 시간 경과량 누적

이후 들어오는 IMU 메시지마다:

sensor_time = msg.header.stamp.to_sec()
ros_time = rospy.Time.now().to_sec()

sensor_elapsed = sensor_time - self.first_sensor_time
ros_elapsed = ros_time - self.first_ros_time

즉,

[
\Delta t{sensor} = t{sensor} - t0_{sensor}
][ \Delta t_{ros} = t_{ros} - t0_{ros} ]

---

🔹 스케일 팩터 계산

IMU 시간과 ROS 시간의 증가 속도 비율을 계산한다.

if sensor_elapsed > 0:
    scale = ros_elapsed / sensor_elapsed
    self.scale_factors.append(scale)

if len(self.scale_factors) < 100:
    return

scaling_factor = sum(self.scale_factors) / len(self.scale_factors)

수식으로 표현하면:

[
s = \text{mean}\left(\frac{\Delta t{ros}}{\Delta t{sensor}}\right)
]

• s > 1 → IMU 시간이 느리게 흐름
• s < 1 → IMU 시간이 빠르게 흐름

---

🔹 최종 보정된 IMU timestamp

corrected_elapsed = sensor_elapsed * scaling_factor
corrected_stamp = rospy.Time.from_sec(
    self.first_ros_time + corrected_elapsed
)

msg.header.stamp = corrected_stamp
self.pub.publish(msg)

즉,

[
t{imu}^{corrected}
= t0{ros}

• s \cdot (t{sensor} - t0{sensor})
  ]

👉 결과:

• IMU timestamp가 ROS 시간축으로 변환
• 장시간 실행 시 발생하던 드리프트 제거

---

4️⃣ 2단계: LiDAR와 IMU를 동일한 ROS 시간으로 강제

(simple_sync.py)

이 단계는 계산보다는 정책적 선택이다.

🔹 IMU 재스탬프

def imu_callback(msg):
    msg.header.stamp = rospy.Time.now()
    imu_pub.publish(msg)

🔹 LiDAR 재스탬프

def lidar_callback(msg):
    msg.header.stamp = rospy.Time.now()
    msg.is_dense = True
    points_pub.publish(msg)

👉 의미:

“센서가 언제 측정했는지”보다
“지금 처리되고 있는 시각”을 기준으로 통일

---

⚠️ 이 방식의 특성

• 장점

  • 큰 시간 오프셋 즉시 제거
  • LIO-SAM 안정성 확보

• 단점

  • 실제 센서 측정 시각이 아닌

    • 콜백 지연
    • 스케줄링 지연
      포함

➡ 정확도보다는 안정성을 우선한 구조

---

5️⃣ 3단계: 실제 동기화 오차 검증

(timestamp_check_synced.py)

🔹 최신 IMU / LiDAR 시간 비교

diff = abs(self.latest_imu_time - self.latest_lidar_time)

if diff < 0.1:
    rospy.loginfo(f"Synced OK: diff={diff:.4f}s")
else:
    rospy.logwarn(f"Time diff too large: {diff:.4f}s")

수식으로는 단순히:

[
\text{diff} = |t{imu} - t{lidar}|
]

---

🔹 판정 기준

• 100ms 이하 → 정상
• 그 이상 → 동기화 실패

👉 이 파이프라인의 명확한 목표는
“LIO-SAM이 요구하는 시간 조건(≤100ms)” 충족

---

6️⃣ 실제로 오차는 어느 정도까지 내려갔나?

✔ 코드가 보장하는 범위

• 100ms 이하
• 스크립트로 명시적 검증 가능

✔ 실제 체감 범위 (환경 기준)

• IMU: 100~200Hz
• LiDAR: 10Hz

➡ 일반적으로:

• 수 ms ~ 수십 ms
  ➡ 최악의 경우:
• LiDAR 주기 근처 (≈100ms)

즉,

“항상 5ms 이하”는 아니지만,
LIO-SAM이 안정적으로 동작하기엔 충분히 작은 범위로 수렴한다.

---

7️⃣ 이 과정을 한 문장으로 정리하면

IMU 센서 시간의 흐름을 ROS 시간에 선형 매핑해 드리프트를 제거하고,
LiDAR와 IMU 메시지를 동일한 ROS 시간 기준으로 재스탬프함으로써
LIO-SAM에서 요구하는 타임스탬프 동기 조건(100ms 이하)을 만족시켰다.

---

8️⃣ 정리하며

• 진짜 핵심 계산은 IMU 시간 스케일 보정
• simple_sync는 동기화 안정성을 위한 강제 정책
• timestamp_check는 문제가 해결됐음을 숫자로 증명하는 단계