Glossary

Fictionlab > Glossary > Time synchronization (PTP)

Time synchronization (PTP)

Time Synchronization (PTP) – definition

Time synchronization is the process of aligning clocks in separate computing and sensing devices to a common time base. In mobile robotics, the relevant mechanism is often the Precision Time Protocol (PTP), standardized as IEEE 1588-2019. PTP distributes time over packet networks, most commonly Ethernet in robotics, and estimates path delay between a clock source and synchronized devices.

For a UGV, synchronized time makes sensor measurements comparable even when they are produced by different devices and processed on different computers. A LiDAR point cloud, IMU sample, stereo frame, GNSS fix, wheel odometry message, and camera image must refer to a consistent timeline before they can be fused by SLAM, visual-inertial odometry, localization, or perception algorithms.

PTP is different from ROS 2 time management. ROS 2 provides time abstractions and the /clock topic for simulated or externally controlled ROS time. PTP synchronizes operating-system and hardware clocks at the network level. A robot can use both mechanisms: PTP for physical sensor timestamps and ROS time for simulation or replay.

Why PTP matters on mobile UGV platforms

Sensor fusion depends on the time difference between observations. If a rover moves while a sensor timestamp is offset, a measurement is associated with an incorrect robot pose. This creates motion distortion in point clouds, reprojection error in camera pipelines, and degraded state estimation.

For a differential-drive platform such as Leo Rover, timing affects the relationship between wheel odometry, IMU angular velocity, and external perception sensors. Leo Rover has a Raspberry Pi-based compute unit and can run ROS 2 distributions such as Humble, subject to operating-system and image support. PTP operation depends on the Ethernet controller, Linux kernel driver, network switch, and connected sensor support. A software-only clock can be synchronized, but hardware timestamping is preferable where the hardware provides a PTP Hardware Clock (PHC).

Raph Rover can use the same synchronization architecture when it carries multiple Ethernet sensors or an external compute unit. Its larger payload capacity can accommodate additional networking hardware, GNSS receivers, LiDAR units, or edge computers, but this does not remove the requirement to validate timestamp quality end to end.

How IEEE 1588 PTP works

PTP organizes devices into a clock hierarchy. In the default Best Master Clock Algorithm, the best clock becomes the grandmaster clock. Other devices synchronize their local clocks to it. IEEE 1588 defines ordinary clocks, boundary clocks, transparent clocks, and management mechanisms.

In the common end-to-end delay mechanism, a slave derives its offset from timestamped message exchanges. The basic calculation assumes symmetric network delay.

mean_path_delay = ((t2 - t1) + (t4 - t3)) / 2
clock_offset    = (t2 - t1) - mean_path_delay

In this notation, t1 is the grandmaster transmit time, t2 is the slave receive time, t3 is the slave transmit time, and t4 is the grandmaster receive time. Asymmetric links, queueing, unstable oscillators, and missing hardware timestamps can increase error.

PTP message exchange normally includes the following message types:

  • Sync and optionally Follow_Up messages from the master.
  • Delay_Req messages from a slave in the end-to-end mechanism.
  • Delay_Resp messages containing the master-side receive timestamp in the end-to-end mechanism.
  • Announce messages used for grandmaster selection.

Two-step PTP uses a separate Follow_Up message to provide a precise transmit timestamp after the Sync message. This is useful when a network interface obtains the hardware transmit timestamp after packet transmission.

PTP, ROS 2 timestamps, and sensor messages

ROS 2 messages commonly store acquisition time in std_msgs/msg/Header. The timestamp field uses builtin_interfaces/msg/Time, which contains signed seconds and unsigned nanoseconds. Message types such as sensor_msgs/msg/Image, sensor_msgs/msg/Imu, sensor_msgs/msg/PointCloud2, and sensor_msgs/msg/NavSatFix include a header.

A ROS 2 node should preserve a sensor-provided timestamp when that timestamp is traceable to the PTP domain. Replacing it with the computer’s receive time adds variable transport and driver latency. The ROS 2 time design distinguishes system time, steady time, and ROS time; use_sim_time affects ROS time but does not configure PTP. See the ROS 2 clock and time design document.

Clock source Typical role on a UGV Important limitation
PTP grandmaster Common Ethernet time reference Requires compatible network configuration
GNSS receiver with PPS Absolute UTC traceability outdoors Needs satellite reception and valid receiver configuration
Host system clock ROS 2 node and log timestamps May drift without synchronization
ROS 2 /clock Simulation and deterministic replay Not a replacement for sensor clock synchronization

Linux implementation and validation

On Linux, the linuxptp project provides ptp4l for IEEE 1588 synchronization and phc2sys for synchronizing the system clock to a PHC. Hardware capability should be checked before deployment. The ethtool -T output identifies timestamping modes and available PTP hardware clocks.

ethtool -T eth0
sudo ptp4l -i eth0 -m -s
sudo phc2sys -s eth0 -c CLOCK_REALTIME -w -m

The -s example configures the local port as a slave. Actual deployment requires a selected PTP profile, transport mode, domain number, grandmaster source, and network topology. A managed switch must support the intended PTP behavior when boundary-clock or transparent-clock operation is required.

Validation should include more than checking that ptp4l is running. Engineers should inspect reported master offset, frequency adjustment, path delay, clock state, packet loss, and sensor timestamp consistency in recorded ROS 2 bags. Recordings should retain the original message header timestamps for later analysis.

Limitations and integration decisions

PTP does not automatically synchronize every sensor on a robot. USB cameras, serial IMUs, and low-cost GNSS receivers may expose host-receipt timestamps only. Their data can still be used, but the integration must document timestamp origin, transport latency, and expected jitter.

Before deploying PTP on Leo Rover or Raph Rover, verify these implementation points:

  • Confirm that every Ethernet sensor supports IEEE 1588 or a documented compatible profile.
  • Check whether the host network interface exposes hardware timestamps through Linux.
  • Use a GNSS-disciplined grandmaster when absolute outdoor time is required.
  • Keep all devices in the same PTP domain unless a deliberate multi-domain design is used.
  • Test synchronization while motors, cameras, LiDAR, and logging workloads are active.

Normative references and standards

The primary PTP reference is IEEE 1588-2019, published by IEEE as the revision of IEEE 1588-2008. Automotive and time-sensitive networking deployments may also use IEEE 802.1AS, the generalized PTP profile for time-sensitive applications. Profile compatibility must be verified because IEEE 1588 devices are not necessarily interoperable with every profile configuration.

See also