8

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

概述:

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

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

预期结果:

由于队列大小为 1,订阅者应处理最新的帧,同时跳过所有其他帧。一旦它完成处理,它就应该移动到下一个最新的帧。不应有旧帧排队。这将导致视频断断续续,但不会滞后(如果有意义的话,fps 低,但不会“延迟”wrt rosbag 流)

实际结果:

订阅者落后于发布的流。具体来说,image_view 节点以 5Hz 的频率显示图像,订阅者似乎将所有图像排队并一一处理,而不是仅仅抓取最新的图像。延迟也会随着时间的推移而增加。当我停止 rosbag 流时,订阅者继续处理队列中的图像(即使 queue = 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订阅者不是最新的,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
4

2 回答 2

0

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

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

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

于 2018-03-21T23:56:12.833 回答
0

在处理像图像或点云这样的大尺寸消息时,正确的方法是使用 Nodelets。

于 2019-03-10T01:32:10.413 回答