ROS2仿真到真机实战：激光雷达SLAM与导航开发-平芜编程栈

开篇先说实话：很多人在学习 ROS2 的时候都会遇到一个很典型的断层——仿真里跑得好好的机器人，一放到真机上就各种“不听话”；要么是话题对不上，要么是驱动没启动，要么是传感器数据一上来就刷屏把节点卡死。这篇文章就是围绕“仿真 + 真机”这条完整链路来写的：从零开始搭建 Ubuntu + ROS2 环境，用 VSCode 做远程开发，在 Gazebo 里搭建带激光雷达的机器人仿真环境，再把同一个思路移植到真机上，实现传感器数据读取、速度控制、SLAM 建图与导航。无论你是准备入门 ROS2 的学生，还是已经在做机器人项目、想系统梳理一遍开发流程的工程师，这篇文章都能提供一套可以参考的落地路径。

1. ROS2 仿真与真机的整体认知

1.1 什么是 ROS2，它解决什么问题

ROS2（Robot Operating System 2）是机器人领域的分布式通信框架，它不是传统意义上的操作系统，而是运行在 Linux 等系统之上的一套中间件。它负责解决机器人的核心问题：多个模块之间如何通信。

一个完整的机器人通常包含：

传感器模块：激光雷达、IMU、摄像头、编码器
决策模块：SLAM、导航、路径规划、运动控制
执行模块：电机驱动、底盘控制板

如果没有统一的通信框架，每个模块都要自己写一套数据交换协议，模块之间耦合严重，代码也很难复用。ROS2 通过“话题（Topic）”“服务（Service）”“动作（Action）”三种通信方式，把各个模块解耦，每个模块只负责发布和订阅消息，整个系统的可维护性大幅度提升。

同时，ROS2 在 ROS1 的基础上改进了实时性、多机通信、安全性等底层设计，更适合现代机器人产品落地。目前很多高校实验室、创业团队和开源机器人项目都已经全面转向 ROS2。

1.2 仿真与真机的核心差异

很多人第一次从仿真切到真机时，最常见的困惑是：“仿真里明明能跑，为什么真机上就是不行？”

这里需要先明确一个概念：仿真和真机的差异，不在于“代码能不能跑”，而在于“环境感知和执行反馈完全不同”。

对比项	仿真环境	真机环境
传感器数据	理想化数据，噪声小	有噪声、有遮挡、有延迟
底盘控制	直接调用仿真接口即可	需要驱动层，涉及串口/通信协议
时间同步	仿真时间可控	系统时间受硬件性能影响
地图环境	重新加载模型即可	需要真实建图、保存、匹配
安全风险	程序崩溃无影响	可能撞墙、损坏设备

所以，聪明的做法不是“仿真一套代码、真机一套代码”，而是从架构上把代码分成几层：

驱动层：负责读取真实传感器数据，或从仿真环境接收模拟数据。
算法层：SLAM、定位、导航、避障，这一层不关心数据来自仿真还是真机。
控制层：接收速度指令，输出到底盘。

只要接口统一，算法层可以完全不修改，切换的只是驱动层的数据来源。这也是“仿真 + 真机”实战中最重要的一条设计原则。

1.3 一套代码从仿真到真机的关键设计

要做到一套代码兼容仿真和真机，核心是统一话题接口。比如：

激光雷达数据统一发到/scan
里程计数据统一发到/odom
速度指令统一订阅/cmd_vel

仿真环境下，Gazebo 插件会发布/scan和/odom，我们通过cmd_vel控制仿真底盘；真机环境下，激光雷达驱动节点发布/scan，底盘驱动节点读取/odom并订阅/cmd_vel。对上层导航算法来说，它看到的接口是完全一致的。

后面整个实战过程都会围绕这个思路来展开。

2. 环境准备与版本说明

2.1 操作系统与 ROS2 版本选型

ROS2 目前主要有几个常用发行版：

Foxy Fitzroy：支持 Ubuntu 20.04，早期稳定版本
Galactic Geochelone：过渡版本，支持 Ubuntu 20.04
Humble Hawksbill：支持 Ubuntu 22.04，长期支持版本，社区资料较多
Iron Irwini：较新的非 LTS 版本
Jazzy Jalisco：支持 Ubuntu 24.04，较新版本

