2

I am using ROS, Ubuntu 16.04 and Python3.

I have a publisher that publishes a custom message at 7.5 Hz. It contains 2 pointclouds and an image. One message has the size of around 2.8 MB, the average bandwith is 21.64 MB/s

I have a subscriber that subscribes to that topic but it has a noticeable delay even though queue_size = 1. While searching for this problem online I found multiple guides that say, that the reason is the buffer size. The default buffer size is apparently too small for the message. But I still get the same delay when I adjust the buffer size.

A code snippet is below:

def listener():
    rospy.init_node('node', anonymous=True)
    rospy.Subscriber("imgAndPoints", customMsg, cb, queue_size=1, buff_size = 2**28)
    #buff_size is 268MB
    rospy.spin()
cb(msg):
    msg_time = msg.header.stamp.to_sec()
    current_time = rospy.Time.now().to_sec()
    print("Delay is ", current_time - msg_time)
    time.sleep(2) #instead of performance intensive cb
    return

The delay grows from 0.008s at the first callback over 1.7s and 3.5s to 3.9 seconds and then stays there pretty consistently. It seems like the buff_size=2**28 doesn't actually do anything. I get the same delays when I run the subscriber without the buff_size argument.

Peter111
  • 803
  • 3
  • 11
  • 21
  • DId you ever find a solution for that issue? I am facing the same issue right now. – sietschie Jan 24 '20 at 11:06
  • No sadly not. What i did then was instead of sending the big msg to a new node, I let the node that created the msg proces the data instead. – Peter111 Jan 29 '20 at 11:20

1 Answers1

0

I would recommend changing the publisher's buffer size to 1.

since all messages are delivered in FIFO order,setting the queue_size to 1 is a valid approach if you want to make sure that a new published value will always prevent any older not yet sent values to be sent. This is good for, say, a sensor that only cares about the latest measurement. e.g. never send older measurements if a newer one exists.

rospy documentation on choosing a good queue_size

Omar Barakat
  • 1
  • 1