域描述

该planning子目录包含与生成朝向所提供目标的轨迹相关的节点和库。这些包括可能不一定能够产生精细轨迹但参与计划过程以减轻路径计划优化问题的复杂性的包。此外，该目录还包含用于测试和记录轨迹生成过程的节点。

子页面

• behavior_planner
  • behavior_planner
  • behavior_planner_node
• Lane planner
  • Lane planner
  • Lane planner nodes
• Object Collision Estimator
  • Object Collision Estimator
  • Object Collision Estimator Nodes
• Parking planner
  • Costmap generator
  • Costmap generator node
  • Freespace planner
  • Freespace planner nodes
• RecordReplay planner
  • RecordReplay planner
  • RecordReplay planner nodes
• OSM Planner
• TrajectoryPlannerNodeBase
• trajectory_smoother
• Trajectory spoofer
• global_velocity_planner

behavior_planner_node

这是 behavior_planner 包装的设计文件。

目的/用例

目的

节点的目的 behavior_planner 是将全局路径转换为局部轨迹以供控制器遵循。

这包括三个主要功能：

• 通过查询相关的轨迹计划，将全局路径中提供的语义映射图元列表转换为轨迹点序列。
• 修改轨迹的路径速度剖面，使车辆在检测到障碍物之前停止。
• 换档时的分裂分裂轨迹。 这只是时间函数，直到控制器可以处理反向运动的轨迹。

用例

系统用例

以下是考虑的用例：

• 离场：车辆必须能够离开停车区，并且必须开到最近的车道以进行跟随车道行驶。
• 车道驾驶：车辆必须沿着语义地图中定义的给定车道行驶。 车辆不得突出车道多边形，不得超过车道限速。
• 停车：车辆必须能够在车道行驶后从最近的车道停车。

输出用例

以下模块是“ behavior_planner ”输出的用户：

• 控制器：根据控制器提供的轨迹计算对vehicle_interface的控制输入 behavior_planner

设计

轨迹计划的难点在于计划的用例和需求会根据情况而变化。 例如，计划者在计划停车轨迹时必须考虑来回走动，而沿车道行驶时则不需要这种机动。 在单个节点中包含针对不同情况的所有算法使得计划复杂且难以长期维护。 在本设计中，轨迹计算的核心算法被拆分为不同的轨迹计划节点， behavior_planner 节点将作为这些节点的管理器来创建最终的轨迹。

将 behavior_planner 通过以下采场将全局路径转换为轨迹：

1. 将全局路径拆分为多个部分
2. 对于每个部分，查询适当的轨迹计划节点以计算每个部分的轨迹。
3. 在移动方向改变的点分割返回的轨迹。
4. 将分割的轨迹传递给速度修改器（即对象碰撞估计器）以优化速度。

假设/已知限制

限制

由于轨迹的计算被分成多个部分并传递给不同的节点进行优化，最终的轨迹可能不是全局最优的。

输入/输出/API

输入

• 车辆状态
• 全局路径
• 语义图

输出

• 弹道

行动呼吁

• PlanTrajectory（由于 ROS 服务调用实现方式的限制，我们使用操作而不是服务）

服务

• HADMapService
• ObjectCollisionEstimatorService

内部工作/算法

错误检测和处理

安全注意事项

参考/外部链接

未来的扩展/未实现的部分

• 在同步服务调用可用后，用服务调用而不是操作替换与轨迹计划的通信

Lane planner

这是 lane_planner 包装的设计文件。

目的/用例

Lane Planner 用于计算车道内的轨迹。 它将使用从 HADMap 获得的车道中心线并将其转换为轨迹。

设计

假设/已知限制

假设：

• 路由消息不包含不相关的原语。
  例如，如果车道连接为 1->2->3，并且如果 start_pose 在车道 2 内，并且目标姿势是车道 3，则给定路线不应包括车道 1。

限制：

• 由于车道计划使用的是车道中心线，因此它可能不是运动学可行的路径，例如，当车道有急转弯时。
• 具有车辆限制的轨迹优化将是未来的工作。

输入/输出/API

输入

• 地图
• 通过 ActionGoalRequest 路由

输出

• 通过 ActionResult 的轨迹

内部工作/算法

轨迹是通过以下步骤生成的：

1. 在 Lanelet Map 中从中心线生成轨迹点
2. 从路径曲率计算转向角
3. 从速度计算每个点的到达时间
4. 调整轨迹大小以适应轨迹容量
5. 速度平滑

错误检测和处理

如果给出任何无效路线，则计划将返回空轨迹。

安全注意事项

参考/外部链接

未来的扩展/未实现的部分

• 使用车道几何形状的可行驶区域优化路径形状
• 使用车辆的加加速度/加速度/速度限制进行速度优化

Lane planner nodes

这是 lane_planner_nodes 包装的设计文件。

目的/用例

LanePlannerNode 是 lane_planner 的 ROS 包装类。

设计

这继承了 TrajectoryPlannerNodeBase 类，该类定义了不同计划之间的公共接口。

实现的虚函数：

• create_map_request：目前它请求完整的地图，因为无法知道包含路线中所有给定 map_primitive 的地图的大小。
• plan_trajectory：将输入传递给 LanePlanner 类以计划轨迹。

假设/已知限制

输入/输出/API

输入和输出见 TrajectoryPlannerNodeBase

内部工作/算法

错误检测和处理

安全注意事项

参考/外部链接

未来的扩展/未实现的部分

• 使用planning_window 大小重新实现createMapRequest 函数。

Object Collision Estimator

目的/用例

碰撞估计器将感知堆栈检测到的对象列表和本地计划生成的本地路径作为输入。 然后它预测自我车辆和静态障碍物之间的任何碰撞。 最后修改本地路径以避免任何潜在的冲突。

设计

输入/输出

输入：

• PredictedObjects.msg
  • 障碍物的列表形状
  • 由感知堆栈产生
• Trajectory.msg
  • 自我车辆的本地路径
  • 由当地计划师制作

输出：

• Trajectory.msg
  • 修改的本地路径
  • 修改以避免任何碰撞

算法

这是估算器的工作流程：

• 收到障碍物清单。
• 增加太小的障碍物的大小。
• 接收轨迹。
• 遍历轨迹上的点。
• 对于每个点，创建一个代表自我车辆在该点占据的体积的形状。
• 对于每个障碍物，检测障碍物形状和自我车辆形状之间是否存在重叠。
• 如果检测到重叠，则将轨迹缩短到碰撞前的点。 将最后一个点的速度和加速度设置为零。
• 将轨迹传递到更平滑的位置以使速度分布更平滑。
• 平滑器将最后几个点的速度设置为零。
• 然后它通过一个高斯滤波器将速度分布图传递给一个逐渐下降到零的速度分布图。

假设/已知限制

• 障碍物与轨迹在同一坐标系中。
• 假设形状与地面平行，并由底面的矩形和 z = 0 表示。因此碰撞检测仅发生在 2d 中。
• 形状的角预计将按逆时针顺序排列。
• 对象的 x 和 y 元素应 size 分别映射到第一条和第二条边的长度。

错误检测和处理

所有 API 都不应发出异常。 如果碰撞检测算法以任何方式失败，则应返回空轨迹，并且行为计划应执行紧急停止。

相关问题

• #474：根据检测到的物体和车辆路径估计碰撞（Object Collision Estimator）
• #447：实施基于语义地图的导航和计划

Object Collision Estimator Nodes

目的/用例

碰撞估计器节点是检测碰撞的接口。 行为计划委派的任务是估计在到达该节点的计划路径上是否可能发生任何碰撞。

设计

该节点实现了对象碰撞估计库的 ROS2 接口。 它有两个主要的外部接口：

1. 订阅主题以从感知堆栈中获取障碍物形状。

1. 为行为计划者提供服务。 该服务将一条轨迹作为输入，并输出另一条经过修改以避免碰撞的轨迹。

假设/已知限制

• 预测对象消息和目标帧应该在同一帧中发布。
• 存在轨迹框架和目标之间的变换

输入/输出/API

输入：

• PredictedObjects.msg
  • 障碍物形状列表。
• Trajectory.msg
  • 行为计划给出的自我车辆的局部路径。
  • 在服务接口上收到

输出：

• Trajectory.msg
  • 修改本地路径以避免任何冲突
  • 在服务接口上返回

内部工作/算法

• 障碍订户
  • 订阅障碍物主题，该主题给出了代表感知管道检测到的障碍物的预测对象列表。
  • 然后将预测的对象传递给 ObjectCollisionEstimator 对象。
• 碰撞估计服务
  • 从行为计划获取包含计划轨迹的请求。
  • 将此轨迹传递给 ObjectCollisionEstimator，后者对其进行修改以避免任何碰撞。
  • 将修改后的轨迹返回给服务的调用者。

错误检测和处理

对于几何计算而言，形状边缘太小的障碍物将其尺寸增加到由 min_obstacle_dimension_m 定义的最小值。 每次遇到此类障碍时，此节点都会发出警告。

未来的扩展/未实现的部分

• 如果轨迹和目标框架之间的变换不存在，估计器应该返回空轨迹并且车辆应该停止。
• 测试 tf 转换代码路径。
• 根据车辆运行模式改变碰撞检测方法和容差。

相关问题

• #474：根据检测到的物体和车辆路径估计碰撞（Object Collision Estimator）
• #447：实施基于语义地图的导航和计划

Costmap generator

这是 costmap_generator 包装的设计文件。

目的/用例

成本图生成器提供了一个接口，用于生成环境的成本图表示。

设计

该库能够创建应用了 lanelet2 可驱动区域的成本图。 为了正确操作，算法应该使用值正确初始化，因为它不提供任何默认值。 该算法考虑了代价地图、地图和车辆框架位置之间的位移，因此提供适当的变换对其正确操作至关重要。

costmap生成的过程包括以下步骤：

1. 成本图生成器接收 HAD 地图、成本图和车辆之间的转换以及地图和成本图之间的转换。
2. 可驾驶区域，即道路、停车位和停车入口，从 HAD 地图中提取并转换为多边形。
3. Costmap 正在移动到机器人的中心位置以对齐其在地图框中的位置。
4. 每一层costmap都被填充了。 目前，存在两层：
   • HAD 地图层，通过以 0 成本填充可行驶区域多边形，其余的以障碍物成本填充；
   • 组合层，其中每个元素是所有层的对应元素的最大值； 目前，当仅存在一个其他图层时，它只是 HAD 地图图层的副本。
5. 如果启用，将计算可行驶区域多边形的边界框并修剪成本图。
6. 返回结果成本图。

配置

未来的扩展/未实现的部分

• 处理其他环境信息来源，如点云或检测到的对象

Costmap generator node

这是 costmap_generator_nodes 包装的设计文件。

目的/用例

成本图生成器提供了一个动作服务器，用于生成环境的成本图表示。

设计

在节点的开始，costmap 使用基本信息初始化，例如帧 id 和该帧内的位置、分辨率、层和大小。 其中一些属性可能会发生变化，例如，大小和位置可能会因成本图修剪而发生变化。

costmap生成的过程包括以下步骤：

1. 使用所需参数配置成本图生成器算法。
2. 调用动作服务器。 动作的目标是由起始姿势和目标姿势组成的路线。
3. 成本地图的边界被计算为计划请求路线所需的区域。
4. 成本地图生成器调用 HAD 地图服务器，请求计算范围内可行驶区域的 HAD 地图。
5. Costmap 生成器接收 HAD 地图。
6. 获得成本图和车辆位置之间的转换。
7. 获得地图和代价地图框架之间的转换。
8. 使用 5-7 范围中提到的信息调用 Costmap 生成器。
9. 在接收到costmap之后，它被转换成一个定义好的通信消息。
10. 调试可视化已发布。
11. 结果，Action 成功发送了 costmap。

输入/输出/API

输入

输出主题

动作服务器

服务客户

配置

Freespace planner

这是 freespace_planner 包装的设计文件。

目的/用例

自由空间计划提供不同搜索算法的实现。 包实现基类，每个实现都从该基类继承。 每个实现都会根据车辆的运动学约束生成从起始姿势到目标姿势的平滑路径。

目前实现的算法：

• 混合 A*

设计

计划需要环境的表示来计划轨迹。 它以 nav_msgs::msg::OccupancyGrid 成本图的形式提供。 算法输出自定义 PlannerWaypoints 对象，其定义可以在代码文档中找到。

拥有成本图算法可以创建避开障碍物的平滑且运动学上可行的轨迹。

此外，该算法还实现了 Reeds-Shepp 成本估计算法，使找到的路径平滑且最优。

计划返回一个布尔值，指示计划是否成功以及以下状态之一以获得更好的详细度：

• SUCCESS - 计划成功
• FAILURE_COLLISION_AT_START - 由于起始位置车辆足迹内有障碍物，计划失败
• FAILURE_COLLISION_AT_GOAL - 计划失败，因为目标位置的车辆足迹内有障碍物
• FAILURE_TIMEOUT_EXCEEDED - 计划失败，因为已超过超时
• FAILURE_NO_PATH_FOUND - 计划失败，因为找不到平滑且运动学上可行的轨迹

Planning 不会返回计划的轨迹，但可以由适当的 getter 访问。

配置

常用计划参数

混合 A* 参数

Freespace planner nodes

这是 freespace_planner_nodes 包装的设计文件。

目的/用例

这个包是一个 2D 轨迹计划节点，它处理静态和动态障碍物。 该节点基于 freespace_planner 包中实现的搜索算法并使用自定义成本图提供程序。

设计

这个包的主要目的是包装计划算法 freespace_planner 并与成本图提供者和高级计划者进行交流，后者决定何时请求计划。 该软件包旨在正确初始化 ROS2 通信，初始化轨迹计划并使它们在动作服务的基础上进行协作。 节点的操作可以通过以下步骤来描述：

1. 自由空间计划接收lanelet2路线作为计划获取停车位轨迹并检查其当前状态的请求。
   • 如果当前正在进行任何计划，则拒绝请求。
   • 在其他情况下，请求被接受并且计划者的状态从 idle 变为 planning 。
2. 在下一步中，创建成本图请求并将其发送到操作服务器。
   • 如果 costmap 请求被拒绝，则计划中止并且计划者的状态变为 idle 。
3. Planner 检查返回的成本图是否为空。
   • 如果 costmap 为空，则计划结束，计划者的状态变为 idle 。
4. 收到 costmap 后，planner 开始使用 freespace_planner package 进行计划。
   • 如果 costmap 响应返回失败，则计划返回失败，并且它的状态更改为 idle .
5. Trajectory 发布用于调试和可视化目的。
6. 最后轨迹被发回，结果标志设置为成功。 Planner 的状态变为 idle .

输入/输出/API

输入

输出主题

动作客户端

动作服务器

配置

节点特定参数

以下参数取自 yaml 参数文件。

算法特定参数

对于每个实施的计划算法，可以更改其特定参数。 下面的所有参数都有命名空间，以区分每个算法之间的不同参数集。

一个*

命名空间名称： astar .

车辆特定参数

以下参数是使用 vehicle_constants_manager node.js获取的。

未来的扩展/未实现的部分

• 目前，由于所需的 HAD 地图提供者的不同，planner 没有从 TrajectoryPlannerNodeBase 类继承，因为它的接口不足。 进一步的发展应该从重新考虑与更高级别的计划者的接口开始。
• 此时计划作为一个动作不会向动作客户端返回任何反馈，因为 behavior_planner 没有使用它。
• 此外，应按顺序调用所有服务。 但是 rclcpp API 不允许进行顺序服务调用，因为在另一个服务回调中调用服务器时，它们可能会导致死锁。 freespace_planner_nodes 这是与 costmap_generator 动作服务器通信 的主要原因。

RecordReplay planner

目的/用例

