5

我已经为其中一个图像主题编写了一个 ROS 订阅者,并使用以下方法将缓冲区设置为 1:

subscriber =rospy.Subscriber("/camera/rgb/image_mono/compressed",CompressedImage, callback,  queue_size=1)

但是我的订阅者仍然落后。知道可能是什么原因造成的吗?我是否正确设置了队列大小?

4

4 回答 4

8

我遇到了完全相同的问题(问题不是不稳定的帧速率,而是实际的延迟)。当我杀死正在发布的任何图像源(rosbag、相机驱动程序等)时,即使在源被杀死后,我的节点仍会处理约 5-10 帧(我确信我有queue_size=1

这是我提出的 github 问题并已解决。事实证明,涉及多个队列(不仅仅是您将 queue_size 设置为 1 的队列)。在我的情况下,默认值buff_size小于我的图像,因此我的节点处理它们的速度不够快,并且总是在某个队列中备份了许多图像。

TL;DRbuff_size为您的订阅者增加了,就像我在这里所做的那样。它对我有用:)

于 2015-03-20T06:04:41.073 回答
3

队列用于对传入消息进行排队。这意味着,如果您的回调处理时间比新消息到达的时间长,则只会queue size保留,其他人不会由您的节点处理。

我建议在发布之前在发布者节点中打印一条消息,并在回调方法的顶部打印一条消息。然后你就可以准确测量 ros 处理你的消息所花费的时间。所有其他时间问题都可能由您的回调方法引起。

于 2014-10-17T07:09:30.987 回答
1

对为什么 buff_size 很重要的补充。官方文档
也可以从 pub.publish 的角度帮助解释导致滞后的另一个原因。

rospy 中的 publish() 默认是同步的(出于向后兼容性的原因),这意味着调用被阻塞,直到:

消息已被序列化到缓冲区中,并且该缓冲区已写入每个当前订阅者的传输中

于 2019-10-05T03:56:23.137 回答
-1

明显滞后的原因很可能是您的回调函数占用了大量时间。如果可能,请尝试解决该问题。将队列大小设置为 1 本质上意味着要求 ROS 处理它可以保留的任何帧。

将您的队列大小设置为更大的数字,例如 5 或 10。这样,(希望,如果处理延迟不是太多)您的所有帧都将被处理,但它们会在时间上滞后。也就是说,视频处理将落后几步,但中间没有任何“抖动”和丢失帧。

于 2014-10-17T07:08:09.577 回答