Patent Description:
Autonomous vehicles (AVs) or self-driving vehicles (SDVs) can perform continuous sensor data processing in order to operate through road traffic on public roads in order to match or even surpass human capabilities. AVs and SDVs can be equipped with many kinds of sensors, including stereoscopic cameras, LiDAR, radar, proximity sensors, and the like. However, one disadvantage of such vehicles is during rendezvous events with requesting riders when a primary pick-up location is unavailable, such as in crowded areas or when a specified location is occupied by another vehicle. While being effective in operating through road traffic, AVs and SDVs are not able to provide the various human gestures readily understood by current transportation service users. <CIT> proposes an approach for determining a drop-off location, a pick-up location, or a combination thereof at a certain time period based, at least in part, on user fitness targets, user preferences, or combination thereof. The approach involves determining at least one user location associated with at least one user. The approach also involves determining fitness parameter information associated with the at least one user. The approach further involves causing, at least in part, a calculation of at least one drop-off location, at least one pick-up location, or a combination thereof with respect to the at least one user location base, at least in part, on the fitness parameter information. The approach also involves causing, at least in part, a configuration of at least one vehicle to travel to the at least one drop-off location, at least one pick-up location, or a combination thereof.

<CIT> relates to technology for operating a fleet of autonomous vehicles. A request for a taxi service may be received from a mobile device. The request may include a current location of the mobile device. The request may indicate that the taxi service is to be performed at a current time. An autonomous vehicle may be selected from the fleet of autonomous vehicles to perform the taxi service based in part on an availability of the autonomous vehicle and the proximity between the autonomous vehicle and the current location of the mobile device. Instructions may be provided to the autonomous vehicle to perform the taxi service according to the request. The autonomous vehicle may be configured to provide commands to drive the autonomous vehicle to the current location of the mobile device in order to perform the taxi service.

<CIT>relates to a driver assistance device for a motor vehicle, which comprises a control device. The control device can output control signals to a drive and/or steering device of the motor vehicle, which cause an autonomous parking process of the motor vehicle to be carried out. The control device can also receive commands from a remote control and, after receiving a predetermined interruption command, interrupt an already started parking process of the motor vehicle. The invention further relates to a method for assisting a driver in monitoring an autonomous parking process of a motor vehicle, which is carried out by a control device of a driver assistance device with the output of control signals to a drive and/or steering device of the motor vehicle.

<CIT> relates to a vehicle for manoeuvring a passenger to a destination autonomously. The vehicle includes one or more computing devices and a set of user input buttons for communicating requests to stop the vehicle and to initiate a trip to the destination with the one or more computing devices. The set of user input buttons consisting essentially of a dual-purpose button configured to stop the vehicle. The dual-purpose button has a first purpose for communicating the request to initiate the trip to the destination and a second purpose for communicating a request to pull the vehicle over and stop the vehicle. The vehicle has no steering wheel and no user inputs for the steering, acceleration, and deceleration of the vehicle other than the set of user input buttons.

The disclosure herein is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements, and in which:.

According to a first aspect of the present invention, there is provided a self-driving vehicle as set out in claim <NUM>. According to a second aspect of the present invention, there is provided a computer-implemented method as set out in claim <NUM>. According to a third aspect of the present invention, there is provided a non-transitory computer readable medium as set out in claim <NUM>.

A self-driving car (SDV) is disclosed that can optimize pick-ups with requesting users. The SDV can communicate with a backend transport facilitation system that manages a transportation arrangement service for users throughout a given region. The transport facilitation system can comprise a number of backend datacenters that can provide users with a designated application that can enable users to submit pick-up requests on their mobile devices. The transport facilitation system may then utilize a pick-up location or area in the pick-up request, identify a number of vehicles (human-driven vehicles or SDVs) proximate to the pick-up area, and select a vehicle or transmit an invitation to a vehicle to service the pick-up request. Thereafter, the selected vehicle or invited driver can accept the request and drive to the pick-up area to rendezvous with the requesting user.

Over time, the transport facilitation system can gather pick-up data indicating successes and troubles in picking up users in certain areas. For example, the transport facilitation system can track vehicle locations dynamically and identify failed pick-ups or situations in which the rendezvous takes an abnormally long time or when vehicles must perform loop around actions to perfect the pick-up. Such failed or problematic pick-ups can be identified by the transport facilitation system and attributed to one or more causes, such as the requesting user being late or pre-occupied, the crowded nature of the pick-up area, traffic, and/or lack of defined pick-up locations at the pick-up area. Conversely, the transport facilitation system can analyze pick-up data for such problematic areas that indicate relative success and low pick-up times. The transport facilitation system can utilize such data to identify specified pick-up location options for each pick-up area indicated in a pick-up request.

As provided herein, a "pick-up location option" or a "set of pick-up location options" can comprise one or more specific pick-up locations (e.g., a set of parking spaces, a proximate street corner, a pull-off area, a shopping area, a wide-shouldered road segment, etc.) for a particular "pick-up area" indicated in a pick-up request. In many examples, the requesting user can set a location pin on a particular location on a mapping resource, generated by a designated application on the user's mobile computing device, to indicate a desired pick-up location. When receiving "a pick-up location" from the requesting user, the transport facilitation system and/or the selected SDV itself can expand the inputted location to a "pick-up area" (e.g., a radius of twenty or forty meters for the inputted location pin) in order to generate a set of pick-up location options for an SDV selected to service the pick-up request. As described herein, such pick-up location options can be determined by the transport facilitation system over time by analyzing historical pick-up data.

According to examples provided herein, when the SDV approaches the pick-up area, the SDV may utilize real-time sensor data from on-board sensors (e.g., LiDAR, radar, stereoscopic cameras, etc.) to perform a hierarchical operation (e.g., an algorithmic pick-up location selection operation that includes cost probability calculations for each detected or encountered pick-up location option) to converge on an optimal pick-up location to rendezvous with the requesting user. In certain implementations, the selected SDV can leverage the previously determined pick-up location options for the pick-up location area, rank the options based on a set of criteria (e.g., proximity to the inputted location pin, average pick-up delta for the option, current traffic conditions, option encounter order), and utilize the sensor data as the SDV approaches the pick-up area to determine an availability of the options.

For example, as the SDV approaches the pick-up area, the SDV can make the availability determinations based on encounter time (e.g., first encountered options first) and calculate a probability of whether a higher ranked available option will be encountered in relation to a current option. Thus, if an available low ranked option is encountered first, in certain conditions the SDV may disregard the option and hold out for a higher ranked available option. Such a hierarchical selection process can be performed by the SDV as a number of cost probability calculations with primary concerns corresponding to a successful pick-up on the first attempt, time delta between the SDV stopping and the user entering the SDV (e.g., walking time), distance between the location option and the inputted pick-up location or actual location of the requesting user, and potential hindrance on traffic.

Communications between the SDV and the requesting user can be initiated by the SDV or the requesting user at any time. Such communications can be relayed through the transport facilitation system, or can be transmitted between the SDV and the requesting user's mobile computing device directly (e.g., using cellular data channels or via direct connection such as Bluetooth, Wi-Fi, or WiGig). In some examples, the transport facilitation system can transmit identifying information of the user's mobile computing device to the SDV, such as the user's phone number, or an on-application unique identifier. The SDV can utilize such information to communicate, for example, a confirmation corresponding to an optimal pick-up location (e.g., when the SDV arrives at the pick-up area), a set of options for the user to choose, a query to the user when options are unavailable, instructions for the user to meet the SDV at an alternate location, status reports, and the like. Furthermore, certain communications can be initiated in accordance with the hierarchical operation performed by the SDV, and can be triggered by certain instances, such as when none of the ranked options are available.

Among other benefits, the examples described herein achieve a technical effect of maximizing pick-up efficiency between a requesting user and an SDV selected to provide transport for the requesting user. The SDV can expand an inputted pick-up location into a pick-up area that includes a number of pick-up location options previously determined to achieve a relative rate of success and seamlessness. In many implementations, the SDV can determine a ranking for the options, and as the SDV approaches the pick-up area, run a hierarchical selection operation to converge on an optimal location to rendezvous with the requesting user.

As used herein, a computing device refers to devices corresponding to desktop computers, cellular devices or smartphones, personal digital assistants (PDAs), laptop computers, tablet devices, virtual reality (VR) and/or augmented reality (AR) devices, wearable computing devices, television (IP Television), etc., that can provide network connectivity and processing resources for communicating with the system over a network. A computing device can also correspond to custom hardware, in-vehicle devices, or on-board computers, etc. The computing device can also operate a designated application configured to communicate with the network service.

One or more examples described herein provide that methods, techniques, and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically, as used herein, means through the use of code or computer-executable instructions. These instructions can be stored in one or more memory resources of the computing device. A programmatically performed step may or may not be automatic.

One or more examples described herein can be implemented using programmatic modules, engines, or components. A programmatic module, engine, or component can include a program, a sub-routine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions. As used herein, a module or component can exist on a hardware component independently of other modules or components. Alternatively, a module or component can be a shared element or process of other modules, programs or machines.

Some examples described herein can generally require the use of computing devices, including processing and memory resources. For example, one or more examples described herein may be implemented, in whole or in part, on computing devices such as servers, desktop computers, cellular or smartphones, personal digital assistants (e.g., PDAs), laptop computers, network equipment (e.g., routers), and tablet devices. Memory, processing, and network resources may all be used in connection with the establishment, use, or performance of any example described herein (including with the performance of any method or with the implementation of any system).

