Method for a vehicle, first vehicle and storage medium

Abstract

The invention provides a method, a first vehicle and a storage medium for a vehicle. Therein, techniques for estimating occupancy of a vehicle location are described. This includes receiving, by at least one processor, state information for a parking location, the state information representing availability of the parking location; predicting, by at least one processor, a future state of the parking location based on the received state information; determining, by at least one processor, a destination based on the predicted future state of the parking location; and providing, by at least one processor, the predicted future state to a controller of a vehicle to control the vehicle to drive to the destination.

Description

Technical Field

[0001] This manual relates to the occupancy of vehicle locations (e.g., parking locations). Background Technology

[0002] Parking space occupancy changes over time. Sometimes, vehicles travel to their destination without securing a parking space. Furthermore, sometimes vehicles arrive at their destination only to find available parking spaces while waiting in traffic (e.g., in a line of vehicles). This not only delays the vehicle's arrival at its destination but also forces passengers waiting to be unloaded and / or picked up to wait inside the vehicle. In some cases, nearby parking spaces will be sufficient, and the vehicle may reach its destination more quickly. Summary of the Invention

[0003] A method for a vehicle includes: receiving, using at least one processor, status information of a parking location, the status information indicating the availability of the parking location; using the at least one processor, predicting a future status of the parking location based on the received status information; using the at least one processor, determining a destination based on the predicted future status of the parking location; and using the at least one processor, providing the predicted future status to a controller of the vehicle to control the vehicle to drive to the destination.

[0004] A non-transitory computer-readable storage medium includes at least one program for execution by at least one processor of a first device, the at least one program including instructions that, when executed by the at least one processor, cause the first device to perform the method described above.

[0005] A first vehicle includes: at least one sensor configured to acquire status information about a parking location in the environment of the first vehicle; at least one computer-readable medium storing computer-executable instructions; and at least one processor communicatively coupled to the at least one sensor, the at least one processor being configured to execute the computer-executable instructions, the execution including: acquiring status information about the parking location from the at least one sensor, the status information indicating the availability of the parking location; predicting a future status of the parking location based on the acquired status information; and providing the predicted future status to a second vehicle to control the second vehicle based on the predicted future status of the parking location.

[0006] A first vehicle includes: at least one computer-readable medium storing computer-executable instructions; at least one processor configured to execute the computer-executable instructions, the execution comprising: receiving status information of a parking location from a server or a second vehicle; predicting a future status of the parking location based on the received status information; determining a destination of the first vehicle based on the predicted future status of the parking location; and a controller for controlling the first vehicle to travel to the destination based on the predicted future status of the parking location. Attached Figure Description

[0007] Figure 1 An example of an autonomous vehicle (AV) with autonomous capabilities is shown.

[0008] Figure 2 An example architecture for AV is shown.

[0009] Figure 3 Examples of inputs and outputs that a sensing system can use are shown.

[0010] Figure 4 A block diagram illustrating the relationship between the inputs and outputs of the planning system.

[0011] Figure 5 The environment of the occupancy estimation system is shown.

[0012] Figure 6 It shows vehicle acquisition and Figure 5 Status information related to the parking location within the environment.

[0013] Figure 7 Show driving to Figure 6 Vehicles parked in the environment.

[0014] Figure 8 A flowchart is shown for estimating the occupancy of parking locations.

[0015] Figure 9A and Figure 9B An alternative flowchart for estimating parking space occupancy is shown.

[0016] Figure 10 It shows the relationship with Figure 5 Mobile devices associated with the occupancy prediction system. Detailed Implementation

[0017] In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of this disclosure. However, it will be apparent that this disclosure may be practiced without these specific details. In other instances, well-known constructions and apparatuses are shown in block diagram form to avoid unnecessarily obscuring this disclosure.

[0018] In the accompanying drawings, for ease of description, a specific arrangement or order of schematic elements (such as those representing devices, modules, systems, instruction blocks, and data elements) is shown. However, those skilled in the art will understand that the specific order or arrangement of the schematic elements in the drawings is not intended to imply a requirement for a particular processing order or sequence, or a separation of processing procedures. Furthermore, the inclusion of schematic elements in the drawings is not intended to imply that such elements are required in all embodiments, nor is it intended to imply that features represented by such elements cannot be included in some embodiments or cannot be combined with other elements in some embodiments.

[0019] Furthermore, in the accompanying drawings, connecting elements, such as solid or dashed lines or arrows, are used to illustrate connections, relationships, or associations between two or more other schematic elements. The absence of any such connecting element does not imply that connections, relationships, or associations cannot exist. For example, some connections, relationships, or associations between elements are not shown in the drawings to avoid obscuring the scope of this disclosure. Additionally, for ease of illustration, a single connecting element is used to represent multiple connections, relationships, or associations between elements. For example, if a connecting element represents communication of signals, data, or instructions, those skilled in the art will understand that such an element represents one or more signal paths (e.g., a bus) that may be necessary to affect the communication.

[0020] Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following detailed description to provide a thorough understanding of the various embodiments described. However, it will be apparent to those skilled in the art that the various embodiments described can be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0021] The features described below can each be used independently of each other or in any combination with other features. However, any individual feature may not solve any of the problems discussed above, or may only solve one of the problems discussed above. Some of the problems discussed above may not be adequately solved by any of the features described herein. Although headings are provided, information relating to specific headings but not found in the sections bearing those headings can be found elsewhere in this specification. Embodiments are described herein based on the following summary:

[0022] 1. General Overview

[0023] 2. System Overview

[0024] 3. AV Architecture

[0025] 4. AV Input

[0026] 5. AV Planning

[0027] 6. Estimated occupancy

[0028] General Overview

[0029] The future state of pick-up and / or drop-off locations (e.g., occupancy, availability, and / or accessibility) can be predicted (e.g., probabilistically estimated) to improve passenger safety and comfort. For example, a first vehicle passing a parking location obtains the location's status (e.g., whether the location is available, whether it is obstructed, whether it exists, etc.) and relays this status information to a remote server or a second vehicle heading to the parking location. In this scenario, the second vehicle can determine whether changing its destination to a different parking location is necessary (e.g., the location is occupied / unavailable, blocked / inaccessible, etc.) and / or beneficial (e.g., high congestion levels near the parking location, etc.).

[0030] The occupancy prediction system improves a vehicle's contextual awareness as it approaches its destination. For example, by knowing where congestion is, the vehicle can redirect to different parking locations within walking distance of its original parking spot. This reduces the resources consumed by the vehicle that would otherwise be spent waiting for a specific parking location. Additionally, the vehicle can drop off passengers and pick up different passengers more quickly, reducing passenger wait times. This technology adapts to user preferences by requesting permission from passengers before changing parking locations. Furthermore, by eliminating the need to wait for unavailable parking locations to become available, congestion within the radius of busy parking locations is reduced, thus decreasing wait times.

[0031] System Overview

[0032] Figure 1 An example of an autonomous vehicle 100 is shown.

[0033] As used herein, the term "passenger" refers to a passenger traveling on a vehicle (e.g., being unloaded en route to a destination) and / or a passenger waiting to be picked up. In some examples, a passenger is a pedestrian or a group of pedestrians (e.g., a family, a school group, etc.).

[0034] As used herein, the term “autonomy” refers to a function, feature, or facility that enables a vehicle to operate partially or fully without real-time human intervention, including but not limited to full AV, high AV, and conditional AV.

[0035] As used in this article, an autonomous vehicle (AV) is a vehicle with autonomous capabilities.

[0036] As used in this article, "vehicle" includes any mode of transport for goods or people. Examples include cars, buses, trains, airplanes, drones, trucks, ships, vessels, submersibles, and spacecraft. Driverless cars are an example of vehicles.

[0037] As used herein, a “track” refers to a path or route that navigates an AV from a first spatiotemporal location to a second spatiotemporal location. In embodiments, the first spatiotemporal location is referred to as the initial location or starting point, and the second spatiotemporal location is referred to as the destination, final location, target, target location, or target position. In some examples, a track consists of one or more road segments (e.g., segments of a road), and each road segment consists of one or more blocks (e.g., a lane or part of an intersection). In embodiments, spatiotemporal locations correspond to real-world locations. For example, a spatiotemporal location is a pick-up or drop-off point for picking up or dropping off people or goods.

[0038] As used herein, “(one or more) sensor” includes one or more hardware components for detecting information relating to the environment surrounding the sensor. Some hardware components may include sensing components (e.g., image sensors, biometric sensors), transmission and / or receiving components (e.g., laser or radio frequency wave transmitters and receivers), electronic components (such as analog-to-digital converters), data storage devices (such as RAM and / or non-volatile memory), software or firmware components, and data processing components (such as application-specific integrated circuits), microprocessors, and / or microcontrollers.

[0039] As used herein, a “scene description” is a data structure (e.g., a list) or data stream that includes one or more classified or labeled objects detected by one or more sensors on an AV vehicle, or one or more classified or labeled objects provided by a source outside the AV.

[0040] As used in this article, a "road" is a physical area that can be traversed by vehicles and can correspond to a named passageway (e.g., a city street, an interstate highway, etc.) or an unnamed passageway (e.g., a driveway within a house or office building, a section of a parking lot, a section of an vacant parking lot, a waste disposal route in a rural area, etc.). Because some vehicles (e.g., four-wheel drive pickup trucks, SUVs, etc.) can traverse a variety of physical areas that are not particularly suitable for vehicle travel, a "road" can be any physical area that is not formally defined as a passageway by any municipality or other government or administrative agency.

[0041] As used herein, a “lane” is the portion of a road through which vehicles can pass. Sometimes lanes are identified based on lane markings. For example, a lane may correspond to most or all of the space between lane markings, or only a portion of the space between lane markings (e.g., less than 50%). For instance, a road with widely spaced lane markings may accommodate two or more vehicles, allowing one vehicle to overtake another without crossing the lane markings; therefore, this could be interpreted as a lane being narrower than the space between lane markings, or as having two lanes. Lanes can also be interpreted in the absence of lane markings. For example, a lane may be defined based on the physical characteristics of the environment (e.g., rocks and trees along a main road in a rural area, or natural obstacles that should be avoided, for example, in underdeveloped areas). Lanes can also be interpreted independently of lane markings or physical characteristics. For example, a lane may be interpreted based on any unobstructed path in an area that would otherwise lack the features that would be interpreted as lane boundaries. In the example scenario, an AV could interpret a lane as passing through an unobstructed portion of a field or open space. In another example scenario, an AV can interpret lanes that pass through a wide road (e.g., wide enough for two or more lanes) without lane markings. In this scenario, the AV can communicate lane-related information to other AVs, allowing them to coordinate route planning using the same lane information.

[0042] The term “over-the-air (OTA) client” includes any AV, or any electronic device embedded in, coupled to, or communicating with an AV (e.g., computer, controller, IoT device, electronic control unit (ECU)).

[0043] The term “over-the-air (OTA) update” means any update, alteration, deletion, or addition to software, firmware, data, or configuration settings, or any combination thereof, delivered to an OTA client using proprietary and / or standardized wireless communication technologies, including but not limited to: cellular mobile communications (e.g., 2G, 3G, 4G, 5G), radio local area networks (e.g., WiFi), and / or satellite Internet.

