ROS1 vs ROS2 核心差异梳理

ROS1 和 ROS2 本质是“两代完全不同的机器人操作系统”——ROS2 不是 ROS1 的简单升级，而是为了解决 ROS1 的痛点（比如单节点崩溃影响全局、不支持实时性、跨设备通信弱），重新设计的底层架构。
推荐论文《Exploring the Performance of ROS》
ROS1 melodic 使用介绍-https://blog.csdn.net/weixin_41469272/article/details/105289174

• ROS1：依赖单一主节点（ROS Master），ROS1使用Master节点来协调通信，所有的节点都需要连接到Master，Master管理各个节点之间的通信信息。Master是中心化的系统。类似电话交换机，一旦主节点崩溃，整个系统瘫痪。
• ROS2：采用去中心化的DDS(数据分发服务Data Distribution Service)协议作为底层通信机制，DDS是一种面向分布式系统的协议，支持实时、可扩展和多平台的通信。ROS2的通信是去中心化的，不再依赖中央的Master节点，而是节点直接通信。DDS是工业级通信标准，支持自动发现节点，系统更健壮，适合分布式多机器人场景。DDS的核心是一个以数据为中心的发布-订阅（Data-Centric Publish-Subscribe，DCPS）模型，该模型旨在为分布式异构平台上的进程间提供高效的数据传输。DCPS模型创建了一个可供任何独立应用程序访问的"全局数据空间"，通过类型化接口实现高效数据分发。

本文从“原理、使用、命令”三个维度，用通俗的语言和对比表讲清楚差异。

一、原理上的核心不同

原理差异的核心：ROS1 是“中央集权式”，ROS2 是“去中心化联盟式”，ROS1 的 roscore 是“中央控制节点”（有实体、需单独启动），ROS2 的 DCPS 是“分布式通信框架”（无实体、嵌入底层） 。

对比维度	ROS1 roscore	ROS2 DCPS
本质	具体的“中央节点”（有进程、有PID）	抽象的“通信规则框架”（无进程、无实体）
存在形式	需手动启动（roscore 命令），启动后是一个独立运行的程序	嵌入在每个 ROS2 节点中，节点启动时自动加载，无需单独启动
核心作用	1. 节点注册（记录所有节点的信息）；2. 话题/服务匹配（告诉发布者“谁订阅了你”）；3. 中央协调（所有通信都要过它）	1. 定义通信规范（比如节点怎么入网、数据怎么匹配）；2. 让节点“去中心化”通信（直接点对点，不用中央协调）；3. 强制执行 QoS 规则
依赖关系	所有节点必须依赖 roscore 才能通信（roscore 挂了，整个通信瘫痪）	节点之间直接通信（按 DCPS 规则），无中央依赖（单个节点崩溃不影响其他节点）

• ROS1 roscore 是“看得见、摸得着”的中央节点，是通信的“核心枢纽”；
  • ROS1：先启动 roscore，再启动节点；关掉 roscore，节点会报错“无法连接到 master”；
• ROS2 DCPS 是“看不见、摸不着”的通信规则集合，是让节点“去中心化通信”的“底层骨架”；
  • ROS2：直接启动两个节点（比如 talker 和 listener），不用启动任何“中央程序”，它们能正常通信；关掉其中一个，另一个照样运行（不会因为对方崩溃而报错）。

---

用生活例子类比：

• ROS1 roscore = 公司的“前台总机”：
  所有员工（节点）入职前必须到前台登记（节点注册）；员工A要给员工B发文件（话题通信），得先问前台“B坐在哪”（总机匹配）；前台下班了（roscore 关闭），所有人都没法互相找到、传递文件。

• ROS2 DCPS = 公司的“内部邮件系统规则”：
  没有前台总机，而是公司统一规定“邮件怎么写地址、怎么发送、怎么确保送达”（DCPS 规范）；每个员工（节点）都自带“邮件客户端”（按 DCPS 实现的 DDS 模块），想发文件直接按规则写地址（Topic）发送，收件人看到自己的地址就接收（点对点通信）；“规则”本身不是一个人或一个部门（无实体），但所有人都按规则做事，通信照样顺畅。

