That clarifies a lot!
I didn’t realise DDS convention was to use the lower resource transport, so many design decisions make sense now.
I also didn’t realise that the DDS XML was expressive enough to set publisher and subscriber defaults separately.
So if I wanted to break ROS1 style, leave configuration hell, and enter network reliability hell, I should change my DDS defaults at the DDS level and hope that the problem nodes are using rclcpp::SystemDefaultsQoS
ros2_ws/DEFAULT_FASTRTPS_PROFILES.xml
:
<?xml version="1.0" encoding="UTF-8" ?>
<!-- This deviates from ROS1 behaviour in favour of not dealing with QoS issues -->
<dds>
<profiles>
<publisher profile_name="test_publisher_profile" is_default_profile="true">
<qos>
<reliability>
<kind>RELIABLE</kind>
</reliability>
</qos>
</publisher>
<subscriber profile_name="test_subscription_profile" is_default_profile="true">
<qos>
<reliability>
<kind>BEST_EFFORT</kind>
</reliability>
</qos>
</subscriber>
</profiles>
</dds>
This works, for nodes that use rclcpp::SystemDefaultsQoS
, but so few of them do that it’s hard to tell if it this XML does anything (it does, on FastRTPS). Most nodes use rclcpp::QoS(N)
This XML does not affect rqt, should I send a pull request?
Probably about time this question got an answer: