ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Multiple nodes publish to one topic, all fields in msg are not populated at once

asked 2012-06-08 05:55:37 -0500

vtug2012 gravatar image

updated 2012-06-08 06:39:59 -0500

joq gravatar image

I set up a minimum ROS package that demonstrates my issue.

Consider a robot that has two sensors, each sensor publishes to the same topic (i.e. /sensorData) but each sensor populates a different subset of the message.

For example the .msg might be:

int64 sensorAout1
int64 sensorAout2
int64 sensorBout1
int64 sensorBout2

Where sensorA populates the first two fields, and sensorB the last two fields. When a listener node subscribes to this topic, then at any one instant the topic is never fully populated with values from both sensors, instead it switches between the two. For example, the output from the listener node contains the sensorA data but blanks for sensorB and then vice versa.

Is there a way to resolve this? perhaps setting up the sensors as services and a seperate node that packages it all into one topic /sensorData?

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted

answered 2012-06-08 06:12:21 -0500

dornhege gravatar image

updated 2012-06-08 06:14:30 -0500

In you setup you don't have any change to detect what data is valid unless it's visible from the data. You could include a flag that says if A or B are valid.

But it seems to me that your setup just isn't properly suited to what you want to do. The better solution would be to only have one message type that contains (out1, out2) and both sensors publish these to topics (sensorA, sensorB) of the same message type. The listener can now match the data sources properly. That obviously also works for different message types (like odom and laser).

Merging those two to one matching data set should then happen by whoever needs these. Depending on how you want to match the data sets, e.g. by timestamp, there are some nice tools in the message_filters package.

edit flag offensive delete link more



This is the "standard" ROS solution, and well-supported by the tools.

joq gravatar image joq  ( 2012-06-08 06:42:18 -0500 )edit

Hi I had a similar situation and I tried by adding the timestamp using ros::Time::now() into my messages. However, the output from synchronization stops after 1 or 2 messages. What can I use for my Timestamp?

SivamPillai gravatar image SivamPillai  ( 2012-09-05 05:54:20 -0500 )edit

answered 2012-06-08 06:20:56 -0500

allenh1 gravatar image

In your main publisher, you should use a scancallback method inside of a class. This way, your main method can call scancallback for both sensors individually before using the publisher to publish from a class. Take a look at this tutorial and this class reference.

edit flag offensive delete link more

answered 2012-06-08 07:21:41 -0500

vtug2012 gravatar image

Thanks for your help. I did consider adding flags to mark valid or unvalid data, and I think this is an option, but it is not very elegant since it involves having additional code to check the flags and using rosbag to log the topic this way (with alternating invalid fields of the message) could produce hard to read telemetry files.

The example I gave is a simple one, in reality we'll have about 3 nodes with a total of 15 channels that we'd like to capture in one topic /sensorData. To make it clean, i'd rather not have 3 separate topics going to the rest of the system but instead have these all bundle together into one /sensorData and then pass this to other nodes that perform control, health monitoring etc.

However, i'll look into using message_filters or the scancallback method.

edit flag offensive delete link more


make a generic sensor data that is more flexible. For channels and things you can look, for example at the pointcloud messages.

dornhege gravatar image dornhege  ( 2012-06-11 22:37:39 -0500 )edit

Question Tools


Asked: 2012-06-08 05:55:37 -0500

Seen: 3,857 times

Last updated: Jun 08 '12