CN115610433A - 自动驾驶车辆的实时事件触发的反馈 - Google Patents

Abstract

本公开涉及收集来自自动驾驶车辆的乘客的反馈。例如，可以确定已经满足用于触发反馈请求的触发环境。触发环境可以包括驾驶事件、其他道路用户的存在或行程状态。基于所述确定识别反馈请求的显示要求和数据收集参数。显示要求限定何时显示反馈请求，而数据收集参数识别反馈请求要收集的信息。基于显示要求和数据收集参数，提供反馈请求以供显示。作为响应，接收并存储来自自动驾驶车辆的乘客的反馈以供后续使用。

Description

自动驾驶车辆的实时事件触发的反馈

相关申请的交叉引用

本申请要求于2021年7月15日提交的第63/222,277号美国临时申请的 申请日的权益，其全部公开内容通过引用并入这里。

技术领域

本发明涉及从自动驾驶车辆的乘客收集反馈的方法。

背景技术

自动驾驶车辆(诸如不需要人类驾驶员的车辆)能够用于帮助将乘客或 物品从一个位置运输到另一个位置。这样的车辆可以以完全自主模式操作， 其中，用户可以提供一些初始输入，诸如上车位置或目的地位置，并且车辆 将自身操纵到该位置。当人(或用户)想要经由车辆在两个位置之间物理地 交通和/或运输货物时，他们可以使用任何数量的出租车或递送服务。迄今为 止，这些服务通常涉及人类驾驶员，该人类驾驶员被给予到达一个位置的分 派指令以接载和卸载用户和/或货物。在一些情况下，例如通过向驾驶员提供提示和/或星级或其他评级，为乘客提供对他或她的搭乘服务的整体体验进行 “评级”的机会。

发明内容

本公开的一个方面提供了从自动驾驶车辆的乘客收集反馈的方法。该方 法包括：由自动驾驶车辆的反馈系统的一个或多个处理器确定已经满足用于 触发反馈请求的触发环境，该触发环境包括驾驶事件、其他道路用户的存在 或行程状态中的一个或多个；基于所述确定，由一个或多个处理器识别反馈 请求的显示要求和数据收集参数，其中，显示要求限定何时显示反馈请求， 而数据收集参数识别反馈请求要收集的信息；由一个或多个处理器基于显示 要求和数据收集参数提供反馈请求以供显示；响应于所述提供，由一个或多个处理器接收来自自动驾驶车辆的乘客的反馈；以及由一个或多个处理器存 储反馈以供后续使用。

在一个示例中，驾驶事件包括从自动驾驶模式脱离到手动驾驶模式。在 另一示例中，其他道路用户的存在包括预定义数量的行人。在另一示例中， 其他道路用户的存在包括预定义数量的骑自行车者。在另一示例中，行程状 态包括从乘客上车(pickup)开始的时间。在另一示例中，行程状态包括从乘 客下车(drop off)开始的时间。在另一示例中，触发环境还包括搭乘者生命 周期要求。在该示例中，搭乘者生命周期要求包括乘客是否在特定搭乘号码 上。另外或替代地，搭乘者生命周期要求包括乘客是否在一周内进行了特定 数量的搭乘。另外或替代地，搭乘者生命周期要求包括乘客是否在多个搭乘 之间具有预定义时间量。另外地或替代地，搭乘者生命周期要求包括自第一 次搭乘以来的预定义周数。在另一示例中，触发环境还包括支持交互要求。 在另一示例中，显示要求限定触发环境已经被满足与显示反馈请求之间的延 迟时间。在另一示例中，显示要求包括必须在显示反馈请求之前发生的车辆 动作。在另一示例中，该方法还包括：基于所述确定，识别反馈请求的优先 级，并且该优先级对应于可能发生触发环境的频率的倒数。在该示例中，所 述方法还包括使用反馈请求的优先级来确定何时显示反馈请求。在另一示例 中，提供包括在自动驾驶车辆的显示器上提供显示。在另一示例中，所述提 供包括在与乘客相关联的客户端计算设备的显示器上提供显示。在另一示例 中，所述方法还包括：基于所述确定，识别反馈请求的频率限制，并且所述提 供还基于频率限制。在该示例中，频率限制包括在行程期间显示的反馈请求 的固定最大数量。

附图说明

图1是根据示例性实施例的示例车辆的功能图。

图2是根据本公开的各方面的车辆的示例外部视图。

图3是根据本公开的各方面的示例系统的功能图。

图4是根据本公开的各方面的示例系统的示意图。

图5是根据本公开的各方面的图4的系统的功能图。

图6A-图6H是根据本公开的各方面的显示器和显示的信息的示例表示。

图7A-图7D是根据本公开的各方面的显示器和显示的信息的示例表示。

图8是根据本公开的各方面的示例流程图。

具体实施方式

所述技术涉及在涉及自动驾驶车辆的行程期间从乘客收集反馈。虽然一 旦任务完成，例如，在旅行完成之后，一些反馈系统可以请求来自用户的反 馈，但是这可能并不总是以及时的方式捕获最有用的反馈。为了实现实时反 馈，人类操作员(“内部利益相关者”)必须首先限定反馈请求。每个反馈请求 可以包括三个主要特征：触发环境、显示要求和数据收集参数。

触发环境可以包括要求，诸如在预定时间段或预定次数内的驾驶事件、 其他道路用户的存在或动作、行程状态、道路图要求、支持交互、用户生成/ 发起的反馈、乘客生命周期(lifecycle)、一天中的时间、其他驾驶条件、或者 这些的同时组合。道路图要求可以包括某些类型的交叉路口、无保护转弯、 狭窄街道、施工区、脱离区(其中，自动驾驶车辆将自动地从自动驾驶模式脱 离到手动驾驶模式，或者不允许靠边停车的区域)等。显示要求可以限定何 时显示反馈请求，以便以及时的方式捕获最有用的反馈。

数据收集参数可以识别反馈请求要收集的信息，或者更确切地说，限定 要输入到反馈系统中的信息的参数。在一些情况下，反馈请求的数据收集参 数也可以基于乘客的类型和/或生命周期而不同。

