ROS 2 Lyrical Luth: Robotics Middleware and Tools

ROS 2 reached an important stability point on May 22, 2026, when Open Robotics released Lyrical Luth. It is the twelfth ROS 2 distribution and the project's new long-term-support release, with support scheduled through May 2031. For robotics teams planning a fresh product cycle, that five-year window is the headline. It offers a more durable base for operating systems, drivers, middleware, simulation, tests, deployment images, and field support than a short-lived distribution can provide.

Lyrical is not simply a maintenance label. It combines a new platform baseline with meaningful changes to execution, Python concurrency, GPU data movement, recording, command-line tools, robot descriptions, and tracing. The release also arrives with an officially recommended simulation pairing: Gazebo Jetty LTS. Together, those decisions give teams a clearer default stack for projects that need a supported foundation beyond a prototype.

The important caveat is that ROS 2 remains an engineering framework, not a finished robot. An LTS distribution reduces platform churn, but it does not choose the right Quality of Service policy, write hardware drivers, secure the network, prove real-time behavior, certify safety, or operate a fleet. Lyrical is a stronger foundation precisely when a team treats those responsibilities as part of the system design.

Why the five-year LTS window matters

ROS 2 distributions have different lifetimes. Kilted Kaiju, released in May 2025, follows the shorter non-LTS cycle. Lyrical is intended to remain supported for five years. That distinction matters because a robot's software is tied to much more than application source code. It depends on an operating system, architecture, compiler, Python version, middleware implementation, simulator, device drivers, navigation or manipulation packages, container images, deployment tools, and security updates.

A long support window gives maintainers more time to stabilize that complete set. It can reduce disruptive migrations during a product generation, make supplier conversations more predictable, and allow a team to qualify one platform thoroughly. It is especially valuable for robots that will remain deployed at customer sites where an operating-system or middleware change requires lab validation, a maintenance visit, a staged rollout, and a tested rollback.

LTS does not mean frozen forever, and it does not guarantee that every package in the wider ROS ecosystem will receive five years of maintenance. Each dependency still needs an owner, release history, license review, security posture, and compatibility plan. A strong adoption decision starts with a bill of materials for software, not just a line in a package manifest.

The Tier 1 baseline moves to Ubuntu 26.04 and Windows 11

The official Lyrical platform table names Ubuntu 26.04 Resolute on amd64 and arm64 as Tier 1, along with Windows 11 using Visual Studio 2022 on amd64. RHEL 10 on amd64 is Tier 2. Ubuntu 24.04 Noble, Debian Trixie, macOS, and OpenEmbedded appear at Tier 3.

Those tiers are more than a popularity ranking. They communicate the level of build, test, and support coverage a platform receives from the ROS 2 project. Open Robotics recommends that new users try Lyrical on a Tier 1 platform. A production team should go further and verify the exact packages it needs on its architecture. A core binary being available does not prove that a lidar driver, GPU library, proprietary fieldbus, simulation plugin, or vendor SDK is ready for the same combination.

The move to Ubuntu 26.04 is consequential for embedded and industrial projects that have standardized on earlier Linux releases. Before migrating, teams should check kernel and driver support, GPU and accelerator toolchains, real-time patches, vendor installers, build farms, base containers, secure-boot processes, and remote-update systems. Staying on an older ROS distribution can be the responsible short-term decision when hardware certification or a critical driver is not ready, provided the existing platform remains supported and risk is actively managed.

A new event-driven executor targets lower CPU use

One of Lyrical's most interesting additions is the callback-group Events Executor. ROS 2 executors determine how ready callbacks are scheduled, including subscriptions, timers, services, and actions. Executor behavior affects latency, fairness, CPU use, concurrency, and how easily a system can be reasoned about under load.

The new executor uses an event queue and supports multiple ROS time sources as well as multiple threads. In the Lyrical release announcement, Open Robotics reported 10 to 15 percent less CPU use than the existing single-threaded and multithreaded executors in its comparisons. That is a useful signal for compute-constrained robots and dense graphs, but it is not a universal performance guarantee.

Teams should benchmark with the real graph, middleware, callback groups, data sizes, rates, thread count, CPU affinity, operating-system settings, and hardware. Average CPU alone is not enough. Measure end-to-end latency, tail latency, jitter, deadline misses, queue growth, starvation, memory, behavior during bursts, and recovery after overload. A lower average can still hide a timing failure that matters to control or safety.

Python gains an asyncio-native model

Lyrical also introduces AsyncNode in rclpy, integrating ROS 2 Python work with asyncio. Developers can use await with subscriptions, services, and timers, and use sleep that respects simulation time. Open Robotics says this model can use less CPU than the default SingleThreadedExecutor.

This is a welcome fit for orchestration nodes that spend much of their time waiting on network I/O, device APIs, timers, or services. It can make cancellation, timeouts, and concurrent I/O flows easier to express than nested callback logic. It also aligns ROS 2 more closely with the large Python ecosystem built around asynchronous programming.

Asyncio does not make blocking work disappear. A callback that performs synchronous disk access, a long computation, or a blocking vendor call can still stall the event loop. CPU-heavy work may belong in another process or a carefully managed executor. Developers need explicit cancellation, shutdown, exception handling, backpressure, and tests using both wall time and simulated ROS time.

The GPU buffer path is promising but deliberately narrow

The release adds rosidl Buffer, a path designed for zero-copy GPU data transfer for uint8 array messages when a compatible buffer backend is available. Avoiding copies can be important for high-bandwidth camera, perception, and accelerator pipelines, where moving large frames between host and device memory consumes time, memory bandwidth, and power.

At release, the documented path was limited to publishers and subscribers using rmw_fastrtps_cpp, the Fast DDS ROS middleware implementation. Zenoh support was described as planned. That limitation belongs in every architecture review. A feature existing in ROS 2 does not mean it works across all messages, middleware implementations, transport paths, and processing frameworks.

A useful evaluation measures the whole pipeline. Confirm how memory is allocated, who owns it, when it can be reused, how synchronization works, whether components remain in one process, what happens at a bridge or recorder, and how the system falls back when a subscriber cannot accept the buffer. Compare end-to-end latency and CPU or GPU utilization, not just a microbenchmark of one handoff.

rosbag2 becomes easier to operate as part of a system

Lyrical expands rosbag2 with remote control through services, Python control for recording and playback, circular recording, more descriptive split-file names, and better observability for lost messages. These changes move rosbag2 beyond a developer manually typing a command at a laptop. A robot can integrate recording into its own lifecycle, incident logic, test harness, or fleet operations.

Circular recording is particularly useful for intermittent faults. A system can keep a bounded recent history, preserve the window around an anomaly, and avoid filling a disk during normal operation. Remote and Python control can coordinate capture with a scenario, test step, mission state, or operator action. Message-loss observability helps distinguish a clean recording from one that silently missed evidence.

Good recording design still requires discipline. Capturing every high-rate topic can overwhelm storage or I/O. Sensitive camera, location, customer, or facility data creates privacy and retention obligations. Teams should define approved topic profiles, QoS overrides, compression, file splitting, encryption, access, metadata, retention, upload conditions, and deletion. Every critical playback workflow should be tested before an incident.

Smaller improvements remove real daily friction

The command-line interface can now work with multiple parameters and topics in more places, produce a doctor report, and show more verbose service information. Parameters gain YAML tags. Logging has more configuration options, including runtime backend selection. Tracing can be opted out at runtime and receives broader improvements.

Robot descriptions also advance. URDF support includes quaternions, capsule geometry, and acceleration, deceleration, and jerk limits. robot_state_publisher can read the robot description from a topic. These may sound like incremental additions, but they can simplify pipelines that generate descriptions dynamically, represent collision geometry more faithfully, or need richer motion constraints.

Each change should still be reviewed against downstream consumers. A simulator, visualizer, planner, driver, or custom parser may not interpret every new field in the same way. The safest rollout includes representative descriptions, recorded data, launch files, and automated checks across the complete toolchain.

Lyrical and Gazebo Jetty are the recommended pair

The official Gazebo compatibility guidance pairs ROS 2 Lyrical LTS with Gazebo Jetty LTS. The default installation uses the ros_gz metapackage for the ROS distribution, and the matching pair receives the strongest integration path. Earlier defaults include Jazzy with Harmonic and Humble with Fortress.

This pairing matters because ROS and Gazebo distributions have their own dependency graphs and release schedules. Trying to combine a new ROS distribution with an older or newer Gazebo release can introduce package conflicts, require manual source builds, or depend on an integration combination that is no longer maintained. Use a non-default pair only when a required feature justifies the extra support burden.

The ros_gz_bridge also deserves an explicit interface design. It supports defined mappings rather than automatically translating every custom message. Bridge only the topics, services, and directions the test requires, pin the configuration, and validate timestamps, frame IDs, QoS, rates, and reset behavior. Simulation interfaces can standardize control of simulators, but a simulation still reflects its model assumptions, not the full physical world.

Middleware choice and QoS remain core architecture decisions

ROS 2 communicates through the RMW abstraction, which allows different middleware implementations. Fast DDS and Cyclone DDS are common DDS-based options, while Zenoh offers a non-DDS path. This flexibility is valuable for products with different discovery, routing, footprint, or network needs. It also means performance and operational behavior are not defined by ROS 2 alone.

A team should select middleware through reproducible tests on the target network. Compare discovery time, steady-state traffic, bandwidth, memory, CPU, large-message behavior, lossy Wi-Fi, multiple interfaces, containers, firewalls, multicast restrictions, router requirements, and recovery after disconnection. Record the middleware and configuration as part of the deployed product.

Quality of Service is equally important. A publisher and subscriber can both be running without exchanging data if requested and offered policies are incompatible. Reliability, durability, history, depth, deadline, lifespan, and liveliness should reflect the semantics of each data flow. A camera stream, emergency state, map, configuration event, and action feedback channel do not all need the same profile. Test late joiners, restarts, congestion, packet loss, and bag playback rather than assuming defaults are harmless.

Security is available, but it is not automatic

SROS2 provides tooling for keystores, keys, certificates, enclaves, and policies built on DDS Security capabilities. It can authenticate participants, encrypt communication, and restrict access to graph resources. That is a meaningful foundation for robots operating on shared or hostile networks.

Secure deployment still requires a system around the tools. Decide who issues identities, where private keys are stored, how robots are provisioned, how least-privilege policies are generated and reviewed, how credentials rotate, what happens when a unit is stolen, and how an incident is investigated. Network segmentation, firewalls, operating-system hardening, signed updates, secret handling, audit logs, and physical access controls remain necessary.

Security settings can also affect availability and support. An expired certificate, incorrect enclave, clock problem, or policy mismatch can look like a communication bug. Deployment tests should prove both that authorized operations work and that unauthorized nodes, topics, services, and actions are denied. Recovery procedures need to function when the normal network or identity service is unavailable.

Real-time behavior and safety still need separate proof

ROS 2 includes mechanisms that can support deterministic systems, including executor choices, composition, middleware configuration, and tracing. None of them turns a general Linux application into a hard real-time or functionally safe system by declaration. Timing depends on the kernel, scheduling, memory allocation, locks, drivers, network, middleware, executor, callbacks, hardware, thermal behavior, and workload.

Measure worst-case behavior under realistic interference. Include startup, discovery, logging, recording, high sensor load, network loss, thermal throttling, storage pressure, component failure, and recovery. Separate safety functions where the hazard analysis requires independence. Emergency stops, watchdogs, safe states, limits, redundancy, diagnostics, and operator procedures need system-level design. Certification evidence and responsibility do not arrive with an open-source package.

A practical migration path to Lyrical

New projects with compatible hardware should start by evaluating Lyrical on a Tier 1 platform, using Gazebo Jetty for the default simulation path. Existing deployments should begin with an inventory. Capture every ROS package and version, operating system, architecture, middleware, QoS override, driver, simulator plugin, bridge, launch file, parameter file, container base, compiler, Python dependency, security policy, and external SDK.

Classify each dependency as supported, source-build only, replaceable, blocked, or unknown. Rebuild continuous integration on the target platform, migrate simulation, replay representative bags, and compare graph behavior and performance. Then test on spare hardware before touching a field unit. Use staged cohorts, health gates, backups, and a rollback image.

