The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
I spoke with some of the folks on the ROS2 Technical Steering Committee today. There isn't a formal definition of what type of QoS should be used for specific topics like joint_states.
robot_state_publisher was changed to accept best-effort reliability, but there wasn't a big discussion about impact in other packages, or alerting other packages to the fact that they will have to deal with different QoS publishers in the same way.
The best advice I can give is "robot_state_publisher, a package in ros_base, uses a configurable subscriber for joint_states with the default QoS profile being rclcpp::SensorDataQoS(), so you probably should too."
There are some possibilities for improvements, but with the Humble freeze coming up it's not really possible or safe to ram in low level changes to DDS. @gvdhoorn mentioned some open issues/prs with rmw that help address this above. Changing the default subscriber QoS to best_effort might help as well, and would make things more like ROS1 where subscribers "just worked".
If you run into issues relating to QoS please voice your concerns. Having to deal with QoS is new in ROS2 and I'm sure I'm not the only one that has run into this kind of issue.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
