[ros-users] [Discourse.ros.org] [Next Generation ROS] Of clocks and simulation, betimes and otherwise

[Kye Morton]

As a precursor, I am definitely not an expert in the field. Also I'm not 100% versed on ROS2, so some of this may be off.

For the end goal, I think a good aim would be a local node that runs in the background and serves out time requests to other nodes as they request then (similar to how roscore is launched if it isn't running when using roslaunch). If this node is not running, then any other given node should interface with the system wall clock.

If the clock node is run, then it should publish to a clock topic. If a clock topic is already published, then the clock node should subscribe and run time calculations based off of the topic. This could also allow for a clock node to be run on multiple machines, and allow them to semi-transparently sync to a common node (step time forward to the message most in the future by default?).

As for the message itself, I think that a default rate of 1Hz should cover enough for most uses. When a system connects to another, there will have to be some ping exchange to make sure the network delay is accounted for (and maybe the clock nodes should do this every so often to keep calculating delay). If it is set up well, then it should be quite accurate at low frequencies, but it also should inherently allow much higher frequencies (perhaps 1000Hz might be overkill in most applications simply due to flooding the link?).

An approach for the clock nodes to use should follow something like ntp, and I feel that most of the diagnostic info shown in things like chrony (https://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/sect-Checking_if_chrony_is_synchronized.html) would be key in allowing the clock skew and frequency skew be automatically calculated by the clock node.

I think having a multiplier set in the message would be a good call, as it would allow systems with conflicting expectations to reject sync messages (sure this adds more configuration, but it ensures your system is all on the same page). This would also allow you to run a stand-alone system in slower or faster time easily by specifying such parameters in the launch file.

Another advantage is that for systems that my disconnect and then reconnect, a system like this could allow for a graceful handover in those moments without disrupting each individual local ROS clock node.

Another improvement may be to allow a "time-since-node-start" (rather than just the current ros::Time() wall time) function to allow nodes that rely on difference in time for loop control to not panic as time syncs externally. Could also allow for ROS_INFO to log with the synced wall time while the node runs on its own "clock" for relative time calculations.

Hopefully that makes enough sense to be useful for you!






---
[Visit Topic](https://discourse.ros.org/t/of-clocks-and-simulation-betimes-and-otherwise/1587/2) or reply to this email to respond.