Time Synchronization Discussion
Description
In general, there are three widely-used time synchronization methods in autonomous vehicle systems: hardware-based, software-based, and hybrid. For the best possible accuracy, my recommendation is usually a hardware-based approach but with software-based additions that complement the hardware. However, in Autoware.Auto, we can't assume that the user has the ability to do hardware-based synchronization as this usually involves some form of custom interface module which distributes either a PPS (pulse-per-second) signal or an NTP (or other protocol) message to each sensor and compute device. As such, we should offer at least recommendations (if not an out-of-the-box solution) for a software-only approach.
Typical ROS Approach
ROS usually represents an authoritative time source in the form of a topic with the message type sensor_msgs/TimeReference
. Then, some local system synchronization method must be used to synchronize the system clock on the ROS compute node with that time source. The ntpd_driver
package is available in Foxy to perform this function. You can then either configure the default ntp
client in Ubuntu (or other host OS) to synchronize with the provided time source. Optionally, you can use chrony
as the synchronizer which is more flexible and OS-agnostic. With this configuration, you can assume that the system clock (and, by extension, ROS time) accurately represents an authoritative time source.
Sensor Time?
The source of the sensor_msgs/TimeReference
is left to the user. Some GNSS drivers produce this message but many do not. Additionally, some other sensors (like Velodyne lidars) also have GNSS-based time inputs which can be published from the sensor driver. However, only one authoritative time source should be used per ROS ecosystem to avoid conflicts and inaccuracies.
The following are just some of the problems can arrise when trying to calculate actual sensor acquisition times from a given sensor relative to the "received-at-the-ros-interface" time:
- The sensor has no internal timing system
- The sensor has an internal timing system but doesn't expose the time data through an interface
- The sensor has an internal timing system and exposes it through an interface, but it is only relative time from sensor start-up
- The sensor has an internal timing system, exposes it through an interface, and it is based on an absolute time source, but the time data provided through the interface is only a subset of the full time/date (looking at you, Velodyne)
- The sensor has an internal timing system, exposes it through an interface, is based on absolute time, and provides the full time/date through the interface, but the ROS driver doesn't support reading it
For Autoware to attempt to provide a somewhat robust, software-based implementation, all of the above problems (and others that I'm sure I'm missing) must be solved for every sensor to get accurate, system-based timestamps on the ROS messages.
Questions
- Should Autoware even attempt to provide a solution to this problem to its users?
- Am I missing some obvious, hardware-based method that we could recommend/provide?
- Should we even attempt to use a software-based-only approach? Would it be considered "safe?"