企业官网建设流程全解析

简介：这套基于清华大学NavGPT-2具身智能大语言模型与ROS2机器人操作系统的交互式自主导航系统项目极简说明，面向机器人开发者、SLAM与具身智能研究人员。系统以自然语言文本指令作为输入，由NavGPT-2完成意图解析与指令转化，再由ROS2驱动感知、决策与控制链路，实现从当前位置到目标点的自主导航。包内共有1512个文件，体积51.04MB，以553个Python脚本、154个C/C++头文件与105个C++源文件为核心，同时包含84个HTML页面、64个STL模型与60个YAML配置，覆盖系统部署、路径规划算法、可视化界面与仿真环境等完整环节。附赠内容还提供了开发文档、技术说明文件以及Path-Planning-Ros2-humble-master路径规划算法库，便于读者深入理解模块划分、话题通信与导航管线搭建。目前已有50人学习浏览，适合用于复盘导航算法工程化实现、扩展自然语言交互机器人功能。

1. NavGPT-2与ROS2能搭出什么样的"会听话"的导航机器人

刚开始接触这个标题时，我最大的困惑是：既然已经有Nav2这样成熟的导航栈，为什么还要硬塞一个大语言模型？后来我发现，传统导航需要人手动在rviz2里点二维目标点，而"把客厅茶几挪到沙发旁"这类自然语言指令，传统导航完全接不住。NavGPT-2是清华大学团队提出的具身智能视觉语言导航大模型，能把视觉观测和自然语言指令一起送进LLM推理链路，输出导航决策；ROS2则提供节点、话题、服务、动作这套通信底座。两者融合出的交互式自主导航系统，能完成"听人话、看环境、定路径、开过去"的完整闭环。

这里先给一个反直觉结论：NavGPT-2落地时不直接算路径，也不会输出线速度和角速度。它当"语义大脑"，把指令翻译成目标意图，走路交给Nav2导航栈。这套方案适合两类人：已经在ROS2里做过SLAM导航、想补上自然语言交互能力的工程师；正在做具身智能研究、需要一个能跑能改的实物载体的团队。

2. 先拆任务：自然语言指令到几何目标之间隔着一层"语义对齐"

2.1 NavGPT-2真正要解的问题：从"看图说话"到"该去哪"

NavGPT-2要解决的问题是具身智能里的视觉语言导航，英文缩写VLN。任务设定并不复杂：机器人当前有一组视觉观测，通常来自机载深度相机，取前、左、右或者上下多视角的RGB图；同时收到一句自然语言指令，比如"穿过客厅，在餐桌旁边停下来"。模型需要给出下一步的导航决策。NavGPT-2相比第一代NavGPT的改进在于，它不再依赖一个独立的VLM把图像转成文字描述再喂给语言模型，而是把视觉编码后的特征更紧地接入LLM的推理过程。这样做的直接收益是"看错图"和"想错路"两个错误源被分开了，模型有更大的空间去做空间推理。

很多做传统导航的工程师第一次接触这类模型时，容易陷入一个误区：把NavGPT-2当成一个"固定输出动作词表"的分类器。实际上它训练完成后的输出是自由文本形式的导航推理。比如输入图片和"穿过客厅去厨房"，模型可能在中间推理里写出"我看到了沙发和茶几，厨房入口在左侧走廊尽头，所以先直行到走廊口再左转"。这个能力对下游非常友好，因为推理过程可以打印出来给调试的人看，也能引导系统去做更精细的目标确认。

但自由文本也带了一个麻烦：同样的语义，模型在两次推理里可能给出不同说法。因此落地的时候绝对不能直接拿整段文本去驱动ROS2导航器。我给团队定的规矩是：NavGPT-2的推理文本只作为日志保留，系统真正接收的是从推理结果中抽取出的结构化意图。具体来说就是一份固定格式的JSON，包含意图类型、语义目标和置信度。把黑匣子模型的输出卡在一个明确数据结构里，是这类系统能稳定运行的第一步。

2.2 输入输出边界：为什么不能让大模型直接控制电机

这里我要花点篇幅说一个最常见的翻车设计：让LLM直接输出线速度和角速度指令。表面上看，这省掉了语义到坐标的转换，模型"说人话"，底盘"听话"，多直接。实际问题有三层。第一，控制频率对不上。底盘速度指令一般要求10Hz以上的稳定周期，而大模型端到端推理一次少则几百毫秒，多则几秒，输出天然断续，底盘接到的是一串"时有时无"的速度，走两步停一下。第二，单位与坐标系极易错。模型训练数据里"向前"到底对应机器人坐标系下的多少米每秒，谁也说不清，真机上一不小心就是往墙上怼。第三，责任边界混乱。一旦导航失败，你无法判断是模型理解错了还是路径规划参数不合理，调试成本成倍上升。

所以我在2.1里那个JSON结构就是刻意把模型输出粒度限制在"语义意图"这一层。意图类型通常只有几个：goto表示去某个语义目标，replan表示当前执行需要重新规划，query表示用户在问状态而不是下命令。语义目标是一个标准化的地点ID，比如charging_station、kitchen_counter。置信度用来做兜底，低于阈值时系统不执行，而是回问一句"我没有把握，请确认一下"。这个设计的核心思想是：模型负责选择题，导航栈负责计算题，两层各干各的活。

现在整个行业都在谈具身智能和视觉大语言模型，但真正缺的不是模型本身，而是把模型输出变成机器人行为的那座桥。这座桥就是本节讲的输入输出边界与语义目标映射模块。

2.3 最简可用的语义目标点表：从"人话"到坐标的一步

为了让语义目标能被导航栈消费，我习惯在第一版系统里做一张非常朴素的YAML表，把环境里每个有意义的地点映射成二维坐标和朝向。这张表同时承担两件事：一是给语义目标ID提供坐标，二是作为人工验证的清单。

semantic_goals: charging_station: position: [2.4, -1.8] yaw: 0.0 aliases: ["充电桩", "充电位置", "充电站"] kitchen_counter: position: [-3.2, 1.5] yaw: 1.57 aliases: ["厨房操作台", "操作台", "厨房台面"]

这个表的字段设计有几个讲究。position用的是map坐标系下的二维坐标，单位米，yaw是期望到达后的朝向，单位弧度；aliases是中文同义词列表。之所以要aliases字段，是因为NavGPT-2在中文分词上并不稳定，用户说"厨房台面"和"操作台"可能触发不同的token结果。系统在goal_router节点里做匹配时，先精确匹配目标ID，匹配失败再遍历所有aliases做包含匹配。包含匹配比完全匹配宽容得多，但也需要小心误命中，比如充电桩和充电桩旁边不能混在一起。

坐标从哪里来？第一版可以拿尺子在地图上量，更靠谱的方式是在rviz2里先手动控制机器人开到目标点，记录当时tf树里的map坐标系位置，再填进表里。这个流程虽然人工，但能保证每个点的坐标是机器人真实可导航的地点。等系统跑通了再考虑自动提取地标，前期别自找麻烦。

3. 用ROS2把这座桥搭起来：节点、话题、服务、动作的选型与最小实现

3.1 命令先跑通最小闭环：三个节点与两条通信通道

上一章把模型输出边界定了，这一章把它们变成ROS2的运行时结构。最小闭环需要三个节点：llm_bridge节点负责接用户文本、请求NavGPT-2推理、解析输出并发布结构化意图；goal_router节点负责订阅意图，查询语义点表，把语义ID转换成PoseStamped；nav_executor节点负责把目标发给Nav2的NavigateToPose行动服务器。三个节点各自独立运行，两条通信通道分别是/llm_bridge/parsed_intent话题和/goal_router/goal_pose话题。

ros2 run navgpt2_bringup llm_bridge --ros-args \ -p llm_endpoint:=http://127.0.0.1:8000/v1/completions \ -p max_tokens:=128 \ -p min_confidence:=0.6

启动命令里三个参数要重点说明。llm_endpoint指向本地部署的模型服务，常见做法是用vLLM或者llama.cpp拉起一个OpenAI兼容接口；max_tokens限制生成长度，NavGPT-2毕竟不是闲聊模型，128个token足够输出一行JSON；min_confidence是置信度阈值，低于0.6的意图直接丢弃回问用户。这三个参数在后端联调里是调得最频繁的，我一般是先跑通默认值，再根据实际日志微调。

首跑强烈建议在同一个ROS_DOMAIN_ID下、同一台机器上完成，不要跨机。ROS2底层走DDS，跨机部署会把"代码问题"和"网络问题"混在一起，后面排查非常痛苦。等单机跑通再拆成跨机，而且拆的时候优先只把llm_bridge放到有GPU的机器上，其余节点留在原本机器。

跑通三个节点后，先用两个命令验证链路再去接Nav2。

ros2 topic echo /navgpt2/parsed_intent --once ros2 action list -t

第一条命令看意图有没有出来，第二条命令确认行动服务器是否已经注册。这两个命令返回都正常，再往下接导航执行层。

3.2 llm_bridge节点骨架：订阅、请求、解析、发布四步循环

这里给一个可以直接抄的Python节点骨架。为了保持可读性，HTTP请求细节和异常处理做了简化，但流程是完整的。

import json import rclpy from rclpy.node import Node from std_msgs.msg import String import requests class LLMBridge(Node): def __init__(self): super().__init__('llm_bridge') self.sub = self.create_subscription( String, '/user/instruction', self.on_instruction, 10) self.pub = self.create_publisher( String, '/navgpt2/parsed_intent', 10) self.declare_parameter('llm_endpoint', 'http://127.0.0.1:8000/v1/completions') self.declare_parameter('min_confidence', 0.6) self.endpoint = self.get_parameter('llm_endpoint').value self.min_conf = self.get_parameter('min_confidence').value def on_instruction(self, msg): prompt = self.build_prompt(msg.data) try: r = requests.post( self.endpoint, json={"prompt": prompt, "max_tokens": 128, "temperature": 0.1}, timeout=10.0) output = r.json()['choices'][0]['text'] intent = json.loads(output) except Exception as e: self.get_logger().error(f'LLM call failed: {e}') return if intent.get('confidence', 0) < self.min_conf: self.get_logger().warn('low confidence, wait for user confirm') return msg_out = String() msg_out.data = json.dumps({ 'intent': intent['intent'], 'target': intent['target'] }) self.pub.publish(msg_out) def build_prompt(self, user_text): return ( 'You are part of an indoor navigation system. ' 'Given the instruction, return JSON with keys: ' 'intent, target, confidence. ' f'Instruction: {user_text}' ) def main(): rclpy.init() node = LLMBridge() rclpy.spin(node)

这个节点最值得注意的几个参数是：temperature设为0.1来压低随机性，超时设为10秒防止模型无响应时把话题回调卡死。回调里所有异常都try住，不让异常把节点搞崩。执行流程很清晰——订阅/user/instruction，组装prompt，请求本地模型接口，解析JSON，过滤低置信度，发布到/parsed_intent。整个循环没有用到任何ROS2服务，因为这一段是纯"文本进、意图出"，用话题最直接。

补充一点关于算力的考虑：本地部署大模型时，vLLM的显存占用、并发数和max_tokens都会影响响应延时。走HTTP接口之后，资源配置调整不依赖代码改动，这是一个很实用的解耦方式。即使后续换更大的模型，llm_bridge节点本身不用改。

3.3 行动服务器：长任务为什么必须用Action而不是Topic

导航不是一个瞬时消息。从发送目标到真正到达，中间要经过几十秒甚至几分钟的执行，还可能需要随时取消或改变目标。Topic虽然也能发一个目标位置，但"执行中""执行失败""取消成功"这些状态反馈全得自己实现。ROS2的动作通信机制恰好是为长任务设计的：客户端发送goal，服务器回调确认，服务器持续发feedback，最终回result，整个生命周期都有明确状态。

用Topic、Service、Action怎么选，我是按这个标准来判断的。一次性查询用Service，比如查询语义坐标；持续高频状态流用Topic，比如激光扫描；需要跟踪进度且能取消的操作，全部走Action。导航目标正好落在第三种。Nav2对外暴露的/navigate_to_pose就是一个标准的NavigateToPose行动服务器，我们用ActionClient去连它。

from geometry_msgs.msg import PoseStamped from nav2_msgs.action import NavigateToPose from rclpy.action import ActionClient class NavExecutor(Node): def __init__(self): super().__init__('nav_executor') self.client = ActionClient(self, NavigateToPose, '/navigate_to_pose') self.client.wait_for_server(timeout_sec=10.0) def send_goal(self, x, y, yaw): goal = NavigateToPose.Goal() goal.pose.header.frame_id = 'map' goal.pose.header.stamp = self.get_clock().now().to_msg() goal.pose.pose.position.x = float(x) goal.pose.pose.position.y = float(y) goal.pose.pose.orientation.z = float(math.sin(yaw / 2)) goal.pose.pose.orientation.w = float(math.cos(yaw / 2)) future = self.client.send_goal_async(goal) future.add_done_callback(self.goal_accepted)

