How to reduce drift in system time using Chrony?
I currently have 2 devices communicating with one another. A Roscube-X acting as the master and a Jetson Orin as its slave.
I'm running an NTP server on the roscube with the Orin acting as a client using chrony.
However, there is a drift in the system time as the duration goes on.
Time drift at launch after restarting chrony using chronyc tracking:
Time drift after a few minutes:
While extremely minor, the drift increases over time. Is there a way to further reduce/delay the drift?
My chrony.conf has the following:
server <roscube ip> minpoll 0 maxpoll 5 maxdelay .000000005
initstepslew 2 <roscube ip>
dumponexit
dumpdir /var/lib/chrony
pidfile /var/run/chronyd.pid
logchange 0.5
sched_priority 1
local stratum 10
allow 127.0.0.1/8
It is only connected to the ROSCube's NTP terminal as a source.
ros works fine if the host time-of-day clocks are within 0.001 second. Please explain what ros problem you are having that requires synchronization many orders of magnitude better than 1e-3.
Isn't
0.000000003seconds, 3 nanoseconds?I'd agree with @Mike Scheutzow: unless you are dealing with very fast mobile robots (or sensor data which encodes phenomena where delta-t must be very small as state variables change very fast), a 3 nanosecond difference between two clocks would seem like it should be OK.
@Mike Scheutzow@gvdhoorn
Sorry, I'm still new to to ros. Planning to link multiple sensors (camera, lidar) to the two devices for use in mapping, so I was unsure if the drift would cause an issue in the long run as it kept increasing over time. Would this still be ok?
Not really an answer, but only you would be able to determine whether a drift of 3 nanoseconds over 3 minutes would be acceptable.
If you don't have any requirements which tell you otherwise right now, I'd suggest to perform some tests and determine whether the performance is sufficient for whatever use-case(s) you have. I doubt anyone here would be able to tell you whether things "would [..] be ok" like this.
Although, 3 ns per 3 minutes drift would lead to 60 ns per hour, which is still well below what would probably become problematic for almost all use-cases. And typical time-synchronisation setups implement periodic syncing, so there would likely not even be the cumulative drift you appear to expect.
@gvdhoorn
alright, thanks for the information. I only left it at max a few hours and it kept going up, so I thought it was cumulative.
I tried to test it out and play a bagfile on one device and is played on the other. Having some issue when it comes to IMU data, but all the other types seems to be working fine.
Thanks.
udpate: the imu issue was solved lowering the rosbag play rate.