这个包提供了一个简单的类来记录状态，然后将它们作为轨迹回放。 这将在模拟器和控制器的现场测试中使用：可以打开记录，开始驾驶轨迹，然后重置车辆位置，然后开始回放，看看控制器做了什么。

轨迹可以是一个循环，可以通过检查轨迹的第一个点和最后一个点之间的距离来简单地确定它，但用户可以最终控制切换此行为。

设计

记录将在内部状态列表的末尾添加状态。

回放将沿着记录的状态列表找到位置和航向方面最接近的状态，并从该状态开始传送轨迹。 轨迹长度最多为 Trajectory 消息指定的 100，如果存在任何记录数据，则至少为 1。

回放时不检查障碍物碰撞。 然而，产生的 Trajectory 消息可以被馈送到一个 obstacle_collision_estimator 节点，该节点将考虑障碍物来修改轨迹。 有关详细信息，请参阅 recordreplay_planner_nodes 设计文档。

假设/已知限制

沿轨迹的点之间没有插值，并且定位不是以一种聪明的方式完成的：记录的状态列表只是简单地迭代。

仅当可以假设下游控制器和车辆能够跟踪在单个轨迹步骤中变为零的期望速度时，停止概念才有效。

确保构造满足这一假设将涉及为停止创建动态可行的速度曲线——这还没有完成。

用户有责任检查轨迹是否适合循环，并 set_loop 根据控制器正在回放的当前轨迹相应地调用以切换循环行为。 is_loop ，这是一个简单的函数，用于检查轨迹的起点和终点是否足够接近，由 提供并实际上由 使用 recordreplay_planner_nodes 。

当循环到达最后一点时，它只是连接轨迹的开始。 没有努力确保位置、方向和速度更新在运动学上是可行的。 例如，如果在记录过程中车辆停在最后一个点，轨迹将包含相同的速度信息，即使车辆应该继续行驶到第一个点。 因此，要使用循环，强烈建议首先优化用户在录制时获取的路径文件。

输入/输出/API

输入：

• VehicleKinematicState.msg 是被记录的状态
• BoundingBoxArray.msg 是障碍物边界框的列表

输出：

• Trajectory.msg 是发布的轨迹

复杂

记录 O(1) 在时间和 O(n) 空间上，重 O(n) 放在时间和空间上，其中 n 是记录状态的数量。 即使障碍物没有改变，目前每次重放都会发生碰撞检查，并且复杂性与障碍物的数量成线性关系，但与自我车辆中的半平面数量和单个障碍物的乘积成正比。

安全注意事项

由安全专家待定。

未来的扩展/未实现的部分

• 轨迹缓冲区清除
• 适当的 tf 支持
• rosbag2 支持录制和稍后重放

RecordReplay planner nodes

目的/用例

这个包为计算包提供了一个 ROS2 节点 recordreplay_planner 。 这样做是为了将计算部分与 ROS2 特定的部分分开。 有关该功能的用途的基本原理，请参见计算部分。

有时希望在回放时循环记录轨迹。 当轨迹的起点和终点太远时，这可以通过设置并使用适当的值来防止不必要 loop_trajectory 的 循环 True 。 loop_max_gap_m

设计

这是一个包装器 recordreplay_planner 。 它的行为可以通过动作来控制。 它可以记录车辆的自我状态，并在以后回放一组记录的状态。 它确实停止了障碍物， from BoundingBoxArray ，发布在任何 tf 可以转换为 VehicleKinematicState ' 框架的框架中。

假设/已知限制

该节点假定记录的状态可以在没有任何 tf 更改的情况下回放。 https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/issues/265 中有一个未解决的问题 来解决此限制。

有关详细信息，请参阅 recordreplay_planner 设计文档。

输入/输出/API

行动：

该节点使用两个动作来控制其行为：

• RecordTrajectory.action 用于记录轨迹。 它运行直到取消。 在操作运行时，节点通过提供的名称订阅 VehicleKinematicState.msg 主题并记录在该主题上发布的所有状态。
• ReplayTrajectory.action 用于重放轨迹。 它运行直到取消。 在操作运行时，节点订阅与 VehicleKinematicState.msg 录制时相同的主题。 recordreplay_planner 当关于该主题的消息发布时，节点会发布大约从该点开始的轨迹（有关如何确定该点的信息， 请参阅设计文档）。
  