以 2025 年的生态来看，如果你使用的是 Ubuntu 22.04，Humble 是比较稳妥的选择；如果使用 Ubuntu 24.04，可以关注 Jazzy。版本需要根据你的实际系统和项目依赖来定，本文示例以“Ubuntu 22.04 + ROS2 Humble”为常见环境，但重点不在某个版本，而在于搭建流程和调试思路。

2.2 ROS2 安装方式：官方 apt 与鱼香ROS

ROS2 的安装通常有两种方式：

方式一：官方 apt 源安装

先配置 apt 源，再安装核心组件。大致流程如下：

sudo apt update sudo apt install software-properties-common sudo add-apt-repository universe sudo apt update sudo apt install ros-humble-desktop

安装完成后需要 source 环境：

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

方式二：使用鱼香ROS一键安装

如果你在下载和配置源时经常遇到网络超时、依赖解析失败，可以使用鱼香ROS提供的一键安装脚本。它会自动完成换源、依赖安装、ROS2 安装和环境变量配置。

wget http://fishros.com/install -O fishros && . fishros

执行后会出现一个交互菜单，选择对应选项即可。这种方式对新手比较友好，能省去不少环境配置的坑。但需要注意，一键脚本会修改系统源和安装较多依赖，建议在专用虚拟机或开发机上执行，避免影响其他开发环境。

2.3 工作空间与示例项目结构

安装完成后，建议先建立一个标准的工作空间。之后所有代码都在这个目录里管理。

mkdir -p ~/ros2_ws/src cd ~/ros2_ws colcon build source install/setup.bash

src目录下放功能包，colcon build是 ROS2 的编译工具。如果提示找不到colcon，可以先安装：

sudo apt install python3-colcon-common-extensions

3. 远程开发环境搭建

3.1 为什么推荐远程开发

机器人项目的开发环境通常和运行环境是分开的。你的日常电脑可能是 Windows 或 macOS，而机器人本体运行的是 Ubuntu，上面挂着激光雷达、底盘驱动和一堆 ROS2 节点。

如果每次都跑到机器人主机上插显示器、接键盘开发，效率极低。远程开发的核心思路是：

代码放在机器人主机（Ubuntu）上
本地 IDE 通过 SSH 远程打开代码
编译、运行、看日志都在远程主机上执行

这样既保证代码运行环境和机器人一致，又保留了本地 IDE 的编辑体验。

3.2 VSCode Remote-SSH 连接 Ubuntu

推荐使用 VSCode 的 Remote-SSH 插件，操作很简单：

在 VSCode 扩展市场安装 “Remote - SSH”。
在本地命令行执行ssh ubuntu用户名@机器人IP地址，确认 SSH 能连通。
在 VSCode 中按Ctrl+Shift+P，输入 “Remote-SSH: Connect to Host”，选择或添加 SSH 主机。
连接成功后，左侧资源管理器会显示远程主机的文件系统，直接打开~/ros2_ws即可。

连接之后，VSCode 会自动在远程主机上安装一个“远程服务器”，本地安装的插件需要重新选择“在 SSH 主机中安装”，比如 Python 插件、CMake 插件、ROS 插件等。

这里有一个小技巧：如果你的机器人主机和开发电脑在同一个局域网内，直接使用局域网 IP 连接；如果跨网络，就需要配置端口转发或使用内网穿透工具，实际项目中更推荐的还是局域网直连，稳定且延迟低。

3.3 远程可视化：rviz2 与 Gazebo 图形界面

远程开发时经常遇到一个问题：机器人主机上启动了rviz2，但在本地看不到图形界面。

解决办法有以下几种：

方法一：本地安装 rviz2，订阅机器人主机的 ROS2 话题

在本地电脑也安装对应版本的 ROS2，然后配置ROS_DOMAIN_ID和 DDS 发现机制，让本地rviz2作为第二台 ROS2 设备接入机器人系统。

方法二：使用 X11 转发

