树莓派5上ROS1与ROS2的深度抉择：从安装到实战的全面解析

最近身边不少朋友都入手了树莓派5，兴致勃勃地想用它来搭建自己的机器人项目。然而，当他们兴冲冲地打开ROS官网，准备大干一场时，往往会被一个最基础的问题卡住：我到底该选ROS1还是ROS2？ 这不仅仅是版本号的新旧之别，更关乎整个项目的技术栈、开发体验乃至未来的维护成本。网上教程虽多，但要么只讲ROS1，要么只讲ROS2，鲜有将两者放在树莓派5这个具体平台上，从安装、配置到实战进行透彻对比的。今天，我们就抛开那些泛泛而谈，深入到命令行和配置文件里，看看在树莓派5这块小小的板子上，ROS1和ROS2究竟有何不同，你又该如何根据手头的项目做出最明智的选择。

1. 核心差异与选型逻辑：不只是“一代”和“二代”

在纠结安装步骤之前，我们必须先理解ROS1和ROS2在架构哲学上的根本区别。这决定了它们各自适合什么样的应用场景。

ROS1（Robot Operating System 1）自2007年诞生以来，凭借其强大的社区生态和丰富的功能包，成为了机器人研究领域的“事实标准”。它的核心通信机制基于TCPROS/UDPROS，是一种中心化的、依赖于ROS Master节点的架构。想象一下，所有的节点（Node）就像公司里的员工，而ROS Master就是那位不可或缺的总经理，负责员工之间的介绍和任务协调。没有总经理，员工之间就无法直接沟通。

ROS1的核心特点与局限：

• 强依赖Master：roscore命令必须首先运行，它是整个系统的“大脑”。一旦Master崩溃，整个系统通信将瘫痪。
• 实时性有限：其通信协议并非为硬实时系统设计，在需要精确时序控制（如高速无人机、工业机械臂）的场景下可能力不从心。
• 网络配置复杂：在多机通信时，需要手动设置ROS_MASTER_URI和ROS_HOSTNAME等环境变量，对新手不够友好。
• 成熟的生态：这是它最大的优势。成千上万的软件包（如导航move_base、感知PCL）经过多年锤炼，稳定可靠，文档和社区支持极其丰富。

相比之下，ROS2的设计目标就是解决ROS1的这些痛点。它基于数据分发服务（DDS）这一工业级中间件标准，构建了一个去中心化的、对等的通信架构。

ROS2的革新之处：

• 无中心节点：不再需要单独的roscore。每个节点都能自主发现和通信，系统鲁棒性大大增强。
• 内置实时支持：DDS协议本身支持服务质量（QoS）策略，可以配置消息的可靠性、截止时间、持久性等，为实时应用提供了可能。
• 跨平台与生产就绪：从底层支持Windows、macOS和实时操作系统（RTOS），更贴近产品化需求。
• 现代化的工具链：使用colcon替代catkin作为构建工具，命令行工具（ros2命令）也更加统一和强大。

那么，在树莓派5上如何选择？我们可以用一个简单的决策表来梳理：

考量维度	优先选择 ROS1	优先选择 ROS2
项目性质	学术研究、原型验证、教育学习	产品原型、需要部署到真实环境、多机器人系统
实时性要求	无硬实时要求，允许一定延迟	有实时性或确定性通信需求
系统可靠性	可接受单点故障（Master崩溃）	要求高可用性，避免单点故障
依赖的软件包	依赖的算法包（如SLAM、运动规划）仅支持ROS1	依赖的驱动或硬件SDK已提供ROS2支持，或软件包已有ROS2版本
开发团队熟悉度	团队更熟悉ROS1，且项目时间紧迫	团队愿意学习新技术，着眼于长期技术栈
操作系统	倾向于使用树莓派OS（Raspbian）	倾向于使用Ubuntu Server 22.04/24.04

提示：如果你的项目严重依赖某个仅在ROS1上可用的经典算法包（例如gmapping），那么ROS1可能是你唯一的选择。反之，如果你是从零开始一个新项目，尤其是涉及多机协作或未来有产品化可能，那么直接投入ROS2的怀抱将是更具前瞻性的决定。

2. 系统准备与安装路径分水岭

选择不同版本的ROS，首先面临的岔路口就是操作系统的选择。这一步的选择，会直接影响到后续所有流程的顺畅程度。

对于ROS1，其官方支持的最后版本是Noetic Ninjemys，主要支持Ubuntu 20.04。在树莓派5上，你有两种主流选择：

1. 树莓派OS（64位）：这是最原生的体验。ROS社区为树莓派OS维护了预编译的软件包仓库，安装过程相对直接，但可能不是最新的Ubuntu LTS基础。
2. Ubuntu Server 20.04/22.04 for Raspberry Pi：由Ubuntu官方提供镜像。在22.04上安装ROS1 Noetic可能需要从源码编译部分依赖，步骤稍复杂，但能获得更新的系统内核和软件库。

对于ROS2，情况则明朗得多。目前最新的长期支持版本是ROS2 Humble Hawksbill，其官方指定的平台就是Ubuntu 22.04。因此，为树莓派5刷入Ubuntu Server 22.04/24.04 LTS的镜像，是开启ROS2之旅最推荐、最顺畅的起点。Ubuntu 24.04对应的是ROS2 Jazzy Jalisco，但Humble作为LTS版本，拥有更长期的维护和更稳定的生态。

基础系统配置（以Ubuntu为例，两者通用）： 安装完系统后，第一件事是进行基础配置，这能避免后续很多网络和权限问题。

# 1. 更新系统软件源列表
sudo apt update && sudo apt upgrade -y

# 2. 设置时区（可选，建议设置为本地时间）
sudo timedatectl set-timezone Asia/Shanghai

# 3. 启用SSH（方便无头模式运行）
sudo systemctl enable ssh
sudo systemctl start ssh

# 4. 安装一些基础开发工具
sudo apt install -y build-essential cmake git curl wget

完成这些步骤后，你的树莓派5就有了一个干净、高效的开发基础。接下来，我们将分别走入ROS1和ROS2的安装世界，你会发现它们的流程和遇到的“坑”截然不同。

3. ROS1 Noetic 在树莓派5上的安装与深度配置

如果你选择了ROS1 Noetic，安装过程更像是一次“传统技艺”的体验。下面的步骤基于Ubuntu 20.04/22.04系统。

3.1 配置软件源与安装核心包

首先，需要将ROS的官方软件源添加到系统中。

# 设置软件源，接受ROS软件包
sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'

# 添加ROS软件源的GPG密钥
curl -s https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | sudo apt-key add -

# 更新软件源缓存
sudo apt update

接下来是安装。对于树莓派，通常不需要完整的桌面环境（Desktop-Full），那会包含大量GUI工具，占用过多资源。我们选择更轻量的ros-noetic-ros-base。

# 安装ROS Noetic基础版（包含通信库、工具、机器人通用库）
sudo apt install -y ros-noetic-ros-base

安装完成后，一个至关重要的步骤是初始化rosdep。这个工具用于安装ROS包的系統依赖。

sudo rosdep init
rosdep update

3.2 环境变量配置与经典“坑点”

ROS1严重依赖环境变量来定位其安装路径。每次打开新的终端，都需要“激活”ROS环境。

# 将以下行添加到你的 ~/.bashrc 文件末尾
echo "source /opt/ros/noetic/setup.bash" >> ~/.bashrc
# 立即生效
source ~/.bashrc

现在，你可以尝试运行ROS的核心——roscore了。在终端输入roscore，如果看到它开始发布日志信息，恭喜你，ROS1的核心系统已经成功运行。

然而，树莓派用户常会遇到一个与Python路径相关的经典问题，尤其是在使用catkin_make编译自己的工作空间时。这个问题通常表现为与catkin_pkg模块相关的CMake错误。

