Ros2: use_sim_time leads to inconsistent clocks

General
1

Hello everyone,

I think, the current design of simulated clocks and the parameter use_sim_time lead to major problems and should be reworked. Here are my issues:

The use_sim_time parameter is available on every node and instructs that node to use the /clock topic as a time source. This allows nodes to run slower or faster e.g. during simulation or playing a bag file.

In ROS1, this was a global parameter, so every node had the same configuration. However, in ROS2, this parameter needs to be set on each node individually. This is a major design flaw because it is very easy to end up with an inconsistent clock source, leading to unexpected and undefined behavior.

Every node means:

  • All simulation launch files
  • All launch files and nodes, started separately for testing
  • All dynamically loaded Gazebo plugins (that start a Node)
  • All GUI tools (rviz, rqt, ā€¦)

To make matters worse, ros2 launch does not have the functionality to set this parameter, so you need to manually insert it in every launch file that you want to start individually in simulation, cluttering the file. And it is very easy to forget to set it.

How many of you created a dedicated launch file for rviz to start it with use_sim_time for simulation? Probably not many. If not, you ended up with an inconsistent time setup, probably without even realizing it.

It is not a use-case to start a setup with inconsistent clocks. Therefore, it should not be possible. The time source should be unique and identical for all nodes by design.

I think, there is a pretty straight-forward solution. During the transition from ROS1 to ROS2, the robot description was moved from a global parameter to a topic, probably for the same reason. Consequently, the clock should follow the same approach and the /clock topic exists already.

4 Likes
2

I thought ROS 2 added a way to set a parameter ā€œin a namespaceā€ that affects all nodes in the namespace (during launch time). But Iā€™m not sure when/which version.

Also, not all nodes necessarily need to share the same clock. You can have some nodes that need no clock at all. In ROS 1 it was the nodelet load node that unncecessarily spent large % CPU just decoding /clock messages which got thrown away. Or you can have some other realtime monitoring/HITL node that just needs to run according to the real time.

But all in all, I share your request. It would be great to have a centrally-configured sim time. What about environment variables?

3

Thanks for your comment.

There is a ā€œSetParameterā€ command for launch files that sets a parameter for all nodes in the same scope. This makes the problem somewhat more manageable but you still need to add this (parameterized) for each individually started launch file, even just for testing. That becomes annoying very fast.

I see, that there are special cases where you would not want the time synchronization. But I would argue that these are exceptions and not the general rule. For these nodes, you could still remap the clock topic to some other name.

Environment variables would not work in a multi-computer setup. I think it is essential to generally ensure a unique time source for all connected nodes.

4

Can anyone share a link to this ā€˜SetParameterā€™ command? Iā€™ve searched through the ros 2 launch repo but couldnā€™t find anything.

5

My experience with setparameter for sim time on a larger scope is that it didnā€™t work. We ended up putting a parm on every node and launch input and piping it through all launch files.

If you thought ROS1 was bad in terms of the chance of using wrong parameter values, or accidental defaults, Ros2 says hold my beer and one ups it ten fold. Yes itā€™s powerful, but itā€™s a terrible user experience in 90% of use cases.

1 Like
6

Fully agreed, this is really annoying and can easily lead to errors. The suggestion to use /clock for this makes sense for me, itā€™s the only thing thatā€™s really universally available.

btw, for quite some time, we have used a check script in our launch files that queries the parameters of all nodes present and makes sure they have a consistent use_sim_time settings. Itā€™s not a great solution, but maybe it can help people until this is fixed in a better way.

7

@Martin-Oehler

I am just trying to understand the requirement here. IMO, there are 2 different things we are asking here? i may be mistaken, could you clarify the following?

The time source should be unique and identical for all nodes by design.

I think it is essential to generally ensure a unique time source for all connected nodes.

i think when we use simulation time, we already have unique time source from /clock topic for everyone subscribes on that topic?

maybe the problem comes up when nodes use system time if they are deployed to multiple physical OS instances?

in this case, there are multiple time source from different systems.

are you suggesting that we should be time synchronization mechanism in ROS 2 for this system time?

In ROS1, this was a global parameter, so every node had the same configuration. However, in ROS2, this parameter needs to be set on each node individually.

Or just simply suggesting, we should have global switch for entire ROS 2 network (maybe under domain identification) to control use_time_time?

thanks,
Tomoya

8

I think this is what youā€™re looking for
launch_ros/actions/SetParameter

9

In ROS2, the time source is only identical and unique, if all nodes use the same value for use_sim_time. However, as detailed in my original post, it is very cumbersome and error-prone to ensure that.

So yes, my suggestion is to have either a) a central switch for the use_sim_time parameter or b) get rid of the parameter and always use the /clock topic.

I think, option b) would simply turn out as defaulting use_sim_time to true. If there is a time source available on the /clock topic, every node uses it, otherwise the system clock is used.

1 Like