在 SSH 命令中增加-X参数：

ssh -X 用户名@机器人IP

然后在远程终端启动rviz2，图形界面会转发到本地。这种方式对网络要求较高，通常需要局域网环境。

方法三：使用 VNC 或远程桌面

在机器人主机上安装 VNC 服务，通过 VNC viewer 连接到机器人桌面，直接操作完整的 Linux 图形界面。适合可视化组件较多、转发性能不足的场景。

我个人的习惯是：日常开发用 VSCode Remote-SSH，调试和可视化用 VNC，两者不冲突。

4. 仿真环境搭建与传感器仿真

4.1 创建 ROS2 工作空间与功能包

仿真环境的起点是创建一个机器人功能包，后面所有模型、启动文件、节点都放在这个包里。

cd ~/ros2_ws/src ros2 pkg create robot_sim --build-type ament_python

这条命令会生成一个标准的 Python 功能包，包含package.xml、setup.py、setup.cfg和robot_sim目录。

为了让目录结构更清晰，我们再手动创建几个子目录：

cd ~/ros2_ws/src/robot_sim mkdir -p urdf launch config

urdf：存放机器人模型文件
launch：存放 launch 启动文件
config：存放 rviz 配置、参数文件

4.2 使用 Xacro 描述机器人模型

Xacro 是 ROS 中常用的一种“宏定义 + 参数化”的 URDF 扩展格式。简单说，URDF 文件里要写的重复 XML 片段，可以用 Xacro 简化。

下面是一个最简单的两轮差速底盘描述，包含一个车体和一个二维激光雷达：

<!-- 文件路径：~/ros2_ws/src/robot_sim/urdf/robot.xacro --> <?xml version="1.0"?> <robot name="robot_base" xmlns:xacro="http://www.ros.org/wiki/xacro"> <xacro:macro name="robot_base_macro"> <!-- 车体 --> <link name="base_link"> <inertial> <mass value="2.0"/> <inertia ixx="0.01" ixy="0.0" ixz="0.0" iyy="0.01" iyz="0.0" izz="0.01"/> </inertial> <visual> <geometry> <box size="0.4 0.3 0.1"/> </geometry> <material name="blue"/> </visual> <collision> <geometry> <box size="0.4 0.3 0.1"/> </geometry> </collision> </link> <!-- 激光雷达 --> <link name="laser_link"> <visual> <geometry> <cylinder radius="0.05" length="0.05"/> </geometry> </visual> </link> <!-- 雷达固定在车体上方 --> <joint name="laser_joint" type="fixed"> <parent link="base_link"/> <child link="laser_link"/> <origin xyz="0 0 0.15" rpy="0 0 0"/> </joint> </xacro:macro> <xacro:robot_base_macro/> </robot>

这个文件定义了机器人模型的两个刚体和一个关节：base_link是底盘中心，laser_link是雷达安装位置，两个刚体通过laser_joint固定连接。

4.3 在 Gazebo 中加载机器人并添加激光雷达

要让 Gazebo 加载这个模型，并且在仿真中产生激光雷达数据，需要在 launch 文件里做几件事：

启动 Gazebo 空世界
把机器人模型加载到参数服务器
调用 Gazebo 的 spawn 服务，把模型生成到仿真世界中
给模型添加传感器插件

常用的传感器插件是gazebo_plugins中的GaussianNoise激光插件。为了演示，我们直接使用一个对新手友好的 libgazebo_ros2_laser 插件。

修改robot.xacro，在laser_link中加入传感器描述：

<!-- 文件路径：~/ros2_ws/src/robot_sim/urdf/robot.xacro 中 laser_link 部分增加 --> <gazebo reference="laser_link"> <sensor type="ray" name="laser_sensor"> <pose>0 0 0 0 0 0</pose> <visualize>true</visualize> <update_rate>10</update_rate> <ray> <scan> <horizontal> <samples>360</samples> <resolution>1</resolution> <min_angle>0.0</min_angle> <max_angle>6.283185307</max_angle> </horizontal> </scan> <range> <min>0.12</min> <max>10.0</max> <resolution>0.01</resolution> </range> </ray> <plugin name="laser_controller" filename="libgazebo_ros2_ray_sensor.so"> <ros> <remapping>~/out:=scan</remapping> </ros> <output_type>sensor_msgs/msg/LaserScan</output_type> </plugin> </sensor> </gazebo>

