调优指南

本指南旨在帮助用户调整导航系统。虽然 配置指南 是所有 Nav2 参数列表的主页,但它并没有包含太多有关如何使用其中最重要的参数调整系统的*细节*。本指南的目的是提供更多关于如何设置系统的建议,而不仅仅是首次设置,您可以在 首次机器人设置指南 找到这些建议。这绝不会涵盖所有参数(因此,请查看您感兴趣的软件包的配置指南),但会提供一些有用的提示和技巧。

本调整指南是一项持续不断的工作。如果您发现一些您遗漏的见解,请随时提交工单或拉取请求,分享您想要分享的智慧。这是一个由 Nav2 用户和维护者慷慨支持的开放部分。请考虑回馈社会。

通货膨胀势场

维护人员发现,许多用户和生态系统导航配置文件都忽略了膨胀层的要点。虽然您可以简单地在墙壁周围膨胀一小段半径来防止发生严重碰撞,但膨胀层的*真正*价值是在整个地图周围创建一个一致的潜在场。

一些最受欢迎的 ROS 导航/Nav2 调整指南甚至“特别提到了这一点<https://arxiv.org/pdf/1706.09068.pdf>”_ 在应用了铭刻成本后,在整个地图宽度上创建一个平缓的潜在场会带来很大的好处,但实际上很少有用户这样做。

这种习惯实际上导致 NavFn、Theta* 和 Smac Planner 生成的路径有些不理想。他们真的想寻找一个平滑的潜在场,而不是宽阔的 0 成本空间,以便停留在空间中间并更好地处理附近的移动障碍物。它将允许在搜索算法遇到导致膨胀的障碍物之前就将搜索重点放在自由空间上,让规划器尽可能地避开障碍物。

因此,维护人员以及 ROS 中所有其他具有成本意识的搜索规划器都建议增加膨胀层成本规模和半径,以便在整个地图上充分产生平滑的势能。对于非常大的开放空间,在中间有 0 成本区域是可以的,但对于大厅、过道等;请创建平滑的势能以提供最佳性能

机器人占地面积与半径

Nav2 允许用户以两种方式指定机器人的形状:几何“足迹”或环绕机器人的圆的半径。在 ROS (1) 中,始终指定机器人的半径近似值是相当合理的,因为全局规划算法不使用它,并且本地规划器/成本地图是使用圆形假设设置的。

但是,在 Nav2 中,我们现在有多个利用完整 SE2 足迹的规划和控制器算法。如果您的机器人不是圆形的,建议您为规划器和控制器提供机器人的实际几何足迹。这将允许规划器和控制器规划或创建进入更狭窄空间的轨迹。例如,如果您有一个非常长但很瘦的机器人,圆形假设不允许机器人规划到仅比您的机器人宽一点的空间,因为机器人在长度上不适合。

运动学上可行的规划器(例如 Smac Hybrid-A*、Smac State Lattice)将使用 SE2 足迹进行碰撞检查,以创建运动学上可行的计划(如果提供了实际足迹)。截至 2021 年 12 月,所有控制器插件都支持完整足迹碰撞检查,以确保安全的路径跟踪。如果您提供机器人的足迹,它将用于确保轨迹有效,建议您这样做。这将防止许多本来可以轻松避免的“机器人卡住”情况。

如果您的机器人确实是圆形的,请继续使用“robot_radius”参数。非圆形机器人改用半径的三个有效理由:

  • 机器人相对于环境而言非常小(例如仓库中的遥控车)

  • 机器人的计算能力非常有限,使用 SE2 足迹检查会增加过多的计算负担(例如嵌入式微处理器)

  • 如果您计划使用完整规划器(例如 Theta*、Smac 2D-A* 或 NavFn),您可以继续使用圆形足迹,因为这些规划器在运动学上不可行,而且无论如何都不会使用 SE2 足迹。

原地旋转行为

使用 Rotation Shim Controller,机器人将在开始跟踪完整路径之前简单地原地旋转。这允许开发人员调整控制器插件以优化路径跟踪,并为您提供开箱即用的干净旋转。

这是由于某些现有控制器中的怪癖而添加的,而调整任务的控制器可能会使其变得僵化 - 或者算法在使用完整路径时根本不原地旋转(如果这是理想的特性)。当机器人的初始和路径方向明显不同时,结果是一种尴尬、卡顿或四处乱转的行为。为控制器提供一个更好的起点来开始跟踪路径,可以使控制器的调整变得容易得多,并为旁观者创造更直观的结果(一位维护者认为)。

注意:如果使用非完整的、运动学上可行的规划器(例如 Smac Hybrid-A*、Smac State Lattice),这不是必要的行为优化。此类规划器将创建考虑机器人起始航向的计划,不需要任何旋转行为。