假设反馈请求满足质量和有用性的内部要求(例如，一些内部标准)，则 可以为反馈请求分配优先级。在一个实例中，优先级对应于可能发生触发环 境的频率的倒数(inverse)。作为另一实例，优先级可以对应于对特定类型的 数据的需要，而不管频率如何。

触发环境、显示要求和数据收集参数可以存储在查找表、数据库或其他 存储系统中，查找表、数据库或其他存储系统允许自动驾驶车辆的反馈系统 的一个或多个计算设备精确地确定何时满足触发环境，然后识别任何对应的 显示要求和数据收集参数。

反馈系统的计算设备可以监测来自自动驾驶车辆的各种系统的信息。例 如，反馈系统的计算设备可以不断地分析来自自动驾驶车辆的定位系统的道 路图特征和位置信息、来自自动驾驶车辆的规划系统的路线和轨迹特征、来 自自动驾驶车辆的感知系统的检测到的对象和特性、以及来自自动驾驶车辆 的行为建模系统的行为预测等。基于此，反馈系统可以确定何时发生触发环 境。

一旦发生触发环境，反馈系统的计算设备就能够为用户生成并显示界面。 这能够在具有或不具有可听通知的情况下根据该反馈请求的显示要求显示在 车辆的显示器上或潜在地显示在用户的电话上。当一次存在多个反馈请求时， 优先级可以允许反馈系统选择这些请求中最重要的请求以向用户显示，而牺 牲其他请求。

反馈结果可以被接收和存储以供后续分析和/或自动发送到车队管理系 统以供存储和后续分析。例如，会诊(triage)团队可以审查反馈并为最初请 求反馈的人类操作员或另一实体创建通知。另外，在给定问题何时发生的准 确时间戳的情况下，会诊团队可以更快速/有效地能够对问题溯源。在一些情 况下，可以实时使用反馈来影响自动驾驶车辆的驾驶行为。

本文描述的特征可以允许自动驾驶车辆在对利益相关者(stakeholder)重 要的事件正在发生时，实时收集来自乘客的反馈。因此，反馈可以更准确并 且甚至更有用，因为它不是在行程已经完成之后才简单地收集的。例如，乘 客将刚刚经历过该事件，因此将比行程中后续对事件具有更好的记忆。此外， 在搭乘中后续的其他负面或正面事件将不会影响乘客对当前事件的反馈。此 外，与在搭乘结束时(当乘客会不太可能正确地回忆答案时)同时询问好几 个问题相比，如果在搭乘过程中多次询问反馈，则一些乘客可能具有更好的体验。

示例系统

如图1所示，根据本公开的一个方面的自动驾驶车辆100包括各种组件。 虽然本公开的某些方面结合特定类型的车辆特别有用，但是车辆可以是任何 类型的车辆，包括但不限于汽车、卡车、摩托车、公共汽车、休闲车等。车辆 可以具有一个或多个计算设备，诸如包含一个或多个处理器120、存储器130 和通常存在于通用计算设备中的其他组件的计算设备110。

存储器130存储由一个或多个处理器120可访问的信息，包括可以由处 理器120执行或以其他方式使用的数据132和指令134。存储器130可以是 能够存储可由处理器访问的信息的任何类型，包括计算设备或计算机可读介 质，或存储可以借助于电子设备读取的数据的其他介质，诸如硬盘驱动器、 存储卡、ROM、RAM、DVD或其他光盘，以及其他可写和只读存储器。系统 和方法可以包括前述内容的不同组合，由此指令和数据的不同部分存储在不同类型的介质上。

指令134可以是由处理器直接(诸如机器代码)或间接(诸如脚本)执 行的任何指令集。例如，指令可以作为计算设备代码存储在计算设备可读介 质上。在这方面，术语“指令”和“程序”在本文中可以互换使用。指令可以 以目标代码格式存储以供处理器直接处理，或者以任何其他计算设备语言存 储，包括按需解释或预先编译的脚本或独立源代码模块的集合。下面更详细 地解释指令的功能、方法和例程。

数据132可以由处理器120根据指令134检索、存储或修改。例如，尽 管所要求保护的主题不受任何特定数据结构的限制，但是数据可以存储在计 算设备寄存器中，作为具有多个不同字段和记录的表、XML文档或平面文件 (flat file)存储在关系数据库中。数据还可以以任何计算设备可读格式被格 式化。

一个或多个处理器120可以是任何常规处理器，诸如可购得的CPU或 GPU。替代地，一个或多个处理器可以是专用设备，例如ASIC或其他基于硬 件的处理器。尽管图1在功能上将计算设备110的处理器、存储器和其他元 件示出为在同一块内，但是本领域普通技术人员将理解，处理器、计算设备 或存储器实际上可以包括可以存储或不存储在同一物理壳体内的多个处理器、 计算设备或存储器。例如，存储器可以是位于与计算设备110不同的壳体中 的硬盘驱动器或其他存储介质。因此，对处理器或计算设备的引用将被理解 为包括对可以并行操作或不并行操作的处理器或计算设备或存储器的集合的 引用。

计算设备110可以包括通常与计算设备结合使用的所有组件，诸如上述 处理器和存储器以及用户输入设备150(例如，一个或多个按钮、鼠标、键盘、 触摸屏和/或麦克风)、各种电子显示器(例如，具有屏幕的监测器或可操作以 显示信息的任何其他电气设备)和扬声器154，以根据需要向自动驾驶车辆 100的乘客或其他人提供信息。例如，电子显示器152可以位于自动驾驶车辆 100的车厢内，并且可以由计算设备110使用以向自动驾驶车辆100内的乘 客提供信息。

计算设备110还可以包括一个或多个无线网络连接156，以促进与其他 计算设备(诸如下面详细描述的客户端计算设备和服务器计算设备)的通信。 无线网络连接可以包括短程通信协议，诸如蓝牙、蓝牙低功耗(LE)、蜂窝连 接，以及各种配置和协议，包括互联网、万维网、内联网、虚拟专用网络、广 域网、局域网、使用一个或多个公司专有的通信协议的专用网络、以太网、 WiFi和HTTP、以及前述的各种组合。

