ROS publish/subscribe queues
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 ropsy.Time.now() 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?
Try with a
queue_sizeofNone. That should result in "the subscriber should be overwritten with a new frame just before the callback is called". Related question: #q269855.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.
If I understood the response of the poster in #q269855 correctly adding this on the subscriber side should essentially give you a
queue_sizeof 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.
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.
Converted my answer to a comment
queue_size=Noneappears not to work for you."ROS Spinning, Threading, Queuing Effective use of multi spinner threads, different queues in ROS" https://levelup.gitconnected.com/ros-...
@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.
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
404and the answer will lose all its value.Please post an answer with the relevant parts quoted from the blog post instead.