As this is a common and frequent issue that is faced in Nav2 in both simulations and non-sim, this issue will describe possible solutions. The root cause of the issue is due to timestamps of messages published by ROS nodes used by Nav2 being unsynchronized. The solutions are described as follows:
-
Check whether all ROS nodes are on sim-time if using simulation. If non-sim, check whether the same time is being reflected on both the host machine and the remote server by running timedatectl on both. If the times are drastically different, then it is most likely due to the machines being on different timezones which can be easily configured. However, if the different is a few minutes, or if the timezones are the same, then it could be a problem with the NTP service. Run timedatectl status on both machines and check whether the NTP service is active. If it is, check whether System clock is synchronized. If it is not, then the issue is most likely with your router. Check that the router is connected to the internet so the time server can be accessed. If it is, then it could be possible that packets necessary for synchronization are being dropped by your router. To fix this, increase the value of RootDistanceMaxSec in /etc/systemd/timesyncd.conf and apply the changes with sudo systemctl restart systemd-timesyncd.service.
-
However, if the above does not work, you could either manually set the time with sudo date -s "2025-07-27 12:00:00" as an example, but do note that you would need to be quite accurate at setting the time, and that you need to manually set the time everytime you restart your machine or remote server.
-
Lastly, you may choose to set the source_timeout parameter in collison_monitor as 0.0 to prevent Nav2 from blocking your robot from moving due to unsynchronization, although the robot may not perform as expected. You may also increase the source_timeout, but that will also lead to navigation issues. As such, this is the last option you should resort to.
As this is a common and frequent issue that is faced in Nav2 in both simulations and non-sim, this issue will describe possible solutions. The root cause of the issue is due to timestamps of messages published by ROS nodes used by Nav2 being unsynchronized. The solutions are described as follows:
Check whether all ROS nodes are on sim-time if using simulation. If non-sim, check whether the same time is being reflected on both the host machine and the remote server by running
timedatectlon both. If the times are drastically different, then it is most likely due to the machines being on different timezones which can be easily configured. However, if the different is a few minutes, or if the timezones are the same, then it could be a problem with the NTP service. Runtimedatectl statuson both machines and check whether the NTP service is active. If it is, check whether System clock is synchronized. If it is not, then the issue is most likely with your router. Check that the router is connected to the internet so the time server can be accessed. If it is, then it could be possible that packets necessary for synchronization are being dropped by your router. To fix this, increase the value ofRootDistanceMaxSecin/etc/systemd/timesyncd.confand apply the changes withsudo systemctl restart systemd-timesyncd.service.However, if the above does not work, you could either manually set the time with
sudo date -s "2025-07-27 12:00:00"as an example, but do note that you would need to be quite accurate at setting the time, and that you need to manually set the time everytime you restart your machine or remote server.Lastly, you may choose to set the
source_timeoutparameter in collison_monitor as 0.0 to prevent Nav2 from blocking your robot from moving due to unsynchronization, although the robot may not perform as expected. You may also increase thesource_timeout, but that will also lead to navigation issues. As such, this is the last option you should resort to.