Support loading default XML profile file

[richiware]

Add support to get Fast RTPS configuration from a default XML file.

When running a ROS2 executable, if exists the XML file DEFAULT_FASTRTPS_PROFILES.xml in the execution directory then FastRTPS will load it and use the profiles defined with is_default_profile=true as default values for entity attributes.

With this PR, ROS2 will take the default values (maybe changed by and XML file) and then apply the ROS2 QoS profiles. A user shall be able to change attributes like heartbeatPeriod through an XML file.

[mikaelarguedas]

Thanks @richiware for the contribution.

I am not very familiar with the definition of xml profiles in DDS. If a user wants to define it's own xml profile, he should follow this schema?
If a user defines it's own xml profile, would it make more sense for this user-defined profile to override the QoS settings defines programmatically ?
Or is it planned to allow the user to have a "default" profile loaded automatically (and overriden by the settings set programmatically ) and another "custom" profile that will override QoS settings at runtime?

[mikaelarguedas]

Is it possible to rebase this branch on top of the current master so that we run our ci jobs on it? thanks!

[mikaelarguedas]

The trailing whitespace makes our linters unhappy

[deng02]

+1 on this PR: we really need the ability to be able to configure the FastRTPS locators

[deng02]

Prior to this issue being posted, I had been working out how to change the participant attributes from ROS2 by adding something to the rmw_fastrtps_cpp layer for configuring an existing ParticpantAttributes object that would then be used by rmw_create_node(). The reason I took this approach is because we needed to potentially add a custom UDPv4 transport, which isn't supported by the profiles yet.

After looking at the above PR I've incorporated the loading of the default XML profile, which may give the best of both worlds: ability to configure the participant attributes using just XML profiles as well as being able to do so directly if that doesn't offer enough flexibility. I have branch setup demonstrating just the partiicpant attributes but this could be expanded to handle the publisher and subscriber as well. However I thought I would get feedback on what the thoughts are on this approach before proceeding witha full PR request: https://github.com/deng02/rmw_fastrtps/commit/26a1db9829a1563ff83b04b2cf76c05aecc68043

For an example of how a ROS2 node might use this, this is a talker that changes the out locator list and causes it to bind to localhost:
https://github.com/deng02/demos/commit/f9f1d6def555cea50a7608723daa31625a558a83

[richiware]

@mikaelarguedas The XSD file you mentioned is the validator for our XML profiles. Currently a user can define profiles in an XML file and create entities using the name of a XML profile (through FastRTPS API), instead of creating attributes programmatically.
Also a XML profile can be set as default and the user can get the default attributes using ``getDefaultParticipantAttributes```function. This function is the one I use in this PR.
With this PR, if exists an DEFAULT_FASTRTPS_PROFILES.xml file and there is a Participant profile set as default, then the Participants created by rmw_fastrtps_cpp will be create with those attributes, except the attributes set programmatically by rmw_fastrtps_cpp.

As you suggested, I rebased the PR.

[richiware]

About @deng02 PR, I taken a look and his approach permits get the default profile (that could be defined in an XML file) and make changes programmatically. But should be extended to publishers and subscribers.

[mikaelarguedas]

• Linux
• Linux-aarch64
• macOS
• Windows

@richiprosima Can you please address linter failures pointed out in the review?

[richiware]

Updated

[deng02]

@richiware Thank you for the feedback. I'll update to deal with the publisher subscriber attributes and submit as a separate PR.

[dirk-thomas]

Using rmw_connext there are currently three levels of configuration involved:

• default configuration coming from a .xml file
• default configuration coming from the ROS 2 profiles and/or the setting the code chooses
• override configuration coming from a .xml file

The first bullet is great to configure e.g. parameters not covered by ROS 2 at all. The third bullet is valuable to override the configuration of e.g. a QoS parameter for a specific topic without the need to modify the code. This PR currently covers only the first bullet if I understand it correctly. @richiprosima Maybe you can comment if you plan to also support the third bullet in the future.

[deng02]

@richiware Thinking on Dirks points above and that directly manipulating the ParticipantAttributes object offers a less flexible approach, I'm going to abandon my strategy in favor of whatever is put forth in this PR. I'll work on making contributions in the XML profile parser at the fastrtps level.

[mikaelarguedas]

CI on this branch rebase on top of master.

• Linux
• Linux-aarch64
• macOS
• Windows

[mikaelarguedas]

@richiware I'm going to merge this. Could you please respond to #153 (comment) regarding the potential implementation of an override of QoS profiles via XML in the future ? thanks!

[richiware]

@dirk-thomas As you said, this PR covers first option. We are opened to work in the third option. I was trying to find out in rmw_connext module how do you cover this option, but I couldn't find it. How do you want to cover this option in rmw_fastrtps?

[dirk-thomas]

I was trying to find out in rmw_connext module how do you cover this option, but I couldn't find it. How do you want to cover this option in rmw_fastrtps?

The XML files used by default in Connext allow the user to override any of the QoS settings - afaik on a fine granular level. That sounds like a reasonable approach to achieve the third option.

[richiware]

I think I'm not understanding your third option. Through our XML files a user can override any of the QoS settings. In our XML files you can define XML profiles for participants, publishers and subscribers. The user can use them by name, but this is not applied on rmw_fastrtps.
Also a user can set a publisher's XML profile (and participant's and subscriber's) as a default profile and it's QoS settings will be use as default in FastRTPS. When rmw_fastrtps uses the function getDefaultPublisherAttributes, rmw_fastrtps obtains the current default FastRTPS QoS parameters which could have been overriden using an XML file.
Looking into rmw_connext I see the same behaviour described here. get_default_datawriter_qos obtains the current default QoS parameters which could have been overriden using an XML file.

[dirk-thomas]

When rmw_fastrtps uses the function getDefaultPublisherAttributes, rmw_fastrtps obtains the current default FastRTPS QoS parameters which could have been overriden using an XML file.

If it is already possible to change the QoS of any topic using a XML file without changing the code that is great. That is exactly what the third option aims for.