从 ROS1 到 ROS2：机器人操作系统的演进、解析与实践指南!

1. 演进的必然：从科研原型到工业级交付

机器人操作系统（Robot Operating System, ROS）自2007年诞生以来，已成为全球机器人研发事实上的标准。其初衷是为斯坦福大学的人工智能实验室提供一个能够快速整合各类硬件驱动、算法库和调试工具的通用框架 1。然而，随着机器人技术从实验室走向自动驾驶汽车、仓储物流集群、手术机器人等工业与商业场景，ROS1 架构设计的局限性逐渐暴露。ROS1 是为单一机器人、非实时环境、且网络连接稳定的科研场景设计的，这导致其在面对多机协同、实时控制、高可靠性及网络安全要求时显得力不从心 2。

ROS2 的诞生并非简单的版本迭代，而是一次彻底的架构重构。其核心目标是解决 ROS1 的根本性缺陷，将 ROS 从一个“科研原型工具”转变为“工业级交付平台”。这一演进过程不仅涉及中间件的替换，更涵盖了从编程范式、构建系统到生态工具链的全方位革新。

1.1 ROS1 的架构局限性分析

要理解 ROS2 的设计哲学，首先必须剖析 ROS1 的痛点。ROS1 的通信架构基于自定义的 TCPROS/UDPROS 协议，并极度依赖于一个中心化的管理节点——Master Node (roscore) 2。

单点故障（Single Point of Failure, SPOF）风险：

在 ROS1 中，所有的节点（Node）在启动时都必须向 Master 注册，节点之间的查找与连接建立全靠 Master 作为“DNS 服务器”来完成。一旦 Master 进程崩溃或网络出现分区导致 Master 不可达，整个系统的节点虽然在已建立连接的情况下可能暂时保持通信，但无法再建立新的连接，服务发现机制彻底瘫痪 2。对于自动驾驶汽车或在危险环境中作业的机器人而言，这种脆弱性是不可接受的。

通信协议的非实时性与不可靠性：

ROS1 的 TCPROS 虽然基于 TCP 提供了一定的可靠性，但它缺乏对通信质量（Quality of Service, QoS）的细粒度控制。在网络拥塞或丢包环境下，系统往往表现出不可预测的延迟 4。此外，ROS1 缺乏真正的实时性支持，无法保证控制指令在确定的时间窗口内送达，这限制了其在底盘控制、机械臂伺服等硬实时场景下的应用 3。

安全性缺失：

ROS1 设计之初并未考虑网络安全，假设所有节点都运行在受信任的内部网络中。通信数据完全以明文传输，且没有任何身份验证机制。任何接入网络的设备都可以向话题发布伪造数据，或者调用服务使得机器人执行危险动作 2。

1.2 ROS2 的设计目标与核心变革

ROS2 旨在保留 ROS1 强大的生态优势（如 Rviz, Gazebo, 丰富的算法包），同时引入工业界验证过的技术标准来解决上述问题 3。

去中心化与 DDS 的引入：

ROS2 最具革命性的变化是摒弃了 Master 节点，转而在底层采用了 数据分发服务（Data Distribution Service, DDS） 标准。DDS 是一种广泛应用于国防、航空航天及金融交易领域的工业级中间件协议 2。通过 DDS，ROS2 实现了真正的点对点（Peer-to-Peer）分布式通信。节点通过动态发现机制（Discovery）自动感知网络中的其他参与者，无需中心服务器介入。这不仅消除了单点故障，还天然支持了多机器人系统的自组网与协同 1。

实时性与确定性：

借助 DDS 的实时发布订阅协议（RTPS），ROS2 能够提供可配置的 QoS 策略，允许开发者在“可靠性”与“实时性”之间做权衡。配合实时操作系统（RTOS）的支持，ROS2 能够满足毫秒级的硬实时控制需求 1。

全平台支持与多语言生态：

ROS1 长期以来是 Linux（尤其是 Ubuntu）的专属，对 Windows 和 macOS 的支持仅限于实验性质。ROS2 在设计之初就将跨平台作为核心指标，官方原生支持 Ubuntu、Windows 10/11、macOS 以及多种 RTOS（如 FreeRTOS, Zephyr）1。这极大地扩展了 ROS 的应用边界，使其能运行在从嵌入式微控制器到云端服务器的异构计算环境中。

特性维度	ROS1 (Noetic)	ROS2 (Humble/Rolling)	工业价值解读
通信架构	中心化 (Master Node)	分布式 (DDS)	消除单点故障，提升系统鲁棒性，支持大规模集群。
中间件协议	TCPROS / UDPROS (自定义)	RTPS (工业标准)	利用成熟工业标准实现高可靠、低延迟通信。
节点发现	依赖 Master XML-RPC	基于组播/单播的自动发现	简化多机配置，支持即插即用。
实时性	无原生支持 (Best-effort)	支持硬实时 (配合 RTOS)	可用于安全关键的运动控制与传感器处理。
操作系统	Linux 为主	Linux, Windows, macOS, RTOS	适应多样化的开发与部署环境，覆盖端-边-云。
构建系统	Catkin (CMake 封装)	Colcon (通用构建工具)	隔离构建环境，支持混合语言项目，提升 CI/CD 效率。
安全性	无 (明文传输)	SROS2 (DDS-Security)	提供加密、认证与访问控制，满足商业安全合规。

这一演进并非一蹴而就。ROS1 Noetic 将在 2025 年 5 月达到生命周期终点（EOL），这标志着一个时代的结束与新时代的全面开启 1。对于所有机器人从业者而言，掌握 ROS2 不再是可选项，而是必须面对的技术转型。

---

2. 核心架构解析：DDS 中间件与通信机制

ROS2 的核心竞争力在于其基于 DDS 的中间件架构。理解 DDS 的工作原理、服务质量策略（QoS）以及中间件接口（RMW）的抽象机制，是深入掌握 ROS2 的关键。

2.1 DDS 标准与 ROS 中间件接口 (RMW)

在 ROS1 中，通信层是直接硬编码在核心库中的。而在 ROS2 中，为了适应不同的应用场景（例如：低延迟的局域网 vs. 高丢包率的无线网），架构采用了分层设计。最底层是具体的 DDS 实现（如 eProsima Fast DDS, Eclipse Cyclone DDS, RTI Connext），之上是 ROS Middleware Interface (RMW) 抽象层 2。

RMW 的抽象价值：

RMW 定义了一套标准的 C 接口，向上对接 ROS 客户端库（RCL），向下适配不同的 DDS 厂商实现。这意味着开发者无需修改一行应用层代码，仅通过设置环境变量即可在不同的 DDS 实现之间切换 6。例如，在开发阶段可能使用开源的 Fast DDS，而在最终部署到对安全性有极高要求的军工项目时，可以无缝切换到通过安全认证的 RTI Connext DDS。

DDS 的核心组件：

1. Domain (域)： 类似于 ROS1 中的 Master URI 隔离，DDS 通过 Domain ID 来隔离网络流量。只有处于同一 Domain ID 的节点才能相互发现并通信 8。

2. Participant (参与者)： 对应于 ROS2 中的 Node（实际上 Node 是 Participant 的封装）。它是接入 DDS 全局数据空间的实体。

3. Topic & Type (话题与类型)： DDS 是以数据为中心的（Data-Centric），严格要求数据类型的定义（IDL）。ROS2 的 .msg 文件在编译时会被转换为 DDS 能够识别的 IDL 文件，进而生成各语言的序列化代码 3。

2.2 服务质量策略 (QoS) 的深度剖析

ROS1 的通信在底层大多是基于 TCP 的可靠传输，用户很难干预。ROS2 暴露了 DDS 丰富的 QoS 配置能力，允许开发者为每一个发布者（Publisher）和订阅者（Subscriber）定制通信行为。这对于解决复杂的机器人网络问题至关重要 9。

QoS 策略通过 Request vs. Offerer 模型进行匹配：只有当发布者提供的 QoS 级别（Offered QoS）满足或优于订阅者请求的级别（Requested QoS）时，连接才能建立。

2.2.1 Reliability (可靠性)

• Reliable (可靠传输)： 保证消息必达。DDS 层会通过确认机制（ACK/NACK）和重传机制来确保数据完整性。这类似于 TCP，但更加灵活。适用于关键控制指令（如 /cmd_vel）或任务调度服务。

