robot_state_publisher is the ROS node that turns a robot's joint angles into a live tree of coordinate frames — the quiet bridge that lets the rest of the system know where every part of the robot is in space.
robot_state_publisher reads the robot's description and its current joint angles, then continuously publishes where every part of the robot is. It's what lets the software know the hand is here and the camera is there, moment to moment.
The rest of a robot's software constantly needs to know where every part is — the camera relative to the base, the gripper relative to the arm. Computing and broadcasting that, continuously, is the job of robot_state_publisher.
What it does
robot_state_publisher takes two inputs — the robot's URDF description (its links and joints) and its current joint angles (the /joint_states topic) — and does the forward kinematics: given the joint angles, where does each link end up? It then publishes every link's pose into the tf transform tree, updated as the robot moves.
Joint angles to a live frame tree
It marries the fixed structure (URDF) with the changing joint angles and broadcasts where every part is — so any node can ask 'where is the camera relative to the base?'
Why it's the quiet keystone
Almost everything spatial depends on it:
RViz draws the robot at the correct pose because robot_state_publisher supplies the frames.
Perception transforms a detected object from the camera frame into the base or map frame using these transforms.
Manipulation and navigation reason about the robot's geometry through the tf tree it maintains.
Without it, the tf tree has gaps and half the stack breaks with "cannot find transform" errors — a very common ROS symptom that traces back to a missing or misconfigured robot_state_publisher (or an absent /joint_states source).
Fixed vs moving joints
For moving joints it needs live /joint_states (from the real robot's encoders or a simulator). For fixed joints (a bolted-on sensor), it publishes a static transform once. A companion, joint_state_publisher, can supply joint values for testing when no hardware is present.
Why it matters
robot_state_publisher is the unglamorous node that keeps the robot's self-model in sync with reality. It's the reason the whole system agrees on where every part of the robot is — the foundation beneath visualization, perception, and motion.
