Why need joint state and robot state publishers?

asked 2021-07-29 22:19:22 -0600

RobotDreams
327 ●16 ●40 ●34

updated 2021-08-01 02:42:01 -0600

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

I’m learning ROS2 with Foxy and a GoPiGo3 robot. I have built a working ROS2 gopigo3_node on my Raspberry Pi based robot (Ubuntu 20.04) Server, and a basic URDF representation of the body, castor wheel, and the differential drive wheels, (with wheel joints) on the desktop computer where I have rviz2 running on Ubuntu 20.04 Desktop.

When I fire up rviz2, I also have to launch a joint state publisher, and robot state publisher (on the desktop system) to get the wheels to move with the body.

I’m following the ROS (1) book “Hands On ROS Programming”, Bernardo Japan, and migrating everything to ROS2.

Why is the “robot” spread between the robot node and the URDF (on two different machines)?

Is it possible to build my robot node to be self descriptive and broadcast the topics the joint state and robot state publishers emit?

$C:\fakepath\Only_Robot_State_Pub.jpg$

$C:\fakepath\Both_Joint_and_Robot_State_Pubs.jpg$

edit retag flag offensive close merge delete

Comments

A high-level and very short summary of what robot_state_publisher does would be:

it performs forward-kinematics for all (*) non-fixed joints in your URDF based on the current values for those joints coming in over the joint_state topic. It consumes JointState messages and produces TF transforms.

So in essence it's a forward-kinematics "solver" run as a stand-alone ROS node.

(*): it's not actually all joint types. Floating joints are for instance not supported

gvdhoorn ( 2021-08-01 02:41:13 -0600 )edit

Thank you, but while I have succeeded to understand the words of that summary of what it does, what it eats and what it produces, (excepting the "forward-kinematics" phrase), I am having to learn to "Think in ROS" to understand why these two subscriber/publishers are needed. For over 40 years my goal for my robots has been to be independent, autonomous, and self-contained. I have had to understand why the robot needed every feature I wrote for it. I am totally out of my element when it comes to thinking about a "distributed robot".

It seems that it is not my robot that needs the joint and robot state publishers, it is rviz2 that needs them to accurately display the visual of my robot and its movements, when I have built my robot node in the fashion it is. (I have migrated the node from ROS1 to ROS2, but ...(more)

RobotDreams ( 2021-08-01 09:19:25 -0600 )edit

It seems that it is not my robot that needs the joint and robot state publishers, it is rviz2 that needs them to accurately display the visual of my robot and its movements

no, that's not quite correct.

Anything which either wants to know what the current state of the joints of your robot is, or which wants to be able to transform data in "some" TF frame X to some other frame Y will need the output of the robot_state_publisher.

RViz is just one such consumer of that information.

But as soon as you start working in configuration space with other producers and consumers of data with a spatial aspect to it (ie: it is somewhere in relation to your robot), you'll want to use tf2. That's when using something like the robot_state_publisher starts to make sense.

...

gvdhoorn ( 2021-08-01 10:04:15 -0600 )edit

...

Could you have your "robot driver" publish TF frames: of course. But why bother?

If you want to continue writing "everything yourself", please do that. No one will stop you.

But it seems rather strange to use a component based software framework to then create a monolithic component which does everything.

the design of the node (what it subscribes/publishes and the services it offers) comes from the mind of others that knew to "Think in ROS". :)

while I understand what you're trying to say, I believe it's slightly more generic than that.

We started with assembly, then gradually added higher-level abstractions to our general purpose programming languages. We went from opcodes to mnemonics, to functions, to classes and with CBSE we use components.

ROS (1 or 2, doesn't matter) is just one concrete implementation of that approach.

So if the ideal-unit-of-reuse is a component, it makes ...(more)

gvdhoorn ( 2021-08-01 10:07:09 -0600 )edit

I don't know if I am supposed to pose another question, or ask in this comment stream ..

Could you have your "robot driver" publish TF frames: of course. But why bother?

But it does, should I remove/comment_out the robot node's existing transform broadcaster publisher, to let the robot_state_publisher and joint_state_publishers do that task?

I also see that the node is instantiating a joint_publisher, but never using it - is that also unnecessary code in the robot node?

My ROS2 migration of "Hands-On-ROS-For-Robotics-Programming" ROS1 gopigo3_node: https://github.com/slowrunner/rosbot-...

RobotDreams ( 2021-08-02 17:35:20 -0600 )edit

I would suggest to post a new question, after having made sure there isn't already one which discusses this.

Use Google to search and append site:answers.ros.org to your query.

gvdhoorn ( 2021-08-03 02:48:35 -0600 )edit

add a comment

answered 2021-07-30 19:18:12 -0600

shonigmann

1567 ●15 ●115 ●49

Context on the difference between joint_state_publisher and robot_state_publisher here.

To answer your questions:

Why is the “robot” spread between the robot node and the URDF (on two different machines)?

Because each of these nodes does a fundamentally different thing. robot_state_publisher consumes your robot's urdf model and makes available, among other things, the static transforms (e.g. the transform between your imu_frame and your base_link, which will never change). While your joints are defined in the urdf, the state of these joints cannot be determined by the urdf alone. So for anything that moves, you need something that can provide that state information and those dynamic transforms.

Is it possible to build my robot node to be self descriptive and broadcast the topics the joint state and robot state publishers emit?

Sure, just about anything is possible. But you should decide whether that is worth the effort. joint_state_publisher and robot_state_publisherare pretty standard in both ROS and ROS2 systems.

edit flag offensive delete link

Comments

Thank you - as an "very old timer" in software, my tendency is toward "write it all myself so I understand it to the deepest level." The lure of ROS for me is to leverage other people's understanding so that I can begin thinking about problems at the solution level without requiring myself to learn everything from "first principles" (line by line processor instructions). Your explanation helps me begin to "think in ROS".

RobotDreams ( 2021-07-31 08:29:30 -0600 )edit

No worries! I definitely agree it can be hard to resist the temptation to do it all yourself (or at least digging into the source code), but it can certainly be rewarding to focus on the "bigger fish", so to speak. This question in particular comes up often, owing I think in no small part to the unfortunately ambiguous and similar name choices

shonigmann ( 2021-07-31 13:20:49 -0600 )edit

add a comment

Why need joint state and robot state publishers?

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

Why need joint state and robot state publishers? edit

Comments

2 Answers

Comments

Question Tools

Stats

Related questions

Why need joint state and robot state publishers?