Patent Description:
Autonomous vehicles, such as vehicles that do not require a human driver, can be used to aid in the transport of passengers or items from one location to another. Such vehicles may operate in a fully autonomous mode where passengers may provide some initial input, such as a destination, and the vehicle maneuvers itself to that destination.

With a typical taxi service, a passenger and vehicle (and/or driver) are assigned to one another, the vehicle stops to allow the passenger to enter, and once safely inside, the vehicle is maneuvered to a destination location, presumably selected by the passenger. Where there is a human driver, the passenger is able to communicate his or her desire to be dropped off at a particular location fairly easily based on the passenger's assessment of the environment of the vehicle. The driver is then able to make a judgment about whether it is safe to stop and let the passenger out. However, in the case of a vehicle without a driver, communicating the passenger's desire to be let out of the vehicle at a particular location (especially when it is not the destination location) is extremely complicated.

<CIT> describes 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 a 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> describes a vehicle for maneuvering 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 and an emergency stopping button different from the dual-purpose button configured to stop the vehicle. The dual-purpose button has a first purpose for communicating a 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.

Claim <NUM> defines a method of stopping a vehicle without a driver. The method comprises: after a passenger has entered the vehicle, maneuvering, by one or more processors, the vehicle in an autonomous driving mode towards a destination location along a route, the route being divided into two or more stages; receiving, by the one or more processors, a signal indicating that the passenger is requesting that the vehicle stop or pull over; in response to receiving the signal, determining, by the one or more processors, a current stage of the two or more stages of the route based on (<NUM>) a current distance, in time or space, of the vehicle from a pickup location where the passenger entered the vehicle and/or (<NUM>) a current distance, in time or space, of the vehicle from the destination location, wherein the current stage is determined based on whether or not the vehicle is within a first threshold distance, in time or space, from the pickup location and/or whether or not the vehicle is within a second threshold distance, in time or space, from the destination location; and stopping, by the one or more processors, the vehicle, wherein where and how the vehicle is stopped is determined based on the determined current stage.

In one example, the determined current stage corresponds to the vehicle being in a parking lot where the passenger entered the vehicle, and stopping the vehicle includes stopping the vehicle at a current location of the vehicle when the signal is received. In this example, the method also includes while the vehicle is stopped, waiting for the passenger to exit and reenter the vehicle. In another example, the determined current stage corresponds to the vehicle being within the first threshold distance, in time or space, from the pickup location, and stopping the vehicle includes stopping the vehicle at a current location of the vehicle when the signal is received. In this example, the method may further comprise, while the vehicle is stopped, waiting for the passenger to exit and reenter the vehicle. In another example, the determined current stage corresponds to the vehicle being more than the second threshold distance, in time or space, from the destination location, and stopping the vehicle includes accessing map information identifying pull over spots where the vehicle is able to stop and allow passengers to exit the vehicle; identifying an available one of the pull over spots; and stopping the vehicle in the available one of the pull over spots. In another example, the determined current stage corresponds to the vehicle being more than the second threshold distance, in time or space, from the destination location, and the method also includes, prior to maneuvering the vehicle towards the destination, setting the destination location as a destination goal for the vehicle; and setting a current location of the vehicle when the signal is received as a new destination goal for the vehicle, and wherein stopping the vehicle is further based on the new destination goal. In another example, the determined current stage corresponds to the vehicle being within the second threshold distance, in time or space, from the destination location, and stopping the vehicle includes stopping the vehicle at a current location of the vehicle when the signal is received. In another example, the determined current stage corresponds to the vehicle being within the second threshold distance, in time or space, from the destination location, and stopping the vehicle includes determining whether the vehicle is already maneuvering to stop, and when the vehicle is determined to be already maneuvering to stop, continuing the maneuvering to the stop and ignoring the signal.

Claim <NUM> defines a system for stopping a vehicle without a driver. The system comprises one or more computing devices having one or more processors configured to: after a passenger has entered the vehicle, maneuver the vehicle in an autonomous driving mode towards a destination location along a route, the route being divided into two or more stages; receive a signal indicating that the passenger is requesting that the vehicle stop or pull over; in response to receiving the signal, determine a current stage of the two or more stages of the route based on (<NUM>) a current distance, in time or space, of the vehicle from a pickup location where the passenger entered the vehicle and/or (<NUM>) a current distance, in time or space, of the vehicle from the destination location, wherein the current stage is determined based on whether or not the vehicle is within a first threshold distance, in time or space, from the pickup location and/or whether or not the vehicle is within a second threshold distance, in time or space, from the destination location; and stopping the vehicle, wherein where and how the vehicle is stopped is determined based on the determined current stage.

In one example, the determined current stage corresponds to the vehicle being in a parking lot where the passenger entered the vehicle, and the one or more processors are also configured to stop the vehicle by stopping the vehicle at a current location of the vehicle when the signal is received. In this example, the one or more processors are also configured to, while the vehicle is stopped, waiting for the passenger to exit and reenter the vehicle. In another example, the determined current stage corresponds to the vehicle being within the first threshold distance, in time or space, from the pickup location, and the one or more processors are further configured to stop the vehicle by stopping the vehicle at a current location of the vehicle when the signal is received. In this example, the one or more processors are also configured to, while the vehicle is stopped, wait for the passenger to exit and reenter the vehicle. In another example, the determined current stage corresponds to the vehicle being more than the second threshold distance, in time or space, from the destination location, and the one or more processors are configured to stop the vehicle by accessing map information identifying pull over spots where the vehicle is able to stop and allow passengers to exit the vehicle; identifying an available one of the pull over spots; and stopping the vehicle in the available one of the pull over spots. In another example, the determined current stage corresponds to the vehicle being more than the second threshold distance, in time or space, from the destination location, and the one or more processors are further configured to, prior to maneuvering the vehicle towards the destination, set the destination location as a destination goal for the vehicle, and set a current location of the vehicle when the signal is received as a new destination goal for the vehicle, and stopping the vehicle is further based on the new destination goal. In another example, the determined current stage corresponds to the vehicle being within the second threshold distance, in time or space, from the destination location, and the one or more processors are further configured to stop the vehicle by stopping the vehicle at a current location of the vehicle when the signal is received. In another example, the determined current stage corresponds to the vehicle being within the second threshold distance, in time or space, from the destination location, and stopping the vehicle includes determining whether the vehicle is already maneuvering to stop, and when the vehicle is determined to be already maneuvering to stop, continuing the maneuvering to the stop and ignoring the signal. In another example, the system also includes the vehicle.

Claim <NUM> defines a non-transitory computer-readable medium on which instructions are stored. The instructions, when executed by one or more processors cause the one or more processors to perform a method of stopping a vehicle without a driver, the method comprising: after a passenger has entered the vehicle, maneuvering the vehicle in an autonomous driving mode towards a destination location along a route, the route being divided into two or more stages; receiving a signal indicating that the passenger is requesting that the vehicle stop or pull over; in response to receiving the signal, determining a current stage of the two or more stages of the route based on (<NUM>) a current distance, in time or space, of the vehicle from a pickup location where the passenger entered the vehicle and/or (<NUM>) a current distance, in time or space, of the vehicle from the destination location, wherein the current stage is determined based on whether or not the vehicle is within a first threshold distance, in time or space, from the pickup location and/or whether or not the vehicle is within a second threshold distance, in time or space, from the destination location; and stopping the vehicle, wherein where and how the vehicle is stopped is determined based on the determined current stage.

Aspects of the technology relate to context aware stopping for dropping off passengers in vehicles that do not have a human driver, for instance, autonomous vehicles. As discussed above, this can be challenging due to the absence of a human driver, and safety risks involved.

In one example, a passenger may express intent by pressing a "pull over" or "stop" button in the vehicle and/or on a client device of the passenger. This may send a signal to the computing devices of the vehicle. In response, the computing devices may attempt to pull over at the first available pull over spot along the current route. In some cases, these pull over spots may be predesignated as such in map information used by the computing devices to maneuver the vehicle. In any event, this response may be problematic as it may take some time to find a spot, especially on roads with higher speed limits. Of course, if the computing devices are not able to pull over the vehicle within a short period of time, such as <NUM> minutes or more or less, the computing devices may then stop the vehicle in a lane (assuming the lane is the farthest to the right in a left hand drive country) or in a shoulder area if possible.

Using the aforementioned button may operate to cause the computing devices to change or update the destination location. For instance, once the passenger uses the button, the computing devices may update the destination location to the vehicle's current location. In such examples, where the computing devices are able to immediately pull over the vehicle, they may do so. If this is not possible, the computing devices may route the vehicle around back towards the updated destination location.

Depending upon how far the vehicle has traveled along a route to the destination location or how far away from the destination location the vehicle is, this information may be used by the computing devices to determine where and how to stop the vehicle and allow the passenger to get out of the vehicle. In this regard, the trip or route may be divided into stages: an early stage, a middle stage, and a late stage.

In the early stage, the computing devices may respond to the passenger using the button by stopping the vehicle immediately in the vehicle's current position. For instance, in response to a signal from the button, the computing devices may give the passenger some time to exit and reenter the vehicle if needed. In some circumstances, the computing devices may only wait for the passenger to reenter the vehicle if the passenger leaves the door of the vehicle open. Again, this may allow the passenger time to get out, retrieve an item, and get back into the vehicle without disrupting the flow of traffic. Alternatively, if the door is closed or if the passenger is gone for an extended period of time, the passenger may be assumed to have cancelled the trip.

If the vehicle has fully merged into a lane of traffic but is more than a second threshold distance away from the destination location, the vehicle may be in the middle stage of a trip. In response to a signal, the computing devices may attempt to find the nearest pull over spot. As an example, this second threshold distance may be <NUM> meters or <NUM> minute or more or less. Again, as noted above, the nearest pull over spot may be the nearest available spot identified from the map information. Once pulled over, the computing devices may indicate to the passenger that it is time to exit the vehicle and allow the passenger to exit the vehicle.

If the vehicle is within a second threshold distance from the destination location, the vehicle may be in late stage of the route. The response of the computing devices to the passenger using the button at this stage may depend on whether the computing devices have already identified a pull over spot and are attempting to maneuver the vehicle into that pull over spot. If so, the computing devices may "ignore" the signal from the button and continue to pull the vehicle into the pull over spot. If not, the computing device may change the destination to the vehicle's current location as discussed above and stop the vehicle in the closest available location to do so under the circumstances. In some cases, this may allow the computing devices to stop the vehicle immediately, again depending on the current circumstances of traffic and the speed limit of the roadway.

The features described herein, which provide for context aware stopping of autonomous vehicles, may allow passengers the ability to get out of a vehicle safely and conveniently prior to reaching a destination. These features also may alleviate some of the burden of the computing devices identifying the exact location of where a passenger wants to get out of a vehicle. Finally, the functionality of allowing a user to end a ride using a button within the vehicle as well as his or her client computing device may increase the feeling of control that the user has while traveling in such vehicles.

As shown in <FIG>, a vehicle <NUM> may include various components. While certain aspects described herein are particularly useful in connection with specific types of vehicles, the vehicle may be any type of vehicle including, but not limited to, cars, trucks, motorcycles, buses, recreational vehicles, etc. The vehicle may have one or more computing devices, such as computing device <NUM> containing one or more processors <NUM>, memory <NUM> and other components typically present in general purpose computing devices.

The one or more processor <NUM> may be any conventional processors, such as commercially available CPUs. Alternatively, the one or more processors may be a dedicated device such as an ASIC or other hardware-based processor. Although <FIG> functionally illustrates the processor, memory, and other elements of computing device <NUM> as being within the same block, it will be understood by those of ordinary skill in the art that the processor, computing device, or memory may actually include multiple processors, computing devices, or memories that may or may not be stored within the same physical housing. For example, memory may be a hard drive or other storage media located in a housing different from that of computing device <NUM>. Accordingly, references to a processor or computing device will be understood to include references to a collection of processors or computing devices or memories that may or may not operate in parallel.

Computing device <NUM> may all of the components normally used in connection with a computing device such as the processor and memory described above as well as a user input <NUM> (e.g., a mouse, keyboard, touch screen and/or microphone) and various electronic displays (e.g., a monitor having a screen or any other electrical device that is operable to display information). In this example, the vehicle includes an internal electronic display <NUM> as well as one or more speakers <NUM> to provide information or audio visual experiences. In this regard, internal electronic display <NUM> may be located within a cabin of vehicle <NUM> and may be used by computing device <NUM> to provide information to passengers within the vehicle <NUM>.

Computing device <NUM> may also include one or more wireless network connections <NUM> to facilitate communication with other computing devices, such as the client computing devices and server computing devices described in detail below. The wireless network connections may include short range communication protocols such as Bluetooth, Bluetooth low energy (LE), cellular connections, as well as various configurations and protocols including the Internet, World Wide Web, intranets, virtual private networks, wide area networks, local networks, private networks using communication protocols proprietary to one or more companies, Ethernet, WiFi and HTTP, and various combinations of the foregoing.

In one example, computing device <NUM> may be an autonomous driving computing system incorporated into vehicle <NUM>. The autonomous driving computing system may capable of communicating with various components of the vehicle. For example, returning to <FIG>, computing device <NUM> may be in communication with various systems of vehicle <NUM>, such as deceleration system <NUM>, acceleration system <NUM>, steering system <NUM>, signaling system <NUM>, navigation system <NUM>, positioning system <NUM>, and perception system <NUM> in order to control the movement, speed, etc. of vehicle <NUM> in accordance with the instructions <NUM> of memory <NUM>. Again, although these systems are shown as external to computing device <NUM>, in actuality, these systems may also be incorporated into computing device <NUM>, again as an autonomous driving computing system for controlling vehicle <NUM>.

As an example, computing device <NUM> may interact with deceleration system <NUM> and acceleration system <NUM> in order to control the speed of the vehicle. Similarly, steering system <NUM> may be used by computer <NUM> in order to control the direction of vehicle <NUM>. For example, if vehicle <NUM> is configured for use on a road, such as a car or truck, the steering system may include components to control the angle of wheels to turn the vehicle. Signaling system <NUM> may be used by computing device <NUM> in order to signal the vehicle's intent to other drivers or vehicles, for example, by lighting turn signals or brake lights when needed.

Navigation system <NUM> may be used by computing device <NUM> in order to determine and follow a route to a location. In this regard, the navigation system <NUM> and/or data <NUM> may store detailed map information, e.g., highly detailed maps identifying the shape and elevation of roadways, lane lines, intersections, crosswalks, speed limits, traffic signals, buildings, signs, real time traffic information, pull over spots vegetation, or other such objects and information. As discussed further below, these pull over spots may be "hand" selected or identified areas where at which the vehicle is lawfully able to stop and park for some period of time such as shoulder areas, parking spots, parking lots, emergency pull over spots, etc..

<FIG> is an example of map information <NUM> for a section of roadway. The map information <NUM> includes information identifying the shape, location, and other characteristics of various road features. In this example, the map information includes three lanes <NUM>, <NUM>, <NUM> bounded by curb <NUM>, lane lines <NUM>, <NUM>, <NUM>, and curb <NUM>. Lanes <NUM> and <NUM> have the same direction of traffic flow (in an eastward direction), while lane <NUM> has a different traffic flow (in a westward direction). In addition, lane <NUM> is significantly wider than lane <NUM>, for instance to allow for vehicles to park adjacent to curb <NUM>. In this regard, the map information <NUM> also includes a plurality of pull over spots <NUM>-<NUM> identified in the map information. Although the example of map information includes only a few road features, for instance, curbs, lane lines, and lanes, given the nature of the roadway of map information <NUM>, the map information may also identify various other road features such as traffic signal lights, crosswalks, sidewalks, stop signs, yield signs, speed limit signs, road signs, etc. Although not shown, the detailed map information may also include information identifying speed limits and other legal traffic requirements as well as historical information identifying typical and historical traffic conditions at various dates and times.

Positioning system <NUM> may be used by computing device <NUM> in order to determine the vehicle's relative or absolute position on a map or on the earth. For example, the position system <NUM> may include a GPS receiver to determine the device's latitude, longitude and/or altitude position. Other location systems such as laser-based localization systems, inertial-aided GPS, or camera-based localization may also be used to identify the location of the vehicle. The location of the vehicle may include an absolute geographical location, such as latitude, longitude, and altitude as well as relative location information, such as location relative to other cars immediately around it which can often be determined with less noise that absolute geographical location.

The positioning system <NUM> may also include other devices in communication with computing device <NUM>, such as an accelerometer, gyroscope or another direction/speed detection device to determine the direction and speed of the vehicle or changes thereto. By way of example only, an acceleration device may determine its pitch, yaw or roll (or changes thereto) relative to the direction of gravity or a plane perpendicular thereto. The device may also track increases or decreases in speed and the direction of such changes. The device's provision of location and orientation data as set forth herein may be provided automatically to the computing device <NUM>, other computing devices and combinations of the foregoing.

The perception system <NUM> also includes one or more components for detecting objects external to the vehicle such as other vehicles, obstacles in the roadway, traffic signals, signs, trees, etc. For example, the perception system <NUM> may include lasers, sonar, radar, cameras and/or any other detection devices that record data which may be processed by computing device <NUM>. In the case where the vehicle is a small passenger vehicle such as a car, the car may include a laser or other sensors mounted on the roof or other convenient location.

The computing device <NUM> may control the direction and speed of the vehicle by controlling various components. By way of example, computing device <NUM> may navigate the vehicle to a destination location completely autonomously using data from the detailed map information and navigation system <NUM>. Computing device <NUM> may use the positioning system <NUM> to determine the vehicle's location and perception system <NUM> to detect and respond to objects when needed to reach the location safely. In order to do so, computing device <NUM> may cause the vehicle to accelerate (e.g., by increasing fuel or other energy provided to the engine by acceleration system <NUM>), decelerate (e.g., by decreasing the fuel supplied to the engine, changing gears, and/or by applying brakes by deceleration system <NUM>), change direction (e.g., by turning the front or rear wheels of vehicle <NUM> by steering system <NUM>), and signal such changes (e.g., by lighting turn signals of signaling system <NUM>). Thus, the acceleration system <NUM> and deceleration system <NUM> may be a part of a drivetrain that includes various components between an engine of the vehicle and the wheels of the vehicle. Again, by controlling these systems, computing device <NUM> may also control the drivetrain of the vehicle in order to maneuver the vehicle autonomously.

Computing device <NUM> of vehicle <NUM> may also receive or transfer information to and from other computing devices. <FIG> and <FIG> are pictorial and functional diagrams, respectively, of an example system <NUM> that includes a plurality of computing devices <NUM>, <NUM>, <NUM>, <NUM> and a storage system <NUM> connected via a network <NUM>. System <NUM> also includes vehicle <NUM>, and vehicle 100A which may be configured similarly to vehicle <NUM>. Although only a few vehicles and computing devices are depicted for simplicity, a typical system may include significantly more.

In one example, one or more computing devices <NUM> may include a server having a plurality of computing devices, e.g., a load balanced server farm, that exchange information with different nodes of a network for the purpose of receiving, processing and transmitting the data to and from other computing devices. For instance, one or more computing devices <NUM> may include one or more server computing devices that are capable of communicating with computing device <NUM> of vehicle <NUM> or a similar computing device of vehicle 100A as well as computing devices <NUM>, <NUM>, <NUM> via the network <NUM>. For example, vehicles <NUM> and 100A may be a part of a fleet of vehicles that can be dispatched by server computing devices to various locations. In this regard, the vehicles of the fleet may periodically send the server computing devices location information provided by the vehicle's respective positioning systems and the one or more server computing devices may track the locations of the vehicles.

In addition, server computing devices <NUM> may use network <NUM> to transmit and present information to a user, such as user <NUM>, <NUM>, <NUM> on a display, such as displays <NUM>, <NUM>, <NUM> of computing devices <NUM>, <NUM>, <NUM>. In this regard, computing devices <NUM>, <NUM>, <NUM> may be considered client computing devices.

As shown in <FIG>, each client computing device <NUM>, <NUM>, <NUM> may be a personal computing device intended for use by a user <NUM>, <NUM>, <NUM>, and have all of the components normally used in connection with a personal computing device including a one or more processors (e.g., a central processing unit (CPU)), memory (e.g., RAM and internal hard drives) storing data and instructions, a display such as displays <NUM>, <NUM>, <NUM> (e.g., a monitor having a screen, a touch-screen, a projector, a television, or other device that is operable to display information), and user input devices <NUM>, <NUM>, <NUM> (e.g., a mouse, keyboard, touchscreen or microphone). The client computing devices may also include a camera for recording video streams, speakers, a network interface device, and all of the components used for connecting these elements to one another.

In addition, the client computing devices <NUM> and <NUM> may also include components <NUM> and <NUM> for determining the position and orientation of client computing devices. For example, these components may include a GPS receiver to determine the device's latitude, longitude and/or altitude as well as an accelerometer, gyroscope or another direction/speed detection device as described above with regard to positioning system <NUM> of vehicle <NUM>.

Although the client computing devices <NUM>, <NUM>, and <NUM> may each comprise a full-sized personal computing device, they may alternatively comprise mobile computing devices capable of wirelessly exchanging data with a server over a network such as the Internet. By way of example only, client computing device <NUM> may be a mobile phone or a device such as a wireless-enabled PDA, a tablet PC, a wearable computing device or system, or a netbook that is capable of obtaining information via the Internet or other networks. In another example, client computing device <NUM> may be a wearable computing system, shown as a wrist watch in <FIG>. As an example the user may input information using a small keyboard, a keypad, microphone, using visual signals with a camera, or a touch screen.

In some examples, client computing device <NUM> may be a concierge work station used by an administrator to provide concierge services to users such as users <NUM> and <NUM>. For example, a concierge <NUM> may use the concierge work station <NUM> to communicate via a telephone call or audio connection with users through their respective client computing devices or vehicles <NUM> or 100A in order to facilitate the safe operation of vehicles <NUM> and 100A and the safety of the users as described in further detail below. Although only a single concierge work station <NUM> is shown in <FIG> and <FIG>, any number of such work stations may be included in a typical system.

Storage system <NUM> may store various types of information as described in more detail below. This information may be retrieved or otherwise accessed by a server computing device, such as one or more server computing devices <NUM>, in order to perform some or all of the features described herein. For example, the information may include user account information such as credentials (e.g., a user name and password as in the case of a traditional single-factor authentication as well as other types of credentials typically used in multi-factor authentications such as random identifiers, biometrics, etc.) that can be used to identify a user to the one or more server computing devices. The user account information may also include personal information such as the user's name, contact information, identifying information of the user's client computing device (or devices if multiple devices are used with the same user account), as well as one or more unique signals for the user.

The storage system <NUM> may also store routing data for generating and evaluating routes between locations. For example, the routing information may be used to estimate how long it would take a vehicle at a first location to reach a second location. In this regard, the routing information may include map information, not necessarily as particular as the detailed map information described above, but including roads, as well as information about those road such as direction (one way, two way, etc.), orientation (North, South, etc.), speed limits, as well as traffic information identifying expected traffic conditions, etc..

As with memory <NUM>, storage system <NUM> can be of any type of computerized storage capable of storing information accessible by the server computing devices <NUM>, such as a hard-drive, memory card, ROM, RAM, DVD, CD-ROM, write-capable, and read-only memories. In addition, storage system <NUM> may include a distributed storage system where data is stored on a plurality of different storage devices which may be physically located at the same or different geographic locations. Storage system <NUM> may be connected to the computing devices via the network <NUM> as shown in <FIG> and/or may be directly connected to or incorporated into any of the computing devices <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc..

<FIG> are examples of external views of vehicle <NUM>. As can be seen, vehicle <NUM> includes many features of a typical vehicle such as headlights <NUM>, windshield <NUM>, taillights/turn signal lights <NUM>, rear windshield <NUM>, doors <NUM>, side view mirrors <NUM>, tires and wheels <NUM>, and turn signal/parking lights <NUM>. Headlights <NUM>, taillights/turn signal lights <NUM>, and turn signal/parking lights <NUM> may be associated the signaling system <NUM>. Light bar <NUM> may also be associated with the signaling system <NUM>.

Vehicle <NUM> also includes sensors of the perception system <NUM>. For example, housing <NUM> may include one or more laser devices for having <NUM> degree or narrower fields of view and one or more camera devices. Housings <NUM> and <NUM> may include, for example, one or more radar and/or sonar devices. The devices of the perception system may also be incorporated into the typical vehicle components, such as taillights/turn signal lights <NUM> and/or side view mirrors <NUM>. Each of these radar, camera, and lasers devices may be associated with processing components which process data from these devices as part of the perception system <NUM> and provide sensor data to the computing device <NUM>.

