ROS进二阶学习笔记（10） -- rospy.Publisher() 之 queue_size
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() 函数阻塞长达一个不确定的时间。这是通过无线网连接时，常见的问题。)
为了使用新的发布机制，the keyword queue_size 就要传给 subscribe() ，它定义了在消息丢失之前的最大队列大小。
- 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.
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.
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.
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.