面试的时候被问："你知道ROS吗？"我说知道。"那ROS和ROS2有什么区别？"我说"ROS2是升级版"。面试官笑了笑，没再追问。

后来才知道，这个问题考的不是你背没背过版本差异，而是看你对机器人软件架构的理解深度。

今天从头讲讲ROS的故事。搞清楚它为什么会出现、遇到了什么问题、为什么要重新设计，比记住几个技术细节重要得多。

ROS的诞生：斯坦福的AI实验室

ROS的全称是Robot Operating System，机器人操作系统。但别被"操作系统"这个词骗了，它不是Windows也不是Linux那样的操作系统，更像是一个机器人软件的"开发框架"。

2007年，斯坦福大学的AI实验室（SAIL）在做家用机器人的项目。他们发现一个很头疼的问题：每做一个新机器人，之前写的代码基本都不能复用。感知模块、导航模块、操控模块，每个项目都重新造一遍轮子。

于是Morgan Quigley带着团队搞了一套框架，把通用的功能抽出来做成可复用的模块，模块之间通过消息通信。这就是ROS的雏形。

后来这个框架被Willow Garage公司接手并开源。Willow Garage当时是做通用机器人平台的，他们需要一个软件框架来支撑PR2机器人。ROS在这个阶段快速发展，形成了我们后来熟悉的核心概念：节点、话题、服务、参数服务器。

ROS1的黄金时代

2010年到2018年，ROS迎来了黄金时期。

学术界大量采用ROS做研究。因为开源、社区活跃、现成的包多。你想做SLAM？有gmapping、cartographer。想做导航？有move_base。想做物体识别？有一堆基于PCL的点云处理包。基本上你能想到的机器人功能，都有人做过了。很多大学教授直接说"我们实验室只用ROS"，因为学生毕业之后去其他实验室也能接着用。

工业界也开始用ROS。很多创业公司基于ROS做服务机器人、无人机、自动驾驶。ROS大大降低了机器人开发的门槛，让几个人的小团队也能做出像样的机器人系统。那个阶段，招聘网站上"熟悉ROS"开始频繁出现，逐渐成了机器人软件工程师的标配技能。

社区的力量也不可忽视。ROS Answers（后来迁移到ROS Discourse）上每天都有人提问和回答，Stack Overflow上ROS相关的问题越来越多。每年还有ROSCon大会，全球的ROS开发者和维护者聚在一起交流。整个生态进入了一个正向循环：用的人越多，包越多，包越多用的人就更多。

这个阶段ROS的生态蓬勃发展，ros.org上注册的包超过几千个，遍布导航、感知、操控、仿真各个领域。

问题开始显现

但ROS1在设计之初有一些假设，随着应用场景的扩展，这些假设不再成立了。

ROS1假设所有节点都在同一台机器上，或者至少在同一个局域网里。它的通信依赖一个中心化的master节点，master挂了整个系统就瘫了。这在实验室里没问题，但在实际产品里就是单点故障。

ROS1假设网络是可靠的。消息丢了就丢了，不保证送达。对于研究场景来说，丢一帧数据重新来就行。但在工业场景里，一条控制指令丢了可能导致机器人撞墙。

ROS1假设开发者都在Linux上。ROS1对macOS的支持是社区勉强维护的，Windows基本不能用。但在商业公司里，有些工具链必须在Windows上跑，有些嵌入式平台用的是RTOS。

ROS1没有实时性保证。它的通信延迟不确定，有时候1ms，有时候100ms。对于需要精确时序的控制系统来说，这是不可接受的。

还有安全问题。ROS1完全没有安全机制，任何能连上网络的设备都可以向你的机器人发送指令。在实验室里无所谓，但产品化的机器人如果存在这种安全漏洞，后果不堪设想。

ROS2的诞生

2015年，Open Robotics（Willow Garage的继承者）联合OSRF基金会，开始开发ROS2。核心目标就是解决ROS1的这些痛点。

ROS2做了一个根本性的架构决策：用DDS（Data Distribution Service）替代ROS1的自研通信层。DDS是OMG组织制定的工业级分布式数据总线标准，在航空航天、国防、医疗设备、自动驾驶领域已经用了几十年。它天生支持去中心化通信（不需要master节点）、QoS策略（可以配置消息的可靠性和时效性）、实时性保证、安全机制（DDS Security规范）。