这段代码的结构在各类ROS2教程里很常见，但真正需要强调两个细节。第一个是frame_id，必须是map，不是odom、base_link。map是全局定位坐标系，odom是里程计局部系，目标点放错坐标系，规划出来的路径可能直接穿墙。第二个是yaw到四元数的转换，ROS2的PoseStamped要求四元数，直接用欧拉角赋给orientation.z是常见错误。send_goal_async返回的future回调里，还要继续订阅feedback，才能拿到实时导航进度，完整工程里这些回调函数是写在类里的，上面这段只保留核心结构。

下表是我在选型时常用的速查标准：

4. Nav2吃下目标点以后：从AMCL到行为树的执行链安排

4.1 AMCL定位与代价地图：先回答"我在哪"，再回答"怎么走"

NavGPT-2把目标点交给导航栈之后，第一件事不是规划路径，而是回答定位问题。AMCL是ROS2环境里最常用的2D激光定位方案。它用粒子滤波维护机器人位姿的分布，订阅激光雷达scan、tf变换、栅格地图，输出map坐标系下的机器人位姿估计。粒子数量直接影响定位精度和CPU开销。我实测过的经验值：室内30到50平方米场景，粒子数3000左右足够；办公楼长走廊这种特征稀疏的环境，要往上调到5000到8000。对应参数在amcl配置文件里是max_particles和min_particles。调参时同时观察rviz2里的粒子簇，粒子发散得厉害，说明观测约束不足，先加雷达频率或调高里程计噪声，不要一味加粒子数。

定位有了，就要回答"哪里能走"的问题。代价地图是Nav2做规划的空间依据。它由多层叠加：静态层使用已经建好的占据栅格地图，障碍物层实时融合激光点云，膨胀层负责把障碍物周围区域外扩，留出安全余量。对轮式底盘，八叉树地图或者3D体素地图不是必须的，但如果你要处理立体障碍或者斜坡，可以另起一个OctoMap层做碰撞检测；两种地图通过costmap插件并存，互不干扰。

robot_radius: 0.25 inflation_layer: inflation_radius: 0.55 cost_scaling_factor: 3.0 obstacle_layer: obstacle_range: 3.0 raytrace_range: 3.5

机器人半径robot_radius直接来自底盘参数，必须比实际车体外壳大5到10厘米。inflation_radius是膨胀半径，目标点被包进这个区域后，规划器会视为风险区域并绕行。cost_scaling_factor是衰减系数，值越大代价衰减越快，机器人越靠近障碍物。这几个参数是调导航手感最先动的地方，动完之后再去看速度限制。

AMCL的关键参数，我给一个常用的起步范围：

4.2 从目标点到行为树：让LLM的决策可以被分支处理

Nav2在较新版本里用行为树把整个导航流程串起来。行为树是一种比状态机更灵活的控制结构，它把导航动作拆成很多小节点：计算代价地图、规划全局路径、控制机器人跟踪路径、恢复行动。它们通过sequence和fallback等控制节点组合，实现"先规划，失败就重试，重试还不成就放弃或者原地旋转"这类逻辑。

行为树用XML描述，Nav2导航时加载一棵默认树。做LLM对接时，我习惯在自定义树里加一个专门的目标检查节点：目标点在代价地图外、在障碍物内部或者很可能是无解目标时，直接返回失败并让行为树走一条回复用户的路径。这样就避免了模型错误目标导致导航器傻傻地原地重规划。这也是LLM系统落地的一个通用原则：模型输出不是代码逻辑，必须靠外围控制结构兜底。

<root main_tree_to_execute="MainTree"> <BehaviorTree ID="MainTree"> <Sequence name="navigate_with_llm"> <CheckNavGPT2Validity target="{goal}"/> <NavigateToPose goal="{goal}"/> </Sequence> </BehaviorTree> </root>

上面的XML只是示意，实际Nav2树要复杂得多，但这种"先验证再执行"的结构非常值得保留。CheckNavGPT2Validity是自定义行为树节点，里面可以查代价地图，判断目标点是否处于free空间。这比在goal_router里做坐标边界检查更稳，因为它用的是导航栈自己维护的代价地图，而不是一份静态YAML表。

