1. 一个看似简单却暗藏玄机的问题“Ubuntu 22.04上能装ROS1吗” 这个问题乍一看像是一个只需要“能”或“不能”就能回答的判断题。但如果你真的在搜索引擎里敲下这行字或者去ROS社区提问得到的答案往往会让你更加困惑。有人会说“可以但很折腾”有人会直接建议“别想了上ROS2吧”还有人会甩给你一个复杂的、需要自己编译源码的教程链接。对于一个想在最新LTS系统上尝试ROS1的开发者尤其是新手来说这种信息混乱的局面足以让人望而却步。问题的核心在于ROS1Robot Operating System 1作为一个已经进入“遗产”维护阶段的软件框架其官方支持的生命周期与Ubuntu发行版的更新节奏并不同步。ROS1的最后一个长期支持版本是Noetic Ninjemys它的官方支持截止到2025年5月并且明确只支持Ubuntu 20.04 (Focal Fossa)。而Ubuntu 22.04 (Jammy Jellyfish) 发布于2022年4月在ROS1 Noetic的规划周期之外。因此从“官方原生支持”的角度看答案很明确不行。官方没有为Ubuntu 22.04预编译好的二进制包.deb文件。然而在软件的世界里“官方不支持”从来不等同于“技术上不可行”。无数开发者、研究者和爱好者的需求是真实存在的实验室新采购的机器预装了22.04不想重装系统项目依赖的某些库或驱动在22.04上才有新版本或者就是想在新系统上尝试经典的ROS1生态。正是这些需求催生了各种“非官方”的解决方案。所以更准确的回答是可行但你需要清楚地知道自己在做什么并准备好应对一系列兼容性挑战这绝非一键安装的体验。本文将彻底拆解在Ubuntu 22.04上安装和使用ROS1的几种路径深入分析每种方法背后的原理、具体操作步骤、必然会遇到的坑以及如何填平它们。我的目标不是劝退而是给你一张清晰的“地形图”让你能基于自己的技术背景和项目需求做出明智的选择并成功抵达目的地。2. 路径抉择三种安装方案的深度剖析面对官方支持的缺失我们主要有三条路可以走使用社区维护的二进制包、从源代码编译、或者采用容器化技术。每一种方案都代表着不同的复杂度、灵活度和系统侵入度。没有最好的只有最适合你当前场景的。2.1 方案一社区二进制包——最快捷的“非官方”正道这是最接近原生安装体验的方法。虽然ROS官方没有为22.04提供包但一些社区成员和机构维护着针对新系统的构建版本。其中最著名的是来自RoboStack频道的ros-noetic-desktop-full包。原理与风险社区维护者利用ROS的构建农场build farm工具链在Ubuntu 22.04的环境下重新编译了Noetic的源代码生成了适用于Jammy的.deb安装包。这省去了用户自己编译的麻烦。但风险在于其维护完全依赖于社区志愿者的精力可能不会像官方包那样及时同步所有更新和安全补丁。此外由于22.04的基础库如Python 3.10, OpenCV 4.5等与20.04不同编译出的二进制包可能与某些预期行为有细微差别。具体操作步骤配置软件源首先需要将RoboStack的仓库添加到你的APT源列表中。这通过一个apt-key和添加源文件来完成请注意apt-key的方式在最新Debian/Ubuntu中已被弃用但许多社区源仍在使用。sudo apt update sudo apt install curl gnupg lsb-release curl -s https://raw.githubusercontent.com/RoboStack/ros-noetic/main/ros-noetic-keyring.gpg | sudo tee /usr/share/keyrings/ros-noetic-archive-keyring.gpg /dev/null echo deb [arch$(dpkg --print-architecture) signed-by/usr/share/keyrings/ros-noetic-archive-keyring.gpg] https://robostack.github.io/ros-noetic $(lsb_release -cs) main | sudo tee /etc/apt/sources.list.d/ros-noetic.list这里的关键是$(lsb_release -cs)会自动获取你的系统代号如jammy确保添加的是对应你系统的仓库。安装ROS更新软件列表并安装桌面完整版。sudo apt update sudo apt install ros-noetic-desktop-full这个过程会下载数百兆的包并自动处理大部分依赖。环境配置和官方安装一样需要将ROS环境变量添加到你的shell配置文件中。echo source /opt/ros/noetic/setup.bash ~/.bashrc source ~/.bashrc为了使用ROS命令行工具还需要安装ros-noetic-rosbash等基础工具包。sudo apt install python3-rosdep python3-rosinstall python3-rosinstall-generator python3-wstool build-essential sudo rosdep init rosdep update实操心得与避坑指南网络问题rosdep init和update步骤常因网络问题失败。可以尝试修改/etc/hosts文件添加对raw.githubusercontent.com的IP解析或使用国内镜像源。验证安装安装完成后务必运行roscore来测试核心服务是否能正常启动。再打开一个新终端运行rosrun turtlesim turtlesim_node和rosrun turtlesim turtle_teleop_key看看经典的小乌龟模拟器能否正常工作。这是检验ROS基础功能是否完好的“试金石”。后续更新通过此方法安装后可以使用sudo apt update sudo apt upgrade来获取社区维护的更新但频率和稳定性需要观察。2.2 方案二从源代码编译——最彻底也最复杂的掌控如果你需要对ROS本身进行修改或者希望绝对控制编译选项和依赖版本从源码编译是唯一的选择。这也是当社区包无法满足需求时的终极解决方案。为什么选择源码编译除了上述原因源码编译还能让你在22.04上构建出理论上与20.04官方二进制包行为最一致的ROS环境因为你可以严格控制依赖库的版本。但代价是巨大的时间成本和出现编译错误的概率。核心步骤与关键配置系统准备安装基础编译工具和ROS的一些核心依赖。sudo apt update sudo apt install python3-rosdep python3-rosinstall-generator python3-wstool build-essential python3-osrf-pycommon sudo rosdep init rosdep update创建工作空间并下载源码我们使用wstool来管理多个仓库的源码。mkdir -p ~/ros_noetic_ws/src cd ~/ros_noetic_ws rosinstall_generator desktop_full --rosdistro noetic --deps --tar noetic-desktop-full.rosinstall wstool init src noetic-desktop-full.rosinstall这一步会下载一个.rosinstall文件里面定义了桌面完整版所需的所有软件包仓库地址和版本然后wstool init会根据这个文件去拉取代码。网络状况不好的话这个过程可能极其漫长且容易中断。解决依赖这是源码编译中最容易出错的一环。rosdep会尝试根据每个包的package.xml文件来安装系统依赖。cd ~/ros_noetic_ws rosdep install --from-paths src --ignore-src -y --osubuntu:jammy关键参数解析--osubuntu:jammy至关重要它告诉rosdep你现在是jammy系统而不是noetic默认的focal。rosdep会去查询针对jammy的ROS包依赖规则如果找不到它会回退到通用的或者focal的规则这可能导致依赖安装不准确。编译使用catkin_make或更现代的catkin build进行编译。./src/catkin/bin/catkin_make_isolated --install -DCMAKE_BUILD_TYPERelease # 或者使用catkin_tools # sudo apt install python3-catkin-tools # catkin build编译过程视机器性能而定可能需要数小时。期间可能会因为Ubuntu 22.04上某些库版本过高而报错例如PCL点云库或OpenCV相关的编译错误。踩坑实录依赖版本冲突的解决 我在编译过程中遇到一个典型错误PROJECT包找不到PCL的某个组件。原因是Ubuntu 22.04的libpcl-dev版本是1.12而ROS Noetic源码期望的可能是1.10。解决方法不是降级系统包可能引发其他问题而是修改ROS包的CMakeLists.txt。需要找到报错包的源码在其CMakeLists.txt中将find_package(PCL 1.10 REQUIRED COMPONENTS ...)中的版本要求1.10改为1.12或者直接移除版本号指定find_package(PCL REQUIRED COMPONENTS ...)。这要求你对CMake和该包有一定了解。这就是源码编译的常态你不仅是使用者还是临时的集成工程师。2.3 方案三容器化方案——最干净利落的隔离术如果你追求极致的系统纯净度或者需要在同一台机器上频繁切换ROS1/ROS2甚至不同版本那么Docker容器几乎是完美选择。它本质上是为ROS1 Noetic创建一个基于Ubuntu 20.04的微型虚拟环境与宿主机的22.04完全隔离。优势与劣势对比优势环境纯净完全复刻官方支持的环境0兼容性问题。隔离安全不会污染宿主机系统玩坏了删掉容器重来就行。可移植性镜像可以分享在任何安装Docker的22.04、20.04甚至其他Linux发行版上运行结果一致。多版本共存可以同时运行ROS Noetic、ROS2 Galactic/Humble的容器互不干扰。劣势性能开销有轻微的性能损耗对于GUI应用需要额外配置。使用复杂度需要学习基本的Docker命令图形和硬件如摄像头、GPU、USB设备接入需要额外映射。开发体验编辑容器内的代码不如直接编辑宿主机文件方便通常需要挂载卷volume。从拉取镜像到运行可视化节点的全流程安装Docker在Ubuntu 22.04上安装Docker引擎。sudo apt update sudo apt install docker.io sudo systemctl enable --now docker # 将当前用户加入docker组避免每次用sudo sudo usermod -aG docker $USER # 退出终端重新登录生效获取ROS镜像从Docker Hub拉取官方ROS镜像。这里我们选择带有桌面环境的noetic-desktop-full。docker pull osrf/ros:noetic-desktop-full运行容器并开启GUI这是关键一步让容器内的ROS程序能显示窗口。xhost local:docker # 允许Docker连接本地X11服务器 docker run -it --rm \ --envDISPLAY \ --envQT_X11_NO_MITSHM1 \ --volume/tmp/.X11-unix:/tmp/.X11-unix:rw \ osrf/ros:noetic-desktop-full \ /bin/bash解释一下参数-it交互式终端--rm退出后自动删除容器--env传递显示相关的环境变量--volume将宿主机的X11套接字挂载到容器内。在容器内使用ROS现在你进入了一个全新的bash终端其根文件系统是Ubuntu 20.04。按照ROS官方教程初始化环境即可。source /opt/ros/noetic/setup.bash roscore rosrun turtlesim turtlesim_node # 此时小乌龟窗口应该会出现在你的宿主机屏幕上高级技巧使用Docker Compose和持久化工作空间 对于复杂项目建议使用docker-compose.yml来定义服务并挂载一个宿主机目录到容器内作为ROS工作空间这样代码可以持久化并在宿主机上用喜欢的IDE编辑。version: 3 services: ros-noetic: image: osrf/ros:noetic-desktop-full container_name: my_ros_noetic network_mode: host # 方便与宿主机其他服务通信 environment: - DISPLAY${DISPLAY} - QT_X11_NO_MITSHM1 volumes: - /tmp/.X11-unix:/tmp/.X11-unix:rw - ./ros_ws:/home/ros_ws:rw # 将当前目录下的ros_ws挂载到容器 stdin_open: true tty: true command: bash -c source /opt/ros/noetic/setup.bash cd /home/ros_ws /bin/bash然后使用docker-compose run ros-noetic启动一个交互式容器你的工作空间就在./ros_ws里。3. 安装后的核心挑战与系统性解决方案无论通过哪种方式在22.04上成功安装了ROS1真正的挑战才刚刚开始。系统底层的差异会像暗礁一样在你运行具体功能包时逐一浮现。主要集中在Python 3、C库版本和系统服务这几个层面。3.1 Python 3.10 兼容性从语法到模块的全面适配Ubuntu 22.04 默认使用 Python 3.10而 ROS Noetic 官方设计是基于 Python 3.8。Python 3.8 到 3.10 有一些不兼容的变更虽然大部分ROS核心包已做适配但大量第三方或你自己编写的Python节点可能出问题。典型问题1collections模块导入错误这是最常见的问题。在Python 3.10中collections模块中的一些抽象基类如Iterable,Callable等需要从collections.abc子模块导入。而很多旧的ROS Python代码直接使用from collections import Iterable。错误信息ImportError: cannot import name Iterable from collections解决方案修改你的Python脚本将导入语句改为# 旧代码 from collections import Iterable, Callable # 新代码 from collections.abc import Iterable, Callable对于大量文件可以使用sed命令进行批量替换但务必谨慎先备份。find . -name *.py -exec sed -i s/from collections import/from collections.abc import/g {} \; # 注意这个命令可能误伤最好在版本控制下操作或手动检查关键文件。典型问题2typing模块的变化Python 3.9/3.10 对typing模块做了大量优化引入了list,dict等泛型语法糖。虽然这通常不会导致直接错误但如果你在代码中使用了较新的typing特性如在 Noetic 环境中开发但用到了 3.9 的语法在旧的 Python 3.8 环境下可能会报错。在 22.04 上这反而是优势但如果你写的代码需要兼容官方 20.04 环境则需要注意。系统性排查与测试 建议为你的ROS项目创建一个基于 Python 3.10 的虚拟环境如venv在其中安装catkin的 Python 工具包catkin_tools等然后运行你的 Python 节点。这样可以在隔离环境中提前发现所有导入和语法错误。3.2 系统库版本冲突以OpenCV和PCL为例ROS Noetic 官方二进制包链接的是 Ubuntu 20.04 仓库中的库版本例如 OpenCV 4.2。而 Ubuntu 22.04 默认提供了 OpenCV 4.5或更高。如果你的 ROS 包无论是二进制安装还是源码编译在运行时动态链接了系统路径下更新的库可能会遇到 ABI应用程序二进制接口不兼容的问题导致崩溃或诡异的行为。症状程序在启动时或执行到特定功能如图像处理时发生段错误Segmentation fault或抛出关于符号未找到undefined symbol的运行时错误。诊断方法使用ldd命令查看可执行文件或共享库的依赖。ldd /opt/ros/noetic/lib/package_name/node_name | grep opencv查看输出中libopencv_core.so.4.2链接的是否是系统路径如/usr/lib/x86_64-linux-gnu/下的4.5版本。如果存在这种混用就是风险的源头。解决方案优先方案使用ROS自带的库。确保你的CMakeLists.txt中find_package(OpenCV REQUIRED)找到的是ROS环境下的OpenCV通常路径是/opt/ros/noetic。在编译时CMake的find_package会设置链接路径。你可以通过检查编译输出的-I和-L参数来确认。隔离方案使用LD_LIBRARY_PATH。在启动ROS节点前通过修改LD_LIBRARY_PATH环境变量优先加载ROS自带的库目录。export LD_LIBRARY_PATH/opt/ros/noetic/lib:$LD_LIBRARY_PATH rosrun your_package your_node可以将这行命令写入你的启动脚本.launch文件或 shell 脚本。终极方案容器化。如前所述Docker 容器能彻底根除此类问题因为它提供了完全一致的库环境。对于PCL点云库问题类似。Ubuntu 22.04 的libpcl-dev是 1.12而 Noetic 预期是 1.10。如果源码编译时通过了但运行时链接了错误版本同样会崩溃。解决方法同样是确保链接路径的正确性。3.3 系统服务与守护进程udev规则与串口权限机器人开发离不开硬件USB设备如激光雷达、IMU、控制器的接入依赖系统的udev规则和用户组权限。这些配置是系统层面的与ROS版本无关但在新系统上设置是必要步骤。串口权限问题默认情况下普通用户无法直接读写串口设备如/dev/ttyUSB0。临时解决每次使用sudo chmod 666 /dev/ttyUSB0但设备重插后失效。永久解决将用户加入dialout组。sudo usermod -a -G dialout $USER重要执行此命令后你需要完全退出当前登录会话注销并重新登录或者重启电脑用户组变更才会生效。仅仅新开一个终端是不够的。udev规则配置为了让设备拥有固定的设备名和权限需要创建 udev 规则。例如为特定型号的激光雷达创建规则找到设备的供应商ID和产品IDlsusb命令查看。在/etc/udev/rules.d/下创建规则文件如99-sick-lms.rulesSUBSYSTEMtty, ATTRS{idVendor}19d2, ATTRS{idProduct}0001, MODE:0666, SYMLINKsick_lms这条规则为特定USB转串口设备设置了权限并创建了一个固定的符号链接/dev/sick_lms。重新加载udev规则并触发sudo udevadm control --reload-rules sudo udevadm trigger。重新插拔设备现在就可以使用/dev/sick_lms来访问设备且无需sudo。这些硬件配置步骤在Ubuntu 22.04上与在20.04上完全一致但正是在新系统上搭建环境时最容易忽略的一环导致ROS节点启动后报“无法打开端口”的错误。4. 实战检验构建与运行一个经典功能包理论说得再多不如亲手跑通一个例子。我们选择在ROS中集成和运行一个经典的SLAM同步定位与建图算法包——gmapping它可以将激光雷达数据转换为地图。这个流程涵盖了创建ROS工作空间、下载源码、解决依赖、编译、运行和调试的完整生命周期能暴露大部分潜在问题。4.1 创建工作空间与获取源码首先我们创建一个独立的工作空间与ROS系统路径隔离这是ROS开发的推荐做法。# 假设我们采用社区二进制包安装的ROS source /opt/ros/noetic/setup.bash mkdir -p ~/catkin_ws/src cd ~/catkin_ws/src接下来我们需要获取gmapping的源代码。gmapping是slam_gmapping包的一部分。我们可以直接使用git克隆或者用wstool如果工作空间是用它初始化的。这里用更通用的gitgit clone https://github.com/ros-perception/slam_gmapping.git cd ~/catkin_ws现在~/catkin_ws/src目录下应该有了slam_gmapping的代码。4.2 解决依赖与编译过程中的排错在编译之前必须解决所有依赖。使用rosdep工具。cd ~/catkin_ws rosdep install --from-paths src --ignore-src -y注意如果你在Ubuntu 22.04上并且rosdep数据库没有正确适配jammy这一步可能会报错提示找不到某些包的规则。错误可能类似于ERROR: the following packages/stacks could not have their rosdep keys resolved to system dependencies: slam_gmapping: No definition of [gmapping] for OS version [jammy]这是因为rosdep的默认规则文件里gmapping的键值可能只定义了focal的依赖。解决方法有两种本地覆盖规则在/etc/ros/rosdep/sources.list.d/下创建一个自定义的规则文件例如20-custom.list指向一个包含jammy规则的本地YAML文件。但这比较繁琐。手动安装依赖查看slam_gmapping包中package.xml文件找到run_depend或exec_depend标签。对于gmapping其核心依赖通常是openslam-gmapping。在Ubuntu 22.04上你可以尝试安装同名包sudo apt install ros-noetic-openslam-gmapping如果找不到可能需要从源码编译openslam-gmapping。这正是在22.04上常见的“依赖链断裂”问题。假设我们解决了依赖开始编译catkin_make # 或者使用catkin build (需先安装 catkin_tools: sudo apt install python3-catkin-tools) # catkin build编译过程可能会顺利也可能会因为之前提到的Python 3.10语法或库版本问题而失败。例如如果gmapping的某个Python工具脚本使用了旧的collections导入方式就会在编译的“生成消息”或“设置步骤”中报错。你需要定位到具体文件并进行修改。4.3 运行测试与可视化调试编译成功后需要刷新工作空间的环境。source ~/catkin_ws/devel/setup.bash现在我们可以尝试运行gmapping节点。但gmapping需要激光雷达数据。为了测试我们通常使用ROS的仿真工具turtlebot3或stage来提供模拟的激光数据。这里以播放一个已有的激光数据包bag文件为例这是一种更简单的测试方法。准备数据首先你需要一个记录了激光雷达话题通常是/scan的.bag文件。可以从ROS官网或一些开源数据集下载。启动gmapping在一个终端中启动gmapping节点并指定正确的参数比如激光话题名。roslaunch gmapping slam_gmapping.launch默认的启动文件可能假设激光话题是/scan。如果不对你需要修改启动文件或通过参数传入roslaunch gmapping slam_gmapping.launch scan_topic:/your_scan_topic。播放数据包在另一个终端播放bag文件。rosbag play your_laser_data.bag --clock--clock参数很重要它发布模拟的时钟信号很多节点依赖它。查看地图再打开一个终端启动rviz这是ROS的可视化工具。rviz在rviz中添加一个Map显示类型将其Topic设置为/map。随着bag文件的播放你应该能看到地图被逐渐构建出来。调试实战问题rviz中看不到地图或者地图是空的。排查思路检查话题在终端运行rostopic list确保有/scan激光数据和/map地图数据话题。如果没有/map说明gmapping节点没有成功发布。检查节点状态rosnode list查看节点是否存活rosnode info /slam_gmapping查看节点详情和订阅发布的话题。查看日志roslaunch的输出、各个终端的输出以及roscore的日志中是否有错误信息。常见的错误包括激光话题名不匹配、坐标系tf变换树不完整、激光数据格式不正确等。检查tfgmapping需要知道激光雷达相对于机器人基座base_link的位置关系。运行rosrun tf view_frames可以生成当前tf树的PDF查看是否有缺失的链接。如果使用bag文件需要确保bag里包含了必要的tf变换信息或者通过static_transform_publisher发布静态变换。通过这样一个完整流程你不仅验证了ROS1在22.04上的基本功能还实战演练了从源码到运行的全过程遇到的每一个错误和解决过程都是对系统兼容性理解的加深。5. 长期维护与迁移建议在Ubuntu 22.04上运行ROS1不是一个一劳永逸的安装动作而是一个需要持续维护的状态。你需要为未来的系统更新、ROS包更新以及最终的迁移做好准备。5.1 系统升级与ROS的脆弱平衡Ubuntu 22.04本身会通过常规更新推送安全补丁和软件包更新。大多数更新是安全的但偶尔会有库的次版本升级例如从OpenCV 4.5.4升级到4.5.5。对于通过社区二进制包安装的ROS只要社区维护者及时跟进重建通常问题不大。但对于源码编译的ROS或者那些链接了系统库的ROS包任何底层库的ABI变化都可能导致运行时崩溃。维护策略谨慎进行系统更新在更新系统前特别是执行sudo apt upgrade最好先查看将要更新的包列表sudo apt list --upgradable。如果看到关键的底层库如libstdc,libgcc,libopencv*,libpcl*有更新需要提高警惕。创建系统快照如果使用虚拟机或支持系统快照的环境如VirtualBox、VMware在进行重大系统更新前创建一个快照。如果更新导致ROS环境崩溃可以快速回滚。隔离测试环境对于生产或重要的开发环境可以考虑使用Docker容器。宿主机系统可以自由升级只要Docker守护进程兼容容器内的ROS环境完全不受影响。5.2 向ROS2迁移的必然性与路径规划必须清醒认识到ROS1已进入维护阶段社区的发展重心和绝大多数新特性都在ROS2上。Ubuntu 22.04有官方原生支持的ROS2发行版Humble Hawksbill支持到2027年和Jammy对应的Rolling。长期来看向ROS2迁移是必然选择。迁移不是替换而是重构ROS2并非ROS1的简单升级它在架构去中心化、实时性、通信机制DDS、构建系统ament/colcon等方面有根本性变化。迁移一个项目意味着代码的重写或大量修改。渐进式迁移路径建议评估与学习首先用一个小型、非核心的项目尝试ROS2。在Ubuntu 22.04上安装ROS2 Humble (sudo apt install ros-humble-desktop)熟悉其基本概念、命令行工具和API。识别桥梁工具ros1_bridge这是一个功能强大的包可以在同一网络内让ROS1和ROS2的节点相互通信发布/订阅话题调用/提供服务。你可以在22.04上同时运行ROS1 Noetic通过本文方法和ROS2 Humble然后用ros1_bridge连接它们。这允许你将系统的一部分逐步迁移到ROS2而另一部分暂时保留在ROS1。迁移指南ROS官方提供了详细的迁移指南从概念对比到代码逐行修改示例。制定项目迁移计划对于大型项目不要试图一次性全部迁移。可以按功能模块拆分先迁移数据流简单、依赖少的模块利用ros1_bridge与原系统交互逐步扩大ROS2模块的范围最终完全取代ROS1。在22.04上并存的优势正因为Ubuntu 22.04是ROS2 Humble的官方支持平台同时又可以通过非官方手段运行ROS1它实际上成为了一个理想的过渡环境。你可以在这个系统上同时搭建和测试ROS1与ROS2的组件进行直接的对比和桥接实验为最终迁移积累宝贵的经验。回过头来看最初的问题“Ubuntu 22.04安装和使用ROS1可行吗” 答案已经非常清晰技术上完全可行但这是一条需要付出额外努力、具备一定排错能力、并且清楚知晓其过渡性质的路径。对于初学者如果条件允许从Ubuntu 20.04开始学习ROS1仍然是阻力最小的选择。但对于已经身处22.04环境且有明确需求或探索精神的开发者本文提供的三种路径和全方位的避坑指南足以让你搭建起一个可用的、甚至稳定的ROS1开发环境。最关键的是在这个过程中培养出的问题解决能力和对系统更深的理解其价值远超一次简单的安装。最终所有的这些努力都应该指向一个目标高效地完成你的机器人项目并为拥抱ROS2的未来做好准备。