W0: ROS2 序论与产业全景

Fri, 10 Apr 2026 00:00:00 GMT

W0-ROS2序论与产业全景

关联：学习主线与阶段路线 · ROS2求职知识图谱

先说结论

如果把机器人软件看成一个产业链问题，而不是一个“会不会写节点”的问题，那么 ROS2 的价值可以概括成一句话：

它不是机器人本体，也不是实时内核，更不是安全认证本身；它是现代机器人系统里最重要的“通用软件装配层”之一。

为什么这句话重要？

机器人项目真正难的，不只是算法对不对
更难的是：感知、定位、规划、控制、硬件驱动、仿真、日志、远程调试、多机通信 怎么被组织成一个可维护系统
ROS2 的核心价值，就是把这些异构模块组织成一个可以协作、可以替换、可以扩展、可以调试的系统

所以，学习 ROS2 不能只把它当成“几个 topic + launch + rviz 命令”。

更准确的理解是：

对学生来说，它是机器人领域最重要的通用工程语言之一
对团队来说，它是跨算法、软件、硬件、测试之间的协作协议
对公司来说，它是缩短研发周期、降低系统集成成本、复用社区资产的基础设施
对你个人来说，它是从“会写功能”走向“会搭系统、会讲架构、会解释工程权衡”的起点

一、ROS2 到底是什么，为什么它叫“机器人操作系统”

先把一个最容易误解的问题说清楚。

ROS / ROS2 这个名字里有 Operating System，但它并不是像 Linux、Windows 那样直接管理 CPU、内存、进程和设备的内核级操作系统。

它更接近：

一套机器人领域的 分布式中间件 + 开发框架 + 工具链 + 生态标准

也就是说，ROS2 通常跑在：

Ubuntu
Debian
Windows
macOS
甚至带 RT patch 的 Linux、容器、嵌入式平台之上

它做的不是“替代底层 OS”，而是：

定义机器人模块之间如何通信
定义数据如何描述和序列化
定义节点如何被启动、组合、管理、监控
提供调试、录包、回放、可视化、仿真、测试等工具
让不同团队写出的模块，能在一个统一图谱里协作

所以从底层往上看，一个常见机器人软件栈大致是：

硬件层：传感器、驱动器、相机、雷达、IMU、编码器、机械臂、底盘
操作系统层：Linux / RT-Linux / Ubuntu
传输与通信层：DDS / UDP / SHM / 网络栈
ROS2 中间件抽象层：RMW
客户端库层：rclcpp、rclpy、rclc
应用节点层：定位、感知、导航、控制、任务编排
工具层：ros2 cli、rviz2、rosbag2、launch

这也是为什么很多工业团队会说：

ROS2 不是“算法框架”这么简单，它更像机器人世界的应用集成总线。

二、为什么 ROS 会成为机器人领域的事实标准之一

1. 它解决的不是单点能力，而是“系统复杂度爆炸”

机器人和传统单体软件有一个根本差别：

机器人天然是 多模块、强并发、强异构、强时序、强物理约束

一个真实机器人系统通常同时包含：

高频传感器流
控制闭环
规划与状态机
远程监控
数据录制与问题复现
多进程甚至多机协同

如果没有统一的软件框架，会出现什么情况？

每个团队自己定义 TCP/UDP 协议
每个模块自己定义消息格式
每个项目都重新造日志、录包、可视化、调试工具
算法同学、驱动同学、应用同学之间接口互相不兼容
同一个问题换了硬件或换了网络环境就得重做一遍

ROS 当年能快速崛起，不是因为它“更优雅”，而是因为它第一次大规模把机器人研发里的这些重复劳动标准化了。

2. 它让“研究成果可复用”这件事第一次变得现实

机器人长期有一个老问题：

论文很多
演示很多
但系统复现和工程落地很难

ROS 生态把很多通用问题抽成标准模块：

地图与导航
TF 坐标变换
传感器消息格式
可视化
机械臂建模
运动规划
仿真接口

这带来的不是“省一点代码”，而是：

让机器人研发从“每个团队重新造轮子”变成“在公共底座上做差异化”。

这和互联网世界里：

大家不再从零写网络协议
大家不再自己造数据库
大家不再自己写编译器

是同一种生产力跃迁。

3. 它形成了人才、工具、项目、社区的正反馈

一个技术能不能成为事实标准，不只看技术本身，还看有没有网络效应。

ROS 的网络效应体现在：

学校课程大量采用
实验室默认使用
开源包数量极多
招聘岗位大量提及
上层项目如 Nav2、MoveIt2、ros2_control 继续增强它的中心地位

根据 Open Robotics 在 2024-01 发布的 2023 ROS Metrics Report，已知使用 ROS 的公司数量已到 910+。而 Open Robotics 在 2025-05-31 ROS 1 EOL 公告中进一步提到，2024 年 9 月 的下载数据里，ROS 2 已经占全部 ROS 下载量的 接近 80%。

这两个信息合起来说明一件事：

ROS 已经不是“小圈子玩具”
ROS2 也不再只是“下一代尝鲜版”
它已经完成了从研究框架到主流工程底座的迁移

三、ROS2 出现之前，ROS1 为什么成功，为什么又不够用了

1. ROS1 为什么成功

ROS 最早在 2007 年 11 月 启动，背景是 Willow Garage 为 PR2 机器人构建开发环境。

ROS1 的时代命题是：

快速做研究
快速拼系统
高度灵活
让不同实验室的软件能互通

在那个阶段，这个定位极其成功。

因为当年的机器人主流场景大多是：

单机器人
算力相对充足
实验室网络较好
对严格实时性要求不高
更看重研究效率而不是产品级稳定性

ROS1 很适合这种环境，所以它迅速成为：

学术研究的通用底座
机器人算法验证的默认平台
大量开源项目的共同语言

2. ROS1 的架构红利，也是它的时代局限

ROS1 的通信、发现、参数、工具链，在“研究原型机”阶段非常好用，但它的设计前提比较强：

单主机 / 单主节点思维很重
对不稳定网络支持弱
安全性设计几乎不是优先级
分布式场景下的弹性有限
实时性支持不足
生命周期管理不标准
面向产品部署的模式不够清晰

Open Robotics 在官方 Why ROS 2? 设计文档里把新需求说得非常直接，主要包括：

多机器人系统
小型嵌入式平台
实时系统
非理想网络
生产环境
更明确的系统构建模式

这几条非常关键。

因为它们对应的不是“技术洁癖”，而是商业化之后一定会撞上的墙。

四、ROS2 诞生的真正原因：机器人从实验室走向产业

1. 行业发生了什么变化

ROS1 时代，很多机器人项目更像“科研系统”。

ROS2 时代，行业问题变成了：

机器人要进仓库、工厂、商场、医院、农场、道路
系统要长期运行，而不是 demo 10 分钟
要支持远程升级、远程监控、问题回放
要支持多机协作和复杂网络环境
要考虑实时控制、资源受限设备、安全、部署一致性

换句话说：

机器人软件的核心矛盾，从“能不能跑起来”，变成了“能不能稳定地规模化运行”。

ROS2 就是在这个产业阶段切换中诞生的。

2. ROS2 不是小修小补，而是一次底座重构

如果只从表面看，很多人会以为 ROS2 只是：

命令改了
API 改了
launch 改了

这理解太浅。

ROS2 真正做的是：

不再自己硬扛所有通信中间件细节
引入 DDS 作为底层数据分发基础
通过 RMW 把不同中间件实现抽象出来
用 QoS 把通信行为从“黑盒默认值”升级为“可工程化配置”
引入 lifecycle、composition、security、rosbag2、多平台支持等能力

这意味着 ROS2 的目标从一开始就不是“更像 ROS1”。

而是：

让机器人软件能从研究原型平滑成长为生产系统。

五、从底层原理看，ROS2 为什么比 ROS1 更像现代工业系统

1. ROS2 的核心哲学：分布式图，而不是单体程序

一个机器人系统不是一个程序，而是一张图。

这张图里有：

节点
topic
service
action
parameter
TF
executor
callback group

本质上，ROS2 让你把一个大系统拆成许多边界明确的组件，再通过标准通信语义把它们连起来。

这在工程上有几个巨大价值：

方便团队分工
方便替换模块
方便隔离故障
方便录制问题现场
方便把单机场景扩展成多机协同

2. DDS 和 RMW：ROS2 最重要的架构升级

ROS1 时代，ROS 自己承担了大量通信机制设计。

ROS2 时代则采用了更成熟的思路：

下面用 DDS
上面用 RMW 抽象

你可以把它理解成：

DDS 是“工业级消息分发地基”
RMW 是“ROS2 对不同地基的适配层”

这样做的好处非常大：

