Nav2官方文档阅读（一）Navigation相关概念

参考链接：https://navigation.ros.org/concepts/index.html

     此页面旨在帮助新机器人专家熟悉移动机器人导航的概念，特别是了解和使用该项目所需的概念。

ROS 2 

ROS 2 是用于 Nav2 的核心中间件。 如果您对此不熟悉，请在继续之前访问 ROS 2 文档。

Action Server

就像在 ROS 中一样，action server是控制导航等长时间运行任务的常用方法。 此堆栈更广泛地使用action，并且在某些情况下，没有简单的topic界面。 作为 ROS 2 中的开发人员，了解动作服务器更为重要。一些简单的 CLI 示例可以在 ROS 2 文档中找到。

action server类似于普通的service server。 客户端会请求完成某个任务，但该任务可能需要很长时间。 例如，将铲子从推土机上移开或让机器人向右移动 10 米。

在这种情况下，action servers 和 clients 允许我们在另一个进程或线程中调用长时间运行的任务，并为其结果返回一个 future 。 此时允许阻塞直到操作完成，但是，您可能希望偶尔检查操作是否完成并继续在客户端线程中处理工作。 由于它是长期运行的，action servers 也会向其客户端提供反馈。 这个反馈可以是任何东西，并且在 ROS .action 中与请求和结果类型一起定义。 在推土机示例中，请求可能是一个角度，反馈可能是要移动的剩余角度，结果是带有结束角度的成功或失败布尔值。 在导航示例中，请求可能是一个位置，反馈可能是导航的时间和到目标的距离，结果是成功的布尔值。

注：我们需要为每一 action server 预先定义一种 action 和 message、service类似，这里可以按照你的需要定义任何数据类型，并把定义好的 action 添加给ROS2，之后就可以建立一个Node，并为其添加 server或者client，使其成为一个server节点或者client节点。具体可以查看官方文档关于action的示例。

通过向动作客户端注册回调，可以同步收集反馈和结果。 它们也可以通过从共享的 furture 对象异步请求信息来收集。 两者都需要客户端节点 spin() 来处理回调组。

该堆栈中使用action server通过 NavigateToPose 动作消息与最高级别的 BT (behavior tree)导航器进行通信。 它们还用于 BT 导航器与后续较小的action server通信，以计算plan、control和recovery。 每个在 nav2_msgs 中都有自己独特的 .action 类型，用于与服务器交互。

注：

1.Nav2中主要的几个动作就是全局规划plan，局部规划control，脱困恢复recovery

2.BT（behavior tree）是ROS2中用于机器人行动决策的基本工具，底层使用的behaviortree_cpp_v3，在此基础上进行了封装，成为了nav2_behavior_tree里的各种插件，当然也可以根据自己的需求编写自己的插件。

Lifecycle Nodes and Bond

生命周期节点（或更准确地说是托管节点）是 ROS 2 独有的。更多信息可以在这里找到。 它们是包含用于启动和拆除 ROS 2 服务器的状态机转换的节点。 这有助于确定 ROS 系统在启动和关闭时的行为（例如启动系统之前需要确保传感器都加载完毕）。 它还帮助用户以合理的方式构建他们的程序以用于商业用途和调试。

当一个节点启动时，它处于未配置状态(unconfigured)，只处理节点的构造函数，不应包含任何 ROS 网络设置或参数读取。 通过启动系统或提供的生命周期管理器，需要通过配置(unconfiguring)将节点转换为非活动(inactive)状态。 之后，可以通过过渡到激活(activing)阶段来激活节点。

此状态将允许节点处理信息并完全设置为运行。 配置阶段触发 on_configure() 方法，将设置所有参数、ROS 网络接口以及安全系统，所有动态分配的内存。 激活阶段，触发 on_activate() 方法，将激活 ROS 网络接口并设置程序中的任何状态以开始处理信息。

为了关闭，我们过渡到停用(deactivating)、清理(cleaning up)、关闭(shutting down)并以最终状态结束。 网络接口分别在这些阶段被停用和停止处理、释放内存、干净地退出。

整个项目中广泛使用生命周期节点框架，所有服务器都使用它。 如果可能，所有 ROS 系统最好使用生命周期节点。

