ROS 2 node

ROS 2 node – definition

A ROS 2 node is a computational entity that performs a defined function within a Robot Operating System 2 application. A node may run as a standalone executable process or as a component loaded into another process. It uses the ROS 2 client library API, such as rclcpp for C++ or rclpy for Python, to communicate with other nodes through topics, services, actions, and parameters. In a mobile robot, nodes separate functions such as motor control, wheel odometry, LiDAR acquisition, localisation, mapping, path planning, and camera processing.

ROS 2 nodes are not limited to one hardware device. A node can run on the onboard computer of a Leo Rover or Raph Rover, on a companion computer such as an NVIDIA Jetson, or on a remote workstation connected through a ROS 2 network. ROS 2 commonly uses DDS, or Data Distribution Service, through its middleware layer for discovery and message transport. This differs from ROS 1, which normally relied on a central ROS Master for graph registration.

For a UGV, node boundaries should follow system responsibilities and timing requirements. A low-level drive node should expose the robot base interface. A navigation node should consume localisation and obstacle data. A perception node should publish sensor-derived observations without directly controlling drivetrain hardware.

How a ROS 2 node works

Each node has a name, namespace, communication interfaces, parameters, and callbacks. At startup, it joins a ROS domain identified by ROS_DOMAIN_ID. Nodes in the same domain can discover compatible publishers, subscribers, service servers, service clients, action servers, and action clients through the configured ROS middleware implementation.

A typical mobile robotics node may provide the following interfaces:

Publisher – sends messages to a topic, for example /scan or /odom.
Subscription – receives messages, for example a base controller subscribing to /cmd_vel.
Service – provides a short request-response operation, such as resetting odometry.
Action – handles a long-running task with feedback and cancellation support, such as navigating to a pose.
Parameter interface – stores configurable values, including frame IDs, serial ports, controller gains, and update rates.
TF broadcaster or listener – publishes or consumes coordinate transforms used by localisation and navigation.

ROS 2 client libraries execute callbacks when data arrives, timers expire, or service and action requests are received. The executor determines how callbacks are scheduled. A single-threaded executor is often sufficient for basic rover integration. Multi-threaded executors and callback groups are useful when sensor processing, communications, and control callbacks must run concurrently.

Nodes in a UGV software graph

A practical ROS 2 graph for a differential-drive rover consists of several nodes with explicit interfaces. This arrangement makes it possible to replace a sensor, navigation stack, or compute unit without redesigning every software component.

Node function	Typical ROS 2 interfaces	Role on a mobile platform
Base driver	`/cmd_vel`, `/odom`, `/joint_states`	Converts velocity commands into differential-drive motion and reports wheel odometry.
LiDAR driver	`/scan` using `sensor_msgs/msg/LaserScan`	Publishes 2D range data for obstacle detection, mapping, or localisation.
IMU driver	`/imu/data` using `sensor_msgs/msg/Imu`	Publishes angular velocity, linear acceleration, and optionally orientation.
State estimator	`/odometry/filtered`, TF transforms	Fuses wheel odometry, IMU, and GNSS measurements into an estimated robot state.
Navigation stack	`/navigate_to_pose` action, `/cmd_vel`	Plans and executes autonomous motion after a map, localisation source, and safety configuration are available.

The ROS 2 interface type matters. For example, geometry_msgs/msg/Twist represents commanded linear and angular velocity, while nav_msgs/msg/Odometry includes pose and twist estimates with covariance fields. Correct message semantics and frame conventions are required for interoperability between nodes.

Quality of Service settings

ROS 2 Quality of Service, or QoS, controls delivery behaviour between publishers and subscribers. QoS compatibility is a common integration issue when combining drivers, SLAM packages, visualisation tools, and navigation components.

The main QoS policies relevant to UGV systems are:

Reliability – RELIABLE requests delivery guarantees, while BEST_EFFORT prioritises timely transmission over retransmission.
Durability – TRANSIENT_LOCAL allows late-joining subscribers to receive samples retained by the publisher according to its history settings; VOLATILE does not.
History and depth – define how many queued samples are retained. A depth of 1 is common for current-state data, while larger queues can absorb temporary processing delays.
Deadline and lifespan – define expected publishing intervals and message validity periods when configured and supported by the middleware.

High-rate sensor data can use best-effort delivery to avoid delayed stale data. Configuration, maps, and mission-critical state changes may require reliable delivery. The appropriate policy depends on network quality, CPU capacity, and whether missing a sample is safer than processing an old sample.

ROS 2 nodes on Leo Rover and Raph Rover

Leo Rover uses a Raspberry Pi-based onboard compute unit and can run supported ROS 2 distributions. Its four-wheel differential-drive base requires a node that accepts velocity commands and provides odometry suitable for higher-level localisation or navigation nodes. Leo Rover is not autonomous by default. Autonomous operation requires sensor integration, a TF tree, localisation or SLAM, obstacle handling, and a configured navigation stack.

On Leo Rover, a compact deployment may run the base driver, LiDAR driver, IMU driver, robot state publisher, and teleoperation node locally. Computationally intensive workloads, such as depth-camera inference or dense visual SLAM, may require a companion computer or remote processing architecture.

Raph Rover can host the same logical ROS 2 graph but is intended for larger payloads and more demanding field integrations. Typical additional nodes may include multi-camera drivers, RTK GNSS receivers, 3D LiDAR processing, mission control, and sensor-fusion components. The software interface remains based on ROS messages, TF frames, parameters, and QoS settings rather than on the physical size of the platform.

Example: launching a rover sensor node

A launch file groups nodes into a repeatable deployment. The following Python launch fragment starts a hypothetical LiDAR driver and assigns a namespace. Actual package names, serial devices, frame IDs, and parameters must match the installed driver and rover configuration.

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(
            package='lidar_driver',
            executable='lidar_node',
            name='lidar',
            namespace='rover',
            parameters=[{
                'frame_id': 'laser_link',
                'serial_port': '/dev/ttyUSB0',
                'scan_mode': 'standard'
            }],
            output='screen'
        )
    ])

The active graph can be inspected from the command line. Engineers should verify node names, topic types, publishers, subscribers, and QoS compatibility before debugging navigation behaviour.

ros2 node list
ros2 node info /rover/lidar
ros2 topic list -t
ros2 topic echo /rover/scan --once
ros2 doctor --report

Normative references and standards

ROS 2 node behaviour is defined primarily by the ROS 2 client library and middleware architecture documentation. The ROS graph naming rules are specified in REP 144, while ROS 2 package metadata conventions are defined in REP 149. Coordinate frame conventions used by rover nodes are described in REP 105, which defines frames such as map, odom, and base_link.