controller_server的局部规划参数也要跟着调：

4.3 rviz2里把整条链路可视化

我调试这套系统时的一个习惯是：永远开着rviz2。能直观看到的东西，不要靠猜。rviz2里加载map、tf、laser、path、goal_pose这些插件后，整条链路的运行状态会非常清晰。tf树正常，机器人模型不动，说明定位环节出问题；全局路径画出来了但机器人不走，说明局部规划或者控制环节出问题；全局路径根本没画出来，那多半是目标点合法性检查没过或者代价地图有问题。

可视化调试的同时，终端里配几个常用的查询命令并行看数据流。

ros2 topic echo /navgpt2/parsed_intent --once ros2 topic echo /goal_router/goal_pose --once ros2 node graph ros2 action info /navigate_to_pose

前三行分别确认意图、目标点、节点连通性，第四行看行动服务器状态。一个很常用的调试节奏是：rviz2负责看地图层面的违规，node graph负责看通信层面的断链，action info负责看导航任务当前到底处于哪个状态。这套组合排查，绝大多数联调问题不会超过十分钟。

5. 联调避坑：大模型与导航系统一起翻车的常见问题排查

5.1 目标点在墙里或地图外，导航器直接取消任务

现象描述：NavGPT-2给出的意图解析正常，goal_router也发出了PoseStamped，但/navigate_to_pose在收到goal几秒钟后直接取消，全局路径完全没有生成。

原因剖析：这类问题九成出在坐标落在未知区域或者障碍物内部。NavGPT-2输出的语义目标和查表坐标不一定精确，特别是aliases匹配到同义词后，目标点可能偏移到墙边甚至墙里。Nav2在行为树里发现目标不可达会进入恢复模式，恢复几次失败后直接取消任务。还有一部分情况是frame_id填错，比如从YAML读取的是odom坐标，却发到了map坐标系下。

解决过程：第一步，在goal_router节点里加坐标合法性检查，目标点超出map尺寸就丢弃并回问用户。第二步，在行为树里做一个目标有效性检查节点，调用costmap服务判断目标点是不是free空间，不是则尝试在膨胀层边缘找最近可达点。第三步，检查YAML里每个坐标是否来自rviz2记录的真实可达pose。把一个静态坐标表当成"必然可达"是常见的误判，建议每个语义目标在建图后统一复核一遍。

5.2 节点都在，话题却互相找不到

现象描述：ros2 node list里能看到llm_bridge和nav_executor，但另一边永远订阅不到消息；ros2 topic list里有话题名，却没有任何数据。

原因剖析：这是ROS2多机部署最容易遇到的DDS发现通信问题。ROS2底层走DDS协议，节点发现默认依赖UDP组播。跨网段、路由器禁组播、多网卡机器，都会导致发现的节点列表不完整。不少人第一次跑跨机就直接卡在这里，绕了一大圈最后发现是网段路由问题。

解决过程：先在同一台机器上确认单机通信无误，排除业务代码问题。然后跨机部署时，确保两端ROS_DOMAIN_ID一致，用export在两端都设置成同一个数字。再在网络层面查探防火墙是否放行对应的UDP端口。如果是多网卡环境，可以在DDS配置或环境变量里显式指定参与通信的网卡。零拷贝机制在这个阶段可以先放一边，它解决的是传输效率，不是发现失效。

提示

单机调试时把ROS_LOCALHOST_ONLY设为1可以关掉跨机发现，但跨机联调时这个变量必须移除，否则节点不可见。

5.3 定位漂移，机器人开着开着突然急停

现象描述：路径规划正常，机器人走出两三米后开始急促地前后左右调整，甚至原地绕圈，rviz2里的机器人位姿和真实位置明显不一致。

原因剖析：AMCL的位姿估计漂移了。最典型的原因是走廊这类环境在几何上高度相似，激光匹配得分区分度低，粒子分布收敛到错误位置；另一个原因是odom噪声参数设得太乐观，滤波器过于信任里程计，没有及时用激光修正。

解决过程：先观察rviz2里的粒子簇。粒子散开成一团说明观测约束不够，把amcl参数里的odom_alpha1到odom_alpha4适当调大，让模型允许里程计有更多误差。再检查激光雷达的帧率，帧率太低会加剧漂移。最根本的解决办法是给导航路线设计加入环境特征点，比如在走廊尽头放个箱子或标志物，让粒子滤波重新收敛得快一点。现实中具身智能导航卡在定位失败，远比卡在模型推理失败要多，环境工程本身就是系统的一部分。

