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.
Originally posted by bc524 on ROS Answers with karma: 43 on 2022-09-19
Post score: 0
Original comments
Comment by Mike Scheutzow on 2022-09-19:
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.
Comment by gvdhoorn on 2022-09-19:
Isn't 0.000000003 seconds, 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.
Comment by bc524 on 2022-09-19:
@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?
Comment by gvdhoorn on 2022-09-20:
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.
Comment by bc524 on 2022-09-20:
@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.