Why need joint state and robot state publishers?
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?
.png "shonigmann"){kind=small}
.png "shonigmann"){kind=small}
A high-level and very short summary of what
robot_state_publisherdoes would be: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
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)
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
Xto some other frameYwill need the output of therobot_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_publisherstarts to make sense....
...
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.
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)
I don't know if I am supposed to pose another question, or ask in this comment stream ..
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-...
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.orgto your query.