计算设备110可以是用于自动驾驶车辆100的自主控制系统的一部分， 并且可以能够与车辆的各种组件通信，以便在自动驾驶模式下控制车辆。例 如，返回图1，计算设备110可以与自动驾驶车辆100的各种系统通信，诸如 减速系统160、加速系统162、转向系统164、信号系统166、规划系统168、 路由系统170、定位系统172、感知系统174、行为建模系统176和功率系统 178，以便在自动驾驶模式下根据存储器130的指令134控制自动驾驶车辆100的移动、速度等。

作为示例，计算设备110可以与减速系统160和加速系统162交互，以 便控制车辆的速度。类似地，转向系统164可以由计算设备110使用，以便 控制自动驾驶车辆100的方向。例如，如果自动驾驶车辆100被配置为诸如 汽车或卡车在道路上使用，则转向系统可以包括用于控制车轮角度以使车辆 转弯的组件。计算设备110还可以使用信号系统166，以便例如通过在需要时 点亮转向信号或刹车灯来向其他驾驶员或车辆发信号通知车辆的意图。

路由系统170可以由计算设备110使用，以便使用地图信息生成到目的 地的路线。规划系统168可以由计算设备110使用，以便生成允许车辆遵循 由路由系统生成的路线的短期轨迹。在这方面，规划系统168和/或路由系 统170可以存储详细的地图信息，例如，识别道路网络的预先存储的高度详 细的地图，包括道路的形状和高程、车道线、交叉路口、人行横道、速度限 制、交通信号、建筑物、标志、实时交通信息(如从远程计算设备(诸如下 面讨论的计算设备410或其他计算设备)接收到的那样更新)、靠边停车地 点、植被或其他这样的对象和信息。

除了上述物理特征信息之外，地图信息可以被配置为道路图，其包括表 示道路或车道路段的多个图形节点和边，所述道路或车道路段一起构成地图 信息的道路网络。每条边由具有特定地理位置(例如，纬度、经度、高度等) 的起始图形节点、具有特定地理位置(例如，纬度、经度、高度等)的结束图 形节点和方向定义。该方向可以指自动驾驶车辆100必须移动以便跟随边的 方向(即，交通流的方向)。图形节点可以位于固定或可变距离处。例如，图 形节点的间隔的范围可以从几厘米到几米，并且可以对应于图形节点所在的 道路的速度限制。在这方面，更大的速度可以对应于图形节点之间的更大距 离。边可以表示沿着相同车道驾驶或改变车道。每个节点和边可以具有唯一 标识符，诸如节点的纬度和经度位置或边的开始和结束位置或节点。除了节 点和边之外，地图可以识别附加信息，诸如在不同边处所需的操纵类型以及 哪些车道是可行驶的。

路由系统170可以使用上述地图信息来确定从当前位置(例如，当前节 点的位置)到目的地的路线。可以使用基于代价的分析来生成路线，基于代 价的分析尝试选择具有最低代价的到目的地的路线。可以以任何数量的方式 来评估代价，诸如到目的地的时间、行进的距离(每条边可以与穿过该边的 代价相关联)、所需的操纵类型、乘客或车辆的便利性等。每条路线可以包括 车辆能够用来到达目的地的多个节点和边的列表。随着车辆行进到目的地， 可以周期性地重新计算路线。

用于路线规划的地图信息可以是与用于规划轨迹的地图相同或不同的地 图。例如，用于规划路线的地图信息不仅需要关于各个车道的信息，而且还 需要车道边界的性质(例如，实心白色、短划线白色、实心黄色等)以确定允 许车道改变的位置。然而，与用于规划轨迹的地图不同，用于路由的地图信 息不需要包括其他细节，诸如人行横道、交通灯、停车标志等的位置，尽管这 些信息中的一些对于路由目的可能是有用的。例如，在具有大量有交通控制 (诸如停车标志或交通信号灯)的交叉路口的路线与不具有交通控制或具有非常少的交通控制的路线之间，后者路线可以具有较低的代价(例如，因为 它更快)，因此是优选的。

定位系统172可以由计算设备110使用，以便确定车辆在地图或地球上 的相对或绝对位置。例如，定位系统172可以包括GPS接收器以确定设备的 纬度、经度和/或高度位置。诸如基于激光的定位系统、惯性辅助GPS或基于 相机的定位的其他定位系统也可以用于识别车辆的位置。车辆的位置可以包 括绝对地理位置，诸如纬度、经度和高度，道路图的节点或边的位置以及相 对位置信息，诸如相对于紧邻其周围的其他汽车的位置，其通常能够以比绝 对地理位置更少的噪声来确定。

定位系统172还可以包括与计算设备110通信的其他设备，诸如加速度 计、陀螺仪或另一方向/速度检测设备，以确定车辆的方向和速度或其变化。 仅作为示例，加速设备可以确定其相对于重力方向或与其垂直的平面的俯仰、 偏航或滚动(或其变化)。该设备还可以跟踪速度的增加或减少以及这种变化 的方向。如本文所阐述的设备对位置和取向数据的提供可以自动提供给计算 设备110、其他计算设备以及前述的组合。

感知系统174还包括用于检测车辆外部的对象的一个或多个组件，诸如 其他车辆、道路中的障碍物、交通信号、标志、树木等。例如，感知系统174 可以包括LIDAR、声纳、雷达、相机和/或记录可以由计算设备110的计算设 备处理的数据的任何其他检测设备。在车辆是诸如小型货车的乘用车的情况 下，小型货车可以包括安装在车顶或其他方便位置上的激光器或其他传感器。

例如，图2是自动驾驶车辆100的示例外部视图。在该示例中，车顶壳 体210和圆顶壳体212可以包括LIDAR传感器以及各种相机和雷达单元。另 外，位于自动驾驶车辆100的前端处的壳体220和车辆的驾驶员侧和乘客侧 上的壳体230、232可以各自容纳LIDAR传感器。例如，壳体230位于驾驶 员门260的前方。自动驾驶车辆100还包括用于也位于自动驾驶车辆100的 车顶上的雷达单元和/或相机的壳体240、242。附加的雷达单元和相机(未示出)可以位于自动驾驶车辆100的前端和后端处和/或沿着车顶或车顶壳体210 的其他位置上。