这段配置的作用是把仿真雷达数据发布到/scan话题，扫描角度从 0 到 2π（即 360 度），每圈采样 360 个点，探测距离 0.12 米到 10 米。这些参数可以按实际需求调整。

4.4 启动仿真并查看 /scan 话题

接下来写一个 launch 文件，把系统一次性拉起来。

# 文件路径：~/ros2_ws/src/robot_sim/launch/sim.launch.py import os from launch import LaunchDescription from launch.actions import ExecuteProcess from launch_ros.actions import Node from ament_index_python.packages import get_package_share_directory def generate_launch_description(): pkg_share = get_package_share_directory('robot_sim') urdf_path = os.path.join(pkg_share, 'urdf', 'robot.xacro') return LaunchDescription([ ExecuteProcess( cmd=['gazebo', '--verbose', '-s', 'libgazebo_ros_factory.so'], output='screen' ), Node( package='robot_state_publisher', executable='robot_state_publisher', parameters=[{'robot_description': open( urdf_path, 'r').read()}], output='screen' ), Node( package='gazebo_ros', executable='spawn_entity.py', arguments=['-entity', 'robot_base', '-x', '0', '-y', '0', '-z', '0.1'], output='screen' ) ])

启动之前，先编译安装功能包：

cd ~/ros2_ws colcon build --packages-select robot_sim source install/setup.bash

然后启动仿真：

ros2 launch robot_sim sim.launch.py

在另一个终端查看话题列表：

ros2 topic list

如果配置正确，能看到/scan话题。打印几帧数据：

ros2 topic echo /scan --once

如果一切正常，你会看到range数组和angle_min、angle_max等字段，说明仿真激光雷达已经在工作。

5. 真机落地实操：从传感器到节点

5.1 真机硬件选型与接线

从仿真迈向真机，第一步是明确硬件。这里以最常见的“树莓派/工控机 + 差速底盘 + 二维激光雷达”组合为例。

主控：树莓派 4B 或者带有 Ubuntu 系统的工控机
底盘：带编码器的两轮差速底盘，支持通过串口或 CAN 接收速度指令
激光雷达：常见的低成本二维激光雷达，例如 RPLIDAR A1、A2 或其他 360 度扫描雷达，具体型号需要以你手上的设备为准
电源：为保证稳定供电，建议主控和底盘驱动分开供电，共地连接

接线时要注意：雷达的 USB 转串口线插在主控上，底盘控制板的通信线也接在主控上，通信接口不要混插。很多新手遇到的“数据读不到”，最后查出来的原因往往是 USB 端口权限问题。

USB 端口权限可以这样解决：

sudo usermod -aG dialout $USER

需要重新登录终端，让用户组生效。

5.2 激光雷达驱动与数据读取

不同品牌的雷达驱动节点各不相同，但最终目标是一致的：把原始测距数据封装成sensor_msgs/msg/LaserScan消息，发布到/scan话题。

以常见的 RPLIDAR 系列为例，ROS2 社区中已经有对应的驱动包：

sudo apt install ros-humble-rplidar-ros

启动雷达驱动：

ros2 run rplidar_ros rplidar_composition

然后验证数据：

ros2 topic echo /scan --once

如果你的雷达不是 RPLIDAR，也没关系，思路是一样的：

找官方或社区提供的 ROS2 驱动包
编译安装
启动驱动节点，确认/scan有数据

这里要注意，不同雷达的帧率、扫描频率、测距范围可能不同。比如有的雷达是 5Hz，有的可以达到 10Hz 以上，这些参数会影响后续 SLAM 和导航的效果，建议在驱动配置中统一确认。

5.3 订阅 /scan 并发布速度指令

有了雷达数据之后，下一步是写一个节点，把底层底盘控制起来。

底盘控制通常使用geometry_msgs/msg/Twist消息，发布到/cmd_vel。Twist消息包含线速度和角速度，底盘收到后会解析成左右轮差速。

下面是一个最简单的控制节点示例，让机器人原地旋转，实现一个自动避障的雏形：

# 文件路径：~/ros2_ws/src/robot_sim/robot_sim/avoidance.py import rclpy from rclpy.node import Node from sensor_msgs.msg import LaserScan from geometry_msgs.msg import Twist class AvoidanceNode(Node): def __init__(self): super().__init__('avoidance_node') self.publisher = self.create_publisher(Twist, '/cmd_vel', 10) self.subscription = self.create_subscription( LaserScan, '/scan', self.scan_callback, 10) self.subscription self.min_distance = 0.5 def scan_callback(self, msg): # 取前方一定角度范围内的最小距离 front_ranges = list(msg.ranges[0:30]) + list(msg.ranges[-30:]) valid_ranges = [r for r in front_ranges if r > 0.0] if len(valid_ranges) == 0: return min_range = min(valid_ranges) cmd = Twist() if min_range < self.min_distance: cmd.angular.z = 0.5 cmd.linear.x = 0.0 else: cmd.linear.x = 0.2 cmd.angular.z = 0.0 self.publisher.publish(cmd) def main(args=None): rclpy.init(args=args) node = AvoidanceNode() rclpy.spin(node) node.destroy_node() rclpy.shutdown() if __name__ == '__main__': main()

这段代码的逻辑是：读取/scan数据，取机器人前方 30 度范围内的最小距离，如果小于 0.5 米就原地旋转，否则前进。实际项目中避障算法会更复杂，但这个示例能帮你快速验证“传感器 -> 算法 -> 底盘”的完整链路。

5.4 仿真与真机的切换策略

前面的模拟节点接收的是仿真雷达数据，现在你的雷达是真实雷达，但代码不需要改动，因为话题接口是一样的。

唯一需要注意的驱动差异是：

数据来源	谁是发布者	谁接收
仿真雷达	Gazebo 激光插件	avoidance / SLAM / Nav2
真机雷达	rplidar_ros 驱动节点	avoidance / SLAM / Nav2

因此，要做的只是在真机上启动雷达驱动节点，而不是 Gazebo。启动避障节点时，它的算法逻辑和话题接口完全复用。

这个设计思路，就是前面反复强调的“驱动层隔离”。工程结构上，建议把不同平台的启动文件分开：

launch/ ├── sim.launch.py # 仿真启动 ├── real.launch.py # 真机启动 └── common.launch.py # 算法节点启动

common.launch.py只启动避障、SLAM、导航这类不关心数据来源的节点，sim.launch.py和real.launch.py只负责启动数据源。这样切换平台时，只需要选择不同的 launch 文件。

6. 基于激光雷达的定位与导航初探

6.1 激光雷达 SLAM 的基本流程

当底盘可以接收速度指令、雷达能发布/scan数据后，就可以进入机器人最核心的应用——SLAM 建图。

SLAM 这个过程可以通俗理解为：机器人一边移动，一边把激光雷达扫描到的环境特征拼接起来，同时估算自己在地图中的位置。

常见的 2D SLAM 工具有：

slam_toolbox：ROS2 社区常用，适合二维激光雷达建图，配置简单
Cartographer：Google 开源，适合复杂环境，但安装和调参门槛较高
GMapping：早期方案，目前在新项目中较少使用

对于入门和中小型室内机器人，我比较推荐slam_toolbox，因为它参数较少、文档清晰，且对 ROS2 支持良好。

6.2 使用 slam_toolbox 构建地图

安装：

sudo apt install ros-humble-slam-toolbox

启动 SLAM 节点时，需要提供激光雷达话题、里程计话题和机器人坐标系关系。最简单的启动方式是在命令行直接传参数：

ros2 run slam_toolbox async_slam_toolbox_node \ --ros-args \ -p use_sim_time:=false \ -p scan_topic:=/scan \ -p odom_frame:=odom \ -p base_frame:=base_link \ -p map_frame:=map

如果你在仿真中测试，需要把use_sim_time改为true，让节点使用仿真时间。

