Revision history [back]

Please see #q303358 for a description of what the JSP is typically used for (ignore the joint_state_controller side of the question and answer).

As to your question specifically: if you only have your robot in simulation, and Gazebo is aware of all joints and you have configured Gazebo correctly to publish JointState messages for those joints, then you do not need the JSP.

Please see #q303358 for a description of what the JSP is typically used for (ignore the joint_state_controller side of the question and answer).

As to your question specifically: if you only have your robot in simulation, and Gazebo is aware of all joints and you have configured Gazebo correctly to publish JointState messages for those joints, then you do not need the JSP.

Please see #q303358 for a description of what the JSP is typically used for (ignore the joint_state_controller side of the question and answer).

As to your question specifically: if you only have your robot in simulation, and Gazebo is aware of all joints and you have configured Gazebo correctly to publish JointState messages for those joints, then you do not need the JSP.

Edit:

Ok, so I am trying to do my due diligence here, and look up your criteria individually. But I am not making the connection.

How would I make sure Gazebo is "aware of all joint"

Does a rostopic echo -n1 /joint_states contain information for all the joints in your .urdf/.xacro?

How would I make sure Gazebo is correctly configured to publish JointState messages?

Well, from the output of rostopic info joint_states which you include in your question, it would appear it is already doing this.

The general idea here is that the joint_states topic carries information about what the current state is of the joints which are part of your robot. That's all really. Whether that includes just a single arm, multiple or has grippers attached or other things doesn't matter. It carries that information.

Where that information comes from (ie: who or what is the originator) doens't matter. As long as those messages are there and they actually describe the current state.

So the JSP could be used to publish "fake" JointState messages for all the joints in your .urdf/.xacro (fake in the sense that they do not come from real hardware or a simulation).

Gazebo can be used (together with the appropriate plugin(s) from gazebo_ros_pkgs) to publish JointState messages based on the state of the simulated robot hw.

A robot driver node can be used to publish JointState messages based on the state of your real robot hw.

Note the theme here: JointState messages are used to convey current system state, no matter where that comes from. The consumers of that state won't care where it comes from, as long as they can work with it.

But the important thing is that you should not have multiple publishers of JointState messages for the same joints, as that will lead to one message describing the state of joint_1 as being 0.0 with another message stating it's actually 1.0 (for instance). I just made those nrs up, but the problem should be clear: a joint cannot be in two states at the same time.

The issue with your simulation is very likely to not be caused by either the JSP nor the RSP. They do not command anything, and Gazebo would not be taking commands from the topics they publish to.