计算设备110可以能够与车辆的各种组件通信，以便根据计算设备110 的存储器的主车辆控制代码来控制自动驾驶车辆100的移动。例如，返回图 1，计算设备110可以包括与自动驾驶车辆100的各种系统通信的各种计算设 备，诸如减速系统160、加速系统162、转向系统164、信号系统166、规划 系统168、路由系统170、定位系统172、感知系统174、行为建模系统176 和功率系统178(即车辆的引擎或马达)，以便根据存储器130的指令134控 制自动驾驶车辆100的移动、速度等。

车辆的各种系统可以使用自动驾驶车辆控制软件来运行，以便确定如何 控制车辆。作为示例，感知系统174的感知系统软件模块可以使用由自动驾 驶车辆的一个或多个传感器(例如相机、LIDAR传感器、雷达单元、声纳单 元等)生成的传感器数据来检测和识别对象及其特性。这些特性可以包括位 置、类型、前进方向(heading)、取向、速度、加速度、加速度的变化、尺寸、 形状等。在一些情况下，可以将特性输入到行为建模系统176的行为预测系 统软件模块中，该行为预测系统软件模块使用基于对象类型的各种行为模型 来输出检测到的对象的预测未来行为。在其他情况下，可以将特征放入一个 或多个检测系统软件模块中，诸如被配置为检测已知交通信号的状态的交通 灯检测系统软件模块、被配置为从由车辆的一个或多个传感器生成的传感器 数据检测施工区的施工区检测系统软件模块以及被配置为从由车辆的传感器 生成的传感器数据检测紧急车辆的紧急车辆检测系统。这些检测系统软件模 块中的每一个可以使用各种模型来输出施工区或对象是紧急车辆的可能性。 检测到的对象、预测的未来行为、来自检测系统软件模块的各种可能性、识 别车辆环境的地图信息、来自识别车辆的位置和取向的定位系统172的位置 信息、车辆的目的地位置或节点以及来自车辆的各种其他系统的反馈可以被 输入到规划系统168的规划系统软件模块中。规划系统168可以基于由路由 系统170的路由模块生成的路线，使用该输入来生成车辆在未来的某个短暂 时间段内遵循的轨迹。在这方面，轨迹可以限定加速度、减速度、速度等的特 定特性，以允许车辆遵循朝向到达目的地的路线。计算设备110的控制系统软件模块可以被配置为例如通过控制车辆的制动、加速和转向来控制车辆的 移动，以便遵循轨迹。

计算设备110可以通过控制各种组件来在自动驾驶模式下控制车辆。例 如，作为示例，计算设备110可以使用来自详细地图信息和规划系统168的 数据完全自主地将车辆导航到目的地位置。计算设备110可以使用定位系统 172来确定车辆的位置，并且使用感知系统174来检测对象并在需要时对其 做出响应以安全地到达该位置。再次，为了这样做，计算设备110和/或规划 系统168可以生成轨迹并使车辆遵循这些轨迹，例如，通过使车辆加速(例 如，通过由加速系统162向引擎或功率系统178供应燃料或其他能量)、减速 (例如，通过减少供应给引擎或功率系统178的燃料、改变档位和/或通过由 减速系统160施加制动)、改变方向(例如，通过由转向系统164转动自动驾 驶车辆100的前轮或后轮)，并且使用信号系统166发信号通知这样的变化 (例如，通过点亮转向信号)。因此，加速系统162和减速系统160可以是包 括车辆的引擎与车辆的车轮之间的各种组件的传动系的一部分。再次，通过 控制这些系统，计算设备110还可以控制车辆的传动系，以便自主地操纵车 辆。

自动驾驶车辆100还可以包括反馈系统。例如，转到图3，反馈系统300 可以包括具有一个或多个处理器320、存储器330、数据332和指令334的一 个或多个计算设备310。这样的处理器、存储器、数据和指令可以分别与计算 设备110的一个或多个处理器120、存储器130、数据132和指令134类似地 配置。反馈系统300可以与自动驾驶车辆100的各种系统通信，包括计算设 备110、减速系统160、加速系统162、转向系统164、信号系统166、规划系 统168、路由系统170、定位系统172、感知系统174、行为建模系统176、功 率系统178等。替代地，反馈系统可以并入计算设备110中或作为计算设备 110的一部分。

计算设备310可以包括用户输入设备350、电子显示器352、扬声器354 和无线网络连接356。这些中的每一个可以被配置为与如上所述的用户输入 设备150、电子显示器152、扬声器154和无线网络连接156相同或类似。在 其他情况下，这些可以是相同的(即，不需要在计算设备110和计算设备310 之间全部复制)。

计算设备310还可以包括一个或多个无线网络连接356，以促进与其他 计算设备(诸如下面详细描述的客户端计算设备和服务器计算设备)的通信。 无线网络连接可以包括短程通信协议，诸如蓝牙、蓝牙低功耗(LE)、蜂窝连 接，以及各种配置和协议，包括互联网、万维网、内联网、虚拟专用网络、广 域网、局域网、使用一个或多个公司专有的通信协议的专用网络、以太网、 WiFi和HTTP，以及前述的各种组合。

另外，存储器330和/或存储器130可以存储关于反馈请求的信息。这样 的信息可以包括三个主要特征：触发环境、显示要求和数据收集参数。触发 环境可以包括要求，诸如在预定时间段或预定次数(例如10次喇叭鸣响)内 的驾驶事件、其他道路用户的存在或动作、行程状态、道路图要求、支持交 互、用户生成/发起的反馈、乘客生命周期、一天中的时间、其他驾驶条件(例 如交通或天气条件)，或者这些的一次性组合。驾驶事件的示例可以包括紧急 的制动、转弯或摆动、某些加速(例如，快速加速)、从自动驾驶模式脱离到 手动驾驶模式等。其他道路用户的存在或动作的示例可以包括存在单个行人、 多个行人、单个骑车者、多个骑车者、单个踏板车、多个踏板车、喇叭鸣响、 被另一个道路用户超过或赶上等的情况。行程状态的示例可以包括搭乘是刚 上车还是快下车、在为紧急情况停车之后已经开始移动、在行程已经取消等。

道路图要求可以包括某些类型的交叉路口、无保护转弯、狭窄街道、施 工区、脱离区(其中，自动驾驶车辆将自动地从自动驾驶模式脱离到手动驾 驶模式)或者不允许靠边停车的区域等。支持交互的示例可以包括由乘客和/ 或远程辅助操作者在乘客和远程辅助操作者之间发起呼叫或聊天。乘客生命 周期(passenger lifecycle)的示例可以包括乘客是否处于特定搭乘号码(例如， 第一次搭乘、第10次搭乘等)、每周搭乘的特定数量、搭乘之间的特定天数 或周数、自第一次搭乘以来的特定周数等。

显示要求可以限定何时显示反馈请求，以便以及时的方式捕获最有用的 反馈。在一些情况下，默认显示要求可以是一旦满足触发环境就立即显示反 馈请求。在其他情况下，显示要求可以限定已经满足的触发环境与显示反馈 请求之间的延迟时间。在其他情况下，显示要求可以限定附加标准，诸如如 果存在紧急情况并且自动驾驶车辆停车，则等待直到自动驾驶车辆再次移动 为止。

数据收集参数可以识别反馈请求要收集的信息，或者更确切地说，限定 要输入到反馈系统中的信息的参数，诸如二元(是/否)、滑动标尺、大量响应 (bucket responses)(例如，微笑到皱眉以暗示愉悦或不悦等)。在一些情况下， 反馈请求的数据收集参数也可以基于乘客的类型和/或生命周期而不同。例如， 与经验较少的搭乘者相比，对经验更丰富的乘客(诸如已经进行了更多搭乘、 出于测试目的正在进行未付费搭乘、或者之前已经提供了关于事件类型的直 接反馈的乘客)的反馈请求可能接收到更直接的问题。例如，在紧急制动事 件之后，反馈请求对于具有较少经验的乘客可能更通用(例如，“现在驾驶舒适度如何？”)并且对于具有更多经验的乘客可能更具体(例如，“那个制动如何？”)。

假设反馈请求满足质量和有用性的内部要求(例如，一些内部标准)，则 反馈请求被分配优先级。在一个实例中，优先级对应于可能发生触发环境的 频率的倒数。较低频率的触发环境会导致较高的优先级，反之亦然。这能够 根据日志的数据来估计。作为另一实例，优先级可以对应于对特定类型的数 据的需要，而不管频率如何。例如，如果需要测量车辆对某些类型的道路用 户的响应，诸如对儿童或家庭群组(例如，儿童和成人一起)的响应，则可以 为这样的反馈请求分配比其他类型的反馈请求更高的优先级。

触发环境、显示要求和数据收集参数可以存储在存储器330的查找表、 数据库或其他存储配置中，其允许反馈系统的一个或多个计算设备310精确 地确定何时满足触发环境，然后识别任何对应的显示要求和数据收集参数。

自动驾驶车辆100的计算设备110还可以从其他计算设备接收信息或向 其他计算设备传送信息，诸如作为运输服务的一部分的那些计算设备以及其 他计算设备。图4和图5分别是包括经由网络460连接的多个计算设备410、 420、430、440和存储系统450的示例系统400的示意图和功能图。系统400 还包括自动驾驶车辆100A和自动驾驶车辆100B，其可以被配置为与自动驾 驶车辆100相同或类似。尽管为了简单起见仅描绘了几个车辆和计算设备， 但是典型的系统可以包括明显更多的车辆和计算设备。

如图5所示，计算设备410、420、430、440中的每一个可以包括一个或 多个处理器、存储器、数据和指令。这样的处理器、存储器、数据和指令可以 与计算设备110的一个或多个处理器120、存储器130、数据132和指令134 类似地配置。

网络460和中间(intervening)图形节点可以包括各种配置和协议，包括 短程通信协议，诸如蓝牙、蓝牙LE、互联网、万维网、内联网、虚拟专用网 络、广域网、局域网、使用一个或多个公司专有的通信协议的专用网络、以太 网、WiFi和HTTP，以及前述的各种组合。这种通信可以由能够向其他计算 设备发送数据和从其他计算设备接收数据的任何设备(诸如调制解调器和无 线接口)来促进。

在一个示例中，一个或多个计算设备410可以包括具有多个计算设备的 一个或多个服务器计算设备，例如，负载平衡服务器群，其与网络的不同节 点交换信息，以用于从其他计算设备接收数据、处理数据以及向其他计算设 备发送数据。例如，一个或多个计算设备410可以包括能够经由网络460与 自动驾驶车辆100的计算设备110或自动驾驶车辆100A或自动驾驶车辆 100B的类似计算设备以及计算设备420、430、440通信的一个或多个服务器 计算设备。例如，车辆100、100A、100B可以是能够由服务器计算设备分派 到各个位置的车队的一部分。在这方面，服务器计算设备410可以用作车队 管理系统，其能够用于通过分配和分派诸如车辆100、100A、100B的车辆来 为乘客安排行程。这些安排可以包括调度到不同位置的行程以便这些乘客上 车和下车。在这方面，服务器计算设备410可以使用调度系统软件来操作， 以便管理上述自动驾驶车辆调度和分派。另外，计算设备410可以使用网络460在显示器(诸如计算设备420、430、440的显示器424、434、444)上向 用户(诸如用户422、432、442)发送和呈现信息。在这方面，计算设备420、 430、440可以被认为是客户端计算设备。

如图4所示，每个客户端计算设备420、430可以是旨在供用户422、432 使用的个人计算设备，并且具有通常与个人计算设备结合使用的所有组件， 包括一个或多个处理器(例如，中央处理单元(CPU))、存储数据和指令的存 储器(例如，RAM和内部硬盘驱动器)、诸如显示器424、434、444的显示 器(例如，具有屏幕的监测器、触摸屏、投影仪、电视或可操作以显示信息的 其他设备)、以及用户输入设备426、436、446(例如，鼠标、键盘、触摸屏 或麦克风)。客户端计算设备还可以包括用于记录视频流的相机、扬声器、网 络接口设备以及用于将这些元件彼此连接的所有组件。

