QoS settings for /joint_states in Humble

edit

I've seen some packages/robots using rclcpp::SensorDataQoS() to publish the /joint_states topic. This can create issues with existing code. A subscriber with the default settings (Reliable) cannot subscribe to a topic published as SensorDataQoS (best effort). There is little documentation about how to use different QoS types, or how to check them.

Is there an official specification as to what QoS settings certain topics, like joint_states, should be using?

Making a topic reconfigurable is fairly trivial, but still needs to be done. rclpy and rclcpp both treat incompatible QoS settings as a warnings. If you're not paying attention then you're in for a fun time figuring out why it's not working, especially if you're launching something big like a robot Moveit config.

Some packages, like robot_state_publisher, have updated their main/rolling branch and default to using SensorDataQoS(). robot_state_publisher even makes it reconfigurable at launch, if you really want to set it to reliable. I'm assuming this will make it into Humble.

ros_controllers is using SystemDefaultsQoS(), but it's a publisher so it's not a big deal, as a SensorDataQoS() subscriber can still receive this.

Moveit2's planning_scene_monitor is still using a subscriber with the default reliable QoS. This will not work with a best effort publisher.

Humble is coming out soon. Should all packages that receive joint_states be updated, or does it fall onto publishers to be reconfigurable? Does it make sense to default to sensor_data type subscribers like ros2 topic echo, as they can receive anything?