-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get most compatibility QoS policies given QoS for multiple endpoints #304
Comments
@mjeronimo @ivanpauno @gonzodepedro Follow up from our conversation today. |
I can see this being an RMW function - with an implementation in rmw_dds_common that dds-based RMWs can all use, to avoid duplication. It does make sense that other implementations may have other rules (such as ignoring all qos so all is compatible) |
The feature sounds good to me!
👍 you actually need the two functions, only one won't work.
IMO when we added the concept of QoS to ROS 2 we kind of accepted the DDS endpoint matching logic. I'm not against a |
Being able to get a publishing QoS when there are multiple subscriptions could come in handy for apps that republish messages, such as rosbag2 and rqt_bag. A related issue over in rosbag2: ros2/rosbag2#629 |
Connected to ros2/rmw#304 Signed-off-by: Jacob Perron <jacob@openrobotics.org>
Connected to ros2/rmw#304 Signed-off-by: Jacob Perron <jacob@openrobotics.org>
Feature request
Feature description
In the presence of multiple publishers, with potentially different QoS settings, it is useful to automatically setup a subscription with a QoS that is compatible with the majority (if not all) of the publishers. Presumably, what it means for two QoS profiles to be compatible depends on the RMW implementation. Therefore, it makes sense to offer an API that, given one or more endpoints, returns a QoS profile that is compatible with the most endpoints.
Immediately useful in the following tools:
ros2 topic pub/echo
ros2cli#594)Implementation considerations
Given the non-symmetric nature of publisher and subscription QoS policies, it may make sense to add two API's: one for getting a publisher QoS and one for getting a subscription QoS.
There already exists an implementation for DDS RMWs in rosbag2, see related issue about moving logic to a common place: ros2/rosbag2#601
I'm proposing we actually move the logic to the RMW layer, since it may vary depending on the RMW implementation.
Perhaps moving this logic to RMW is overkill, as the existing QoS policies are fairly specific to DDS. Alternatively, we could hard-code the compatibility rules in
rcl
.The text was updated successfully, but these errors were encountered: