RCL_ROS_TIME: how to get sim-time-aware monotonic timing?

[tonynajjar]

Description

When use_sim_time=true, an RCL_ROS_TIME clock sources time from the /clock topic. When use_sim_time=false, it falls back to RCL_SYSTEM_TIME unconditionally. This fallback is hardcoded in rcl.

There is currently no native way to create a clock that uses /clock in simulation and RCL_STEADY_TIME (monotonic wall time) on real hardware. The only two options available are:

• RCL_STEADY_TIME — monotonic but ignores sim time entirely
• RCL_ROS_TIME — sim-time-aware, but falls back to RCL_SYSTEM_TIME (not RCL_STEADY_TIME) on real hardware

This is a problem for any node that needs different clock behaviors for different purposes within the same node. For example, a controller node typically needs:

Use case	Real hardware	Simulation
Control loop timer	RCL_STEADY_TIME (monotonic, NTP-immune)	/clock
Message timestamps	RCL_SYSTEM_TIME (wall clock)	/clock

Today, both of these are impossible to satisfy with a single RCL_ROS_TIME clock because the fallback is always RCL_SYSTEM_TIME. Using the node's clock for a control loop timer silently introduces NTP sensitivity on real hardware.

Motivation

This came up in ros-navigation/navigation2#6063, which makes various Nav2 components sim-time-aware by switching from rclcpp::WallRate to rclcpp::Rate(freq, node->get_clock()). This is the right thing to do for simulation, but it silently changes the real-hardware behavior from RCL_STEADY_TIME (monotonic) to RCL_SYSTEM_TIME (NTP-adjustable), because that's the only fallback RCL_ROS_TIME supports.

Current workaround

The only workaround is to check use_sim_time at construction and branch between create_timer and create_wall_timer:

class Controller : public rclcpp::Node
{
public:
  Controller() : Node("controller")
  {
    if (get_parameter("use_sim_time").as_bool()) {
      timer_ = create_timer(100ms, std::bind(&Controller::control_loop, this));
    } else {
      timer_ = create_wall_timer(100ms, std::bind(&Controller::control_loop, this));
    }
  }

  void control_loop()
  {
    auto cmd = compute_velocity();
    cmd.header.stamp = now();
    pub_->publish(cmd);
  }
};

This is fragile — use_sim_time is checked once at construction, so runtime parameter changes are ignored. Every node or library that needs monotonic + sim-aware timing must duplicate this pattern. The same issue applies to rclcpp::Rate and rclcpp::WallRate, where there is no equivalent workaround at all.

Question

What is the intended way to get sim-time-aware monotonic timing in rclcpp? Is there an existing mechanism we are missing, or does rclcpp need a way to configure the fallback clock type for RCL_ROS_TIME?

[SteveMacenski]

A slightly different ask: But would Timer and Rate when not wall-rate always use non-NTP corrected times? I can see essentially no time that I would have a Timer or Rate object running at some fixed frequency when I want that frequency disrupted by NTP updates. Having the "real" time is useful in the context of now() or other things were you're looking at time values / comparisons, but asking for a function to be called at 10hz or sleep a loop at 1kHz, I can't think of a single instance where having the true corrected time is a net-benefit.

So I suppose my suggestion would be to build Rate / Timer such that it uses RCL_STEADY_TIME when not using Simulation Time as the straight-up policy.

[fujitatomoya]

as far as i know, there is no way that we can configure steady time with RCL_ROS_TIME is false... it is just hardcoded as you mentioned for now. i am not sure if this falls back only to system time intentionally. IMO user configuration would be useful as reported here.

suggested change would be adding a fallback_clock_type field to rcl_ros_clock_storage_t (defaulting to RCL_SYSTEM_TIME for backward compatibility), so when use_sim_time=false the clock falls back to whichever type the user configured instead of always using system time? @tonynajjar does that cover Nav2 requirement, right?

[tonynajjar]

That's also what I imagined at first, but even with this feature, it's not sufficient to set node clock to RCL_ROS_TIME with fallback RCL_STEADY_TIME because like mentioned, we still need RCL_SYSTEM_TIME in some instances, e.g. when setting msg timestamps.
I haven't thoroughly thought about the implications but maybe by default a node can have 2 clocks? One with RCL_ROS_TIME with fallback RCL_STEADY_TIME and the other RCL_ROS_TIME with fallback RCL_SYSTEM_TIME and the users uses each as they see fit?

[tonynajjar]

If we find a satisfying design relatively soon, I'm happy to contribute this as I'm currently in the weeds of this topic (although this is possibly a bigger redesign)

[fujitatomoya]

how about the following? just off the top of my head, need to consider more details before implementation, but i think that is doable.

• in rcl, make the fallback type configurable on rcl_clock_t (as discussed above)
• rclcpp::TimeSource, expose attachClock() / detachClock() publicly to user application so that multiple clocks are bound to the time source of the node.
• rclcpp::Clock, accept the fallback option in its constructor as user configuration. (in default, system time for backward compatibility)