ROS2 不必把发现、传输、可靠性等都从零重造
可以利用 DDS 现成的 QoS、发现机制、安全扩展
可以在不同场景切换不同实现，如 Fast DDS、Cyclone DDS、Connext
网络、时延、可靠性等问题变成了可调工程参数，而不是纯玄学

这也是 ROS2 为什么更适合工业讨论。

工业系统最怕的不是“功能少”，而是：

一旦环境变化，就不知道系统会怎么退化

QoS + DDS 至少给了你描述和控制退化行为的工具。

3. QoS：这是 ROS2 工程性的灵魂之一

很多初学者觉得 QoS 只是几个选项：

reliable
best_effort
keep_last
keep_all

但从工程视角看，QoS 其实是在回答三个核心问题：

数据丢一点可不可以？
数据延迟一点可不可以？
新订阅者是否需要历史数据？

举几个现实例子：

场景 A：激光雷达点云给可视化

丢一两帧通常可以接受
但不能因为追求绝对可靠，把系统拖得越来越卡

这时 best_effort 往往合理。

场景 B：机械臂抓取前的目标位姿

一次错误数据可能导致抓空甚至碰撞
这里可靠性比“偶尔少一点延迟”更重要

这时更偏向 reliable。

场景 C：配置、地图、静态变换

后来的订阅者也要拿到最近一次有效数据

这时就会涉及 transient local 这类策略。

所以 QoS 不只是“会背名词”，而是：

你是否理解每类数据在业务上的容错边界。

这正是工业系统思维。

4. Lifecycle：从“脚本式启动”升级到“可监管系统”

ROS2 的 managed node / lifecycle 设计非常值得重视。

它的思想很像工业软件里的受控启动状态机：

Unconfigured
Inactive
Active
Finalized

这带来的价值是：

系统可以先配置再激活
节点失败后可以更标准地恢复
上层调度器更容易知道当前系统处于什么状态

为什么工业场景很需要它？

因为真实系统里，启动顺序和依赖关系很敏感。

比如一个 AMR 仓储车系统：

先确认激光雷达驱动正常
再启动定位
再启动地图匹配
再激活路径规划
最后才开放任务执行

如果没有明确生命周期，很多系统就只能靠：

睡几秒
写 shell 脚本重试
靠人工盯日志

这不是工程化。

Lifecycle 的意义就在于把“上线顺序、激活条件、失败恢复”纳入标准模型。

5. Composable Nodes：降低进程边界成本

在 ROS1 里，nodelet 是一个方向，但使用体验和统一性有限。

ROS2 的 composable nodes 更明确地支持：

将多个组件装入同一进程
在保留模块化边界的同时减少序列化/拷贝成本

这对高吞吐场景很关键。

典型场景：

相机驱动 -> 图像预处理 -> 检测推理 -> 跟踪

如果每一步都跨进程序列化，大流量数据开销会很大。

组合节点的价值是：

保留软件模块化
同时尽量接近高性能流水线

6. rosbag2、安全、多平台：这些都不是锦上添花

rosbag2 的意义不是“录包功能升级”这么简单，而是：

更好的性能
更现代的数据格式支持
更贴近真实排障流程

一个真实工业团队排查问题，往往不是现场 debug，而是：

先录问题发生时的数据
回放到测试环境
对比不同版本行为
复现实验结果

没有稳定录包和回放能力，机器人问题几乎无法规模化排查。

安全也是类似逻辑。

ROS1 在安全上并不是零星缺点，而是设计优先级不在那里。

ROS2 借助 DDS-Security，把身份、加密、访问控制纳入体系，这意味着它至少具备往产品级环境走的结构基础。

六、ROS2 解决了哪些“过去做机器人很痛”的问题

下面用更偏商业分析的方式，把 ROS2 解决的问题归纳成几类。

1. 解决“研发资产不复用”的问题

没有通用框架时：

每个项目从零搭通信层
每个团队重复造可视化、日志、接口描述、驱动适配

有了 ROS2：

你可以复用社区标准消息
复用现成工具链
复用大量上层包和项目模板

这直接降低研发成本。

2. 解决“实验室能跑，现场跑不稳”的问题

ROS2 没有神奇到自动保证工业级稳定，但它至少补上了很多 ROS1 时代的结构缺口：

QoS
多 RMW
lifecycle
组合节点
更好的录包回放
更好的参数与 launch 组织

这让系统稳定性从“经验活”变成“可设计、可验证、可调优”的工程活动。

3. 解决“多机协同和复杂网络下难以控制”的问题

真实机器人系统常见这些情况：

机器人本体多个计算单元
车端和边缘服务器协同
多机器人共享任务调度
Wi-Fi 抖动、丢包、网络切换

ROS2 明显比 ROS1 更适合处理这些问题，因为它从设计上就承认：

网络并不总是理想的
节点也不一定都在同一台机器上

4. 解决“从 PC 到 MCU 的链路割裂”问题

micro-ROS 的意义很大。

它不是让所有控制逻辑都塞进 MCU，而是让资源受限设备也能更自然地进入 ROS2 体系。

典型实战意义：

上位机负责导航和任务
MCU 负责电机、传感器采样、低层控制
二者通过统一体系协作，而不是完全两张皮

这对机器人产品化非常关键。

七、ROS1 和 ROS2 到底差在哪，不要只背“DDS”

面试和工程里最怕一种回答：

ROS1 和 ROS2 的区别？ROS2 底层用了 DDS。

这句话不算错，但远远不够。

更完整的回答应该从“目标函数变化”来讲。

1. ROS1 的目标函数

研究效率优先
灵活优先
快速原型优先

2. ROS2 的目标函数

在保留模块化和开放生态的同时
增强分布式可扩展性
增强实时/嵌入式适配能力
增强生产环境可用性
增强网络与部署可控性

3. 可以落地记忆的对比

通信架构

ROS1：自研通信体系，简单直接，但扩展性和工业适配有限
ROS2：DDS + RMW，通信行为更可调，可适配更多场景

可靠性与网络适应

ROS1：在理想局域网和研究环境里很好用
ROS2：更面向复杂网络、多机和跨环境部署

生命周期管理

ROS1：缺少统一生命周期模型
ROS2：有 lifecycle，更适合受控启动和恢复

性能与组合

ROS1：nodelet 可用，但整体不够统一
ROS2：composable nodes 更系统化

安全

ROS1：基本不以安全为设计重点
ROS2：有基于 DDS-Security 的结构支持

嵌入式

ROS1：嵌入式支持弱
ROS2：通过 rcl / rclc / micro-ROS 明显增强

产品化路径

ROS1：适合原型和研究
ROS2：更适合作为产品级机器人软件基础设施

4. 一个现实判断

截至 2025-05-31，ROS 1 Noetic 已正式 EOL。

这意味着今天如果还把学习主线放在 ROS1 上，除非你的工作环境有历史包袱，否则投资回报率已经明显下降。

ROS1 仍值得了解，因为：

你会遇到历史项目
你会遇到迁移问题
你会遇到面试追问

但你的主线能力建设应当放在 ROS2。

八、ROS2 在机器人行业里的真实位置

1. 它不是所有层都统治，但在“应用集成层”非常强

机器人公司通常不会只靠 ROS2。

真实系统往往是：

下层：MCU / FPGA / EtherCAT / CAN / 厂商控制器
中层：ROS2 负责系统集成、状态流转、任务编排、感知规划接入
上层：调度平台、云端平台、数字孪生、运营后台、数据库、AI 服务

所以 ROS2 最强的层次不是：

安全 PLC 替代品
硬实时内核替代品
企业 ERP 替代品

它最强的是：

把机器人软件系统的“中间大脑”和“模块接口层”标准化

2. 哪些赛道特别依赖 ROS2

从实践上看，以下方向最容易看到 ROS2：

AMR / 室内移动机器人
服务机器人
仓储物流机器人
移动操作机器人
机械臂集成与柔性制造
自动驾驶科研/原型系统
农业机器人
巡检机器人
医疗辅助机器人

这些场景的共同点是：

传感器多
软件模块多
需要大量集成
需要快速迭代

这正是 ROS2 的主场。

3. 哪些场景 ROS2 不是唯一中心

如果你的系统是：

极强硬实时
强安全认证
极致资源受限
结构高度固定

那么 ROS2 往往不是唯一主角，甚至不是主角。

比如：

伺服控制最内环
安全急停链路
功能安全认证部分
很小的裸机控制器

这类部分通常还会依赖：

RTOS
PLC
专有控制器
厂商 SDK

工业落地的成熟做法，通常不是“全部交给 ROS2”，而是：

把 ROS2 放在适合它的位置，让它和实时控制层、现场总线层、云平台层协作。

这才是工程判断。

九、和其他机器人软件路线相比，ROS2 的优势与劣势

这里不做“宗教战争”，只做工程视角比较。

1. 相比厂商私有 SDK / 私有机器人软件栈

ROS2 的优势：

开放生态，学习成本能转化为长期资产
可观测性强，工具链完整
社区包多，复用度高
更容易跨硬件、跨项目迁移

ROS2 的劣势：

集成复杂度比“厂商全家桶”高
需要自己承担更多架构治理
长期版本兼容、依赖管理需要经验

一句话总结：

私有栈适合封闭场景快速交付
ROS2 适合追求生态复用与系统自主权

2. 相比 PLC / 传统工业自动化架构

PLC 的优势在于：

确定性
可靠性
认证成熟
现场维护体系成熟

ROS2 的优势在于：

感知、规划、AI 集成能力强
模块组合灵活
更适合复杂自主系统

所以在工业里常见的不是二选一，而是组合：

PLC 管强确定性和安全逻辑
ROS2 管高层任务、感知、规划、柔性行为

3. 相比 Orocos / RTT 一类强实时框架

Orocos/RTT 更强调：

硬实时
确定性执行
控制领域深度

ROS2 更强调：

全系统集成
生态规模
上层应用复用

如果你做的是最内层控制回路，Orocos 一类框架可能更专。如果你做的是“整个机器人产品的软件体系”，ROS2 的综合价值通常更高。

4. 相比 YARP、LCM、ZeroMQ 自建框架等

这些路线通常能在某些局部问题上做得很强：

更轻
更可定制
更符合某些组织的历史积累

但 ROS2 的最大优势不是单点最优，而是：

生态总量
人才供给
标准接口
工具完整度
上层项目协同

商业世界里，很多时候不是最优技术赢，而是“总体拥有成本更低”的技术赢。

ROS2 很符合这个规律。

十、现实工业场景里，为什么大家愿意用 ROS2

下面给几个贴近实战的例子。

场景 1：仓储 AMR

一个仓储 AMR 通常要处理：

激光雷达、IMU、轮速计
定位建图
局部/全局规划
障碍物避让
任务调度
远程监控
数据录制与故障复盘

为什么 ROS2 合适？

Nav2、TF、rviz2、rosbag2 这些能力能直接进入工程链路
节点化架构适合快速替换定位或规划模块
QoS 能帮助处理无线网络和高频数据流
多进程/多机部署自然

对公司来说，这意味着：

研发速度更快
问题定位更标准
人员流动时知识迁移更容易

场景 2：工厂里的柔性机械臂工作站

比如做：

视觉引导抓取
打磨
码垛
检测

这种场景的痛点不是机械臂能不能动，而是：

相机、视觉算法、路径规划、机器人控制器怎么接起来
现场切换工件或夹具时，软件能不能快速重配

ROS2 的价值在于：

它能把感知、规划、控制外围逻辑组织起来
MoveIt2、ros2_control、ROS-Industrial 生态可以复用
生命周期、参数化和 launch 让产线切换更可控

但同样要注意：

最内层伺服控制不一定让 ROS2 做
安全和硬实时部分仍会有专有系统参与

这就是“ROS2 在工业里通常担任系统大脑，而不是电机驱动器本身”。

场景 3：多机器人协同

比如医院配送、酒店配送、园区巡检。

这类系统里最难的是：

不是某一台机器人功能
而是多机、弱网、任务调度、异常恢复、远程运维

ROS2 的分布式架构、QoS、生命周期和多机通信能力，让它比 ROS1 更适合承担这种系统的软件底座。

场景 4：资源受限的边缘控制单元

如果机器人本体里有 MCU 负责低层采样和执行，而主控负责高层任务，那么 micro-ROS 能让这类设备进入统一的软件体系。

这在产品上非常重要，因为它减少了“上下位机两种语言、两套协议、两套调试体系”之间的割裂。

十一、ROS2 的优点，不要只背“生态多”

1. 模块化强

模块化不是说“文件拆得开”，而是：

节点边界清楚
接口明确
替换成本相对可控

2. 生态规模大

生态大带来的不是热闹，而是：

找资料更容易
找现成包更容易
招人更容易
换项目时经验迁移更强

3. 工具链完整

rviz2、ros2 topic、ros2 service、ros2 param、rosbag2、launch 这些工具把“开发-调试-验证-复现”串成了闭环。

4. 更接近产品化

相对 ROS1，ROS2 在这些方面明显更成熟：

QoS
lifecycle
安全
嵌入式延展
多平台
组合与性能路径

5. 社区标准化强

坐标、消息、驱动、仿真、导航、机械臂、可视化都有大量共识和标准接口，这会极大减少跨团队沟通成本。

