About QoS of Images

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: