面试的时候被问你知道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 RoboticsWillow Garage的继承者联合OSRF基金会开始开发ROS2。核心目标就是解决ROS1的这些痛点。ROS2做了一个根本性的架构决策用DDSData 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。其中Humble2022年发布是目前工业界用得最多的版本支持到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的rclpyPython客户端库在性能上已经大幅提升越来越多的团队开始用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