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.
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:
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??
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…
