Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#3,329 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@JeremiahM37 ci sta già lavorando.

Dal 16/10/2026.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
10/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
distributed-systems, robotics

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C++
Stelle
815
Fork
572
Merge medio
6g 8h
PR unite (30g)
20

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ros2/rclcpp

Tutte le issue di ros2/rclcpp

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.