ROS进二阶学习笔记（10） – rospy.Publisher() 之 queue_size
ROS进二阶学习笔记（10） – rospy.Publisher() 之 queue_size
ref link
===============
queue_size: publish() behavior and queuing
publish() in rospy is synchronous by default (for backward compatibility reasons) which means that the invocation is blocking until:
- the messages has been serialized into a buffer
- and that buffer has been written to the transport of every current subscriber
If any of the connections has connectivity problems that might lead to publish() blocking for an indefinite amount of time. This is a common problem when subscribing to topics via a wireless connection.
(sonictl: publish() 在rospy 里是同步进行的，为了向老版兼容。这就意味着对消息的调用会出现阻塞。直到：
» message 序列性地进入 buffer
» 并且buffer 已经被写入每一个subscriber的 transport(运输机)
如果这些连接出现任何连接性问题， 会导致 publish() 函数阻塞长达一个不确定的时间。这是通过无线网连接时，常见的问题。)
自从 hydro 以后，推荐使用新的 asynchronous ，异步的，发布机制，它更像是roscpp的做法。
为了使用新的发布机制，the keyword queue_size 就要传给 subscribe() ，它定义了在消息丢失之前的最大队列大小。
当publish()被调用时，会把串行化了的数据发到每一个subscriber，连接会异步地发生自不同的线程，但串行化仍将同步地发生。这就使得只有出现连接问题的subscriber会接收不到新的消息。
如果你发布消息的速度快于rospy能发送出去的速度，rospy会把老的messges丢掉。
注意，传输层上还会有个操作系统级的序列，比如TCP/IP发送buffer.
如何选择queue_size值：
- 0 - 无限长的buffer，直到被取走，不扔掉。可能会导致取不过来，内存耗尽掉~不推荐。
- 1, 2, 3, - 基本上1秒能有10次数据处理能力的话（），这种小的buffer 就够了。对于只关心最新的值的情况，最适用。
- 10或更多 - 用户界面msg 是比较好的例子，这种东东不能丢失。另一个例子就是当你想要记录所有的值，这样的值又是高速发布的。
Choosing a good queue_size
It is hard to provide a rule of thumb for what queue size is best for your application, as it depends on many variables of your system. Still, for beginners who do not care much about message passing, here we provide some guidelines.
If you’re just sending one message at a fixed rate it is fine to use a queue size as small as the frequency of the publishing.
If you are sending multiple messages in a burst you should make sure that the queue size is big enough to contain all those messages. Otherwise it is likely to lose messages.
Generally speaking using a bigger queue_size will only use more memory when you are actually behind with the processing - so it is recommended to pick a value which is bigger than it needs to be rather than a too small value.
But if your queue is much larger than it needs to be that will queue up a lot of messages if a subscriber is lagging behind. This might lead to messages arriving with large latency since all messages will be delivered in FIFO order to the subscriber once it catches up.
queue_size Omitted
If the keyword argument is omitted, None is passed or for Groovy and older ROS distributions the publishing is handled synchronously. As of Indigo not passing the keyword argument queue_size will result in a warning being printed to the console.
queue_size None
Not recommended. Publishing is handled synchronously which means that one blocking subscriber will block all publishing. As of Indigo passing None will result in a warning being printed to the console.
queue_size Zero
While a value of 0 means an infinite queue, this can be dangerous since the memory usage can grow infinitely and is therefore not recommended.
queue_size One, Two, Three
If your system is not overloaded you could argue that a queued message should be picked up by the dispatcher thread within a tenth of a second. So a queue size of 1 / 2 / 3 would be absolutely fine when using 10 Hz.
Setting the queue_size to 1 is a valid approach if you want to make sure that a new published value will always prevent any older not yet sent values to be dropped. This is good for, say, a sensor that only cares about the latest measurement. e.g. never send older measurements if a newer one exists.
queue_size Ten or More
An example of when to use a large queue size, such as 10 or greater, is user interface messages (e.g. digital_io, a push button status) that would benefit from a larger queue_size to prevent missing a change in value. Another example is when you want to record all published values including the ones which would be dropped when publishing with a high rate / small queue size.