ROS, ROS2: Why joint_state_pub and robot_state_pub?

@KeithW HELP!

I decided today was the day - fire up rviz and watch ROSbot Dave do a square in the middle of the room.

Other than the squeaking driving my wife to banish Dave to a room “far, far away”, and having to remember how to launch it, it appeared rviz on Ubuntu in a virtual machine on my Mac was actually showing that Dave was moving.

Here is the graph from rqt:

Which brings up my next questions:

  • Why does my GoPiGo3 node need the separate robot_state_publisher and joint_state_publisher?
  • How does joint_state_publisher publish joint_states if it doesn’t listen to any topics?
2 Likes

It must know my wife. :wink:

2 Likes

I can see your problem from the first graph.

If you want Dave to dance squares, you need a better square dance caller! That graph looks like a Texas two-step totally drunk.

Yup, you need a better, less squeaky, dance caller.

2 Likes

I put Dave in the (carpeted) front bedroom to dance the hours away. After a while, I would notice on the “Dave Monitor”, he had stopped dancing. When I checked on him - He was kissing an empty chair. Found him that way three times - same chair. I have to admit the chair is quite a looker if you are into that kind of thing:

2 Likes

Congratulations on getting Dave to dance.

My understanding - the joint_state_publisher does just that. It describes the current state of all the non-fixed joints. The robot_state_publisher then takes that information and the URDF to publish the transforms for all of the links.

In this case it probably doesn’t. The gopigo3_node seems to be doing that directly. It also seems to be sending tf messages directly. I’ll have to go back and look at the code for the node. I don’t know of a way to check which topic messages come from which nodes to verify this - the originating source isn’t part of the message. But the joint_state_publisher can listen to topics that are publishing joint states (set via the source_list parameter). I think the initial state comes from the URDF, so it may look at that for sending the initial messages (but I’m less sure on that point). There’s also a gui tool that can be used to adjust the joint states being sent by the joint_state_publisher.

I looked at some of the examples I used in my online course - they didn’t have a joint_state_publisher running at all. The joint_state_publisher for the gopigo3 is being launched by a launch file on the pc - I commented that part out on one of my launch files and everything seemed to run fine. So I’m actually not sure why it was included. Maybe it’s vestigial code that just never got cleaned up??

/K

PS - really funky chair. I like it, I think.

2 Likes

When I don’t fire up the joint state pub, the wheels don’t stay attached to the bot when it moves.

2 Likes

Interesting. I just had mine propped up on a stand - I hadn’t tried moving it. So the joint_state_publisher must be important in setting up all of the relationships for the initial state. In the examples I saw w/o one, this must have been accomplished some other way.

That is one downside to the courses on The Construct - the robots you program are already set up. So there’s a lot in that initial configuration that is never really discussed (at least as far as I’ve gotten). It does seem like a bit of a chicken and the egg problem - to configure a robot requires a fair amount of ROS knowledge, but you can’t get ROS knowledge w/o a configured robot…

/K

2 Likes

Even with the joint_state_publisher running, the wheels go with the bot but don’t rotate when the bot moves.

I went back and tried only the robot_state_publisher running, and indeed the wheels are not represented in rviz2 correctly:

2 Likes