上一阵子帮朋友评审一个机器人项目方案我连续翻了几个车间的整体架构发现一个现象大家机器人品牌不同、机构构型不同、应用场景也不同但工程师做的事情有接近一半是重复的。导航参数重新调一遍底盘驱动框架重新写一遍工具坐标系重新标一遍甚至同一套视觉识别方案到了新设备上还要再改接口改半天。反观乐高零件种类并不算多却能拼出汽车、城堡、机械臂和整个城市。原因在于乐高颗粒有统一凸起和凹槽机械接口固定轮子不会因为换了车身就不能用。机器人行业正在追求的方向其实很像这件事把机器人拆成标准颗粒通过标准化接口快速组合成不同形态的产品。这篇文章不聊玄学而是从硬件、软件、工业标准三个层面分析“机器人乐高化”到底在解决什么问题同时用 ROS 2 导航作为案例展示怎么把一个完整机器人系统“拼”出来。1. 为什么说“机器人的下一站或许是乐高化”1.1 乐高化不是娱乐化而是模块化、标准化、可组合化很多人听到“机器人乐高化”会有直觉反感机器人是严肃的工业设备不是儿童玩具。这里说的乐高化并不代表把机械臂做成五彩塑料壳而是指开发模式上具备乐高的三个核心特征。第一是模块化。系统由多个职责单一的单元组成每个单元都能独立开发、测试和替换。第二是标准化。模块之间的机械接口、电气接口、通信协议、软件 API 必须保持稳定就像乐高积木的凸点和凹槽不管哪个零件箱里拿出来的都能怼在一起。第三是可组合化。通过不同模块的拼装能够得到不同能力而不需要修改基石模块本身。举个例子同一个移动底盘如果顶部预留了统一供电接口和通信协议让它加一个机械臂就变成移动操作机器人换成一个货架顶升机构就变成仓储搬运机器人装上一圈补光灯和摄像头又成了巡检设备。这种“一个平台衍生多种产品”的模式正是乐高化给工程开发带来的最大收益。1.2 机器人行业当下的痛点恰好堆在“拼插”这个环节机器人项目有一个很典型的矛盾单个项目看起来都是定制开发但是放到更大范围看大量轮子被反复发明。硬件上骨架、关节、驱动、控制板各家有各家的设计结构件很难互换。软件上控制程序往往从零搭建通讯协议东一块西一块。结果就是项目交付周期长、成本高、工程师长期陷在低级重复劳动里真正该投入的算法调优和场景创新反而没有时间做。另一个问题是更新速度。这两年机器人算法迭代非常快视觉模型、路径规划算法、导航方案几乎每隔几个月就有新版本。如果软件是单体架构更换一个算法模块往往要梳理全局依赖稍微不注意就引入新问题。只有把能力拆成边界清晰的积木块才能实现“换一个部件不碰其他部件”。1.3 乐高化在机器人上体现为两条主线一条是硬件主线一体化关节模组、末端工具快换、标准法兰、标准化 IO 和总线接口让机器人的“身体”可以被拼装。另一条是软件主线ROS 2 这类中间件把功能拆成节点功能包之间通过话题、服务、动作通信让机器人的“大脑”可以被编排。两条主线汇合以后机器人项目就从一个“纯手工雕塑”的过程慢慢变成一个“按图拼装、局部定制”的过程。下面先看硬件层。2. 硬件层让机器人“身体”可以拼装2.1 从机械臂整机走向一体化关节模组传统工业机械臂的研发往往是一套深度定制工程电机选型、减速器匹配、驱动器设计、结构件加工、线缆走线、散热处理全部要一起考虑。成熟厂家这么做的确能打磨出高刚性和高可靠性的产品但对于小批量、多品种的机器人团队来说这种模式成本太高、周期太长。一体化关节模组在这个背景下越来越流行。一个关节模组内部往往集成了电机、减速器、编码器、抱闸、驱动器甚至部分通信控制电路。对外只留下两个接口一个机械安装面、一个总线通信口。机器人本体开发者不需要分别处理每一个部件的原理图和底层驱动只需要把关节模组按角度串联起来写控制指令让它转动。更关键的是可维护性。传统结构如果某个关节内部电机损坏在小团队里基本等于这台设备要返厂拆解。采用一体化关节模组后可以把故障关节整个拆下来换上新的同型号模组机器人重新标定后又能使用。这其实就是硬件积木化的一个非常具体的好处。2.2 工具快换系统让末端执行器“即插即用”机械臂的“手”变化最多有时是夹爪有时是吸盘有时是焊枪有时是视觉相机。如果每换一种工具都要重新接线、重新改程序现场调试效率会非常低。工具快换系统解决的问题正是末端工具的快速拼插。这类装置一般分成机器人侧和工具侧两部分机器人侧装有锁紧机构工具侧固定在具体工具上。对接时不仅完成机械锁紧还会同步接通电气信号、气路甚至 EtherCAT 等通信链路。换工具的过程从以前几十分钟的人工检修缩短到几分钟的自动对接。在这个环节里法兰标准很重要。例如机械臂末端法兰尺寸如果遵循 ISO 9409 这类标准不同厂家生产的末端工具和快换装置就存在互换基础。对集成商来说提前定义好末端机械接口和电气引脚定义本质上就是在给自己造一套“积木接口标准”。2.3 从发那科 PNS 和现场 IO 看信号级标准化讨论工业机器人不能只盯着机械结构。机器人在工厂里通常不是孤立设备而是整条产线的一部分需要和 PLC、传感器、上位机、输送线配合。以发那科机器人的远程启动为例工程师经常提到 PNS 功能。PNS 的核心思想是用一组数字输入信号来“选择程序编号”。外部 PLC 按预先约定好的编码方式把需要执行的程序号发给机器人控制柜再配合远程启动信号机器人就会自动运行对应程序。过程很像把机器人当成了产线里的一个“执行积木”PLC 只需要知道给哪个地址发什么信号不需要关心机器人内部程序是怎么写的。同样的思路也出现在 ABB、库卡、安川等品牌上。它们各自有远程模式、外部自动模式也都有对应的 IO 映射表。项目集成时最枯燥也最容易出错的反而就是这些 IO 点位的约定。哪一位是启动哪一位是暂停哪一位是程序号选择必须以表格形式固定下来否则现场接线和程序联调时所有人都会崩溃。这里也想强调一个观点硬件乐高化不只是把螺丝孔做成统一尺寸信号层面的标准化甚至更重要。结构插不上顶多改个支架信号对不上则可能直接导致设备误动作存在安全隐患。3. 软件层ROS 2 把机器人能力拆成积木3.1 ROS 不是操作系统而是软件“积木系统”很多第一次接触 ROS 的开发者会误以为 ROS 是一个操作系统。准确地说ROS 是运行在 Linux 之上的机器人中间件和工具生态它的核心价值在于提供了一套模块间通信机制和丰富的功能包。ROS 2 中有几个最基础的概念理解它们就能理解“软件积木”是怎么拼接的。节点是功能单元相当于一块积木。一个传感器驱动可以是一个节点一个路径规划器可以是一个节点一个底盘控制模块也可以是一个节点。话题是节点之间异步通信的通道类似积木的咬合结构。发布者把消息放到话题上订阅者从话题上取数据。服务是对同步请求-响应模型的封装调用方发请求服务端处理完返回结果。动作则适合执行时间较长的任务比如“移动到目标点”客户端可以随时查询进度也可以取消动作。节点之间只依赖“话题名、消息类型、服务接口”这些契约并不需要知道对方内部实现。因此替换其中任何一个节点只要契约不变其余部分无需改动。这就是典型的软件可插拔设计。3.2 一个最小示例用两个积木拼出“感知触发运动”为了更直观感受这种“拼插感”我们写一个非常小的 ROS 2 例子。一个节点负责“感知”另一个节点负责“运动”两个节点通过话题/motion_cmd通信。第一个文件sensor_block.py模拟一个定时发布指令的感知模块import rclpy from rclpy.node import Node from std_msgs.msg import String class SensorBlock(Node): def __init__(self): super().__init__(sensor_block) self.publisher self.create_publisher(String, /motion_cmd, 10) self.timer self.create_timer(1.0, self.timer_callback) self.count 0 def timer_callback(self): msg String() msg.data f第 {self.count} 次触发 self.publisher.publish(msg) self.get_logger().info(f感知积木发布: {msg.data}) self.count 1 def main(argsNone): rclpy.init(argsargs) node SensorBlock() try: rclpy.spin(node) except KeyboardInterrupt: pass finally: node.destroy_node() rclpy.shutdown() if __name__ __main__: main()第二个文件motion_block.py模拟一个接收指令后运动的模块import rclpy from rclpy.node import Node from std_msgs.msg import String class MotionBlock(Node): def __init__(self): super().__init__(motion_block) self.subscription self.create_subscription( String, /motion_cmd, self.listener_callback, 10 ) def listener_callback(self, msg): self.get_logger().info(f运动积木收到指令: {msg.data}) # 这里可以替换成真实的底盘速度控制逻辑 def main(argsNone): rclpy.init(argsargs) node MotionBlock() try: rclpy.spin(node) except KeyboardInterrupt: pass finally: node.destroy_node() rclpy.shutdown() if __name__ __main__: main()运行前先 source ROS 2 环境然后打开两个终端分别执行python3 sensor_block.py python3 motion_block.py第二个终端会持续打印“运动积木收到指令”。如果将来想把“感知”从定时器换成真正的人体红外传感器只需要修改sensor_block.py的内部逻辑保持话题名和消息类型不变运动模块完全不需要改动。这个例子虽然简单但就是软件乐高化的基础模型。3.3 常见算法积木建图、定位、规划、控制在真实机器人系统里功能比刚才的例子复杂得多但拼接逻辑是类似的。以移动机器人导航为例系统通常由这几块积木组成SLAM 建图积木例如 Cartographer 或 SLAM Toolbox。它接收激光雷达扫描和里程计输出环境地图和机器人在地图中的位姿估计。AMCL 定位积木。当地图已经准备好机器人开机后只需要定位不需要重新建图时AMCL 是经典选择。代价地图与路径规划积木。Nav2 提供全局规划器和局部规划器负责在障碍物环境中搜索从当前位置到目标点的可行路径。底盘控制积木。接收速度指令把轮速命令下发到电机驱动器。这些积木通过 TF 坐标变换和传感器话题串起来。只要大家按约定发布/tf、/odom、/scan这些标准数据任何一家导航算法包都能接入。这就是为什么现在导航开发效率明显高于十年前。Nav2 还使用行为树来描述导航任务流程。行为树是一种可编排的控制结构每个节点是一个小的判断或动作。比如“先检查是否到达目标如果没到就搜索路径路径存在后跟随后续路径”。把行为树拆开看一个个节点其实都是可复用的决策积木。下面是一段简化的行为树逻辑示意仅用来表达节点间的拼装关系root main_tree_to_executeMainTree BehaviorTree IDMainTree Sequence name导航任务 Condition IDGoalNotReached/ Action IDComputePathToPose/ Action IDFollowPath/ /Sequence /BehaviorTree /root注意这不是一个完整可运行的 Nav2 行为树文件只是为了说明“任务 决策节点按顺序组合”的思想。4. 动手实践用 ROS 2“拼”一个最小导航系统4.1 环境准备与安装要验证上面的拼接思路最简单的方式是使用 Gazebo 仿真环境。本节示例以 Ubuntu 22.04 和 ROS 2 Humble 为例如果你使用的是其他发行版将命令中的humble替换成对应版本名称。安装导航相关功能包sudo apt update sudo apt install ros-humble-navigation2 ros-humble-nav2-bringup ros-humble-slam-toolbox除了这些基础包还需要有一个能发布激光、里程计和 TF 的机器人环境。实际项目里可以用自己的底盘想快速验证可以选用仿真环境。仿真平台不是本文重点这里不再展开具体型号只强调一个概念无论真机还是仿真必须能持续发布以下内容/tf树特别是odom - base_link和base_link - laser。里程计话题例如/odom。激光雷达话题例如/scan。这相当于约定好了积木的“凹槽”有了这些标准输入Nav2 才能拼上去。4.2 第一步用 SLAM Toolbox 建图打开一个终端启动自己的机器人仿真环境。接着启动 SLAM Toolboxros2 launch slam_toolbox online_async_launch.py use_sim_time:true如果启动命令不一致可以用下面的方式先查看当前环境中的 launch 文件ros2 pkg prefix slam_toolbox ls $(ros2 pkg prefix slam_toolbox)/share/slam_toolbox/launch/SLAM Toolbox 启动后手动遥控机器人把目标环境完整走一圈。当 RViz 中出现的地图轮廓稳定清晰后保存地图ros2 run nav2_map_server map_saver_cli -f ~/map/factory_map执行成功后会生成factory_map.pgm和factory_map.yaml。前者是灰度地图图片后者是地图参数文件后面定位要用。4.3 第二步加载地图启动定位建好的地图相当于拼接图样。把地图交给 Nav2 前需要先启动定位模块告诉系统“机器人现在站在地图中的哪个位置”。打开新终端启动 Nav2 自带的定位 launchros2 launch nav2_bringup localization_launch.py map:~/map/factory_map.yaml use_sim_time:true启动后打开 RViz2通过“2D Pose Estimate”按钮手动给一个初始位姿或者让定位模块自动收敛。如果 TF 树正常地图和激光扫描点会逐渐对齐。4.4 第三步启动导航规划和执行模块定位正常以后再启动导航模块ros2 launch nav2_bringup navigation_launch.py use_sim_time:true这时系统的模块结构已经非常清晰定位
上一阵子帮朋友评审一个机器人项目方案我连续翻了几个车间的整体架构发现一个现象大家机器人品牌不同、机构构型不同、应用场景也不同但工程师做的事情有接近一半是重复的。导航参数重新调一遍底盘驱动框架重新写一遍工具坐标系重新标一遍甚至同一套视觉识别方案到了新设备上还要再改接口改半天。反观乐高零件种类并不算多却能拼出汽车、城堡、机械臂和整个城市。原因在于乐高颗粒有统一凸起和凹槽机械接口固定轮子不会因为换了车身就不能用。机器人行业正在追求的方向其实很像这件事把机器人拆成标准颗粒通过标准化接口快速组合成不同形态的产品。这篇文章不聊玄学而是从硬件、软件、工业标准三个层面分析“机器人乐高化”到底在解决什么问题同时用 ROS 2 导航作为案例展示怎么把一个完整机器人系统“拼”出来。1. 为什么说“机器人的下一站或许是乐高化”1.1 乐高化不是娱乐化而是模块化、标准化、可组合化很多人听到“机器人乐高化”会有直觉反感机器人是严肃的工业设备不是儿童玩具。这里说的乐高化并不代表把机械臂做成五彩塑料壳而是指开发模式上具备乐高的三个核心特征。第一是模块化。系统由多个职责单一的单元组成每个单元都能独立开发、测试和替换。第二是标准化。模块之间的机械接口、电气接口、通信协议、软件 API 必须保持稳定就像乐高积木的凸点和凹槽不管哪个零件箱里拿出来的都能怼在一起。第三是可组合化。通过不同模块的拼装能够得到不同能力而不需要修改基石模块本身。举个例子同一个移动底盘如果顶部预留了统一供电接口和通信协议让它加一个机械臂就变成移动操作机器人换成一个货架顶升机构就变成仓储搬运机器人装上一圈补光灯和摄像头又成了巡检设备。这种“一个平台衍生多种产品”的模式正是乐高化给工程开发带来的最大收益。1.2 机器人行业当下的痛点恰好堆在“拼插”这个环节机器人项目有一个很典型的矛盾单个项目看起来都是定制开发但是放到更大范围看大量轮子被反复发明。硬件上骨架、关节、驱动、控制板各家有各家的设计结构件很难互换。软件上控制程序往往从零搭建通讯协议东一块西一块。结果就是项目交付周期长、成本高、工程师长期陷在低级重复劳动里真正该投入的算法调优和场景创新反而没有时间做。另一个问题是更新速度。这两年机器人算法迭代非常快视觉模型、路径规划算法、导航方案几乎每隔几个月就有新版本。如果软件是单体架构更换一个算法模块往往要梳理全局依赖稍微不注意就引入新问题。只有把能力拆成边界清晰的积木块才能实现“换一个部件不碰其他部件”。1.3 乐高化在机器人上体现为两条主线一条是硬件主线一体化关节模组、末端工具快换、标准法兰、标准化 IO 和总线接口让机器人的“身体”可以被拼装。另一条是软件主线ROS 2 这类中间件把功能拆成节点功能包之间通过话题、服务、动作通信让机器人的“大脑”可以被编排。两条主线汇合以后机器人项目就从一个“纯手工雕塑”的过程慢慢变成一个“按图拼装、局部定制”的过程。下面先看硬件层。2. 硬件层让机器人“身体”可以拼装2.1 从机械臂整机走向一体化关节模组传统工业机械臂的研发往往是一套深度定制工程电机选型、减速器匹配、驱动器设计、结构件加工、线缆走线、散热处理全部要一起考虑。成熟厂家这么做的确能打磨出高刚性和高可靠性的产品但对于小批量、多品种的机器人团队来说这种模式成本太高、周期太长。一体化关节模组在这个背景下越来越流行。一个关节模组内部往往集成了电机、减速器、编码器、抱闸、驱动器甚至部分通信控制电路。对外只留下两个接口一个机械安装面、一个总线通信口。机器人本体开发者不需要分别处理每一个部件的原理图和底层驱动只需要把关节模组按角度串联起来写控制指令让它转动。更关键的是可维护性。传统结构如果某个关节内部电机损坏在小团队里基本等于这台设备要返厂拆解。采用一体化关节模组后可以把故障关节整个拆下来换上新的同型号模组机器人重新标定后又能使用。这其实就是硬件积木化的一个非常具体的好处。2.2 工具快换系统让末端执行器“即插即用”机械臂的“手”变化最多有时是夹爪有时是吸盘有时是焊枪有时是视觉相机。如果每换一种工具都要重新接线、重新改程序现场调试效率会非常低。工具快换系统解决的问题正是末端工具的快速拼插。这类装置一般分成机器人侧和工具侧两部分机器人侧装有锁紧机构工具侧固定在具体工具上。对接时不仅完成机械锁紧还会同步接通电气信号、气路甚至 EtherCAT 等通信链路。换工具的过程从以前几十分钟的人工检修缩短到几分钟的自动对接。在这个环节里法兰标准很重要。例如机械臂末端法兰尺寸如果遵循 ISO 9409 这类标准不同厂家生产的末端工具和快换装置就存在互换基础。对集成商来说提前定义好末端机械接口和电气引脚定义本质上就是在给自己造一套“积木接口标准”。2.3 从发那科 PNS 和现场 IO 看信号级标准化讨论工业机器人不能只盯着机械结构。机器人在工厂里通常不是孤立设备而是整条产线的一部分需要和 PLC、传感器、上位机、输送线配合。以发那科机器人的远程启动为例工程师经常提到 PNS 功能。PNS 的核心思想是用一组数字输入信号来“选择程序编号”。外部 PLC 按预先约定好的编码方式把需要执行的程序号发给机器人控制柜再配合远程启动信号机器人就会自动运行对应程序。过程很像把机器人当成了产线里的一个“执行积木”PLC 只需要知道给哪个地址发什么信号不需要关心机器人内部程序是怎么写的。同样的思路也出现在 ABB、库卡、安川等品牌上。它们各自有远程模式、外部自动模式也都有对应的 IO 映射表。项目集成时最枯燥也最容易出错的反而就是这些 IO 点位的约定。哪一位是启动哪一位是暂停哪一位是程序号选择必须以表格形式固定下来否则现场接线和程序联调时所有人都会崩溃。这里也想强调一个观点硬件乐高化不只是把螺丝孔做成统一尺寸信号层面的标准化甚至更重要。结构插不上顶多改个支架信号对不上则可能直接导致设备误动作存在安全隐患。3. 软件层ROS 2 把机器人能力拆成积木3.1 ROS 不是操作系统而是软件“积木系统”很多第一次接触 ROS 的开发者会误以为 ROS 是一个操作系统。准确地说ROS 是运行在 Linux 之上的机器人中间件和工具生态它的核心价值在于提供了一套模块间通信机制和丰富的功能包。ROS 2 中有几个最基础的概念理解它们就能理解“软件积木”是怎么拼接的。节点是功能单元相当于一块积木。一个传感器驱动可以是一个节点一个路径规划器可以是一个节点一个底盘控制模块也可以是一个节点。话题是节点之间异步通信的通道类似积木的咬合结构。发布者把消息放到话题上订阅者从话题上取数据。服务是对同步请求-响应模型的封装调用方发请求服务端处理完返回结果。动作则适合执行时间较长的任务比如“移动到目标点”客户端可以随时查询进度也可以取消动作。节点之间只依赖“话题名、消息类型、服务接口”这些契约并不需要知道对方内部实现。因此替换其中任何一个节点只要契约不变其余部分无需改动。这就是典型的软件可插拔设计。3.2 一个最小示例用两个积木拼出“感知触发运动”为了更直观感受这种“拼插感”我们写一个非常小的 ROS 2 例子。一个节点负责“感知”另一个节点负责“运动”两个节点通过话题/motion_cmd通信。第一个文件sensor_block.py模拟一个定时发布指令的感知模块import rclpy from rclpy.node import Node from std_msgs.msg import String class SensorBlock(Node): def __init__(self): super().__init__(sensor_block) self.publisher self.create_publisher(String, /motion_cmd, 10) self.timer self.create_timer(1.0, self.timer_callback) self.count 0 def timer_callback(self): msg String() msg.data f第 {self.count} 次触发 self.publisher.publish(msg) self.get_logger().info(f感知积木发布: {msg.data}) self.count 1 def main(argsNone): rclpy.init(argsargs) node SensorBlock() try: rclpy.spin(node) except KeyboardInterrupt: pass finally: node.destroy_node() rclpy.shutdown() if __name__ __main__: main()第二个文件motion_block.py模拟一个接收指令后运动的模块import rclpy from rclpy.node import Node from std_msgs.msg import String class MotionBlock(Node): def __init__(self): super().__init__(motion_block) self.subscription self.create_subscription( String, /motion_cmd, self.listener_callback, 10 ) def listener_callback(self, msg): self.get_logger().info(f运动积木收到指令: {msg.data}) # 这里可以替换成真实的底盘速度控制逻辑 def main(argsNone): rclpy.init(argsargs) node MotionBlock() try: rclpy.spin(node) except KeyboardInterrupt: pass finally: node.destroy_node() rclpy.shutdown() if __name__ __main__: main()运行前先 source ROS 2 环境然后打开两个终端分别执行python3 sensor_block.py python3 motion_block.py第二个终端会持续打印“运动积木收到指令”。如果将来想把“感知”从定时器换成真正的人体红外传感器只需要修改sensor_block.py的内部逻辑保持话题名和消息类型不变运动模块完全不需要改动。这个例子虽然简单但就是软件乐高化的基础模型。3.3 常见算法积木建图、定位、规划、控制在真实机器人系统里功能比刚才的例子复杂得多但拼接逻辑是类似的。以移动机器人导航为例系统通常由这几块积木组成SLAM 建图积木例如 Cartographer 或 SLAM Toolbox。它接收激光雷达扫描和里程计输出环境地图和机器人在地图中的位姿估计。AMCL 定位积木。当地图已经准备好机器人开机后只需要定位不需要重新建图时AMCL 是经典选择。代价地图与路径规划积木。Nav2 提供全局规划器和局部规划器负责在障碍物环境中搜索从当前位置到目标点的可行路径。底盘控制积木。接收速度指令把轮速命令下发到电机驱动器。这些积木通过 TF 坐标变换和传感器话题串起来。只要大家按约定发布/tf、/odom、/scan这些标准数据任何一家导航算法包都能接入。这就是为什么现在导航开发效率明显高于十年前。Nav2 还使用行为树来描述导航任务流程。行为树是一种可编排的控制结构每个节点是一个小的判断或动作。比如“先检查是否到达目标如果没到就搜索路径路径存在后跟随后续路径”。把行为树拆开看一个个节点其实都是可复用的决策积木。下面是一段简化的行为树逻辑示意仅用来表达节点间的拼装关系root main_tree_to_executeMainTree BehaviorTree IDMainTree Sequence name导航任务 Condition IDGoalNotReached/ Action IDComputePathToPose/ Action IDFollowPath/ /Sequence /BehaviorTree /root注意这不是一个完整可运行的 Nav2 行为树文件只是为了说明“任务 决策节点按顺序组合”的思想。4. 动手实践用 ROS 2“拼”一个最小导航系统4.1 环境准备与安装要验证上面的拼接思路最简单的方式是使用 Gazebo 仿真环境。本节示例以 Ubuntu 22.04 和 ROS 2 Humble 为例如果你使用的是其他发行版将命令中的humble替换成对应版本名称。安装导航相关功能包sudo apt update sudo apt install ros-humble-navigation2 ros-humble-nav2-bringup ros-humble-slam-toolbox除了这些基础包还需要有一个能发布激光、里程计和 TF 的机器人环境。实际项目里可以用自己的底盘想快速验证可以选用仿真环境。仿真平台不是本文重点这里不再展开具体型号只强调一个概念无论真机还是仿真必须能持续发布以下内容/tf树特别是odom - base_link和base_link - laser。里程计话题例如/odom。激光雷达话题例如/scan。这相当于约定好了积木的“凹槽”有了这些标准输入Nav2 才能拼上去。4.2 第一步用 SLAM Toolbox 建图打开一个终端启动自己的机器人仿真环境。接着启动 SLAM Toolboxros2 launch slam_toolbox online_async_launch.py use_sim_time:true如果启动命令不一致可以用下面的方式先查看当前环境中的 launch 文件ros2 pkg prefix slam_toolbox ls $(ros2 pkg prefix slam_toolbox)/share/slam_toolbox/launch/SLAM Toolbox 启动后手动遥控机器人把目标环境完整走一圈。当 RViz 中出现的地图轮廓稳定清晰后保存地图ros2 run nav2_map_server map_saver_cli -f ~/map/factory_map执行成功后会生成factory_map.pgm和factory_map.yaml。前者是灰度地图图片后者是地图参数文件后面定位要用。4.3 第二步加载地图启动定位建好的地图相当于拼接图样。把地图交给 Nav2 前需要先启动定位模块告诉系统“机器人现在站在地图中的哪个位置”。打开新终端启动 Nav2 自带的定位 launchros2 launch nav2_bringup localization_launch.py map:~/map/factory_map.yaml use_sim_time:true启动后打开 RViz2通过“2D Pose Estimate”按钮手动给一个初始位姿或者让定位模块自动收敛。如果 TF 树正常地图和激光扫描点会逐渐对齐。4.4 第三步启动导航规划和执行模块定位正常以后再启动导航模块ros2 launch nav2_bringup navigation_launch.py use_sim_time:true这时系统的模块结构已经非常清晰定位
