Disable timestamp checking with zenoh-dds-bridge?

[Yadunund]

Hi there,

We have a couple of machines on the same local subnet but running ROS 2 nodes on different DDS domains IDs. We've deployed a zenoh bridge on each machine to selectively bridge certain ROS 2 endpoints. Once we disconnected these machines from the internet, their systems clocks go out of sync. As a result the bridges start throwing errors about timestamps that are significantly out of sync. Wondering if there is a way to disable timestamp checking of zenoh packets? Or is it better to have one of the machines serve as an NTP server and have others sync with this machine?

[JEnoch]

Hi @Yadunund,

Short answer:
currently the zenoh-bridge-dds are timestamping by default and there is no option to disable this.
However, you can get rid of those logs about timestamps exceeding the delta by increasing the delta value.
For this, define such environment variable: UHLC_MAX_DELTA_MS=86400000. This means the log won't occur if the clock drift between your 2 system clocks is less than 1 day (86400000 milliseconds)

Long answer:
zenoh-bridge-dds requires timestamps and thus synchronised system clocks for a correct behaviour of TRANSIENT_LOCAL support.
Lets consider your ROS 2 nodes on different domains IDs are publishing on the same topic with TRANSIENT_LOCAL QoS. If host A has a drifting clock in the future wrt. host B, whatever the real order of publication between the 2 hosts, the data published by host A might always have a greater timestamp than those published by host B.
On the subscription side, the bridge receiving those data over Zenoh reorder them by timestamp before publishing over DDS. And a ROS 2 reader with HISTORY KEEP_LAST=x might always get the latest publications from host A only, despite host B made more recent publications.
Thus , for some use cases, it would be better to setup some synchronisation of clocks between the hosts.

[Yadunund]

Hi @JEnoch,

Many thanks for the detailed response. Really appreciate it. There are some endpoints with TRANSIENT_LOCAL durability so I guess clock sync is the way to go.

On a slightly unrelated note,
Host A is a ROS 2 service server and Host B and Host C are service clients that make requests. What i've noticed is that as soon as one of Host B or Host C is able to make a service call and get a response from the server, the other Host is unable to discover the service (it keeps retrying and sometimes succeeds after several minutes). I'm using the 0.6.0 version of the zenoh bridge.

The problem does not exist when I have 3 terminals on the same PC running the service/client nodes on different domain ids and have a zenoh bridge that bridges the service across these domains on localhost. The only difference in the zenoh config files between this test case and the one described above is the IP address in the tcp_connect parameters. (ie ["0.0.0.0:7447"] vs [192.168.50.1:7447]

I'm wondering if you have an explanation for this. Would PR eclipse-zenoh/zenoh-plugin-dds#108 fix this?

[Yadunund]

Fixing the time delta issue also resolved this so I'll close this ticket. Again, thanks for the quick solution!