• Best Effort (尽力而为)： 不保证消息送达，不进行重传。如果网络拥塞或丢包，数据直接丢失。这类似于 UDP。适用于高频传感器数据（如 20Hz 的激光雷达数据），因为对于实时避障而言，接收最新的数据帧远比重传一秒前的旧数据重要 2。

兼容性警告： 如果订阅者请求 Reliable，但发布者只提供 Best Effort，连接将无法建立。反之则兼容 9。

2.2.2 Durability (持久性)

• Volatile (易失性)： 默认模式。消息发出后，如果没有订阅者在线，消息即逝。后加入的订阅者无法接收之前的消息。

• Transient Local (本地持久化)： 发布者会保存最近发布的 N 条消息（由 Depth 决定）。当新的订阅者加入时，发布者会将这些历史消息发送给它。这完美复现了 ROS1 中的 Latched Topic 机制。这对于静态地图（/map）或机器人描述（/robot_description）至关重要，确保延迟启动的导航节点依然能获取地图数据 9。

2.2.3 History & Depth (历史与深度)

• Keep Last (N)： 仅保留最新的 N 条消息。这是最常用的配置，用于防止缓存无限增长导致内存溢出。

• Keep All： 保留所有消息，直到达到资源限制。仅用于调试或需完整数据记录的场景 9。

2.3 零拷贝 (Zero Copy) 与共享内存传输

在 ROS1 中，即便是同一台机器上的节点通信，数据也需要经过序列化、经由 localhost 网络栈传输、再反序列化。对于 1080p 或 4K 的高频图像流，这种内存拷贝（Memcpy）带来了巨大的 CPU 开销和延迟 12。

ROS2 引入了基于共享内存的**零拷贝（Zero Copy）**机制。当发布者和订阅者位于同一台物理机时，DDS 可以直接传递内存指针，而非拷贝数据本身。

实现机制：

ROS2 提供了 Loaned Message API。发布者不再是自己 new 一个消息对象，而是向中间件“借用”（Loan）一块内存。

C++

// C++ 零拷贝发布示例
auto pub = node->create_publisher<Image>("camera/image", 10);
// 向中间件借用内存，该内存直接位于共享内存段中
void* loaned_msg = pub->borrow_loaned_message();
// 填充数据...
// 发布（归还）消息，订阅者将直接读取该内存地址
pub->publish(std::move(loaned_msg));

这一机制能将大数据传输的延迟降低 50% 至 80%，极大提升了自动驾驶等数据密集型应用的性能 13。要启用此功能，通常需要配置 DDS 的 XML 文件（如 Fast DDS 的 shm 传输模式）或使用支持 Iceoryx 的 Cyclone DDS 13。

2.4 多中间件切换与互操作实战

ROS2 允许通过环境变量动态切换 RMW 实现，这为性能调优提供了极大便利。

常用 RMW 实现对比：

1. rmw_fastrtps_cpp (eProsima Fast DDS)： 默认实现。功能全面，配置项极其丰富（通过 XML），支持同步/异步发布模式。在大规模网络下表现优异，但配置相对复杂 7。

2. rmw_cyclonedds_cpp (Eclipse Cyclone DDS)： 以其“开箱即用”的高性能和低延迟著称，特别是在 WiFi 网络环境下表现往往优于默认配置的 Fast DDS。它的包体积较小，且配置简单（通常只需调整 CYCLONEDDS_URI 环境变量）6。

切换命令：

Bash

# 安装 Cyclone DDS RMW
sudo apt install ros-humble-rmw-cyclonedds-cpp

# 临时切换当前终端的 RMW
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

# 验证当前使用的 RMW
ros2 doctor --report | grep middleware

注意： 尽管 RMW 旨在屏蔽差异，但不同厂商在极端情况下的序列化行为（如 WString 处理）可能存在不兼容。在生产环境中，建议所有节点统一使用同一款 RMW 实现 7。

---

3. 现代编程范式：客户端库与执行模型

ROS2 的编程接口（API）经历了彻底的现代化改造，特别是 C++ 客户端库 rclcpp，大量使用了 C++11/14/17 的特性（如智能指针、Lambda 表达式）。此外，执行模型从隐式的轮询变为显式的执行器（Executor）模式。

3.1 从 roscpp 到 rclcpp 的范式转变

在 ROS1 中，开发者习惯于面向过程的编程风格，通过全局的 ros::NodeHandle 来管理资源。ROS2 强制推行面向对象的设计，rclcpp::Node 成为核心基类。

节点初始化对比：

• ROS1:

  C++

  ros::init(argc, argv, "node_name");
  ros::NodeHandle nh; // 获取节点句柄
  ros::Publisher pub = nh.advertise<std_msgs::String>("topic", 10);
  

• ROS2:

  C++

  rclcpp::init(argc, argv);
  // 推荐创建继承自 rclcpp::Node 的类
  auto node = std::make_shared<rclcpp::Node>("node_name");
  // 发布者创建，使用智能指针管理
  auto pub = node->create_publisher<std_msgs::msg::String>("topic", 10);
  

命名空间与消息头文件：

ROS2 的消息头文件路径发生了变化，增加了 .hpp 后缀，且在包含路径中显式包含 msg 目录，以避免命名冲突。

• ROS1: #include <std_msgs/String.h>

• ROS2: #include <std_msgs/msg/string.hpp>

  此外，ROS2 的日志宏 RCLCPP_INFO 需要传入一个 Logger 对象，而不是像 ROS1 那样直接调用。这使得日志可以自动附带节点的命名空间信息，便于多节点调试 16。

3.2 执行器 (Executor) 与回调管理

ROS1 的 ros::spin() 是一个黑盒，单线程轮询所有回调队列。ROS2 引入了 Executor 概念，将节点的“执行逻辑”与“业务逻辑”解耦 18。

执行器类型：

1. SingleThreadedExecutor (单线程执行器)： 默认模式。所有回调函数在一个线程中串行执行。如果某个回调函数阻塞（如执行耗时计算或 sleep），整个节点都会卡死，无法处理其他消息。

2. MultiThreadedExecutor (多线程执行器)： 维护一个线程池，可以并发执行多个回调。这对于利用多核 CPU 处理并发数据流（如同时处理激光雷达和图像数据）非常有效。

回调组 (Callback Groups)：

为了防止多线程环境下的竞态条件或死锁，ROS2 引入了回调组来控制并发粒度 18。

• Mutually Exclusive (互斥组)： 组内的回调函数在同一时刻只能有一个在运行。适用于需要访问同一临界区资源的场景。

• Reentrant (可重入组)： 组内的回调函数可以并行执行，甚至同一个回调函数（如服务回调）可以被多个线程同时调用。

这种机制赋予了开发者对调度策略的完全控制权，是实现确定性执行的基础。

3.3 生命周期节点 (Lifecycle Node)

ROS1 节点一旦启动即进入活跃状态，开发者很难控制其初始化顺序。这导致了著名的“启动竞争”问题：驱动尚未就绪，算法节点已开始请求数据。

ROS2 引入了 Managed Node (生命周期节点)，基于有限状态机（FSM）管理节点状态 20。

标准状态机：

1. Unconfigured (未配置)： 节点已实例化，但未加载参数或分配资源。

2. Inactive (非活跃)： 节点已配置（Configured），资源已分配（如连接传感器），但尚未开始执行业务逻辑（不发布数据）。

3. Active (活跃)： 节点正常运行，处理数据与服务。

4. Finalized (终止)： 节点析构前的清理状态。

状态转换接口：

开发者需重写 on_configure(), on_activate(), on_deactivate(), on_cleanup() 等虚函数。外部管理程序（如 Nav2 的 lifecycle_manager）可以通过服务调用来触发这些转换，从而确保系统按照严格定义的顺序启动：先加载参数，再连接硬件，最后开启数据流 22。

3.4 动作 (Action) 的一等公民化

在 ROS1 中，Action 是基于 Topic 实现的上层封装库 (actionlib)。在 ROS2 中，Action 成为核心通信机制之一，拥有独立的定义和 API 24。

通信模型升级：

ROS2 Action 涉及三个服务（Service）和两个话题（Topic）：

• Goal Service: 发送目标，服务器决定接受或拒绝。

• Cancel Service: 客户端请求取消任务。

• Result Service: 获取最终执行结果。

• Feedback Topic: 服务器周期性反馈进度。

