5

I have written a ROS subscriber to one of the image topics and I have set my buffer to 1 using:

subscriber =rospy.Subscriber("/camera/rgb/image_mono/compressed",CompressedImage, callback,  queue_size=1)

However my subscriber still lags behind. Any idea what might be causing this? Am I setting the queue size correctly?

Sello Mkantjwa
  • 1,798
  • 1
  • 20
  • 36

4 Answers4

8

I was having the exact same problem (it wasnt the choppy framerate that was the issue, it was the actual lag). When I would kill whatever image source was publishing (rosbag, camera driver, etc.), my node would still process ~5-10 frames even after the source was killed (and I was sure I had queue_size=1)

Here is the github issue I made and it was resolved. It turns out there are multiple queues involved (not just the one that you set queue_size to 1). In my case, the default buff_size was smaller than my images, and so my node wasn't processing them fast enough, and there always was a number of images backed up in some queue.

TL;DR increase the buff_size for your subscriber, as I did here. It worked for me :)

Cashew
  • 1,466
  • 2
  • 16
  • 21
  • So basically the subscriber can drop only message that are already in its buffer completely. If the buffer is smaller than `queue_size + 1`, than no message is ever dropped and the TCP buffer is buffering your messages. – Dimitri Schachmann Jul 19 '16 at 13:40
3

The queue is for queueing incoming messages. This means, if your callback takes longer to proccess than new messages arrive, only queue size is kept, the others are not processed by your node.

I would suggest to print out a message in the publisher node before publishing and a message at the top of your callback method. Then you can exactly measure the time it takes for ros to handle your messages. All other timing issues will be possibly caused by your callback method.

Steffen
  • 2,381
  • 4
  • 20
  • 33
  • 1
    I agree but if these other messages are not processed does that not mean that my subscriber will deal with the most recent one. As ausch, the video display should be choppy (due to skipped frames) but not lag behind? – Sello Mkantjwa Oct 17 '14 at 16:52
  • Well, it should lag as long as it takes for your callback method to process. – Steffen Oct 17 '14 at 18:28
  • I get it!! Because i will always show each message a few seconds after I receive it. Thanks – Sello Mkantjwa Oct 17 '14 at 19:17
1

A supplement to why buff_size matters.
Also the official document can help explain another reason that causes lag from the perspective of pub.publish.

publish() in rospy is synchronous by default (for backward compatibility reasons) which means that the invocation is blocking until:

the messages has been serialized into a buffer and that buffer has been written to the transport of every current subscriber

Qinsheng Zhang
  • 1,113
  • 1
  • 11
  • 19
-1

The reason for the visible lag is most probably that your callback function takes up a lot of time. If at all possible, try to fix that. Setting the queue size to 1 essentially means asking ROS to process whatever frames it can hold on to.

Set your queue size to a larger number, say 5 or 10. This way, (hopefully, if the processing delay isn't too much) all of your frames will be processed, but they'll be lagging behind in time. That is, the video processing will run a few steps behind but without any "jerks" and missing frames in between.

a-Jays
  • 1,182
  • 9
  • 20
  • I don't mind a choppy picture. In fact I prefer that to a laggy one. The reason I use a queue size of one is so that I have the most up to date info when the callback is called. I dont need to process all of them, I just need to process the current one. And yes, my callback takes longer than the rate of incoming messages (Hard to change that). – Sello Mkantjwa Oct 17 '14 at 16:54
  • In that case, what is the issue? A queue size of 1 will ensure just that. – a-Jays Oct 17 '14 at 17:06