十二、ROS2 的缺点，也必须讲清楚

如果只讲优点，你后面一做项目就会很挫败。

1. 学习曲线并不低

ROS2 表面上看入门容易，实际上要真正用好，必须同时理解：

Linux
C++ / Python
分布式通信
QoS
launch
调试工具
构建系统
并发回调和 executor

它不是一门单点技术，而是一套系统工程方法。

2. 兼容性和版本治理是现实成本

真实项目里经常会遇到：

不同 distro 差异
第三方包移植不一致
文档版本不统一
不同 RMW 表现差异

这意味着 ROS2 很强，但并不“省心”。

3. 不是天然硬实时

ROS2 可以更接近实时系统，但“支持实时”不等于“天然硬实时”。

如果系统要满足极严苛确定性，仍需要：

RT 内核
内存与线程策略
执行器设计
现场总线与控制器配合

4. 安全能力存在，但落地并不自动

有 DDS-Security，不代表你开箱即用就安全。

真实安全需要：

网络分区
凭证管理
权限设计
运维策略

5. 分布式系统的调试复杂度天然更高

节点多了、机子多了、网络复杂了，排障就一定更难。

ROS2 给了你工具，但不会替你思考。

十三、今天为什么还值得学 ROS2，而不是直接跳到“AI 机器人”

这是一个现在很容易误判的问题。

很多人会觉得：

大模型来了
具身智能火了
那 ROS2 会不会过时？

我的判断是：

短期到中期，恰恰相反，AI 越强，ROS2 这类系统底座越重要。

原因很简单。

AI 解决的是：

感知理解
决策生成
语义交互
策略泛化

但机器人最终还是要落到：

传感器接入
消息流组织
状态同步
控制执行
任务编排
故障回退

也就是说：

AI 决定“做什么”
ROS2 往往负责“怎么把系统组织起来并真正执行”

尤其在现阶段的大多数商业项目里，系统集成问题仍然比“模型推理本身”更刚性。

十四、学习 ROS2，正确的心智模型是什么

你后面开始 W1 时，最应该带着的不是“我去学 API”，而是下面这几个心智模型。

1. ROS2 是系统工程，不是命令背诵

学习目标不是：

会 ros2 topic list

而是：

能说清楚一个机器人系统为什么要拆成这些节点
能解释消息流和数据流
能解释为什么这里用 topic，不用 service
能解释为什么这条链路需要 reliable

2. 每学一个概念，都要问一句“工业里为什么需要它”

比如学：

topic
service
action
parameter
lifecycle
QoS

都不要停留在“定义是什么”。

要继续追问：

它解决了什么工程痛点？
如果没有它，现场会怎么乱？

3. 把 ROS2 学成“架构语言”

以后不论你做导航、感知、机械臂还是多机器人，最值钱的能力不是某个包的 API，而是：

你能不能把系统画成图
能不能解释模块边界
能不能做技术取舍
能不能把问题从日志一路定位到通信、参数、调度、执行

4. 把项目经验和 ROS2 原理绑定

后续学习中，每个知识点最好都绑定你的项目：

当前项目里有哪些节点
哪些 topic 是主干数据流
哪些地方可能需要 QoS 调优
哪些节点未来适合用 lifecycle

这样知识才不是飘着的。

十五、W0 学完以后，你应该能回答的 10 个问题

ROS2 本质上是什么，为什么它不是真的操作系统？
为什么 ROS 会成为机器人领域事实标准之一？
ROS1 当年为什么成功？
ROS1 为什么不再适合做未来主线？
ROS2 诞生的根本行业背景是什么？
DDS、RMW、QoS 在 ROS2 里分别扮演什么角色？
ROS2 相对 ROS1 最重要的升级不是哪些表层变化，而是什么底层目标变化？
ROS2 在工业系统里通常处在什么层，不适合替代什么层？
为什么 ROS2 对 AMR、服务机器人、柔性制造这类场景特别有价值？
学 ROS2 应该建立怎样的系统工程心智模型？

如果这 10 个问题你能讲顺，后面的 W1 就不会只是“学语法”，而会变成“学一套机器人系统方法论”。

十六、给你的学习建议：W0 之后怎么进入 W1

最合理的进入方式不是马上啃大而全源码，而是按下面顺序：

先建立系统图感
学 topic/service/action 三种通信模型
学 QoS，并开始和实际数据链路绑定
学 launch/parameter，理解系统组织方式
学 executor/callback group，理解并发执行
再逐步进入 rclcpp、lifecycle、composition