• Status Topic: 广播当前所有目标的状态。

异步编程模型：

ROS2 的 Action Client 采用了全异步设计。发送目标后，返回的是一个 Future 对象。开发者需要注册回调函数来处理目标被接受、反馈更新和最终结果。这避免了长时间阻塞主线程，保证了节点的高响应性 25。

---

4. 构建系统与依赖管理：Colcon 与 Ament

ROS2 的构建工具从 catkin_make 进化为 colcon，构建系统核心从 catkin 变为 ament。这一变化旨在解决构建隔离性问题，并支持 Python 脚本的原生安装 27。

4.1 Colcon：隔离构建与通用性

隔离构建 (Isolated Build)：

ROS1 的 catkin_make 会将所有包放在同一个 CMake 上下文中构建，这意味着一个包定义的变量可能污染另一个包。colcon 默认为每个包运行独立的 CMake 进程。这虽然增加了构建时间，但极大提高了构建的稳定性和模块间的解耦 29。

无 Devel 空间：

ROS1 有一个 devel 空间，允许在不安装的情况下运行代码。ROS2 采用了“构建即安装”的策略，只有 build 和 install 目录。

为了弥补开发便利性的缺失，colcon 提供了 --symlink-install 参数 31。

Bash

colcon build --symlink-install

该命令会在 install 目录中创建指向源码（如 Python 脚本、Launch 文件、配置文件）的软链接。这样，修改脚本后无需重新编译即可生效，复刻了 devel 空间的用户体验。

4.2 依赖声明与 package.xml 升级

package.xml 升级到了格式 2 或 3，标签更加语义化 17：

• <depend>：通用依赖，涵盖构建、导出和运行。

• <buildtool_depend>：构建工具依赖（如 ament_cmake）。

• <exec_depend>：运行时依赖（替代了 ROS1 的 <run_depend>）。

• <test_depend>：单元测试依赖。

正确声明依赖对于 colcon 确定构建顺序（拓扑排序）至关重要。

4.3 Ament CMake 实战

CMakeLists.txt 的编写方式发生了重大变化。ROS1 的 catkin_package() 被 ament_package() 取代。更重要的是，依赖查找与链接变得更加现代化 27。

ROS1 写法：

CMake

find_package(catkin REQUIRED COMPONENTS roscpp std_msgs)
include_directories(${catkin_INCLUDE_DIRS})
target_link_libraries(my_node ${catkin_LIBRARIES})

ROS2 写法：

CMake

find_package(ament_cmake REQUIRED)
find_package(rclcpp REQUIRED)
find_package(std_msgs REQUIRED)

add_executable(my_node src/main.cpp)
# 自动处理头文件路径和库链接，无需手动指定 include_directories
ament_target_dependencies(my_node rclcpp std_msgs)

install(TARGETS my_node DESTINATION lib/${PROJECT_NAME})
ament_package()

混合工作空间管理：

在迁移过渡期，通常需要同时操作 ROS1 和 ROS2。切勿在同一个终端同时 source 两个环境，除非正在使用 ros1_bridge。正确的做法是使用 overlay（覆盖层）和 underlay（底层）的概念，并在 .bashrc 中设置别名来分别加载环境，避免环境变量（如 PYTHONPATH）冲突 34。

---

5. 工具链与配置系统：Launch、参数与安全

ROS2 的工具链向着“可编程”和“安全性”两个方向大幅迈进。Launch 系统从声明式 XML 转向了命令式 Python，参数系统从全局服务转向了节点本地化，安全系统则实现了从无到有的跨越。

5.1 Python Launch 系统：配置即代码

ROS1 的 XML Launch 文件虽然简单，但在处理复杂逻辑（如条件启动、参数动态生成）时捉襟见肘。ROS2 推荐使用 Python 脚本作为 Launch 文件（.launch.py），这使得 Launch 文件本身成为了一段可执行的程序 36。

核心结构：

Launch 文件通过 generate_launch_description() 函数返回一个描述符。

Python

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription(,
            remappings=[
                ('/old_topic', '/new_topic')
            ]
        )
    ])