启动 SLAM 之后，通过 rviz2 可以直观地看到地图构建过程：

rviz2

在 rviz2 中手动添加Map显示，话题选择/map，就能看到激光雷达扫描出来的环境地图。此时需要控制机器人移动，让雷达覆盖整个空间。手动控制可以用下面这样的命令：

ros2 topic pub /cmd_vel geometry_msgs/msg/Twist \ "{linear: {x: 0.2, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.1}}"

移动过程中，地图会一点点扩展。当建图完成后，保存地图：

ros2 run nav2_map_server map_saver_cli -f ~/map

这会生成map.pgm和map.yaml两个文件，分别是地图图片和地图描述文件。

6.3 使用 Nav2 做导航（概念性说明）

有了地图，下一步就是导航。ROS2 中常用的是 Nav2 导航栈。

Nav2 的工作流程可以简化成三步：

接收目标点（来自手动指定或上层调度）
结合地图和传感器数据做全局路径规划
发布/cmd_vel控制底盘移动，同时避障

启动 Nav2 之前，需要准备几个参数文件：地图文件、代价地图参数、规划器参数、控制器参数。这些参数文件官方模板都有，直接使用并修改关键项即可。

ros2 launch nav2_bringup bringup_launch.py \ map:=~/map.yaml

在实际运行中，Nav2 需要/scan、/odom、/tf等话题。如果你的底盘驱动没有发布可靠的里程计，定位效果会大打折扣。这是 Nav2 落地中最容易失败的环节，建议在接入 Nav2 之前先确认odom和tf的稳定性。

导航是一个比较大的话题，这篇文章里先不做过度展开。建议先把 SLAM 建图和底层控制跑通，再逐步研究 Nav2 的参数调整。

7. 常见问题与排查思路

在实际动手过程中，几乎每个人都会遇到几个“正常但很头疼”的问题。下面整理了一些高频问题，按排查顺序给出思路。

问题现象	常见原因	解决思路
`ros2`命令找不到	环境变量未 source	执行`source /opt/ros/humble/setup.bash`，并添加到`.bashrc`
`colcon build`报错找不到包	依赖包未安装	检查`package.xml`中的`<depend>`，逐个安装缺失依赖
仿真中`/scan`没有数据	模型没加载或插件配置错误	检查 Gazebo 中是否生成了模型，查看启动日志中的插件报错
真机雷达 USB 读不到数据	权限不足或驱动不对	添加用户到`dialout`组，重新插拔 USB，确认设备节点是`ttyUSB0`还是`ttyACM0`
`tf`找不到坐标变换	缺失 static transform publisher	在 launch 中增加`robot_state_publisher`或手动发布`odom -> base_link`
SLAM 地图偏移严重	里程计不准或时间不同步	检查`use_sim_time`参数；真机需要标定轮距和编码器
VSCode Remote-SSH 连接慢	DNS 回退或服务配置问题	在 SSH 配置中设置`ServerAliveInterval 60`，关闭本地代理变量
Nav2 导航不走直线	控制器参数不合适	调整`controller_server`的 PID 参数，检查速度限制和加速度限制

除了表格里的问题，我再补充几个实战中非常关键的排查要点。

第一个是“先看话题，再看参数”。

无论遇到什么功能异常，先确认话题有没有数据、频率是否正常：

ros2 topic hz /scan ros2 topic info /scan

ros2 topic hz会持续打印话题发布频率。如果频率是 0，说明发布端有问题；如果频率突然变成 0，大概率是节点崩溃或通信中断。

第二个是“多看日志，少猜原因”。

ROS2 的日志通常可以通过RMW_IMPLEMENTATION和RCUTILS_LOG_LEVEL调整。默认的 error 和 warn 级别已经能暴露大部分问题。启动节点时加上--verbose或查看终端输出，比盲目改参数更有效。

第三个是“仿真和真机分别保存配置”。

前面提到use_sim_time这个参数，仿真中必须设置为true，真机通常设置为false。如果不注意，真机上的 Nav2 会一直等待仿真时间，表现就是“地图不动、机器人不动、话题无输出”，排查很久才发现只是时间源的问题。

