将 ROS 发布者或订阅者的队列大小设置为较大值的原因

Reason to set queue size of ROS publisher or subscriver to a large value

当我查看机器人操作系统 (ROS) 的教程时,我发现大多数 example codes 将发布者的队列大小设置为更大的值,例如 1000。我认为这会导致失去实时响应的节点。

为什么要设置这么大的值?

来自 ROS 文档 (http://wiki.ros.org/ROS/Tutorials/WritingPublisherSubscriber):

消息发布者(生产者): "advertise() 的第二个参数是消息队列的大小 用于发布消息。如果消息发布得更快 超过我们可以发送的数量,这里的数字指定要发送多少条消息 在扔掉一些之前先缓冲一下。"

消息订阅者: "The second parameter to the subscribe() function is the size of the message queue. If messages are arriving faster than they are being processed, this is the number of messages that will be buffered up before beginning to throw away the oldest ones."

可能的解释: 思考消费者-生产者问题。

您不能保证您会按照消息到达的速率使用消息。因此,您创建了一个队列,当消息来自发件人(例如某些传感器)时,该队列就会被填充。 坏情况:如果您的程序在其他部分延迟,并且您无法以消息到达的速率读取消息,则队列会增加。 好的案例:一旦您的其他处理负载减少,您就可以更快地读取队列并开始减少它。如果您有空闲时间,您最终会将队列大小减少到零。

所以对于你的问题,如果你发送队列大小为大值你可以保证不会丢失消息。在一个简单的例子中,你没有内存限制,所以你可以做任何你想做的事,比如使用许多 GBytes 的 RAM 来创建一个大队列,并确保始终有效。 或者,如果您创建一个玩具示例来解释您不希望程序因其他原因崩溃的概念

现实生活中的例子可以是服务员和厨房洗碗的场景。 假设顾客吃完饭,服务员把他们的脏盘子拿到厨房洗。他输入了 table。只要洗碗机可以,他就会去 table 拿盘子洗。在正常操作中,table 永远不会被填充。但是,如果其他人将另一个任务交给洗碗工,table 将开始变满。直到一段时间,服务员不能再放菜,留下 tables 脏(系统问题)。但是,如果 table 在那里人为地大(比如 1000 平方单位),即使洗碗机很忙,服务员也可能会完成工作,考虑到一段时间后他将能够 return 洗碗。

好吧,答案很长,但它可能有助于理解队列。