Ask Your Question

Can ROS timers be safe to clock jumps?

asked 2022-02-02 10:17:59 -0500

knxa gravatar image

updated 2022-02-02 10:30:39 -0500

Ubuntu 20.04, ROS noetic

It seems that ROS timers are not completely robust to clock jumps e.g. from daylight time savings.

I created a ros::WallTimer that triggered every second and logged the intervals with a std::chrono::steady_clock. Then I set back the clock 1 hour and then again 1 hour forward.

I get this output:

[ WARN] [1643816822.911882384] [/node]: tick 1.0
[ WARN] [1643816823.911713294] [/node]: tick 2.0
[ WARN] [1643816824.911731140] [/node]: tick 3.0
[ WARN] [1643816825.911736092] [/node]: tick 4.0
[ WARN] [1643816826.911609692] [/node]: tick 5.0
[ WARN] [1643813221.572964459] [/node]: tick 7.0    // lost timer tick after setting clock -1 hour
[ WARN] [1643813222.572882079] [/node]: tick 8.0
[ WARN] [1643813223.572958188] [/node]: tick 9.0
[ WARN] [1643813224.572914005] [/node]: tick 10.0
[ WARN] [1643816820.668951557] [/node]: tick 11.0   // extra timer tick after setting clock +1 hour
[ WARN] [1643816820.669097722] [/node]: tick 11.0
[ WARN] [1643816821.669390752] [/node]: tick 12.0
[ WARN] [1643816822.669412872] [/node]: tick 13.0

Does ROS1 have any ways to prevent these irregularities? Among other things I am concerned it affects certain heartbeat intervals in my system.

[EDIT] I notice that Ubuntu resets the clock seconds when I shift the hour:

Wed 02 Feb 2022 05:19:13 PM CET
Wed 02 Feb 2022 04:19:00 PM CET

... so this might explain some of the above. However it does not change the underlying problem: Does a steady timer exist in ROS1?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2022-02-05 12:06:51 -0500

lucasw gravatar image

updated 2022-02-05 12:08:01 -0500

I expect DST time jumps are not really time jumps because unix epoch time keeps marching forward behind the scenes regardless, and not at all the same as changing your system clock.

Why not use use std::chrono steady_clock as a timer when it matters? There's probably a not-ros C++ example of how to trigger a steady callback.

There could be a use case where a system is going to be disconnected from the internet for such a long time a backwards time jump could happen (, and a ros system needs to be running at the same time the re-connection happens, and if the timer isn't steady something bad happens?

(The std::chrono steady clock vs. system clock issue:

( is sort of related, maybe isn't a problem with modern Windows)

There are a lot of issues with nodes and timers not handling the non-wall ros clock jumping backwards in time which happens if you are looping playback of a ros bag: some stop functioning entirely, others report errors and recover- that kind of clock time jumping ought to be more of a first class feature, more ought to be done to test for that or make it much less likely a given node or library call implementer handles those jumps the wrong way.

Some ros2 std chrono steady clock discussion + plus simulation time and non 1:1 time:

edit flag offensive delete link more



Good comment about the DST time jumps, you are right that in typical use cases this will not affect my system. I actually just found a steady timer in ROS noetic, which is not documented in the wiki, but solves the problem I described above.

ros::SteadyTimer timer = nh.createSteadyTimer(ros::WallDuration(1.0), &MyClass::onTimer, this, false);

... and with a callback like:

void onTimer(const ros::SteadyTimerEvent& event);
knxa gravatar image knxa  ( 2022-02-07 01:18:21 -0500 )edit

Suggestion to have a steady Rate

lucasw gravatar image lucasw  ( 2022-02-07 08:47:50 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2022-02-02 10:17:59 -0500

Seen: 56 times

Last updated: Feb 05