2、ROS2基础回顾：节点、话题、服务、动作、参数、生命周期节点等核心概念
在进入 Nav2 导航与边缘 AI 融合的实战之前，必须先夯实 ROS2 的通信与执行模型。导航系统本质上是多个功能模块（传感器驱动、定位、路径规划、控制、感知推理）之间的协同工作，而 ROS2 提供的节点、话题、服务、动作、参数与生命周期机制，正是支撑这种协同的骨架。本章将系统梳理这些核心概念，并特别强调它们在 Nav2 与边缘 AI 融合场景下的角色与约束。
上图展示了 ROS2 节点与四种主要通信机制（话题、服务、动作、参数）以及生命周期状态机之间的关系。在 Nav2 与边缘 AI 融合的系统中，节点是基本计算单元，话题承载高频传感器数据与推理结果，服务用于同步查询（如地图获取），动作则负责需要持续反馈和可取消的导航任务，参数提供运行时配置能力，生命周期机制确保各模块按序安全启停。
2.1 节点与话题：导航数据流的主动脉
核心原理
节点（Node）是 ROS2 中可执行文件的运行实例，每个节点负责单一职责。在 Nav2 系统中，典型节点包括 controller_server（轨迹跟踪）、planner_server（全局路径规划）、bt_navigator（行为树导航）、amcl（定位）以及边缘 AI 推理节点（如 yolo_detector）。节点之间通过话题（Topic）进行异步、单向、连续的数据交换。话题采用发布/订阅模式，发布者与订阅者解耦，不关心对方是否存在或何时加入。
在边缘 AI 融合场景中，话题是连接感知与规划的桥梁。例如，AI 推理节点订阅 /camera/image_raw（原始图像），经过模型推理后发布 /perception/obstacles（障碍物列表），而 Nav2 的 costmap 节点订阅该话题，将动态障碍物标记到代价地图中，从而影响全局与局部路径规划。
判断方法与操作流程
判断一个通信场景是否适合使用话题，可依据以下标准：
- 单向性：数据只从生产者流向消费者，无需请求-响应。
- 连续性：数据以固定或可变频率持续产生，如激光扫描、图像帧、速度指令。
- 多对多：多个订阅者需要同一份数据，如多个规划模块同时订阅障碍物信息。
操作流程上，创建话题通信需要三步：定义消息类型（如 sensor_msgs/msg/LaserScan）、在发布节点中创建发布者、在订阅节点中创建订阅者并注册回调函数。在 Nav2 中，常用命令行工具验证话题通信：
# 查看所有活跃话题
ros2 topic list
# 查看话题消息频率与带宽
ros2 topic hz /perception/obstacles
# 实时打印话题内容
ros2 topic echo /perception/obstacles --once案例拆解：AI 障碍物检测结果注入代价地图
假设一个室内服务机器人搭载 RGB-D 相机，需要在导航中避开临时摆放的椅子。传统 Nav2 仅依赖激光雷达，无法感知低矮或透明障碍物。我们增加一个边缘 AI 节点，运行 YOLOv8 模型检测“椅子”类别。
背景与约束：边缘设备为 Jetson Orin Nano，推理延迟约 30ms，相机帧率 15fps。检测结果需要以 visualization_msgs/msg/MarkerArray 或自定义消息发布，频率需与代价地图更新频率匹配（通常 1-5Hz）。
实施步骤：
- 定义自定义消息
PerceptionObstacle.msg，包含障碍物中心点、半径、置信度、类别标签。 - AI 节点订阅
/camera/depth/image_raw，将检测到的 2D 框结合深度图转换为 3D 位置。 - 发布到
/perception/obstacles，频率 3Hz。 - 修改 Nav2 的
costmap配置文件，添加一个ObstacleLayer插件，订阅该话题并将障碍物标记为致命代价。
结果对比：未融合前，机器人直接撞向椅子；融合后，全局规划器在 1 米外重新规划路径，绕行成功。代价是推理节点占用约 40% CPU，且当检测置信度低于 0.5 时会出现漏检，需设置阈值过滤。
sensor_msgs、nav_msgs），避免自定义消息带来的跨包编译与调试成本。若必须自定义，务必在 package.xml 中声明依赖。2.2 服务与动作：同步请求与长时任务
核心原理
服务（Service）采用客户端-服务器模式，提供同步、一次性、短时的请求-响应通信。典型应用包括：获取地图（/map_server/load_map）、切换全局规划器（/planner_server/change_planner）、查询机器人状态。服务适合耗时小于几百毫秒的操作，若耗时过长会阻塞调用方。
动作（Action）是 ROS2 中面向长时任务的通信机制，由目标（Goal）、反馈（Feedback）、结果（Result）三部分组成，支持客户端取消任务。Nav2 的导航请求正是通过动作实现：客户端发送目标点，bt_navigator 执行导航，期间持续发布反馈（当前位姿、剩余距离），最终返回结果（成功/失败/取消）。
判断方法与操作流程
选择服务还是动作，可参考下表：
| 维度 | 服务 | 动作 |
|---|---|---|
| 耗时 | 短（毫秒级） | 长（秒到分钟级） |
| 反馈 | 无 | 有周期性反馈 |
| 取消 | 不支持 | 支持 |
| 典型场景 | 查询参数、加载地图 | 导航、机械臂运动 |
操作流程上，动作通信需要定义 .action 文件（包含 Goal/Feedback/Result 三个部分），然后分别实现动作服务器与客户端。Nav2 中，bt_navigator 是动作服务器，用户可通过命令行发送导航目标：
ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose "{pose: {header: {frame_id: 'map'}, pose: {position: {x: 2.0, y: 1.0}, orientation: {w: 1.0}}}}"案例拆解：边缘 AI 触发动态目标重规划
考虑一个安防巡检机器人，AI 视觉模块识别到可疑人员时，需要立即改变导航目标点。此时若使用服务，机器人会阻塞等待路径规划完成，无法响应新的视觉事件。改用动作后，AI 节点作为动作客户端，在导航执行过程中发送新目标，bt_navigator 会取消当前目标并规划新路径。
关键参数：动作服务器设置 goal_handle 的取消策略为“接受取消”，客户端设置 cancel_goal 超时时间为 0.5 秒。实测中，从视觉识别到新路径开始执行，总延迟约 200ms，满足实时响应要求。
2.3 参数与生命周期节点：配置与受控启停
核心原理
参数（Parameter）是节点的键值对配置，支持运行时动态修改。Nav2 中大量使用参数：代价地图的膨胀半径、规划器的最大速度、AMCL 的粒子数等。参数可通过命令行、代码或 YAML 文件加载。
生命周期节点（Lifecycle Node）是 ROS2 提供的一种状态机管理机制，节点在“未配置→未激活→激活→清理/关闭”等状态间转换。Nav2 的所有核心节点均为生命周期节点，目的是确保系统按正确顺序启动：先加载地图与参数，再激活规划器，最后开始导航。
判断方法与操作流程
生命周期节点的状态转换必须显式调用，不能自动跳转。常用命令：
# 查看节点生命周期状态
ros2 lifecycle get /planner_server
# 切换状态
ros2 lifecycle set /planner_server configure
ros2 lifecycle set /planner_server activate在 Nav2 启动脚本中，通常使用 nav2_bt_navigator 的 autostart 参数自动完成状态转换。对于边缘 AI 节点，建议也设计为生命周期节点，以便在模型加载失败时进入“未配置”状态，而不是直接崩溃。
案例拆解：动态调整 AI 推理阈值
在导航过程中，若 AI 检测的误报率过高，会导致代价地图频繁出现虚假障碍物，路径规划震荡。通过参数服务，可在运行时调整置信度阈值：
ros2 param set /yolo_detector confidence_threshold 0.7同时，利用生命周期节点，在机器人进入空旷区域时，可临时将 AI 节点切换到“未激活”状态，减少计算负载；进入复杂区域时再激活。实测中，这种策略使 Jetson 的 GPU 占用率从 85% 降至 45%，而导航成功率保持 95% 以上。