Time Synchronization

In CRS hardware experiments with cars, communication between the CRS platform on the host computer and the cars happens over Wi-Fi, which is subject to delays, jitter and packet loss.

However, the sensor measurements from the cars need to be correlated to the instant of time in which they were taken. To that goal, the cars and the host computers synchronize their clocks to timestamp each measurement and packet.

In short, the cars connect to an NTP server and synchronize their clock. For more detail, see below

Network Time Protocol (NTP)

The Network Time Protocol (NTP) is a standard protocol to synchronize a machine's clock to a variety of different clock sources of varying accuracy and trustworthiness, subject to delays in networks.

A client seeks to synchronize its clock with a server, which is the time source. In our setup, we have that the CRS host computer is the time source, while the cars are the clients.

NTP Server in CRS

To serve the local time of the host machine, we spin up a second Docker container next to CRS, cturra/ntp that serves the local time of the host machine as a time source in the CRS network.

The cars already know the IP address of the host machine from their usual connection. The port is standardizes to 123, so the cars will automatically discover the server when they connect to CRS.

At boot, the cars start synchronizing their clock. As soon as they are synchronized, they will timestamp their packets with the Unix timestamp in microseconds. If for some reason the cars cannot find the NTP server, they will timestamp all packets with the timestamp 0, which is detected on CRS side.

All messages published in ROS that are related to sensor measurements from the cars then get the correct timestamp that corresponds to the measurement instant on the car attached.