User defined Fast-RTPS parameter control

Next Generation ROS
1

Hi,

I was interested in checking if there are plans to enable user application access the Attributes specifically ParticipantAttributes, Publisher & Subscriber Attributes. This in turn enables us to create or enable static endpoint discovery. I’d be interested to work on it, if there is a design proposed already. Please help with some directions.

2

The ROS 2 API only provides only a small subset available in the underlying implementation. Therefore some rmw impl. do allow you to reach “around” the ROS 2 API and access native handles of the used implementation. For FastRTPS we have a simple example doing that in the demo repository.

You will find additional API for other entities in the rmw_fastrtps_cpp API: look at the files starting with get_ in https://github.com/ros2/rmw_fastrtps/tree/a9ffcc5b18ae3b92a6c979cbdd1809209923349c/rmw_fastrtps_cpp/include/rmw_fastrtps_cpp

I am not sure if exposing the participant / publisher / subscriber is sufficient for you use case or if you need to control the actual instantiation of the native handles. In the later case the current API doesn’t provide a way to do so yet.

3

Ok, I did check the demo it was part of the release-beta3 and this got me interested in doing the same with Attributes.

For now, I’m interested to expose attributes since I’m working on a Single SOC and I would want to avoid context switches as much as possible. StaticEndpointDiscovery helps me do it, i.e I’ve a predefined list of Pub-Sub pairs so as to avoid a few discovery search loops inside buildtin/discovery. I wanted to check if there are any hidden daemons as why these changes were avoided.

Do you see a usability of the above? Just in case its pushed upstream.

Thanks for the reply.

4

The DDS API itself is pretty complex due to all these capabilities. The RMW API intentionally doesn’t expose each and every possible option since that would likely overload many users. E.g. currently the interface doesn’t expose anything about the discovery. So any implementation (which could even be not DDS-based) can easily implement the interface. So for adding more and more options it kind of depends how we balance this. I would recommend opening a ticket for your ideas / use cases and propose specific enhancements. That allows for early feedback before spending too much time on the actual implementation.

5

Thank you. I’ll try that.