[0044] The term "edge node" refers to one or more edge devices coupled to a network that provide a portal for communicating with AV and can communicate with other edge nodes and cloud-based computing platforms to schedule OTA updates and deliver OTA updates to OTA clients.

[0045] The term "edge device" refers to a device that implements an edge node and provides a physical wireless access point (AP) to the core network of an enterprise or service provider (such as Verizon or AT&T). Examples of edge devices include, but are not limited to: computers, controllers, transmitters, routers, routing switches, integrated access devices (IADs), multiplexers, metropolitan area network (MAN) and wide area network (WAN) access devices.

[0046] "One or more" includes functions performed by one element, functions performed by multiple elements, such as in a distributed manner, several functions performed by one element, several functions performed by several elements, or any combination of the above.

[0047] It will also be understood that, although in some cases the terms “first,” “second,” etc., are used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of the various described embodiments, a first contact may be referred to as a second contact, and similarly, a second contact may be referred to as a first contact. Both the first contact and the second contact are contacts, but they are not the same contact.

[0048] The terminology used in the description of the various embodiments described herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used in the description of the various embodiments described and the appended claims, the singular forms “a,” “an,” and “the” are also intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that “and / or,” as used herein, refers to and includes any and all possible combinations of one or more related list items. It will also be understood that when the terms “comprising,” “including,” “possessing,” and / or “having” are used in this specification, they specifically indicate the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0049] As used herein, depending on the context, the term "if" may optionally be understood as meaning "when" or "at that time" or "in response to being determined" or "in response to being detected." Similarly, depending on the context, the phrase "if determined" or "if [the stated condition or event] has been detected" may optionally be understood as meaning "when determined" or "in response to being determined" or "when [the stated condition or event] is detected" or "in response to being detected."

[0050] As used herein, an AV system refers to an AV and an array of hardware, software, stored data, and real-time generated data that support AV operation. In embodiments, the AV system is incorporated within an AV. In embodiments, the AV system is distributed across several locations. For example, some of the software for the AV system is implemented in a cloud computing environment.

[0051] Generally, this document describes technologies applicable to any vehicle with one or more autonomous capabilities, including fully automated vehicle (AV), highly automated vehicle (AV), and conditionally automated vehicle (AV), such as so-called Level 5, Level 4, and Level 3 vehicles, respectively (see SAE International Standard J3016: Classification and Definition of Terms Related to Automated Driving Systems for Motor Vehicles on Roads, the entire contents of which are incorporated herein by reference for further details on vehicle autonomy levels). The technologies described in this document are also applicable to partially automated vehicle (AV) and driver-assisted vehicle (MAV) vehicles, such as so-called Level 2 and Level 1 vehicles (see SAE International Standard J3016: Classification and Definition of Terms Related to Automated Driving Systems for Motor Vehicles on Roads). In embodiments, one or more Level 1, Level 2, Level 3, Level 4, and Level 5 vehicle systems are capable of automatically performing certain vehicle operations (e.g., steering, braking, and map usage) under certain operating conditions based on the processing of sensor inputs. The technologies described in this document can benefit vehicles of any level, ranging from fully automated vehicle (AV) to human-operated vehicles.

[0052] AVs have advantages over vehicles that require human drivers. One advantage is safety. For example, in 2016, the U.S. experienced 6 million car accidents, 2.4 million injuries, 40,000 deaths, and 13 million vehicle collisions, with an estimated social cost of over $910 billion. From 1965 to 2015, the number of traffic fatalities per 100 million miles driven in the U.S. decreased from about 6 to about 1, partly due to additional safety features deployed in vehicles. For example, an extra half-second warning associated with an impending collision is believed to mitigate 60% of front and rear collisions. However, passive safety features (such as seat belts and airbags) may have reached their limits in improving these figures. Therefore, active safety measures, such as automated vehicle controls, are a possible next step in improving these statistics. Since human drivers are considered to be responsible for serious pre-collision events in 95% of collisions, autonomous driving systems could potentially achieve better safety outcomes by: identifying and avoiding emergencies more reliably than humans; making better decisions, obeying traffic regulations better than humans, and predicting future events better than humans; and controlling vehicles more reliably than humans.

[0053] refer to Figure 1 The AV system 120 enables the vehicle 100 to operate along a trajectory 198, traversing the environment 190 to the destination 199 (sometimes referred to as the final location), while avoiding objects (e.g., natural obstacles 191, vehicles 193, pedestrians 192, cyclists and other obstacles) and complying with road rules (e.g., operating rules or driving preferences).

[0054] In an embodiment, the AV system 120 includes means 101 for receiving and operating operating commands from and on a computer processor 146. The term "operating command" is used to refer to executable instructions (or sets of instructions) that cause the vehicle to perform actions (e.g., driving maneuvers). Operating commands may, without limitation, include instructions for causing the vehicle to begin moving forward, stop moving forward, begin moving backward, stop moving backward, accelerate, decelerate, make a left turn, and make a right turn. Examples of means 101 include a steering controller 102, a brake 103, a gearshift, an accelerator pedal or other acceleration control mechanism, a windshield wiper, side door locks, window controllers, and a turn indicator.

[0055] In an embodiment, the AV system 120 includes sensors 121 for measuring or inferring attributes of the state or condition of the vehicle 100, such as the AV's position, linear velocity and angular velocity, linear acceleration and angular acceleration, and heading (e.g., the direction of the front end of the vehicle 100). Examples of sensors 121 are GPS, inertial measurement units (IMUs) that measure both linear acceleration and angular rate of the vehicle, wheel rate sensors for measuring or estimating wheel slip ratio, wheel braking pressure or braking torque sensors, engine torque or wheel torque sensors, and steering angle and angular rate sensors.

[0056] In an embodiment, sensor 121 also includes sensors for sensing or measuring properties of the AV's environment. Examples include a monocular or stereo camera 122 with visible, infrared, or thermal (or both) spectra, a LiDAR 123, a RADAR, an ultrasonic sensor, a time-of-flight (TOF) depth sensor, a rate sensor, a temperature sensor, a humidity sensor, and a precipitation sensor.

[0057] In one embodiment, the AV system 120 includes a data storage unit 142 and a memory 144 for storing machine instructions associated with a computer processor 146 or data collected by sensors 121. In another embodiment, the data storage unit 142 and the memory 144 store historical, real-time, and / or predictive information about the environment 190. In another embodiment, the stored information includes maps, driving performance, traffic congestion updates, or weather conditions. In yet another embodiment, data related to the environment 190 is transmitted from a remote database 134 to the vehicle 100 via a communication channel.

[0058] In an embodiment, AV system 120 includes communication devices 140 for transmitting measured or inferred attributes of the state and conditions of other vehicles, such as position, linear velocity and angular velocity, linear acceleration and angular acceleration, and linear heading and angular heading, to vehicle 100. These devices include vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication devices, as well as devices for wireless communication via point-to-point or ad hoc networks, or both. In an embodiment, communication device 140 communicates across the electromagnetic spectrum (including radio and optical communications) or other media (e.g., air and acoustic media). Combinations of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) communication (and in some embodiments, one or more other types of communication) are sometimes referred to as vehicle-to-all-things (V2X) communication. V2X communication typically conforms to one or more communication standards for communication with and between AVs.

[0059] In one embodiment, the communication device 140 includes a communication interface. This may be a wired, wireless, WiMAX, Wi-Fi, Bluetooth, satellite, cellular, optical, near-field, infrared, or radio interface. The communication interface transmits data from a remote database 134 to the AV system 120. In one embodiment, the remote database 134 is embedded in a cloud computing environment. The communication device 140 transmits data collected from the sensor 121 or other data related to the operation of the vehicle 100 to the remote database 134. In another embodiment, the communication device 140 transmits information related to teleoperation to the vehicle 100. In some embodiments, the vehicle 100 communicates with other remote (e.g., "cloud") servers 136.

[0060] In this embodiment, the remote database 134 also stores and transmits digital data (e.g., data such as road and street locations). This data is stored in memory 144 on the vehicle 100 or transmitted from the remote database 134 to the vehicle 100 via a communication channel.

[0061] In one embodiment, the remote database 134 stores and transmits historical information (e.g., rate and acceleration distribution) related to driving attributes of vehicles that previously traveled along trajectory 198 at similar times of day. In one implementation, such data can be stored in memory 144 on vehicle 100 or transmitted from the remote database 134 to vehicle 100 via a communication channel.

[0062] The computer processor 146 located on the vehicle 100 generates control actions in an algorithmic manner based on both real-time sensor data and prior information, allowing the AV system 120 to perform its autonomous driving capabilities.

[0063] In one embodiment, the AV system 120 includes a computer peripheral device 132 coupled to a computer processor 146 for providing information and alerts to a user of the vehicle 100 (e.g., a passenger or a remote user) and receiving input from that user. The coupling can be wireless or wired. Any two or more interface devices can be integrated into a single device.

[0064] In one embodiment, the AV system 120 receives and enforces a passenger privacy level, such as one specified by the passenger or stored in a passenger-associated profile. The passenger privacy level determines how specific passenger-associated information (e.g., passenger comfort data, biometric data, etc.) stored in the passenger profile and / or stored on cloud server 136 and associated with the passenger profile is permitted. In one embodiment, the privacy level specifies specific passenger-associated information that is deleted once the ride is complete. In another embodiment, the privacy level specifies specific passenger-associated information and identifies one or more entities authorized to access that information. Examples of the specified entities authorized to access the information may include other AVs, third-party AV systems, or any entity that could potentially access the information.

[0065] A passenger's privacy level can be specified at one or more granular levels. In one embodiment, the privacy level identifies specific information to be stored or shared. In another embodiment, the privacy level applies to all information associated with the passenger, allowing the passenger to specify that their personal information should not be stored or shared. The designation of entities authorized to access specific information can also be specified at various granular levels. The various sets of entities authorized to access specific information may include, for example, other AVs, cloud server 136, specific third-party AV systems, etc.

[0066] In an embodiment, AV system 120 or cloud server 136 determines whether vehicle 100 or another entity can access certain information associated with a passenger. For example, a third-party AV system attempting to access passenger input related to a specific time and place must, for example, obtain authorization from AV system 120 or cloud server 136 to access passenger-associated information. For example, AV system 120 uses a specified privacy level for the passenger to determine whether passenger input related to time and place can be presented to a third-party AV system, vehicle 100, or another AV. This allows the passenger's privacy level to specify which other entities are allowed to receive data related to the passenger's actions or other data associated with the passenger.

[0067] AV architecture