<FIG> is an example internal view of vehicle <NUM> through the opening of door <NUM>. In this example, there are two seats <NUM> for passengers with a console <NUM> between them. Directly in ahead of the seats <NUM> is a dashboard configuration <NUM> having a storage bin area <NUM> and the internal electronic display <NUM>. As can be readily seen, vehicle <NUM> does not include a steering wheel, gas (acceleration) pedal, or brake (deceleration) pedal which would allow for a semiautonomous or manual driving mode where a passenger would directly control the steering, acceleration and/or deceleration of the vehicle via the drivetrain. Rather, as described in further detail below, user input is limited to a microphone of the user input <NUM> (not shown), features of the console <NUM>, and wireless network connections <NUM>. In this regard, internal electronic display <NUM> merely provides information to the passenger and need not include a touch screen or other interface for user input. In other embodiments, the internal electronic display <NUM> may include a touch screen or other user input device for entering information by a passenger such as a destination, etc..

<FIG> is a top down view of the console <NUM>. Console <NUM> includes various buttons for controlling features of vehicle <NUM>. For example, console <NUM> includes buttons that may be found in a typical vehicle such as buttons <NUM> for locking and unlocking the doors <NUM>, buttons <NUM> for raising or lowering the windows of doors <NUM>, buttons <NUM> for turning on internal lights of the vehicle, buttons <NUM> for controlling a heating function of seats <NUM>, as well as buttons <NUM> for controlling the volume of speakers <NUM>.

In addition, console <NUM> also includes buttons <NUM> for initiating communication with concierge <NUM> via one of the wireless network connections <NUM>. Once the concierge work station is connected to the vehicle, the concierge may communicate with the passenger via the speakers <NUM> and/or internal electronic display <NUM>. In addition, the microphone allows the passenger to speak directly to the concierge. In some cases, vehicle <NUM> may include an internal still or video camera that allows the concierge to view the status of the passengers and confirm their safety.

Buttons <NUM> and <NUM> may also be a part of user input <NUM> and in this regard, allow a passenger to communicate with computing device <NUM>, for example, to initiate or end a trip in the vehicle. In this regard, button <NUM> may act as an emergency stopping button that, when pushed, causes vehicle <NUM> to stop in a short amount of time. Because the passenger does not have direct control of the acceleration or deceleration of vehicle <NUM> by way of a gas or brake pedal, button <NUM> may be an emergency stop button that is critical to allowing a passenger to feel safe and act quickly in case of an immediate emergency. In addition, because of the potentially abrupt nature of a stop initiated by the emergency stopping button <NUM>, the emergency stopping button <NUM> may feature a cover (e.g., a clear plastic cover) that may have to be removed or flipped up in order to activate button <NUM>.

Button <NUM> may be a multi-function button. For example, <FIG> provides examples of the same button; here button <NUM>, in three different states. In the first state <NUM>, button <NUM> is inactive, that is, if pressed, the computer devices <NUM> would not respond by taking any particular action with regard to controlling the movement of the vehicle. However, even in this inactive state, the computing devices <NUM> may provide a passenger with some visual or audible feedback to indicate that the button is pressed. As an example, this feedback may indicate that the computer recognizes that the button was pressed or otherwise activated, but that button is currently inactive and the vehicle will not respond by maneuvering the vehicle in any particular way (e.g., not starting a trip or pulling over).

In the second state <NUM>, when the vehicle is ready to begin a trip, the button <NUM> may change to a "GO" button which a passenger uses to initiate a trip to a destination or drop off location. Once vehicle <NUM> is moving, button <NUM> may change to a third state <NUM>, where the button <NUM> is a "PULL OVER" button which a passenger users to initiate a non-emergency stop. In this regard, computer <NUM> may respond by determining a reasonable place to pull the vehicle over, rather than coming to a more sudden stop as with the emergency stop button <NUM>. Arrows <NUM>, <NUM>, and <NUM> indicate that the states need not be displayed only in the order of first, second third, but may switch from second to first, third to first, third to second, etc. as dictated by the needs of computer <NUM>.

In addition or alternatively, rather than having a single multipurpose button, such as button <NUM>, two buttons with different states of activation may be used. In this regard, a first button may have an inactive state and an active or "GO" state which enables a passenger to initiate a trip to a destination or drop off location. A second button may have an inactive state and an active or "PULL OVER" state which enables a passenger to initiate a non-emergency stop. In some examples, when the first button is in the active state, the second button is in the inactive state. Similarly, when the second button is in the active state, the first button may be in the inactive state. In some instances, before the vehicle is ready to start a trip to a drop off location, both the first and second buttons may be in the inactive state. In any event, when the vehicle is moving towards a destination location, computing device <NUM> may respond to a signal from button <NUM> by determining a safe place to pull the vehicle over, rather than coming to a more sudden stop as with the emergency stop button <NUM>.

