我已经为其中一个图像主题编写了一个 ROS 订阅者，并且我已使用以下方法将缓冲区设置为 1：
subscriber =rospy.Subscriber("/camera/rgb/image_mono/compressed",CompressedImage, callback, queue_size=1)
但是我的订阅者仍然落后。知道可能是什么原因造成的吗？我是否正确设置了队列大小？
【问题讨论】：
标签： python image opencv ros subscriber
visible 滞后的原因很可能是您的回调函数占用了大量时间。如果可能，请尝试解决该问题。将队列大小设置为 1 本质上意味着要求 ROS 处理它可以保留的任何帧。
将您的队列大小设置为更大的数字，例如 5 或 10。这样，（希望，如果处理延迟不是太多）您的所有帧都将被处理，但它们会在时间上滞后.也就是说，视频处理将落后几步，但中间不会出现任何“抖动”和丢失帧。
【讨论】：
队列用于对传入消息进行排队。这意味着，如果您的回调处理时间比新消息到达的时间长，则只保留queue size，其他的不会由您的节点处理。
我建议在发布之前在发布者节点中打印一条消息，并在回调方法的顶部打印一条消息。然后你就可以准确测量 ros 处理你的消息所花费的时间。所有其他时间问题都可能由您的回调方法引起。
【讨论】：
我遇到了完全相同的问题（问题不是不稳定的帧速率，而是实际的延迟）。当我杀死正在发布的任何图像源（rosbag、相机驱动程序等）时，我的节点仍然会处理 ~5-10 帧即使在源被杀死后（我确信我有 @ 987654323@)
这是我创建的the github issue，它已解决。事实证明，涉及多个队列（不仅仅是您将 queue_size 设置为 1 的队列）。在我的例子中，默认的 buff_size 比我的图像小，因此我的节点处理它们的速度不够快，并且总是在某个队列中备份了许多图像。
TL;DR
为您的订阅者增加buff_size，如I did here。它对我有用:)
【讨论】：
queue_size + 1，则不会丢弃任何消息，TCP 缓冲区正在缓冲您的消息。
supplement 解释为什么 buff_size 很重要。
此外，the official document 可以帮助从 pub.publish 的角度解释导致滞后的另一个原因。
rospy 中的publish() 默认是同步的（用于向后 兼容性原因），这意味着调用被阻塞 直到：
消息已被序列化到缓冲区中，并且该缓冲区已 已写入每个当前订阅者的传输中
【讨论】：