---

原理差异对比

ROS应用程序由独立的计算进程组成，这些进程称为节点（nodes），它们促进了故障隔离、开发速度的提升、模块化和代码复用。节点之间的通信基于发布/订阅模型。在这种模型中，节点通过主题（topic）传递消息进行通信。消息有一个简单的数据结构（类似于C语言中的结构体），由.msg文件定义。节点通过主题名称来识别消息的内容。当一个节点向一个主题发布消息时，另一个节点订阅该主题并利用消息。例如，如下图所示，“Camera”节点将消息发送到“Images”主题。主题中的消息被“Car Detection”节点和“Pedestrian Detection”节点接收。发布/订阅模型被设计为在细粒度的尺度上模块化，适合分布式系统。

对于实现此功能，ROS1 和ROS2的系统构建框图如下：

上图简要说明了ROS1和ROS2的系统模型。
ROS1：图中左侧，ROS1的实现包括通信系统TCPROS/UDPROS，使用TCP和UDP套接字。在启动订阅节点和发布节点启动前，需要首先启动主节点(rosocore)，发布及订阅节点在启动后会与主节点交互，主节点收集信息并管理主题，类似于服务器。通过与主节点的XML/远程过程调用（RPC）事务后，订阅节点请求与发布节点的连接，使用约定的连接协议。实际数据（即消息）直接在节点之间传输，不通过主节点。ROS1实现了节点之间的点对点数据传输。由于ROS1的实现，这种通信需要一个主进程（在分布式系统中是唯一的）。
ROS1可选地提供了nodelets，这些nodelets提供了优化数据传输的高效节点组合，避免了TCPROS和UDPROS的使用。nodelet通过传递指针在同一进程中的节点之间实现非序列化的数据传输。ROS2继承了这个选项作为进程内通信，解决了nodelets的一些基本问题（例如，安全内存访问问题）。

ROS2：相比之下，如右侧图所示，ROS2基于DDS，并包含一个DDS抽象层，不再需要一个实体节点。由于这个抽象层，用户不需要了解DDS的API。这个层次使得ROS2可以拥有更高层次的配置，并优化DDS的利用。此外，由于使用DDS，ROS2不需要主进程。这对于提高容错性非常重要。

对比维度	ROS1 原理（中央集权）	ROS2 原理（去中心化）
通信架构核心	依赖 roscore（Master 节点）：所有节点必须注册到 roscore，话题/服务匹配全靠它协调（中央枢纽）	基于 DDS 分布式框架：无中央节点，节点通过 DDS 直接点对点通信（按 DCPS 规则匹配）
通信底层实现	自定义 TCP/UDP 协议（简单但不通用）：只支持 ROS1 节点间通信，无法和其他系统（如嵌入式）直接互通	采用工业级 DDS 标准：支持跨设备（PC/嵌入式板）、跨系统（Windows/Linux）、跨编程语言通信
数据传输规则	无统一 QoS：所有数据“一视同仁”（要么都传，要么都丢），无法满足不同数据需求（比如传感器数据要快、参数数据要稳）	内置 QoS 服务等级：给数据定“规则”（如“必达件”“加急件”），适配不同场景（传感器用高速低可靠，参数用低速高可靠）
节点生命周期管理	无标准化生命周期：节点启动就满负荷运行，关闭就是“硬停”（可能导致资源泄漏，比如传感器没关闭）	支持 Lifecycle 生命周期：节点按“未配置→待命→活跃→终止”流程运行，优雅启动/退出，支持外部控制状态
实时性支持	不支持实时性：操作系统调度是“尽力而为”，控制指令（比如电机指令）可能延迟，不适合工业机器人	原生支持实时性：可对接实时操作系统（如 Xenomai、RTLinux），控制指令能精准按时执行（毫秒级响应）
容错性（稳定性）	单点故障影响全局：roscore 崩溃后，所有节点都无法通信；一个节点卡死可能拖垮整个系统	去中心化容错：无中央依赖，单个节点崩溃不影响其他节点；DDS 自带重传、超时机制，通信更稳定
多机器人协同	无原生支持：多机器人通信需要手动配置端口、隔离话题，容易串扰（比如你家机器人数据传到邻居家）	原生支持多机器人：通过 Domain（域） 隔离数据（不同机器人用不同 Domain），无需额外配置

