合作

相关 API

• /api/planning/velocity_factors
• /api/planning/steering_factors
• /api/planning/cooperation/set_commands
• /api/planning/cooperation/set_policies
• /api/planning/cooperation/get_policies

描述

RTC (请求合作) 是一项功能,使人类作员能够在自动驾驶模式下支持决策. Autoware 通常使用自己的决定来驾驶车辆,但作员可能更喜欢在实验和复杂情况下做出决定.

规划组件将需要决策的每种情况作为场景进行管理. 每个场景都有一个 ID,在场景完成或取消之前,该 ID 不会更改. 作员可以使用此 ID 覆盖目标场景的决策. 在实践中,用户界面应用程序可以隐藏 ID 的规范,并为作员提供抽象的接口.

例如,在下图中,车辆需要进行两次变道并在十字路口左转. 因此,规划组件为每个所需的作生成三个场景实例,每个场景实例将等待决策做出,在本例中为 改变或保持车道 和 左转或在十字路口等待 . 此时,由于障碍物,Autoware 决定不再变道,因此车辆将停在那里. 但是,作员可以通过 RTC 功能覆盖该决定并强制变道,以便车辆可以达到目标. 使用 RTC,作员可以推翻这些决策,以继续驾驶车辆到达目标.

架构

支持 RTC 的模块除了 module decision 之外,还有 operator decision 和 cooperation policy,如下所示. 这些模块在规划车辆行为时使用由这些值确定的合并决策. 有关这些值的详细信息,请参阅 decisions 部分. 当没有作员决策时,将使用合作策略,并且具有由系统设置设置的默认值. 如果模块支持 RTC,则这些信息在 速度因子或转向因子 中作为 合作状态的

序列

这是一个示例序列,它覆盖了场景决策以强制变道.它适用于体系结构部分的图表中的第二个场景. 这里我们假设合作策略设置为 optional,有关详细信息,请参阅后面介绍的 decisions 部分.

1. 规划模块在接近需要变道的地方时创建一个具有唯一 ID 的场景实例.
2. 场景实例根据当前情况生成模块 decision.在这种情况下,模块决定不会因为障碍物而变道.
3. 场景实例生成合并决策.此时,还没有 operator 决策,因此它基于 module 决策.
4. 场景实例根据合并的决策规划车辆保持车道.
5. 场景实例发送合作状态.
6. 作员收到合作状态.
7. 作员发送合作命令以覆盖模块决策并进行变道.
8. 场景实例收到合作命令,更新算子决策.
9. 场景实例根据当前情况更新模块决策.
10. 场景实例更新合并的决策.它基于收到的作员决定.
11. 场景实例根据合并的决策计划车辆变道.

决策

合并决策由 module decision、operator decision 和 cooperation policy 决定,每个策略都取下表所示的值.

状态	价值观
合并决策	停用, 激活
模块决策	停用, 激活
作员决策	停用, 激活, 自主, 无
合作政策	必需、可选

这些值的含义如下.请注意,每个模块的合作策略是通用的,因此更改它会影响同一模块中的所有场景.

价值	描述
停用	作员/模块在优先考虑安全的情况下规划车辆行为的决策.
激活	作员/模块决策,以优先驾驶来规划车辆行为.
自主	遵循 module 决策的 operator 决策.
无	operator decision 的初始值,表示尚无 operator decision.
必需	要求作员决定继续驾驶的政策.
可选	不需要作员决定继续驾驶的政策.

以程是确定合并决策的方式.

例子

这是 lane change module 合作的示例.决策组合的行为如下.

作员决策	政策	模块决策	描述
停用	-	-	作员指示保持车道,而不管模块的决定如何.因此,车辆由作员决定保持车道.
激活	-	-	作员指示改变车道,而不管模块的决定如何.因此,车辆根据作员的决定改变车道.
自主	-	停用	作员指示遵循 module decision.因此,车辆通过模块决策保持车道.
自主	-	激活	作员指示遵循 module decision.因此,车辆通过模块决策改变车道.
无	必需	-	使用 required 策略是因为没有作员指令.因此,车辆根据合作政策保持车道.
无	可选	停用	使用 optional 策略是因为没有 operator 指令.因此,车辆通过模块决策保持车道.
无	可选	激活	使用 optional 策略是因为没有 operator 指令.所以车辆通过模块决定改变车道.