-
Notifications
You must be signed in to change notification settings - Fork 160
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
Try to autodetect matching QoS in ros2 topic pub/echo
#594
Comments
I'm working on changes to implement partially some of this changes into ros2 topic echo. I have some questions:
|
I think it should handle any possible combination of QoS policies. I.e. we shouldn't limit ourselves to the preset profiles as users are free to create custom profiles.
I think that sounds reasonable.
Maybe we don't have to detect when a new publisher joins exactly, rather we can detect when there's a new publisher with an incompatible QoS. There is a callback API that can let us know when a new incompatible publisher is detected (see this example). Another case to consider is when publishers drop from the graph. It's possible that if a publisher is gone, then the echo tool would be able to opt for a stricter QoS policy. E.g. consider the following:
Of course we still have a similar problem of detecting when there is a change to the ROS graph. I think we can get notified that something in the graph has changed, but are not told what changed. So, we'd have to query the state of the graph whenever something changes, and re-evaluated the QoS settings. I'm not sure how expensive this would be. On top of this, I think a graph listener API is only currently available in rclcpp (there's no Python equivalent). I would say that as a first step, we could query all publishers at startup and pick QoS based on that; be a strict as possible while maintaining compatibility. Then, any time we get an "incompatible QoS" event, re-calculate the QoS of the subscription. Listening to graph events to detect dropped publishers is probably best to implement separately as I think it is a bit more involved. |
Related rosbag2 ticket: ros2/rosbag2#601 |
Another potential issue we should consider is how we should decide if two QoS policies are compatible or not. The rules laid out here are specific to DDS implementations. We probably want to make sure that the CLI tools work reasonably with different kinds of RMW implementations too. Maybe we could leverage the API being added in ros2/rclpy#684 to help determine if a policy is valid (instead of hard-coding rules). |
Since #613, the I think we could apply similar logic to the |
Related PR #644 |
The |
Feature request
It could be a great usability improvement if
ros2 topic echo
would make an effort to use a matching subscription QoS, and similarly forpub
. For a previous discussion, see #156. The basic idea would be (talking aboutecho
but the same applies topub
):--qos
flags, which would fix the specified parameters and let the others be deducedBut that only talks about a single point in time, whereas for a long-running
echo
command publishers can come and go. That raises the questions:pub1
,echo
,pub2
vspub2
,echo
,pub1
). If I understand correctly, there are warnings about this now, which help somewhat.The text was updated successfully, but these errors were encountered: