# I cannot publish sporadic messages in time for debugging - they stay in a "queue" somewhere!

Hi! I am fairly new to ROS and I am trying to debug my own planner, as a plugin of move_base (navigation stack).

I am using QT Creator as IDE and I found very useful its debugging functionality based on GDB. Now, it seems natural to me to use topics to send out debugging information, in this case poses, to visualise them in RVIZ. The problem is that this does not work as expected.

I can see that some poses are displayed correctly in RVIZ, but when I cycle between breakpoints the poses are not updated accordingly to the code. For example I can cycle through a publish call a couple of time and nothing is published, then the third time all the messages that were not published (if the publisher queue is long enough) get published at the same time. This is absolutely not consistent over time, and sometime the messages get published almost at every cycle, sometime after 3, sometime after 10, sometime after more than 20 calls to the publish function.

I noticed that the repeatability of the publishing rate is somehow related to the frequency at which I run through the breakpoints. When I run through the breakpoints as quickly as possible, the poses are published almost (but not always!) every time. Of course, running through the breakpoints is not in line with the need for debugging.

It seems like something goes to sleep when the messages are not published regularly, either the publisher, or the subscribers. I tried to disprove one of the two hypothesis by checking the messages that are sent with rostopic echo, and this behaves exactly like rviz: whenever the messages are received in rviz, they are displayed by echo, so either they go to sleep and wake up at the same time, or the problem is in the publisher.

I tried to put together a minimal example of my problem, but when I create my own node the problem does not appear anymore. It looks like this only happens within move_base. I will try to narrow down the issue by writing a minimal plugin of move_base, but this will take a bit longer.

If in the meantime you have any suggestion, please write them down

Thanks.

edit retag close merge delete

This is likely due to how you set up your spining. Since you're using Qt, there are going to be threading issues to consider also -- Qt retains control of the main thread. You're going to have to provide a bit more information...some of your source code would be helpful.

( 2015-07-15 10:37:28 -0500 )edit

Thanks kramer for your reply. Tomorrow at work I will post the relevant source code. I am not familiar with the concept of spinning, but if you mean that I keep the processor busy, I thought about that problem: I added some sleep time right after publishing and I placed the breakpoints after that.

( 2015-07-15 14:33:09 -0500 )edit

Unfortunately I don't know how the publish function is implemented nor compiled, so I wonder if it calls a background service somehow. Plus my code is a plugin of move_base and not an independent process, so I have a very poor control of what executes at a given time.

( 2015-07-15 14:41:30 -0500 )edit

I tried to produce a minimal example of my problem, but I failed. If I compile a complete node with the minimal publishing structure of my code, the problem does not appear.

( 2015-07-20 08:05:34 -0500 )edit

Now I need to figure out if the problem arises because my code is within a plugin of move_base or because of some interaction with the rest of my code...

( 2015-07-20 08:06:37 -0500 )edit

Sort by » oldest newest most voted

This sounds like Nagle's algorithm at work. (it's a fairly standard packet coalescing algorithm)

Try using the tcpNoDelay() transport hint in your subscriber to turn it off.

You may also want to read http://wiki.ros.org/roscpp/Overview/P... for more details on how the publish queue and transport hints work in roscpp.

more

Thanks ahendrix. I learned a few things thanks to your post. Unfortunately I am using standard nodes for subscribers (rviz, rostopic echo), so I cannot provide a transport hint. Moreover, If you see my comment above, it looks like the subscribers are working correctly...

( 2015-07-20 08:01:29 -0500 )edit