Revision history [back]

ROS 2 relies on the underlying middleware to provide things like managing how many samples to buffer. There are many QoS parameters available from DDS, the default middleware, and ROS 2 provides a subset of them through its API.

For the equivalent of a "queue size", the relevant parameter is the history policy. This specifies how many samples to keep for publishers and for subscribers. You may also want to look at the durability policy, which defines if published samples are available for a subscriber that starts after the publisher begins publishing, and the reliability policy, which defines whether data must be delivered or if it is OK to lose a few samples.

Because there are many more Quality of Service settings than just the number of samples to buffer, there is a different API for setting these parameters from ROS 1. You create an object that specifies the QoS policies you want, and pass that in when constructing a publisher or subscriber.

In rclpy you should use the QoSProfile object from rclpy.qos. You can set the history member of this object to specify the sort of history retention you want. The two simple values are to keep the most recent sample or to keep all samples.

See the data_publisher.py demonstration for how to use this API. The relevant lines are 75-80 and 92-93. You can run the demo to try out different values for history using this command:

ros2 run topic_monitor data_publisher

For more information on the impact of QoS policies in ROS 2, there is a good tutorial/demonstration of their impact available on the documentation page. If you want to understand more about the QoS policies DDS provides, including those not accessible via the ROS 2 API directly, then you should look at the DDS specification, section 7.1.3. Don't be put off by the technical appearance of the document, the table of QoS policies is quite readable.