ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Time synchronization approaches

asked 2021-06-07 09:04:58 -0500

Leonti gravatar image

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/3797...

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

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_driverand 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 ntpserver and use it as a source of truth for another one: http://wiki.ros.org/ROS/NetworkSetup#...
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...
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.
Cheers!

edit retag flag offensive close merge delete

Comments

1

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.

gvdhoorn gravatar image gvdhoorn  ( 2021-06-07 10:07:02 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
3

answered 2021-06-07 13:38:55 -0500

tfoote gravatar image

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.

edit flag offensive delete link more

Question Tools

4 followers

Stats

Asked: 2021-06-07 09:04:58 -0500

Seen: 6,169 times

Last updated: Jun 07 '21