[Gazebo] /rbq/odometry의 header.stamp가 `--sim` 옵션에서도 wall clock인 이슈

[mqjinwon]

현상

시뮬(--sim)에서 DdsBridge가 게시하는 /rbq/odometry, /rbq/imu, /rbq/joint_states의 header.stamp가 Unix wall clock이다.

같은 버스에서 sensor_bridge(ros_gz_bridge, use_sim_time: true)가 게시하는 /rbq/imu/IMU_state stamp는 /clock과 같다.

시간축이 둘이다. 시뮬 시각이 벽시계보다 느려지면 odom stamp는 벽을 따라가고 /clock은 뒤처진다.

재현

--sim 스택과 물리 시뮬을 띄운 뒤:

ros2 topic echo /clock --once
ros2 topic echo /rbq/imu/IMU_state --field header.stamp --once
ros2 topic echo /rbq/odometry --field header.stamp --once
ros2 topic info /rbq/odometry -v

/rbq/odometry publisher는 _CREATED_BY_BARE_DDS_APP_. ROS 노드가 아니라 use_sim_time 파라미터가 없다.

같은 세션, 4 s 간격 예:

	Δstamp
/clock	4.15 s
/rbq/odometry	4.50 s

코드

rbq_sdk_cpp/include/Timer.hpp:

static double GetTime() {
    std::chrono::time_point<std::chrono::system_clock> t =
        std::chrono::system_clock::now();
    auto timestamp = std::chrono::duration_cast<std::chrono::nanoseconds>(
        t.time_since_epoch()).count();
    return (timestamp * 1.0e-9);
}

--sim과 무관하게 Unix epoch다.

scripts/sim.bash의 --sim은 물리 시뮬 연결이다. stamp를 /clock으로 바꾸는 플래그는 없다.

sensor_bridge.launch.py의 ros_gz_bridge만 use_sim_time: True. /rbq/imu/IMU_state는 이 경로. /rbq/odometry는 DdsBridge payload라 타지 않는다.

기대

--sim이면 /rbq/odometry의 header.stamp가 /clock과 같은 시간축이도록 설정하기.

• /clock과의 차이가 시간에 따라 커지지 않는다 (dt_odom ≈ dt_clock).

stamp를 채우는 곳은 --sim일 때의 Timer::GetTime() 또는 DdsBridge. 시뮬 시각 소스는 이미 받는 sim tick이거나 /clock. /clock 전에는 stamp를 올리지 않거나, 첫 clock 이후부터 맞춘다.

[ktpark08]

오랜만입니다 진원님! 제보 감사합니다.

지적하신 내용 확인했고, 재현 절차와 원인 분석 모두 정확했습니다.

확인 결과

두 갈래로 나뉘어 있었습니다.

• /rbq/odometry 와 local_world → base_link TF 는 이미 develop 에서 /clock 축으로 옮겨져 있었습니다. 시뮬 시각을 아직 못 받은 구간에는 아예 발행하지 않도록도 돼 있고요 — epoch 스탬프가 한 번 섞이면 이후 시뮬 시각 샘플이 tf2 버퍼에서 "과거"로 영구 거부되기 때문입니다. 다만 이건 마지막 릴리스(v1.16.11) 이후에 들어간 변경이라, 릴리스 바이너리로 보시면 여전히 wall clock가 맞습니다.
• /rbq/imu 와 /rbq/joint_states 는 여전히 wall clock였습니다. 이슈에 세 토픽을 같이 적어주신 게 정확했고, 이쪽은 남아 있던 진짜 누락입니다.

조치

--sim 일 때 /rbq/imu, /rbq/joint_states 의 header.stamp 도 /rbq/odometry·TF 와 같은 시뮬 시각을 쓰도록 맞췄습니다. 이제 네 토픽 모두 /clock 과 같은 시간축이라 dt ≈ dt_clock 이 되고, 시뮬이 wall clock보다 느려져도 벌어지지 않습니다.

시뮬 시각 소스는 말씀하신 대로 이미 받고 있던 값입니다 — 물리 시뮬이 보내는 상태 메시지의 헤더 스탬프가 gz 의 sim clock 이라 별도 /clock 구독 없이 그대로 씁니다. 실기(--sim 없음)에서는 종전과 동일하게 wall clock입니다.

/rbq/motion/heartbeat, /rbq/robot_status, /rbq/battery 는 의도적으로 wall clock로 두었습니다. 프로세스 생존·텔레메트리 성격이라 실제 경과 시간이 맞고, use_sim_time 소비자와 시간 정합을 맞출 대상이 아니라고 봤습니다. 혹시 이쪽도 /clock 이어야 하는 사용 사례가 있으면 알려주세요.

다음 release 에 반영되면 이 이슈에서 다시 알려드리겠습니다. 좋은 제보 감사합니다! 🚀

[mqjinwon]

경태님 빠른 회신 감사드립니다! 좋은 시뮬레이터 덕분에 잘 개발하고 있습니다 :)

말씀해주신 것과 같이 /rbq/motion/heartbeat, /rbq/robot_status, /rbq/battery 토픽은 굳이 /clock 과 동기화될 필요는 없을 것 같습니다.

본 이슈와 별도로 시뮬레이션에서 /rbq/battery 값을 조절할 수 있도록 걸수 있는 파라미터가 있을까요? 시뮬레이션 상에서 시나리오 검증시 활용하고 싶습니다.

[ktpark08]

안녕하세요, 진원님! 시뮬레이터가 개발에 도움이 되고 있다니 저희도 기쁩니다 :)

배터리 값 조절에 대해서는, 현재 시뮬레이션에서 /rbq/battery 값을 설정할 수 있는 파라미터는 없습니다.
/rbq/battery 는 --sim 에서는 CAN 이 없어 0 % / 0 V 로 고정되어 있습니다.

시나리오 검증 용도로 필요하시다는 점은 잘 이해했습니다. 시뮬레이션 모드에서만 잔량·전압·충전 상태를 외부에서 주입할 수 있는
방법(예: sim 전용 토픽 또는 REST 엔드포인트)을 검토해 보고, 추후 업데이트에 포함할 수 있을지 살펴보겠습니다.
진행 상황이 생기면 이 스레드에 다시 공유드리겠습니다.

감사합니다.