Revision history [back]

TL;DR: I strongly suspect that what's happening is that you create a publisher and immediately publish a message on it before the subscriber has had time to connect, so the first message (or first few messages) are missed.

Longer version:

Let's call the node with your code that you pasted above Talker and the node that subscribes Listener.

Here's the sequence of events:

1. The ROS master (roscore) is started.
2. Listener is started.
3. At the moment that the Subscriber is created for topic T in the Listener code, it notifies the master that it would like to be notified of any future publishers on that topic.
4. Talker is started.
5. At the moment that the Publisher for topic T is created, the master is notified.
6. The master notifies Listener that there is a new publisher and tells it the IP and port of the publisher in the Talker node.
7. Talker publishes its first message (or couple of messages). They are missed by the Listener.
8. Listener contacts Talker and requests that future messages are send to it.
9. Talker keeps publishing messages. They are received by Listener.

If you add a sleep between step 6 and 7 (i.e., after creating the publisher, but before publishing messages), that gives the subscribers time to subscribe, and no messages are missed.

A second point is that you are publishing messages as fast as you can read them from disk, without delay. This can result in tens of thousands of messages being published per second. In that case, either the publisher or subscriber queue will overflow, and messages are dropped.

In summary, you should do the following:

• create a small sleep (1 second is more than enough) after creating the publishers, but before starting to publish if it's important not to miss any messages.
• Ensure that the queue_size parameters in all publishers and subscribers are large enough to buffer a few seconds worth of messages.
• Rate limit your publishing to ensure that you don't publish more than queue_size / N messages per second, where N is something like 3-5.

TL;DR: I strongly suspect that what's happening is that you create a publisher and immediately publish a message on it before the subscriber has had time to connect, so the first message (or first few messages) are missed.

Longer version:

Let's call the node with your code that you pasted above Talker and the node that subscribes Listener.

Here's the sequence of events:

1. The ROS master (roscore) is started.
2. Listener is started.
3. At the moment that the Subscriber is created for topic T in the Listener code, it notifies the master that it would like to be notified of any future publishers on that topic.
4. Talker is started.
5. At the moment that the Publisher for topic T is created, the master is notified.
6. The master notifies Listener that there is a new publisher and tells it the IP and port of the publisher in the Talker node.
7. Talker publishes its first message (or couple of messages). They are missed by the Listener.
8. Listener contacts Talker and requests that future messages are send to it.
9. Talker keeps publishing messages. They are received by Listener.

If you add a sleep between step 6 and 7 (i.e., after creating the publisher, but before publishing messages), that gives the subscribers time to subscribe, and no messages are missed.

A second point is that you are publishing messages as fast as you can read them from disk, without delay. This can result in tens of thousands of messages being published per second. In that case, either the publisher or subscriber queue will overflow, and messages are dropped.

In summary, you should do the following:

• create a small sleep (1 second is more than enough) after creating the publishers, but before starting to publish if it's important not to miss any messages.
• Ensure that the queue_size parameters in all publishers and subscribers are large enough to buffer a few seconds worth of messages.
• Rate limit your publishing to ensure that you don't publish more than queue_size / N messages per second, where N is something like 3-5.1-5.

TL;DR: I strongly suspect that what's happening is that you create a publisher and immediately publish a message on it before the subscriber has had time to connect, so the first message (or first few messages) are missed.

Longer version:

Let's call the node with your code that you pasted above Talker and the node that subscribes Listener.

Here's the sequence of events:

1. The ROS master (roscore) is started.
2. Listener is started.
3. At the moment that the Subscriber is created for topic T in the Listener code, it notifies the master that it would like to be notified of any future publishers on that topic.
4. Talker is started.
5. At the moment that the Publisher for topic T is created, the master is notified.
6. The master notifies Listener that there is a new publisher and tells it the IP and port of the publisher in the Talker node.
7. Talker publishes its first message (or couple of messages). They are missed by the Listener.
8. Listener contacts Talker and requests that future messages are send to it.
9. Talker keeps publishing messages. They are received by Listener.

If you add a sleep between step 6 and 7 (i.e., after creating the publisher, but before publishing messages), that gives the subscribers time to subscribe, and no messages are missed.

A second point is that you are publishing messages as fast as you can read them from disk, without delay. This can result in tens of thousands of messages being published per second. In that case, either the publisher or subscriber queue will overflow, and messages are dropped.

In summary, you should do the following:

• create a small sleep (1 second is more than enough) after creating the publishers, but before starting to publish if it's important not to miss any messages.
• Ensure that the queue_size parameters in all publishers and subscribers are large enough to buffer a few seconds worth of messages.
• Rate limit your publishing to ensure that you don't publish more than queue_size / N messages per second, where N is something like 1-5.1..5.