Question

我在收听图像消息的rospy订阅者时遇到了一些滞后问题。

概述：

我有一个rosbag将图像流式传输到5Hz的/ camera / image_raw。我还有一个image_view节点，用于显示图像以供参考。此image_view以5Hz显示它们。

在我的rospy订户中（使用queue = 1初始化），我还显示图像（用于比较与image_view节点的延迟时间）。订户随后进行了一些繁重的处理。

预期结果：

由于队列大小为1，订户应处理最新帧，同时跳过所有其他帧。一旦完成处理，它应该继续前进到下一个最新的帧。应该没有旧帧排队。这会导致视频不稳定，但不会延迟（低fps，但没有＆＃34;延迟＆＃34; wrt rosbag流，如果有意义的话）

实际结果：

订阅者落后于已发布的流。具体来说，image_view节点以5Hz显示图像，并且订户似乎将所有图像排队并逐个处理它们，而不是仅仅抓取最新图像。延迟也随着时间的推移而增长。当我停止rosbag流时，订户继续处理队列中的图像（即使队列= 1）。

请注意，如果我将订阅者更改为具有非常大的缓冲区大小（如下所示），则会产生预期的行为：

self.subscriber = rospy.Subscriber("/camera/image_raw", Image, self.callback,  queue_size = 1, buff_size=2**24)

然而，这不是一个干净的解决方案。

此问题也在以下链接中报告，我在其中找到了缓冲区大小解决方案。官方解释假设出版商实际上可能正在放慢速度，但事实并非如此，因为image_view用户以5Hz显示图像。

https://github.com/ros/ros_comm/issues/536，Ros subscriber not up to date，http://answers.ros.org/question/50112/unexpected-delay-in-rospy-subscriber/

感谢任何帮助。谢谢！

代码：

def callback(self, msg):
    print "Processing frame | Delay:%6.3f" % (rospy.Time.now() - msg.header.stamp).to_sec()
    orig_image = self.bridge.imgmsg_to_cv2(msg, "rgb8")
    if (self.is_image_show_on):
        bgr_image = cv2.cvtColor(orig_image, cv2.COLOR_RGB2BGR)
        cv2.imshow("Image window", bgr_image)
        cv2.waitKey(1)

    result = process(orig_image) #heavy processing task
    print result

Answer 1

首先，如果你打算在你的主题中计算延迟流，你将走错路，因为image_view节点和cv_bridge + opencv都使用大量资源来显示导致一些滞后的图像。

之后订阅来自2个不同节点的图像主题仍然不稳定（在我的发行版中是靛蓝），除非您更改发布者方面的传输提示

我建议做的是停止订阅者节点并检查图像是否正确流式传输（特别是在您的代码中），然后使用rostopic delay someTopic向您显示您的延迟。如果问题仍然存在问题您可以将发布者中的transport_hint更改为UDP（不确定是否可以在rosbag中进行，但很可能在真正的驱动程序中）

Answer 2

处理诸如图像或点云之类的大消息时，正确的方法是使用Nodelets。

ROS图像用户滞后

2 个答案: