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