8. 最佳实践与工程建议

8.1 工程命名与目录规范

ROS2 功能包命名建议使用小写字母和下划线，不要使用大写。功能包和节点名称要有含义，例如robot_base_driver、laser_scan_filter、nav_goal_publisher。虽然 ROS2 对命名没有强制约束，但清晰的命名能减少沟通成本。

目录结构建议按职责划分：

src/ ├── robot_base_driver/ # 底盘驱动 ├── robot_lidar/ # 雷达驱动 ├── robot_sim/ # 仿真模型与启动文件 ├── robot_navigation/ # 导航相关节点 └── robot_msgs/ # 自定义消息

8.2 参数管理

不要把所有配置硬编码在源码里。传感器的波特率、底盘的最大速度、雷达的最小测量距离、SLAM 地图的参数，都应该放到 YAML 参数文件中。

在 launch 文件中加载参数：

Node( package='robot_navigation', executable='nav_goal_publisher.py', parameters=[os.path.join(pkg_share, 'config', 'nav_params.yaml')] )

参数文件的分支管理也很重要。如果同一个功能包要运行在多台机器人上，建议把设备独有参数放在独立 YAML 文件中，不修改公共模板。

8.3 日志与调试

真机调试过程中，ros2 topic echo和rqt_graph是两个非常好用的工具。rqt_graph可以用图形化的方式显示节点和话题之间的关系，特别适合在启动多个节点之后检查通信链路是否完整。

rqt_graph

如果界面比较混乱，可以选择只看/scan、/cmd_vel、/odom这几个关键话题，快速定位“谁发布了、谁订阅了、链路有没有断”。

8.4 安全与生产环境注意事项

真机调试，安全永远排在第一位。

第一次跑真机时，建议把底盘架起来，让轮子悬空，先验证速度指令是否正确，再落地测试。
使用手动急停开关，一旦发现机器人异常移动，立即切断底盘电源。
激光雷达属于光学传感器，避免阳光直射，防止传感器损坏。
编写代码时，对底盘速度做限幅，尤其是第一次测试时，线速度不要超过 0.2m/s。
涉及地图覆盖或系统参数修改时，先备份原文件和原地图。

8.5 代码可维护性

尽量把节点逻辑拆小。一个节点只做一件事，比如：

雷达驱动节点：只负责读雷达、发布/scan
底盘驱动节点：只负责读里程计、订阅速度指令
避障节点：只做逻辑判断，不关心底层数据来源
导航节点：只接收目标点，输出速度指令

节点之间用话题解耦，后续替换任何一个模块都不影响其他节点。

9. 从入门到落地的学习建议

到这里，你已经完整走了一遍“环境搭建 -> 远程开发 -> 仿真建模 -> 真机驱动 -> 激光雷达应用”的流程。

这篇文章中，你可以直接复用的部分包括：

ROS2 环境安装和问题处理思路
VSCode Remote-SSH 远程开发配置思路
一个带激光雷达的仿真机器人模型
一个能完成避障的 Python 节点
一套仿真与真机共用的代码结构

下一步可以继续学习的方向，我建议按顺序推进：

先把自己的底盘驱动彻底摸清楚，包括里程计消息、TF 变换。
在真机上跑通手动控制，确认cmd_vel -> 底盘 -> 编码器 -> odom闭环。
用 slam_toolbox 在真实环境建一张图，先不用追求精度，重点是流程。
研究 Nav2 导航参数，逐项理解代价地图、路径规划、控制器的作用。
逐步引入更复杂的传感器，比如 IMU、摄像头，做多传感器融合。

在动手过程中，建议把“用真机验证仿真逻辑”当作默认习惯。仿真能帮你快速验证算法思路，但最终所有问题都会在真机上暴露。每次都先在仿真里跑通流程，再上真机，可以大幅缩短调试周期并降低设备损坏的风险。

希望这篇文章能帮你少走一些弯路。如果你在配置或调试过程中遇到其他问题，欢迎在评论区留下具体现象和日志信息，我会根据实际情况继续补充和更新。