Ask Your Question
0

What is the difference between joint_state_publisher and joint_state_controller?

asked 2018-09-14 01:54:42 -0500

Long Smith gravatar image

So the question is in the title. It looks like both of them do the same thing, don't they? Is there any reason to prefer one over another?

Thanks!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
6

answered 2018-09-14 05:00:46 -0500

gvdhoorn gravatar image

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 ... (more)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-09-14 01:54:42 -0500

Seen: 426 times

Last updated: Sep 14 '18