Furthermore, one or more examples described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium. Machines shown or described with figures below provide examples of processing resources and computer-readable mediums on which instructions for implementing examples disclosed herein can be carried and/or executed. In particular, the numerous machines shown with examples of the invention include processors and various forms of memory for holding data and instructions. Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers. Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash memory (such as carried on smartphones, multifunctional devices or tablets), and magnetic memory. Computers, terminals, network enabled devices (e.g., mobile devices, such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable mediums. Additionally, examples may be implemented in the form of computer-programs, or a computer usable carrier medium capable of carrying such a program.

Numerous examples are referenced herein in context of a self-driving vehicle (SDV) or an autonomous vehicle (AV). A SDV or AV refers to any vehicle which is operated in a state of automation with respect to steering and propulsion. Different levels of autonomy may exist with respect to AVs, however, it is generally accepted that a fully autonomous vehicle is referred to as an SDV, and can operate without any human intervention.

<FIG> is a block diagram illustrating an example self-driving vehicle (SDV) implementing a control system, as described herein. In an example of <FIG>, a control system <NUM> can autonomously operate the SDV <NUM> in a given geographic region for a variety of purposes, including transport services (e.g., transport of humans, delivery services, etc.). In examples described, self-driving vehicle can operate without human control. For example, in the context of automobiles, an SDV <NUM> can autonomously steer, accelerate, shift, brake, and operate lighting components without human intervention. Some variations also recognize that an SDV <NUM> can be operated either autonomously in a fully autonomous mode, or may be switched to a manual mode in which a human driver may take at least partial control.

In many examples, the SDV <NUM> can include a wireless communication interface or communications array <NUM> to communicate with a backend, transport facilitation system <NUM>. As provided herein, the transport facilitation system <NUM> can comprise one or more backend servers (e.g., a regional datacenter) that provide a transportation arrangement service to connect requesting users—via an executing rider application on the users' mobile devices-with available drivers or SDVs. Thus, the transport facilitation system can manage the transportation arrangement service for a given region in which the SDV <NUM> operates. In doing so, the transport facilitation system <NUM> can connect users with SDVs and/or human driven vehicles for transportation purposes in an on-demand basis. Specifically, the transport facilitation system <NUM> can provide a designated application <NUM> to be executed on the user devices <NUM> (e.g., mobile computing devices), which can enable the user to submit a pick-up request <NUM> to the transport facilitation system <NUM> over one or more networks <NUM>. The transport facilitation system <NUM> can utilize location data <NUM> from various SDVs and human-driven vehicles throughout the given region, and select a vehicle proximate to the requesting user's current or inputted location to service the pick-up request <NUM>. In the example provided, the transport facilitation system <NUM> selects SDV <NUM> to service the pick-up request <NUM> based at least in part on the proximity between the SDV <NUM> and the pick-up location indicated in the pick-up request <NUM>.

Based on the selection, the transport facilitation system <NUM> can generate and transmit a transport directive <NUM> to the SDV <NUM> to service the pick-up request <NUM>. The transport directive <NUM> can be received by the communications array <NUM> and can be transmitted to the control system <NUM> of the SDV <NUM>. In one example, the transport directive <NUM> can comprise a an instruction to the control system <NUM> to operate the SDV <NUM> to autonomously drive to the pick-up location area in order to rendezvous with the requesting user. In other implementations, the transport directive <NUM> can comprise an invitation, which control system <NUM> can first accept or deny prior to committing to the pick-up request <NUM>.

In one implementation, the control system <NUM> can utilize specific sensor resources in order to intelligently operate the vehicle <NUM> in most common driving situations. For example, the control system <NUM> can operate the vehicle <NUM> by autonomously steering, accelerating, and braking the vehicle <NUM> as the vehicle progresses to a destination. The control system <NUM> can perform vehicle control actions (e.g., braking, steering, accelerating) and route planning using sensor information, as well as other inputs (e.g., transmissions from remote or local human operators, network communication from other vehicles, etc.).

In an example of <FIG>, the control system <NUM> includes a computer or processing system which operates to process sensor data that is obtained on the vehicle <NUM> with respect to a road segment upon which the vehicle <NUM> operates. The sensor data can be used to determine actions which are to be performed by the vehicle <NUM> in order for the vehicle <NUM> to continue on a route to a destination. In some variations, the control system <NUM> can include other functionality, such as wireless communication capabilities, to send and/or receive wireless communications with one or more remote sources. In controlling the vehicle <NUM>, the control system <NUM> can issue instructions and data, shown as commands <NUM>, which programmatically control various electromechanical interfaces of the vehicle <NUM>. The commands <NUM> can serve to control operational aspects of the vehicle <NUM>, including propulsion, braking, steering, and auxiliary behavior (e.g., turning lights on).

The SDV <NUM> can be equipped with multiple types of sensors <NUM>, <NUM> which can combine to provide a computerized perception of the space and environment surrounding the vehicle <NUM>. Thus, the control system <NUM> can continuously assess a situational environment of the SDV <NUM> when operating the acceleration, braking, and steering systems through road and pedestrian traffic on public roads and highways. Likewise, the control system <NUM> can operate within the SDV <NUM> to receive sensor data <NUM> from the collection of sensors <NUM>, <NUM>, and to control various electromechanical interfaces for operating the vehicle <NUM> on roadways.

In more detail, the sensors <NUM>, <NUM> operate to collectively obtain a complete sensor view of the vehicle <NUM>, and further to obtain situational information proximate to the vehicle <NUM>, including any potential hazards proximate to the vehicle <NUM>. By way of example, the sensors <NUM>, <NUM> can include multiple sets of camera sensors <NUM> (video cameras, stereoscopic pairs of cameras or depth perception cameras, long range cameras), remote detection sensors <NUM> such as provided by radar or LIDAR, proximity or touch sensors, and/or proximity or sonar sensors (not shown).

Each of the sensors <NUM>, <NUM> can communicate with the control system <NUM> utilizing a corresponding sensor interface <NUM>, <NUM>. Each of the sensor interfaces <NUM>, <NUM> can include, for example, hardware and/or other logical components which are coupled or otherwise provided with the respective sensor. For example, the sensors <NUM>, <NUM> can include a video camera and/or stereoscopic camera set which continually generates image data of an environment of the vehicle <NUM>. As an addition or alternative, the sensor interfaces <NUM>, <NUM> can include a dedicated processing resource, such as provided with a field programmable gate array ("FPGA") which can, for example, receive and/or process raw image data from the camera sensor.

In some examples, the sensor interfaces <NUM>, <NUM> can include logic, such as provided with hardware and/or programming, to process sensor data <NUM> from a respective sensor <NUM>, <NUM>. The processed sensor data <NUM> can be outputted as sensor data <NUM>. As an addition or variation, the control system <NUM> can also include logic for processing raw or preprocessed sensor data <NUM>.

According to one implementation, the vehicle interface subsystem <NUM> can include or control multiple interfaces to control mechanisms of the vehicle <NUM>. The vehicle interface subsystem <NUM> can include a propulsion interface <NUM> to electrically (or through programming) control a propulsion component (e.g., an accelerator actuator), a steering interface <NUM> for a steering mechanism, a braking interface <NUM> for a braking component, and a lighting/auxiliary interface <NUM> for exterior lights of the vehicle <NUM>. The vehicle interface subsystem <NUM> and/or the control system <NUM> can further include one or more controllers <NUM> which can receive commands <NUM> from the control system <NUM>. The commands <NUM> can include route information <NUM> and operational parameters <NUM>-which specify an operational state of the vehicle <NUM> (e.g., desired speed and pose, acceleration, etc.).

The controller(s) <NUM> can generate control signals <NUM> in response to receiving the commands <NUM> for one or more of the vehicle interfaces <NUM>, <NUM>, <NUM>, <NUM>. The controllers <NUM> can use the commands <NUM> as input to control propulsion, steering, braking, and/or other vehicle behavior while the SDV <NUM> follows a current route. Thus, while the SDV <NUM> actively drives along the current route, the controller(s) <NUM> can continuously adjust and alter the movement of the vehicle <NUM> in response to receiving a corresponding set of commands <NUM> from the control system <NUM>. Absent events or conditions which affect the confidence of the SDV <NUM> in safely progressing along the route, the control system <NUM> can generate additional commands <NUM> from which the controller(s) <NUM> can generate various vehicle control signals <NUM> for the different interfaces of the vehicle interface subsystem <NUM>.

In various implementations, the control system <NUM> can include a database <NUM> that stores operational sub-maps <NUM> for the given region. These sub-maps <NUM> can comprise previous recorded, analyzed, and processed sensor maps of the given region. For example, the sub-maps <NUM> can include surface maps (e.g., LiDAR and/or stereoscopic camera-based maps) to which the control system <NUM> can continuously compare with the real-time sensor data <NUM>. In some aspects, each sub-map can represent a road segment of the given region from a particular direction, and can include processed sensor data that indicates all, or nearly all, static objects and features that the SDV <NUM> can expect to encounter on that particular road segment (e.g., lanes, traffic signals, signs, telephone poles, overpasses, parking meters, parking areas or locations, buildings, houses, trees, structures, background features, and the like). Accordingly, the control system <NUM> can dynamically analyze the real-time sensor data <NUM> from the sensors <NUM>, <NUM> of the SDV <NUM> in view of a current sub-map <NUM> in order to dynamically determine its location and orientation within the given region, and detect and resolve any potential hazards to maneuver the SDV <NUM> and avoid such hazards if necessary.

According to examples, the commands <NUM> can specify actions to be performed by the vehicle <NUM>. The actions can correlate to one or multiple vehicle control mechanisms (e.g., steering mechanism, brakes, etc.). The commands <NUM> can specify the actions, along with attributes such as magnitude, duration, directionality, or other operational characteristics of the SDV <NUM>. By way of example, the commands <NUM> generated from the control system <NUM> can specify a relative location of a road segment which the SDV <NUM> is to occupy while in motion (e.g., change lanes, move into a center divider or towards the shoulder, perform a turn, etc.). As other examples, the commands <NUM> can specify a speed, a change in acceleration (or deceleration) from braking or accelerating, a turning action, or a state change of exterior lighting or other components. The controllers <NUM> can translate the commands <NUM> into control signals <NUM> for a corresponding interface of the vehicle interface subsystem <NUM>. The control signals <NUM> can take the form of electrical signals which correlate to the specified vehicle action by virtue of electrical characteristics that have attributes for magnitude, duration, frequency or pulse, or other electrical characteristics.

In an example of <FIG>, the control system <NUM> can include a route planner <NUM>, event logic <NUM>, and a vehicle control <NUM>. The vehicle control <NUM> represents logic that converts alerts of event logic <NUM> ("event alert <NUM>") into commands <NUM> that specify a set of vehicle actions. According to examples described herein, the control system <NUM> can further include rendezvous logic <NUM> that can facilitate in the SDV <NUM> successfully and seamlessly making pickups.

In example implementations, the route planner <NUM> can select one or more route segments <NUM> that collectively form a path of travel for the SDV <NUM> when the vehicle <NUM> is on a current trip (e.g., servicing a pick-up request). In one implementation, the route planner <NUM> can specify route segments <NUM> of a planned vehicle path which defines turn by turn directions for the vehicle <NUM> at any given time during the trip. The route planner <NUM> may utilize the sensor interface <NUM> to receive GPS information as sensor data <NUM>. The vehicle control <NUM> can process route updates from the route planner <NUM> as commands <NUM> to progress along a path or route using default driving rules and actions (e.g., moderate steering and speed).

In certain implementations, the event logic <NUM> can trigger a response to a detected event. A detected event can correspond to a roadway condition or obstacle which, when detected, poses a potential hazard or threat of collision to the vehicle <NUM>. By way of example, a detected event can include an object in the road segment, heavy traffic ahead, and/or wetness or other environmental conditions on the road segment. The event logic <NUM> can use sensor data <NUM> from cameras, LIDAR, radar, sonar, or various other image or sensor component sets in order to detect the presence of such events as described. For example, the event logic <NUM> can detect potholes, debris, objects projected to be on a collision trajectory, and the like. Thus, the event logic <NUM> can detect events which enable the control system <NUM> to make evasive actions or plan for any potential hazards.

In certain implementations, the event logic <NUM> can dynamically compare the sensor data <NUM> with current sub-maps <NUM> as the SDV <NUM> travels throughout the given region. In some aspects, as the SDV <NUM> crosses into a subsequent road segment, the event logic <NUM> can access a new current sub-map <NUM> from the database <NUM> in order to continuously process the sensor data <NUM>.

When events are detected, the event logic <NUM> can signal an event alert <NUM> that classifies the event and indicates the type of avoidance action to be performed. Additionally, the control system <NUM> can determine whether an event corresponds to a potential incident with a human driven vehicle, a pedestrian, or other human entity external to the SDV <NUM>. In turn, the vehicle control <NUM> can determine a response based on a score or classification of the event. Such response can correspond to an event avoidance action <NUM>, or an action that the vehicle <NUM> can perform to maneuver the vehicle <NUM> based on the detected event and its score or classification. By way of example, the vehicle response can include a slight or sharp vehicle maneuvering for avoidance using a steering control mechanism and/or braking component. The event avoidance action <NUM> can be signaled through the commands <NUM> for controllers <NUM> of the vehicle interface subsystem <NUM>.

When an anticipated dynamic object of a particular class does in fact move into position of likely collision or interference, some examples provide that event logic <NUM> can signal the event alert <NUM> to cause the vehicle control <NUM> to generate commands <NUM> that correspond to an event avoidance action <NUM>. For example, in the event of a bicycle crash in which the bicycle (or bicyclist) falls into the path of the vehicle <NUM>, the event logic <NUM> can signal the event alert <NUM> to avoid the collision. The event alert <NUM> can indicate (i) a classification of the event (e.g., "serious" and/or "immediate"), (ii) information about the event, such as the type of object that generated the event alert <NUM>, and/or information indicating a type of action the vehicle <NUM> should take (e.g., location of object relative to path of vehicle, size or type of object, etc.).

According to examples described herein, SDV <NUM> can include a communications array <NUM> to communicate over one or more networks <NUM> with a backend, transport facilitation system <NUM>, such as the transport facilitation system <NUM> described with respect to <FIG>. In some aspects, when the SDV <NUM> is selected to service a pick-up request, the communications array <NUM> can receive a transport directive <NUM> from the transport facilitation system <NUM> to service the pick-up request and drive to a pick-up location to rendezvous with the requesting user. In such aspects, the transport directive <NUM> can be transmitted to the route planner <NUM> in order to autonomously drive the SDV <NUM> to the pick-up location area.

In various implementations, the control system <NUM> can expand the pick-up location into a pick-up area with a certain radius (e.g., forty meters) from the inputted pick-up location by the requesting user. Furthermore, the database <NUM> of the SDV <NUM> can store pick-up and drop-off location sets <NUM> (PDOLS <NUM>) for specified location areas. The PDOLS <NUM> can be determined by the transport facilitation system <NUM> over time by collecting and analyzing pick-up data <NUM> (and/or drop off data) from any number of AVs, SDVs, or human-driven vehicles to identify specific optimal locations on a fine granular level. Thus, if a requesting user inputs a pick-up location into a pick-up request <NUM>-which may be indicated in the transport directive <NUM>-the rendezvous logic <NUM> can expand the pick-up location into a pick-up area, and perform a lookup in the PDOLS <NUM> to identify a set of pick-up location options, or an options set <NUM>, to rendezvous with the requesting user. In some examples, the rendezvous logic <NUM> can treat the inputted pick-up location as a reference point (e.g., a radial center) for a pick-up area that encompasses one or multiple specific location options determined to have high success rates and low pick-up times.

In variations, the PDOLS <NUM> can be stored at the transport facilitation system <NUM> and accessed by the control system <NUM> via the network(s) <NUM>. Additionally, in some examples, the transport facilitation system <NUM> can receive the pick-up request <NUM>, identify the pick-up location, expand the pick-up location into a pick-up area, and determine a set of one or more pick-up location options within the pick-up area. Thus, in such implementations, the transport directive <NUM>, or subsequent transmission, can include data indicating the set of pick-up location options <NUM> corresponding to the pick-up area.

Whether determined by the transport facilitation system <NUM> or the SDV <NUM>, the rendezvous logic <NUM> can utilize the options set <NUM> as the SDV <NUM> approaches the pick-up area to determine an optimal pick-up location to rendezvous with the requesting user. In one example, the options set <NUM> can comprise a ranked set of location options according to such factors as average success rate (e.g., a rate in which the initial pick-up attempt was successful), an average pick-up time (e.g., the time between the vehicle stopping and pulling away), and can factor in distances between the inputted pick-up location by the requesting user and the actual pick-up location, any obstacles or hindrances between them (e.g., a road or intersection), and the like. In certain examples, the SDV <NUM> ranks the options set <NUM> based, at least in part, on (i) the historical data from the transport facilitation system <NUM> (e.g., success rates and/or pick-up deltas for each option), and (ii) the inputted location by the requesting user. Utilizing this ranking, the control system <NUM> can perform the hierarchical selection operation as the SDV <NUM> approaches the pick-up area and begins to detect the pick-up location options in the options set <NUM>.

Thus, as the control system <NUM> operates the acceleration, braking, and steering systems of the SDV <NUM> along the current route to within a certain distance from the pick-up area, the control system can trigger the rendezvous logic <NUM> to begin analyzing the sensor data <NUM> based on the options set <NUM>. In one example, the SDV <NUM> utilizes the determined ranking of the options set <NUM> and performs the selection operation by identifying an availability of each of the ranked options as the SDV <NUM> encounters and detects them. In such an example, the rendezvous logic <NUM> can, on a high level, check off each of the encountered pick-up location options in the options set <NUM> in a binary manner (e.g., either available or unavailable).

On a more granular level, when the SDV <NUM> enters the pick-up area, the rendezvous logic <NUM> performs a cost analysis of whether to halt the SDV <NUM> at an encountered available option, or hold out for a higher ranked available option yet to be detected. According to various implementations, an encountered low ranked available option may require the requesting user to walk a certain distance (e.g., twenty or thirty meters), which increases the pick-up delta. For this low-ranked option, the rendezvous logic <NUM> processes the sensor data <NUM> to identify such criteria as traffic conditions, an occupancy factor for proximate stopping areas (e.g., heavily occupied, moderately occupied, or lightly occupied), the number of remaining options in the ranked options set <NUM>, the rankings of such remaining options, the distance to the inputted pick-up location, etc. Based on the criteria, the rendezvous logic <NUM> determines a probability that a future higher-ranked encountered option will be available. Accordingly, if the probability exceeds a certain threshold (e.g., sixty-five percent), then the rendezvous logic <NUM> instructs the vehicle control <NUM> to continue through the pick-up area until the rendezvous logic <NUM> identifies a better available option in the set <NUM>.

According to examples provided herein, the cost analysis may be performed by the rendezvous logic <NUM> for each option in the options set <NUM> as they are encountered, and until the rendezvous logic <NUM> calculates a probability, corresponding to a currently encountered pick-up location option, that does not exceed the threshold. In other words, when the SDV <NUM> approaches a specific pick-up location option in the options set <NUM> in which the probability of a better future option is below the threshold, the rendezvous logic <NUM> can instruct the vehicle control <NUM> to pull over and/or stop at the currently encountered pick-up location option. Thus, when the SDV <NUM> enters the pick-up area, and the sensors <NUM>, <NUM> begin detecting the pick-up location options, the rendezvous logic <NUM> can dynamically identify availability of encountered options and, if available, can dynamically calculate the probability of encountering a better option without having to perform a loop around action for a second attempt. Accordingly, the rendezvous logic <NUM> can perform this hierarchical selection operation in order to converge on an optimal pick-up location from the options set <NUM>. However, it is contemplated that this optimal location may or may not be the highest ranked, or even the highest ranked available option in the option set <NUM>. For example, the rendezvous logic <NUM> may determine that a currently encountered pick-up location option suffices for the pick-up based on location options that are potentially more optimal, but are further up the road and cannot be detected.

In certain implementations, the rendezvous logic <NUM> can further attempt to identify the requesting user, and take into account the exact location of the requesting user when performing the cost analyses. In one example, the SDV <NUM> can be provided with the user's location from the transport facilitation system <NUM>, which can track the location via GPS resources of the user device. In variations, the rendezvous logic <NUM> can detect the user utilizing various other methods, such as detecting the user holding up a hand in a hailing manner, or the user holding up the user device <NUM>, which can output a certain display feature or pattern. In some aspects, the detected location of the user may not exactly correlate with the inputted pick-up location by the user. For example, the user may input a location that is twenty or thirty meters from where the user is actually located. According to examples, in detecting the user, the rendezvous logic <NUM> can dynamically override the ranking of options and prioritize options closer to the user's actual location. For example, as the rendezvous logic <NUM> dynamically performs the cost analyses for each option (e.g., based, at least in part, on the inputted location by the user), the rendezvous logic <NUM> can detect the requesting user. As the SDV <NUM> continues through the pick-up area, the rendezvous logic <NUM> can override the rankings, and restructure the probability calculations based on the actual location of the user, as opposed to the inputted location. Accordingly, the rendezvous logic <NUM> can alter the factors of the probability calculation, which can be triggered by the detection of the requesting user.

Additionally or alternatively, the rendezvous logic <NUM> can communicate with the requesting user directly over a network <NUM>. In certain implementations, the rendezvous logic <NUM> can be partially dependent on the requesting user in performing the pick-up. For example, as the SDV <NUM> approaches the pick-up area, the rendezvous logic <NUM> can transmit a direct communication <NUM> to the user device <NUM> of the requesting user. In some examples, this direct communication <NUM> can query the user of whether an available pick-up location is proximate to the user (e.g., within ten meters). If the user answers in the affirmative, then the rendezvous logic <NUM> can negate the cost calculations and instruct the vehicle control <NUM> to drive to the available location. For example, the user can input a current location on the designated application <NUM>, which can be transmitted to the SDV <NUM>, and utilized by the vehicle control <NUM> to drive to the user. Further, the direct communications <NUM> can provide a confirmation to the user device <NUM> that the SDV <NUM> has found an optimal pick-up location, and can provide details to the user of the location.

In certain examples, the direct communications <NUM> between the SDV <NUM> and the user device <NUM> are relayed through the transport facilitation system <NUM>. In such examples, the SDV <NUM> and the user device <NUM> do not communicate directly, and the user device <NUM> can receive such communications <NUM> over the designated application <NUM>. In variations, the SDV <NUM> can receive identifying information of the user device <NUM> from the transport facilitation system <NUM> (e.g., in the transport directive <NUM>). In such variations, once the SDV <NUM> is within wireless range of the user device <NUM>, the SDV <NUM> can scan for wireless signals or otherwise detect such signals (e.g., a beacon from the user device <NUM>), and establish a direct local connection with the user device <NUM> (e.g., a Bluetooth, Wi-Fi, or WiGig connection). Thereafter, the direct communications <NUM> between the SDV <NUM> and the user device <NUM> can be transmitted over this direct connection.

According to some examples, when the SDV <NUM> approaches the pick-up area, the rendezvous logic <NUM> can provide the user device <NUM> with status updates indicating, for example, that the SDV <NUM> is searching for an optimal pick-up location, or that the SDV <NUM> has identified an optimal pick-up location. Additionally or alternatively, once the rendezvous logic <NUM> identifies an optimal pick-up location, the rendezvous logic <NUM> can transmit a confirmation to the user device <NUM> indicating the location. For example, the confirmation can include a mapping feature identifying the immediate surroundings of the location (e.g., road names, intersections, sidewalks, trees, etc.), and an indicator showing the pick-up location (e.g., an arrow or highlight).

In one variation, the rendezvous logic <NUM> can present the user device <NUM> with a plurality of available options (e.g., on a mapping feature), and the requesting user can select a particular option from the plurality. The rendezvous logic <NUM> can then instruct the vehicle control <NUM> to drive the SDV <NUM> to the selected location.

In certain examples, a particular pick-up location may not have a corresponding pick-up location options set <NUM> in the PDOLS <NUM>. In such examples, the rendezvous logic <NUM> can perform an on-the-fly selection process to determine candidate location options based in part on the inputted location by the user, or the actual location once the requesting user is detected. Other factors in determining an optimal pick-up location without a ranked options set <NUM> can include traffic conditions, overall availability of pick-up areas (e.g., parking spaces), distance to the inputted or actual location of the user, and the like.

In further examples, the rendezvous logic <NUM> can determine that none of the pick-up location options are available. In such examples, the rendezvous logic <NUM> can rely more heavily on direct communications <NUM> with the user, and/or attempt to make the pick-up by utilizing a reserve option. Such reserve options can include double parking, stopping briefly in a yellow or red zone, taking a next turnout (e.g., into a side street or parking lot), etc. The rendezvous logic <NUM> can utilize the reserve options only when all other options are exhausted, or when the rendezvous logic <NUM> fails in a first attempt. Thus, in some examples, the rendezvous logic <NUM> can keep such reserve options locked, and unlock the reserve options based on one or more triggering events. Such triggering events can include the SDV <NUM> passing the inputted or actual location of the requesting user, a failed pick-up attempt and loop around action, detection of no available options, and the like. In certain examples, when reserve options are unlocked, the rendezvous logic <NUM> can transmit an alert to the user device <NUM> to be aware and ready for a quick pick-up.

Once the pick-up is performed, the control system <NUM> can operate the acceleration, braking, and steering systems to autonomously drive the SDV <NUM> to the destination, which can be inputted by the user prior to pick-up or provided to the SDV <NUM> after pick-up. According to some examples, the drop-off of the requesting user can be performed in a similar manner. For example, as the SDV <NUM> approaches a crowded destination area, the control system <NUM> can identify that a drop-off location corresponding to the destination is unavailable. In certain examples, the PDOLS <NUM> in the database <NUM> can include drop-off location options and the control system <NUM> can perform a similar hierarchical selection operation, described herein, for the drop-off. Thus, in some examples, the control system <NUM> can rank the drop-off location options set <NUM> (e.g., based on a specified drop-off location in the transport directive <NUM>), and perform the hierarchical selection process to, for example, converge on an optimal drop-off location, as described similarly herein with respect to the pick-up.

In certain implementations, the control system <NUM> of the SDV <NUM> can enable the user to have at least partial control over the drop-off. For example, during the ride, the control system <NUM> can execute speech recognition to translate the user's spoken words into control commands. The translated commands can cause the control system <NUM> to operate various controllable parameters of the SDV <NUM> itself. For example, the spoken words of the user can be translated to control the climate control system, the audio and/or display system, certain network services (e.g., phoning, conferencing, content access, gaming, etc.), seat adjustment, and the like. According to examples described herein, the control system <NUM> can also operate the acceleration, braking, and steering system of the SDV <NUM> based on certain speech commands from the user. In one aspect, as the SDV <NUM> approaches the destination, the user can ask or otherwise command the SDV <NUM> to stop at its current location. In response to this stop command from the user, the control system <NUM> can perform a quick check of the situational environment to determine a safety factor of a stopping action. If the safety factor is within a certain safety range, or otherwise exceeds a threshold safety level, the control system <NUM> can cause the SDV <NUM> to stop at the current location to make the drop-off. However, if the safety factor does not meet such a minimum threshold, then the control system <NUM> can automatically search for a next available drop-off option in the corresponding drop-off option set, and stop the SDV <NUM> at the next available option to make the drop-off.

<FIG> is a block diagram illustrating an example mobile computing device executing a designated application for a transport arrangement service, as described herein. The mobile computing device <NUM> can store a designated application (e.g., a rider app <NUM>) in a local memory <NUM>. In response to a user input <NUM>, the rider app <NUM> can be executed by a processor <NUM>, which can cause an app interface <NUM> to be generated on a display screen <NUM> of the mobile computing device <NUM>. The app interface <NUM> can enable the user to, for example, check current price levels and availability for the transportation arrangement service. In various implementations, the app interface <NUM> can further enable the user to select from multiple ride services, such as a carpooling service, a regular rider service, a professional rider service, a van transport service, a luxurious ride service, and the like. Example services that may be browsed and requested can be those services provided by UBER Technologies, Inc. of San Francisco, California.

The user can generate a pick-up request <NUM> via user inputs <NUM> provided on the app interface <NUM>. For example, the user can select a pick-up location, view the various service types and estimated pricing, and select a particular service for transportation to an inputted destination. In certain implementations, current location data <NUM> from a GPS module <NUM> of the mobile computing device <NUM> can be transmitted to the transport facilitation system <NUM> over one or more networks <NUM> to set the pick-up location. In many examples, the user can also input the destination prior to pick-up. The processor <NUM> can transmit the pick-up request <NUM> via a communications interface <NUM> to the backend transport facilitation system <NUM> over the network <NUM>. In response, the mobile computing device <NUM> can receive a confirmation <NUM> from the transport facilitation system <NUM> indicating that a selected SDV will service the pick-up request <NUM> and rendezvous with the user at a determined pick-up location.

As the SDV approaches a pick-up area corresponding to the inputted pick-up location, the SDV can perform cost analyses for one or more pick-up location options, as described herein with respect to <FIG>. As further described, as the SDV performs the hierarchical selection process to find an optimal pick-up location, the mobile computing device <NUM> and the SDV control system <NUM> can engage in direct communications <NUM> in order to coordinate the pick-up. In one aspect, the direct communications <NUM> can be included on a rendezvous feature <NUM> displayed on the display screen <NUM> of the mobile computing device <NUM> (e.g., via the rider app <NUM>). In certain implementations, the rendezvous feature <NUM> can enable the user to select a pick-up location option, confirm a selected option, and can provide the user with information corresponding to the optimal pick-up location option. In one aspect, the rendezvous feature <NUM> can provide a map of the user's immediate surroundings, and can include an indicator that identifies the optimal pick-up location on the map. Thus, in examples in which the user must walk a certain distance (e.g., fifteen to twenty meters), the rendezvous feature <NUM> can provide the user with the indicator of the rendezvous location as well as low level walking directions to the location.

<FIG> is a flow chart describing an example method of performing a rendezvous process by a self-driving vehicle (SDV), as described herein. In the below description of <FIG>, reference may be made to reference characters representing like features shown and described with respect to <FIG> and <FIG>. Furthermore, the methods and processes described in connection with <FIG> can be performed by an example SDV control system <NUM>, <NUM> as shown and described with respect to <FIG> and <FIG>. Referring to <FIG>, the control system <NUM> of the SDV <NUM> can receive a transport directive <NUM> from a backend transport facilitation system <NUM> (<NUM>). In some examples, the transport directive <NUM> can include a pick-up location specified by the requesting user (<NUM>). Additionally, the transport directive <NUM> can include an inputted destination by the requesting user (<NUM>).

According to certain examples, the control system <NUM> can expand the pick-up location to a pick-up area in which the pick-up location comprises a reference point (<NUM>). For example, the control system <NUM> can generate the pick-up area to include a certain number of pick-up location options previously determined to facilitate more efficient pick-ups (e.g., by the transport facilitation system <NUM> utilizing historical pick-up data). In variations, the control system <NUM> can utilize the inputted pick-up location as a radial center of the pick-up area, and can perform a lookup in the pick-up/drop-off location sets <NUM> stored in the database <NUM> for a pick-up location options set <NUM> that corresponds to the expanded area. In further variations, each pick-up/drop-off location option set (PDOLS <NUM>) in the database <NUM> can be associated with a specified pick-up location area. Thus, if the inputted location by the requesting user is within an associated area corresponding to an options set <NUM>, the control system <NUM> can utilize the options set <NUM> in performing the pick-up. In any case, the control system <NUM> can identify a pick-up location options set <NUM> that corresponds to the pick-up location area (<NUM>).

The control system <NUM> can then operate the acceleration, braking, and steering system of the SDV <NUM> to autonomously drive the SDV <NUM> to the pick-up area (<NUM>). As the SDV <NUM> approaches the pick-up area, the control system <NUM> can utilize the sensor data <NUM> to dynamically detect location options in the options set <NUM> (<NUM>). Furthermore, in detecting the location options, the control system <NUM> can determine an availability of each option. In addition, according to examples described herein, the control system <NUM> may then perform a cost analysis for each of the encountered location options in the options set <NUM> (<NUM>). The cost analysis can include any number of factors, and can output a value that ultimately determines whether the control system <NUM> will stop the SDV <NUM> at the encountered or detected option, or whether the control system <NUM> will continue in the hopes that a future encountered option will be available.

Specifically, the cost analysis for each encountered option in the options set <NUM> can include inputs such as ranking, pick-up success rate, average pick-up delta time, distance to inputted pick-up location, distance to actual user location, remaining available options, the rankings of such options, whether the SDV <NUM> has passed the requesting user, and the like. The output of the cost analysis can include a probability that a better option will be encountered or detected after the SDV <NUM> passes the current encountered option. Thus, if the outputted probability is above a certain threshold (e.g., sixty-five percent), the control system <NUM> can disregard the current encountered option and continue along the current route. However, if the probability is below the threshold, then the control system <NUM> can classify the current encountered option as the optimal option for pick-up (<NUM>). Thus, the control system <NUM> can stop the SDV <NUM> to rendezvous with the requesting user and perform the pick-up accordingly (<NUM>).

<FIG> is a flow chart describing another example method of performing a rendezvous process by a self-driving vehicle (SDV), as described herein. In the below description of <FIG>, reference may be made to reference characters representing like features shown and described with respect to <FIG> and <FIG>. Furthermore, the lower level methods and processes described in connection with <FIG> can be performed by an example SDV control system <NUM>, <NUM> as shown and described with respect to <FIG> and <FIG>. Referring to <FIG>, the control system <NUM> can store pick-up and drop-off locations sets <NUM> in a local database <NUM> (<NUM>). In certain variations, the pick-up and drop-off location sets <NUM> can be stored remotely at the backend transport facilitation system <NUM>, and can be accessed by the SDV <NUM> when, for example, a particular transport directive <NUM> is accepted. In further variations, the transport directive <NUM> itself can include an options set <NUM> that corresponds to an inputted pick-up location by the requesting user. For example, the transport facilitation system <NUM> can receive the pick-up request from the user, and perform a lookup in a database that stored pick-up and drop-off location sets <NUM> for a matching options set <NUM> for the inputted pick-up location. Furthermore, each options set <NUM> can include one or more pick-up location options that the transport facilitation system <NUM> has analyzed, based on historical pick-up data <NUM>, to facilitate relatively efficient pick-ups between SDVs or human driven vehicles and requesting users.

According to examples, the control system <NUM> of the SDV <NUM> can receive a transport directive <NUM> from the transport facilitation system <NUM> to service a pick-up request from a requesting user (<NUM>). As described herein, the transport directive <NUM> can include at least an inputted pick-up location by the requesting user (<NUM>). In variations, the transport directive <NUM> can further include identifying information of the user (<NUM>)-such as a unique identifier of the user's mobile computing device (e.g., a media access control address)-a destination, and/or an options set <NUM> that corresponds to the inputted pick-up location. Alternatively, the control system <NUM> can perform a lookup in the database <NUM> for a matching options set <NUM> that corresponds to the inputted pick-up location (<NUM>). Thus, the control system <NUM> can determine whether a matching options set <NUM> is available in the database <NUM> (<NUM>). If a matching options set <NUM> is not found (<NUM>), then the control system <NUM> can perform an on-the-fly selection process to identify an optimal location to pick-up the requesting user (<NUM>).

According to some examples, the on-the-fly selection process can involve the control system <NUM> analyzing sensor data <NUM> for available pick-up location options as the SDV <NUM> approaches the pick-up area (<NUM>). Furthermore, the selection process can take into account the distance between an available option and the inputted or actual location of the requesting user. For example, as the SDV <NUM> approaches the pick-up area, the control system <NUM> can analyze the sensor data <NUM> for open pick-up areas (e.g., parking spaces, turn-outs, loading zones, street corners, etc.) that are proximate to the inputted pick-up location or, if identified, the requesting user. Thus, the control system <NUM> can also scan the situational environment of the SDV <NUM> for the requesting user in performing the selection process to determine an optimal pick-up location. Furthermore, if an available pick-up location is not readily identified, the control system <NUM> can initiate communications with the user's mobile computing device <NUM> to coordinate a pick-up location (<NUM>), as described in further detail below.

However, in certain aspects, if a matching options set <NUM> is identified in the database <NUM> (<NUM>), the control system <NUM> can rank the pick-up location options in the options set <NUM> while en route to the pick-up area (<NUM>). For example, the control system <NUM> can rank the pick-up location options based on the inputted location by the user (<NUM>). Specifically, the options set <NUM> can include a plurality of pick-up location options within a predetermined distance from the inputted pick-up location (e.g., fifty meters). Each option can be previously identified by the transport facilitation system <NUM> as facilitating more efficient pick-ups relative to other specified locations near the inputted pick-up location. The control system <NUM> can initially rank the options based on proximity to the inputted pick-up location, where the nearest options may be ranked higher than the options that are further away.

Additionally or alternatively, the control system <NUM> can rank the options based on historical pick-up data <NUM> indicated in the options set <NUM>. For example, the transport facilitation system <NUM> can analyze pick-up data <NUM> over time to determine a set of attributes for each pick-up location option. These attributes can indicate average pick-up times, success rates, and, in some examples, an overall efficiency score calculated by the transport facilitation system <NUM>. Thus, the control system <NUM> can further rank the options in the options set <NUM> based on the previously determined attributes. Utilizing the ranked options set <NUM>, the control system <NUM> can then perform a hierarchical, cost analysis selection process for each encountered option as the SDV <NUM> approaches the pick-up area (<NUM>). For example, the control system <NUM> can analyze the sensor data <NUM> to first identify a pick-up location option and determine its availability (<NUM>) to either continue the analysis or disregard the option.

If the option is available, the control system <NUM> can further determine whether the option is likely to be most optimal for the pick-up based on a number of factors. Such factors can include a number of remaining options left in the ranked options set <NUM>, the individual rankings of those remaining options, and/or traffic conditions (<NUM>), which may or may not permit a pick-up where, for example, double parking is necessary. For example, the control system <NUM> can analyze the sensor data <NUM> to determine whether current traffic is below a certain threshold. This threshold can comprise various factors such as road conditions, whether multiple lanes are available, the type of neighborhood (e.g., commercial or residential), the speed limit, and the number of detected operating vehicles traveling in the same direction as the SDV <NUM>. If the traffic is below the threshold, then the control system <NUM> can determine that the SDV <NUM> can be safely stopped on the side of the road and/or double parked without causing disruption. Thus, if none of the location options in the options set <NUM> is available, and the traffic is below the threshold, the control system <NUM> can stop the SDV <NUM> at a current location, or at a location most proximate to the requesting user, to make the pick-up. However, if none of the location options are available and the traffic is above the threshold, then the control system <NUM> can perform a reserve operation to make the pick-up, as described herein. Such a reserve operation may include stopping in a red zone, double parking, or transmitting an update to the requesting user or backend transport facilitation system <NUM> indicating that the SDV <NUM> will loop around to make a second attempt.

In various implementations, the control system <NUM> can further scan the situational environment to detect the requesting user. If the requesting user is at an actual location that differs from the inputted location (e.g., by ten or twenty meters), then the control system <NUM> can override the initial rankings and recalculate the cost analysis or probabilities based on the distance of the encountered option to the actual location of the requesting user (<NUM>). Thus, the control system <NUM> can prioritize pick-up location options that are more proximate to the user's actual location, and deprioritize location options that are further away from the user's actual location.

According to some examples, if no location options in the options set <NUM> are available, the control system <NUM> can perform an on-the-fly selection process (<NUM>) described herein, and/or communicate with the requesting user for assistance in making the selection (<NUM>). For example, the control system <NUM> can generate and transmit a mapping feature for display on the user's device <NUM> via the designated application <NUM>. The mapping feature can include a map of the immediate surroundings of the requesting user, and can enable the user to select a particular location in which to rendezvous with the SDV <NUM>. In response to a selection, the control system <NUM> can operate the acceleration, braking, and steering systems of the SDV <NUM> to meet the user at or nearby the selected location.

Alternatively, the control system <NUM> can determine, based on the hierarchical selection process, an optimal location in which to rendezvous with the requesting user (<NUM>). In various aspects, the optimal location can result from a probability calculation for each of the available detected or encountered options (<NUM>). In one example, the control system <NUM> can dynamically calculate a probability that the SDV <NUM> will encounter a higher ranked available option as compared to a currently encountered or detected option. If the probability is above a certain threshold (e.g., sixty-five or seventy percent), then the control system <NUM> can disregard the current option and continue to analyze further detected options. However, if the probability calculate yields a value lower than the threshold, then the control system <NUM> can stop the SDV <NUM> at the current location (<NUM>). Thus, the control system <NUM> can pull over the SDV <NUM> at an optimal pick-up location based on that location corresponding to the first cost probability calculation below the predetermined threshold.

Thereafter, the control system <NUM> can signal the requesting user to rendezvous with the SDV <NUM> at the location. In one example, the control system <NUM> can provide a visual or auditory signal, such as displaying an indication on an outwardly visible display, or sounding a siren or horn of the SDV <NUM>. Additionally or alternatively, the control system <NUM> can transmit a confirmation to the user's device <NUM> indicating that the SDV <NUM> has stopped or will stop at the optimal location option (<NUM>). After picking up the requesting user, the control system <NUM> can autonomously drive the SDV <NUM> to the destination (<NUM>).

<FIG> is a block diagram illustrating a computing system for an SDV upon which examples described herein may be implemented. The computer system <NUM> can be implemented using one or more processors <NUM>, and one or more memory resources <NUM>. In the context of <FIG>, the control system <NUM> can implemented using one or more components of the computer system <NUM> shown in <FIG>.

According to some examples, the computer system <NUM> may be implemented within an autonomous vehicle with software and hardware resources such as described with examples of <FIG>. In an example shown, the computer system <NUM> can be distributed spatially into various regions of the self-driving vehicle, with various aspects integrated with other components of the self-driving vehicle itself. For example, the processors <NUM> and/or memory resources <NUM> can be provided in the trunk of the self-driving vehicle. The various processing resources <NUM> of the computer system <NUM> can also execute rendezvous instructions <NUM> using microprocessors or integrated circuits. In some examples, the rendezvous instructions <NUM> can be executed by the processing resources <NUM> or using field-programmable gate arrays (FPGAs).

In an example of <FIG>, the computer system <NUM> can include a communication interface <NUM> that can enable communications over one or more networks <NUM> with a backend transport facilitation system, such as the transport facilitation system <NUM> described with respect to <FIG>. In one implementation, the communication interface <NUM> can also provide a data bus or other local links to electro-mechanical interfaces of the vehicle, such as wireless or wired links to and from the AV control system <NUM>, and can provide a network link to a transport facilitation system over one or more networks <NUM>. Further still, the communication interface <NUM> can include a local wireless or wired communication link with a user's mobile computing device.

The memory resources <NUM> can include, for example, main memory, a read-only memory (ROM), storage device, and cache resources. The main memory of memory resources <NUM> can include random access memory (RAM) or other dynamic storage device, for storing information and instructions which are executable by the processors <NUM>. The processors <NUM> can execute instructions for processing information stored with the main memory of the memory resources <NUM>. The main memory <NUM> can also store temporary variables or other intermediate information which can be used during execution of instructions by one or more of the processors <NUM>. The memory resources <NUM> can also include ROM or other static storage device for storing static information and instructions for one or more of the processors <NUM>. The memory resources <NUM> can also include other forms of memory devices and components, such as a magnetic disk or optical disk, for purpose of storing information and instructions for use by one or more of the processors <NUM>.

According to some examples, the memory <NUM> may store a plurality of software instructions including, for example, rendezvous instructions <NUM>. The rendezvous instructions <NUM> may be executed by one or more of the processors <NUM> in order to implement functionality such as described with respect to <FIG>.

In certain examples, the computer system can transmit the SDV location <NUM> to the backend transport facilitation system. Based on a correlation between an inputted pick-up location in a pick-up request submitted by a user and the SDV location <NUM>, the computer system <NUM> can receive a transport directive <NUM> via the communication interface <NUM> and network <NUM> from a transport facilitation system. In some aspects, the computer system <NUM> can further receive an options set <NUM>, corresponding to an inputted pick-up location, from the transport facilitation system. In variations, the computer system <NUM> can perform a lookup of proximate pick-up location options in a local database based on the inputted pick-up location in the transport directive <NUM>.

Claim 1:
A self-driving vehicle, SDV, (<NUM>) comprising:
a sensor system to dynamically detect a situational environment of the SDV (<NUM>);
a communications system in communication with a transport facilitation system (<NUM>) in order to enable the SDV (<NUM>) to service pick-up requests (<NUM>);
acceleration, braking, and steering systems and;
a control system (<NUM>) to execute instructions that cause the control system (<NUM>) to:
process sensor data (<NUM>) from the sensor system to autonomously operate the acceleration, braking, and steering systems throughout a given region;
receive a transport directive from the transport facilitation system (<NUM>) to service a pick-up request (<NUM>) from a requesting user, the transport directive indicating an inputted pick-up location by the requesting user;
autonomously operate the acceleration, braking, and steering systems along a current route to a pick-up area encompassing the inputted pick-up location;
characterized in that the executed instructions further cause the control system to:
determine a corresponding set of pick-up location options (<NUM>) for the pick-up area;
determine a ranking of respective pick-up location options in the set of pick-up location options (<NUM>); and
as the SDV (<NUM>) approaches the pick-up area, perform an operation to identify, via the sensor data (<NUM>), an optimal pick-up location option from the set of pick-up location options to rendezvous with the requesting user, the identifying of the optimal pick-up location option being based at least in part on a probability indicating whether a pick-up location option of the set of pick-up location options ranked higher than the optimal pick-up location option will be available to rendezvous with the requesting user.