Start with ros2 topic echo /health/status (or rqt_robot_monitor): it names the item and,
for TF, the likely cause. Then the status topics: odometry/status, localization/status,
navigation/status, control/status.
The follower stops when the robot pose (map -> base_link) is older than
safety.tf_timeout_sec (0.5 s). tf2 answers at the latest time every edge of the chain has, so
the oldest edge decides; normally the LiDAR-inertial edge camera_init -> body (a 100 ms scan
plus 20–80 ms of processing: 0.15–0.35 s in total).
Measure the sensor clock offset. Compare header.stamp of /livox/lidar (and
/livox/imu, /Odometry, the camera info) with the host clock at reception, for example the
median over 10 s. Normally 0.10–0.15 s; much more, or the year 1970, means the LiDAR runs on
its own clock.
Find the old edge.ros2 run tf2_ros tf2_monitor map base_link shows the average and
maximum delay per edge. A large and stable delay of camera_init -> body points to the
clock; a fluctuating one to load. Health says the same: steady (source clock offset?) or
varying (system load?).
Check between machines.chronyc tracking on each computer: the offset must be below
1 ms on a LAN (clock.enabled: true lets health watch it).