comparison between zenoh vs FastDDS Discovery Server v2

[ros2torial]

In this article (https://zenoh.io/blog/2021-03-23-discovery/) it seems like zenoh is compared with normal DDS discovery which is definitely slow and not scalable. Is there any comparison of Zenoh with FastDDS Discovery Server v2 Discovery Data to get the latest comparison.

[ros2torial]

I experimented on comparison between zenoh vs FastDDS Discovery Server v2. In my setup there are 10 robot PC and 1 Fleet management system PC (FMS PC). In case of FastDDS Discovery Server v2, each robot PC only shares meta data like encalve info of around 424 bytes to FMS PC and gets meta data like guid info of around 488 bytes from FMS PC. This is happening every 3 seconds. So there are 2 meta messages from each robot PC to FMS PC and in total 20 meta messages from all robot PC to FMS PC.

In case of zenoh, each robot PC is running zenoh client and FMS PC is running zenoh router. Each zenoh client receives meta info(127 bytes) of router as well as all the other clients. so here each zenoh client recieves 10 meta messages from router and shares one meta message to router every 2.25 seconds. In total there are 11*10 meta messages. Means it is order of n square which increases traffic.

From this results, it seems like FastDDS Discovery Server v2 is efficient than zenoh.

[JEnoch]

each zenoh client (192.168.7.250) sends a KeepAlive message to zenoh router(192.168.7.17) and receives three messages from the zenoh router which I guess is KeepAlive message of other 3 zenoh clients. Why are we getting three messages from zenoh router?

Your guess is correct: each bridge publishes a KeepAlive message which is subscribed by the 3 other bridges.
So each KeepAlive message goes to the router which routes it to the 3 other bridges.

That indeed causes a n-square traffic between the robots for mutual supervision. But that's required for the implementation of some DDS QoS such as Liveliness and Transient.
Such p2p traffic also occurs with plain DDS, but probably also using the FastDDS Discovery Service. I'm not sure why you don't see such robot-to-robot traffic using the Discovery Service. We would need to reproduce your setup to analyse.

Note we're working on replacing this KeepAlive protocol with a new Zenoh built-in liveliness mechanism that will reduce the traffic: the mutual supervision will rely on the user data traffic and thus will not cause additional traffic.

The discovery messages are usually not periodic, but are rather sent at startup and/or at of an application.
Did you also manage to measure those ones ?
I didn't measure those messages as they were not periodic so I guess won't be an issue .

Those initial discovery messages are actually the major issue that ROS2 users encounter over wireless networks or over the internet.
This initial traffic can be huge: each ROS2 node publishes discovery information for each DDS Publisher and Subscriber it has (plus 2 for each Service and 8 for each Action), and an update on ros_discovery_info topic for each. All those discovery messages are received by each ROS2 node.
This traffic floods the network at startup, introducing latencies and possible messages loss in wireless networks, leading to "false death" detections, and re-publications, and to more flooding...

[JEnoch]

I observed that if DDS plugin is not used in robot side(i.e. running zenohd in robot), then the zenoh client on robot only receives one message from zenoh router every 2.25 sec. But if we use DDS then the zenoh client on robot receives more message from zenoh router every 2.25 sec. I tried many options but couldn't solve it.

Sorry, I don't understand: you confirmed that what you call "zenoh client" is actually a "zenoh-bridge-dds", right ?
So if in the robot you only run zenohd and not zenoh-bridge-dds, what's the "zenoh client" ?

Do you mind joining our Discord ? https://discord.gg/vSDSpqnbkm
So we could have a direct chat and I can better understand your experiments and results. I'm usually online on CET time zone working days.

[ros2torial]

Those initial discovery messages are actually the major issue that ROS2 users encounter over wireless networks or over the internet.

I didn't compare the initial discovery messages between zenoh and FastDDS Discovery Server v2. Surely I will conduct this experiment too. Although in terms of periodic data case FastDDS Discovery Server v2 seems to be efficient than zenoh since it doesn't cause n-square traffic.

I conducted an experiment last week where the periodic data of Zenoh and FastDDS Discovery Server v2 is compared -

Data exchange per second using wifi network	FastDDS Discovery Server v2	Zenoh (peer-clients-udp)
One publisher(1 robot) one subscriber(FMS PC)	516 bytes/sec	221.888 bytes/sec
Two publisher(2 robot) one subscriber(FMS PC)	1000 bytes/sec	556.666666667 bytes/sec
Ten publisher(10 robot) one subscriber(FMS PC)	5000 bytes/sec	7298.88889 bytes/sec

As we can observe from the data that for single robot case zenoh is good although as we increase the number of robots zenoh becomes inefficient because of n-square traffic.

Sorry, I don't understand: you confirmed that what you call "zenoh client" is actually a "zenoh-bridge-dds", right ?
So if in the robot you only run zenohd and not zenoh-bridge-dds, what's the "zenoh client" ?

Sorry, for confusion. Here each robot is running zenoh client by using either zenohd or zenoh-bridge-dds whichever provides better functionality and features. I am experimenting with both for now.

Also, I am unable to join discord from the above link. Will try again later.

[JEnoch]

Which applications are you running as publishers and subscriber ?
RO2 nodes? Plain DDS pub/sub? Plain Zenoh pub/sub in your experiment with zenohd?

[ros2torial]

I am ruining ROS2 nodes as publishers and subscriber. In case of single publisher and single subscriber these are the commands used for above experiment -

FastDDS

PC 1 (192.168.1.153)

Terminal 1
fastdds discovery -i 0
or
fastdds discovery -i 0 -l 192.168.1.153 -p 11811

Terminal 2

export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
export ROS_DISCOVERY_SERVER="192.168.1.153:11811"
ros2 run demo_nodes_cpp listener

PC 2 (192.168.1.113)

Terminal 1

export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
export ROS_DISCOVERY_SERVER="192.168.1.153:11811"
ros2 run demo_nodes_cpp talker

Zenoh

PC 1 (192.168.1.153)

Terminal 1

export ROS_LOCALHOST_ONLY=1
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
ROS_DOMAIN_ID=1 ros2 run demo_nodes_cpp listener

Terminal 2
zenoh-bridge-dds -d 1 -m peer -a /chatter -l udp/192.168.1.153:7447 --dds-localhost-only

PC 2 (192.168.1.113)

Terminal 1

export ROS_LOCALHOST_ONLY=1
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp
ROS_DOMAIN_ID=2 ros2 run demo_nodes_cpp talker

Terminal 2
zenoh-bridge-dds -d 2 -m client -a /chatter -e udp/192.168.1.153:7447 –dds-localhost-only