🤔 or maybe some better design...

[jmachowinski]

Your run into one fundamental thing here. A sim clock is not guaranteed to be monotonic. Therefore if you have code using the steady time, and relying on the fact that this in fact monotonic, this code will break as sim time is non monotonic and can jump backwards.

A second thing to consider here is that this change will likely break users code. We use wall timers in cases, were we need to
process stuff periodically even if the simulation is stopped. E.g. QT event loops, or polling from third library network libraries.

If you now change the behavior of wall time while the sim is stopped you will break existing packages all over the place.

[tonynajjar]

A sim clock is not guaranteed to be monotonic

Just to understand, what makes you say that? Can't it be monotonic if we implement it to forcefully be monotonic, in whatever node publishes /clock?

[jmachowinski]

If I restart the simulator, it will jump back in time. Or if I replay a bag, and play it a second time, the sim time will jump back.
I don't see a sane way to implement monotonic behavior in these cases.

[tonynajjar]

I experimented with some solutions:

What I tried first (configurable fallback)

I initially implemented the configurable fallback @fujitatomoya mentioned on RCL_ROS_TIME — adding a fallback_clock_type field to the internal rcl_ros_clock_storage_t and a new rcl_ros_clock_init_with_fallback() function. The rclcpp side got a two-arg Clock(RCL_ROS_TIME, RCL_STEADY_TIME) constructor.

The problems I have with this approach:

• The type still says RCL_ROS_TIME, which by definition as falls back to system time — hiding a different fallback behind it is a semantic contradiction.
• sleep_until() and ClockWaiter need to know the fallback type to sleep on the right chrono clock, but it's buried in opaque storage — we'd need a getter or duplicate branching logic.
• Every switch(clock->type) in the codebase still sees RCL_ROS_TIME and assumes system-time fallback behavior.

What I'm proposing instead: RCL_ROS_STEADY_TIME

A new rcl_clock_type_t enum value that is like RCL_ROS_TIME but falls back to RCL_STEADY_TIME (monotonic) instead of RCL_SYSTEM_TIME when sim time is not active. This would have relatively few changes and would likely not even break ABI.
One con of this approach is naming confusion; It's not immediately clear what the difference between RCL_ROS_STEADY_TIME and RCL_ROS_TIME is. It would probably make sense to have RCL_ROS_SYSTEM_TIME but renaming RCL_ROS_TIME is heavily breaking so out of scope. Any better naming is welcome

Why this is better than the fallback approach

• No semantic contradiction — RCL_ROS_TIME still means "falls back to system time", always.
• The type carries the information e.g. every switch(clock->type) can handle it correctly without reaching into internals.
• Probably ABI-safe

Follow-up (maybe separate PR)

If we go with this approach, I would propose some breaking default changes that @SteveMacenski already alluded to:

Entity	Current Default	Proposed Default	Notes
Node::create_timer()	RCL_ROS_TIME	RCL_ROS_STEADY_TIME	Sim-aware + monotonic
rclcpp::Rate	RCL_SYSTEM_TIME	RCL_ROS_STEADY_TIME	Sim-aware + monotonic
Node::create_wall_timer()	RCL_STEADY_TIME	Deprecated	Use create_timer(RCL_STEADY_TIME) instead
rclcpp::WallRate	RCL_STEADY_TIME	Deprecated	Use Rate(hz, RCL_STEADY_TIME) instead
rclcpp::WallTimer	RCL_STEADY_TIME	Deprecated	Use create_timer with RCL_STEADY_TIME clock

The deprecations are no strong opinion, we can keep them as syntactic sugar but I don't really see the point given how easily we can create a Rate or Timer with any clock type

Happy to hear your feedback!

[tonynajjar]

@jmachowinski

If I restart the simulator, it will jump back in time. Or if I replay a bag, and play it a second time, the sim time will jump back.
I don't see a sane way to implement monotonic behavior in these cases.

I'm not exactly sure what new problem you are pointing out that would be introduced with this PR. Can you clarify? Today if a node uses sim time, it's dependent on the simulator and cant handle simulator restart. If it uses steady or system time, not dependent on simulator and no problem.

A second thing to consider here is that this change will likely break users code. We use wall timers in cases, were we need to process stuff periodically even if the simulation is stopped.

We should definitely have the option for a clock that is not dependent on sim time, even when use_sim_time is true (for other timers in the same node). For this case I'd say we just need to use RCL_STEADY_TIME and not RCL_ROS_STEADY_TIME.

[jmachowinski]

Your initial proposal was to run wall timers on sim time. This would create the new problem, that wall timers then could jump backwards in time.
Before there was a clear semantic difference between wall and non wall timers and clocks.
The introduction of a new RCL_ROS_STEADY_TIME looks like the only way forward from my point of view. But from a semantic point of view it is a total mess.