Patent ID: 12223841

DETAILED DESCRIPTION

The following detailed description is merely exemplary in nature and is not intended to limit the application and uses. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, summary, or the following detailed description. As used herein, the term “module” refers to any hardware, software, firmware, electronic control component, processing logic, and/or processor device, individually or in any combination, including without limitation: application specific integrated circuit (ASIC), a field-programmable gate-array (FPGA), an electronic circuit, a processor (shared, dedicated, or group) and memory that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.

Embodiments of the present disclosure may be described herein in terms of functional and/or logical block components and various processing steps. It should be appreciated that such block components may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. For example, an embodiment of the present disclosure may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. In addition, those skilled in the art will appreciate that embodiments of the present disclosure may be practiced in conjunction with any number of systems, and that the systems described herein is merely exemplary embodiments of the present disclosure.

For the sake of brevity, conventional techniques related to signal processing, data transmission, signaling, control, machine learning models, radar, lidar, image analysis, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail herein. Furthermore, the connecting lines shown in the various figures contained herein are intended to represent example functional relationships and/or physical couplings between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in an embodiment of the present disclosure.

The subject matter described herein discloses apparatus, systems, techniques, and articles for an On-Demand Autonomy (ODA) system that incorporates an onboard/offboard Ride Assistant human machine interface (HMI) system. The Ride Assistant system may enable a mechanism to select and rate leader(s)/follower(s) at the beginning and end of trips; allow for follower or leader or authorized person initiated ongoing trip interrupts, such as modifications (e.g., pit stop) or terminations, via a mobile application (offboard) or infotainment system (onboard) or visual gestures. The following disclosure describes apparatus, systems, techniques, and articles for enhancing user safety by leveraging in-vehicle monitoring (e.g., cabin camera, external camera) and communication systems. The following disclosure describes apparatus, systems, techniques, and articles for providing a robust feedback system (e.g., using display/haptic/voice/gestures/alert sounds) that can be tapped to communicate with users in requesting vehicle or leader vehicle at various stages of service provisioning such as initiation, active, hand-off, and termination. The following disclosure describes apparatus, systems, techniques, and articles for accepting leader(s)/follower(s) based on ratings, leaving a rating based on comfort and safety at the end of the trip.

FIG.1is a block diagram depicting an example On-Demand Autonomy (ODA) system100for providing ODA services. The example ODA system100includes an On-Demand Autonomy server (ODAS)102, one or more leader vehicles (Lv)104, and one or more follower vehicles (Fv)106. The ODA system100is configured to implement a platooning service wherein a group of vehicles (including the one or more leader vehicles104and the one or more follower vehicles106) are driven together in a platoon. In a platoon, the distances between vehicles (e.g., cars or trucks) can be reduced using a virtual coupling108(e.g., electronic coupling) between leader and follower vehicles. The virtual coupling108allows future vehicle maneuvers to be communicated ahead of time to allow the platooned vehicles to accelerate or brake simultaneously. The virtual coupling108can also allow for a closer headway between vehicles while traveling as a platoon by reducing or eliminating reacting distance since future vehicle maneuvers are known ahead of time. In the ODA system100, the Lv104is communicatively coupled to the ODAS102via a communication link110, and the Fv106is communicatively coupled to the ODAS102via a communication link112. Through the communication links110,112, the ODAS102can facilitate setup of platooning trip between a Lv104and a Fv106, monitor the Lv104and the Fv106during the platooning trip, communicate status information regarding the platooned vehicles104,106to each other, communicate platoon termination requests between the platooned vehicles104,106, and communicate safety information between the platooned vehicles104,106.

The virtual coupling108and communication links110,112, may be implemented using a wireless carrier system such as a cellular telephone system and/or a satellite communication system. The wireless carrier system can implement any suitable communications technology, including, for example, digital technologies such as CDMA (e.g., CDMA2000), LTE (e.g., 4G LTE or 5G LTE), GSM/GPRS, or other current or emerging wireless technologies.

The communication links110,112, may also be implemented using a conventional land-based telecommunications network coupled to the wireless carrier system. For example, the land communication system may include a public switched telephone network (PSTN) such as that used to provide hardwired telephony, packet-switched data communications, and the Internet infrastructure. One or more segments of the land communication system can be implemented using a standard wired network, a fiber or other optical network, a cable network, power lines, other wireless networks such as wireless local area networks (WLANs), or networks providing broadband wireless access (BWA), or any combination thereof.

In one example implementation, Lv104comprises an autonomous vehicle that is configured as a leader vehicle. In this example, the Lv includes a processor in communication with an ODAS configured to: determine whether to confirm a request for an on-demand autonomy ODA service which is received via a broadcast by the ODAS to a set of Lvs wherein the ODA service request includes navigation and control of an Fv to a requested location by creating a virtual link between the Lv and the Fv to configure a vehicle platoon to enable transport of the Fv by the Lv wherein the vehicle platoon is a linking of the Lv to the Fv via the virtual link to enable the Lv to assume control of the Fv, and to navigate the Fv to the requested location; process information broadcast from the ODA server wherein the information broadcast occurs via a distribution protocol to solicit multiple responses from the set of Lvs to create the virtual link between the Lv and Fv wherein each Lv of the set of Lvs independently makes a decision whether to confirm the ODA service request and to create the virtual link with the Fv; determine a value score independently by the Lv based on the information broadcast that provides a cost metric of an amount provided by the ODA service for the Lv to perform an operation of navigating and the control of the Fv to the requested location wherein the value score is based on a set of factors associated directly with operation of the Lv to the ODA service request; and decide whether in a first instance, confirm acceptance of the ODA service request and enable the virtual link to navigate and the control by the Fv of the Lv in the vehicle platoon to the requested location, and in a second instance, continue to monitor the information broadcast from the ODA server to wait for another ODA service request.

In one example implementation, Fv106comprises an autonomous or semiautonomous vehicle that includes a processor in communication with an ODAS. In this example, the processor is configured to enable the Fv to establish a virtual link in a platoon with an Lv wherein the virtual link enables the Fv to simulate vehicle operations of a high level of autonomous driving capability without the Fv being configured for the high level of autonomous driving capability.

In one example implementation, ODAS102includes a processor in communication with a first vehicle and at least one second vehicle. In this example, the processor responsive to receiving a trip request for ODA service from the first vehicle is configured to seek an agreement to establish a virtual link between the first vehicle and the at least one second vehicle. To seek an agreement, the processor is configured to: broadcast the trip request to a group of second vehicles; receive a set of responses submitted by one or more second vehicles to the broadcast trip request; identify at least one second vehicle as an Lv from the submitted responses from the group of second vehicles based on a matching operation; coordinate one or more responses between the first and second vehicles based on results of the matching operation to confirm an acceptance of the agreement; and in response to confirmation of the acceptance of the agreement, create a trip plan for the trip request for the ODA service based on a set of preferences received from each of the vehicles.

FIG.2is a block diagram depicting an example vehicle200that may be used in the example ODA system as a leader vehicle or follower vehicle. The example vehicle200generally includes a chassis12, a body14, front wheels16, and rear wheels18. The body14is arranged on the chassis12and substantially encloses components of the vehicle200. The body14and the chassis12may jointly form a frame. The wheels16-18are each rotationally coupled to the chassis12near a respective corner of the body14. The vehicle200is depicted in the illustrated embodiment as a passenger car, but other vehicle types, including trucks, sport utility vehicles (SUVs), recreational vehicles (RVs), etc., may also be used. The vehicle200may be capable of being driven manually, autonomously and/or semi-autonomously.

The vehicle200, in this example, is an autonomous vehicle. The example autonomous vehicle200may include a so-called Level Two, Two plus, Three, Four, or Level Five automation system. A level Two or Two plus system indicates a system that has capabilities to create and confirm a virtual link and enable an Lv to control the Fv to a requested location where the Fv has relinquished control of vehicle operation to the Lv.

A Level Four system indicates “high automation”, referring to the driving mode-specific performance by an automated driving system of all aspects of the dynamic driving task, even if a human driver does not respond appropriately to a request to intervene. A Level Five system indicates “full automation”, referring to the full-time performance by an automated driving system of all aspects of the dynamic driving task under all roadway and environmental conditions that can be managed by a human driver.

The vehicle200further includes a propulsion system20, a transmission system22to transmit power from the propulsion system20to vehicle wheels16-18, a steering system24to influence the position of the vehicle wheels16-18, a brake system26to provide braking torque to the vehicle wheels16-18, a sensor system28, an actuator system30, at least one data storage device32, at least one controller34, and a communication system36that is configured to wirelessly communicate information to and from other entities48.

The sensor system28includes one or more sensing devices40a-40nthat sense observable conditions of the exterior environment and/or the interior environment of the autonomous vehicle10. The sensing devices40a-40ncan include but are not limited to, radars, lidars, global positioning systems, optical cameras, thermal cameras, ultrasonic sensors, inertial measurement units, and/or other sensors. The actuator system30includes one or more actuator devices42a-42nthat control one or more vehicle features such as, but not limited to, the propulsion system20, the transmission system22, the steering system24, and the brake system26.