Do not mix a distribution migration with unrelated application redesign unless there is a compelling reason. Separating platform changes from feature changes makes failures easier to isolate. Retain the old build and its source provenance long enough to reproduce a customer issue and recover a device.

The WhatAI verdict

ROS 2 Lyrical Luth is the most sensible default for a new, long-lived ROS 2 project in 2026 when the required hardware and packages support its Tier 1 baseline. The five-year window, Gazebo Jetty pairing, new executor, asyncio-native Python model, GPU buffer path, and operational rosbag2 improvements make it more than a routine annual release.

Its value is control and interoperability, not turnkey simplicity. ROS 2 lets a team compose a robot from standard communication patterns, reusable packages, multiple middleware options, simulation, visualization, recording, and security tooling. The same openness means the team owns architecture, compatibility, tuning, assurance, and operations.

Choose Lyrical for new systems that benefit from a stable support horizon and can validate the complete dependency set. Migrate existing robots when the platform benefit outweighs the qualification cost, not because a version number is newer. The teams that get the most from ROS 2 treat distribution selection as one part of disciplined robotics engineering, with measurable QoS, repeatable simulation, protected identities, reproducible builds, staged deployment, and evidence from the real machine.

WhatAI Decision Box

ROS 2 Lyrical Luth is the current long-term-support release of the open-source robotics middleware ecosystem. It combines C++ and Python client libraries with messaging, launch, lifecycle, visualization, recording, security, and debugging tools for distributed robot applications.

ROS 2 is free to use, but production robotics still requires engineering, hardware, compute, testing, security, operations, and often commercial support. Lyrical is Tier 1 on Ubuntu 26.04 for amd64 and arm64 and on Windows 11 for amd64, with a support window through May 2031.

Share how your team handles ROS distributions, middleware, Quality of Service, simulation, hardware drivers, security, testing, and migration. Include platform and package versions because compatibility depends heavily on the complete system.

Use Cases

Pricing varies by plan and region — see current pricing.

Plan features change — last updated: 2026-08-16.

ROS 2 Lyrical Luth Community Discussions

Explore community discussions. Ask and answer questions on ROS 2 Lyrical Luth to grow and learn together.

ROS 2 Lyrical Luth Pros & Cons

How to Get Results with ROS 2 Lyrical Luth: Step-by-Step Workflow

1. Define the robot and assurance target

   List the hardware, sensors, actuators, control rates, environments, latency needs, failure modes, security boundary, safety obligations, and operating lifetime before selecting packages.

2. Select one supported platform set

   For a new long-lived project, evaluate Lyrical on a Tier 1 platform and pair it with Gazebo Jetty. Freeze the operating system, architecture, ROS distribution, middleware, compiler, and core package versions.

3. Prototype the graph

   Divide the application into focused nodes and define topics, services, actions, parameters, lifecycle states, namespaces, message contracts, ownership, and expected rates before writing broad application code.

4. Design Quality of Service

   Choose reliability, durability, history, depth, deadline, lifespan, and liveliness per data flow. Test compatible and intentionally incompatible endpoints under packet loss, late joins, congestion, and restarts.

5. Build a simulation baseline

   Use the default Lyrical and Jetty pairing, bridge only required interfaces, model timing and sensor noise, and create deterministic launch and world configurations that can run in continuous integration.

6. Add observability and replay

   Standardize logging, diagnostics, tracing, topic statistics, and rosbag2 profiles. Record representative failures with metadata and verify that playback reproduces important behaviors.

7. Secure the deployment

   Threat-model the robot, isolate networks, create SROS2 keystores and enclaves, grant least-privilege policies, protect keys, define rotation and revocation, and test denied operations as well as allowed ones.

8. Validate on real hardware

   Move from simulation to hardware in controlled stages. Measure jitter, CPU, memory, discovery, startup, thermal behavior, network loss, emergency stops, degraded modes, and recovery procedures.

9. Package and reproduce

   Pin dependencies, keep source and binary provenance, build repeatable containers or images, automate tests, document middleware and QoS settings, and retain a rollback path.