5.4 话题有数据但导航器不接招，QoS策略不匹配

现象描述：ros2 topic hz能看到目标话题在持续发布，数据内容也正确，但nav_executor毫无反应，连日志都不打。

原因剖析：ROS2引入了服务质量QoS机制。发布方和订阅方必须满足兼容策略，否则消息会被系统丢弃。Nav2的NavigateToPose内部使用Reliable可靠性传输，而很多自定义节点默认用了best_effort策略，两边不匹配，消息悄悄消失。

解决过程：给自定义发布方显式设置QoS配置，可靠性设为Reliable，持久性设为TransientLocal，并且使用足够大的队列深度。我在3.2的llm_bridge骨架里没有写这个细节，因为单机测试时它容易蒙混过关；一旦目标话题被多个节点订阅，或者话题在节点启动后重建，问题就会冒出来。这是ROS2学习过程中最经典的"看起来通了，实际没通"陷阱。

5.5 中文同义词匹配失败，用户指令被错误解析

现象描述：用户说"去厨房操作台"，NavGPT-2返回的target是厨房灶台或者空白，导航去错了地方。

原因剖析：NavGPT-2的预训练语料以英文为主，中文命令经过分词后语义对齐不稳定。加上语义点表用英文ID做key，没有别名归一化环节，用户的"操作台""台面""灶台"几种说法映射到不同结果。

解决过程：在YAML里为目标添加aliases字段，匹配逻辑先精确匹配后别名包含匹配。同时在prompt里要求NavGPT-2输出标准化目标名称，比如限定"如果用户提到厨房相关的台面，target统一填kitchen_counter"。更稳妥的方案是加一个轻量的中文实体归一化步骤，在请求模型之前先把文本做同义词替换。大模型的输出不确定性，靠限制输出格式和词表是压不住的，必须在外围做归一化。

6. 进阶：把LLM的下一步交给行为树，再用ros2 bag回放压测

6.1 行为树编排多段导航

单目标跑通后，值得做的第一个进阶是多段导航："先回充电桩充十分钟电，再去厨房操作台"这类复合指令，可以在行为树里挂一个Sequence节点，把两个目标点按顺序执行。NavGPT-2的每一轮输出都变成一个树节点，树一方面决定下一段导航执行什么，另一方面把执行结果返回给模型决定是否继续。业界不少具身智能操作系统的架构研究，也把行为树作为任务编排的事实标准。这种结构能应对的任务复杂度，远高于在代码里写死的顺序调用。

6.2 ros2 bag回放，把真实现场带回办公桌

调试这套系统最痛苦的是每轮实验都要有人在机器人旁边发指令。ros2 bag记录话题数据并支持回放，把一次完整的交互过程打包：用户指令、模型输出、导航feedback、tf坐标变换都录下来。改完prompt或者参数后，回放同一段bag，让导航系统重新执行，就能判断改动是否真的变好。

ros2 bag record -o navgpt2_session \ /user/instruction /navgpt2/parsed_intent \ /odom /tf /scan /feedback

这个录制命令选择话题的思路是"只录输入和状态，不录路径规划输出"。回放的时候只重放用户指令话题，让NavGPT-2和Nav2重新推理，这样才能验证修改后的模型效果。如果连模型输出一起回放，就等于复读旧答案了。

6.3 用随机指令压测稳定性

还有一个压测习惯：写一个脚本用ros2 topic pub随机发出预置指令，一次跑半小时以上。关注两个指标，一个是节点是否异常退出，另一个是高延迟的模型推理是否造成话题堆积。NavGPT-2这类大模型推理时间波动很大，长尾请求可能卡到十几秒，如果llm_bridge没有超时保护，会把整个指令链路拖死。

这套系统我迭代下来的体会是：大模型落地机器人，本质不是把模型调聪明，而是把模型的输出约束好、把系统的失败兜住。模型置信度低不可怕，可怕的是下游照单全收；定位不准也不可怕，可怕的是没有在行为树里留退路。希望这套从NavGPT-2到ROS2再到Nav2的完整落地思路能帮到你，祝你在真机上少踩几个我踩过的坑。

本文还有配套的精品资源，点击获取