The communication system36is configured to wirelessly communicate information to and from other entities48, such as but not limited to, other vehicles (“V2V” communication,) infrastructure (“V2I” communication), remote systems, and/or personal devices. In an exemplary embodiment, the communication system36is a wireless communication system configured to communicate via a wireless local area network (WLAN) using IEEE 802.11 standards or by using cellular data communication. However, additional or alternate communication methods, such as a dedicated short-range communications (DSRC) channel, are also considered within the scope of the present disclosure. DSRC channels refer to one-way or two-way short-range to medium-range wireless communication channels specifically designed for automotive use and a corresponding set of protocols and standards.

The data storage device32stores data for use in automatically controlling the vehicle200. The data storage device32may be part of the controller34, separate from the controller34, or part of the controller34and part of a separate system. The controller34includes at least one processor44and a computer-readable storage device or media46. Although only one controller34is shown inFIG.2, embodiments of the vehicle200may include any number of controllers34that communicate over any suitable communication medium or a combination of communication mediums and that cooperate to process the sensor signals, perform logic, calculations, methods, and/or algorithms, and generate control signals to automatically control features of the vehicle200.

The processor44can be any custom made or commercially available processor, a central processing unit (CPU), a graphics processing unit (GPU), an auxiliary processor among several processors associated with the controller34, a semiconductor-based microprocessor (in the form of a microchip or chipset), a macro processor, any combination thereof, or generally any device for executing instructions. The computer-readable storage device or media46may include volatile and nonvolatile storage in read-only memory (ROM), random-access memory (RAM), and keep-alive memory (KAM), for example. KAM is a persistent or non-volatile memory that may be used to store various operating variables while the processor44is powered down. The computer-readable storage device or media46may be implemented using any of several known memory devices such as PROMs (programmable read-only memory), EPROMs (electrically PROM), EEPROMs (electrically erasable PROM), flash memory, or any other electric, magnetic, optical, or combination memory devices capable of storing data, some of which represent executable instructions, used by the controller34.

The programming instructions may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. The one or more instructions of the controller34, when executed by the processor44, may configure the vehicle200to receive and accept requests from a remote cloud ODA server, process instructions, provide various decision-making responses, monitor for broadcast messages associated with a virtually made vehicle leader or follower configuration, and provide status information for an ODA service.

The ODA system100can allow a host vehicle106that may have various levels of autonomous driving capabilities to follow a lead vehicle104, such as a Robo Taxi, that may have various levels of autonomous driving capabilities from one destination to another. The occupants of the host vehicle106may include a human driver who operates the host vehicle106during certain portions of a trip. Similarly, the lead vehicle104may include a human driver who operates the lead vehicle104doing certain portions of a trip.

In one example operating scenario, a platoon of vehicles consisting of one Lv configured to guide one or more Fvs from one point to another may be formed. In this operating scenario the ODA server102may select one or more Fvs106and command the Fvs106to follow a selected one of multiple Lvs104in a vehicle platoon for navigation, guidance, and instruction for dropping off one or more of the Fvs106at various designated points. The ODA server102may perform operations to initiate a trip and cause a virtual coupling between the Lv and Fv.

The ODA server102may use a decision-making intelligent algorithm to elect a leader for a leg of a trip, which consists of a Robo Taxi. The ODA server102may select a leader based on multiple inputs that may include the current state of the vehicle, route of the vehicle, weather, passenger preference, follower pick-up/drop-off locations, and history, etc. The ODA server102identifies a rendezvous and communicates trip details to the host vehicle and leader vehicle to execute a trip.

In one example operating scenario, a driver of a vehicle may request assistance to a location without requiring the driver to perform driver operations. In another example operating scenario, the driver of the vehicle may desire a more autonomous driving experience and may be willing to relinquish vehicle control for a route segment or entire route to an Lv. In either example scenario, the vehicle may be configured with Level 2 plus capabilities that provide limited autonomous vehicle operations yet have communication capabilities to make requests for an on-demand service and to enable a virtual link with an Lv where the Lv can be given sufficient operational control via the virtual link to virtually tow the vehicle to a desired location without the driver of the vehicle having to operate the vehicle.