此行为最适合:

  • 可以原地旋转的机器人,例如差速机器人和全向机器人。

  • 当开始跟踪与机器人当前航向明显不同的新路径时,或者当调整控制器以执行任务导致紧密旋转变得困难时,优先原地旋转。

规划器插件选择

Nav2 提供了许多现成的规划插件。首次设置时,请参阅 设置 以详细了解 Nav2 中的算法样式,并参阅 导航插件 以全面了解当前可用的插件列表(可能会随时间更新)。

但总体而言,下表是针对不同类型机器人基座的最佳规划插件的良好指南:

Plugin Name

Supported Robot Types

NavFn Planner

Circular Differential, Circular Omnidirectional

Smac Planner 2D

Theta Star Planner

Smac Hybrid-A* Planner

Non-circular or Circular Ackermann, Non-circular or Circular Legged

Smac Lattice Planner

Non-circular Differential, Non-circular Omnidirectional, Arbitrary

如果您使用的是计算能力非常有限的非圆形机器人,则可能值得评估使用其中一个完整规划器(例如粒子假设规划器)的好处。维护人员建议首先开始使用适合您平台的更高级算法之一,但在需要时缩减规划器。可行规划器的运行时间通常与完整规划器相当(有时甚至更快),因此不要让它们较新的性质欺骗您。

由于规划问题主要由机器人类型驱动,因此该表准确地总结了维护人员对用户的建议。在圆形机器人体制内,规划算法的选择取决于应用和期望的行为。NavFn 通常会制作宽阔的曲线;Theta* 更喜欢直线并以任何角度支持它们;而 Smac 2D 本质上是一种具有成本意识惩罚的经典 A* 算法。

Note

这些只是社区默认的和可用的插件。对于特定的应用程序/平台,您也可以选择不使用任何插件,而是创建自己的插件,这就是 Nav2 框架的意图。有关更多详细信息,请参阅 编写新的 Planner 插件 教程。如果您愿意将这项工作回馈给社区,请提交工单或联系维护者!他们很乐意听到您的意见。

控制器插件选择

Nav2 提供了许多现成的控制器插件。对于首次设置,请参阅 设置 以更详细地细分 Nav2 中的算法样式,并参阅 导航插件 以全面了解当前可用的插件列表(可能会随时间更新)。

但总体而言,下表是对不同类型的机器人底座可用的控制器插件的良好一阶描述:

Plugin Name

Supported Robot Types

Task

DWB controller

Differential, Omnidirectional

Dynamic obstacle avoidance

Dynamic obstacle avoidance

MPPI Controller

Differential, Omnidirectional, Ackermann, Legged

RPP controller

Differential, Ackermann, Legged

Exact path following

Rotation Shim

Differential, Omnidirectional

Rotate to rough heading

VP controller

Differential, Ackermann, Legged

High speed path tracking

所有上述控制器都可以处理圆形和任意形状的机器人。

受控的 Pure Pursuit 适用于精确的路径跟踪,通常与运动学上可行的规划器之一(例如 State Lattice、Hybrid-A* 等)配对,因为已知这些路径在给定严格物理约束的情况下是可行路径。但是,它也可以应用于差速驱动机器人,这些机器人可以轻松旋转以匹配任何完整路径。如果您只是希望机器人精确地跟随路径,而无需任何动态避障或偏差,那么这是首选插件。它简单而几何,并且在附近有障碍物*和*急转弯时会减慢机器人的速度。

DWB 和 MPPI 都是可以跟踪路径的选项,但如果存在动态障碍物(为了避开它们),它们也会偏离路径。DWB 通过在一组批评者上对多条轨迹进行评分来实现这一点。这些轨迹也是通过可替换的插件生成的,但支持在有效速度和加速度限制范围内开箱即用的 Omni 和 Diff 机器人类型。这些批评者是可以在运行时选择的插件,包含可以调整以创建所需行为的权重,例如最小化路径距离、最小化到目标或航向的距离以及可以设计的其他动作惩罚。这确实需要针对给定的平台、应用程序和所需行为进行一些调整,但可以调整 DWB 以很好地完成几乎任何一件事。

另一方面,MPPI 实现了一种基于优化的方法,使用先前最佳轨迹的随机扰动样本来最大化一组基于插件的目标函数。在这方面,它类似于 DWB,但 MPPI 是一种更现代、更先进的技术,它将处理环境中的动态代理,并根据基于优化的轨迹规划而不是 DWB 的恒定动作模型创建智能行为。然而,MPPI 的计算成本确实略高,但强烈建议采用这种方式,并且由于其强大功能,它已获得大量开发资源和关注。这通常开箱即用,但要针对特定​​行为进行调整,您可能需要重新调整某些参数。此包的 README.md 文件包含有关如何有效调整它的详细信息。

