我在收听图像消息的 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