ROS 2 Humble

ROS 2 Humble – definition

ROS 2 Humble Hawksbill is a long-term support (LTS) distribution of the Robot Operating System 2. It was released on 23 May 2022 and is supported until May 2027 according to REP 2000. ROS 2 is not an operating system in the conventional sense. It is a set of middleware abstractions, client libraries, tools, message definitions, build systems, and packages used to develop distributed robotic applications.

In mobile robotics, ROS 2 Humble provides the software interfaces required to connect a UGV base, wheel encoders, IMU, LiDAR, depth cameras, GNSS receivers, and onboard compute hardware. It is commonly used to build a complete robot stack: low-level motion control, state estimation, mapping, localization, path planning, obstacle avoidance, telemetry, and simulation.

For Fictionlab platforms, ROS 2 Humble is relevant as a supported native software environment for Leo Rover, while Raph Rover ships with ROS 2 Jazzy on Ubuntu 24.04 LTS. Leo Rover uses a four-wheel differential-drive chassis and a Raspberry Pi-based built-in compute unit. ROS 2 Humble can expose its base controller through standard ROS interfaces and can be extended with external sensors and companion computers. Autonomy is not enabled by default. A navigation stack, sensor drivers, calibration, and safety logic must be integrated separately.

ROS 2 Humble architecture for UGV systems

ROS 2 Humble uses a distributed publish-subscribe architecture. Nodes exchange messages over a Data Distribution Service (DDS) middleware implementation through the ROS Middleware interface (RMW). This differs from ROS 1, which depended on a central ROS Master for node discovery and registration.

In a UGV deployment, separate nodes usually perform individual functions. A motor driver publishes odometry, an IMU driver publishes inertial measurements, a LiDAR driver publishes laser scans, and a navigation node publishes velocity commands. Nodes can run on one computer or across multiple computers on the same network.

/cmd_vel commonly uses geometry_msgs/msg/Twist for linear and angular velocity commands.
/odom commonly uses nav_msgs/msg/Odometry for wheel-based pose and velocity estimation.
/scan commonly uses sensor_msgs/msg/LaserScan for planar LiDAR data.
/imu/data commonly uses sensor_msgs/msg/Imu for angular velocity, linear acceleration, and orientation data.
/tf and /tf_static distribute coordinate-frame transforms through tf2.

The expected frame hierarchy for a differential-drive rover normally includes map, odom, base_link, and sensor frames such as laser or camera_link. The coordinate conventions used by ROS are defined in REP 103. For example, REP 103 defines x as forward, y as left, and z as up for a robot body frame.

Quality of Service and real-time data delivery

ROS 2 Humble exposes DDS Quality of Service (QoS) settings per publisher and subscriber. QoS configuration is important on mobile robots because sensor streams may be frequent, wireless links may be unreliable, and stale control data can be unsafe.

ROS 2 QoS policy	Purpose in a UGV system	Typical example
Reliability	Selects best-effort or reliable delivery.	Best-effort is often used for high-rate LiDAR or camera data.
Durability	Controls whether late-joining nodes receive stored data.	Transient local is appropriate for static transforms on `/tf_static`.
History and depth	Controls queued message history.	A small queue can reduce latency for velocity commands.
Deadline	Defines the expected interval between messages.	It can be monitored to detect a missing sensor stream.

QoS incompatibility can prevent communication even when topic names and message types match. For example, a subscriber requesting reliable delivery cannot communicate with a publisher configured only for best-effort delivery. ROS 2 Humble provides QoS profiles in rclcpp and rclpy, including sensor-data-oriented settings.

Navigation and autonomy with ROS 2 Humble

ROS 2 Humble supports the Nav2 framework for autonomous navigation. Nav2 can combine a map, localization source, robot footprint, odometry, obstacle observations, planners, controllers, and recovery behaviors. It is suitable for indoor and outdoor UGV experiments when the sensor coverage and compute capacity are adequate.

A typical Leo Rover navigation configuration combines wheel odometry with IMU data and a two-dimensional LiDAR. The robot_localization package can fuse odometry and inertial data using an Extended Kalman Filter. SLAM packages such as slam_toolbox can create a 2D occupancy grid from LiDAR scans and transform estimates. For GNSS-based outdoor operation, a receiver with RTK corrections can contribute global position data, but GNSS alone does not provide sufficient obstacle perception for local navigation.

# Inspect active ROS 2 nodes and sensor topics
ros2 node list
ros2 topic list
ros2 topic hz /scan
ros2 topic echo /odom --once

# Start a Nav2 launch file with simulation time disabled
ros2 launch nav2_bringup navigation_launch.py use_sim_time:=false

On Leo Rover, computationally intensive perception pipelines may exceed the capacity of the default Raspberry Pi compute unit. Depth-camera processing, visual SLAM, dense point-cloud filtering, or neural-network inference can require a companion computer. Raph Rover can accommodate larger payloads and compute hardware where a field deployment requires additional sensors, battery capacity, or onboard processing.

Package management, builds, and deployment

ROS 2 Humble packages are commonly installed as Ubuntu packages or built from source in a colcon workspace. The primary build tool is colcon, while ament_cmake and ament_python are standard build-system integrations. Humble targets Ubuntu 22.04 Jammy Jellyfish as its primary Tier 1 platform under REP 2000.

mkdir -p ~/ugv_ws/src
cd ~/ugv_ws
colcon build --symlink-install
source install/setup.bash

For repeatable deployments, a rover application can be packaged in a Docker container. Containerization helps standardize dependencies, but direct access to serial devices, CAN interfaces, cameras, and GPU acceleration must be explicitly configured. Hardware control nodes should also be supervised by system services and protected with command timeouts or watchdog behavior.

ROS 2 Humble on Leo Rover and Raph Rover

Leo Rover documentation provides platform-specific interfaces, configuration guidance, and ROS integration material at docs.leorover.tech. A practical Humble-based Leo Rover setup usually starts with teleoperation, odometry verification, TF-frame validation, and sensor timestamp checks before enabling SLAM or Nav2.

Raph Rover is better suited to configurations that require a higher payload, larger sensor suite, or a dedicated edge-computing enclosure. Its standard software stack is ROS 2 Jazzy, but the software model remains the same: hardware drivers publish standardized messages, estimation nodes create robot state estimates, and navigation nodes consume those estimates to generate safe velocity commands.

References and documentation

The following sources document the relevant ROS 2 distribution, coordinate conventions, and architectural concepts. They should be consulted when configuring an interoperable UGV software stack.