uXRCE-DDS bridge multicast UDP addresses and ports

PX4 Autopilot Telemetry (Comms) 📡
1

Dear community,

I am running two PX4 autopilot SITL instances with the uXRCE-DDS bridge (micro-xrce-dds-bridge udp4 -p 8888) and I try to understand what address / port is used for each ROS2 topic :

  • I am using Cyclone DDS : RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
  • Each PX4 instance is launched in a separate terminal and restricted to use a unique Network interface
    export CYCLONEDDS_URI=<path_to_this_config_file.xml> :
 <?xml version="1.0" encoding="utf-8"?>
 <CycloneDDS
    xmlns="https://cdds.io/config"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd"
>
    <Domain Id="any">
        <General>
            <Interfaces>
                <NetworkInterface name='tun0' />
            </Interfaces>
        </General>
    </Domain>
</CycloneDDS>
  • Each network interface is assigned an IP address (tun0 is 192.168.0.1, tun1 is 192.168.0.2)

The second PX4 instance points to a network interface called “tun1”. Routes are configured between the network interfaces, ping works, ros2 demo pub/sub examples also works.

Using a quick Wireshark analysis, i can see the discovery protocol of DDS at play on the UDP multicast address 239.255.0.1:7400, which I understand.
However, it seems that the PX4 instances are talking to the UDP multicast addresses :

  • 239.255.0.7:10317 with approx. 10 messages per second (UDP traffic)
  • 239.255.0.7:10318 with approx. 1 message per second (UDP traffic)

image
image1525Ă—251 53.5 KB

Questions:

  • How did the uXRCE-agent decided to use 239.255.0.7:[10317;10318] to create the DDS topics ?
  • Is it something configurable from the uXRCE-DDS client side (PX4 side) ?

If anyone has the knowledge to answer these questions, this would highly help me ! :slight_smile:
Thanks in advance, TB

PS: this setup is in simulation only for now, but ultimately, my questions apply to real-life deployment also, with each UAV having its own network stack, PX4 autopilot and uXRCE-agent on the onboard computer.

1 Like
2

Hi @Theotime_Balaguer

This confuses me: shouldn’t be 239.255.0.2? see Client API — eProsima Micro XRCE-DDS 2.1.1 documentation and Micro-XRCE-DDS-Agent/include/uxr/agent/config.hpp.in at 9311555dd0edc960f12852f8223c4458d9da39e0 · eProsima/Micro-XRCE-DDS-Agent · GitHub

On the client side you can only specify the IP address and port where the client expect to find the Agent, in simulation it is set to the localhost 127.0.0.1, port 8888

3

Hi @Benja

Thank you for your answer. In the OMG’s DDSI-RTPS interoperability specification, the default address and port for the discovery protocol is 239.255.0.1:7400. From DDSI-RTPS v2.5 document :

image
image1097Ă—243 14.8 KB

So, I would say it is normal for the uXRCE-DDS Agent to announce itself on this address / port. I was using the snap package of uXRCE-DDS. I changed it to source installation from github, the behaviour is the same :

image
image1001Ă—328 55.1 KB

While looking in details at the data inside the packets, I noticed these UDP mutlicast flows are actually the publisher/subscriber middleware of Gazebo (the simulator I use)…

So, actually, the uXRCE-DDS bridge is following OMG’s guidelines. :upside_down_face:

For future users that may end-up here, here is my take on the question :

  • The uXRCE-DDS bridge uses 239.255.0.1:7400 to discover other DDS participants
  • When multiple participants subscribe to the same topic, DDS uses UDP multicast 239.255.0.1:7401 to distribute the messages
  • Gazebo simulator transport layer uses the multicast address 239.255.0.7, don’t get baited (see these lines and this PR)

Thanks Benja for insights on the client side and your help understanding the situation !

1 Like
4

Glad that you figured it out!

I must say, I still don’t really understand this

Why do you say that 239.255.0.1:7400 is the discover address and port for uXRCE-DDS even if the code says 239.255.0.2:7400 ?

5

Well, you are right, some unknown magic is at play here…

Fact is that the multicast address 239.255.0.2:7400 is never used in my system, while the Micro-XRCE-DDS bridge is up and running.

At this day, I cannot explain why 239.255.0.2 is not used. :frowning:

6

Could it be that 239.255.0.2:7400 is used by another process (not the agent) and the agent is just not using the multicast feature?

7

Hi @Benja,

Your question made me want to try another method, with a “cleaner” environment than my machine, so I came up with a very simple and reproducible process. I set up a network namespace in my linux environment and launch three programs from within the netns :

Wireshark monitors all the UDP multicast groups :

image
image1001Ă—315 50.9 KB

Still no use of 239.255.0.2:7400. So you are probably right, the Agent doesn’t use multicast, which seems smart considering there is only one machine subscribed to its topics.

So, I added a new network namespace, linked it to the first netns (the one running the Agent) and launched another instance of PX4 in it ./PX4-Autopilot/build/px4_sitl_default/bin/px4 -i 1.

If everything goes well, it should launch the uXRCE-DDS Client and activate the discovery protocol on 239.255.0.2:7400 as stated in the docs, but in my case using wireshark I see no message going to this IP address (and the Client-Agent connection doesn’t work for the second UAV).

PS: I can ping one netns from the other and vice-versa, and I see announcements coming from the foreign netns on 239.255.0.1:7400, so probably not a network problem.
For that matter, I can see the ROS2 topics from the first PX4 in the second network namespace, so the DDS Domain ID is not in cause, there is a DDS connectivity between the two namespaces.

Could it be a bug ?