尽管客户端计算设备420、430可以均包括全尺寸个人计算设备，但是它 们可以替代地包括能够通过诸如互联网的网络与服务器无线地交换数据的移 动计算设备。仅作为示例，客户端计算设备420可以是移动电话或诸如以下 项的设备：启用无线的PDA、平板PC、可穿戴计算设备或系统，或者能够经 由互联网或其他网络获得信息的上网本。在另一示例中，客户端计算设备430 可以是可穿戴计算系统，示出为如图4所示的腕表。作为示例，用户可以使 用小键盘、小键区、麦克风、使用相机的视觉信号或触摸屏来输入信息。作为 又一示例，客户端计算设备440可以是包括键盘、鼠标、相机和其他输入设 备的台式计算系统。

客户端计算设备中的每一个可以是由人(例如，人类操作者或用户422、 432、442)用来审查和分析由车辆的感知系统(诸如自动驾驶车辆100的感 知系统174)生成的传感器数据和其他信息的远程计算设备。尽管在图3和 图4中仅示出了几个远程计算设备，但是在典型的系统中可以包括任何数量 的这样的工作站。

与存储器130一样，存储系统450可以是能够存储可由服务器计算设备 410访问的信息的任何类型的计算机化存储器，诸如硬盘驱动器、存储卡、 ROM、RAM、DVD、CD-ROM、可写和只读存储器。另外，存储系统450可 以包括分布式存储系统，其中，数据存储在多个不同的存储设备上，这些存 储设备可以物理地位于相同或不同的地理位置。存储系统450可以经由如图 4和图5所示的网络460连接到计算设备，和/或可以直接连接到或并入到计 算设备110、410、420、430、440等中的任何一个中。

如下面更详细描述的，存储系统450可以存储各种类型的信息。该信息 可以由服务器计算设备(诸如一个或多个服务器计算设备410)检索或以其他 方式访问，以便执行本文描述的一些或所有特征。例如，存储系统450可以 存储日志数据。日志数据可以包括例如由感知系统(诸如自动驾驶车辆100的 感知系统174)生成的传感器数据。感知系统可以包括生成传感器数据的多个 传感器。作为示例，传感器数据可以包括原始传感器数据以及识别所感知的 对象(包括其他道路用户)的定义的特性的数据，诸如对象(诸如车辆、行 人、骑自行车者、植被、路缘、车道线、人行道、人行横道、建筑物等)的形 状、位置、取向、速度等。日志数据还可以包括识别不同类型的事件的“事 件”数据，所述事件诸如与其他对象的碰撞或接近碰撞、描述自动驾驶车辆 100的潜在路径的规划地形和/或速度的规划轨迹、车辆在不同时间的实际位 置、车辆在不同时间的实际取向/前进方向、车辆在不同时间的实际速度、加 速度和减速度(和/或速度、取向/前进方向/转向角、加速度等随时间的变化)、感知对象的分类和响应、感知对象的行为预测、车辆的各种系统(诸如加速 度、减速度、感知、转向、信号、路由、功率等)在不同时间的状态(包括日 志的错误、车辆的各种系统在不同时间的输入和输出等)。因此，这些事件和 传感器数据可以用于“重建”车辆的环境，包括感知的对象以及模拟中车辆 的行为。

日志数据中的至少一些可以是“搭乘数据”，即，在由乘客在诸如自动驾 驶车辆100的自动驾驶车辆中进行的特定行程或搭乘期间生成的日志数据。 搭乘数据可以包括日志数据的所有上述特征，或者可以仅包括特定类型的数 据，诸如来自车辆的规划系统(诸如规划系统168)的运动规划命令、来自车 辆的遥测、来自用于控制车辆的地图信息的上下文、来自车辆的感知系统(诸 如感知系统174)的其他道路用户(诸如车辆、骑自行车者、行人等)的处理 的或原始的传感器数据、加速度信息、抖动(jerk)(或加速度的导数(derivative)) 信息等。搭乘数据还可以与由一个或多个乘客针对特定搭乘提供的搭乘反馈 相关联。如下面进一步讨论的，该反馈中的至少一些可以由乘客响应于例如 在不愉快事件期间或之后立即提供。另外地或替代地，如下面进一步讨论的， 反馈可以包括在搭乘已经完成之后的总体搭乘质量值。

示例方法

除了上述和附图中所示的操作之外，现在将描述各种操作。应当理解， 以下操作不必以下面描述的精确顺序执行。相反，能够以不同的顺序或同时 处理各种步骤，并且还可以添加或省略步骤。

图8包括用于从自动驾驶车辆的乘客收集反馈的一些示例的示例流程图800，其可以例如由自动驾驶车辆的反馈系统的一个或多个处理器(诸如自动 驾驶车辆100的反馈系统300的处理器320和/或计算设备110的处理器120) 执行。例如，在框810处，确定已经满足用于触发反馈请求的触发环境。所 述触发环境包括驾驶事件、其他道路用户的存在或行程状态中的一个或多个。

反馈系统300的计算设备310可以监测来自自动驾驶车辆100的各种系 统的信息。例如，反馈系统的计算设备可以不断地分析来自自动驾驶车辆的 定位系统172的道路图特征和位置信息、来自自动驾驶车辆的路由系统170 和规划系统168的路线和轨迹特征、来自自动驾驶车辆的感知系统174的检 测到的对象和特性(例如，诸如黄灯、人行横道中的行人等的状态)、以及来 自自动驾驶车辆的行为建模系统176的行为预测(例如，预测轨迹)等。基 于此，反馈系统可以确定存储器330中限定的触发环境何时发生。

在框820处，基于所述确定，确定反馈请求的显示要求和数据收集参数。 显示要求限定何时显示反馈请求，而数据收集参数识别反馈请求要收集的信 息。例如，一旦在存储器330和/或存储器130中识别出触发环境，则计算设 备310可以识别任何相关联的显示要求和数据收集参数。

在框830处，基于显示要求和数据收集参数提供反馈请求以供显示。一 旦发生触发环境，反馈系统的计算设备就能够为用户生成并显示界面。这能 够通过经由诸如网络460的网络向乘客的客户端计算设备发送反馈请求来显 示在车辆的显示器(诸如显示器152或显示器352)上，或者潜在地显示在乘 客的客户端计算设备(例如，客户端计算设备420)上。反馈请求可以在具有 或不具有可听通知(例如，“叮的一声”)的情况下被显示。

图6A-图6H提供了可以在行程期间由计算设备110和/或310显示在显 示器152或352上的信息的示例表示。在图6A的示例中，在乘客已经发起 到目的地的行程之后，描绘了指示自动驾驶车辆100正在到目的地的途中的 信息屏幕。图6B描绘了可以在图6A的示例之后显示的反馈请求的示例表 示。在该示例中，图6B的反馈请求包括用于用户提供反馈的信息(“Kat，上车顺利么？”)以及多个选项(愤怒的脸、皱眉的脸、中立的脸和微笑的脸等) 的请求。在该示例中，反馈请求已被定制为包括乘客的姓名(“Kat”)，尽管这 可能不是必需的。

图7A和图7B提供了可以如何在乘客的客户端计算设备处显示反馈请求 的示例。在图7A中，反馈请求最初在乘客的客户端计算设备420的“锁定屏 幕”上显示为通知。一旦乘客打开通知，则显示反馈请求的其余部分。

如上所述，多个选项可以由反馈请求的数据收集参数限定。在图6C的示 例中，乘客可能已经例如使用触摸屏或车辆的另一用户输入设备(例如，用 户输入设备150)选择了愤怒的脸(这里是“糟糕”)。如图6C和图7C所示， 计算设备110和/或310可以自动突出显示所选择的选项。

然而，如上所述，何时显示反馈请求取决于反馈请求的显示要求。在这 方面，显示要求可以识别在满足触发条件之后多久才显示反馈请求。作为示 例，显示要求可以是“进入窄车道后15秒”、“在刚离开交叉路口后”等。某 些反馈请求可能更适合于一种类型的输入(例如，用于车辆的语音和用于电 话的文本)。

在一些情况下，可能存在要同时或在短时间段内显示的多个反馈请求。 例如，在10秒的时间段内，反馈系统可以确定已经满足了两个或多个不同的 反馈请求的触发条件。优先级可以允许反馈系统选择那些请求中最重要的请 求以显示给用户，而牺牲其他请求。另外或替代地，较低优先级请求可能潜 在地延迟到稍后的搭乘。

在框840处，响应于所述提供，接收来自车辆的乘客的反馈。例如，乘 客可以经由用户输入设备150和/或用户输入设备350或通过乘客的客户端计 算设备的用户输入设备来提供反馈。如果使用客户端计算设备(例如，乘客 的移动电话)，则反馈可以被发送到车辆(例如，经由蓝牙、蓝牙低功耗(LE)、 近场通信、经由网络460或其他通信协议)，或者可以被发送到服务器计算设 备(诸如服务器计算设备410)并且随后由服务器计算设备转发到乘客的客户 端计算设备(例如，计算设备420)。

在一些情况下，反馈请求可以包括对信息的反馈请求的多个“层”，以便 收集关于乘客体验的尽可能多的信息。换句话说，根据乘客的响应，可以显 示附加的反馈请求。例如，转到图6D和图7C，可以响应于用户分别选择图 6C或图7C中的皱眉的脸而显示第二反馈请求(“告诉我们哪里糟糕”)。第二 反馈请求还可以包括再次由第二反馈请求的数据收集参数限定的多个选项 (“感觉不安全”、“错误地点”和“远离路缘”)。在该示例中，乘客可以选择 “感觉不安全”选项，如图6E中突出显示的。

如图6E所示，一旦乘客已经向第二反馈请求(或潜在地如图6B所示的 初始反馈请求)提供反馈，计算设备110和/或310就可以提供附加选项，诸 如可以允许乘客记录和提交可听或视频消息的“添加评论”以及可以允许乘 客提交对反馈请求的响应的“提交”选项。类似地，如图7D所示，客户端计 算设备420可以显示文本框(“要添加的任何内容”)以供用户提供文本以及 提供图像或音频记录的附加选项(分别为选项710和选项720)。图7D还提供了选项730以提交乘客的反馈。

例如，在图6F和图6G的示例中，如通知620所指示的，正在记录(“收 听”)音频。该示例还向乘客提供了一些指导(尝试解释，例如“难以尝试进 入汽车”)连同用于“取消”可听记录或“提交”可听记录的附加选项。在图 6G的示例中，计算设备110和/或310已经转录了可听消息并将其再次显示 在显示器上，连同用于“取消”可听记录或“提交”可听记录的附加选项。

在框850处，存储反馈以供后续使用。反馈结果可以被接收并存储在例 如存储器130和/或存储器330中，以供后续分析和/或自动发送到车队管理系 统以供存储和后续分析。在这方面，反馈可以被发送到服务器计算设备410以 存储在存储系统450中。一旦乘客选择了任何上述提交选项，如图6H所示， 计算设备110和/或310就可以提供由用户提供的反馈的概要以及反馈正在被 提交(例如，存储以供后续使用和/或自动发送)的指示630。一旦提交和/或 在适当的时间段已经过去之后，显示器152和/或352可以返回到图6A中的 信息屏幕或另一信息屏幕，图6A中的信息屏幕指示自动驾驶车辆100正在 其去往目的地的途中。

在一些情况下，会诊团队可以审查反馈并为最初请求反馈的人类操作员 或另一实体创建通知(例如，错误)。另外，在存在问题何时发生的准确时间 戳(例如，与“在我20分钟搭乘中的某个时间，一辆汽车拦住了我们”相比， “几秒前一辆汽车拦住了我们”)的情况下，会诊团队可以更快速/有效地能够 对问题溯源。

在一些情况下，可以实时使用反馈来影响自动驾驶车辆的驾驶行为。例 如，如果乘客对自动驾驶车辆突然加速进行无保护转弯或一些其他操纵的时 刻具有强烈的负面反应，则能够从此时开始更保守地控制自动驾驶车辆，从 而更少地为了时间/路线效率而进行优化，并且甚至潜在地避免违规操纵。作 为另一示例，如果乘客实时报告负面的上车体验，则车队管理系统会能够为 车队中的所有其他自动驾驶车辆禁用该上车位置，并避免该区域中的其他不 良的上车，例如，至少直到能够确定负面的上车体验的原因为止。

反馈请求还能够具有频率以及乘客限定的限制。例如，每次行程可以显 示固定的最大数量的反馈请求，或者这可以根据行程的长度而变化。在一些 情况下，特定行程的反馈请求的数量可以根据乘客提供响应的过去历史而变 化(例如，该乘客在过去行程期间的更多响应对应于当前行程的更多反馈请 求)。在一些情况下，可以使用机器学习方法来基于不同群组或类型的乘客来 确定在行程期间显示的反馈请求的数量和频率。例如，正在测试车辆的乘客 可以预期比付费乘客提供更多的反馈。此外，可以预期他们的第一次搭乘(较 新的乘客)、第10次搭乘或第100次搭乘(经验丰富的乘客)的乘客提供不 同类型、数量和质量的反馈。这些频率要求可以与触发环境相关联并且也存 储在存储器130和/或330中。

在一些情况下，乘客可以“静音”或不请求“这种”附加反馈请求或“根 本”不请求附加反馈请求。例如，乘客能够通过经由用户输入设备150或者 从乘客自己的客户端计算设备(例如移动电话)选择在旅行开始时静音反馈 来做出改变，指示乘客不想在行程期间被打扰。乘客还可以使用那些信道之 一来响应特定反馈请求，从而选择暂停所述种类或类型的反馈或在行程的持 续时间内暂停反馈。乘客还可以能够选择跨行程的反馈的偏好(例如，在账 户设置中，经由乘客的客户端计算设备，其能够在行程期间但非必须，或者 经由车辆的用户输入设备)。可以将此偏好信息发送到计算设备110和/或310， 以便控制对当前行程的请求的频率(或甚至仅完全静默)。另外，可以将偏好 信息发送到服务器计算设备，诸如服务器计算设备410，以便将未来反馈请求 的偏好与乘客的账户信息一起存储。再次，如果使用客户端计算设备(例如， 乘客的移动电话)，则偏好信息可以被发送到车辆(例如，经由蓝牙、蓝牙低 功耗(LE)、近场通信或其他通信协议)，或者可以首先被发送到服务器计算 设备(诸如服务器计算设备410)并且随后由服务器计算设备转发到车辆的计 算设备(例如，计算设备110和/或310)。

本文描述的特征可以允许自动驾驶车辆在对利益相关者重要的事件正在 发生时，实时收集来自乘客的反馈。因此，反馈可以更准确并且甚至更有用， 这是因为它不是在行程已经完成之后被简单地收集的。例如，乘客将刚刚经 历过该事件，因此将比行程中后续对其具有更好的记忆。此外，搭乘中后续 的其他负面或正面事件将不会影响乘客对当前事件的反馈。此外，与在搭乘 结束时(当乘客会不太可能正确地回忆答案时)同时询问几个问题相比，如 果在搭乘过程中多次询问反馈，则一些乘客可能具有更好的体验。

除非另有说明，否则前述替代示例不是相互排斥的，而是可以以各种组 合来实现以实现独特的优点。由于能够在不脱离由权利要求限定的主题的情 况下利用上述特征的这些和其他变化和组合，因此实施例的前述描述应当通 过说明的方式而不是通过限制由权利要求限定的主题的方式来理解。另外， 本文描述的示例的提供以及措辞为“诸如”、“包括”等的条款不应被解释为 将权利要求的主题限制在具体示例；相反，这些示例仅旨在说明许多可能的 实施例之一。此外，不同附图中的相同附图标记能够标识相同或相似的元素。

Claims (20)

1.一种从自动驾驶车辆的乘客收集反馈的方法，所述方法包括：

由自动驾驶车辆的反馈系统的一个或多个处理器确定已经满足用于触发反馈请求的触发环境，所述触发环境包括驾驶事件、其他道路用户的存在或行程状态中的一个或多个；

基于所述确定，由一个或多个处理器识别反馈请求的显示要求和数据收集参数，其中，所述显示要求限定何时显示反馈请求，而所述数据收集参数识别反馈请求要收集的信息；

由一个或多个处理器基于显示要求和数据收集参数提供反馈请求以供显示；

响应于所述提供，由一个或多个处理器接收来自自动驾驶车辆的乘客的反馈；以及

由一个或多个处理器存储反馈以供后续使用。

2.根据权利要求1所述的方法，其中，所述驾驶事件包括从自动驾驶模式脱离到手动驾驶模式。

3.根据权利要求1所述的方法，其中，所述其他道路用户的存在包括预定义数量的行人。

4.根据权利要求1所述的方法，其中，所述其他道路用户的存在包括预定义数量的骑自行车者。

5.根据权利要求1所述的方法，其中，所述行程状态包括从乘客上车开始的时间。

6.根据权利要求1所述的方法，其中，所述行程状态包括从乘客下车开始的时间。

7.根据权利要求1所述的方法，其中，所述触发环境还包括搭乘者生命周期要求。

8.根据权利要求7所述的方法，其中，所述搭乘者生命周期要求包括乘客是否在特定搭乘号码上。

9.根据权利要求7所述的方法，其中，所述搭乘者生命周期要求包括乘客是否在一周内进行了特定数量的搭乘。

10.根据权利要求7所述的方法，其中，所述搭乘者生命周期要求包括乘客是否在搭乘之间具有预定义时间量。

11.根据权利要求7所述的方法，其中，所述搭乘者生命周期要求包括自第一次搭乘以来的预定义周数。

12.根据权利要求1所述的方法，其中，所述触发环境还包括支持交互要求。

13.根据权利要求1所述的方法，其中，所述显示要求限定触发环境已经被满足与显示反馈请求之间的延迟时间。

14.根据权利要求1所述的方法，其中，所述显示要求包括必须在显示反馈请求之前发生的车辆动作。

15.根据权利要求1所述的方法，还包括：基于所述确定，识别反馈请求的优先级，其中，所述优先级对应于可能发生触发环境的频率的倒数。

16.根据权利要求15所述的方法，还包括：使用反馈请求的优先级来确定何时显示反馈请求。

17.根据权利要求1所述的方法，其中，所述提供包括在自动驾驶车辆的显示器上提供显示。

18.根据权利要求1所述的方法，其中，所述提供包括在与乘客相关联的客户端计算设备的显示器上提供显示。

19.根据权利要求1所述的方法，还包括：基于所述确定，识别反馈请求的频率限制，并且其中，所述提供还基于频率限制。

20.根据权利要求19所述的方法，其中，所述频率限制包括在行程期间显示的反馈请求的固定最大数量。

Images