问题根源：树莓派系统或用户可能安装了多个Python版本（如python2.7, python3.8, python3.9），而ROS Noetic虽然主要使用Python3，但其某些底层脚本或你从旧项目继承的代码可能仍存在兼容性问题。CMake在配置过程中调用Python解释器时，可能指向了错误的版本或一个缺少必要包的环境。

解决方案不是简单安装catkin_pkg，而是确保构建环境的纯净与一致性：

# 1. 首先，为你的ROS开发创建一个专用的Python虚拟环境（强烈推荐）
sudo apt install -y python3-venv python3-pip
cd ~
python3 -m venv ros_noetic_venv
source ~/ros_noetic_venv/bin/activate

# 2. 在虚拟环境中安装ROS构建所需的核心Python包
pip install catkin-pkg rospkg empy

# 3. 创建你的工作空间
mkdir -p ~/catkin_ws/src
cd ~/catkin_ws

# 4. 在激活的虚拟环境下，使用明确的Python解释器路径进行编译
catkin_make -DPYTHON_EXECUTABLE=$(which python3)

使用虚拟环境的好处是隔离了ROS项目所需的Python依赖，避免了与系统其他Python应用的冲突。编译成功后，别忘了将工作空间的setup.bash也加入环境变量。

echo "source ~/catkin_ws/devel/setup.bash" >> ~/.bashrc

4. ROS2 Humble 在树莓派5上的安装与新范式体验

ROS2的安装流程体现了其现代化和标准化的一面。我们以Ubuntu 22.04和ROS2 Humble为例。

4.1 安装过程：简洁与标准化

首先，依然是设置软件源和密钥。ROS2的仓库结构更加清晰。

# 确保Ubuntu Universe仓库已启用
sudo apt install -y software-properties-common
sudo add-apt-repository universe

# 添加ROS2 GPG密钥
sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg

# 添加ROS2软件源
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(source /etc/os-release && echo $UBUNTU_CODENAME) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null

# 更新并安装ROS2基础版
sudo apt update
sudo apt install -y ros-humble-ros-base

ROS2的rosdep初始化与ROS1类似：

sudo rosdep init
rosdep update

环境变量的设置方式也一致：

echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc
source ~/.bashrc

现在，你可以体验ROS2无需roscore的便利了。直接打开两个终端，分别运行：

# 终端1：发布一个话题
ros2 run demo_nodes_cpp talker

# 终端2：订阅同一个话题
ros2 run demo_nodes_py listener

你会看到两个节点自动发现彼此并开始通信，期间没有启动任何中心服务。这种去中心化的体验，正是ROS2架构优势的直接体现。

4.2 工作空间与构建系统：从catkin到colcon

ROS2彻底告别了catkin_make，采用了更强大、更模块化的colcon构建工具。创建和编译工作空间的流程有了新变化。

# 1. 安装colcon及其常用扩展
sudo apt install -y python3-colcon-common-extensions

# 2. 创建ROS2工作空间
mkdir -p ~/ros2_ws/src
cd ~/ros2_ws

# 3. 放入你的功能包源码（例如，从GitHub克隆一个）
# git clone https://github.com/ros2/examples src/examples -b humble

# 4. 解析并安装依赖（非常重要的一步！）
rosdep install -i --from-path src --rosdistro humble -y

# 5. 编译工作空间
colcon build

colcon build命令会为工作空间中的每个包单独创建构建目录（build/）、安装目录（install/）和日志目录（log/）。编译成功后，你需要“激活”的是install目录下的环境。

# 激活当前工作空间的安装结果
source ~/ros2_ws/install/setup.bash
# 也可以将其加入.bashrc，但注意多个工作空间的source顺序

4.3 可能遇到的挑战与解决思路

在树莓派5上安装ROS2，最常见的挑战来自于资源限制和依赖冲突。

• 内存不足导致编译失败：colcon build默认会并行编译多个包，这可能耗尽树莓派5的8GB内存。解决方法是为colcon设置并行任务数。

  # 使用2个并行任务进行编译，减少内存压力
  colcon build --parallel-workers 2
  # 或者，更彻底地，先编译单个包
  colcon build --packages-select <your_package_name>
  

