Optionally disable ros publisher buffering

edit

Hi everyone,

We are using ROS as a basis for our robotics/AI project. It's been great so far with all the tools and code it provides, however today I ran into a small (big?) problem.

A small conceptual explanation of how our system is designed and how it works. We have some input on a socket port which is basically visual data. We have a ros node that reads this port out, does some processing, and publishes the data ready for consumption on a topic. This happens at 60Hz. We have another node that consumes this visual data and sends instructions out a serial port, the control node. This also happens at 60Hz. So far so good; this is standard ROS stuff and besides some minor caveats we've had no problems using this model.

Now here comes my problem. Some buffering takes place in the visual node when publishing the processed data. So at 60Hz we receive visual data from the socket, and at 60Hz we call publisher.publish(processedVisualData);. What sometimes happens is that new data from the socket arrives before the previously published data is actually sent to the control node. I know this for sure because sometimes this happens in the control node (function calls derived from print statements throughout my program):

• "Start spinning..."
• ros::spinOnce()
• visualUpdateCallback();
• "Ros spinning complete"
• runControl()
• "Control finished."
• "Start spinning..."
• ros::spinOnce()
• "Ros spinning complete"
• runControl()
• "Control finished."

So what happens here is because of the buffering in the visual node (or in the TCP of the subscriber? I've been looking at the ROS source code a lot lately and I've seen buffers in literally every class I look at) the control node sometimes runs without a new visual update, even though that visual update was given to the publisher in the visual node. So even though both nodes run at 60Hz (I've confirmed this with rostopic hz; the throughput of visual messages and control messages is almost 60Hz), the control nodes effectively runs at 30Hz, because every odd cycle it has to reuse "stale" data.

There are a few possible solutions I've found:

• Set the queue of the publisher in the visual node to one. That ensures that everytime a message is being sent it's guaranteed to be the most up-to-date. The buffering delay is somehow still in place however, so control still runs at 30Hz. (I tested this by only running the control function when new data arrived. It's output was 30 Hz even though the visual update frequency was 60Hz.)
• Produce more messages. I guess this can work, but there are 2 limitations
  • The visual input really runs strictly at 60Hz. I can't make it produce more data
  • Buffering is still in place. So even if I could crank the visual data up to 100Hz, then my control node will still run at a percentage of that. That's bad because it makes performance unpredictable: for some topics, if ...