What is the correct way to implement robot_state_publisher and joint_state_publisher?

asked 2020-05-21 14:17:55 -0500

matthewmarkey
68 ●7 ●10 ●13

updated 2020-05-22 04:52:46 -0500

I have used both the joint_state_publisher and robot_state_publisher in my demo_gazebo.launch file shown here... I am publishing to joint_states from multiple sources, but I am unsure of how to rectify the situation. The current Gazebo output can be seen here.

With my rostopic info joint_states:

homefolder@ubuntu:~$ rostopic info joint_states
Type: sensor_msgs/JointState

Publishers: 
 * /joint_state_publisher (http://ubuntu:41201/)
 * /gazebo (http://ubuntu:34151/)

Subscribers: 
 * /move_group (http://ubuntu:39291/)
 * /joint_state_publisher (http://ubuntu:41201/)

What would be the correct way to implement my robot in Gazebo without this erratic behavior? Any insight would be greatly appreciated.

Edit:

The arm itself spawns in gazebo but is moving violently in place at the origin. Every link is moving in different directions and the model looks like it wants to explode but doesn't. I am pretty sure I have fixed the model correctly as far as both Rviz and Gazebo are concerned.

Any ideas?

Comments

What would be the correct way to implement my robot in Gazebo without this erratic behavior?

what behaviour?

Your question does not seem to describe any problem.

We cannot rely on videos here, as those tend to disappear. Please include a textual description of your problem.

gvdhoorn ( 2020-05-22 03:47:20 -0500 )edit

Ok, sure sorry about that. I have edited the original post, do you have any idea why this may be occurring @gvdhoorn?

matthewmarkey ( 2020-05-22 04:53:00 -0500 )edit

To "anchor" models in Gazebo, you'll either have to make the base link very heavy, or make sure to set world as the parent link.

In any case: I doubt this has anything to do with either JSP or RSP, as those only report state, they do not command anything.

gvdhoorn ( 2020-05-22 05:04:35 -0500 )edit

Just to clarify, are you saying that my rostopic info joint_states above can be considered typical of the system I am describing?

matthewmarkey ( 2020-05-22 05:13:14 -0500 )edit

Well it depends: if you're only interested in using Gazebo as a stand-in for your hw, I don't really see a need for a JSP instance.

Note again: the JSP is not intended for commanding a robot. It's:

a fake JointState publisher, or
a tool to coalesce multiple JointState topics into a single, coherent message

There are quite a few Q&As about this here on this forum (some of which I answered myself) and I believe you've also seen those.

gvdhoorn ( 2020-05-22 05:16:04 -0500 )edit

I currently am just interested in simulating the model in gazebo (with hopes for the real hardware later). I am confused on whether I need to include the JSP in this instance, and/or whether I am using it correctly or not.

I realize there are multiple Q&A's about this, but I have not been able to interpret them to the point that I can solve my issue. Have I missed something that was posted in a previous post that I have contributed to (that you have seen)? If so, would you be kind enough to point me in the proper direction?

If you are referring to 352216, that is where I got the idea that the publishers were conflicting and/or I am not utilizing the JSP correctly.

matthewmarkey ( 2020-05-22 05:46:34 -0500 )edit

add a comment

answered 2020-05-23 03:45:23 -0500

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

updated 2020-05-24 05:09:29 -0500

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.

edit flag offensive delete link

Comments

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"

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

matthewmarkey ( 2020-05-24 04:57:53 -0500 )edit

Yes all of my joints are shown for rostopic echo -n1 /joint_states:

homefolder@ubuntu:~$ rostopic echo -n1 /joint_states
header: 
  seq: 685
  stamp: 
    secs: 7
    nsecs: 342000000
  frame_id: ''
name: [forearm_joint, plat_joint, shoulder_joint, wrist_joint]
position: [0.753493966922786, 1.1709049141293049, -0.15562912528162975, -1.1311536829692272]
velocity: [-77.90983453530433, -73.04516765152432, 154.98471163054006, 50.93919701325415]
effort: [0.0, 0.0, 0.0, 0.0]

When I run rostopic echo /joint_states, I can see the states of the joints changing very quickly and this looks similar to where you have said: "... message describing the state of joint_1 as being 0.0 with another message stating it's actually 1.0 (for instance). "

Ok, I understand this is probably not a JSP or an RSP issue...can you maybe suggest another area I can investigate so I can get to the bottom of this?

Thank you Prof.

matthewmarkey ( 2020-05-24 05:18:01 -0500 )edit

add a comment

What is the correct way to implement robot_state_publisher and joint_state_publisher?

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

What is the correct way to implement robot_state_publisher and joint_state_publisher? edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

What is the correct way to implement robot_state_publisher and joint_state_publisher?