10. Operate the support lifecycle

    Track ROS, operating-system, middleware, simulator, driver, and security advisories. Rehearse upgrades in a representative environment and retire unsupported distributions before field risk accumulates.

ROS 2 Lyrical Luth Gotchas and Limits to Know Before You Start

• ROS 2 is middleware and tooling, not a complete robot operating system or turnkey autonomy stack.
• Package maturity, maintenance, licenses, and compatibility vary across the wider ecosystem.
• Incompatible Quality of Service profiles can silently prevent otherwise healthy endpoints from exchanging data.
• Discovery and multicast behavior can be unreliable across firewalls, VLANs, Wi-Fi, containers, and complex networks without deliberate configuration.
• Changing the RMW implementation can alter performance, resource use, tooling behavior, and supported features.
• Security features are not a substitute for provisioning, least privilege, key protection, network segmentation, updates, and incident response.
• A desktop simulation result does not prove real-time, safety, reliability, or field performance on the target robot.
• Non-default ROS and Gazebo pairings may need source builds or create dependency conflicts.
• The Lyrical GPU buffer path is configuration-specific and was initially limited to supported message types and Fast DDS publishers and subscribers.
• LTS support does not guarantee that every third-party driver or package will be maintained for the full distribution lifetime.
• Binary support tiers differ by operating system and architecture, so verify the official table before committing hardware.
• ROS 1 reached end of life and migration can require architectural, API, launch, parameter, and build-system changes rather than a simple rebuild.

Which ROS 2 Lyrical Luth Feature Fits Your Use Case

Starter Prompts for ROS 2 Lyrical Luth

What is ROS 2?

ROS 2 is an open-source collection of middleware, client libraries, development tools, conventions, and reusable packages for robot software. It helps distributed processes communicate and coordinate, but it is not an operating system kernel or a finished robot application.

What is the current ROS 2 LTS release?

ROS 2 Lyrical Luth is the current long-term-support distribution. It was released on May 22, 2026, and its support period runs until May 2031.

Is ROS 2 free?

ROS 2 core software is free and open source, with no per-seat or runtime fee. A real deployment can still incur substantial costs for hardware, compute, cloud services, integration, testing, support, training, maintenance, and safety work.

Which platforms have Tier 1 support for Lyrical?

The official supported-platform table lists Ubuntu 26.04 Resolute on amd64 and arm64 and Windows 11 with Visual Studio 2022 on amd64 as Tier 1 platforms. RHEL 10 on amd64 is Tier 2.

Which Gazebo release should be used with Lyrical?

The recommended default pairing is ROS 2 Lyrical LTS with Gazebo Jetty LTS. Non-default pairings can require source builds, introduce package conflicts, or rely on outdated combinations.

Does ROS 2 require DDS?

ROS 2 uses a pluggable ROS middleware interface. Common implementations use DDS, including Fast DDS and Cyclone DDS, while Zenoh provides a non-DDS option. Features and behavior can differ by implementation.

Why can two healthy ROS 2 nodes fail to communicate?

Quality of Service incompatibility is a common cause. Reliability, durability, history, depth, deadline, lifespan, and liveliness policies must be compatible. Namespace, domain, discovery, firewall, middleware, and security settings can also prevent communication.

Is ROS 2 secure by default?

Security is available but must be designed and enabled. SROS2 supports keystores, certificates, enclaves, and access-control policies using DDS Security capabilities. Teams still need identity management, least privilege, key rotation, network controls, audit procedures, and deployment guidance.

Does ROS 2 guarantee hard real-time or functional safety?

No. ROS 2 provides mechanisms that can support deterministic designs, but real-time performance depends on the operating system, executor, middleware, memory behavior, drivers, hardware, configuration, and workload. Functional safety requires a separate system-level engineering and assurance process.

Should every project upgrade to Lyrical immediately?

Not automatically. New projects should strongly consider the current LTS on a Tier 1 platform, but existing systems need a dependency audit covering drivers, middleware, Gazebo, MoveIt, Nav2, ros2_control, custom packages, deployment images, and hardware support before migration.

Related AI, Coding and Development Tools

Explore the Network