动作在 autoware_auto_vehicle_msgs 和 autoware_auto_planning_msgs 中定义 autoware_auto_perception_msgs 。

客户：

• autoware_auto_planning_msgs/srv/ModifyTrajectory 是客户端， obstacle_collision_estimator 它将在该节点内部生成的轨迹上检查障碍物碰撞，并交回修改后的轨迹以避开障碍物。 可以通过 enable_object_collision_estimator 参数切换此行为。

输入：

• autoware_auto_vehicle_msgs/msg/VehicleKinematicState 是用作回放记录点的状态，也用于修剪回放轨迹的起点

输出：

• autoware_auto_planning_msgs/msg/Trajectory 是发布的轨迹。 如果 enable_object_collision_estimator ，则为修改后的轨迹。

复杂

见 recordreplay_planner 。

安全注意事项

由安全专家待定。

未来的扩展/未实现的部分

• 适当的 tf 支持

相关问题

• #265 扩展以 tf 正确支持
• #273 修复和扩展集成测试

OSM Planner

目的/用例

这个包提供了一个带有 lanelet2 OpenStreetMap (OSM) XML 的全局路径计划。 它按照地图中定义的交通规则计划从当前位置到最终停车位的最短路径/车道。 路径以从起始位置到目标位置的车道 ID 数组的形式给出。

请注意，全局路径是中心车道线，包括通过地图中定义的可行驶区域从/到停车位的路径。

设计

通用lanelet2数据结构

路线计划

路径（车道）计划利用lanelet2 api从给定的起点和目标位置（x，y，z）获取最短路径。 计划步骤包括，

1. 从给定位置查找下车和停车位置 id，例如定位器节点的当前位置 (find_nearparking_from_point)
2. 从 osm 地图中定义的停车和车道关联中找到起点和目标车道 id (find_lane_id)
3. 查找将下车地点和停车位置连接到车道路线的可驾驶区域路径 ID
4. 使用lanelet2 api (get_lane_route) 查找最短路径图搜索
5. 将 4 的最短路径与可行驶的停车路径连接到 3 的车道路线。

假设/已知限制

• osm 地图必须有停车 id 到车道关联
• osm 地图必须具有将停车 id 与车道 id 相关联的可行驶区域属性
• 仅在此阶段需要计划从/到停车位的路径
• 将停车位内的目标姿势修改为位于停车位的中心，以方便停车计划者的生活； 看 Lanelet2GlobalPlanner::refine_pose_by_parking_spot()

输入/输出/API

输入：

• 二进制映射
• GPS 位置 (lat, lon, alt) 将地图地理位置转换为 utm 坐标
• 起始/目标位置

输出：

• 车道 ID 数组

复杂

