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 |
Role of queue_size in Publishers:
This parameter is needed because, in most cases, the message must be transmitted to another node. This communication process can be time consuming, especially compared to the time needed to create messages.
ROS mitigates this delay by having the publish method store the message in an outbox queue and return right away. A separate thread behind the scenes actually transmits the message.
The (integer) value of the queue_size is the number of messages that the message queue can hold.
Interestingly, the ROS client library is smart enough to know when the publisher and subscriber nodes are part of the same underlying process. In these cases, the message is delivered directly to the subscriber, without using anty network transport.
Role of queue_size in Subscribers:
When new messages arrive, they are stored in a queue until ROS gets a chance to execute your callback function. This parameter establishes the maximum number of messages that ROS will store in that queue at one time. If new messages arrive when the queue is full, the oldest unprocesses messages will be dropped to make room.
Difference betwen the cases of Publisher and Subscriber
The rate at which ROS can empty a publishing queue depends on the time taken to actually transmit the messages to subscribers, and is largely out of our control.
In contrast, the speed with which ROS empties a subscribing queue depends on how quickly we process callbacks. Thus, we can reduce the likelihood of a subscriber queue overflowing by a) ensuring that we allow callbacks to occur via ros::spin or ros::SpinOnce. frequently, and b) reducing the amount of time consumed by each callback.
Source - 'A Gentle Introduction to ROS' by Jason M. O' Kane
| | 2 | No.2 Revision |
Role of queue_size in Publishers:
This parameter is needed because, in most cases, the message must be transmitted to another node. This communication process can be time consuming, especially compared to the time needed to create messages.
ROS mitigates this delay by having the publish method store the message in an outbox queue and return right away. A separate thread thread behind the scenes actually transmits the message.
The (integer) value of the queue_size is the number of messages that the message queue can hold.
Interestingly, the ROS client library is smart enough to know when the publisher and subscriber nodes are part of the same underlying process. In these cases, the message is delivered directly to the subscriber, without using anty network transport.
Role of queue_size in Subscribers:
When new messages arrive, they are stored in a queue until ROS gets a chance to execute your callback function. This parameter establishes the maximum number of messages that ROS will store in that queue at one time. If new messages arrive when the queue is full, the oldest unprocesses messages will be dropped to make room.
Difference betwen the cases of Publisher and Subscriber
The rate at which ROS can empty a publishing queue depends on the time taken to actually transmit the messages to subscribers, and is largely out of our control.
In contrast, the speed with which ROS empties a subscribing queue depends on how quickly we process callbacks. Thus, we can reduce the likelihood of a subscriber queue overflowing by a) ensuring that we allow callbacks to occur via ros::spin or ros::SpinOnce. frequently, and b) reducing the amount of time consumed by each callback.
Source - 'A Gentle Introduction to ROS' by Jason M. O' Kane
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.
