Rosanswers logo

I have a simple rover using ROS2 Foxy with a lidar running on Raspberry Pi and the rest of the stack running on Ubuntu PC (localization, navigation and odometry).

AMCL is complaining about extrapolation into the future as soon as I turn on the Lidar: https://answers.ros.org/question/379705/amcl-failed-to-transform-initial-pose-in-time/

This got me thinking about clock synchronization between nodes on my Ubuntu PC and the Raspberry Pi. Ubuntu PC is synchronised using ntp which is the default. Raspberry Pi is synchronized using Chrony which is provided by Balena.io docker environment: https://www.balena.io/docs/reference/OS/time/

Should this be enough or can it still cause a discrepancy that might cause TF issues?
How common is it to have more specialized time synchronization and how necessary it is? Is it ok to synchronize 2 machines by just using ntp, or should one be synchronized by the time from the other?

So far I've seen these approaches:

  1. Use ntpd_driver and publish clock time from one computer and use it to synchronize time on another: https://index.ros.org/r/ntpd_driver/
  2. Directly set one computer as ntp server and use it as a source of truth for another one: http://wiki.ros.org/ROS/NetworkSetup#Timing_issues.2C_TF_complaining_about_extrapolation_into_the_future.3F
  3. Just make sure both computers use ntp and that's enough

Approach #1 is called a "typical ROS approach" here: https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/922
How typical is it?
Every tutorial or video I've seen so far doesn't even mention time and clock synchronization so it seems like default approach #3 should work for most of people.
Or approaches #1 and #2 are just omitted because it's understood that you need to synchronize clock of one computer from the clock of another one if you don't want to have timing issues?

Just looking for a general guidance here.

Originally posted by Leonti on ROS Answers with karma: 62 on 2021-06-07

Post score: 0

Original comments

Comment by gvdhoorn on 2021-06-07:
You tagged this ros2, so this is somewhat off-topic, but I believe it still works: chrony is typically used in situations where Wall-clock sync is not as important, but sync between two hosts is. You don't mention it, so I thought I would.

If host1 syncs to some (internet) NTP server, and host2 syncs to host1 using chrony, in the end the result should be identical, but in case neither host1 nor host2 have internet access (or access to an ntpd via some other means), chrony between host1 and host2 will at least keeo their clocks synchronised.


1 Answer 1


Rosanswers logo

The primary ROS tutorials do not mention time as they make the assumption that your hosts have synchronized walltime. This is discussed in: http://wiki.ros.org/Clock

The most standard way to synchronize over the network is using the chrony ntp agent (Your #3) . During PR2 development we spent a lot of time figuring out how to coordinate effectively and we found nothing that out performed chrony's ntp agent. To get the best results you can set it up in a higherarchical manner if you have a group of machines on an internal robot network which is then connected over wifi to a larger network (your #2). Chrony has a lot of logic for detecting and measuring network latency and network drops while making it's estimates which is why it out performs most other agents.

I have not personally used the TimeReference plus ntpd_driver packages. This his highly dependent on your time source and locality of that time source. For latency purposes that topic is likely only best used in localhost or very well connected networks. This mechanism is best used when you have an accurate hardware clock locally connected such as a GPS device. This can be very powerful in an autonomous car use case such as autoware, with one or more high precision GPS devices and very low latency networks locally. However, if it's just a raspberry pi on the network I would strongly suggest going with the simpler solution. NTP via Chrony was good enough for the PR2 to leverage it's actively tilting laser and moving arms simultaneously from different computers.

Originally posted by tfoote with karma: 58457 on 2021-06-07

This answer was ACCEPTED on the original site

Post score: 3


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.