In these example scenarios, an Fv can be virtually towed in a platoon configuration with an Lv thereby enabling an autonomous driving experience (e.g., a level 4 or 5 autonomous driving experience) without the Fv being configured or having level 4 or 5 autonomous driving capabilities. That is, by creating a virtual link between the Lv and Fv, the Fv can operate in a semi or nearly autonomous manner by reliance on the control operations provided by the Lv. By relying on the Lv for control and navigation to the requested location, the Fv can simulate an autonomous driving experience without being configured with the necessary software, hardware, and control system for level 4 or 5 autonomous driving capabilities.

Various conditions may arise that may necessitate changes be made to a platooning trip, after the platooning tip has been initiated. The example ODAS102is configured to handle the conditions that can cause a modification to a platooning trip, after the platooning trip has been initiated.

FIG.3is a diagram of an example timing chart illustrating example interactions over time301between an ODA server302, a host vehicle or Fv, and a Robo Taxi or Lv resulting from a requested change by an occupant of the Fv after the beginning303of a platooning trip. In this example, an occupant of the Fv sends a trip modification or termination request to the ODAS302(operation304) via a host ride assistant306. The host ride assistant306may be embodied in a vehicle human machine interface (HMI)308in the host vehicle (e.g., an infotainment system in a host vehicle) or a mobile app310on a user device.

The ODAS302broadcasts the information content of the request to current and future trip leaders (Lvs) for the platooning trip (operation312) notifying them of the requested trip modification. The Lvs acknowledge and accept the request (operation314). The trip modification may then be implemented. The Lvs may acknowledge the request via Robo Taxi ride assistant316in the case of an Lv containing a human driver or occupant or may acknowledge the request via a built in ODS system module in the case of a human less vehicle. The Robo Taxi ride assistant316may be embodied in a vehicle human machine interface (HMI)318in the Robo Taxi vehicle (e.g., an infotainment system in a Robo Taxi vehicle) or a mobile app320on a user device.

When the request is for a trip modification in which the current Robo Taxi will no longer function as a leader vehicle, the ODAS302will elect a new leader and compute new rendezvous points, if necessary (operation322). The ODAS302will subsequently communicate revised coupling/decoupling information to the host vehicle (operation324) and to the Robo Taxi (operation326). When the request is for trip cancelation or a modification in which the current Robo Taxi will no longer function as a leader vehicle, the subsequent communication will include decoupling instructions for the Fv and current Lv and coupling instructions for the Fv and a new Lv. When the request is for a trip cancelation and not a modification, the ODAS302will subsequently communicate revised decoupling information to the host vehicle (operation324) and to the Robo Taxi (operation326).

After receipt of the subsequent communication, the host vehicle will transmit an acknowledgment accepting or rejecting the coupling/decoupling instructions in the subsequent communication (operation328), and the newly elected Robo Taxi will transmit an acknowledgment accepting or rejecting the coupling/decoupling instructions in the subsequent communication (operation330). The ODAS302will monitor the trip if the host vehicle and newly elected Robo Taxi accept the coupling instructions or terminate the trip if the host vehicle and newly elected Robo Taxi reject the coupling instructions (operation332).

FIG.3provides an example wherein an occupant in the host vehicle requests a trip modification or termination. There may also be instances wherein the current Robo Taxi requests that its participation in the trip be terminated.

FIG.4depicts an example timing chart that illustrates example interactions over time401between an ODA server402, a host vehicle or Fv, and a Robo Taxi or Lv resulting from a requested change by an occupant of the Fv after the beginning403of a platooning trip. In this example, an occupant of the Lv or the Lv sends a trip termination request to the ODAS402(operation404). The occupant may send the request via a Robo Taxi ride assistant406. The Robo Taxi ride assistant406may be embodied in a vehicle human machine interface (HMI)408in the Lv (e.g., an infotainment system in a Lv) or a mobile app410on a user device.

The ODAS402broadcasts the information content of the termination request to the Fv for the platooning trip (operation412) notifying it of the requested termination request. The Fv acknowledges and accepts the termination request (operation414). The Fv may acknowledge the request via host ride assistant406or may acknowledge the request via a built in ODS system module in the Fv. The host ride assistant406may be embodied in a vehicle human machine interface (HMI)408in the Robo Taxi vehicle (e.g., an infotainment system in a Robo Taxi vehicle) or a mobile app410on a user device. Also, shown is a Robo Taxi ride assistant416, which may be embodied in a vehicle human machine interface (HMI)418in the Robo Taxi vehicle (e.g., an infotainment system in a Robo Taxi vehicle) or a mobile app420on a user device