Alternatively, two buttons, one having a "GO" state and the other having a "PULL OVER" state may be used. For example, <FIG> is a side perspective view of a console <NUM> having a set of buttons which may be part of user input <NUM>. The set of buttons in this example includes two buttons which can initiate a trip or cause the vehicle to pull over. Console <NUM> may be positioned on an interior of vehicle <NUM> at a headliner area (the interior surface of the roof of the vehicle. Console <NUM> may be used as an alternative to console <NUM> or in addition to console <NUM>. In this example, console <NUM> includes buttons <NUM>, <NUM>, <NUM>, and <NUM>. Each of these buttons operates to send a signal to the computing devices <NUM>. In response to the signal from button <NUM>, the computing devices <NUM> may connect the passenger with a concierge. A signal from button <NUM> may cause the computing devices <NUM> to lock or unlock the doors (depending upon the current state of the doors). A signal from button <NUM> may cause the computing devices to pull the vehicle over, similar to the operation of the button <NUM> when in the "PULL OVER" state. A signal from button <NUM> may cause the computing devices to initiate a trip to a destination, similar to the operation of the button <NUM> when in the "GO" state.

Thus, passenger communication with computing device <NUM> for navigation purposes may be limited to buttons such as button <NUM> and emergency stopping button <NUM> and/or button, wireless network connection <NUM> (such as Bluetooth LE) with the passenger's client computing device, and by sending information from the passenger's client computing device to the server computing devices <NUM> which then relays that information to the vehicle's computing device. In some examples, a passenger may provide information to the vehicle's computing device <NUM> via voice commands through the microphone as discussed above. In addition, however, the passenger may communicate with the concierge via a phone call, an application on the passenger's client computing device, a microphone, and/or the button <NUM> and in turn, the concierge may provide instructions control certain aspects of a vehicle via a concierge work station.

In one aspect, a user may download an application for requesting a vehicle to a client computing device. For example, users <NUM> and <NUM> may download the application via a link in an email, directly from a website, or an application store to client computing devices <NUM> and <NUM>. For example, client computing device may transmit a request for the application over the network, for example, to one or more server computing devices <NUM>, and in response, receive the application. The application may be installed locally at the client computing device.

The user may then use his or her client computing device to access the application and request a vehicle. As an example, a user such as user <NUM> may use client computing device <NUM> to send a request to one or more server computing devices <NUM> for a vehicle. The request may include information identifying a pickup location or area and/or a destination location or area. As an example, such location may be identified by street addresses, location coordinates, points of interest, etc. In response the one or more server computing devices <NUM> may identify and dispatch, for example based on availability and location, a vehicle such as vehicle <NUM> to the pickup location. This dispatching may involve sending information to the vehicle identifying the user (and/or the user's client device), the pickup location, and the destination location or area.

The computing devices <NUM> may use the information from the server computing devices to identify a pick up location and destination location for an assigned passenger. The computing devices <NUM> may then maneuver the vehicle towards the pickup location as discussed above. Once the vehicle is some predetermined distance from the pickup location, the computing devices <NUM> may attempt to stop the vehicle at a location proximate to the pickup location in order to allow the passenger to enter. Once the passenger has entered the vehicle, he or she may be asked to perform some tasks such as buckle a seat belt, close a door, confirm his or her destination as that of the assigned passenger, and initiate a trip to the passenger's destination location. This initiation may be performed, for instance by using button <NUM> (when in the "GO" state) or button <NUM>. In response to a signal from one of these buttons, the computing devices <NUM> may begin to maneuver the vehicle <NUM> towards the destination location for the passenger.

<FIG> is an example view of vehicle <NUM> driving along a roadway <NUM> corresponding to the map information <NUM> of <FIG>. In that regard, lanes <NUM>, <NUM>, <NUM> correspond to the shape and location of lanes <NUM>, <NUM>, <NUM>, curbs <NUM>, <NUM> correspond to the shape and location of curb <NUM>, and lane lines <NUM>, <NUM>, <NUM> correspond to the shape and location of lane lines <NUM>, <NUM>, <NUM>, and curb <NUM>. In this example, vehicle <NUM> is traveling in lane <NUM>. Vehicles <NUM>, <NUM>, and <NUM> are parked within lane <NUM> along curb <NUM>, while vehicle <NUM> is moving in lane <NUM> and vehicle <NUM> is moving in lane <NUM>. Because pull over spots <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> merely correspond to a shoulder area where vehicle <NUM> could lawfully park for some period of time, there is no corresponding "real world" feature included in <FIG>.

As the vehicle moves along lane <NUM>, the perception system <NUM> provides the computing devices with sensor data regarding the shapes and location of objects, such as curbs <NUM>, <NUM>, lane lines <NUM>, <NUM>, <NUM>, as well as vehicles <NUM>, <NUM>, <NUM>, <NUM>. <FIG> depicts sensor data perceived by the various sensors of the perception system <NUM> when vehicle <NUM> is in the situation as depicted in <FIG> in combination with other information available to the computing devices <NUM>. In this example, vehicles <NUM>, <NUM>, <NUM>, <NUM>, are represented by bounding boxes for objects <NUM>, <NUM>, <NUM>, <NUM> as provided by the perception system <NUM> to the computing devices <NUM>. Of course, these bounding boxes represent merely a volume of space within which data points corresponding to an object are at least approximately bounded within. In addition, in <FIG>, the destination location for passenger is represented by a marker <NUM>.

Along the way to the destination location, represented by marker <NUM>, a passenger may express intent to stop the vehicle to the computing devices <NUM> by pressing a button, such as buttons <NUM> or <NUM>, in the vehicle and/or on a client device of the passenger using the application described above. Although not required, for simplicity, the layout of virtual buttons displayed on a touch-sensitive display of the client computing device may mimic the layout of the buttons of the vehicle in order to give the passenger greater context about what the buttons mean. This may send a signal to the computing devices of the vehicle. In response, the computing devices may attempt to pull over at the first available pull over spot along the current route. As noted above, these pull over spots may be predesignated as such in map information used by the computing devices to maneuver the vehicle. In any event, this response may be problematic as it may take some time to find a spot or may be potentially dangerous to stop in some areas, especially on roads with higher speed limits, such as those greater than <NUM> miles per hour. Of course, if the computing devices are not able to pull over the vehicle within a short period of time, such as <NUM> minutes or more or less, the computing devices may then stop the vehicle in a lane (assuming the lane is the farthest to the right in a left hand drive country) or in a shoulder area if possible.

Using one of buttons <NUM> or <NUM> or requesting a pull over using a client device of the passenger, may cause the computing devices to change or update the destination location. For instance, once the passenger uses one of the buttons <NUM> or <NUM>, the computing devices may update the destination location to the vehicle's current location. In such examples, where the computing devices are able to immediately pull over the vehicle, they may do so. For example, turning to <FIG>, which combines the example of <FIG> with the pull over spots of <FIG>, a passenger within vehicle <NUM> may use button <NUM> or button <NUM> (or his or her client computing device) to indicate a desire to pull the vehicle over. In response, the computing devices may replace the destination location, represented by marker <NUM>, with the current location of the vehicle represented by marker <NUM>. Accordingly, the computing devices <NUM> may immediately begin looking for an available pull over spot. In the example of <FIG>, the computing devices <NUM> may identify pull over spot <NUM> as the closest available pull over stop and control the vehicle in order to come to a stop within the pull over spot <NUM>. If this is not possible, for instance where no pull over spots are available, the computing devices may, if not blocking other traffic, stop the vehicle in the lane <NUM>, attempt to find another spot to stop the vehicle on a nearby street, or route the vehicle around back towards the updated destination location. Of course, routing the vehicle around the block could cause the vehicle <NUM> to loop around continuously if there is no appropriate place to stop.

However, there are many reasons why a passenger may want to exit a vehicle. For instance, the passenger may want to end a trip early (i.e. the passenger is ill or uncomfortable), to stop the vehicle momentarily to get some fresh air, to stop the vehicle to retrieve a misplaced or forgotten item (i.e. left a bag outside of the vehicle), to stop a ride which was started by mistake (i.e. someone mistakenly hit button <NUM> or <NUM>), or the passenger is attempting to get out just before the vehicle reaches the destination location.

Depending upon how far the vehicle has traveled along a route to the destination location or how far away from the destination location the vehicle is, this information may be used by the computing devices to determine where and how to stop the vehicle and allow the passenger to get out of the vehicle. In this regard, the route may be divided into stages: an early stage, a middle stage, and a late stage.

<FIG> is an example abstract representation <NUM> of these stages which provide for context aware stopping of vehicles, such as vehicle <NUM> (or vehicle 100A). In this regard, <FIG> includes markers <NUM> and <NUM> representing pickup and destination locations for a trip along a route represented by line <NUM>. The route is divided into a beginning stage between the pickup location and a first threshold distance from the pickup location represented by marker <NUM>, a middle stage between the first threshold distance and a second threshold distance from the destination location represented by marker <NUM>, and a late stage between the second threshold distance and the destination location. The late stage can be further subdivided by a marker <NUM> representing the point at which the computing devices <NUM> begin to maneuver the vehicle into a pull over spot in order to allow the passenger to exit the vehicle.

In one example, the vehicle may be in an early stage of the trip. For instance, the early stage may correspond to a time when the vehicle is located within a parking lot (i.e. not a lane of traffic), is less than a first threshold distance (in time or space) from where the passenger entered the vehicle (such as a few seconds or a few feet from the pickup location), or before the vehicle has completely pulled away from a parking spot and merged into a lane of traffic and not already blocking the flow of traffic (i.e. not stopped in a lane of traffic), and so on. In response to a signal, the computing devices may respond by stopping the vehicle immediately, or really using an appropriate and comfortable braking pattern so as not to alarm the passenger, in its current position. For example, as shown in <FIG>, a passenger may have entered vehicle <NUM> at a pickup location corresponding to the pull over spot <NUM> of <FIG>. At this point, the passenger may use button <NUM> or button <NUM> (or his or her client computing device) to indicate a desire to pull the vehicle over. In response, because the vehicle is currently still within an early stage of the trip being still located within or at least partially within the area of pull over spot <NUM>, the computing devices <NUM> may respond to the signal by simply stopping the vehicle in place.

At this point, the computing devices <NUM> may then give the passenger some time to exit and reenter the vehicle if needed. In some circumstances, the computing devices may only wait for the passenger to reenter the vehicle if the passenger leaves the door of the vehicle open. Again, this may allow the passenger time to get out, retrieve an item, and get back into the vehicle without disrupting the flow of traffic. As one example of this process, if a door of the vehicle is open, the computing devices <NUM> may wait until the door is closed by the passenger. This may be achieved by using a sensor for the door and relaying the state of the sensor to the computing devices. If the vehicle's doors are closed, and the vehicle is empty, the computing devices <NUM> may send a notification to the passenger's client computing device indicating that the vehicle will leave in some predetermined period of time (for instance, <NUM> minutes or more or less) if the passenger does not reenter the vehicle. Alternatively, if the door is closed or if the passenger is gone for an extended period of time, the passenger may be assumed to have cancelled the trip.

In addition or alternatively, the passenger may use the application to request additional time or the computing devices <NUM> may send a notification to the passenger's client computing device asking if the passenger would like to make a request for additional time. For instance, the notification may be sent as soon as the vehicle is stopped informing the passenger that the vehicle will wait for some predetermined period of time, such as <NUM> minutes or more or less. In response, the passenger may confirm, request additional time, or indicate that he or she is no longer interested in a trip (i.e. the passenger can effectively cancel the trip).

If the passenger reenters the vehicle, the computing devices may continue to maneuver the vehicle towards the destination location. If the passenger does not reenter after the predetermined period of time, a concierge, such as concierge <NUM>, may check that the passenger has not left anything in the vehicle, for instance using an audible and/or visual connection (i.e. a speaker, microphone, and or/camera). If not, the computing devices <NUM> move the vehicle to a new location, await instructions from the server computing devices <NUM>, and/or to default to some other non-passenger-serving behavior. If so, the computing devices <NUM> may also send a notification to the passenger's client computing device (either directly or via the server computing devices <NUM>) indicating that the vehicle will leave in some second predetermined period of time, such as <NUM> minutes or more or less. After that second predetermined period of time, the concierge <NUM> may check again, and as long as the passenger did not leave a living thing in the vehicle, send instructions to the computing devices <NUM> to pull away as noted above.

This first and second predetermined period of time may be adjustable based on the circumstances where the vehicle is currently stopped as well as the reason why the passenger has left the vehicle. For example, less time may be provided where there is a lot of traffic congestion, high demand for dispatching vehicles (i.e. vehicle <NUM> is needed for another trip), or if the vehicle cannot safely or lawfully remain in its current position. Similarly, if the passenger is sick, he or she may need more time as compared to when the passenger has left an item outside the vehicle. As such, as described above, the passenger may use his or her client computing device to request additional time. These predetermined periods of time may therefore be adjusted accordingly.

If the vehicle has fully merged into a lane of traffic but is more than a second threshold distance away (in time or distance) from the destination location, the vehicle may be in middle stage of the route. As an example, this second threshold distance may be <NUM> meters or <NUM> minute or more or less. For example, comparing the example of <FIG> with the example of <FIG>, in <FIG>, the vehicle <NUM> has completely pulled out of the pull over spot <NUM> and is now merged with any traffic in the lane <NUM>. In addition, a destination location for the passenger within vehicle <NUM> is greater than the second threshold distance (and thus not shown in <FIG>). In response to a signal, the computing devices may attempt to find the nearest pull over spot. At this point, computing devices <NUM> may maneuver the vehicle <NUM> to pull over into pull over spot <NUM>. Again, as noted above, the nearest pull over spot may be the nearest available spot identified from the map information. Once pulled over, the computing devices may indicate to the passenger that it is time to exit the vehicle and allow the passenger to exit the vehicle.

In order to increase the efficiency at which the computing devices are able to stop the vehicle we may even be allowed to deviate from the route in order to do so, thereby allowing the vehicle to stop on a side road if needed. Similarly, if the vehicle is currently on a high speed road, such as one with a greater than <NUM> mile per hour speed limit or a highway, the computing devices may exit that road at the first available opportunity and attempt to find a stop at a pull over spot thereafter.

Because such stops in the middle stage of a trip are more likely to be short term where the passenger is likely to return to the vehicle and resume the trip, the computing devices may attempt to find a pull over spot that would allow the vehicle to easily continue towards the destination after the passenger resumes the trip, such as by using button <NUM>, button <NUM>, or the passenger's client computing device. For instance, the computing devices may avoid pulling down a one-way street, onto a dead end road, an exit or entrance ramp, turning at an intersection, turning onto a side street that does not reconnect or takes too long to reconnect to a main thoroughfare, etc. which would increase the time to the destination by more than a minute or more or less. Again, once stopped, the vehicle may operate as in the examples above providing a passenger with notifications warning the passenger that the vehicle may leave or will be leaving in a threshold period of time.

When in this middle stage, if the computing devices are not able to pull the vehicle over within a predetermined time, such as <NUM> minutes or more or less, the computing devices may make a request to a remote assistance provide for further instructions on how to proceed.

If the vehicle is less than or within the second threshold distance from the destination location, the vehicle may be in late stage of the route. For example, as shown in <FIG>, vehicle <NUM> is approaching the destination location and is within the second threshold distance represented by line <NUM> from the destination location represented by marker <NUM>. In this stage, the response of the computing devices <NUM> to the signal from button <NUM>, button <NUM> or the passenger's client computing device may depend on whether the computing devices have already identified a pull over spot and are attempting to maneuver the vehicle into that pull over spot. If so, the computing devices may "ignore" the signal and continue to pull the vehicle into the pull over spot. If not, the computing device may change the destination to the vehicle's current location as discussed above and stop the vehicle in the closest available location to do so under the circumstances. In some cases, this may allow the computing devices to stop the vehicle immediately, of course, depending on the current circumstances of traffic, current position and orientation of the vehicle as well as safety considerations such as the speed limit of the roadway where the vehicle is currently traveling.

In other words, the response of the computing devices <NUM> with respect to the example of <FIG> will depend whether the vehicle has reached the marker <NUM> of <FIG>. For example, if in <FIG> the computing devices <NUM> have already begun to maneuver vehicle <NUM> into pull over spot <NUM> (for instance, the vehicle <NUM> is being parallel parked), the computing devices may simply continue to maneuver vehicle <NUM> into the pull over spot <NUM>. If in <FIG>, the computing devices <NUM> are not already maneuvering the vehicle <NUM> into a pull over spot, the computing devices <NUM> may respond by maneuvering vehicle <NUM> to the closest available pull over spot, here pull over spot <NUM>, or may stop within lane <NUM>, if safe to do so given speed limits for lane <NUM> and current traffic conditions.

In some instances, data from passengers using button <NUM>, button <NUM>, or his or her client computing device to pull the vehicle over during the late stage may be used to improve how the computing devices <NUM> identify the pull over location in which to stop the vehicle for future passenger pick up or drop offs. As an example, machine learning techniques could be used to generate a model which could be used to select a "best" pull over location of all available pullover locations proximate to a pickup or destination location.

All of the aforementioned physical distances may be measured along the route or actual distance from the pickup location (i.e. a straight line). For instance, the threshold distances may be defined in time or in distance, either direct (as the crow flies) or along a route the vehicle is currently following.

In some instances, if a passenger uses one of the buttons <NUM> or <NUM>, but then changes her mind, he or she may cancel the request to pull over by pressing the same button a second time or alternatively by hitting button <NUM>. To achieve this, before actually stopping the vehicle, the computing devices may wait for a predetermined grace period, such as <NUM> second or more or less, for a second signal before deviating from the route and/or actually stopping or slowing the vehicle down. This allows the passenger to cancel the request and the computing devices to continue to maneuver the vehicle to the destination location without interruption. The grace period may be implemented only in certain situations, such as where the vehicle has already pulled into a lane of traffic from the pickup location.

Where the passenger decides to use his or her mobile device to request that the vehicle pull over, the response of the computing devices may be different or the same as using the buttons <NUM>, <NUM>. For instance, if the passenger requests a stop from his or her client computing device, the passenger may also indicate whether he or she is ending the trip early or just stopping temporarily. In this regard, a request to pull over using the client computing device may surface an optional dialog in the application that asks for the reason of the stop for data collection. This data may be used to identify additional options or reasons for stopping into the application for future strips. Additionally, when the passenger uses a button in the application to request that the vehicle pull over, the image of the button may change into a "cancel pullover request" button to make it clear that pressing this button again will cancel the request. Such an operation may or may not be possible in a vehicle with physical buttons as discussed above.

The passenger may also have an option to ask for help (from remote assistance) or provide other feedback.

The responses of the computing devices <NUM> to signals from the buttons <NUM>, <NUM> must of course be weighed with safety and legal considerations such as whether the drop off is in a busy or quiet street, how disruptive to the flow of traffic stopping at particular locations would be, whether continuing to stop is a violation of a rule or law, etc..

The buttons <NUM> or <NUM> may also be used to "pause" a trip (i.e. so a passenger can grab a coffee), change a destination once in the vehicle, or to stop the vehicle in the case of an emergency. Of course, these situations are less preferred than those discussed above and may not be appropriate uses of these buttons.

Claim 1:
A method of stopping a vehicle (<NUM>) without a driver, the method comprising:
after a passenger has entered the vehicle, maneuvering (<NUM>), by one or more processors, the vehicle in an autonomous driving mode towards a destination location (<NUM>) along a route (<NUM>), the route being divided into two or more stages;
receiving (<NUM>), by the one or more processors, a signal indicating that the passenger is requesting that the vehicle stop or pull over;
in response to receiving the signal, determining (<NUM>), by the one or more processors, a current stage of the two or more stages of the route based on (<NUM>) a current distance, in time or space, of the vehicle from a pickup location (<NUM>) where the passenger entered the vehicle and/or (<NUM>) a current distance, in time or space, of the vehicle from the destination location, wherein the current stage is determined based on whether or not the vehicle is within a first threshold distance (<NUM>), in time or space, from the pickup location and/or whether or not the vehicle is within a second threshold distance (<NUM>), in time or space, from the destination location; and
stopping (<NUM>), by the one or more processors, the vehicle, wherein where and how the vehicle is stopped is determined based on the determined current stage.