1.2 环境安装与首次验证

1.2 环境安装与首次验证

本节摘要：安装 ROS2 本身只要几分钟，真正决定后续效率的是装完之后的环境验证与工作空间组织。本节承接 1.1 的重铸逻辑，给出桌面完整版的安装步骤、五项首次验证动作及其健康判据，并讲清 colcon 工作空间的目录语义与 overlay 叠加机制。这是全册所有动手环节的运行基座。

为什么要"验完才信"

1.1 节说过，ROS2 通信是去中心化的——这带来一个安装期的副作用：环境坏了往往不报错，而是"安静地不工作"。ROS1 时代 roscore 起不来会立刻尖叫，ROS2 里发现协议失败没有任何报警，两个终端看起来都在正常运行，只是互相看不见。所以这一节的重心不在安装命令，而在那套五项验证：花五分钟确认环境可信，能省掉后面章节里数小时的"玄学排查"。

一、安装：发行版与安装方式的选择

发行版选长期支持版。本册以 Humble 为基准（Ubuntu 22.04），Jazzy（Ubuntu 24.04）命令完全一致。滚动版别用在真机上——你要的是能跑半年不变的环境，不是新特性。

推荐用 apt 装桌面完整版，它自带 RViz、turtlesim、demo 节点，正是验证环节需要的全部道具：

# 添加软件源与密钥后（官方源设置步骤见发行版文档）
sudo apt install ros-humble-desktop
# 底层构建工具，工作空间编译必用
sudo apt install python3-colcon-common-extensions
# 环境变量：建议写进 bashrc，让每个新终端自动生效
echo "source /opt/ros/humble/setup.bash" >> ~/.bashrc
source ~/.bashrc
​

第三行的 source 是新手第一坑。ROS2 的命令、消息查找全依赖环境变量，每个终端会话独立生效——你在 A 终端 source 了，B 终端依然找不到 ros2 命令。写进 bashrc 是一劳永逸的做法，但要注意：后续我们自己建的工作空间也要 source，且顺序必须是"先底层安装、后自己的工作空间"，后者会覆盖前者的同名包。

第二种方式是从源码编译，只在两种场景需要：你要改 ROS2 本身的代码，或目标平台（如某些 ARM 板）没有预编译包。代价是首次编译约一小时与一长串依赖问题。真机开发板常见的做法是交叉编译或直接用厂商预装好的镜像，别在板子上从零编译桌面版。

二、五项首次验证

安装报告成功不等于环境可用。按下面的顺序验，每项都有明确的健康判据。

# 验证一：命令行入口与版本
ros2 --help          # 判据：打印命令分组，不报"找不到命令"
ros2 doctor          # 判据：汇总检查项，警告可容忍，ERROR 必须处理

# 验证二：自带小海龟仿真跑起来
ros2 run turtlesim turtlesim_node      # 判据：弹出蓝色窗口

# 验证三：另开终端，遥控小海龟（本终端无需再 source，若已写入 bashrc）
ros2 run turtlesim turtle_teleop_key   # 判据：方向键控制海龟移动

# 验证四：验证系统自检的话题数据流
ros2 topic list                        # 判据：至少看到 /turtle1/cmd_vel
ros2 topic echo /turtle1/pose --once   # 判据：打印一帧位姿后退出

# 验证五：demo 双节点跨终端通信
ros2 run demo_nodes_cpp talker
ros2 run demo_nodes_cpp listener       # 判据：listener 打印 I heard
​

五项验证各自覆盖一层。验证一查的是环境变量与 Python 入口；验证二、三查的是图形栈与包查找；验证四确认话题数据流与消息序列化正常；验证五最有分量——两个独立进程通过 DDS 发现彼此并完成一次可靠传输，这条链路通了，说明发现协议、序列化、网络栈全部健康。这五项里任何一项不达标，先解决再往后学，否则后面每一章的问题都会混入"环境本身就有病"的干扰项。

ros2 doctor 值得多说一句。它会检查环境变量、网络配置、RMW 实现一致性等十几项，输出分 WARN 与 ERROR 两级。WARN 常见的是"非默认 RMW"之类，可暂不理会；ERROR 里最典型的是多网卡导致组播走错口，处理办法是设置 ROS_IPV6 或禁用多余网卡，这个问题在 1.3 的排错实录里还会正面遭遇。

图 1-1：首次环境验证五道关卡

三、工作空间：你自己的代码住在哪

验证用的是系统包，开发用的是工作空间。colcon 约定的目录语义值得逐个记牢：src 放源码包，build 放编译中间产物，install 放编译结果与环境钩子，log 放编译日志。日常只需要关心 src 与 install 两个目录。

mkdir -p ~/ros2_ws/src && cd ~/ros2_ws/src
# 创建一个 Python 功能包：包名用小写下划线
ros2 pkg create my_first_pkg --build-type ament_python \
  --dependencies rclpy std_msgs
cd ~/ros2_ws
colcon build                       # 全量编译
source install/setup.bash          # 叠加到环境上（覆盖同名系统包）
ros2 run my_first_pkg my_node      # 你的节点可以跑了
​

包名的组织习惯值得提前立规矩：功能包名全小写加下划线，节点名、话题名同理。等项目长到十几个包，命名混乱的代价会指数级上升，这是第 8.5 节工程化标准的前奏。overlay 机制则是多项目并行的关键：先 source 底层、再 source 工作空间，同名包后者生效；你可以同时维护一个稳定版工作空间与一个实验版工作空间，按需叠加，互不污染。

⚠️ 常见坑：colcon build 必须在工作空间根目录执行，在 src 里执行会把编译产物撒进源码树；编译报"找不到包"时，八成是当前终端没有 source 底层的 setup.bash。

本节要点回顾

• 装完必验：五项验证覆盖环境变量、图形栈、输入链路、数据流与 DDS 发现，全绿才算环境可信；
• source 的会话隔离：每个终端独立生效，顺序是先系统后工作空间；
• colcon 四目录语义：src 源码、build 中间、install 结果、log 日志，编译在根目录执行；
• overlay 叠加规则：后 source 的同名包覆盖前者，这是并行开发与版本管理的基础；
• 发行版选长期支持版，源码编译只在改源码或无预编译包时使用。

下一节就用这个刚验证过的环境，故意制造一次"收不到消息"，把排错方法论立起来。