Revision history [back]

So the question is in the title. It looks like both of them do the same thing, don't they?

well .. sort of, but not really actually.

joint_state_publisher (JSP) is a stand-alone node, which has no way of interacting with hardware directly. In fact, the node itself is never really involved when you work with real robots, unless you have multiple publishers of JointState messages (on multiple topics) and have a desire to create a single topic onto which the complete state of all your JointState publishers is broadcast. The JSP can take all those topics and coalesce the msgs on them into a single one, containing all joints and all the state and publish that to a different topic.

The JSP can also be used with its GUI, in which case you can influence the values of the various joints it has found in the robot_description parameter using sliders. This is typically done when testing URDFs, or when you don't yet have an actual driver for a particular piece of hardware but still want to be able to generate JointState messages for that piece of hw. It's not a simulator of course, more of a UI for a data generator component.

The joint_state_controller however does not support any of this. It is a part of ros_control and cannot be used without it (of course you can, but that would need some work).

It's job is to use the data that comes out of the RobotHW ::read(..) method and (eventually) convert that into a JointState message and publish it. It knows about transmissions and other configurable aspects of ros_control. It only does its work for joints for which it has been configured to do that, and it only does that in a ros_control context.

So summarising:

• the joint_state_publisher is a stand-alone node, which does not interface with hardware directly. It is typically used when you don't have hardware, or when you have multiple publishers of JointState msgs and want a single, coherent view over all those joint_state topics.

• the joint_state_controller is a class in one of the packages of ros_control. It is not a stand-alone node. This one does interface with hardware. It's called a "controller" but it's not: it is a class that transforms data from an internal ros_control representation to JointState messages and publishes those.

As to your question:

Is there any reason to prefer one over another?

Which one you use will depend entirely on what you are intending to do. But there is also not really a choice here, as I don't believe the two entities overlap in any really meaningful way.

If you have real hardware and need JointState messages published for it, and using ros_control makes sense (because you also need to actually control actuators fi), then using joint_state_controller would be the way to go. The JSP cannot help you in this case, as it does not interface with hw.

If you just want to test a URDF, or want to generate JointState messages for joints you don't yet have a driver for, or want to coalesce multiple JointState publications into one, then the JSP can help.