Best effort QoS messages larger than UCLIENT_UDP_TRANSPORT_MTU not published

[jimmy-mcelwain]

I am using the Micro-XRCE-DDS-Client with micro-ros using UDP, and I have been running into a problem where I am trying to publish a message of type joint_state using rmw_qos_profile_sensor_data, which uses best effort reliability.

I am able to publish without a problem if my message size is under the UCLIENT_UDP_TRANSPORT_MTU, but if my message exceeds that size, then it does not publish.

It does, however, publish correctly if I change the QoS profile to something with reliable reliability, such as rmw_qos_profile_default, or if I increase the UCLIENT_UDP_TRANSPORT_MTU to be larger than the message.

Unless I misunderstand something or something is wrong in my configuration, it seems to me like the serialization/deserialization is not working properly for messages with best-effort reliability.

[jimmy-mcelwain]

Here's a simple program that demonstrates what I am talking about:
https://github.com/jimmy-mcelwain/issue394/blob/main/main.c

[pablogs9]

Hello @jimmy-mcelwain,

DDS-XRCE standard does not define mechanisms for fragmenting XRCE Best Effort payloads.
So that means: if you are using the Best Effort XRCE stream your payload size will be restricted to MTU less overheads.

Notice Best Effort XRCE stream does not mean Best Effort DDS Publisher. Using Micro XRCE-DDS Client you can create a DDS Reliable Writer that uses a Best Effort XRCE Stream (client <-> agent communication).

Unfortunately in micro-ROS, Best Effort Writer/Readers will use Best Effort XRCE streams and Reliable Writer/Readers will use Reliable XRCE Streams. Check here for reference.

If you need to send bigger payload using the micro-ROS API you will need to increase the MTU or use a reliable configuration.

If you are using Micro XRCE-DDS API directly, you can create a rmw_qos_profile_sensor_data QoS compatible DataWriter that uses a XRCE-DDS Reliable stream.

[gavanderhoorn]

Thank you @pablogs9 for your response.

Using Micro XRCE-DDS Client you can create a DDS Reliable Writer that uses a Best Effort XRCE Stream (client <-> agent communication).

wouldn't that basically make the whole communication 'chain' best effort?

If you are using Micro XRCE-DDS API directly, you can create a rmw_qos_profile_sensor_data QoS compatible DataWriter that uses a XRCE-DDS Reliable stream.

to make sure we understand you correctly, would that mean the communication between the Agent and the Client would be reliable/using a reliable stream, while between the Agent and other DDS readers best effort reliability would be used?

[pablogs9]

wouldn't that basically make the whole communication 'chain' best effort?

Yes

to make sure we understand you correctly, would that mean the communication between the Agent and the Client would be reliable, while between the Agent and other DDS readers best effort reliability would be used?

That's it. In general, the Client (XRCE or micro-ROS) communicates with the Agent and the Agent communicates with the DDS dataspace. So you have two independent levels of reliability, from client to agent, and from agent to DDS.

[gavanderhoorn]

Would you happen to know of any documentation that shows how Client<->Agent and Agent<->DDS 'mapping' or a description of the different options, and how micro-ROS 'maps' ROS 2 QoS profiles to XRCE-DDS?

Or is the source of rmw_microxrcedds (like you linked) the best place to find this information?

[pablogs9]

Concerning XRCE, in the documentation, you will find how an XRCE-DDS stream can be configured: https://micro-xrce-dds.docs.eprosima.com/en/latest/client.html#streams. There is no "mapping", you just configure an XRCE channel to create and operate DDS entities defined by XML, references or binary.

Concerning micro-ROS, it is simple: Best Effort Publisher or Subscribers will use Best Effort XRCE-DDS Streams and Reliable Publisher or Subscribers will use Reliable XRCE-DDS Streams. This is not configurable and its defined in the rmw_microxrcedds.

[gavanderhoorn]

There is no "mapping"

I understand. I was mostly thinking of what the 'matrix' of possible combinations (ie: XRCE-DDS vs ROS 2/DDS) would look like, and what the resulting 'final' QoS of the full chain would look like.

---

Edit: oh and apologies for the noise. This seems like it should've been an RTFM ("message size sent or received by a best-effort stream must be less or equal than the MTU defined in the transport layer").

[pablogs9]

I guess that the full chain will only be affected by reliability.

Edit: oh and apologies for the noise. This seems like it should've been an RTFM ("message size sent or received by a best-effort stream must be less or equal than the MTU defined in the transport layer").

No worries