ROS / ROS2 到底是什么？写给第一次接触机器人开发的人
最近在接触机器人项目时，经常会看到 ROS、ROS1、ROS2 这些词。
如果以前没做过机器人开发，很容易先产生一个疑问：ROS、ROS1、ROS2 到底是什么关系？
刚开始我也很容易把它理解成一个“机器人操作系统”，甚至会下意识地认为：
ROS2 是不是像 Windows、Ubuntu 一样的系统？
是不是需要单独部署一台 ROS2 服务器？
雷达、摄像头、导航程序是不是通过 IP 地址访问 ROS2？
实际上都不是。
如果之前主要接触的是 Web、Java、Go、Docker、Kubernetes 这些技术，那么理解 ROS2 最困难的地方，不是代码，而是它的工作方式和传统 Web 系统不太一样。
这篇文章不深入 ROS2 底层，只用比较通俗的方式介绍：
- ROS、ROS1、ROS2 分别是什么
- ROS1 和 ROS2 是什么关系
- 为什么机器人需要 ROS2
- ROS2 是软件还是环境
- ROS2 有没有 IP 地址
- 雷达、导航、机器人控制程序是怎么通过 ROS2 配合工作的
- ROS2 和 Windows、Linux、Kubernetes 有什么区别
一、先说结论：ROS、ROS1、ROS2 分别是什么？
先把三个名字分清楚。
ROS 的全称是：
Robot Operating System
中文一般翻译为：
机器人操作系统
不过这个名字很容易让人误解。虽然名字里有 Operating System（操作系统），但 ROS 并不是 Windows、Ubuntu 这种真正意义上的操作系统。
更准确地说：
ROS 是一整套专门用于机器人开发的软件框架、通信机制、开发工具和生态。
可以先粗略理解为：
ROS 是机器人软件的基础平台。
后来，ROS 发展出了两代主要体系：
ROS
├── ROS1：第一代
└── ROS2：第二代
其中：
ROS1 = 第一代 ROS
ROS2 = 第二代 ROS
ROS2 的全拼就是：
Robot Operating System 2
中文一般翻译为：
机器人操作系统 2
所以，平时如果别人只说“ROS”，有时候是在泛指整个 ROS 生态；如果进入实际开发，就要进一步确认说的是 ROS1 还是 ROS2。
机器人里面可能同时存在很多程序：
雷达程序
摄像头程序
定位程序
建图程序
导航程序
机械臂控制程序
底盘控制程序
这些程序需要不断交换数据、互相配合。
ROS 最核心的价值，就是让这些程序能够按照统一的方式进行通信和协作。
三、ROS1 和 ROS2 是什么关系？
可以把它们理解成：
ROS1 是第一代，ROS2 是面向新一代机器人场景重新设计的第二代。
但 ROS2 并不是简单地在 ROS1 后面“升级一个版本号”。
它在很多基础设计上都做了重新设计，例如更重视：
- 多机器人协作
- 分布式通信
- 实时性
- 安全性
- 跨平台能力
- 工业和产品化场景
如果用熟悉的软件技术来类比，可以把它理解成：
ROS1
≈ 老一代机器人软件架构
ROS2
≈ 为现代机器人重新设计的新一代架构
因此，今天新做机器人项目时，通常会优先关注 ROS2。
这篇文章后面也会以 ROS2 为主，因为对于第一次接触机器人开发的人来说，先理解 ROS2 的工作方式更有实际意义。
三、为什么机器人需要 ROS2？
假设现在要开发一个非常简单的移动机器人。
机器人身上有：
激光雷达
摄像头
电机
控制器
同时还有几个软件：
雷达程序
建图程序
导航程序
电机控制程序
机器人运行的时候，大概会发生这样的事情：
雷达扫描周围环境
↓
告诉建图程序：
“前面有一堵墙”
↓
建图程序生成地图
↓
导航程序读取地图
↓
导航程序计算：
“应该往左走”
↓
控制程序收到命令
↓
真正控制机器人左转
问题来了。
这些程序是不同人开发的，甚至可能来自不同公司。
那么：
雷达程序怎么把数据交给建图程序？
建图程序怎么把地图交给导航程序？
导航程序又怎么把运动命令交给机器人？
如果没有统一的体系，每两个程序之间都可能需要单独设计通信方式。
最后很容易变成：
雷达 → 自己写 TCP
地图 → 自己写接口
导航 → 再设计一套协议
机器人控制 → 又写一套通信
系统会越来越复杂。
ROS2 就是为了解决这个问题。
四、可以把 ROS2 理解成“机器人内部的公共通信平台”
一个比较容易理解的类比是：
ROS2 有点像机器人内部的“企业微信 + 公共通信规则”。
假设机器人里面有几个“部门”：
雷达部门
地图部门
导航部门
控制部门
雷达部门不停发布：
我刚刚扫描到了这些障碍物。
地图部门需要这些数据，于是直接接收。
地图生成以后又发布：
最新地图已经生成。
导航部门接收到地图以后，开始计算路线。
导航程序最后又发布：
机器人向前走，速度 0.5m/s。
控制程序接收到以后，再真正驱动机器人。
整个过程可以理解成：
雷达程序
↓
发布雷达数据
↓
ROS2
↓
建图程序
↓
发布地图
↓
ROS2
↓
导航程序
↓
发布运动命令
↓
ROS2
↓
机器人控制程序
ROS2 本身不会替你“识别障碍物”或者“规划路线”。
它更重要的作用是：
让这些不同的软件能够方便地连接起来。
五、ROS2 到底是“软件”还是“环境”？
这个问题其实两个说法都可以。
ROS2 本身是一整套软件。
安装以后，它又会在电脑上形成一个机器人开发和运行环境。
可以类比 JDK。
例如：
Ubuntu
↓
安装 JDK
↓
运行 Java 程序
ROS2 类似：
Ubuntu
↓
安装 ROS2
↓
运行各种机器人程序
因此一台机器人上的计算机可能是：
Ubuntu
│
├── ROS2
│
├── 雷达程序
├── 建图程序
├── 导航程序
└── 机器人控制程序
所以可以简单理解：
ROS2 是安装在操作系统上的机器人软件基础环境。
六、ROS2 是不是需要单独部署一台服务器？
通常不是。
这也是刚接触 ROS2 时特别容易误解的地方。
传统 Web 系统经常是：
服务器
↓
启动一个服务
↓
监听 8080 端口
↓
其他系统通过
http://192.168.1.10:8080
访问
ROS2 通常不是这种思路。
例如一台机器人身上可能有一块 NVIDIA Jetson 小电脑。
可以直接在 Jetson 上安装：
Ubuntu
+
ROS2
+
雷达驱动
+
建图程序
+
导航程序
+
机器人控制程序
这些程序都运行在同一台电脑里。
ROS2 不需要再单独找一台机器作为“ROS2服务器”。
七、ROS2 有地址吗？
通常没有所谓：
http://ros2:8080
这样的地址。
因为 ROS2 本身不是一个 Web 服务。
机器人程序也不是通过 HTTP 请求：
GET /ros2/lidar
去获取雷达数据。
ROS2 使用的是另外一套通信机制。
可以简单理解成：
所有 ROS2 程序进入同一个通信体系以后，可以互相发现和交换数据。
例如：
雷达程序：
“我要发布雷达数据”
导航程序：
“我要接收雷达数据”
只要它们运行在合适的 ROS2 环境和网络中，就可以建立通信。
所以 ROS2 和传统的：
客户端 → IP + 端口 → 服务端
这种思维方式不完全一样。
八、ROS2 里面经常说的 Node 是什么？
Node 中文一般叫“节点”。
听起来很复杂，其实可以直接理解成：
一个正在运行的机器人小程序。
例如：
雷达驱动
= 一个 Node
摄像头程序
= 一个 Node
导航程序
= 一个 Node
机器人控制程序
= 一个 Node
所以一台机器人运行起来以后，可能同时运行很多 Node。
例如：
ROS2
│
├── 雷达节点
├── 摄像头节点
├── 地图节点
├── 定位节点
├── 导航节点
└── 机器人控制节点
大家各自负责自己的事情。
九、Topic 又是什么？
Topic 是 ROS2 非常核心的概念。
可以简单理解成：
消息频道。
比如定义一个频道：
/scan
专门发布激光雷达数据。
雷达程序不断往 /scan 里面发布数据。
建图程序和导航程序如果需要雷达数据，就订阅 /scan。
可以想象成微信群：
微信群：雷达数据群
雷达：
不停往群里发数据
SLAM：
关注这个群
导航：
也关注这个群
雷达不需要知道：
到底是谁在使用我的数据。
它只负责发布。
需要的人自己订阅。
这就是 ROS2 很重要的一种工作方式。
十、为什么这种方式特别适合机器人？
因为机器人里面很多数据都是实时不断产生的。
例如激光雷达可能一直在产生：
第1帧数据
第2帧数据
第3帧数据
第4帧数据
……
摄像头也是不断产生图像。
机器人当前位置也在不断变化。
这些数据不像普通 Web 接口：
请求一次，返回一次。
更像：
数据源一直在不停地产生数据。
因此“发布 / 订阅”的方式非常适合机器人。
十一、雷达驱动是怎么使用 ROS2 的？
假设购买了一个激光雷达。
雷达厂家通常会提供一个程序：
ROS2 Driver
也就是 ROS2 驱动。
这个程序负责：
真实雷达
↓
读取雷达数据
↓
转换成ROS2通用的数据格式
↓
发布到ROS2
于是后面的 SLAM 建图程序就不用研究：
这个雷达内部到底是什么通信协议。
SLAM 只需要获取 ROS2 中的雷达数据。
整个链路大概是：
激光雷达
↓
雷达ROS2驱动
↓
ROS2
↓
SLAM
十二、SLAM 又是什么？
SLAM 可以先简单理解成：
机器人一边走，一边建立地图，同时判断自己在地图中的位置。
例如机器人第一次进入一个办公室：
开始不知道周围环境
↓
雷达不断扫描
↓
发现墙
↓
发现走廊
↓
发现房间
↓
慢慢建立地图
最终可能得到一张类似这样的地图：
┌────────办公室────────┐
│ │
│ │
└────────┐ │
│ 走廊 │
│ │
├────会议室───┤
│ │
└────仓库─────┘
ROS2 本身并不是 SLAM。
SLAM 是运行在 ROS2 体系中的另外一个程序。
十三、Nav2 又是什么？
地图建立以后，接下来就要让机器人自己走。
例如告诉机器人：
从办公室去仓库。
Nav2 会根据地图计算：
当前位置
↓
走廊
↓
左转
↓
继续前进
↓
仓库
然后不断产生机器人运动命令。
所以可以简单记：
SLAM
=
建地图
Nav2
=
在地图上导航
它们都可以运行在 ROS2 体系中。
十四、ROS2 和 Windows、Ubuntu、K8s 有什么区别？
可以这样对比：
| 技术 | 主要解决的问题 |
|---|---|
| Windows / Ubuntu | 让计算机能够运行各种软件 |
| Docker | 把应用和运行环境打包起来 |
| Kubernetes | 管理很多服务器和容器应用 |
| ROS2 | 让机器人中的硬件和软件模块协同工作 |
例如：
Kubernetes 更关心：
服务部署在哪里？
运行几个副本？
容器挂了怎么办？
ROS2 更关心：
雷达数据怎么交给导航？
地图怎么交给定位？
导航命令怎么交给机器人？
两者解决的是完全不同的问题。
十五、可以把 ROS2 理解成“机器人软件的数据高速公路”
如果一定要找一个最容易理解的比喻，我觉得：
ROS2 就像机器人内部的数据高速公路。
机器人里的各种程序分别是不同的车辆和站点：
雷达
摄像头
SLAM
导航
机器人控制
ROS2 提供了一套统一的道路和交通规则。
于是：
雷达 ───────┐
│
摄像头 ─────┤
↓
ROS2
↓
┌─────┼─────┐
↓ ↓ ↓
建图 导航 控制
不同程序不用每次都重新设计一套通信方式。
十六、为什么机器人行业大量使用 ROS2？
ROS2 真正有价值的地方不只是通信。
更重要的是背后已经形成了一个很大的机器人软件生态。
很多公司、学校和开源开发者都会提供 ROS2 版本的软件，例如：
激光雷达驱动
摄像头驱动
机械臂驱动
SLAM
导航
定位
路径规划
机器人模型
可视化调试工具
因此开发一个机器人时，很多东西不需要完全从零开始。
例如：
买一个支持ROS2的雷达
↓
使用厂家的ROS2驱动
↓
获得标准雷达数据
↓
接入现成SLAM
↓
生成地图
↓
接入Nav2
↓
实现自主导航
这也是 ROS2 最重要的价值之一：
把不同厂商、不同算法、不同机器人软件连接到同一个生态里。
十七、那 ROS2 是全球标准吗？
严格来说不是。
ROS2 并不是类似 ISO、国家标准这样的强制标准。
更准确地说：
ROS2 是全球机器人领域非常主流的一套开源软件框架和生态。
可以类比 Kubernetes。
Kubernetes 也不是“全球法律规定必须使用的标准”，但是云原生领域已经有大量公司和产品围绕它构建生态。
ROS2 在机器人领域有一点类似。
因此会看到很多机器人厂商介绍：
支持ROS
支持ROS2
提供ROS2 SDK
提供ROS2 Driver
本质上是在告诉开发者：
我的硬件可以比较方便地接入 ROS2 机器人生态。
十八、最终应该怎么理解 ROS2？
如果只记一句话：
ROS2 是一套安装在计算机上的机器人软件框架和通信平台，用来让雷达、摄像头、建图、导航、机器人控制等不同程序按照统一方式互相通信和协作。
如果用技术人员比较熟悉的方式概括：
Ubuntu
解决：
计算机怎么运行软件
Kubernetes
解决：
服务怎么部署和管理
ROS2
解决：
机器人中的各种硬件和软件怎么互相配合
所以第一次接触 ROS2 时，并不需要马上学习它底层用了什么通信协议，也不用马上研究复杂的机器人算法。
先建立这个认识就足够了：
ROS2 本身不是机器人，它更像机器人软件世界里的“公共基础设施”。
后面的雷达、SLAM、导航、机械臂、机器狗等不同能力，都是在这个基础设施上逐渐连接起来的。
理解了这一点，再去看机器人项目里的 Node、Topic、SLAM、Nav2、DDS 等概念，就会容易很多。
最后再记一句：ROS 是整个机器人软件生态的名字，ROS1 是第一代，ROS2 是第二代；对于现在的新项目，重点理解 ROS2 即可。
浙公网安备 33010602011771号