FastDDS in low-bandwidth ROS2 environment

[Krzo99]

Hi all,

I'm making a mobile robot using ROS2 and FastDDS. The said robot can be monitored in Rviz2.
Robot is mostly running in good internet connection, however, it can happen that the signal gets very weak. In this case, the robot should continue working as previously commanded. As I'm not yet 100% versed on FastDDS, I'll explain my thinking and I hope somebody can help me.

The problem

With default FastDDS configuration in low-bandwidth moments, publishers (data_writters) block the main thread for a long time.
This happens as they are set to SYNC publish mode by default. So low bandwidth means low upload speed, and it can take multiple seconds to upload anything (Talking about < -80dB signal) (even with BEST_EFFORT ROS2 QoS).

I tried solving this with a ASYNC publish mode, however, the data rate is still so low, that, as it says in the DOCS, it blocks when the send queue is full. What solved this was setting <non_blocking_send>true</non_blocking_send> in a custom <transport_descriptor>. However, subscribing to topics (from PC & Robot) from the same node tops-up the queue again, and no other topics are added or transmitted. Does each ros2 node have one queue, or does each publisher have its own queue?
This is a big problem, as some topics might be subscribed by both, Rviz2 and the Robot at the same time. I guess I could create seperate publishers for some topics. One for on-robot and one for sending over network.

The Solution?

Ideally, I want to achieve the following:

• All communications between nodes on the robot should run in SYNC publish mode, to make sure they are delivered. The QoS would then be configured in ROS2.
• Any communications from the robot over WLAN0 interface would be in ASYNC non_blocking mode. So any topic, going through wlan0 would not block, and optimally, it wouldn't even be added to send queue & sent if bandwidth was too low. Or maybe, the sending would be killed, if it took too long, or if the data-rate was too low, or if the queue already had some topics in it.

The first solution would be easy.
The second, however, I'm not sure how to tackle.
I guess, making separate publishers that are only subscribed on a remote PC for topics that are needed by both, PC and robot.
Could I create multiple <transport_descriptor> tags, all with <type>UDPv4</type>, and each with separate <interfaces>?
Would that work, however I'm not sure what interface to put for any transport that happens only on the robot.
Something like this:

<profiles>
    <transport_descriptors>
        <transport_descriptor>
            <transport_id>internal_transport</transport_id>
            <type>UDPv4</type>
        </transport_descriptor>

        <transport_descriptor>
            <transport_id>wlan0_transport</transport_id>
            <type>UDPv4</type>
            <non_blocking_send>true</non_blocking_send>
            <interfaces>wlan0</interfaces>
        </transport_descriptor>
    </transport_descriptors>

    <participant>
        <rtps>
            <useBuiltinTransports>false</useBuiltinTransports>
            <userTransports>
                <transport_id>wlan0_transport</transport_id>
            </userTransports>
        </rtps>
    </participant>
</profiles>

I would then assign ASYNC to individual topics that go over wlan0.
But I'm not sure how do I make sure wlan0_transport is used with publishers (and not internal_transport)?
If nothing else, I could create a custom publishing class, that would handle wlan0 publishing. But I hope that isn't needed.

Is my train of thought correct?
Thanks for all your help!

[Mario-DL]

Hi @Krzo99,

Thanks for using Fast DDS and ROS 2. Leaving some suggestions that may help in the scenario you propose

• Isolating localhost nodes in a domain and have the wlan0 nodes to communicate via another domain using transport with <non-blocking-send>.
• Using unique network flows for the wlan entities.
• Using Discovery server to use dedicated channels and separate node groups.

Anyways, if you need further help to setup your architecture, please contact our commercial support at [email protected].