Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Late /clock delivery under use_sim_time stalls node now() for ~0.33 s (found via ros2_control controller time)

Đang mở
  • Có gì không ổn?
#3,329 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@JeremiahM37 đang làm issue này rồi.

Từ ngày 16/10/2026.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
10/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp
Lĩnh vực
distributed-systems, robotics

Hướng nghiên cứu

The issue is an open investigation, not a fix: it asks whether a 0.33 s gap in /clock delivery under use_sim_time is expected, and whether now() on a RCL_ROS_TIME clock should hold still or extrapolate. Reproducing it needs the Gazebo and ros_gz_bridge setup from ur_sim_control.launch.py plus a recorder for /clock arrival times. Done would mean a maintainer-level answer on where the stall originates (bridge or DDS) and whether the clock path is at fault.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

With use_sim_time=true, a node's now() (and the controller manager's time, which is built on it) can hold still for about 0.33 s while the simulator keeps running. Gazebo's own clock stream is smooth in the same run, so the gap appears after Gazebo publishes /clock: either in ros_gz_bridge or in DDS delivery to the subscriber. I have not yet separated those two.

This matters for ros2_control, which uses the node clock to time controllers. A frozen clock freezes the controller's reference, and the arm then jumps when the clock catches up. Related: ros2_control#3683 (issue) and #3684 (PR, which makes the controller manager use the time argument it is given when sim time is in use).

What we measured

Setup: ROS 2 Jazzy (RoboStack), rmw_fastrtps_cpp with FASTDDS_BUILTIN_TRANSPORTS=UDPv4, Gazebo Harmonic empty world, UR5e via ur_simulation_gz (ur_sim_control.launch.py), 24 busy CPU-bound processes on a 32-core host. Arm commanded through example_move (12 runs, all succeeded).

Run of 420 s:

Source Largest arrival gap Gaps > 0.2 s
Gazebo transport /world/<w>/clock, subscribed directly 0.100 s 0
/clock on ROS, after ros_gz_bridge 0.335 s 8 (0.333–0.335 s) plus one at 0.213 s

The same load on mujoco_ros2_control (basic demo, arm moving, 6 × 60 s): no /clock gap over 0.2 s, and the largest lag between /clock and the controller-manager time in /joint_states was 32 ms. Its /clock comes from a physics thread in the same process, with no bridge.

Earlier A/B on the same Gazebo setup, from the ros2_control issue: the unpatched controller manager aborted 7 of 60 trajectories, and the patched one 0 of 60. Those aborts all coincided with /clock gaps of 0.27–0.33 s, with controller time frozen during each gap.

What I'd like rclcpp's view on

  1. Is a 0.33 s stall in /clock delivery to a use_sim_time node expected behaviour, or a defect in the clock subscription path?
  2. Is it expected that now() on a RCL_ROS_TIME clock holds still while /clock is late, rather than extrapolating from the last stamp?
  3. Does the answer change if the stall is caused by the bridge process rather than DDS? If it's a bridge issue, I'll raise it in ros_gz.

Related: #2535 (timer callbacks delayed under simulation time), #3122 (no sim-time-aware monotonic clock).

Reproduce

export FASTDDS_BUILTIN_TRANSPORTS=UDPv4
ros2 launch ur_simulation_gz ur_sim_control.launch.py   # arm and controllers
# 24 busy processes:  python3 -c "while True: pass" &
# record /clock arrival wall times (reliable QoS, depth 100) and /joint_states stamps,
# and drive the arm with JointTrajectory goals

The recorder and analysis scripts are available on request.

Ngôn ngữ chính
C++
Star
815
Fork
572
Merge trung bình
6 ngày 8 giờ
Pull request đã merge (30 ngày)
20

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ros2/rclcpp

Tất cả issue của ros2/rclcpp

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.