这种方式允许开发者利用 Python 的强大功能，例如读取环境变量、遍历目录、进行数学运算后再设置参数，甚至根据当前系统状态决定是否启动某个节点。虽然 ROS2 后来也加回了对 XML 和 YAML Launch 的支持，但 Python 依然是功能最全的首选 37。

5.2 去中心化的参数管理

ROS1 拥有一个全局的 Parameter Server，节点启动时向其查询参数。ROS2 取消了全局参数服务器，参数变成了节点私有的属性 5。

YAML 配置文件的变革：

由于参数属于节点，YAML 文件的层级结构必须明确指定节点名称：

YAML

/my_node_name:
  ros__parameters:
    kp: 1.5
    ki: 0.0
    enable_logging: true

注意 ros__parameters 这个关键字是必须的。在启动时，如果不显式声明参数（declare_parameter），直接读取参数可能会失败（取决于节点配置），这强制开发者在代码中明确列出节点所需的配置项，提高了代码的可维护性 39。

5.3 SROS2：构建安全的机器人网络

ROS2 的 DDS-Security 规范通过 SROS2 工具包落地，提供了三大安全支柱：认证、访问控制和加密 41。

安全部署流程：

1. 创建密钥库 (Keystore)： 相当于证书颁发机构 (CA)。

   Bash

   ros2 security create_keystore ~/sros2_keystore
   

2. 创建飞地 (Enclave)： 为每个节点或进程生成私钥和证书。

   Bash

   ros2 security create_enclave ~/sros2_keystore /my_namespace/my_node
   

3. 定义策略 (Governance & Permissions)： 编写 XML 文件，规定哪些节点可以发布/订阅哪些话题。SROS2 会对这些策略文件进行签名。

4. 分发与运行： 将生成的密钥文件安全分发到对应机器，并设置环境变量启用安全模式。

   Bash

   export ROS_SECURITY_ENABLE=true
   export ROS_SECURITY_STRATEGY=Enforce
   export ROS_SECURITY_KEYSTORE=~/sros2_keystore
   

启用后，未持有合法证书的节点将无法发现网络中的其他节点，即使处于同一局域网内；所有通信数据均经过 AES 加密，防止窃听和篡改 42。

---

6. 扩展生态：仿真、微控制器与云端

ROS2 的生态系统早已超越了单纯的上位机软件，向着嵌入式底层和云端仿真两端延伸。

6.1 Gazebo 的迭代：从 Classic 到 Ignition (Sim)

随着 ROS1 的退役，Gazebo 9/11 (Gazebo Classic) 也停止了功能更新。新一代仿真器 Gazebo (原名 Ignition Gazebo) 采用了模块化架构，渲染、物理引擎和传感器模拟完全解耦 44。

ros_gz_bridge 的关键作用：

ROS1 使用 gazebo_ros_pkgs 将 ROS 节点直接嵌入仿真器插件中。ROS2 采用了更清晰的架构：Gazebo 运行在独立的进程中，通过 ros_gz_bridge 节点将 Gazebo 的内部传输层（Ignition Transport）与 ROS2 DDS 进行桥接 46。

迁移影响：

• URDF/SDF: 模型描述文件需要适配新的标签。

• Launch: 启动方式变为调用 ros_gz_sim 的 launch 文件，并通过参数桥接所需的话题（如 /cmd_vel 和 /lidar）。

  Bash

  ros2 launch ros_gz_sim gz_sim.launch.py gz_args:="empty.sdf"
  ros2 run ros_gz_bridge parameter_bridge /cmd_vel@geometry_msgs/msg/Twist@gz.msgs.Twist
  

这种分离架构使得 ROS2 可以更容易地与 Unity、Unreal Engine 或 NVIDIA Isaac Sim 等其他仿真引擎集成 46。

6.2 Micro-ROS：将 ROS2 植入 MCU

在 ROS1 时代，微控制器（如 Arduino）通常通过 rosserial 协议作为从设备接入。Micro-ROS 则利用 Micro-XRCE-DDS 协议，将微控制器变成了 ROS2 网络中的一等公民 48。

架构组成：

• Micro-ROS Client: 运行在 MCU（如 ESP32, STM32, Raspberry Pi Pico）上的轻量级库，基于 FreeRTOS 或 Zephyr 等 RTOS。