二、核心使用上的不同（实际开发/部署差异）

使用差异是原理差异的“落地体现”——ROS2 更适合复杂场景（多机器人、工业控制、跨设备），ROS1 适合简单场景（单机、教学、快速原型）。

使用差异对比表

对比维度	ROS1 使用特点	ROS2 使用特点
启动流程	必须先启动 roscore（roscore 命令），再启动节点；roscore 挂了要重启所有节点	无需启动任何“中央程序”，直接启动节点（如 ros2 run）；节点可随时启停，互不影响
节点通信配置	无需配置 DDS/QoS：默认所有节点在同一“网络”，话题匹配只看名称+数据类型	需关注两个关键配置：1. Domain（默认 0，多机器人需改不同值）；2. QoS 套餐（按场景选，如传感器用 SENSOR_DATA）
生命周期控制	节点只有“运行/停止”两种状态：无法控制节点“待命”（初始化完成但不工作）	可通过命令行/代码/其他节点控制生命周期：比如让雷达节点先“待命”，导航节点就绪后再“激活”
参数管理	参数是“节点私有”：修改参数需要指定节点名，重启节点后参数丢失（需手动保存）	支持“全局参数”和“私有参数”：参数可持久化（重启节点不丢失），支持参数事件监听（参数变了自动触发回调）
服务/动作通信	服务是“同步请求-响应”（单次通信）；动作通信需依赖 actionlib 第三方库	服务、动作通信是“原生支持”：动作通信自带进度反馈（比如“机器人移动1米”，实时返回移动了0.5米）
开发调试	工具简单：rostopic/rosservice/rviz 足够；但无原生日志分级、性能分析工具	工具更强大：1. 日志分级（DEBUG/INFO/WARN/ERROR），支持过滤日志；2. 自带性能分析工具（ros2 topic hz 看频率、ros2 doctor 查问题）；3. rviz2 支持更多传感器类型
跨平台/跨语言	仅支持 Linux（主要）、部分支持 Windows；编程语言支持 C++/Python（核心）	原生支持 Linux/Windows/macOS/嵌入式系统（如 Raspberry Pi）；新增支持 Java/C#/Rust 等
依赖安装/环境配置	依赖管理简单：通过 apt-get install ros-<版本>-<包名> 安装；环境变量只需 source devel/setup.bash	依赖管理更规范：支持二进制安装（apt）、源码编译（colcon build）；环境变量需 source install/setup.bash（编译后目录是 install，不是 devel）
适用场景	1. 教学/入门（简单易上手）；2. 单机快速原型（比如一个机器人做避障实验）；3. 已有成熟 ROS1 代码的项目	1. 多机器人协同（比如两台机器人配合搬运）；2. 工业控制（需要实时性、稳定性）；3. 跨设备部署（PC+嵌入式板）；4. 复杂系统（多传感器、多算法模块）

三、支持命令上的差异（常用命令对照表）

ROS2 命令在 ROS1 基础上做了“统一化”（比如 ros2 topic/ros2 service 语法一致），但部分核心命令变化较大，下面是“高频命令对比”（按功能分类）。

1. 环境配置/包管理命令

环境变量的不同：

• ROS 2与ROS 1的区别：ROS 1中会设置ROS_PACKAGE_PATH来帮助系统查找软件包，但ROS 2改用Colcon作为构建工具，依赖COLCON_PREFIX_PATH和AMENT_PREFIX_PATH来管理包路径。

• 新的包发现机制：ROS 2通过ament_cmake和colcon的索引文件（如package.xml和COLCON_IGNORE）动态定位包，不再需要显式的ROS_PACKAGE_PATH。

