Glossary

Fictionlab > Glossary > ROS 2 Jazzy

ROS 2 Jazzy

ROS 2 Jazzy – definition

ROS 2 Jazzy Jalisco is a long-term support (LTS) distribution of the Robot Operating System 2. It was released by Open Robotics in May 2024 and is supported until May 2029. A ROS 2 distribution is a tested set of ROS client libraries, command-line tools, middleware integrations, build tools, and packages released together under a fixed name and version policy.

For mobile robotics, ROS 2 Jazzy provides the software framework used to connect a UGV’s onboard computer, motor controller, sensors, localisation stack, perception nodes, and navigation software. It is not an autonomy system by itself. A Leo Rover or Raph Rover requires additional nodes and configuration for mapping, localisation, obstacle detection, path planning, and velocity control.

Jazzy is the first ROS 2 LTS distribution targeting Ubuntu 24.04 LTS (Noble Numbat). Its platform support policy, including supported architectures and operating systems, is defined in REP 2000. For Raspberry Pi-based systems, 64-bit ARM support and the availability of binary packages must be verified against the current Jazzy platform matrix and the operating system installed on the compute unit.

ROS 2 Jazzy architecture for UGV platforms

ROS 2 Jazzy uses a distributed node architecture. A node is an executable process that performs one defined function, such as publishing wheel odometry, reading an IMU, processing LiDAR scans, or sending velocity commands. Nodes exchange typed messages through topics, services, and actions, and expose configuration through parameters.

Communication is implemented through a ROS middleware interface called RMW. In a typical ROS 2 installation, the RMW implementation uses DDS (Data Distribution Service), an OMG standard for data-centric publish-subscribe communication. DDS discovery allows nodes on the same network and ROS domain to find compatible publishers and subscribers without a central ROS master.

UGV function Typical ROS 2 interface Common message type
Motor velocity command Topic geometry_msgs/msg/Twist
Wheel odometry Topic nav_msgs/msg/Odometry
2D LiDAR scan Topic sensor_msgs/msg/LaserScan
Inertial measurement data Topic sensor_msgs/msg/Imu
Coordinate frame transforms Topic tf2_msgs/msg/TFMessage
Navigation goal Action nav2_msgs/action/NavigateToPose

Mobile robot integrations should follow the coordinate conventions in REP 103. ROS uses metres for length, radians for angles, and right-handed coordinate frames. A common UGV transform tree is map → odom → base_link → sensor_frame. Incorrect frame orientation or inconsistent timestamps can invalidate localisation and navigation results.

Jazzy on Leo Rover and Raph Rover

Leo Rover is a four-wheel differential-drive UGV typically configured with an onboard Raspberry Pi compute unit. Its ROS 2 software compatibility depends on the installed operating system, rover firmware and drivers, and the selected ROS distribution. Moving a Leo Rover software stack from ROS 2 Humble to Jazzy requires checking the operating system, CPU architecture, driver compatibility, package dependencies, and custom workspace source code.

A basic Jazzy deployment on Leo Rover commonly includes the following functional layers. These components can run on the onboard computer or be split between the rover and an external workstation, provided that the ROS network configuration is consistent.

  • A hardware driver that receives wheel encoder data and publishes odometry.
  • A velocity interface subscribing to /cmd_vel and converting linear and angular commands to differential-drive motor commands.
  • Static and dynamic TF publishers defining chassis, LiDAR, camera, IMU, and GNSS frame relationships.
  • Sensor drivers for USB or Ethernet LiDAR, depth cameras, IMUs, and GNSS/RTK receivers.
  • Navigation packages such as Nav2, together with SLAM or localisation software.

Raph Rover can use the same ROS 2 Jazzy architecture but has a different integration scope. Its larger payload capacity can support additional compute hardware, larger sensor sets, or higher-power perception equipment. This does not change the ROS graph design. It changes practical requirements such as power budgeting, mounting geometry, network topology, sensor calibration, and real-time compute load.

Quality of Service and mobile network behaviour

ROS 2 Quality of Service (QoS) settings define how publishers and subscribers exchange data. QoS is important on UGVs because camera streams, LiDAR scans, control commands, and map data have different reliability and latency requirements. A subscriber and publisher with incompatible QoS policies may not communicate.

The standard ROS 2 QoS profiles are documented in the ROS 2 Jazzy QoS documentation. In practical rover deployments, the following choices are common starting points.

  • reliable delivery for control, configuration, and critical state information.
  • best_effort delivery for high-rate sensor streams when dropping stale data is preferable to retransmission delay.
  • keep_last history with a bounded queue depth for memory control.
  • transient_local durability for static information that late-joining nodes must receive, such as a map or latched configuration state.
source /opt/ros/jazzy/setup.bash

ros2 doctor --report
ros2 node list
ros2 topic list
ros2 topic hz /scan
ros2 topic echo /odom --once

The ros2 topic hz command measures the observed message rate at the local subscriber. It does not prove that sensor timestamps are correct or that every message reaches every node. For navigation debugging, engineers should inspect message frequency, timestamp monotonicity, TF availability, frame IDs, covariance values, and QoS compatibility.

Migration from ROS 2 Humble to Jazzy

ROS 2 Humble Hawksbill and ROS 2 Jazzy Jalisco are separate distributions. For Ubuntu, Humble targets Ubuntu 22.04 LTS, while Jazzy targets Ubuntu 24.04 LTS under the ROS 2 release policy. Binary packages from one distribution must not be mixed with packages from another distribution in the same environment.

Before upgrading a UGV workspace, validate the following items in a controlled environment. This is especially important for custom hardware drivers and sensor SDK wrappers.

  • Confirm that all required packages have Jazzy releases or can be built from source.
  • Rebuild colcon workspaces after sourcing the Jazzy environment.
  • Check Python dependencies because Ubuntu 24.04 uses a newer Python runtime than Ubuntu 22.04.
  • Validate launch files, parameter names, plugin APIs, and deprecated package interfaces.
  • Test motor stop behaviour and command timeouts before operating the rover near people or equipment.

Normative references and official documentation

ROS 2 Jazzy is maintained under the ROS 2 distribution and release process. The following primary sources define its support status, platform targets, conventions, and communication behaviour.

See also