Sensor Topic Conventions

asked 2012-07-16 05:51:48 -0500

ljentoft
51 ●2 ●4 ●5

We have a sensor that will be used in several locations in a robot (e.g. multiple instances of a single hardware device). Is there a preferred naming convention for message topics under these situations? I have not been able to find anything under the ROS Best Practices page

It seems like ideally, one would like to remap the root topic while maintaining the subtopics,

/sensor/raw
/sensor/calibrated

launching as

/remapped_sensor/raw
/remapped_sensor/calibrated

however the "remap" tag appears to only work for full topics.

Two other options seem to be nesting under a namespace (somewhat reduntantly) e.g.

/location_namespace/sensor/raw    
/location_namespace/sensor/calibrated

Or alternately, defining a launchfile argument (with default value) that specifies the root topic

/launch_arg/raw
/launch_arg/calibrated

Or perhaps there are other conventions?

Thanks!

edit retag flag offensive close merge delete

add a comment

5

answered 2012-07-16 06:36:00 -0500

Ryan

3248 ●20 ●47 ●63 http://www.clearpathro...

What we like to do is have the sensor topics exist (or be remapped to) in what appears to be the global namespace, then nest the node launch under a namespace. That's your /location_namespace/ example, without the redundancy.

For example (code untested, but I think it gives you the idea):

<group ns="location"/>
   <node pkg="foo" name="bar" type="baz">
      <remap from="camera/rgb/image_color" to="rgb/image_color"/>
     <remap from="camera/camera_info" to="camera_info"/>
   </node>
</group>

edit flag offensive delete link

add a comment

0

answered 2012-07-16 12:30:59 -0500

ljentoft
51 ●2 ●4 ●5

Thanks all for the fast and helpful responses!

Looks like I'll be using

/sensor/subtopic

for now then and keep topic name changes strictly in remapping.

edit flag offensive delete link

add a comment

-1

answered 2012-07-16 06:35:16 -0500

Thomas D

4347 ●33 ●65 ●86 http://denewiler.us/cv

I like to create parameters in my node that are used to set the topic names for all the publishers, and then set those parameters using a private node handle. The result is that your topics will have a prefix of the node name, including namespaces. For example, if you were to have a node acting as a driver for an IMU then you could simply have your topic names default to

ros::NodeHandle pnh("~");
std::string raw_pub_topic_name;
std::string cal_pub_topic_name;
pnh.param("raw_pub_topic_name", raw_pub_topic_name, std::string("raw"));
pnh.param("cal_pub_topic_name", cal_pub_topic_name, std::string("calibrated"));

In your launch file, if you simply start the node and give it the name imu_node then your topics will be

/imu_node/raw
/imu_node/calibrated

However, if your launch file started 2 of your IMU nodes (both with the name imu_node) with one pushed down into the left_arm namespace and the other pushed down into the torso namespace then you would end up with your topics being published on

/left_arm/imu_node/raw
/left_arm/imu_node/calibrated
/torso/imu_node/raw
/torso/imu_node/calibrated

The benefit of this is that if you have another node written that is supposed to listen for these topics then you can do the same thing for your subscribers. Just create parameters for the subscription topics using a private node handle, have them default to imu_node/raw and imu_node/calibrated, and then push them into appropriate namespaces so that they will get left_arm or torso.

edit flag offensive delete link

Comments

3

Is there any reason you don't just use remapping and namespaces to modify topic names at runtime? The way you set things up, every subscriber node needs to know the publishing node name as opposed to just a topic name.

Eric Perko ( 2012-07-16 07:31:50 -0500 )edit

4

Like Eric, I would not recommend naming topics via parameters, because it bypasses the standard ROS topic remapping. Topic names should be separate from node names, so alternative nodes can fulfil similar roles in the system.