ROS publish/subscribe queues

asked 2017-12-08 04:43:11 -0600

zlaja gravatar image

We have two nodes in our system where one node publishes frames from the inbuilt camera and the other processing node takes the image and shows it using imshow in opencv. The messages are essentially Images from sensor_msgs. Both publish and subscribe nodes have queues set to 1 and in the case of subscriber node we also set the to buffer size to 2**24 (we are using rospy).

In the publisher node we set the timestamp to and in the subscriber node we compare the current time with the timestamp of the message to check how old the frame from the camera is, essentially the delay of communication. If the subscriber node does nothing else then show the image, the delay is very small, few miliseconds. However, if we simulate that the subscriber node needs to do something to process the frame and then show it, the delays increase substantially (we measure the delay before the messages are "processed"). For example, if we set the processing delay of 1 second, then all incoming frames are delayed by 1 second plus the additional 1 second of "processing time". If we take the how queues should work then the input queue on the subscriber should be overwritten with a new frame just before the callback is called (given that it publishes 30 FPS) which would then make the delay of only 1 second due to processing. Right now it seems that the previous message is somehow cached or that the subscriber queue is updated only when the callback function is called and never overwritten.

Are we thinking in the wrong way here, is this expected behaviour?

edit retag flag offensive close merge delete


Try with a queue_size of None. That should result in "the subscriber should be overwritten with a new frame just before the callback is called". Related question: #q269855.

gvdhoorn gravatar image gvdhoorn  ( 2017-12-08 05:06:51 -0600 )edit

On the subscriber side? The delay is only increasing. If put on the publisher side then this would make force the synchronous mode which is not really what we want if I understand it correctly.

zlaja gravatar image zlaja  ( 2017-12-08 05:47:57 -0600 )edit

If I understood the response of the poster in #q269855 correctly adding this on the subscriber side should essentially give you a queue_size of 1 but with the 'overwriting' semantics that you are looking for.

If not, then either there is something else going on, or #q269855 was incorrect.

gvdhoorn gravatar image gvdhoorn  ( 2017-12-08 05:50:11 -0600 )edit

I checked now more throughly the behaviour and it seems that if the queue size is set to None the subscriber will receive 5-6 consecutive images (with consecutive sequence numbers) and then it will jump ca 200 frames forward but still with quite substantial delay which is always increasing.

zlaja gravatar image zlaja  ( 2017-12-08 06:38:46 -0600 )edit

Converted my answer to a comment queue_size=None appears not to work for you.

gvdhoorn gravatar image gvdhoorn  ( 2017-12-09 03:21:44 -0600 )edit

"ROS Spinning, Threading, Queuing Effective use of multi spinner threads, different queues in ROS"

cascais gravatar image cascais  ( 2020-08-06 13:32:33 -0600 )edit

@cascais The answers on this forum should be more direct to what the questioner's asking about. While the link you posted looks like a valuable, relevant source, just linking to it doesn't sound like a direct answer. And looks like you've posted the exact same answer to several other posts. Someone flagged your post as offensive, which I think is a reasonable suggestion. Please consider updating your posts.

130s gravatar image 130s  ( 2020-08-07 02:09:43 -0600 )edit

I've converted @cascais answer to a comment. @130s is correct: link-only answers are essentially not answers.

@cascais: please don't spam links like that.

The blog post does seem like a good resource, but if it ever disappears (and it will, as all web pages eventually disappear), the link will 404 and the answer will lose all its value.

Please post an answer with the relevant parts quoted from the blog post instead.

gvdhoorn gravatar image gvdhoorn  ( 2020-08-07 02:22:00 -0600 )edit