Robot, Node, Topic and Frame Describe Different Things

Readers who meet robotics vocabulary for the first time often collapse four separate words into one mental picture: a machine that moves, a program that runs, a channel that carries signals, and a geometric reference used to say where something is. Keeping these terms distinct matters because conference reports about hardware launches and technical guides about middleware use the same short words with different scopes. This glossary entry separates the hardware robot, the ROS 2 software node, the message topic, and the coordinate frame, using everyday interpretation rather than a product definition.

The Hardware Robot as a Physical Machine

A robot in the plain engineering sense is the physical device: motors, sensors, a chassis, a power system, and the onboard computers that drive it. When an exhibition report mentions a new humanoid or an agricultural inspection platform, it is describing this physical object and its mechanical capabilities. The robot exists whether or not any particular software framework is running on it. A reader should therefore interpret "robot" as the machine you can point at, photograph, and transport, not as a process inside an operating system. In ROS 2 documentation for the Jazzy release, the tutorial example runs a simulator called turtlesim on a computer; the simulated turtle is a visual stand-in, while the concepts of nodes and topics describe the software, not the shell of a machine. Keeping the hardware sense separate prevents confusion when a trade show says a robot has "new actuators" while a developer says the same robot has "new nodes."

ROS 2 Nodes as Modular Software Units

ROS 2 breaks complex systems down into many modular nodes, according to the official Jazzy documentation on topics at ROS 2 Jazzy documentation. A node is a software participant in the larger system; in the tutorial examples, one node handles keyboard teleoperation and another runs the turtle simulation. In the tutorial, the two default node names are `/turtlesim` and `/teleop_turtle`. The teleoperation node accepts keystrokes, and the simulator node draws the result. A node may publish data to any number of topics and simultaneously subscribe to any number of topics, so the same software unit can both send and receive. For a glossary reader, the practical interpretation is that "node" names a software participant, not a piece of metal. One physical robot may host many nodes, and one node may later run on a different machine without changing the word "robot" used for the hardware.

Topics as Communication Buses Between Nodes

Topics are a vital element of the ROS graph that act as a bus for nodes to exchange messages, as stated in the same Jazzy topic source. The tutorial shows the `/teleop_turtle` node publishing keystroke motion data to the `/turtle1/cmd_vel` topic, while the `/turtlesim` node subscribes to that topic to receive it. The type of that topic is `geometry_msgs/msg/Twist`, which tells both sides what structure of data to expect: a linear vector and an angular vector, each with three float64 values. A single command such as `ros2 topic echo /turtle1/cmd_vel` lets an observer see the values being published. Topics can be one-to-one, one-to-many, many-to-one, or many-to-many, so a topic is better imagined as a named channel in a messaging system than as a direct cable between two machines. A reader should not say "the robot published a topic" if they mean the hardware; strictly, the software node published to a named channel.

Message Types and Safe Observation

Publishers and subscribers must send and receive the same message type to communicate, and the topic type identifies the message structure used on that topic. The Jazzy tutorial uses `geometry_msgs/msg/Twist` and shows that the structure contains two `Vector3` parts. An observer using command-line introspection can list active topics, echo their data, and check publisher and subscription counts. A useful documentation practice is to record the topic name, its message type, and the direction of flow as observed. Suppose a hypothetical example: a team writes down that `/turtle1/cmd_vel` carries `Twist` data from a teleop node to a simulation node during a demonstration. That record is an observation note. Recordkeeping of this kind helps later readers understand the software layout.

Coordinate Frames and Keeping Track Over Time

A frame answers "relative to what?" rather than "what moved?" The tf2 library lets the user keep track of multiple coordinate frames over time, maintaining relationships in a tree structure buffered in time, according to the official Jazzy tf2 concepts page at ROS 2 Jazzy documentation. A robotic system typically has many 3D coordinate frames that change over time, such as a world frame, base frame, gripper frame, and head frame. The library can answer questions such as where the head frame was relative to the world frame five seconds ago, or what the pose of an object in a gripper is relative to the base. The distinction from a topic is important: a topic moves a message from one node to another, while a frame defines the geometric reference in which a position or vector is expressed. Transforms published in the `geometry_msgs/msg/Transform` message represent the frame formulation, and the library handles inversion depending on the direction traversed in the tree.

Reading These Four Terms Together in Practice

When a report about industry updates describes a factory robot, the word refers to hardware. When a developer log mentions `/teleop_turtle`, it refers to a node. When they say `/turtle1/cmd_vel`, it refers to a topic carrying `Twist` messages. When they say "base frame" or "map frame," it refers to a coordinate frame used to interpret positions. Recommended documentation practice is to write all four elements separately in a glossary note: machine identity, software node names, topic names with types, and frame identifiers. A hypothetical checklist entry might read: observed robot is the physical platform; observed node names are `/turtlesim` and `/teleop_turtle`; observed topic is `/turtle1/cmd_vel` of type `geometry_msgs/msg/Twist`; observed frames include world and turtle pose references. Such a checklist is a reader aid for distinguishing the four terms. By keeping hardware, software participant, message channel, and geometric reference in separate columns of understanding, a reader can follow both exhibition news and technical walkthroughs without mixing up four things that merely sit next to each other in a robot system.