在 Nav2 中，我们使用 LifecycleNodes 的封装 nav2_util LifecycleNode。 这个封装为典型的应用程序包装了 LifecycleNodes 的大部分复杂性。 它还包括生命周期管理器的绑定连接，以确保在服务器转换后，它也保持活动状态。 如果服务器崩溃，它会让生命周期管理器知道并关闭系统以防止发生严重故障。 有关详细信息，请参阅 Eloquent to Foxy。

 

Behavior Trees

行为树 (BT) 在复杂的机器人任务中变得越来越普遍。 它们是要完成的任务的树形结构。 它创建了一个更具可扩展性和人类可理解性的框架，用于定义多步骤或多状态应用程序。 这与有限状态机 (FSM) 相对，后者可能有几十个或多个状态和数百个转换。 一个例子是踢足球的机器人。 将足球比赛的逻辑嵌入到 FSM 中将具有挑战性，并且容易出错，有许多可能的状态和规则。 此外，诸如从左侧、右侧或中心射门之类的建模选择尤其不清楚。 使用 BT，可以为许多行为创建和重用基本原语，如“踢”“走”“去球”。 更多信息可以在这本书中找到。 我强烈建议阅读第 1-3 章以更好地理解术语和工作流程。 它应该只需要大约 30 分钟。

对于这个项目，我们使用 BehaviorTree CPP V3 作为行为树库。 我们在 BT Navigator 中创建了可以构建为树的节点插件。 节点插件被加载到 BT 中，当解析树的 XML 文件时，注册的名称是相关联的。 此时，我们可以通过行为树进行导航

使用这个库的一个原因是它能够加载子树。 这意味着可以将 Nav2 行为树加载到另一个更高级别的 BT 中，以使用该项目作为节点插件。 一个例子是在足球比赛中，使用 Nav2 行为树作为“去球”节点，将球检测作为更大任务的一部分。 此外，我们为 BT 提供了一个 NavigateToPoseAction 插件，因此可以从客户端应用程序通过通常的操作接口调用 Nav2 堆栈。

Navigation Servers

规划器planner和控制器controler是导航任务的核心。 恢复recovery用于使机器人摆脱不良情况或尝试处理各种形式的问题以使系统具有容错能力。 在本节中，将分析围绕它们的一般概念及其在本项目中的用途。

Planner, Controller, and Recovery Servers

本项目中的三个动作服务器是计划器、恢复和控制器服务器。 这些动作服务器用于托管算法插件的地图以完成各种任务。 它们还托管算法插件用于计算其输出的环境表示。

计划器和控制器服务器将在运行时使用名称（别名）和要使用的算法类型进行配置。 这些类型是已注册的插件库名称，名称是任务的别名。 一个示例是使用名称 FollowPath 的 DWB 控制器，因为它遵循参考路径。 在这种情况下，DWB 的所有参数都将放置在该命名空间中，例如 FollowPath.。

然后，这两个服务器公开与其任务对应的操作接口。 当行为树勾选相应的BT节点时，它会调用动作服务器来处理它的任务。 服务器内的动作服务器回调将通过映射到特定算法的名称（例如 FollowPath）调用所选算法。 这允许用户将行为树中使用的算法抽象为算法类。 例如，您可以使用 N 个插件控制器来跟踪路径、与充电器对接、避开动态障碍物或与工具交互。 在同一服务器中拥有所有这些插件允许用户使用单个统一的一个对象来描述任务所处环境，否则复制起来很费尽。

或者，由于 BT 节点是调用动作的简单插件，因此可以创建新的 BT 节点来调用具有其他动作类型的其他动作服务器。 如果可能，建议始终使用提供的服务器。 如果由于插件或操作接口，需要新服务器，则可以通过框架维持。 新服务器应该使用新的类型和插件接口，类似于提供的服务器。 需要创建一个新的 BT 节点插件来调用新的动作服务器——但是通过广泛使用服务器和插件，不需要在 Nav2 存储库本身中进行分叉或修改。

Planners

规划器的任务是计算完成某个目标函数的路径。 路径也可以称为路线，具体取决于所选的命名法和算法。 两个典型的例子是计算一个目标的计划（例如从当前位置到一个目标）或完全覆盖（例如覆盖所有可用空间的计划）。 规划者将可以访问全局环境表示（global costmap）和缓存在其中的传感器数据。 Planner可以：

计算最短路径
计算完整的覆盖路径
沿着稀疏或预定义的路线计算路径

