ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
4

Do the default subscription constructors block?

asked 2011-12-05 06:49:16 -0600

tjay gravatar image

Please forgive me if documentation on this issue is the proverbial snake that should have bit me, but based on some initial explorations it looks like the

ros::NodeHandle::subscribe()

family and their rospy equivalents don't block. That is: it appears that the statement will return before the corresponding object/thread creation/spin-up is complete and actually ready to receive messages. Is this indeed the case? If so, what's the preferred way to confirm that the Subscriber object is ready?

To give (example) context, suppose I want to write (pseudo)code like this:

def handler(msg):
  pub(/topic,msg++)
subscribe(/topic,handler)
pub(/topic,0)

that creates a pub/sub loop without there being any timing issues for that first crucial message reception.

_Trevor

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2011-12-22 01:57:18 -0600

tfoote gravatar image

You are correct that subscriber/publishers handles do not block. They cannot block because you do not know how many potential connections are desired.

I would recommend that you review your design to not rely on 100% success rate of message passing. There are innumerable reasons why a message might not be delivered, including message queue overflows several buffers at different levels, wireless links ect. Thus if your algorithm is fragile to a single message being lost it may work most of the time, but when your algorithm is used in another setting or you try to extend it all of a sudden it will develop spurrious failures which will be very hard to track down.

The most common paradigm is to have a continuous stream of processing triggered by each piece of incoming sensor data. Thus if you lose one message at any point you only lose the data from that one message and the system will process the next message one cycle later. This design also inherently deals with the losses at startup.

If you cannot make your design inherently loss tolerant you should consider looking at using ros Service calls or the actionlib libarary.

edit flag offensive delete link more

Comments

Many thanks! To sway your fears, you're preaching to the choir as far as treating messages as unreliable. The example is meant to be pathological (for testing purposes). I had just never seen the non-blocking behavior explicitly referred to and wanted to make sure I wasn't missing something obvious.
tjay gravatar image tjay  ( 2011-12-26 16:15:18 -0600 )edit

Question Tools

Stats

Asked: 2011-12-05 06:49:16 -0600

Seen: 807 times

Last updated: Dec 22 '11