``` bash
root@nvidia:~/ros2_ws# ros2 topic echo /goal_pose
header:
  stamp:
    sec: 1776912839
    nanosec: 772353086
  frame_id: map
pose:
  position:
    x: -0.2929971516132355
    y: -28.93631362915039
    z: 0.0
  orientation:
    x: 0.0
    y: 0.0
    z: -0.7140266359687852
    w: 0.7001185350546718
---
header:
  stamp:
    sec: 1776912894
    nanosec: 349057427
  frame_id: map
pose:
  position:
    x: 1.0191293954849243
    y: -23.940237045288086
    z: 0.0
  orientation:
    x: 0.0
    y: 0.0
    z: -0.758253550259611
    w: 0.6519597790651626
---
header:
  stamp:
    sec: 1776912930
    nanosec: 59193832
  frame_id: map
pose:
  position:
    x: -0.25821736454963684
    y: -26.604511260986328
    z: 0.0
  orientation:
    x: 0.0
    y: 0.0
    z: -0.7286561115363753
    w: 0.6848797493872113
---
header:
  stamp:
    sec: 1776913007
    nanosec: 811936088
  frame_id: map
pose:
  position:
    x: -0.5403046607971191
    y: -23.95861053466797
    z: 0.0
  orientation:
    x: 0.0
    y: 0.0
    z: -0.7323575592769619
    w: 0.6809202635917743
---
header:
  stamp:
    sec: 1776913105
    nanosec: 601216801
  frame_id: map
pose:
  position:
    x: -0.13717754185199738
    y: -31.840221405029297
    z: 0.0
  orientation:
    x: 0.0
    y: 0.0
    z: -0.6531641242066932
    w: 0.7572163672618966
---

```

雷达同步问题
```
ros2_ws\src\rslidar_sdk\config\config.yaml
use_lidar_clock: false
```


