static_transform_publisher and robot_state_publisher

asked 2017-10-19 09:21:42 -0500

tanasis
97 ●14 ●17 ●23

Hello,

I am a bit confused about the static_transform_publisher and the robot_state_publisher (or at least I think I am). So we are setting up a robot with sensor at all, and before we used the urdf approach we were using the static_transform_publisher to get the TF between sensors.

Now we want to use the urdf approach, i.e. robot_state_publisher. This is also publishing TF. So this should be now our source for tf, right? No need for the static_transform_publisher? (I think it will even interfere)

Thanks!

answered 2017-10-19 10:25:40 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

Now we want to use the urdf approach, i.e. robot_state_publisher. This is also publishing TF. So this should be now our source for tf, right? No need for the static_transform_publisher? (I think it will even interfere)

In short: yes, TF frames should preferably have only one backing publisher.

If you have a urdf, robot_state_publisher (RSP) can do that for you, no need for static_transform_publisher (STP).

You're not required to use RSP though, you can use URDF and still use STP as well.

One advantage of the RSP over STP is that the former will listen to JointState msgs (on the joint_states topic) and update the frames it knows about (from your urdf) using FK. That is something STP cannot do.