旋转垫片插件有助于协助 TEB 和 DWB 等插件在开始跟踪路径之前将机器人原地旋转到新路径的方向。这允许您调整本地轨迹规划器以按照所需的行为运行,而不必担心能够在非常小的欧几里得距离内以显著的角度距离偏差旋转。一些控制器在为精确的路径跟踪进行大量调整时,其动作会受到限制,并且无法非常干净地旋转到新方向。其他控制器具有“螺旋式”行为,因为它们的采样需要一定的平移速度,从而阻止其简单地原地旋转。这有助于缓解该问题,并使机器人非常平稳地在原地旋转。

最后,Vector Pursuit 是另一种很好的路径跟踪解决方案,与 RPP 一样,它与运动学上可行的规划器配对。它比 RPP 更先进一点,因为它还考虑了路径方向。Vector Pursuit 可以高速处理复杂路径,但它仍然是一个简单的几何控制器,因此需要的计算资源较少。

Note

这些只是社区默认的可用插件。对于特定的机器人平台/公司,您也可以选择不使用任何插件,而是创建自己的插件。有关更多详细信息,请参阅:ref:writing_new_nav2controller_plugin 教程。如果您愿意将这项工作回馈给社区,请提交工单或联系维护人员!他们很乐意听到您的意见。

在 Smac 规划器中缓存障碍启发式方法

Smac 的 Hybrid-A* 和 State Lattice 规划器提供了一个选项“cache_obstacle_heuristic”。这可用于缓存启发式算法,以便在重新规划到相同目标姿势之间使用,这可以**显著**提高规划器的速度(40-300%,具体取决于许多因素)。障碍启发式算法用于引导机器人进入空间中间,尊重成本,并推动运动学上可行的搜索沿着走廊找到有效的解决方案。可以将其想象成一个 2D 成本感知搜索,当规划器需要在完全可行搜索/SE2 碰撞检查中付出更多努力时,它可以“引导”规划器应该去哪里。

这对于加快性能以实现更好的重新规划速度很有用。但是,如果您缓存此启发式算法,它将不会使用成本图中的最新信息进行更新以引导搜索。在规划过程中,规划器仍将使用最新的成本信息进行碰撞检查,因此这不会影响路径的安全性。但是,它可能会引导搜索沿着新阻塞的走廊进行,或将搜索引导到可能有新的动态障碍物的区域,如果整个解决方案空间都被阻塞,这可能会大大减慢速度。

因此,维护人员建议仅在工作在基本静态(例如,没有太多移动的东西或变化,不使用全局成本地图中的实时传感器更新等)环境中,在跨大空间规划单个目标时启用此功能。在目标更改为 Nav2 之间,此启发式方法将使用最新的信息集进行更新,因此如果您频繁更改目标,它就没什么用。

Costmap2D插件

Costmap2D 有许多可供您使用的插件(包括可供您创建的插件!)。

  • StaticLayer:用于设置来自 SLAM 的地图(预构建或当前正在实时构建),以调整环境大小并设置关键功能,如用于全局规划的墙壁和房间。

  • InflationLayer:使用指数函数膨胀致命成本,以帮助引导导航算法远离墙壁并快速检测碰撞

  • ObstacleLayer:用于 2D 平面激光雷达的 2D 成本图层,或者在 3D 传感器上无法使用 3D 图层的低计算设备上使用。如果您有足够的计算能力,请使用 VoxelLayer 来处理 3D 数据,以提供更准确的结果。

  • VoxelLayer:用于非平面 2D 激光雷达或基于光线投射清除的深度相机处理的 3D 成本图层。由于收集的数据稀疏,不适用于 3D 激光雷达。

  • SpatioTemporalVoxelLayer:3D 激光雷达、非平面 2D 激光雷达或基于时间衰减的深度相机处理的 3D 成本地图层。适用于具有高传感器覆盖范围的机器人,如 3D 激光雷达或许多深度相机,由于缺乏光线投射,计算开销较低。

  • RangeLayer:为成本地图包含建模声纳、红外传感器或其他范围传感器

  • DenoiseLayer:从最终成本地图中去除盐和胡椒噪声,以消除未过滤的噪声。还可以选择删除可配置大小的群集,以消除动态障碍物的影响,而不会出现时间衰减。

此外,代价地图过滤器: - KeepoutFilter:在代价地图中标记禁区、高权重或低权重区域 - SpeedFilter:根据位置降低或增加机器人速度 - BinaryFilter:在特定区域启用或禁用二进制主题

注意:当成本地图过滤器可以与“VectorObject”服务器配对时,可以使用矢量化区域,而不是共享同一软件的地图栅格区域。

我们很乐意提供的其他页面

如果您愿意参与,可以参阅 https://github.com/ros-planning/docs.nav2.org/issues/204 中提供的一些想法,但我们也欢迎您提出任何有见地的意见!