Nodes — The Fundamental Computation Unit
A node is a single executable process in a ROS system. Each node is designed to perform one specific function: a camera driver node, a SLAM node, a path planner node, a motor controller node. This modularity makes systems easier to develop, test, replace, and reuse. A typical mobile robot runs 20–60 nodes simultaneously.
Nodes are the vertices of the ROS computation graph — the directed graph showing how all running nodes communicate. You can introspect running nodes with:
ros2 node list # list all active nodes
ros2 node info /slam_node # show publishers, subscribers, services, actions
In ROS 2, nodes run within an executor that manages their callbacks. The default SingleThreadedExecutor runs all callbacks sequentially; MultiThreadedExecutor allows concurrent callback execution. Nodes can also be composed into a single process (component containers) for zero-copy intra-process communication, critical for high-bandwidth data like camera images.
Topics and Messages — Asynchronous Publish/Subscribe
Topics implement the publish-subscribe communication pattern. A publisher node writes messages onto a named topic; any number of subscriber nodes can read from it. The communication is asynchronous and decoupled — publishers and subscribers do not know about each other, only about the topic name and message type.
Message types are defined in .msg files using ROS Interface Definition Language. Core message packages include:
std_msgs— primitive types: String, Bool, Int32, Float64, Headergeometry_msgs— spatial quantities: Twist, Pose, PoseStamped, Vector3, Transformsensor_msgs— sensor data: LaserScan, Image, Imu, PointCloud2, NavSatFixnav_msgs— navigation: Odometry, OccupancyGrid, Path
ros2 topic list # list all active topics
ros2 topic echo /scan # print messages on /scan to terminal
ros2 topic hz /scan # measure publishing frequency
ros2 topic bw /camera/image_raw # measure bandwidth usage
ros2 interface show sensor_msgs/msg/LaserScan # inspect field definitions
Common ROS Message Types
| Package | Message | Key Fields | Typical Use |
|---|---|---|---|
| std_msgs | String | string data | Simple text commands, status strings |
| geometry_msgs | Twist | Vector3 linear, Vector3 angular | Robot velocity commands to /cmd_vel |
| sensor_msgs | LaserScan | float32[] ranges, angle_min, angle_max, range_max | 2D LIDAR distance measurements |
| sensor_msgs | Image | uint8[] data, height, width, encoding | Raw camera frames |
| nav_msgs | Odometry | geometry_msgs/PoseWithCovariance pose, TwistWithCovariance twist | Wheel encoder pose estimate |
| geometry_msgs | PoseStamped | Header header, Pose pose | Navigation goals, waypoints, object poses |
Services and Actions — Synchronous and Long-Running Communication
Services implement synchronous request-response communication. A service client sends a request message to a named service; the server processes it and returns a response. Services are defined in .srv files specifying request and response fields separated by ---. They are suited for discrete, quick operations: toggling a sensor (SetBool), querying the current map (GetMap), resetting an odometer.
ros2 service list
ros2 service call /set_pen turtlesim/srv/SetPen "{r: 255, g: 0, b: 0, width: 3, off: 0}"
Actions address the need for long-running tasks with feedback. An action has three message types: goal (sent by client), feedback (periodically sent by server during execution), and result (sent on completion). The client can also cancel a goal mid-execution. Actions are used for: navigating to a waypoint (NavigateToPose), moving a robot arm to a target pose, executing a gripper sequence. They are implemented on top of topics and services internally and use _action naming convention.
ros2 action list
ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose "{pose: {header: {frame_id: map}, pose: {position: {x: 2.0, y: 1.0}}}}"
Topic Bandwidth and Latency
Estimating the data throughput of a ROS topic
BW = msg_size_bytes × frequency_Hz [bytes/sec] Latency = serialisation_time + DDS_transport_time + deserialisation_time
msg_size_bytes: size of one serialised message in bytes; frequency_Hz: publishing rate; DDS transport time depends on QoS reliability setting (reliable adds ACK round-trip), message size, and network interface (loopback ~1 µs, Ethernet ~100 µs)
A 1080p raw image (1920×1080×3 bytes ≈ 6 MB) at 30 Hz requires ~180 MB/s — use compressed image topics or intra-process communication to avoid this on a single host.