ROS2还做了很多改进：支持多语言（C++、Python是官方支持的，社区还有Rust、Java等绑定）、支持实时操作系统（如FreeRTOS、RT-Preempt Linux）、支持多机器人系统（通过namespace隔离）、内建安全机制（SROS2基于DDS Security）。但核心思想没变——节点、话题、服务这些概念都保留了，只是底层实现完全重写了。

ROS2的第一个LTS版本是2018年的Crystal Clemmys，之后每年一个LTS版本：Dashing、Eloquent、Foxy、Galactic、Humble、Iron、Jazzy。其中Humble（2022年发布）是目前工业界用得最多的版本，支持到2027年。

从ROS1到ROS2的迁移

很多公司面临一个问题：现有的ROS1代码怎么办？全部重写不现实，但ROS1又不维护了（ROS1 Noetic在2025年停止维护）。

实际的做法是渐进式迁移。先把不依赖通信的工具代码（算法库、驱动封装）直接搬过来，这部分改动最小。然后逐步替换通信层，从ROS1的topic/service换成ROS2的对应物。最后处理那些深度依赖ROS1特性的代码，比如参数服务器、tf监听等。

社区也提供了桥接工具，可以让ROS1和ROS2的节点同时运行、互相通信。这样就能一个模块一个模块地迁移，不用一次性全换。ros1_bridge这个包就是干这个的，它能在ROS1的topic和ROS2的topic之间做消息转发。

面试中怎么聊ROS历史

面试官问ROS相关的问题，如果你能讲清楚ROS的设计演变和背后的原因，会比单纯背API有说服力得多。

比如："ROS1的中心化master在实验室场景下够用，但产品化之后单点故障和安全性就成了问题。ROS2用DDS替代了自研通信层，去掉了master，每个节点都能独立发现和连接其他节点。这个架构变化直接解决了单点故障和安全性问题。"

这种回答说明你不只是会用ROS，而是理解它为什么这么设计，面试官会觉得你有深度思考的能力。

ROS2的生态现状和未来

截至2026年，ROS2的生态已经相当成熟。主流机器人厂商——Universal Robots、Franka、AgileX——都提供了原生的ROS2驱动接口。导航方面，Nav2已经完全替代了ROS1的move_base。SLAM领域，SLAM Toolbox和Cartographer都有成熟的ROS2版本。

值得关注的是ROS2在工业领域的渗透速度。汽车行业的自动驾驶仿真、物流AGV的调度系统、农业机器人的作业控制，越来越多地采用ROS2作为中间件。这背后的驱动力是DDS的实时性和可靠性——工业场景对通信质量的要求远高于实验室环境。

如果你正在准备面试，关注ROS2的最新进展也很重要。比如ROS2的rclpy（Python客户端库）在性能上已经大幅提升，越来越多的团队开始用Python写上层逻辑节点。

ROS迁移的决策考量

从ROS1迁移到ROS2不是简单的代码翻译，很多设计决策需要重新考量。比如ROS1的roslaunch参数格式在ROS2中完全改变了，节点生命周期管理也是全新的概念。实际迁移时建议分步走：先把核心功能跑通，再逐步迁移辅助工具。面试时如果被问到迁移经验，重点讲你遇到的兼容性问题和解决方案，比罗列迁移步骤更有价值。

给你的建议

如果你刚开始学机器人开发，直接学ROS2。ROS1已经停止维护了，新项目没必要再用它。但了解一下ROS1的设计是有好处的，因为很多现有的教程、代码、文档都是基于ROS1的，理解了ROS1的概念，看ROS2的资料会更快上手。

读一下ROS2的设计文档（design.ros2.org），里面记录了每个重要设计决策的讨论过程和取舍理由。知道"为什么这么设计"比知道"怎么用"更重要，因为工具会过时，但设计思想是通用的。

---

上一篇：第105篇 CI/CD自动化——GitHub Actions/Jenkins在机器人项目中的应用

下一篇预告：第107篇 ROS1的痛点——为什么行业必须迁移到ROS2