The ODAS402will elect a new leader and compute new rendezvous points, if necessary (operation422). The ODAS402will subsequently communicate revised coupling/decoupling information to the host vehicle (operation424) and to the current Robo Taxi and newly elected Robo Taxi (operation426). The subsequent communication will include decoupling instructions for the Fv and current Lv and coupling instructions for the Fv and a new Lv.

After receipt of the subsequent communication, the host vehicle will transmit an acknowledgment accepting or rejecting the coupling/decoupling instructions in the subsequent communication (operation428), and the newly elected Robo Taxi will transmit an acknowledgment accepting or rejecting the coupling/decoupling instructions in the subsequent communication (operation430). The ODAS402will monitor the trip if the host vehicle and newly elected Robo Taxi accept the coupling instructions or terminate the trip if the host vehicle and newly elected Robo Taxi reject the coupling instructions (operation432).

FIG.5depicts an example timing chart that illustrates example interactions over time501between an ODA server502, a host vehicle or Fv, and a Robo Taxi or Lv resulting from various vehicle status alert messages after the beginning503of a platooning trip. During a platooning trip both the host vehicle and the Robo Taxi communicate their status to the server502.

The host vehicle provides a periodic heartbeat message n (operation504) to report its status, and the Robo Taxi provides a periodic heartbeat message n (operation506) to report its status. The server502analyzes the periodic heartbeat messages from the host vehicle and the Robo Taxi to determine whether a fault condition exists with the host vehicle or the Robo Taxi. When the server502detects a fault condition, the server502diagnoses the default type, such as a transient coupling interference, and selects a feedback mechanism for alerting the host vehicle and the Robo Taxi regarding the detected fault type (operation508). The feedback mechanism may be a text alert, voice alert, or a non-verbal alert such as a haptic alert.

In this example, the server502provides an alert (e.g., text, voice, and/or non-verbal cue) to the host vehicle (operation510) notifying the host vehicle of the diagnosed default type and provides an alert (e.g., text, voice, and/or non-verbal cue) to the Robo Taxi (operation512) notifying the Robo Taxi of the diagnosed default type. When the fault type is an emergency fault type, the server, in this example, provides a nonverbal cue, such as a haptic cue, to the host vehicle and to the Robo Taxi.

Responsive to receiving the alert, the host vehicle provides an acknowledgment heartbeat message n+1 (operation514). Also, responsive to receiving the alert, the Robo Taxi provides an acknowledgment heartbeat message n+1 (operation516). These operations are examples of platoon fault handling operations518performed by the ODA server502, the host vehicle, and the Robo Taxi. Thus, the server502can monitor for periodic heartbeat messages from the platoon vehicles; when a periodic heartbeat message is received, compute a first result that indicates whether a fault has occurred with the platoon vehicle that sent the heartbeat message and when a fault has occurred provides a diagnosis of the type of fault that has occurred; and when the type of fault has been diagnosed, provide an alert (e.g., voice, text, haptic) to the platoon vehicles alerting them of the diagnosed type of fault.

The ODA server502, the host vehicle, and the Robo Taxi can also perform communication failure event handling operations520. When a periodic heartbeat message from one of the host vehicle or the Robo Taxi fails to reach the ODA server502, the communication failure event handling operations520are performed.

In this example, the host vehicle sends a periodic heartbeat message n+x to the server operation522. The Robo Taxi, however, fails to provide a periodic heartbeat message n+x to the server (operation524). In response, the server502sends an alert to the host vehicle (operation526) notifying the host vehicle of the missed periodic heartbeat message from the Robo Taxi, and sends a query to the Robo Taxi regarding the health of the Robo Taxi and the coupling health status of the Robo Taxi (operation528). The Robo Taxi responds with an acknowledgement heartbeat message (operation530) from which the server502can determine the status of the Robo Taxi. The server502can then send an alert (e.g., text and/or voice) providing a status update regarding the host vehicle health status and regarding the coupling health status (operation532).

Thus, the server502can monitor for periodic heartbeat messages from the platoon vehicles. When a periodic heartbeat message is not received from one of the plurality of platoon vehicles, the server requests vehicle health status and virtual coupling health status for the platoon vehicle from which the periodic heartbeat message was not received; sends an alert (text/voice/haptic) to the other of the plurality of platoon vehicles that provides notification that the periodic heartbeat message was not received; and when a responsive message is received in response to the request for health status, the server alerts (text/voice) the other of the plurality of platoon vehicles with status information for the platoon vehicle from which the periodic heartbeat message was not received.