[0068] Figure 2 Showing for use in AV (e.g., Figure 1 The example architecture 200 of the vehicle 100 shown is illustrated. Architecture 200 includes a sensing system 202 (sometimes referred to as a sensing circuit), a planning system 204 (sometimes referred to as a planning circuit), a control system 206 (sometimes referred to as a control circuit), a positioning system 208 (sometimes referred to as a positioning circuit), and a database system 210 (sometimes referred to as a database circuit). Each system plays a role in the operation of the vehicle 100. Commonly, systems 202, 204, 206, 208, and 210 can be... Figure 1This is a portion of the AV system 120 shown. In some embodiments, any of systems 202, 204, 206, 208, and 210 is a combination of computer software (e.g., executable code stored on a computer-readable medium) and computer hardware (e.g., one or more microprocessors, microcontrollers, application-specific integrated circuits (ASICs), hardware memory devices, other types of integrated circuits, other types of computer hardware, or any or all combinations of these hardware). Systems 202, 204, 206, 208, and 210 are each sometimes referred to as processing circuitry (e.g., computer hardware, computer software, or a combination of both). Any or all combinations of systems 202, 204, 206, 208, and 210 are also examples of processing circuitry.

[0069] In use, the planning system 204 receives data representing destination 212 and determines data representing a trajectory 214 (sometimes called a route) that the vehicle 100 can travel to reach (e.g., arrive at) destination 212. In order for the planning system 204 to determine the data representing trajectory 214, the planning system 204 receives data from the sensing system 202, the positioning system 208, and the database system 210.

[0070] The sensing system 202 uses, for example, as Figure 1 One or more sensors 121 are shown to identify nearby physical objects. The objects are classified (e.g., grouped into types such as pedestrians, bicycles, cars, traffic signs, etc.), and a scene description including the classified objects 216 is provided to the planning system 204.

[0071] The planning system 204 also receives data representing the location 218 of the AV from the positioning system 208. The positioning system 208 determines the AV location by calculating location using data from sensor 121 and data from database system 210 (e.g., geographic data). For example, the positioning system 208 uses data from GNSS (Global Navigation Satellite System) sensors and geographic data to calculate the longitude and latitude of the AV. In embodiments, the data used by the positioning system 208 includes high-precision maps with lane geometry properties, maps describing road network connectivity properties, maps describing lane physical properties (such as traffic speed, traffic volume, number of vehicle and bicycle lanes, lane width, lane traffic direction, or lane marking type and location, or combinations thereof), and maps describing the spatial locations of road features (such as pedestrian crossings, traffic signs, or various types of other traffic signals). In embodiments, the high-precision map is constructed by adding data to a low-precision map via automatic or manual annotation.

[0072] The control system 206 receives data representing trajectory 214 and data representing AV position 218, and operates the AV control functions 220a-220c (e.g., steering, throttle, braking, ignition) in a manner that will cause the vehicle 100 to travel along trajectory 214 to reach destination 212. For example, if trajectory 214 includes a left turn, the control system 206 will operate the control functions 220a-220c in such a way that the steering angle of the steering function will cause the vehicle 100 to turn left, and the throttle and braking will cause the vehicle 100 to pause and wait for passing pedestrians or vehicles before making the turn.

[0073] AV input

[0074] Figure 3 The sensing system 202 is shown. Figure 4 The inputs used are 302a-302d (e.g., Figure 1 Examples of sensor 121 and outputs 304a-304d (e.g., sensor data) are shown. One input 302a is a LiDAR (light detection and ranging) system (e.g., Figure 1 The LiDAR system shown is 123. LiDAR is a technique that uses light (e.g., a beam of light such as infrared light) to obtain data related to physical objects in its line of sight. The LiDAR system produces LiDAR data as output 304a. For example, LiDAR data is a collection of 3D or 2D points (also called point clouds) used to construct a representation of environment 190.

[0075] Another input 302b is a RADAR (radar) system. RADAR is a technology that uses radio waves to acquire data related to nearby physical objects. RADAR can acquire data related to objects that are not within the line of sight of a LiDAR system. The RADAR system generates RADAR data as output 304b. For example, RADAR data is one or more radio frequency electromagnetic signals used to construct a representation of the environment 190.

[0076] Another input 302c is a camera system. The camera system uses one or more cameras (e.g., a digital camera using a light sensor such as a charge-coupled device [CCD]) to acquire information about nearby physical objects. The camera system produces camera data as output 304c. Camera data is typically in the form of image data (e.g., data in image data formats such as RAW, JPEG, PNG, etc.). In some examples, the camera system has multiple independent cameras, for example, for stereoscopic imaging (stereoscopic vision), which enables the camera system to perceive depth. Although the objects perceived by the camera system are described here as "nearby," this is relative to the AV (view of objects). In some embodiments, the camera system is configured to "see" distant objects (e.g., objects as far as 1 kilometer or more in front of the AV). Therefore, in some embodiments, the camera system has features such as sensors and lenses optimized for perceiving distant objects.

[0077] Another input 302d is a Traffic Light Detection (TLD) system. A TLD system uses one or more cameras to acquire information related to traffic lights, street signs, and other physical objects that provide visual navigation information. The TLD system produces TLD data as output 304d. TLD data is often in the form of image data (e.g., data in image data formats such as RAW, JPEG, PNG, etc.). The difference between a TLD system and a system that includes cameras is that a TLD system uses a camera with a wide field of view (e.g., using a wide-angle lens or fisheye lens) to acquire information related to as many physical objects as possible that provide visual navigation information, enabling the vehicle 100 to access all the relevant navigation information provided by these objects. For example, the field of view of a TLD system is approximately 120 degrees or greater.

[0078] In some embodiments, sensor fusion technology is used to combine outputs 304a-304d. Thus, individual outputs 304a-304d are provided to other systems within the vehicle 100 (e.g., to systems such as...). Figure 2 The planning system 204 shown may provide combined outputs to other systems in the form of single or multiple combined outputs of the same type (e.g., using the same combination technique or combining the same outputs or both) or single or multiple combined outputs of different types (e.g., using different individual combination techniques or combining different individual outputs or both). In some embodiments, an early fusion technique is used. The early fusion technique is characterized by combining the outputs before applying one or more data processing steps to the combined outputs. In some embodiments, a late fusion technique is used. The late fusion technique is characterized by combining the outputs after applying one or more data processing steps to the individual outputs.

[0079] Path planning

[0080] Figure 4 Show (for example, as) Figure 2 The diagram 400 illustrates the relationship between the inputs and outputs of the planning system 204. Generally, the output of the planning system 204 is a route 402 from a starting point 404 (e.g., a source location or initial location) to an ending point 406 (e.g., a destination or final location). Route 402 is typically defined by one or more road segments. For example, a road segment refers to the distance to be traveled over at least a portion of a street, road, highway, driveway, or other physical area suitable for vehicle travel. In some examples, such as if the vehicle 100 is an off-road capable vehicle such as a four-wheel drive (4WD) or all-wheel drive (AWD) car, SUV, or pickup truck, route 402 includes “off-road” segments such as unpaved paths or open fields.

[0081] In addition to route 402, the planning system also outputs lane-level route planning data 408. Lane-level route planning data 408 is used to navigate segments of route 402 at specific times based on conditions. For example, if route 402 comprises a multi-lane highway, lane-level route planning data 408 includes trajectory planning data 410, which vehicle 100 can use to select a lane from the multiple lanes based on factors such as whether an exit is nearby, whether another vehicle is present in one or more of the multiple lanes, or other factors that change over a period of minutes or less. Similarly, in some implementations, lane-level route planning data 408 includes a speed constraint 412 specific to a segment of route 402. For example, if the segment includes pedestrians or unexpected traffic, speed constraint 412 can limit vehicle 100 to a slower speed than expected, such as a speed based on speed limit data for that segment.

[0082] In an embodiment, the inputs to the planning system 204 include (e.g., from...) Figure 2 The database system 210 shown contains database data 414 and current location data 416 (for example, Figure 2 The AV position 218 shown is used (for example, for AV position 218). Figure 2 The destination data 418 and object data 420 shown for destination 212 (e.g., as shown) Figure 2The perception system 202 shown perceives classified objects 216. In some embodiments, database data 414 includes rules used during planning. The rules are specified using a formal language (e.g., Boolean logic). At least some of these rules will apply to any given situation encountered by vehicle 100. A rule applies to a given situation if it has conditions satisfied based on information available to vehicle 100 (e.g., information about the surrounding environment). Rules can have priorities. For example, a rule “move to the leftmost lane if the road is a highway” can have a lower priority than “move to the rightmost lane if the exit is within a mile.”

[0083] Estimated occupancy

[0084] Figure 5 An environment 500 for an occupancy estimation system 550 is shown. Environment 500 includes vehicles 504A-504H (collectively referred to as "vehicle 504") driving on road 502. In an embodiment, vehicle 504 is compared with a reference... Figure 1 The described vehicle 100 is the same or similar. In the embodiments, any or all of the vehicle 504 is autonomous or semi-autonomous.

[0085] Environment 500 includes one or more parking areas 506A-506F (collectively referred to as "Parking Area 506"), and the parking area includes one or more parking locations 508A, 508B (collectively referred to as "Parking Location 508"). However, for the sake of brevity, Figure 5 Some parking locations 508 are not explicitly marked. A parking location 508 is a place or location where a vehicle 504 can at least temporarily stop to pick up and / or unload passengers. Sometimes, this parking location 508 is referred to as a "PuDo location" or a pick-up / unload location. In some cases, parking locations 508 are used for short-term parking (e.g., one day or one week) or long-term parking (e.g., one month or one year, typically for long-term storage of the vehicle 504). Similarly, parking area 506 is a set of parking locations 508 and defines the boundaries of the parking locations 508.

[0086] In some examples, parking area 506 includes a single parking location 508, and in other examples, parking area 506 includes more than one parking location 508 (e.g., 2-10, etc.). In most examples, parking location 508 is adjacent to road 502 (e.g., typical in an urban environment), such that vehicle 504 can reach parking location 508 and vehicles 504 passing by parking location 508 can see parking location 508. In some examples, parking area 506 is a parking lot or parking garage with many parking locations 508 (e.g., 50-100 parking locations).

[0087] In this embodiment, parking area 506 and parking location 508 are predefined and stored in a database or map and hosted by server 520. Figure 5 In the example shown, server 520 and some or all of the vehicles 504 within environment 500 are part of a vehicle network defining occupancy estimation system 550. In this example, occupancy estimation system 550 includes some or all of the vehicles 504 and server 520, enabling the vehicles 504 to communicate directly with each other and / or directly with server 520. Computational tasks described with reference to a specific vehicle 504 may also be performed by server 520 and / or other vehicles 504 within occupancy estimation system 550.

[0088] In this embodiment, map annotation processing assembles a database by generating location information for all permissible parking areas 506 and parking locations 508 within environment 500. In this context, "permissible" means that parking location 508 is available for use by vehicle 504 for at least some time of the year. In some examples, map annotation processing includes manual processing involving human annotators defining the individual parking areas 506 and parking locations 508 based on aerial satellite imagery of environment 500 and onboard LiDAR and / or camera imagery.

[0089] In some examples, parking location 508 does not include places where vehicles 504 are illegally parked (e.g., in fire zones, blocking fire hydrants, on pedestrian crossings, at intersections, blocking entrances, etc.). In this example, legal information is queried from a system associated with local zoning services (e.g., a group that maintains a list of laws, rules, and / or regulations related to vehicle movement in regions such as cities, states, etc.). The database contains location information for each parking area 506 and each parking location 508 within environment 500.

[0090] In the example, passenger 510 within environment 500 uses an app (e.g., a mobile application) on mobile device 512 to request a ride from a first location (e.g., a pick-up location) to a second location (e.g., a drop-off location). In this example, the first location is passenger 510's current location as determined by a GPS receiver within mobile device 512. Once passenger 510 requests vehicle 504 by responding to a query via the app (e.g., via a user interface of mobile device 512, such as a touchscreen), the app then causes mobile device 512 to send a request to vehicle 504 (e.g., vehicle 504A) within occupancy estimation system 550 to drive to the first location and pick up passenger 510 (e.g., via road 502). In some examples, the app causes mobile device 512 to automatically select the vehicle 504 closest to passenger 510 (e.g., specifically via instructions from one or more processors of occupancy estimation system 550 to select vehicle 504A).

[0091] In one embodiment, the App causes the mobile device 512 to display the locations of all vehicles 504 within environment 500, and enables the passenger 510 to select a specific vehicle 504A within occupancy estimation system 550 (e.g., via the user interface of the mobile device 512). In some examples, the App enables the passenger 510 to select a specific vehicle 504A based on the number of passengers 510 that the vehicle can accommodate (e.g., 1-7 passengers) or based on the luxury level of the vehicle 504 (e.g., via the user interface). In the following examples, it is assumed that occupancy estimation system 550 and / or passenger 510 have already selected vehicle 504A as vehicle 504.

[0092] In embodiments, the processor is a component of the occupancy estimation system 550. In some examples, the processor is physically part of any or all of the vehicles 504 within the mobile device 512, server 520, and / or occupancy estimation system 550. In some examples, information is partially processed by a first processor within the vehicle 504 and provided to a second processor within the server 520 to perform computational tasks. In this example, a general reference to the occupancy estimation system 550 includes performing some or all of the processing steps on any one or more of the processors within the mobile device 512, server 520, and / or vehicle 504 operating within the network of the occupancy estimation system 550.

[0093] In this embodiment, the occupancy estimation system 550 determines the closest parking location 508 to passenger 510 based on the current location of passenger 510 determined by the GPS receiver of mobile device 512. In this example, the occupancy estimation system 550 determines that a specific parking location 508A is the closest parking location 508 to passenger 510 and defines the specific parking location 508A as a pick-up location 508. Furthermore, the occupancy estimation system 550 sends information to mobile device 512, causing mobile device 512 to display an indication that the determined nearest parking location 508 is the specific parking location 508A and that passenger 510 should expect to be picked up at parking location 508A by a specific vehicle 504A. In this example, the destination of vehicle 504A is the determined pick-up location at parking location 508A.

[0094] In one embodiment, the destination of vehicle 504A is determined based on passenger 510's preferred parking location. For example, passenger 510 indicates a preference for a specific parking location 508A (and / or a specific parking area 506A). In some examples, vehicle 504A increases its tolerance for waiting time or congestion based on passenger parking location preferences to accommodate those preferences. For example, vehicle 504A may wait in traffic to reach a specific parking location 508A without changing its destination to a different parking location (e.g., parking location 508B).

[0095] While the foregoing paragraphs describe an example where parking location 508A is specifically identified / selected as the pick-up location for passenger 510, in other examples, the occupancy estimation system 550 may determine any parking location 508 within a specific parking area 506A as a pick-up location for passenger 510. In this example, the occupancy estimation system 550 determines the pick-up location for passenger 510 based on whether any parking location 508 is unavailable and / or inaccessible when the vehicle 504A arrives at the specific parking area 506A. For example, the occupancy estimation system 550 determines that parking area 506A is closest to passenger 510 and sends information to the vehicle 504A indicating that parking area 506A (and the parking locations within parking area 506A) is the closest parking area to passenger 510. Then, the occupancy estimation system 550 sends information to the mobile device 512 so that the mobile device 512 displays an indication that the identified parking area 506A and / or any parking location 508 within the parking area 506A can be a pick-up location. In this example, the passenger 510 is notified that the vehicle 504 can reach any parking location 508A within the parking area 506A.

[0096] In an embodiment, while vehicle 504A is en route to its destination, occupancy estimation system 550 continues to receive status information. In some examples, the received status information is provided or transmitted from other vehicles 504 (e.g., vehicles 504B-504H) that are driving and / or parked within environment 500. Reference is made below. Figure 6 The details of acquiring the status information are described. The occupancy estimation system 550 uses the status information to probabilistically predict or estimate whether the destination will be available and / or reachable when vehicle 504A arrives at the destination to pick up passenger 510. For example, the status information indicates whether any parking location 508A within a specific parking area 506A is available, such as whether vehicle 504 is currently parked at parking location 508A. In some examples, the status information includes the availability of parking location 508A, the reachability of parking location 508A, and / or the congestion level of the area near parking location 508A (e.g., within a 10-foot or 50-foot radius of parking location 508A). In some examples (but not explicitly shown), parking location 508A may no longer exist (e.g., from an outdated database or map). In this example, the status information is stored in a database and is queried by some or all of the vehicles 504 within the occupancy estimation system 550 to obtain the status of any parking location 508 and / or predict the future status of any parking location 508.

[0097] In an embodiment, the destination of vehicle 504A is determined based on at least one event occurring within a radius of parking location 508. For example, status information indicates at least one event within a radius (e.g., 100 feet, 500 feet, etc.) of parking location 508. In some examples, the event is (e.g., determined via a query of local news resources) a sporting event, program, concert, protest, and / or marathon. For example, unless, for example, a passenger expresses a preference for attending the event, vehicle 504A uses information about the event to select a parking location 508 that is far from the event.

[0098] In one embodiment, the destination of vehicle 504A is determined based on at least one of temperature, precipitation, wind chill, and / or humidity at parking location 508. In this embodiment, status information indicates at least one of temperature, precipitation, wind chill, and humidity at parking location 508A when vehicle 504A is expected to arrive at parking location 508A. For example, if there is a high probability of severe weather at parking location 508A (e.g., determined from a weather service database such as weather.com), a system on the vehicle (e.g., a computer processor 146 located within vehicle 504A) uses this information to select a covered parking location 508. Figure 5 (Not explicitly shown in the text).

[0099] In embodiments, one or more of the vehicles 504 within the occupancy estimation system 550 are configured to acquire status information (e.g., weather at the location and / or whether the vehicle is located at the location) regarding some or all of the parking locations 508 in the various parking areas 506 within the environment 500. In some examples, the status information is acquired by the LiDAR and / or camera system of the vehicle 504 as it drives through the environment 500 and passes a parking location 508. In some examples, the vehicle 504 acquires the status information as it drives through the environment 500 during normal driving (e.g., when it passes a parking location 508 en route from a first location to a second location). In some examples, the occupancy estimation system 550 instructs the vehicle 504 to specifically drive to a particular parking location 508 and acquire an image of that particular parking location 508. In other examples, when vehicle 504 is parked at parking location 508, status information is acquired by the LiDAR and / or camera system of vehicle 504 (e.g., to acquire status information about other parking locations 508 within the parking area 506 where vehicle 504 is parked).

[0100] In an embodiment, the occupancy estimation system 550 determines the state information of parking location 508 based on acquired LiDAR and / or camera information, predicts the future state of a specific parking location 508A based on the state information, and sends the state information and / or future state information to a database of server 520 for storage. In this context, "future state" refers to the predicted state at a specific future moment measured from when the state information is acquired by vehicle 504. In some examples, the future state is predicted over a future period of time (e.g., at least 10 minutes after the state information is acquired, or from the time the state information is acquired until the same time tomorrow). In some examples, "future state" and / or "future time" refers to the time from when the image information is acquired by vehicle 504. For example, future time refers to 10 seconds from when the image information is acquired by vehicle 504. In some examples, the future state is predicted (e.g., probabilistically predicted using a machine learning system) at several future times. For example, in some scenarios, future state refers to the predicted state at the next 10 seconds, 20 seconds, 30 seconds, 60 seconds, and 1 minute. In some examples, some or all of these predicted future states are stored in a database on server 520 for querying by vehicles 504 within the occupancy estimation system 550. In embodiments, the database stores state information and / or future state information for querying by all vehicles 504 within the occupancy estimation system 550 to determine whether a particular parking location 508 is available and / or reachable at a future time.

[0101] In this embodiment, the status information represents the current status of the accessibility of each parking location 508, and the occupancy estimation system 550 predicts the status or future status of the corresponding parking location 508 based on the current status information of the corresponding parking location 508 or adjacent parking locations 508.

[0102] Figure 6 This illustrates that the vehicle 602 acquires status information regarding one or more parking locations 610A-610C (collectively referred to as "parking locations 610") within environment 500. In an embodiment, the vehicle 602 references... Figure 5 and Figure 1 The described vehicle 504 and / or vehicle 100 are identical or similar. In an embodiment, vehicle 602 includes a LiDAR system 604. In an embodiment, the LiDAR system 604 of vehicle 602 is similar to the reference [reference document / model / etc.]. Figure 1 The LiDAR system 123 of the described vehicle 100 is the same as or similar to that of the vehicle 602. In an embodiment, the vehicle 602 includes a camera system 606. In an embodiment, the camera system 606 is similar to that of the reference vehicle 602. Figure 1 The camera system 122 of the described vehicle 100 is the same as or similar to that of the vehicle 100.

[0103] The LiDAR system 604 and / or camera system 606 include one or more sensors 620 configured to acquire status information about one or more parking locations 610 within a parking area 608 in the environment 500. In an embodiment, sensor 620 includes a thermal imaging camera to detect vehicles (e.g., Figure 6 The vehicles 622, 624 and 626 shown) and pedestrians ( Figure 6 Thermal features (not explicitly shown). For example, a thermal imaging camera acquires a thermal image and determines that the thermal features of the thermal image are higher than a threshold indicating the presence of a vehicle or pedestrian. In an embodiment, sensor 620 includes a microphone to acquire sound information and detect the sound level or audible features of vehicles and pedestrians based on the sound information. For example, the microphone system determines that the sound level is higher than a threshold indicating the presence of a vehicle or pedestrian.

[0104] like Figure 6 As shown in the example, vehicle 602 acquires status information of parking location 610 from sensor 620 of vehicle 602. In some examples, acquiring status information includes (e.g., via imaging processing) detecting one or more objects within the boundaries of parking location 610. In this context, the term "object" is a physical object that prevents or obstructs access to parking location 610 (e.g., blocks accessibility). Objects include, but are not limited to, vehicles, pedestrians, trash cans, garbage, construction cones, temporary fences, construction barriers, and packages.

[0105] The "boundary" of parking location 610 defines the permissible parking area for vehicles. The boundary of parking location 610 is retrieved from a database. In some examples, the boundary is a 3D domain taking into account the height (e.g., 10 feet) above the road surface for vehicle clearance. In some examples, occupancy estimation system 550 determines the vehicle (e.g., referring to the permissible parking area defined by the boundary of parking location 610) based on the permissible parking area defined by the boundary of parking location 610. Figure 5 The destination location of the described vehicle 504A. For example, the occupancy estimation system 550 (e.g., by receiving vehicle size information from a vehicle registry) determines that the length of the vehicle (e.g., vehicle 504A) is 10 feet, and then selects a destination location to include a parking location 610 with a length of at least 10 feet to accommodate the 10-foot vehicle length. In some examples, the occupancy estimation system 550 applies the same rationale to the width and / or length of the parking location 610. In this example, the destination location is selected by the occupancy estimation system 550 based on the physical dimensions of the parking location and the physical dimensions of the vehicle (e.g., vehicle 504A).

[0106] In some examples, image processing software from the occupancy estimation system 550 is used to detect one or more objects (e.g., image recognition or image classification is used to identify objects as vehicles or pedestrians). For example, image processing is used to identify parking meters 612 associated with parking location 610, and the location of parking meters 612 is used to confirm the location of the parking location. In this example, status information includes information about the parking meters associated with the parking location.

[0107] exist Figure 6 In the scenario shown, as the vehicle 602 drives past parking location 610, the vehicle 602 acquires status information of the three parking locations 610. Sensors 620 of the vehicle 602 acquire status information (e.g., image information and / or audible information) of at least some of the parking locations 610 in the parking area 608, and this information is processed by an occupancy estimation system 550 (e.g., using imaging processing software and / or acoustic processing software) to determine the status information of some or all of the parking locations 610 within the parking area 608.

[0108] As referenced above Figure 5As described, in some examples, as the vehicle 602 drives past each parking location 610 while traveling within environment 500, the vehicle 602 continuously acquires status information for each parking location 610. In other scenarios, the vehicle 602 is instructed by occupancy estimation system 550 to acquire status information for a specific parking area 608 and / or a specific parking location 610 within that specific parking area 608.

[0109] In embodiments, image processing is performed by an occupancy estimation system 550 (e.g., a server 520 associated with the occupancy estimation system 550). In some examples, the occupancy estimation system 550 sends a request to the vehicle 602 to obtain status information about the parking location 610. Alternatively, the occupancy estimation system 550 directly receives images, audio, and / or video, and / or status information about the parking location 610 acquired by the vehicle 602. In examples where images, audio, and / or video are received, the occupancy estimation system 550 includes image processing capabilities to detect one or more objects within the image and determine status information about the parking location 610.

[0110] In an embodiment, the occupancy estimation system 550 generates a status history of parking location 610 and stores the status history in a database. In some examples, the status history is a chronological list of the historical states of parking location 610. In some examples, the status history includes the date and time information when the status was acquired and determined. In this example, the status history represents status information and previous status information, and is a record of historical status information about parking location 610. In some examples, the database receives requests for the status of a specific parking area 608 and / or a specific parking location 610 from vehicles within the occupancy estimation system 550.

[0111] In one embodiment, the occupancy prediction system 550 predicts (e.g., probabilistically using a machine learning system) the future state of parking location 610 based on its state history. In some examples, the state history includes information about parking location 610 being occupied 98% of the time between 9:00 AM and 9:00 PM on a specific date in a year (e.g., July 4th). In this scenario, the occupancy prediction system 550 predicts that the availability of parking location 610 will be low (e.g., unlikely to be available) on that specific date next year. In other examples, the state history includes information about parking location 610 being occupied 98% of the time at 5:00 PM on weekdays during a specific month. In this scenario, the occupancy prediction system 550 predicts that the availability of parking location 610 at that specific time during a weekday in that specific month will also be low (e.g., unlikely to be available).

[0112] In some examples, the status history includes information about parking location 610 being occupied for 2% of the time between 9:00 AM and 9:00 PM on a specific date in a year (e.g., February 1st). In this scenario, the occupancy prediction system 550 predicts that the availability of parking location 610 will be high (e.g., likely available) on that specific date in the following year. In other examples, the status history includes information about parking location 610 being occupied for 5% of the time at 10:00 AM on weekdays during a specific month. In this scenario, the occupancy prediction system 550 predicts that the availability of parking location 610 will also be high (e.g., likely available) during that specific time of week in that specific month.

[0113] In some examples, the occupancy estimation system 550 predicts future states based on the state history of adjacent parking locations. For example, if (e.g., as determined by processing images and classifying construction cones or equipment, or as determined by receiving information from server 520) a parking location is a construction zone, the occupancy estimation system 550 predicts that adjacent parking locations are also in construction zones.

[0114] In an embodiment, the occupancy prediction system 550 predicts the future state of parking location 610 based on the predicted movement of detected objects. For example, consider the following scenario: Vehicle 602 drives past parking location 610 and acquires image information about the object. The occupancy prediction system 550 (e.g., via image processing) processes the image information and determines that the object is a vehicle. Vehicle 602 continuously acquires image information about vehicle 622 (e.g., two or more images per second) and continuously processes the image information to determine the movement of vehicle 622. Figure 6 In the example shown, the movement of vehicle 622 is indicated by arrow 634, and vehicle 622 may be leaving parking location 610C due to approaching parking location 610C, the movement of vehicle 622, and / or the use of turn signals. In this embodiment, the movement of vehicle 622 is represented in the status information.

[0115] In an embodiment, the occupancy prediction system 550 predicts whether the vehicle 622 will obstruct the accessibility of the parking location 610 in the future based on the movement of the vehicle 622 and / or based on the vehicle's direction of travel, speed, turn signals, etc. Similarly, in some examples, the occupancy prediction system 550 (e.g., based on the vehicle's direction of travel, speed, turn signals, etc.) determines that the movement of the vehicle indicates that the vehicle is entering the parking location 610 and may park there.

[0116] The state of the parking location at a future time represents a prediction of the future state. For example, the prediction of the future state is based on the movement of detected objects, and the predicted movement is determined based on definite movements represented in images acquired from the vehicle.

[0117] In some examples, the status information includes information about the accessibility of parking location 610 and objects obstructing its accessibility, such that the database includes information about the objects. For example, if the detected object is a pedestrian (e.g., detected via imaging processing software), the status indication stored in the database indicates that the object is a pedestrian. In another example, if the detected object is a vehicle (e.g., vehicle 622 detected via imaging processing software), the status indication stored in the database indicates that the object is a vehicle.

[0118] In the example, in environment 500, the field of view of sensor 620 is partially obstructed by vehicle 624 driving in the lane adjacent to vehicle 602. The presence of vehicle 624 affects vehicle 602's ability to accurately assess the state information of parking location 610A because some information about parking location 610A is unavailable due to the obstructed vehicle 624. In some examples, the occupancy estimation system 550 determines an obstacle when the location of the obstructed object (e.g., using 3D position information from sensor 620) is outside the boundary of the parking location. In some examples, an indication that parking location 610A is obstructed is included within the state information.

[0119] In an embodiment, occupancy prediction system 550 determines an accuracy level representing the accuracy of the state information. For example, occupancy prediction system 550 determines whether the accuracy is low or high. In some examples, occupancy prediction system 550 determines low accuracy when it cannot classify an object or has difficulty classifying an object (e.g., if occupancy prediction system 550 cannot use imaging processing to determine whether it is a vehicle or a pedestrian). In another example, occupancy prediction system 550 associates the state information with low accuracy when it determines that the location of the detected object is outside the boundary of the parking location (e.g., if the object obstructs the view of the parking location from the perspective of a vehicle). In yet another example, occupancy prediction system 550 associates the state information with low accuracy when the accuracy determined by the image classification system is below a threshold (e.g., 20%). In other examples, the occupancy prediction system 550 determines the object to be a vehicle or pedestrian using imaging processing with an accuracy above a threshold, or when the detected object's location is within the boundaries of the parking location. In some examples, the accuracy is included in the status information and stored in a database.

[0120] In one embodiment, the occupancy estimation system 550 sends a request to an additional vehicle to verify (or confirm) the status information of parking location 610 based on the first vehicle's low-accuracy determination of the parking location 610's status. In some examples, this request is based on the accuracy of the status information determined from a previous vehicle driving past parking location 610 (e.g., low accuracy from obstructed view or low accuracy from failed classification of detected objects).

[0121] Figure 7 A vehicle 702 is shown driving to a parking location 610 within environment 500. The vehicle 702 is included in an occupancy estimation system 550, and in an embodiment, is compared with a reference... Figure 5 The described vehicle is the same as or similar to the 504A. In some examples, such as Figure 5 As shown, vehicle 702 is driving to pick up passenger 510. In other examples, vehicle 702 is carrying passenger 510 and driving to a destination to unload passenger 510 and / or pick up additional passengers.

[0122] In one embodiment, the occupancy prediction system 550 predicts that vehicle 702 will arrive at its destination (e.g., parking location 610, as previously determined by the occupancy prediction system 550 and / or selected / confirmed by passenger 510) within a certain period of time (e.g., two minutes). In some examples, the occupancy prediction system 550 predicts that vehicle 702 will arrive at its destination within two minutes based on traffic congestion, speed limits, weather, and / or road availability between the current location of vehicle 702 and parking location 610. In some examples, server 520 receives traffic congestion, speed limits, weather, and / or road availability information stored in a database.

[0123] In one embodiment, occupancy estimation system 550 queries a database to retrieve the most recent state of parking area 608 and / or parking location 610. In some examples, occupancy estimation system 550 predicts the future state of parking location 610 when the vehicle 702 is expected to typically arrive at parking area 608 and / or parking location 610.

[0124] In an embodiment, when a destination is determined (e.g., before vehicle 702 picks up passengers), occupancy estimation system 550 queries a database for status information of all parking areas 608 and parking locations 610 within environment 500 and / or predicts future status information of all parking areas 608 and parking locations 610 within environment 500. In this scenario, status information is stored in the database when it is received from each vehicle within occupancy estimation system 550. In this way, each vehicle within occupancy estimation system 550 can independently obtain status information about parking areas 608 and / or parking locations 610 within environment 500, as well as all status information provided or sent to the database for storage and querying by any or all vehicles within occupancy estimation system 550. Similarly, in some cases, the occupancy prediction system 550 predicts the future state of each parking location 610 within the environment 500 within a future time range (e.g., at one-minute intervals) and stores the future state information in a database for query by any or all vehicles within the occupancy prediction system 550.

[0125] In embodiments, the occupancy estimation system 550 determines the destination of the vehicle 702 based on the predicted future state of parking area 608 and / or parking location 610. In some examples, the occupancy estimation system 550 determines the vehicle's destination based on the time when the state information is acquired. As an example, the state information is acquired ten minutes before the vehicle is predicted to arrive at the parking location. In some embodiments, the state information is used to determine the likelihood that the location will be available when the vehicle arrives. In some examples, the occupancy estimation system 550 compares the time (e.g., via a database lookup) to peak times in the area of ​​the location.

[0126] For example, 5 p.m. Eastern Time in Boston, Massachusetts, is considered peak time, and the prediction is made in part based on the premise that a parking location is unlikely to be available in Boston at 5 p.m. (e.g., low probability of availability) and / or that access to that location will be hampered by predicted traffic congestion (e.g., low probability of accessibility). In an embodiment, a low probability of availability is determined when the estimated future availability is less than a threshold (e.g., a probability of 40%, 50%, 60%, etc.). Similarly, in an embodiment, a low probability of accessibility is determined when the estimated future accessibility is less than a threshold (e.g., a probability of 40%, 50%, 60%, etc.).

[0127] In other examples, 10:00 AM Eastern Time in Boston, Massachusetts represents off-peak hours, and the prediction is made in part based on the likelihood that the parking location is available in Boston at 10:00 AM (e.g., a high probability of availability) and / or that access to the location will not be blocked by any predicted traffic (e.g., a high probability of availability). In embodiments, a high probability of availability is determined when the predicted future availability is greater than a threshold (e.g., a probability of 60%, 50%, 40%, etc.). In some cases, the threshold used to delineate between a low probability of availability and a high probability of availability is the same. Similarly, in embodiments, a high probability of availability is determined when the estimated future accessibility is greater than a threshold (e.g., a probability of 60%, 50%, 40%, etc.). In some cases, the threshold used to delineate between a low probability of accessibility and a high probability of availability is the same.

[0128] In one embodiment, a third criterion is used between a low probability of availability and / or accessibility and a high probability of availability and / or accessibility, such that the occupancy estimation system 550 predicts that a parking location will be "likely" available. In this scenario, the probabilities of accessibility and / or availability are determined when the estimated future accessibility and / or availability are greater than a threshold used to classify low probability of accessibility and / or availability and less than a threshold used to classify high probability of availability and / or availability.

[0129] In another example, occupancy prediction system 550 compares time to expected nighttime events (e.g., nightlife) in the area of ​​the location. For example, 10 p.m. Eastern Time in Miami, Florida represents nightlife, and the prediction is made in part based on the premise that the location is unlikely to be available in Miami at 10 p.m. (e.g., a low probability of availability). As another example, the destination of the vehicle is determined based on whether the time represents day or night, based on whether the sunrise or sunset time at the parking location is used.

[0130] In this embodiment, the occupancy prediction system 550 determines the vehicle's destination based on the date the status information was acquired. As an example, acquiring status information on a weekend with less traffic makes the parking location more likely to be available (e.g., high probability of availability). As another example, acquiring status information on a weekday with more traffic makes the parking location less likely to be available (e.g., low probability of availability). For example, the occupancy prediction system 550 determines whether the acquisition date is Monday through Friday and predicts that the parking location is unlikely to be available and / or reachable because traffic volume is expected (e.g., low probability of availability and / or reachability). As another example, the occupancy prediction system 550 determines whether the date is a national holiday or a local holiday and predicts that the location is likely to be available because no traffic volume is expected (e.g., high probability of availability and / or reachability).

[0131] In embodiments, the occupancy estimation system 550 determines whether to change the destination of the vehicle 702 based on future state indicating the predicted time of arrival at the destination and / or additional state information. In some examples, the additional state information represents the most recent state information of the parking location 610 (e.g., state information acquired after the initial determination of the destination). In some examples, the additional state information is used to update the future state of the parking location, and in a scenario where the updated future state indicates that the probability of the parking location being available has decreased to below a predetermined threshold (e.g., below a 20% probability), the occupancy estimation system 550 determines to change the destination to a new parking location with a higher probability than the current destination. In embodiments, the occupancy estimation system 550 determines the new destination based on walking distance from the original destination, accessibility for disabled persons, whether the new destination includes shelter covering the parking location (e.g., a parking garage), and / or based on the predicted future state of the new destination.

[0132] For example, if the destination is parking area 608, and (e.g., by a low probability of availability and / or accessibility) all three parking locations 610A-610C are predicted to be unreachable or occupied when vehicle 702 is predicted to arrive at parking area 608, then occupancy prediction system 550 will change the destination from parking area 608 to a different parking area (e.g., Figure 5 (Multiple parking areas are shown in the diagram), but are also within walking distance of parking area 608. As another example, if the destination is specifically parking location 610A (e.g., as indicated by passenger preferences) and (e.g., by a low probability of availability and / or accessibility) parking location 610A is predicted to be unreachable or occupied when vehicle 702 is predicted to arrive at parking location 610A, then occupancy prediction system 550 will change the destination from parking location 610A to a different parking location within the same parking area 608 (e.g., parking location 610B or 610C).

[0133] In an embodiment, the occupancy estimation system 550 changes the vehicle's destination based on the accuracy associated with status information. For example, when the occupancy estimation system 550 receives status information associated with low accuracy (e.g., indicating that the availability and / or reachability of a parking location cannot be accurately determined), the occupancy estimation system 550 changes the destination to a new parking location associated with the status information with higher accuracy than the current destination. In this example, if the current destination is associated with a parking location with low accuracy (e.g., 20%), but an adjacent parking location is available with higher accuracy (e.g., 40%) than the current destination, and the adjacent parking location is available and reachable, then the occupancy estimation system 550 may change the destination to the adjacent parking location.

[0134] In one embodiment, the occupancy estimation system 550 requests authorization (or permission) from a passenger (e.g., a passenger waiting to be picked up or a passenger already inside the vehicle 702) to change the destination of the vehicle 702 based on changes in the status information of the parking location 610. For example, (e.g., via a user interface on a mobile device and / or a user interface within the vehicle 702) the passenger is notified that the occupancy estimation system 550 recommends a change of destination (or, from the passenger's perspective, a change of drop-off or pick-up location) based on changes in status information (e.g., a particular parking location 610 is no longer available and / or inaccessible).

[0135] In embodiments, passengers can (e.g., using the user interface of a mobile device and / or the user interface of vehicle 702) approve or reject a proposed change of destination. For example, occupancy estimation system 550 may provide or send a request to the mobile device associated with the passenger to present a query requesting authorization on the user interface. In this example, the passenger makes a selection on the user interface, and occupancy estimation system 550 receives an indication indicating whether the passenger approves or rejects the request. In other examples, occupancy estimation system 550 sends a request to the user interface within vehicle 702 to present a query requesting authorization. Furthermore, occupancy estimation system 550 receives an indication indicating whether the passenger approves or rejects the request.

[0136] In one embodiment, the occupancy estimation system 550 changes the vehicle's destination based on requested authorization (e.g., based on approval or denial from a passenger). For example, when a passenger approves the requested change, the occupancy estimation system 550 instructs the vehicle 702 to proceed to the new destination (e.g., the new parking spot) instead of the original destination (e.g., the original parking area). In other scenarios, when a passenger denies the requested change, the occupancy estimation system 550 instructs the vehicle 702 to proceed to the original destination (e.g., the original parking spot). In some cases, the occupancy estimation system 550 instructs the vehicle 702's mobility device and / or user interface to present an alert to the passenger that increased traffic congestion and / or increased waiting times may occur if the original destination is maintained. In some cases, if the passenger maintains the original destination, the occupancy estimation system 550 increases the tolerance for waiting times (e.g., queuing at a parking spot) and / or traffic congestion.

[0137] In an embodiment, in response to receiving a rejection request, the occupancy estimation system 550 receives additional status information and determines (e.g., within a predetermined time limit such as one hour or one day) that reaching the original destination is impossible. For example, upon receiving a rejection request, the occupancy estimation system 550 (e.g., via an accident database) receives additional information such as: an accident has occurred within a radius threshold of the destination (e.g., within 500 feet of the destination) and the parking location is now temporarily unreachable for 2 hours while the accident is being cleared. In this example, the occupancy estimation system 550 overturns the rejection based on the additional status information of the parking location and informs the passenger that the road to the original destination is now closed due to an accident and that the occupancy estimation system 550 is selecting a new destination (e.g., overturning the rejection decision).

[0138] In one embodiment, in response to receiving a rejection request, the occupancy estimation system 550 receives additional state information and determines that the predicted future state of the destination has decreased below a predetermined threshold (e.g., below a 20% reachability probability). For example, regardless of receiving the rejection request, the occupancy estimation system 550 may overturn the rejection request for changing the destination and instruct the vehicle to proceed to the new destination (e.g., overturn the rejection decision). In some cases, the predetermined threshold is a user preference.

[0139] In one embodiment, in response to receiving a rejection request, the occupancy prediction system 550 receives additional status information and determines that proceeding to the original destination is unsafe. For example, upon receiving a rejection request, the occupancy prediction system 550 (e.g., via an emergency alert service or police database) receives additional information such as: disruption (e.g., unexpected gathering of crowds and / or individuals) is occurring or planned to occur when the vehicle 702 is predicted to arrive at its destination. In this example, regardless of receiving the rejection request, the occupancy prediction system 550 changes the destination to a new destination outside the affected area of ​​the disruption (e.g., overturns the rejection decision).

[0140] In one embodiment, the affected areas of the interference (e.g., affected streets, towns, blocks, etc.) are stored in a database, and the decision to reject the request to change the destination is based on the affected areas of the interference.

[0141] In an embodiment, congestion is determined by the occupancy prediction system 550 when the density of vehicles and / or pedestrians within the destination radius exceeds a threshold. For example, the occupancy prediction system 550 determines congestion if it predicts that more than 10 people will be within a 10-foot radius of the parking location at the predicted future time of the vehicle's arrival at the destination.

[0142] In some examples, additional information indicates that a power outage has occurred at the destination (e.g., from an electricity service provider), and a power outage map representing the affected area is received. In this example, occupancy estimation system 550 determines a new destination outside the affected area of ​​the power outage (e.g., as defined by an emergency alert service or the electricity service provider), and occupancy estimation system 550 changes the destination to the new destination (e.g., overturns the rejection decision) regardless of receiving a rejection request.

[0143] In one embodiment, after the occupancy estimation system 550 receives updated status information about the destination and / or before the occupancy estimation system 550 rejects the request to change the destination, a second recommendation is provided to the passenger. The occupancy estimation system 550 then receives the passenger's response. In some examples, the destination is changed in response to the passenger's response to the recommendation.

[0144] In one embodiment, vehicle 702 includes a controller for controlling vehicle 702 to drive to its destination based on a predicted future state of its parking location. Similarly, other vehicles within the occupancy estimation system 550 include controllers for controlling their respective vehicles.

[0145] In one embodiment, the occupancy estimation system 550 instructs the second vehicle to drive to and park at the destination of vehicle 702. For example, it instructs the second vehicle to remain at the destination (e.g., occupy the destination so that other vehicles do not remain parked) until vehicle 702 arrives at the destination. In this example, the second vehicle maintains the parking location of vehicle 702. In this example, the second vehicle is controlled to drive to the destination.

[0146] In one embodiment, the occupancy estimation system 550 determines, based on predicted future states and / or passenger preferences, to instruct the second vehicle to hold a parking location for other vehicles. For example, the occupancy estimation system 550 (e.g., based on updated state information) determines that a parking location will be unavailable when vehicle 702 is predicted to arrive at its destination. In this example, the occupancy estimation system 550 determines that vehicle 702 is scheduled to arrive at its destination within 1 minute. However, the occupancy estimation system 550 also knows that the second vehicle is about to pass through the destination. In this example, because the occupancy estimation system 550 maintains a database of all locations and routes for all vehicles within environment 500, the occupancy estimation system 550 knows that the second vehicle is about to pass through the destination. In this example, the occupancy estimation system 550 queries the database to determine that the second vehicle will pass through the destination within 1 minute (e.g., before the first vehicle is scheduled to arrive at its destination). In this example, the occupancy estimation system 550 instructs the second vehicle to hold a parking location at the destination until vehicle 702 arrives.

[0147] In this way, the occupancy estimation system 550 can determine whether to reserve parking spaces for other vehicles based on the proximity of other vehicles in the environment to the destination, the routes of each vehicle within the occupancy estimation system 550, historical demand for parking spaces, and passenger preferences of each vehicle's passengers. For example, if a high-demand parking space becomes available, the occupancy estimation system 550 instructs a second vehicle to reserve a parking space for the first vehicle.

[0148] Figure 8 A flowchart illustrating a process 800 for estimating parking location occupancy is shown. For example, process 800 can be referenced... Figure 1 The described vehicle 100 has one or more computer processors 146, references. Figure 5 Server 520 described, reference Figure 5 The described mobile device 512 or generally referenced Figures 5 to 7 The described occupancy estimation system 550 is used for execution.

[0149] In some embodiments, status information of the parking location is received (box 802). For example, status information is received from server 520 and / or other vehicles.

[0150] In embodiments, status information is acquired from at least one camera on a vehicle (e.g., a vehicle identical or similar to vehicle 100). For example, the status information is acquired and sent to a server and / or other vehicles. In some examples, status information is acquired from at least one LiDAR system on the vehicle. In some examples, the status information includes information about objects (e.g., pedestrians or vehicles) obstructing the accessibility of the parking location. In some examples, the status information includes information about parking meters associated with the parking location.

[0151] In some embodiments, the future state of the parking location is predicted (box 804). For example, the future state of the parking location can be predicted based on received state information. For example, the destination is determined (806) based on the predicted future state of the parking location. In some examples, the destination is the parking location, and in other examples, the vehicle selects another parking location.

[0152] In one embodiment, the predicted future state is provided (box 808) to a controller of the vehicle for controlling the vehicle to drive to its destination. For example, the vehicle receives an instruction to continue to the determined destination. In some examples, it is determined whether to change the vehicle's destination.

[0153] In this embodiment, server 520 performs some or all of the calculations of occupancy estimation system 550. For example, a first vehicle (e.g., when driving past a parking location) acquires the status information of the parking location and sends the status information to server 520. In this example, server 520 predicts the future status of the parking location and determines whether to update (e.g., the destination of the first or second vehicle) based on the predicted future status of the parking location. In this example, server 520 then sends the future status information and / or a request to change the destination to either the first or second vehicle. In this way, one vehicle can provide status information available to other vehicles within occupancy estimation system 550, and instructions for controlling the second vehicle are provided to the second vehicle by server 520.

[0154] In this embodiment, some or all of the occupancy prediction system 550's calculations are performed at the vehicle level. For example, a first vehicle (e.g., when driving past a parking location) acquires the parking location's status information and sends it directly to a second vehicle. In this example, the second vehicle predicts the parking location's future state and determines whether to update the destination based on the predicted future state. In this example, the second vehicle then controls itself based on the predicted future state of the parking location.

[0155] Figure 9A and Figure 9B An alternative flowchart illustrating process 900 for estimating parking site occupancy is shown. Process 900 illustrates the processing performed at passenger level 902, vehicle level 904, and server level 906. (Refer to the above...) Figure 5 The processing described above, performed at server level 906, is typically implemented by server 520, but in some cases by the vehicle itself or by other vehicles within the vehicle network occupying the estimation system 550. Therefore, processing 900 can be referenced... Figure 1 The described vehicle 100 has one or more computer processors 146, references. Figure 5 Server 520 described, reference Figure 5 The described mobile device 512 or generally referenced Figures 5 to 7 The described occupancy estimation system 550 is used for execution. In this way, processing 900 represents an example implementation of the calculation steps performed by the occupancy estimation system 550, but other implementations are used in other examples.

[0156] refer to Figure 9AA passenger (e.g., via an app on a passenger's mobile device such as mobile device 512) requests (902A) a vehicle (e.g., vehicle 504A) to pick up the passenger (e.g., passenger 510) at a pick-up location. The vehicle receives (904A) the passenger's request via a server (e.g., server 520) that communicates with some or all of the vehicles within the occupancy estimation system 550. The passenger can select a drop-off location (e.g., destination) via the app.

[0157] Upon receiving a request from a passenger (904A), the vehicle then drives (e.g., autonomously or semi-autonomously) to the pick-up location and picks up (904B) the passenger (e.g., allows) them to enter the vehicle. In some examples, the vehicle stops at the parking location for a certain period of time (e.g., ten minutes and / or twenty minutes, etc.) until the passenger enters the vehicle (e.g., the passenger indicates to the vehicle that they have entered the vehicle via an app on their mobile device). In some examples, the vehicle detects the presence of the passenger within the vehicle via one or more passenger detection sensors within the vehicle. The vehicle then drives to the selected and / or preferred destination (e.g., the drop-off location from the passenger's perspective). As previously referenced Figure 1 In some examples, the vehicle is an autonomous vehicle, and the vehicle controls itself at least partially to drive to its destination with little or no human driver assistance. In other examples, the vehicle requires a driver to drive it to its destination.

[0158] When a destination is selected, Server 906 predicts (906A) that the parking location is likely to be available when the vehicle is predicted to reach the destination (e.g., the parking location is predicted to be open with an 80% probability by a probabilistic prediction model) and is also likely to be reachable (e.g., the parking location is predicted to have low traffic, no events, and no severe weather with an 80% probability by a probabilistic prediction model). In this way, Server 906 predicts (906A) that the parking location is likely to be both available and reachable when the vehicle is predicted to reach the destination.

[0159] Subsequently, the second vehicle (906B) drives towards the destination and acquires new / additional state information about the parking location at the destination. The second vehicle sends the additional state information to server 906, which updates its future state predictions based on the additional state information from the second vehicle. Therefore, server 906 now predicts (906C) that the destination is predicted to be open with 75% certainty when the vehicle is predicted to reach the destination (e.g., via a probabilistic prediction model). In the depicted example, when the second vehicle acquires the state information, a limited field of view is noted (e.g., possibly due to an object obstructing part of the field of view). In this way, availability can be determined based on information about the field of view of the vehicle acquiring state information related to the parking location.

[0160] Server 906 predicts (906C) that the parking location is still likely to be reachable based on the prediction that traffic congestion is low, no events are planned to occur within the radius of the parking location, and no severe weather is predicted. In this way, server 906 predicts that the parking location (906C) is likely to be available and reachable when the vehicle is predicted to reach its destination, but the probability of the parking location being available has been reduced compared to the initial prediction 906A.

[0161] In the example scenario, a vehicle carrying passengers is stuck in a traffic jam (904B), or there is usually traffic congestion while driving to its destination, causing the vehicle to slow down below a predetermined speed threshold. In some examples, the vehicle is determined to be "stuck in a traffic jam" when its speed decreases below a predetermined speed limit of the road the vehicle is currently driving on. In some examples, a database maintains a list of speed limits, and the vehicle receives speed limit information. For example, when the vehicle's speed decreases to 10 MPH below the speed limit (e.g., 25 MPH if the speed limit for a particular road is 35 MPH), the vehicle determines that there is traffic congestion. Then, in this case, when the vehicle (e.g., via the vehicle's GPS or the vehicle's speed sensor) determines that the vehicle's speed is 24 MPH, the vehicle determines that there is at least some traffic congestion and sends (906D) traffic information and an indication of the vehicle's position in traffic to server 520. In this way, the vehicle determines whether there is traffic congestion (or is "stuck in traffic") based on the vehicle's speed and the speed limit information of the road it is currently traversing.

[0162] For example, traffic congestion can be determined based on the presence of other vehicles around (or within) the vehicle and the vehicle's speed. In this example, a vehicle is determined to be congested if (e.g., via LiDAR sensors or cameras on the vehicle or adjacent vehicles) indicates that other vehicles are to its left, right, in front of, and / or behind it, and the vehicle's speed is below a threshold speed. In some examples, traffic congestion is determined based on the density of vehicles around the vehicle (e.g., 10 vehicles within a 20-foot radius indicate traffic congestion).

[0163] Server 906 receives sent information 906D about traffic congestion from the vehicle and searches for alternative routes the vehicle can take to reach its destination. For example, server 906 compares traffic information on other roads in environment 500. In some examples, the traffic congestion information is known to server 906 because it is stored in a database, retrieved from a map server, or retrieved from vehicles currently driving within environment 500. In embodiments, server 906 instructs the vehicle to change its route based on status information. For example, it controls the vehicle to change its route from its original route to a new route and controls the vehicle to follow the new route.

[0164] When a vehicle becomes stuck in traffic congestion, a third vehicle (or a second vehicle) drives (906E) past the destination and acquires status information about the parking location. The third vehicle sends the status information to server 906, which updates its future status predictions based on the updated status information from the third vehicle. Therefore, server 906 now predicts (906F) that the parking location is "likely" available when the vehicle is predicted to reach the destination (e.g., open with a 45% probability determined by a probabilistic prediction model). When the third vehicle acquires the status information, no obstacles are noticed (e.g., possibly because the parking location is fully visible from the third vehicle's perspective). Server 906 now predicts (906F) that the parking location is "likely" reachable (e.g., reachable with a 45% probability determined by a probabilistic prediction model) based on the prediction that traffic congestion is moderate, no events are planned to occur within the radius of the parking location, and no severe weather is predicted. In this way, the 906F server predicts that the parking location will be "likely" available and "likely" reachable when the vehicle is predicted to reach its destination.

[0165] refer to Figure 9BIn the depicted example, server 520 determines that the availability of a parking location has dropped below a threshold (e.g., a predetermined threshold with a 50% probability). In this scenario, when the probability of parking location availability drops below 50%, server 906 determines that the vehicle's destination should be changed. In an embodiment, occupancy prediction system 550 changes the vehicle's destination based on traffic congestion information. For example, if there is traffic congestion along a route and occupancy prediction system 550 determines that an alternative route can be taken but a change of parking location to an adjacent parking location is necessary, then occupancy prediction system 550 changes the parking location. Similarly, in some cases, occupancy prediction system 550 changes parking areas for the same or similar reasons.

[0166] In one embodiment, server 906 determines that the vehicle's destination should be changed based on reachability information, including traffic congestion, scheduled events, and weather. For example, server 906 (e.g., via an app on the passenger's mobile device or via the vehicle's own user interface) sends a request (902B) to the passenger to notify them of the recommended destination change. This request informs the passenger that the vehicle recommends changing the destination to a different one (e.g., changing the destination from a first parking location to a different parking location) and requests (902C) the passenger's approval for the destination change.

[0167] In the scenario shown, the passenger refuses (902D) the request to change the destination. The refusal request is sent (902E) to server 520, and server 520 maintains the original destination. Simultaneously, the fourth vehicle (or the second or third vehicle) drives (906G) past the destination's parking location, obtains status information, and sends the status information to server 520. Server 520 then updates the future status of the parking location based on the updated status information from the fourth vehicle.

[0168] Therefore, server 906 now predicts (906H) that the parking location is unlikely to be available based on a 20% probability (e.g., through a probabilistic prediction model). Regardless of this low availability, server 906 still predicts (906H) that the parking location is likely to be reachable based on the prediction that traffic congestion is moderate, no events are planned to occur, and no severe weather is predicted. This means that while the vehicle may be able to reach the destination, the destination is unlikely to be available. However, because the destination is not predicted to be available, server 906 determines that the vehicle should not attempt to drive to the destination and may waste time. In this scenario, the availability of the parking location decreases below a threshold (e.g., a 25% probability), causing server 520 to overturn the passenger's decision and instruct (904D) the vehicle to proceed to a new destination with a higher probability of availability and reachability relative to the current destination. Server 520 notifies the passenger of this change (902F).

[0169] Figure 10 A mobile device 1000 associated with an occupancy estimation system 550 is shown. In an embodiment, the mobile device 1000 is associated with a reference... Figure 5 The described mobile device 512 is similar to or identical to it. Mobile device 1000 is included within the occupancy estimation system 550. Mobile device 1000 includes a touchscreen display or user interface 1002 that displays the road 1004 of the environment 500 and the parking area and / or parking location 1006 of the environment 500. Figure 10 In the example shown, each circle 1006 represents a different parking location 1006. In other examples, each circle 1006 represents a parking area, and a set of parking locations within a parking area can be viewed / selected by the passenger by pressing the corresponding parking area on the user interface 1002. In some embodiments, the App configuration defines whether the parking area is displayed on the App and can be selected by the passenger.

[0170] In the embodiment, the passenger is a reference Figure 5 The passenger 510 is described. In some examples, the passenger loads an app on mobile device 1000 to request a vehicle to pick them up at a pick-up location. In some examples, mobile device 1000 (e.g., using a GPS receiver within the mobile device) determines its location. In the scenario where the location is determined, mobile device 1000 displays a location marker 1008 representing its location on a map of environment 500. In this way, the location of mobile device 1000 acts as a proxy for the passenger's location.

[0171] In an embodiment, occupancy estimation system 550 sends information to mobile device 1000 indicating a request 1010 to a passenger, allowing the passenger to select a pick-up location from which a vehicle will pick them up. In some examples, occupancy estimation system 550 sends information to an app to suggest a parking location 1012 within the passenger's walking distance (e.g., less than 1000 feet). In some examples, the suggested parking location 1012 is determined based on predicted availability and / or accessibility status information of all parking locations within environment 500. In some examples, the suggested parking location 1012 is determined based on status information and / or stored future status information stored in a database of server 520. In some examples, [the process is similar to the above reference]. Figures 5 to 9B The recommended parking location is determined by the same or similar way as the described destination.

[0172] In one embodiment, the occupancy estimation system 550 sends information indicating that walking path 1014 is displayed on the user interface 1002 to the mobile device 1000. In some examples, the occupancy estimation system 550 determines walking path 1014 based on the location of the sidewalk, crosswalk, accessibility for disabled persons, and / or determines whether the walking path involves indoor or outdoor travel. In some examples, the occupancy estimation system 550 determines the distance of walking path 1014 and displays (820) the distance information on the user interface 1002.

[0173] In some examples, walking route 1014 is based on passenger preferences (e.g., the passenger indicates to the app that walking is not preferred). In examples where walking is not preferred, occupancy prediction system 550 will recommend changing to a parking location closer to the passenger (e.g., parking location 1016), even if the parking location is predicted to be unavailable when the vehicle is predicted to arrive. In this scenario, the tolerance for increased wait time for the parking location to become available is increased (e.g., the vehicle will wait in a line of vehicles to arrive at the parking location). For example, user interface 1002 receives indication of pick-up location preferences from the passenger. For example, the passenger (e.g., by pressing or selecting via user interface 1002) indicates that the passenger would prefer a specific pick-up location from the vehicle. Thus, the pick-up location is based on the received pick-up location preference. In other examples, the passenger's destination preference (e.g., drop-off location) is selected by the passenger, and the vehicle's destination is based on the received destination preference.

[0174] In one embodiment, the occupancy estimation system 550 sends information to the mobile device 1000 indicating that indications 1018A-1018A (typically indication 1018) of the predicted future state (e.g., availability and / or accessibility) of one or more parking locations are displayed on the user interface 1002 along with the location of the corresponding parking location. For example, the occupancy estimation system 550 automatically determines the predicted future state based on selecting the nearest available vehicle to pick up the passenger and predicting when that vehicle will arrive at one or more parking locations within the passenger's radius (e.g., within a 500-foot radius). For example, assuming a vehicle, the occupancy estimation system 550 determines the predicted availability and accessibility of the various parking locations visible on the mobile device's user interface.

[0175] In an embodiment, indication 1018 indicates whether a parking location is predicted to be empty (1018A, e.g., likely available and / or reachable), active (1018B, e.g., possibly available and / or reachable), or congested (1018C, e.g., unlikely to be available and / or reachable). In some examples, an empty prediction 1018A is used to indicate that the probability of a parking location being available and / or reachable is higher than a first threshold (e.g., higher than 60%). In some examples, an active prediction 1018B is used to indicate that the probability of a parking location being available and / or reachable is higher than a second threshold and lower than the first threshold (e.g., between 30% and 60%). In some examples, a congested prediction 1018C is used to indicate that the probability of a parking location being available and / or reachable is lower than a second threshold (e.g., lower than 30%). In other examples, whether each parking location is safe is also determined by the occupancy estimation system 550 and displayed on the user interface 1002.

[0176] In this manner, the occupancy estimation system 550 sends information indicating a corresponding indication of the predicted future state of additional parking locations (e.g., not just suggested parking locations) to the mobile device 1000 for display on the user interface 1002. In some examples, the indication 1018 is displayed in color (e.g., red, yellow, or green) based on whether the predicted future state of the parking location is available and / or accessible (e.g., unlikely to be available, possibly available, and very likely to be available, respectively). In some examples, the indication varies in terms of marker shape, marker size, marker line width, and / or marker color based on the predicted availability and / or accessibility represented by the future state.

[0177] In the preceding description, embodiments of the invention have been described with reference to numerous specific details, which may vary from implementation to implementation. Therefore, the specification and drawings should be considered illustrative rather than restrictive. The sole and exclusive indication of the scope of the invention, and what the applicant expects to be the scope of the invention, is the literal and equivalent scope of the claims published from this application in the specific form of the claims, including any subsequent amendments. Any definitions of terms expressly set forth herein for inclusion in such claims should be taken as meaning as such terms are used in the claims. Furthermore, when the term “comprising” is used in the preceding specification or appended claims, what follows that phrase may be an additional step or entity, or a sub-step / sub-entity of a previously stated step or entity.

Claims

1. A method for a vehicle, comprising: Using at least one processor, the status information of the parking location of the vehicle is received, the status information indicating the availability of the parking location; Using the at least one processor, the future state of the parking location or the parking area when the vehicle is predicted to arrive at the parking location or the parking area associated with the parking location is predicted based on the received state information; Using the at least one processor, the destination of the vehicle is determined based on the predicted future state of the parking location or the parking area; as well as Using the at least one processor, the predicted future state of the parking location or parking area and the destination are sent to the controller of the vehicle to control the vehicle to drive to the destination. Determining the destination of the vehicle includes: judging whether the destination of the vehicle needs to be changed. The determination of whether to change the destination of the vehicle includes: requesting authorization from passengers or waiting passengers to change the destination of the vehicle. The determination of whether to change the destination of the vehicle includes at least one of the following: To change the destination of the vehicle based on the requested authorization from the passenger or the waiting passenger; and The vehicle's destination is changed based on additional status information of the parking location to overturn a request for authorization from the passenger or the waiting passenger.

2. The method of claim 1, wherein, The status information includes at least one of the following: information about the accessibility of the parking location, the congestion level of the area near the parking location, and information about the parking meter associated with the parking location.

3. The method according to claim 1 or 2, further comprising: The status history of the parking location is generated based on the received status information and previously received status information.

4. The method according to claim 3, wherein, Predicting the future state of the parking location includes: The future state is predicted based on the state history of the parking location.

5. The method according to claim 1 or 2, wherein, Predicting the future state of the parking location includes: The future state is predicted based on the state history of adjacent parking locations.

6. The method according to claim 1 or 2, further comprising: The accuracy of receiving and associating the received status information. The determination of the destination of the vehicle is based on the accuracy associated with the received status information.

7. The method according to claim 1 or 2, wherein, Receiving the status information includes: The status information is acquired from at least one camera.

8. The method according to claim 1 or 2, wherein, Determining the destination of the vehicle includes: The following information is provided, which can be used by the user interface to display an indication of the predicted future state of the parking location and a corresponding indication of the predicted future state of additional parking locations.

9. The method according to claim 8, further comprising: Receive destination location preferences provided at the user interface; as well as The destination of the vehicle is changed based on the received destination location preference.

10. The method according to claim 1 or 2, wherein, The status information indicates at least one event that occurred within the radius of the parking location, and The determination of the destination of the vehicle is based on at least one event that occurs within the radius of the parking location.

11. The method according to claim 1 or 2, wherein, The status information indicates at least one of the following at the parking location when the vehicle is expected to arrive at the parking location: temperature, precipitation, wind chill, and humidity. The destination of the vehicle is determined based on at least one of the temperature, precipitation, wind chill, and humidity at the parking location.

12. The method according to claim 1 or 2, wherein, The destination of the vehicle is determined based on the time when the status information is acquired.

13. The method according to claim 12, wherein, The destination of the vehicle is determined based on the sunrise or sunset time at the parking location and whether the acquisition time represents daytime or nighttime.

14. The method according to claim 1 or 2, wherein, The destination of the vehicle is determined based on the date the status information was acquired.

15. The method according to claim 1 or 2, wherein, The predicted future state corresponds to the state at least ten minutes after the state information is acquired.

16. The method according to claim 1 or 2, wherein, The vehicle is a first vehicle, and receives the status information from a second vehicle.

17. The method according to claim 1 or 2, wherein, Providing the predicted future state to the controller of the vehicle includes: Control the vehicle to drive to the destination.

18. The method according to claim 1 or 2, wherein, The vehicle is a first vehicle, and the method further includes: Instructions are given to the second vehicle to drive to the destination and remain there until the first vehicle arrives at the destination.

19. The method of claim 18, further comprising at least one of the following: Determine whether to provide the instruction to the second vehicle based on historical demand at the parking location; and Whether to provide the instructions to the second vehicle is determined based on passenger preferences for the parking location.

20. The method according to claim 1 or 2, wherein, The destination of the vehicle is determined based on the preferred parking location of the passenger or waiting passenger.

21. A non-transitory computer-readable storage medium comprising at least one program for execution by at least one processor of a first device, the at least one program comprising instructions that, when executed by the at least one processor, cause the first device to perform the method according to any one of claims 1 to 20.

22. A first vehicle, comprising: At least one computer-readable medium storing computer-executable instructions; At least one processor is configured to execute the computer-executable instructions, the execution including the following operations: Receive the status information of the parking location of the first vehicle from the server or the second vehicle. Based on the received state information, predict the future state of the parking location or the parking area when the first vehicle is predicted to arrive at the parking location or the parking area associated with the parking location. The destination of the first vehicle is determined based on the predicted future state of the parking location or the parking area; and A controller is configured to control the first vehicle to travel to the destination based on a predicted future state of the parking location or the parking area. Determining the destination of the first vehicle includes: judging whether to change the destination of the first vehicle. The determination of whether to change the destination of the first vehicle includes: requesting authorization from passengers or waiting passengers to change the destination of the first vehicle. The determination of whether to change the destination of the first vehicle includes at least one of the following: The destination of the first vehicle shall be changed based on the requested authorization from the passenger or the waiting passenger; and The request for authorization from the passenger or the waiting passenger is overturned based on additional status information of the parking location, and the destination of the first vehicle is changed based on the overturned refusal.

23. A computer program product comprising a program that causes a computer to perform the method according to any one of claims 1 to 20.

Images