ROS 2 Lyrical 深度解析：相比 Humble，究竟升级了什么？

有条理hac

562人浏览 · 2026-06-12 11:19:02

有条理hac · 2026-06-12 11:19:02 发布

从机器人开发者视角看 ROS 2 的下一代 LTS 版本

2026年5月，ROS 2 发布了最新长期支持版本（LTS）—— Lyrical Luth。

对于大多数机器人团队来说，真正的问题不是：

“Lyrical 有什么新功能？”

而是：

“相比我们正在使用的 Humble，它到底解决了哪些痛点？”

本文将从架构、性能、开发效率、AI融合以及工程实践几个维度，对 ROS 2 Lyrical 与 Humble 进行全面对比分析。

一、为什么 Humble 能成功？

2022年发布的 Humble Hawksbill 是 ROS2 历史上最成功的 LTS 版本之一。

其核心价值在于：

DDS生态成熟
Nav2趋于稳定
MoveIt2工业化
rosbag2逐渐可用
Component组件化成熟

大量工业机器人项目至今仍运行在 Humble 上。

但是随着机器人越来越向：

AI Agent
多传感器融合
边缘GPU计算
自动驾驶
VLA（Vision-Language-Action）

方向发展，Humble 开始暴露出一些问题。

二、Humble 的五大痛点

1 Async 编程能力不足

在 Humble 中：

client.call_async(req)

虽然支持异步接口。

但本质上：

spin()

仍然依赖 Executor 调度。

开发者经常会写出：

while not future.done():
    rclpy.spin_once(node)

这样的代码。

结果：

可读性差
状态管理复杂
容易形成回调地狱

尤其是在：

Web API
云端机器人
AI Agent

场景中非常明显。

2 Executor 调度效率有限

Humble 默认：

SingleThreadedExecutor
MultiThreadedExecutor

问题在于：

Ready Queue竞争
Callback延迟
CPU空转

当节点数量超过几十个后：

Camera
Lidar
Localization
Mapping
Planner
Controller

调度开销开始明显上升。

3 AI数据链路复制过多

典型流程：

Camera
 ↓
CPU Memory
 ↓
ROS Message
 ↓
DDS
 ↓
CPU Memory
 ↓
GPU
 ↓
TensorRT

一次图像传输可能发生：

2~4次内存复制

对于：

4K视觉
多摄像头
Transformer模型

开销巨大。

4 rosbag2 可观测性不足

很多团队都经历过：

录了8小时数据
回来看发现丢包

但 Humble 无法实时发现：

Topic丢失
Recorder过载
DDS丢包

往往是在数据分析阶段才发现问题。

5 运维与诊断工具不足

排查系统时经常需要：

ros2 topic hz
ros2 topic info
ros2 node info

反复组合命令。

大型系统调试成本较高。

三、Lyrical 的核心优化

Lyrical 并不是一次功能升级。

它更像一次：

面向 AI 机器人时代的基础设施升级。

四、优化一：AsyncNode —— 原生异步编程

Lyrical 引入：

from rclpy.experimental import AsyncNode

开发者可以直接使用：

await

语法。

示例：

async def callback():
    result = await client.call(req)
    await clock.sleep(1.0)

相比 Humble：

future = client.call_async(req)

开发体验发生质变。

优势：

原生 asyncio
更易集成 FastAPI
更易集成 LangChain
更适合 Agent 系统

对于机器人 AI Agent：

LLM
 ↓
Planner
 ↓
ROS Action
 ↓
Robot

会极大降低代码复杂度。

五、优化二：新的 Executor 架构

Lyrical 引入：

Callback Group Events Executor

即：

EventsCBGExecutor

官方测试显示，相比传统 Executor 可以降低约 10%~15% CPU 开销。

核心思想：

Polling
   ↓
Event Driven

传统：

不断检查谁准备好了

Lyrical：

谁触发事件就执行谁

对于：

Nav2
MoveIt2
自动驾驶

这类高并发系统收益明显。

六、优化三：真正面向 AI 的零拷贝通信

这是我认为 Lyrical 最重要的升级。

新增：

rosidl::Buffer

用于替代：

std::vector<uint8_t>

的数据传输方式。

以前：

GPU
 ↓
CPU
 ↓
DDS
 ↓
CPU
 ↓
GPU

现在：

GPU Buffer
 ↓
ROS Topic
 ↓
GPU Buffer

减少数据复制。

对于：

TensorRT
CUDA
Isaac ROS
YOLO
SAM2

收益巨大。

这是 ROS2 开始真正拥抱 AI Workload 的标志。

七、优化四：rosbag2 进入工程化时代

Lyrical 对 rosbag2 做了大量增强。

远程控制

以前：

Ctrl+C

停止录制。

现在：

ROS Service

直接控制：

Start
Stop
Pause
Resume

Python API

直接：

pause()
resume()
stop()
seek()

即可控制数据录制。

丢包监控

新增：

/ events / rosbag2_messages_lost

Topic。

实时发现：

DDS丢包
Recorder过载
存储瓶颈

问题。

对于自动驾驶数据采集团队意义非常大。

八、优化五：URDF 向工业机器人靠拢

Lyrical 的 URDF 1.2 增加：

acceleration
deceleration
jerk

约束。

支持更真实的运动学建模。

过去：

速度限制

现在：

速度
加速度
减速度
Jerk

全部支持。

更符合：

工业机械臂
协作机器人
AGV

控制需求。

九、优化六：运维能力增强

新增：

ros2 topic bw --all

查看全系统带宽。

ros2 service info --verbose

查看详细服务状态。

ros2 doctor --report

生成系统诊断报告。

对于现场调试非常实用。

十、Humble 与 Lyrical 对比总结

维度	Humble	Lyrical
生命周期	2022-2027	2026-2031
Python开发	Callback/Future	AsyncNode
Executor	Single/Multi	EventsCBG
CPU利用率	普通	更优
GPU数据流	多次复制	rosidl::Buffer
AI集成	一般	优秀
rosbag2	基础功能	工程化
URDF能力	基础	工业级
运维工具	一般	增强
长期规划	维护期	下一代主线