• Python包版本冲突：ROS2 Humble基于Python 3.10。如果你通过pip在系统全局或用户目录安装了某些包的冲突版本，可能会引发问题。同样，使用Python虚拟环境是最佳实践。

  # 为ROS2项目创建独立的虚拟环境
  python3 -m venv ~/ros2_humble_venv
  source ~/ros2_humble_venv/bin/activate
  # 在虚拟环境中安装必要的pip包，如numpy、opencv-python-headless等
  pip install numpy opencv-python-headless
  # 然后在这个虚拟环境中运行colcon build和你的ROS2节点
  

5. 实战场景对比与性能考量

理论说再多，不如实际跑一跑。我们设计两个简单的实战场景，在树莓派5上对比ROS1和ROS2的表现。

场景一：单节点CPU/内存占用与通信延迟 我们编写一个简单的消息发布-订阅测试。在ROS1中，使用rospy；在ROS2中，使用rclpy。通过top命令和rostopic hz / ros2 topic hz 来观察节点进程的资源占用和消息传输频率稳定性。

在我的树莓派5（Ubuntu 22.04， 8GB RAM）的简单测试中，运行一个基本的字符串消息发布节点（10Hz）：

• ROS1 Noetic：Python节点内存占用约45MB。在Master稳定运行时，延迟抖动较小。但启动和关闭Master有额外开销。
• ROS2 Humble：Python节点内存占用约55MB。直接启动节点，无需Master，整体感觉更“轻快”。在QoS设置为默认“Best Effort”时，延迟与ROS1相当；若设置为“Reliable”，会有更高的一致性保证，但可能引入微小延迟。

场景二：网络中断恢复能力 这是一个能凸显ROS2架构优势的场景。我们让两个节点（发布者和订阅者）建立通信，然后手动断开树莓派的Wi-Fi或以太网连接，等待10秒后再恢复。

• ROS1：网络恢复后，订阅者通常无法自动重连并恢复接收消息，除非重启节点或重新初始化连接。这是因为其基于TCP的连接在断开后需要Master重新协调，而这个过程不是自动的。
• ROS2：得益于DDS的发现机制，在网络恢复后，发布者和订阅者能够自动重新发现彼此并恢复通信，无需任何干预。这对于移动机器人或网络不稳定的环境至关重要。

场景三：多机通信配置复杂度 在多台树莓派构建机器人集群时：

• ROS1：需要在每台机器上正确设置ROS_MASTER_URI（指向Master主机）和各自的ROS_HOSTNAME。配置繁琐，且Master主机成为单点故障。
• ROS2：原则上，只要所有机器在同一个局域网内，并正确设置了ROS_DOMAIN_ID环境变量（默认是0），它们就能自动发现。配置极其简单，且无中心故障点。

注意：ROS2的自动发现虽然方便，但在大型网络或特定安全要求下，可能需要配置DDS的发现协议（如Simple Discovery Protocol）或使用安全功能。对于绝大多数中小型树莓派项目，默认设置已经完全足够。

经过以上从理念、安装、配置到实战的层层剖析，选择的天平应该已经向你心中倾斜。ROS1像一位经验丰富、拥有庞大工具库的老工匠，能帮你快速实现想法，但工具间耦合较紧，有些设计已显陈旧。ROS2则像一套模块化、高可靠性的现代工业流水线，学习曲线初期可能稍陡，但它为应对复杂、真实的世界而设计。

对于树莓派5的玩家，我的个人建议是：如果你的项目是教育、快速原型验证，或者严重依赖ROS1独占的经典算法包，那么选择ROS1 Noetic，并善用Python虚拟环境来规避依赖冲突。如果你是启动一个面向未来、考虑多机协作或产品化的新项目，那么毫不犹豫地拥抱ROS2 Humble，从Ubuntu 22.04开始你的旅程，并尽早适应colcon和基于DDS的思维模式。 技术选型没有绝对的对错，只有最适合当前项目阶段和团队能力的方案。希望这篇对比能帮你拨开迷雾，在树莓派5上更自信地开启你的机器人创作。