米喜最近总有人问我同样一个问题：想进入具身智能这行，到底该学ROS1还是直接上ROS2？问的人里有刚毕业的学生，有做传统嵌入式转过来的工程师，还有一些是想给实验室搭机器人平台的老师。网上关于两个版本谁优谁劣的讨论也吵了好几年，有人说ROS2稳定了赶紧上，有人说ROS1生态庞大、资料齐全不用急着迁，夹在中间的新手往往一头雾水。
我接触ROS大概是从Indigo那会儿开始的，后来在Melodic、Noetic上做过移动底盘，也接过机械臂的MoveIt方案，ROS2的Dashing、Foxy、Humble也都实际跑过项目，包括用ROS2做过机器狗的导航和感知模块。这篇文章我会把这些年两个版本都用下来的真实感受写清楚：它们到底差在哪里、选型的决策逻辑是什么、从ROS1迁到ROS2要跨越哪些坑，以及具身智能硬件接入时两个版本各自的适用场景。
1. 具身智能研发里，ROS版本选择为什么让人头疼
1.1 一套机器人软件框架牵动整条技术栈
先说一个基本事实：ROS不是单纯的“操作系统”，也不是某个算法库，它是介于操作系统和机器人应用之间的一整套分布式通信框架。放到具身智能的场景里看，一台机器人身上同时存在感知、定位、导航、规划、控制、人机交互等多个模块，这些模块分属不同的开发团队、运行在不同计算单元上，它们需要一套约定俗成的消息格式和通信方式把数据“串”起来。ROS解决的就是这个问题，这也是为什么你在任何一家机器人公司、任何一篇具身智能论文里都能看到它的身影。
但“无处不在”和“版本分裂”是两回事。我在2023年看到不少新开的机器人创业公司，技术栈里写的是Ubuntu 20.04 + ROS1 Noetic，招聘要求也写着“熟悉ROS1/ROS2”，这个“/”其实很微妙——他们自己可能都没想清楚新项目到底用哪个，因为团队里老一辈工程师只会ROS1，新招进来的年轻人又只会ROS2。
如果你只是做一个固定场景的轮式机器人，ROS1完全够用，没必要折腾。但如果你要做的是一台要进入千行百业的通用具身智能机器人，需要支持多机协同、需要和云平台对接、需要对底层关节做实时控制、需要和其他机器人共享地图和任务——那ROS1的架构瓶颈就会逐渐冒出来。
1.2 老代码资产与新项目需求之间的拉锯
具身智能这个领域有一个独特的现象：学术论文和开源代码更新极快，但底层机器人平台反而长时间停留在ROS1。比如你在GitHub上搜一个“mobile manipulation”的仓库，很多是基于ROS1的，跑起来还要依赖特定版本的Gazebo和MoveIt；而另一方面，像宇树、波士顿动力这类新一代机器人平台，官方给出的SDK和示例已经全面转向ROS2。
我在带项目时经常遇到这种局面：团队里有现成的ROS1代码库，是一年多时间积累的底盘驱动、状态机、导航配置，直接扔掉太可惜；但客户要求的新功能，比如多台机器人协同避让、动态任务分配，在ROS1里做要多写很多底层逻辑。这个拉锯如果没有清晰的判断标准，项目很容易卡在半路，团队心力也会被反复折腾掉。
这篇文章就是想把选择标准讲透，让你面对具体场景时能快速判断“该用哪个”，而不是靠感觉。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ROS1与ROS2的本质差异：从架构上理解两个版本的“脾气”
2.1 最大的分水岭：中心化Master与去中心化DDS
先说ROS1最核心的架构。ROS1的每个节点在启动时要向一个叫做roscore的Master节点进行注册，Topic、Service的通信双方也通过Master完成匹配。你可以把它理解成“所有人都要通过一个总机来转接电话”：总机知道每个节点的地址和话题，通信双方交换信息之前先通过总机建立连接。这个过程本身很稳定，但它有一个天然的缺点——总机一旦挂了，整台机器人的所有通信就全部瘫痪。在实验室里多节点崩溃、重启是家常便饭，但你没法接受一台在外跑着的机器人突然“失联”。
ROS2则把Master整个拿掉了，底层换成DDS（Data Distribution Service）这套分布式通信标准。每个节点在启动时会通过“发现机制”主动去探测同网络内的其他节点，话题、服务、动作的匹配变成了节点与节点之间直接协商。最直观的感受是：启动多个节点时，不需要先启动一个roscore，各个节点开起来之后它们自己就能找到彼此。这个“各自发现”的机制看起来只是去掉了Master，实际上改变了整个系统的容错能力和扩展方式，也直接影响了ROS2在多机器人、多机协同场景下的天然优势。
2.2 通信质量、实时性与QoS策略
ROS1的通信质量模型相对简单：话题消息默认用TCP传输，也有UDPROS的选项，但日常开发中很少人真的去用。TCP本身可靠、稳定，但它的重传机制对高频率、大带宽的数据不太友好，而且实时性没有保证。曾经有人在ROS1里用激光雷达和视觉数据做融合，点云消息一大，就直接挤占其他话题的带宽，整个系统的延迟就上来了。
ROS2基于DDS引入了QoS（Quality of Service）策略。QoS可以理解成一套“通信契约”，你可以告诉系统这种消息是“必须送达”还是“丢了就算了”、是“只发给最新的订阅者”还是“保留历史数据”。这对具身智能非常重要：比如传感器高频数据，你希望订阅者拿到尽可能新鲜的帧，丢失一两帧可以接受，那就用“尽力传输”策略；比如任务调度指令，你希望绝对不丢，那就用“可靠传输”策略。不同的模块用不同的QoS策略，整个系统在数据洪流下依然能保持稳定。
为了直观表示两个版本的差异，我整理了一个表格：
| 维度 | ROS1 | ROS2 |
|---|---|---|
| 系统架构 | 中心化Master（roscore） | 去中心 |