ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

cpp publisher/subscriber tutorial loosing some messages

asked 2019-01-23 04:35:40 -0500

volume_8091 gravatar image

I was following the tutorial) and faced the following problem: some messages (usually 3) are lost when doing the sequence:

  1. start talker
  2. start listener
  3. stop talker
  4. start talker

For example, an output like this is produced in the talker window:

$ rosrun beginner_tutorials talker 
[ INFO] [1548238652.003693516]: hello world 0
[ INFO] [1548238652.103993652]: hello world 1
[ INFO] [1548238652.203964623]: hello world 2
[ INFO] [1548238652.304064752]: hello world 3
[ INFO] [1548238652.404034941]: hello world 4

While in the listener window only latter are shown:

[ INFO] [1548238652.304599291]: I heard: [hello world 3]
[ INFO] [1548238652.404490112]: I heard: [hello world 4]
[ INFO] [1548238652.504314152]: I heard: [hello world 5]

There is no such problem with the Python publisher/subscriber, not even a single message was lost.

ROS Kinetic, Ubuntu 16.04.05 x64 (run under VirtualBox with Win7 x64 as a host). No original files were changed, just copy and paste from the tutorials.

edit retag flag offensive close merge delete


You could try increasing the queue size of the publisher. However, there is no guarantee that all messages will be delivered.

curi_ROS gravatar image curi_ROS  ( 2019-01-23 05:54:13 -0500 )edit

if you lose only the first three messages each time you start the talker node, the reason might be that: the publisher takes milliseconds to be initialized. try to put some delay like 1 sec before publishing any message and see what will happen.

mali gravatar image mali  ( 2019-01-23 10:12:09 -0500 )edit

@curi_ROS increasing queue size from 1000 to 10,000 did not give any difference. As only 3 messages were lost, buffer size of 1000 would already be enough to avoid the problem.

volume_8091 gravatar image volume_8091  ( 2019-01-24 02:00:56 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2019-01-24 05:06:19 -0500

Alberto E. gravatar image

updated 2019-01-24 05:07:46 -0500


As you already noticed, this is caused by the time it takes to initialize the Publisher. I wanted to share an alternate solution to the problem, which is using the getNumSubscribers() method of the Publisher class.

This method returns the number of subscribers that are currently connected to the Publisher. In your case, you could add something like this to the talker.cpp code:

while(chatter_pub.getNumSubscribers() == 0)

This would go right before the publish of the message:


This way, you won't publish any message until the Publisher/Subscriber connection is created, so you won't lose any message. You can also check the following post for more details.


edit flag offensive delete link more



+1 for mentioning getNumSubscribers(), but a nitpick: you write "the Publisher/Subscriber", as if there are only 1 of each. That is rarely the case. There are typically many, in which case waiting for a single one makes little sense.

Same comment about the text in the blogpost you link to.

gvdhoorn gravatar image gvdhoorn  ( 2019-01-24 05:23:14 -0500 )edit

It would be good to link to / discuss an explanation of when to use which type of interaction, as "lost messages" are almost inherent to something as loosely / completely decoupled as (ROS) pub-sub.

If lost msgs are unacceptable, perhaps services or actions are better suited.

gvdhoorn gravatar image gvdhoorn  ( 2019-01-24 05:24:09 -0500 )edit

Not only did your solution work, but it is also much more reliable and avoids ugly guess-waiting-time question.

volume_8091 gravatar image volume_8091  ( 2019-01-24 05:24:40 -0500 )edit

@Alberto E. As a final note, could you share a piece of advice on how to look up the names of subscribers? This could enable not starting publishing until the very important Subscriber(s) starts listening.

UPD: the video is good, thank you very much

volume_8091 gravatar image volume_8091  ( 2019-01-24 05:29:00 -0500 )edit

This could enable not starting publishing until the very important Subscriber(s) starts listening.

and would also remove one of the advantages of pub-sub: decoupling in the space dimension.

See #q203129.

gvdhoorn gravatar image gvdhoorn  ( 2019-01-24 06:43:44 -0500 )edit

answered 2019-01-24 01:57:46 -0500

volume_8091 gravatar image

As @mali suggested, the problem was in time to initialize the publisher (actually, it took up to 30 milliseconds). Adding the 50ms pause before publishing the first message was enough to not loose any messages.

As far as I can guess, Python does not suffer from this due to its slower work, so by the time rosout is accessible, the publisher takes less than 10ms to initialize. Unfortunately, I do not have time for a closer profiling and answering the question deeper than that.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2019-01-23 04:31:37 -0500

Seen: 1,235 times

Last updated: Jan 24 '19