-
Notifications
You must be signed in to change notification settings - Fork 2
Time Synchronization
This tutorial was created by Simon-Pierre Deschênes (Thanks 🎉).
Typically, a robotic system is composed of multiple sensors, each streaming data with their own timestamps. In order to put in relation these different measurements, it is important that they are timestamped in a coherent way. For instance, if a camera detects that a car must take a left turn in 5 seconds and that the command is sent 6 seconds later, a crash can occur. In order to ensure coherent timestamping of all the data, the clocks of the different devices on the robot must be synchronized.
This protocol is used to synchronize the clocks of multiple devices over a network. To do so, packets are sent between devices with information about the current time of their clock.
If a client sends a packet to a server at time t0, there will be a communication delay and the packet will be received on the server at time t1. Then, if the server sends back a packet to the client at time t2, there will be another communication delay and the packet will be received by the client at time t3. Times t0 and t3 were stamped by the client clock while times t1 and t2 were stamped by the server clock. Knowing all these timestamps and assuming that the communication delays between the client and server were the same in both directions, it is possible to synchronize a client clock to a server clock. This works in theory, but in practice, the communication delay is not always the same in both directions. This can lead to offsets of several hundreds of milliseconds between a computer and an atomic clock when synchronizing over the internet. However, on small networks with no congestion, a synchronization accuracy of around 1 millisecond can be achieved with NTP.To estimate the quality of the time delivered by a time server, a stratum is assigned to each time source. The stratum of a source is the number of leaps it takes to get to the original clock that computed the delivered time.
For instance, in the above figure, the time servers (second row), to which the atomic clocks are connected, would have a stratum of 1. The computers in the row below, which are secondary time servers, would have a stratum of 2, since it would take at least two leaps to get from these computers to the atomic clocks in this network configuration. Finally, the computers in the last row would have a stratum of 3. Since typically, time sources with a higher stratum are less accurate, it is preferable to synchronize with the sources having the lowest stratum. Furthermore, in order to avoid loops in the synchronization chain, devices are only allowed to synchronize with time sources that have a lower stratum than them.Chrony is an implementation of NTP. It is a tool for Unix that allows to synchronize the clocks of multiple devices. Once the time offset of a computer with a time source is computed using NTP, this computer can be synchronized by speeding up or slowing down its clock. Chrony will not instantly correct the clock of the computer, because a jump in time could lead to inconsistent behavior in time-dependent programs running on this computer, especially if the jump is in the past. The only exception to this rule is during the initialization of the computer. Only then can Chrony directly set the time of the clock to the correct time. Once the initialization phase is passed, jumps in time are not allowed. During normal operation, Chrony will select the best time source in its list (i.e., the one with the lowest stratum) and synchronize with it regularly. Chrony can also combine the information coming from multiple time sources to estimate a better time.
Chrony can be installed using the following command in a terminal on Ubuntu:
sudo apt install chrony
In order to synchronize a client to a server, Chrony must be installed on both computers. When Chrony is installed, a service that runs at startup is created. To query the status of this service, use the following command:
sudo systemctl status chrony
The following subsections will detail the configuration needed on a client and server computer that we would like to synchronize together.
To edit the configuration file of the server, run this command in a terminal on the server computer:
sudo vim /etc/chrony/chrony.conf
The following lines detail the time sources with which this computer is synchronized:
pool ntp.ubuntu.com iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1
pool 2.ubuntu.pool.ntp.org iburst maxsources 2
They can be removed if no outside time synchronization is wanted. The following line describes the conditions under which Chrony can perform a jump in time during initialization. In this case, a jump in time is allowed on the three first clock updates if the offset is greater than one second.
makestep 1 3
The following line must be added at the end of the file to allow time synchronization requests coming from the 192.168.0.0
sub-network.
allow 192.168.0.0/24
The following line must also be added if time synchronization is still wanted when internet is not available on the server. It specifies that when no outside time source is available, the stratum of the server computer is assumed to be 10.
local stratum 10
Once we are done editing the configuration file, the Chrony service needs to be restarted for the changes to take effect. It can be done using the following command:
sudo systemctl restart chrony
To edit the configuration file of the server, run this command in a terminal on the server computer:
sudo vim /etc/chrony/chrony.conf
The following lines detail the time sources with which this computer is synchronized:
pool ntp.ubuntu.com iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1
pool 2.ubuntu.pool.ntp.org iburst maxsources 2
They can be removed if no outside time synchronization is wanted. The following line describes the conditions under which chrony can perform a jump in time during initialization. In this case, a jump in time is allowed on the three first clock updates if the offset is greater than one second.
makestep 1 3
The following line must be added at the end of the file to allow time synchronization with the server computer that we set up previously.
server 192.168.0.2 iburst prefer
In this case, the IP address of the server computer was 192.168.0.2
, but it needs to be adjusted.
The iburst
parameter tells it that it must wait two seconds before making four-request bursts when synchronizing.
The prefer
parameters tells it that this time source is to be preferred over other sources that don't have this flag.
Once we are done editing the configuration file, the Chrony service needs to be restarted for the changes to take effect.
It can be done using the following command:
sudo systemctl restart chrony
The current time of the software clock (or system clock), which is the clock Chrony synchronizes, can retrieved using the following command:
date
The current time of the hardware clock, which can also be synchronized by Chrony if the parameters are set accordingly, can be retrieved using the following command:
sudo hwclock
It is possible to see which time sources are used by using the following command:
chronyc sources -v
If more information about time synchronization is wanted, the following command can be used:
chronyc tracking
- Warthog Teach and Repeat (ROS1)
- Warthog Teach and Repeat (ROS2)
- Time Synchronization
- Deployment of Robotic Total Stations (RTS)
- Deployment of the backpack GPS
- Warthog Emlid GPS
- Atlans-C INS
- How to use a CB Radio when going in the forest
- IP forwarding
- Emlid Data Postprocessing (PPK)
- Lessons Learned
- Robots' 3D Models
- Order Management
- Fast track Master → PhD
- Intellectual Property
- Repository Guidelines
- TF Cheatsheet
- Montmorency Forest Wintertime Dataset
- RTS-GT Dataset 2023
- Deschenes2021 Dataset
- TIGS Dataset
- DRIVE Datasets
- BorealHDR
- TimberSeg 1.0
- DARPA Subterranean Challenge - Urban Dataset
- How to upload a dataset to VALERIA
- ROS1 Bridge
- Migrating a repository to ROS2 (Humble)
- ROS2 and rosbags
- MCAP rosbags
- DDS Configuration (work in progress)
- Using a USB Microphone with ROS2
- ROS2 in VSCode
- ROS2 Troubleshooting