Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#3,329 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@JeremiahM37 已经在做这个了。

开始于 2026年10月16日。

评估

难度
5/5
预计耗时
一周以上
新手友好度
10/100
Issue 类型
缺陷
描述清晰度
需要澄清
活跃度
活跃
技术栈
cpp
领域
distributed-systems, robotics

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
C++
星标
815
派生
572
平均合并
6 天 8 小时
30 天内合并 PR
20

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

ros2/rclcpp 的其他 Issue

查看 ros2/rclcpp 的全部 Issue

相似的 Issue

更多 C++ Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。