Nav2 中规划器的一般任务是计算从当前姿势到目标姿势的有效且可能最佳的路径。 但是，存在许多受支持的计划和路线类别。

Controllers

控制器，在 ROS 1 中也称为本地规划器，是我们遵循全局计算路径或完成本地任务的方式。 控制器将有权访问本地环境表示（local costmap），并以此来计算出一个可行的控制信号让底盘来执行。 许多控制器将机器人在空间中向前投射，并在每次更新迭代时计算局部可行路径。 控制器可以：

跟踪一条路径
使用里程计框架中的检测器与充电站对接
登上电梯
与工具的接口

Nav2 中控制器的一般任务是计算出可行的控制方案来追踪全局路径。 但是，存在许多类型的控制器和本地规划器。 该项目的目标是所有控制器算法都可以作为该服务器中的插件，用于常见的研究和工业任务。

Recoveries

恢复是容错系统的支柱。 恢复的目标是处理系统的未知或故障情况并自主处理它们。例如如果感知系统中出现了故障，会导致感知到的环境中充满虚假的障碍物。 恢复行为可以清除costmap让机器人移动可以继续移动。

另一个例子是机器人由于动态障碍物或控制不佳而被卡住。 在允许的情况下，倒退或原地旋转可以让机器人从恶劣的位置移动到它可以成功导航的自由空间。

最后，在完全故障的情况下，恢复行为可以呼叫工作人员介入帮助。 这可以通过电子邮件、短信、Slack、Matrix 等来完成。

Waypoint Following

定点巡逻是导航系统的基本功能，它告诉我们的系统如何使用导航到达多个目的地。

nav2_waypoint_follower 包含一个航点跟随程序，带有用于特定任务执行器的插件接口。 如果您需要前往给定位置并完成特定任务（例如拍照、拿起盒子或等待用户输入），这将非常有用。 这是一个很好的演示应用程序，用于说明如何在示例应用程序中使用 Nav2。

但是，它不仅可以用于示例应用程序。 有两种经典的机器人集群管理/调度方案。 傻瓜器人+ 智能集中调度器或者智能机器人+ 傻瓜集中调度器。

第一中情况里，nav2_waypoint_follower 完全足以创建生产级的机器人解决方案。 由于自治系统/调度员在分配任务时会考虑机器人的姿势、电池电量、当前任务等因素，因此机器人上的应用程序只需要担心手头的任务，而不是系统的其他复杂性 完成要求的任务。 在这种情况下，您应该将向航点跟随者发出的请求视为 1 个工作单元（例如，仓库中的 1 个拣货、1 个安全巡逻循环、1 个过道等）来执行任务，然后返回给调度员进行下一个任务 任务或要求充电。 在这种思想流派中，航点跟随应用程序只是导航之上和系统自治应用程序之下的一步。

在第二种情况中，nav2_waypoint_follower 是一个很好的示例应用程序/概念证明，但您确实需要机器人上的航点跟踪/自治系统来承载更多，以制定一个强大的解决方案。 在这种情况下，您应该使用 nav2_behavior_tree 包创建自定义应用程序级行为树，使用导航来完成任务。 这可以包括子树，例如在任务中检查充电状态以返回码头或在更复杂的任务中处理 1 个以上的工作单元。 很快，将有一个 nav2_bt_waypoint_follower（名称可能会调整），让您可以更轻松地创建此应用程序。 在这种思想流派中，航点跟随应用与系统自主性更紧密地联系在一起，或者在许多情况下，本身就是系统自主性。

两者没有伯仲之分，这在很大程度上取决于您的机器人正在完成的任务、在什么类型的环境中以及可用的云资源。 对于给定的业务案例，这种区别通常非常明显。

State Estimation

根据社区标准，在导航项目中，需要提供 2 个主要转换。 map to odom 变换由定位系统（localization, mapping, SLAM）提供，odom to base_link 由里程计系统提供。

Standards

REP 105 定义了导航和更大的 ROS 生态系统所需的框架和约定。 应始终遵循这些约定，以利用社区中可用的丰富定位、里程计和 slam 项目。

简而言之，REP-105 要求必须至少为你的机器人构建一个包含完整map -> odom -> base_link -> sensor 的 TF 树。 TF2 是 ROS 2 中的时变转换库，我们用来表示和获取时间同步转换。 全局定位系统（GPS、SLAM、动作捕捉）的工作至少是提供map -> odom 转换。 然后是里程计系统的作用是提供 odom -> base_link 转换。 与 base_link 相关的其余转换应该是静态的并在您的 URDF 中定义。