• 环境变量的分工

  • ROS_DISTRO：仅标识当前ROS版本（如humble），用于脚本或工具判断版本。
  • ROS_PACKAGE_PATH：在ROS 2中已弃用，替代方案如下：
    • AMENT_PREFIX_PATH：包含所有ROS 2包的安装路径（通过setup.sh自动添加）。
    • COLCON_PREFIX_PATH：Colcon构建工具使用的包路径（类似ROS 1的CATKIN_PREFIX_PATH）。

使用如下命令打印ROS相关环境变量

printenv | grep ROS_

功能	ROS1 命令	ROS2 命令	备注
初始化工作空间	catkin_init_workspace	mkdir -p src && cd src（无需初始化命令）	ROS2 工作空间更简单，直接创建 src 目录即可
编译工作空间	catkin_make（或 catkin build）	colcon build（推荐）	ROS2 编译后生成 install/ 目录（存放可执行文件）
激活环境	source devel/setup.bash	source install/setup.bash	环境变量生效后才能使用包/节点
安装官方包	sudo apt-get install ros-kinetic-<包名>	sudo apt-get install ros-humble-<包名>	版本名不同（如 ROS1 kinetic、ROS2 humble）
查看已安装的包	rospack list	ros2 pkg list

2. 节点/话题/服务/参数命令

功能	ROS1 命令	ROS2 命令	备注
启动 roscore（中央节点）	roscore	无（直接启动节点）	ROS2 去中心化，无需中央节点
启动节点	rosrun <包名> <节点名>	ros2 run <包名> <节点名>	语法一致，ROS2 无需先启动 roscore
查看活跃节点	rosnode list	ros2 node list
查看话题列表	rostopic list	ros2 topic list
查看话题数据	rostopic echo /<话题名>	ros2 topic echo /<话题名>
查看话题频率	rostopic hz /<话题名>	ros2 topic hz /<话题名>
发布话题数据	rostopic pub /<话题名> <数据类型> <数据>	ros2 topic pub /<话题名> <数据类型> <数据>	语法一致，ROS2 支持 QoS 参数（如 --qos-profile sensor_data）
查看服务列表	rosservice list	ros2 service list
调用服务	rosservice call /<服务名> <请求数据>	ros2 service call /<服务名> <请求数据>
查看参数列表	rosparam list	ros2 param list
设置参数	rosparam set /<参数名> <值>	ros2 param set <节点名> <参数名> <值>	ROS2 参数默认绑定节点，需指定节点名
保存参数	rosparam dump <文件名>.yaml	ros2 param dump <文件名>.yaml	ROS2 可保存全局参数，重启后可加载

3. 生命周期/特殊命令（ROS2 新增）

功能	ROS1 无对应命令	ROS2 命令	备注
查看节点生命周期状态	-	ros2 lifecycle list /<节点名>	查看节点当前状态（如 Unconfigured/Active）
控制节点生命周期	-	ros2 lifecycle set /<节点名> <状态指令>	状态指令：configure（未配置→待命）、activate（待命→活跃）、shutdown（终止）
查看 DDS 域配置	-	ros2 doctor --report	检查当前 Domain、QoS 匹配等通信状态
切换 DDS 实现	-	export RMW_IMPLEMENTATION=<DDS名>	如 export RMW_IMPLEMENTATION=rmw_fastrtps_cpp（默认 FastDDS）
动作通信相关	需用 actionlib 工具	ros2 action list/ros2 action send_goal	原生支持动作指令，无需额外库

四、总结

1. 核心记忆点

• ROS1：中央集权（roscore）、简单易用、功能单一、适合入门/单机；
• ROS2：去中心化（DDS）、稳定灵活、支持复杂场景、适合实际项目/工业应用。

2. 关键避坑点

• ROS1 避坑：启动节点前必须先开 roscore；多机器人通信容易串扰，需手动隔离；
• ROS2 避坑：多机器人必须改 Domain（如机器人1用 Domain 0，机器人2用 Domain 1）；QoS 不匹配会导致“发布者发数据，订阅者收不到”（按场景选套餐即可，比如传感器用 SENSOR_DATA）。