MoveIt 的运动规划架构遵循“感知-规划-行动”方法。为了规划和执行运动，首先感知环境和机器人状态（“感知”），然后由规划器计算机器人轨迹（“规划”），最后使用轨迹控制器在一次运行中执行（“行动”）。
虽然此解决方案适用于众所周知的静态环境中的全局运动规划，但该方法不适用于许多实际应用，特别是在不稳定或动态环境中。诸如在桌子上给某人端上一杯水或在凹凸不平的黑板上写字之类的任务需要更复杂的方法来应对不可预测的变化。例如，机器人的环境可能会动态变化，或者任务本身可能存在某些不确定性，例如用粉笔写字需要调整黑板上的压力，而粉笔用完后也会变短。
解决这些挑战需要一种方法，能够根据当前情况调整执行的动作，甚至在环境发生不可预见的变化时通过重新规划做出反应。混合规划架构试图通过结合一对循环的全局和局部规划器来解决这个问题。
什么是混合规划？
混合规划是一种运动规划方法，它结合了异构运动规划器来产生更强大或反应更快的解决方案。这种通用方法在导航社区中已经非常成熟，并在 navigation2 等热门项目中成功实施。
MoveIt 的混合规划架构结合了一对并行且循环运行的全局和局部规划器，具有不同的规划速度和问题范围。
全局规划器的任务是解决全局运动规划问题，这与“感知-规划-行动”应用程序中使用的规划器非常相似。使用的规划器算法应该是完整的，因此在计算时间方面被认为是相对较慢的。此外，全局规划器不需要实时安全，这意味着不能保证规划器在特定期限内找到解决方案。根据规划器的实现，全局规划器可能会在执行过程中生成一个初始解决方案或迭代优化的解决方案。
本地规划器在执行期间持续运行，并生成迭代机器人命令以遵循全局轨迹。在某种程度上，本地规划器类似于控制器，只是架构允许解决更复杂的问题和约束。这个想法是规划器能够推理世界并拥有内部状态。该属性使其用途广泛，可用于解决任意局部规划问题的组合，例如：
展开、混合或拼接后续全局参考轨迹
在遵循全局路径的同时动态避免近距离碰撞
根据局部约束调整全局轨迹（例如，在不平坦表面上施加所需的力，根据视觉反馈重新调整工具）
局部轨迹优化和时间参数化（在局部环境中优化轨迹在计算上更便宜、更快捷）
为了能够解决这些局部问题，局部规划器必须快速、能够对传感器反馈做出反应，并且在许多情况下实时安全。此外，它应该是确定性的，以避免出现不稳定或不可预测的运动。
通常，局部规划器依赖于全局规划器生成的参考轨迹，这样它就不会陷入局部最小值。由于有时仍无法排除局部最小值，因此可能需要触发全局规划器进行重新规划，以便仍然达到预期目标。此行为需要某种方式来传达规划器事件并相应地处理它们。为此，混合规划架构允许实施基于事件的逻辑，该逻辑可针对特定用例和规划器类型进行定制。
Global Planner |
Local Planner |
|---|---|
|
|
|
|
|
|
混合规划在广泛的用例中都很有用。大多数应用程序可以分为以下三种场景。
在线运动规划：全局规划器创建初始全局解决方案并不断优化它。同时，局部规划器执行参考轨迹并将更新的轨迹段混合到其中。
反应运动：全局规划器用于修复无效的解决方案（重新规划），而局部规划器在碰撞前减速或停止
自适应运动：局部规划器用于使全局解决方案适应动态条件，例如保持工具与不平坦表面的稳定接触
混合规划架构
下图描述了构成混合规划架构的基本插件类型和 ROS 接口。
该架构由三个 ROS 组件节点构成：
混合规划管理器
为混合规划请求提供 ROS 操作
运行规划逻辑并协调规划器
全局规划器
解决全局规划问题并发布解决方案轨迹
局部规划器
处理传入的全局轨迹更新
根据机器人状态、世界和参考轨迹解决局部规划问题
向机器人驱动器发送位置/速度命令
架构组件设计为通用且高度可定制。由于组件仅通过 ROS 2 消息接口进行交互，因此很容易替换架构的每个组件或插件的实现。插件接口设计为最小，并尽可能从实际算法实现中抽象出来。这使开发人员可以完全专注于独立的逻辑或求解器，而无需实现基础设施的任何部分。这也允许针对不同的设置或规划问题重复使用相同的组件。
混合规划管理器
该组件是架构的“大脑”。其主要目的是处理 HybridPlanner 操作请求并根据规划逻辑插件协调运动规划和执行过程。规划逻辑在 PlanningLogic 插件中实现，并在设计上由事件驱动。事件由字符串标识符定义，可能会触发针对全局或本地规划器的操作调用或取消。下图显示了一个简单规划逻辑的示例事件日志：
事件由混合规划操作请求以及全局和本地规划器操作反馈消息触发。在此示例中，混合规划管理器在收到混合规划请求后启动全局规划器。全局轨迹到达后，启动本地规划器，本地规划器完成后，混合规划管理器返回混合规划响应。
规划逻辑插件的自定义实现支持将通用事件映射到架构提供的可用操作，如“启动全局规划”、“停止轨迹执行”或“切换到本地规划器约束 x”。这样，运动规划行为就变得高度可定制且适应性强。
全局规划器
全局规划器是架构中最简单的组件。它提供了一个处理全局规划器请求的操作服务器。这些请求包括通用的 MotionPlanRequests，由全局规划器插件处理。默认情况下，这只是 MoveIt 的规划管道，但从技术上讲，任何类型的规划器甚至 MTC 都可以在这里使用。规划结果使用操作反馈进行报告，解决方案轨迹发布到本地规划器以供进一步处理。
本地规划器
本地规划器还运行一个处理来自混合规划管理器的请求的操作服务器。该操作用于启动和停止执行，还可以配置运行时参数，如约束或求解器类型。
本地规划器实现基于两个插件：
轨迹运算符：此插件维护全局参考轨迹，处理来自全局规划器的轨迹更新，并监控当前机器人状态的进程。
局部约束求解器：此插件实现迭代求解器算法，该算法根据参考轨迹和局部约束生成机器人命令。它可能包括用于动态处理传感器输入或事件更新的附加接口。
下图显示了混合规划管理器发出操作请求时本地规划器的示例循环周期：
Each iteration the local planner requests the current planning scene and matches the current robot state within the reference trajectory. If the goal is reached, the local planning action successfully finishes. Otherwise, the current local planning problem is identified based on the current robot state and solved afterwards. Finally, the resulting control commands are published to the robot controller.
How does it work?
The runtime behavior of a Hybrid Planner can best be understood by drawing a workflow diagram that visualizes the communication channels and events of the different components.
Below is a diagram that shows the runtime logic of a successful trajectory execution.
The planner is invoked by a hybrid planning request which is also the first event the Hybrid Planning Manager reacts to. In this example, the planner logic simply runs both planners in sequence. After the initial hybrid planning request, the Hybrid Planning Manager invokes the global planner. The global planner computes and publishes a trajectory which is received by the Hybrid Planning Manager and the Local Planner Component. Important to notice is, that the Local Planner Component just processes the new trajectory and does not start executing until it is invoked by the Hybrid Planning Manager. Once requested by the Hybrid Planning Manager, the Local Planner Component starts unwinding the reference trajectory and returns the action response successfully when it reaches the final state. After that, the Hybrid Planning Manager returns a successful HybridPlanningResponse.
Now let’s consider a more difficult scenario where the hybrid planner is designed to avoid an obstacle during execution by replanning. The animation below shows a simple motion that is being fixed at runtime because of changing collision objects.
Here, the collision object present during the global planning process disappears after the global trajectory is computed. Instead two new collision objects appear that invalidate the initial global trajectory. The local planner detects the imminent collision and pauses the execution until the global planner has provided an updated collision free trajectory.
Below you can see the workflow of the described behavior.
The startup is the same as in the first example, but during unwinding the reference trajectory the local planner detects a collision. Here, the planner logic reacts by re-invoking the global planner. During the calculation of the new global solution, the local planner must prevent the robot from colliding with the collision object i.e. by keeping its current position. After the global planner finishes its calculation, the new global solution is published to the local planner and the local planner’s Trajectory Operator Plugin blends the update into the reference trajectory. Afterwards, the Local Planner Component continues to follow the reference trajectory as the updated solution enables it to steer around the collision object.
If you want to use Hybrid Planning in your application or just want to experiment with it, check out the Hybrid Planning Example Tutorial.