• Micro-ROS Agent: 运行在上位机（Linux）上的代理服务，负责将 MCU 的轻量级通信转换为标准的 DDS 流量。

优势：

MCU 节点可以直接发布话题、提供服务甚至由生命周期管理器管理。这意味着底层的传感器驱动和电机控制回路可以无缝融入 ROS2 的生态，享受 QoS 配置和调试工具的便利，彻底打破了嵌入式开发与上层应用开发的隔阂 48。

---

7. 迁移实践与互操作指南

对于拥有大量 ROS1 资产的团队，迁移是一个渐进的过程。ros1_bridge 是连接新旧世界的桥梁。

7.1 ros1_bridge 的原理与配置

ros1_bridge 是一个特殊的节点，它同时连接 ROS1 Master 和 ROS2 DDS 网络，负责消息的自动转换和转发 34。

动态桥接 (Dynamic Bridge)：

最简单的使用方式。它会监听两边的网络，一旦发现同名且类型兼容的话题（如 ROS1 有发布者，ROS2 有订阅者），就会自动建立转发通道。

Bash

# 必须在一个干净的终端中按顺序执行
source /opt/ros/noetic/setup.bash
source /opt/ros/humble/setup.bash
export ROS_MASTER_URI=http://localhost:11311
ros2 run ros1_bridge dynamic_bridge

自定义消息的桥接：

动态桥接仅支持标准消息。对于自定义消息（.msg），必须从源码编译桥接包。这需要创建一个包含 ROS1 消息包、ROS2 消息包和自定义映射规则（YAML 文件）的混合工作空间，并按照严格的顺序进行编译，以便桥接程序能生成转换代码 51。

7.2 渐进式迁移策略

策略一：边缘节点先行 (Leaf-Node First)

优先将传感器驱动（Lidar, Camera）和执行器驱动迁移到 ROS2。使用 Bridge 将数据传回 ROS1 的核心算法层。这有助于验证硬件兼容性和 DDS 通信的稳定性 53。

策略二：核心算法替换

利用 ROS2 强大的算法库（如 Navigation2, MoveIt2）替换 ROS1 的对应模块。保留 ROS1 的外围驱动，通过 Bridge 将数据输入给 ROS2 的算法节点。

多机通讯配置陷阱：

在跨机桥接时，务必注意：

• ROS1: 需正确设置 ROS_MASTER_URI 和 ROS_IP。

• ROS2: 需确保所有机器处于同一 ROS_DOMAIN_ID，且网络支持 UDP 组播（Multicast）。如果在不支持组播的 WiFi 网络中，需配置 DDS XML 文件使用单播发现（Unicast Discovery）8。

7.3 结语：拥抱确定性的未来

从 ROS1 到 ROS2 的跨越，是机器人软件工程从“能用”到“好用”、从“实验”到“产品”的质变。虽然 DDS 的配置复杂性、C++ 现代语法的门槛以及构建系统的变更带来了陡峭的学习曲线，但其带来的实时性保障、分布式容错能力和原生安全机制，是构建下一代智能机器人不可或缺的基石。随着 2025 年 ROS1 的谢幕，尽早掌握 ROS2 的架构原理与实践技能，已成为每一位机器人开发者的必修课。

---

附录：ROS1 vs ROS2 关键差异速查表

核心概念	ROS1 实现机制	ROS2 实现机制	迁移要点
构建工具	catkin_make / catkin tools	colcon build	需重写 CMakeLists.txt 和 package.xml，注意构建隔离。
节点句柄	ros::NodeHandle	rclcpp::Node / self	转向面向对象编程，移除全局句柄。
消息循环	ros::spin()	rclcpp::spin(node) + Executors	显式选择执行器模型，注意死锁风险。
参数系统	Global Parameter Server	Node-Local Parameters	参数需在 Launch 文件或 YAML 中按节点层级配置。
Launch	XML (.launch)	Python (.launch.py)	利用 Python 脚本实现动态配置逻辑。
通信底层	Master + TCPROS	DDS (RTPS)	配置 XML 文件优化 QoS，无需运行 Master。
头文件	.msg -> Header.h	.msg -> header.hpp	修改 #include 路径，使用 msg 命名空间。
桥接工具	无	ros1_bridge	仅在过渡期使用，注意序列化开销。