FIG.6depicts an example timing chart that illustrates example interactions over time601between an ODA server602, a host vehicle or Fv, and a Robo Taxi or Lv resulting from the occurrence of an occupant safety event after the beginning603of a platooning trip. In this example, an in-vehicle occupant or remote user sends a safety alert message to the server602(operation604) via a host ride assistant606, such as via an in-vehicle infotainment system608or a user application610from a user device. Alternatively, the host vehicle could sense a safety condition and send a safety alert message to the server602. For example, the host vehicle may leverage in-vehicle monitoring (e.g., cabin camera) to identify a safety condition.

Responsive to receiving the safety alert message, the server502sends a responsive message to the entity (e.g., host ride assistant606or host vehicle) that sent the safety alert message seeking further information (operation612). The host vehicle may leverage in-vehicle communication systems to display the request for further information. The entity that sent the safety alert message can respond by sending a detailed description of the safety condition that necessitated the need to send the safety alert message (operation614).

Responsive to receiving the detailed description, the server602determines and executes an appropriate safety response616. The safety response may be to call 911, for example, if the safety condition is a health emergency. Other examples of safety responses include having the host vehicle pull over for a physical inspection and others.

The server602also sends a safety event response alert to the Robo Taxi advising the Robo Taxi of the safety condition that necessitated the need to send the safety alert message (operation618). The safety event response alert may be sent to the Robo Taxi ride assistant620(e.g., the Robo Taxi infotainment system622or a user application624on a user device). Alternatively, the safety event response alert may be sent to the Robo Taxi itself. The Robo Taxi may leverage in-vehicle communication systems to display the safety event response alert. Responsive to receiving the safety event response alert, the entity that received the safety event response alert may send an acknowledgement message to the server (operation626).

The server602also sends an alert regarding the safety response to the host vehicle and/or host ride assistant (operation628). The alert may be in the form of a text alert and/or a voice alert. The host vehicle may leverage in-vehicle communication systems to display the alert. The entity receiving the alert regarding the safety response sends an acknowledgement to the server602(operation630).

Thus, the server602can monitor for a safety alert message regarding a platoon vehicle. When a safety alert message is received, the server requests further information regarding the safety condition necessitating the safety alert message. When detailed information further information regarding the safety condition necessitating the safety alert message is received by the server602, the server602calculates a safety event response, causes the safety event response to occur, and sends an event response alert to the leader vehicle which may include signaling the leader vehicle to adjust driving accordingly (e.g., operate conservatively or to pull over). The server602can monitor for an acknowledgement from the leader vehicle, broadcast an alert (e.g., voice/text) to the host vehicle and/or host ride assistant606regarding the safety event response, and monitor for an acknowledgement from the host vehicle.

In the examples ofFIGS.3-6, a Ride Assistant system comprising a host ride assistant and a Robo Taxi ride assistant, was disclosed. In the examples ofFIGS.3-4, the Ride Assistant system allowed for follower or leader initiated ongoing trip interrupts, such as modifications (e.g., pit stop) and terminations, via a mobile application (offboard) or infotainment system (onboard).

Additionally, the host ride assistant can be configured to allow a host vehicle occupant to select leader(s) at the beginning of a trip and rate leader(s) at the end of the trip. Similarly, the Robo Taxi ride assistant may be configured to allow a Robo Taxi occupant to select follower(s) at the beginning of a trip and rate follower(s) at the end of a trip. For example, the Ride Assistant system via the host ride assistant and the Robo Taxi ride assistant can allow occupants to leave a rating based on comfort and safety at the end of the trip. By providing a mechanism for rating leaders and followers, the host ride assistant can be configured to allow an occupant to accept leader(s) based on ratings, and the Robo Taxi ride assistant can be configured to allow an occupant to accept follower(s) based on ratings.

In the examples ofFIGS.3-6, a robust feedback system was disclosed (e.g., using display/haptic/voice/alert sounds) that can be tapped to communicate with users in a requesting host vehicle or leader vehicle at various stages of service provisioning such as initiation, active, hand-off, and termination.

The foregoing outlines features of several embodiments so that those skilled in the art may better understand the aspects of the present disclosure. Those skilled in the art should appreciate that they may readily use the present disclosure as a basis for designing or modifying other processes and structures for carrying out the same purposes and/or achieving the same advantages of the embodiments introduced herein. Those skilled in the art should also realize that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that they may make various changes, substitutions, and alterations herein without departing from the spirit and scope of the present disclosure.