```
 ---
  ⚠️ 警告1：No goal checker was specified in parameter 'current_goal_checker'. Server will use only plugin loaded
  general_goal_checker

  含义

  这是配置缺失类警告，不影响功能，只是提示你没有显式指定当前使用的目标检查器，系统自动用了第一个加载的general_goal_check
  er。
  根因

  ROS2 Humble及以上版本的Nav2新增了current_goal_checker强制配置项，你的配置里只定义了goal_checker插件，但没有指定当前使
  用哪一个。
  ✅ 解决方案

  在controller_server的ros__parameters下添加一行即可：
  controller_server:
    ros__parameters:
      current_goal_checker: "general_goal_checker"  # 新增这行
      controller_frequency: 20.0
      # ... 其他原有配置

  ---
  ⚠️ 警告2：Behavior Tree tick rate 100.00 was exceeded!

  含义

  这是性能类警告，行为树默认tick频率是100Hz（每10ms执行一次），现在单次tick执行时间超过了10ms，导致频率不达标。
  根因

  行为树中的计算密集型节点执行太慢，90%的情况是MPPI控制器计算耗时过长，小概率是系统CPU负载过高、规划器卡顿等。
  ✅ 排查&解决方案

  1. 先看CPU占用：top 看controller_server进程的CPU占比，如果超过100%就是计算量太大
  2. 优先优化MPPI参数（你的当前配置计算量过高），后面警告3会详细说
  3. 实在优化不了可以调大BT的tick间隔，在bt_navigator下加：
  bt_navigator:
    ros__parameters:
      bt_loop_duration: 20  # 从10ms改成20ms，频率降到50Hz，不推荐，优先优化控制器

  ---
  ⚠️ 警告3：Control loop missed its desired rate of 20.0000Hz

  含义

  这是核心性能警告，控制器要求20Hz的控制频率（每50ms输出一次速度指令），现在单次循环执行超过了50ms，频率不达标。
  ⚠️ 这个问题必须优先解决：控制频率低于15Hz会导致MPPI控制不稳定，甚至出现急刹、撞障碍物的情况。
  根因

  你的MPPI配置计算量过大，两个核心参数超标：
  FollowPath:
    batch_size: 2000  # 单次迭代采样2000条轨迹，计算量极大
    time_steps: 56    # 每条轨迹预测56步（0.05*56=2.8秒预测时长）
  - 2000的batch_size在Jetson NX级别的嵌入式平台单次计算就要60-80ms，肯定达不到50ms的要求
  - 额外加重负载的配置：local costmap的obstacle_max_range: 20.0，local
  costmap本身只有6m×6m，处理20米内的点云完全是浪费CPU
  ✅ 解决方案（按优先级）

  1. 调小MPPI计算量（优先保证控制频率达标）：
  FollowPath:
    batch_size: 1000  # 降到800-1200，轨迹采样数减半，性能提升一倍，效果下降不明显
    time_steps: 40    # 降到32-40，预测时长2秒足够，履带车速度慢不需要太长预测
  2. 缩小local costmap障碍物检测范围：
  # local_costmap的voxel_layer下的scan配置
  obstacle_max_range: 10.0  # 从20米改成10米，足够覆盖6m的local costmap范围
  3. 验证效果：改完后用ros2 topic hz /cmd_vel_nav看频率，稳定在18Hz以上就算合格

  ---
  ❌ 错误1：Failed to create a plan from potential when a legal potential was found. This shouldn't happen.

  含义

  这是Navfn规划器内部错误：规划器已经算出了从起点到终点的势场（理论上存在可行路径），但实际提取路径的时候失败了。
  根因

  结合你的配置，最可能的几个原因：
  4. 可行通道太窄：你的膨胀半径是1.8m，车身本身宽1.8m，通道宽度必须大于3.6m才能通过，如果路径上有窄于这个宽度的通道，膨
  胀后就没有可行空间了
  5. 起点/终点落在膨胀区内：虽然势场是通的，但膨胀后的代价太高，路径提取的时候找不到合法的起点/终点
  6. 膨胀半径过大：1.8m的膨胀半径刚好是车身宽度，没有冗余，稍微有点障碍物就会把通道堵死
  7. 全局costmap噪点过多：点云误检的障碍物挡住了路径
  ✅ 排查&解决方案

  8. 排查路径情况：规划失败时，在rviz上看起点到终点的通道宽度，是不是小于3.6m
  9. 优化膨胀半径（如果通道普遍较窄）：
  # 全局和局部costmap的inflation_radius都可以降到1.5m（只要大于车身最大半长1.2m就满足SMAC优化要求）
  inflation_radius: 1.5
  10. 优化Navfn参数：
  GridBased:
    tolerance: 1.0  # 从0.5米改成1.0米，允许终点有更大的容忍范围
  11. 终极方案：换规划器：如果经常走窄通道，把Navfn换成nav2_smac_planner/SmacPlanner，对窄通道的支持好很多
  12. 检查全局costmap噪点：如果有很多误检的小障碍物，调大mark_threshold过滤噪点

  ---
  ❌ 错误2：Failed to get result for follow_path in node halt!

  含义

  这是次生错误，不影响功能，只是日志提示：行为树在终止（halt）的时候，尝试获取follow_path节点的执行结果，但结果不存在。
  根因

  完全是前面的规划失败导致的连锁反应：规划失败后整个导航任务提前终止，follow_path节点还没来得及产生结果就被强制停止了。
  ✅ 解决方案

  解决前面的规划失败问题后，这个错误会自动消失，不需要单独处理。

  ---
  🎯 解决优先级建议

  13. 【最高优先级】先解决控制循环频率不够的问题，直接影响导航安全性
  14. 【次高优先级】解决规划失败的问题，影响导航可用性
  15. 【低优先级】解决剩下的配置类警告，不影响功能只是优化日志

  额外优化建议

  你现在的voxel层mark_threshold: 10有点太高了，需要10个点才能标记障碍物，容易漏检小障碍物，建议调到3-5更合适：
  voxel_layer:
    mark_threshold: 3  # 从10改成3，平衡噪点过滤和小障碍物检测
```