Global Positioning: Localization and SLAM

全局定位系统（GPS、SLAM、动作捕捉）的工作至少是提供map -> odom 转换。 我们提供 amcl，这是一种基于粒子滤波器的自适应蒙特卡罗定位技术，用于静态地图的定位。 我们还提供 SLAM Toolbox 作为默认 SLAM 算法，用于定位和生成静态地图。

这些方法也可能产生其他输出，包括位置主题、地图或其他元数据，但它们必须提供有效的转换。 可以使用机器人定位将多种定位方法融合在一起，下面将详细讨论。

Odometry

里程计系统的作用是提供odom -> base_link 转换。 里程计可以来自许多来源，包括激光雷达、雷达、车轮编码器、VIO 和 IMU。 里程计的目标是提供基于机器人运动的平滑连续的局部坐标系。 全局定位系统将更新相对于全球框架的变换以解决里程计漂移。

机器人定位通常用于这种融合。 它将采用 N 个各种类型的传感器，并为 TF 和主题提供连续和平滑的里程计。 典型的移动机器人设置可能具有来自车轮编码器、IMU 和视觉的融合。

平滑输出然后可用于精确运动的航位推算和在全局位置更新之间准确地更新机器人的位置。

Environmental Representation

环境表征是机器人感知环境的方式。 它还充当各种算法和数据源的中心定位，将它们的信息组合到一个空间中。 然后，控制器、计划人员和恢复人员使用该空间来安全有效地计算他们的任务。

Costmaps and Layers

当前的环境表示是一个成本图。 成本图是一个规则的 2D 单元格网格，其中包含来自未知、空闲、占用或膨胀成本的成本。 然后搜索此成本图以计算全局计划或采样以计算本地控制工作。

各种成本地图层被实现为 pluginlib 插件，以将信息缓冲到成本地图中。 这包括来自 LIDAR、RADAR、声纳、深度、图像等的信息。在将传感器数据输入到代价地图层之前对其进行处理可能是明智的，但这取决于开发人员。

可以创建 Costmap 层来检测和跟踪场景中的障碍物，以便使用相机或深度传感器避免碰撞。 此外，可以创建层以基于某些规则或启发式算法更改底层成本图。 最后，它们可用于将实时数据缓冲到 2D 或 3D 世界中，以进行二元障碍物标记。

Costmap Filters

想象一下，您正在注释地图文件（或任何图像文件），以便根据注释地图中的位置执行特定操作。 标记/注释的示例可能是将区域排除在外以避免在内部进行规划，或者让像素属于标记区域中的最大速度。 这个带注释的地图被称为“过滤器掩码”。 就像覆盖在表面上的蒙版一样，它的大小、姿势和比例可以与主地图相同，也可以不相同。 过滤器蒙版的主要目标是提供在地图上标记具有一些附加功能或行为变化的区域的能力。

成本图过滤器 - 是基于成本图层的方法，将过滤器掩码中注释的空间相关行为变化应用到 Nav2 堆栈中。 成本图过滤器作为成本图插件实现。 这些插件被称为“过滤器”，因为它们通过过滤器掩码上标记的空间注释过滤成本图。 为了制作过滤后的代价图并改变机器人在注释区域的行为，过滤器插件读取来自过滤器掩码的数据。 该数据在过滤器空间中被线性转换为特征图。 有了这个转换后的特征图以及地图/代价图，任何传感器数据和当前机器人坐标过滤器都可以更新底层代价图并根据机器人的位置改变机器人的行为。 例如，可以通过使用成本图过滤器来实现以下功能：

机器人永远不会进入的禁区/安全区。
限速区。 机器人进入这些区域的最大速度将受到限制。
机器人在工业环境和仓库中移动的首选通道。

Other Forms

存在各种其他形式的环境表示。 这些包括：

梯度图，类似于代价图，但表示表面梯度以检查遍历性
3D costmaps，以 3D 形式表示空间，但也需要 3D 规划和碰撞检查
网格贴图，类似于梯度贴图，但具有多个角度的表面网格
“矢量空间”，接收传感器信息并使用机器学习来检测要跟踪的单个项目和位置，而不是缓冲离散点。