ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
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.