Open
Description
Migrating ROS1 latching topics to ROS2 was raised as an issue at the FSW meeting on 1/9. The concern is that there is no ROS2 feature that exactly corresponds to ROS1 latching topics, and there are various possible approaches to achieve similar functionality. Creating this thread as one place to discuss.
To over-simplify a bit, the basic issue is that the closest ROS2 feature corresponding to ROS1 latching topics is using "transient local" DDS QoS. However, whereas in ROS1 you only need to declare that a topic is latching on the publisher side, in ROS2 you need to tell both sides to use transient local QoS. (This summary glosses over some other important issues!)
Here are some great background references about the topic:
- Improve latching/transient_local support in ROS 2 ros2/ros2#464 @wjwwood explains why this is a thorny issue. In short, DDS provides transient local QoS which is vaguely similar to ROS1 latching topics, but also has important differences, and there are good reasons to use DDS-native features rather than craft complex ROS2 abstractions on top of them to more precisely mimic older ROS1 functionality.
- Move the QoS detection code to a more central place ros2/rosbag2#601 One possible approach briefly discussed during the FSW meeting is enabling a subscriber to a topic to use an adaptive QoS that matches the QoS profile used by the publisher. This thread points to three existing implementations of adaptive QoS for subscribers and discusses feasibility of making that functionality more broadly available in ROS2.
- Automatic/adaptive subscription QoS ros2/rclcpp#1868 This thread suggests that adaptive QoS for subscribers will eventually be a core ROS2 feature, but since it hasn't been completed yet, it's unlikely to become available in the ROS2 Humble distro we expect to use for our initial Astrobee ISS deployment of ROS2. In other words, it doesn't make sense to wait for the core feature to be available before tackling this issue.