现在，从给定位置搜索停车位是 O(n-1) 在空间中，std::min_element ( https://en.cppreference.com/w/cpp/algorithm/min_element#Complexity )

相关问题

• #470 - 地图加载器

TrajectoryPlannerNodeBase

这是 trajectory_planner_node_base 包装的设计文件。

目的/用例

具有样板的节点，用于操作轨迹计划以管理跨轨迹计划的公共输入和输出数据流。

设计

TrajectoryPlannerNodeBase 是一个通用的轨迹计划节点，它返回从开始状态导航到行为计划请求中定义的目标状态的轨迹。

必须在子类中实现以下功能：

• MapRequest create_map_request( route ) 必须实施。 返回值应该是对 map_provider 的请求消息。 实施者应该创建一个请求，以便计划者可以接收足够的地图信息来计划轨迹。 例如，如果停车计划可能想要在小区域内请求停车位和车道对象，而车道计划可能想要查询只有车道对象的较大地图。
• Trajectory plan_trajectory( route, map ) 必须实施。 返回值应该是从起始状态导航到目标状态的轨迹。
• bool is_trajectory_valid( trajectory ) 可以覆盖以允许计划者对轨迹进行特定验证。

假设/已知限制

当前轨迹消息具有有限的容量。 如果轨迹需要比容量更多的点，则必须对其进行裁剪，以使大小适合容量。 如果先前计划的轨迹不完整，则行为计划者的工作是重做对每个计划者的请求。

输入/输出/API

输入：

• 具有开始和目标状态的轨迹请求
• 通过服务调用进行 HAD 映射

输出：

• 计算轨迹
• 计划者的 ReturnCode (SUCCESS/FAIL)

内部工作/算法

错误检测和处理

安全注意事项

参考/外部链接

未来的扩展/未实现的部分

• 必须在发布前对轨迹进行最终验证。 这可以随着更多计划器的实施而完成，以便我们更好地了解需要哪些验证并且可以使其通用。

Trajectory spoofer

这是 trajectory_spoofer 包装的设计文件。

目的/用例

这个包提供了一个 ROS2 节点和类，用于生成可用于测试的轨迹，以替代运动计划。 这样做是为了能够在不依赖运动计划或定位的情况下测试需要有效轨迹的组件。 此外，与使用运动计划不同，该模块可以控制生成的轨迹类型并提供可重复性。

该软件包仅用于 在模拟 中测试控制器。

设计

该节点监听车辆状态并使用接收到的第一个位置作为轨迹中的起点。 基于参数，节点使用 trajectory_spoofer 类生成轨迹。 轨迹基于简单的几何图案，如直线或圆。

假设/已知限制

Trajectory 将使用与传入状态消息相同的 TF 帧。

输入/输出/API

参数：

• speed_ramp_on (bool) : 当前未使用
• target_speed (float): 所有轨迹点使用的速度
• num_of_points (int): 在轨迹上生成的点数（最大 100）
• 轨迹类型（字符串）：目前仅支持“直线”或“圆形”
• length (float): 以米为单位的轨迹长度，仅用于 trajectory_type ='straight'
• radius (float): 以米为单位的轨迹半径，仅用于 trajectory_type ='circle'

输入：

• autoware_auto_vehicle_msgs/msg/VehicleKinematicState 是设置为起点同时触发轨迹发布的状态

输出：

• autoware_auto_planning_msgs/msg/Trajectory 是发布的轨迹

发射：

• $ros2 launch trajectory_spoofer trajectory_spoofer.launch.py

内部工作/算法

错误检测和处理

不适用于生产用途。

安全注意事项

不适用于生产用途，仅用于有限测试且仅用于模拟。

参考/外部链接

未来的扩展/未实现的部分

• 添加其他类型的几何图案，如曲率、8 字形、变道、右/左转、U 形转弯等。
• 添加不同的速度曲线，如加速、减速、加速和减速、振荡、突然制动等。

相关问题

• #233 创建虚拟轨迹欺骗器

global_velocity_planner

这是 global_velocity_planner 包装的设计文件。

目的/用例

它创造了轨迹。 它将更容易测试控制器。 它提供了额外的信息，例如控制器的参考速度和加速度。

设计

它像 lane_planner 一样工作，从 lanelet2_global_planner 获取路线，然后构成航点。 通过使用这些路点，它计算相应路点的曲率。 在这些计算之后，它会根据从参数文件中获取的最大横向和纵向加速度填充这些航路点的纵向速度。

假设/已知限制

输入/输出/API

输入：

• 全球航线

参数：

• 纵向加速度
• 横向加速度
• 轨迹分辨率
• cg_to_front_m
• cg_to_rear_m

输出：

• 弹道

内部工作/算法

1. 在 Lanelet Map 中从中心线生成轨迹点
2. 计算轨迹点的曲率。
3. 计算相对于横向和纵向加速度的纵向速度。
4. 计算每个轨迹点的转向角和方向。
5. 从速度计算每个点的到达时间。
6. 调整轨迹大小。

错误检测和处理

安全注意事项

参考/外部链接

未来的扩展/未实现的部分

• 将实施第一点的转向角。
• get_closest_index 函数将被优化。