Open mcamurri opened 5 days ago
Hi @mcamurri,
The ouster-ros driver currently adds -37
seconds (by default) to the timestamps values returned when PTP mode is used but you can easily prevent this by resetting the launch parameter ptp_utc_tai_offset
to zero. Other than that all the time values reported are mainly coming from the sensor. So a difference of 2 years suggests that the sensor isn't running in Sync. This may happen when:
Can you examine the the output of GET /api/v1/time/ptp
and check the status and reported timestamps.
Also since this doesn't appear to be a driver problem it might be a good question to post on Ouster https://community.ouster.com.
I actually thought of the opposite, that there is some problem with the driver (perhaps a mismatch with the SDK since it seems old).
I'm not using a ethernet-usb adapter, and I have used the same computer with many other ouster devices before with no problem. Further, as shown by the outputs, the PTP is working correctly on the machine.
I'll ask someone to the lab to post the output of the HTTP call you suggested.
As you suggested, the issue has been reposted here: https://community.ouster.com/t/huge-delay-about-2-years-in-ros-messages-timestamps-when-using-ptp/195
I actually thought of the opposite, that there is some problem with the driver (perhaps a mismatch with the SDK since it seems old).
No the SDK version shouldn't impact the PTP as the SDK C++ client wasn't updated for the last two releases. In any case, the SDK client will be updated to a more a recent version as part of #363
I rarely use PTP in my daily development routine so I can't tell for certain that the ouster-ros driver is at fault here, but this part of the code wasn't much altered since it was introduced. As I noted above the driver merely forward the timestamp it receives from the sensor. The only thing that the driver does in addition to the SDK is by default it subtracts 37 seconds when PTP mode is in use but this can be easily eliminated by passing ptp_utc_tai_offset:=0
to the launch command. This is done to align the reported time with the machine time which typically uses UTC.
Describe the bug When the lidar is set in PTP mode, the timestamps produced have a fixed offset of
74986812
seconds (about 2 years) on a correctly configured machine with a PTP supported NIC.The output of
lspci -nnk | grep -A2 Ethernet
is:The output of
ethtool -T enp45s0
is:The Ouster diagnostic and ptp config files are attached here: diagnostic_and_config.zip
To Reproduce
connect the lidar to the ethernet port (in my case
enp45s0
) and set it to link local modeOn one terminal, run the
ptp4l
utility (config file is attached):the output is as follows:
On another terminal, run the
phc2sys
to sync the NIC to theCLOCK_REALTIME
:Example output:
On a third terminal, run the compiled driver:
Monitor the delay:
example output is:
which is consistent with the timestamps, which are in the order of
165xxxxxxx
nanoseconds while the actual ones from all other sensors are172xxxxxxx
The PTP syncing is correct as evidenced by the outputs above, but as double check the output of the
CLOC_REALTIME
and the NIC itself are also in sync:Screenshots Configuration on the dashboard (everything was left untouched except for the PTP timestamp mode on the Ouster):
Platform (please complete the following information):
OS-1-128
ousteros-image-prod-bootes-v3.1.0+20240426041747
)noetic
Ubuntu 20.04
with kernel6.1.100-0601100-generic
x64
origin/master
as of 12 Sep 2024 (e59e9a4bd53a1a65a6f99f09d3bbbf35a0aea806). Note that at this hash, the submodule for the ouster-sdk points to: 2898060 which is from Oct 2023