Patent Application
20240144127
Services that operate, manage, and/or serve as dispatchers for multiple vehicles exist to support many applications. For example, a vehicle service provider may operate vehicles that pick up and deliver packages, that pick up and deliver restaurant orders, and/or that provide ride sharing or taxi services to human riders. In some cases, the vehicles that a single service provider manages may have multiple assigned purposes. The assigned purposes may vary from vehicle to vehicle, or even by time of day or tenant assignment for a single vehicle.
This document describes methods and systems that are directed to addressing the problems described above, and/or other issues.
At least some of the problems associated with the existing solutions will be shown solved by the subject matter of the independent claims that are included in this document. Additional advantageous aspects are discussed in the dependent claims. In various embodiments, this document describes a method of managing a group of objects such as vehicles to serve multiple partners. The method includes, for each of a plurality of partners, assigning a respective primary fleet of objects (such as vehicles) to that partner, in which each primary fleet comprises: (a) a service level requirement comprising a minimum number of objects that must be available for that primary fleet; and (b) a set of parameters governing operation of each object that is assigned to that primary fleet. The method also requires maintaining a common fleet of vehicles, from which vehicles or other objects may be temporarily assigned to one of the primary fleets.
When the system receives, from a first partner of the plurality of partners, a first task request (such as a trip request), then in response to the common fleet having a number of objects that equals or exceeds total unfulfilled service level requirements for all of the primary fleets, the system will select an object from the common fleet and assign the selected object to the primary fleet of the first partner. The system will then cause the selected object to fulfill the first task request in accordance with the set of parameters governing operation of each object that is assigned to the primary fleet of the first partner.
The methods described above may be embodied in a system including a processor and memory containing programming instructions that, when executed, will cause the processor to implement the actions described above. Various embodiments also include a computer program product that contains such programming instructions, and a memory containing the computer program product.
The accompanying drawings are incorporated into this document and form a part of the specification.
This document describes system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations of any of the above, for dynamically allocating fleets of vehicles to multiple tenants. The system is described by way of example using fleets of vehicles and ride service requests. However, the method and systems can be used, and are applicable, to allocate other types of task requests to vehicles, as well as task requests to other objects that may be assigned to a fleet. All such applications are intended to be included in this disclosure.
Current methods and systems for managing groups of vehicles are inefficient. For example, some services assign a dedicated fleet of vehicles to a single tenant for a given period of time. This static allocation can result in inefficient vehicle use, as some vehicles may remain idle during times that the tenant has a low usage requirement, and a dedicated fleet may not include enough vehicles to handle a tenant's requirements during periods of high demand. In addition, vehicles of a dedicated fleet may need to travel a relatively long distance when they switch from one assignment to another. This results in more energy usage, adds to traffic congestion, and increases vehicle wear and maintenance requirements.
As an alternative to static allocation of a dedicated fleet of vehicles to a single tenant, some services simply maintain a common, “universal” fleet of vehicles, in which all vehicles that service a given area are pooled and shared by multiple tenants. The universal fleet approach also has disadvantages. For example, it risks unintended sharing of information between tenants, as some data about a first tenant's trip (such as the drop-off location) may be exposed to a second tenant for whom the vehicle will perform its next assignment. This is in part because all vehicles share the same fleet, and authorizations for each vehicle are typically configured at the fleet level. It also can inhibit the fleet's ability to implement certain tenant-specific use cases, such as a tenant requirement that vehicles assigned to it not be operated in certain areas where competitors operate, or that a minimum number of vehicles be dedicated to the tenant's fleet at any given time.
This document describes methods and systems in which a service provider system dynamically allocates fleets of vehicles to various partners. The dynamic allocation methods described in this document can address the issues described above, as well as other issues.
As used in this document, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. Unless defined otherwise, all technical and scientific terms used in this document have the same meanings as commonly understood by one of ordinary skill in the art. As used in this document, the term “comprising” means “including, but not limited to.”
In this document, the term “vehicle” refers to any moving form of conveyance that is capable of carrying either one or more human occupants and/or cargo and is powered by any form of energy. The term “vehicle” includes, but is not limited to, cars, trucks, vans, trains, autonomous vehicles, aircraft, aerial drones and the like. An “autonomous vehicle” (or “AV”) is a vehicle having a processor, programming instructions and drivetrain components that are controllable by the processor without requiring a human operator. An autonomous vehicle may be fully autonomous in that it does not require a human operator for most or all driving conditions and functions, or it may be semi-autonomous in that a human operator may be required in certain conditions or for certain operations, or that a human operator may override the vehicle's autonomous system and may take control of the vehicle.
While this document may describe various examples in the context of an AV, the present solution is not limited to AV applications. The present solution of dynamically allocating fleets of objects to tenants may be used in other applications, with fleets of objects such as robotic systems, manufacturing process equipment, or other items.
In this document, the terms “service provider system” and “service provider” refer to a system or entity that manages operation of a fleet of vehicles or other objects. The service provider system will include a memory, programming instructions, optional monitoring equipment such as GPS systems or other data, and communication equipment that enables the system to receive information from, and send instructions to, the vehicles or other objects that the system manages.
In this document the terms “tenant” and “partner” interchangeably refer to an entity that generates task requests for a group of objects (such as trip requests for vehicles) and sends the task requests to a service provider, and to whom a fleet may be assigned. For example, in the context of vehicles, a tenant may be a ride sharing service that submits trip requests for passengers, a grocery store or retailer that submits package pickup and delivery requests, or a subset of a larger entity such as a luggage transport service team of an airport operator.
In this document the term “fleet” refers to a finite, identifiable group of vehicles or other objects. For example, a fleet may be identified as those vehicles for whom a data set is maintained. The data set will include a vehicle identification number (VIN) or another unique identifier for each vehicle in the fleet.
Each fleet's data set may include or otherwise be associated with one or more vehicle configuration parameters that specify, limit, and/or regulate the operating behavior of vehicles that are assigned to the fleet. Configuration parameters may include, for example: (1) authorizations, and in particular which partners will receive telemetry data and other data (such as trip notifications) from the vehicles in the fleet; (2) geographical networking (GeoNet) instructions, such as lanes that vehicles in the fleet must follow when moving; and (3) map zones, such as boundaries within which a vehicle's operation is permitted or from which the vehicle's operation is restricted when assigned to the fleet, or boundaries that are associated with different operational parameter values (such as maximum speed or minimum following distance). Some configuration parameters may be time-dependent and/or cyclical, and therefore may vary based on factors such as: (a) traffic volume as received from a traffic service; (b) whether or not the time of the vehicle's trip is during a designated rush hour period; (c) anticipated demand increases at certain locations at certain times (such as the time that bars are scheduled to close, or the end time of a sporting or other entertainment event).
The tenant client device(s) 102 can be used by employees or other users of the tenants to send requests 122 for accessing services 156 supported by server(s) 106 of the service provider system 118 and/or for receiving responses 124 from the service provider system 118. The communications between tenant client device(s) 102 and services 156 can be facilitated via tenant application programming interfaces (APIs) 162. A separate tenant API can be provided for each tenant to allow for scalability for any number of tenants to be integrated into the system 100. In addition, one or more service provider client device(s) 134 can be used by employees or other users of the service to send requests 122 for accessing services 156 supported by server(s) 106 of the service provider system 118 and/or for receiving responses 124 from the service provider system 118.
The communications between service provider client device(s) 134 and services 156 can be facilitated via client API(s) 164. A separate client API can be provided for each client of the service provider to allow for scalability for any number service provider clients to be integrated into the system 100. The responses 124 can include, but are not limited to, resources generated by the server(s) 106 (for example, reports, data analytics, map data and/or other information) and/or resources 172 stored in a datastore 128 (for example, as map data, vehicle status information, and/or other information).
Various types of services 156 that may be provided by the service provider will be discussed in detail below. The services provided to client devices 102, 134 can include, for example, providing vehicles in response to ride service or delivery service requests, as well as providing current status and/or historical log information of all vehicle runs that the fleet performed or is performing for that tenant. In addition to service provider client devices 134, optionally the service provider system 118 may include one or more administrator client devices 138, which are service provider devices that are operated by individuals or systems having a higher level of authorization to perform functions that client devices operated by other users 150 may not be permitted to do (such as authorize client devices, as will be discussed below).
The service provider system 118 comprises an API 126 configured to facilitate assignment of permissions 142 and access management for the services 156. In this regard, API 126 comprises an identity and access management (IAM) module 136. IAM module 136 is configured to: (i) facilitate limitation and expansion of tenant permissions for requesting and/or accessing services and/or resources based on tenant identifiers, metropolitan identifiers and/or fleet identifiers; and (ii) ensure that IAM operations are consistent across all services 156.
Permissions can be assigned by an administrator using an administrator device 138 to each client device operated by a tenant 114 and/or each user 150 of a client device 134 of the service provider system 118. An API user interface 140 may be displayed on the administrator device 138 to facilitate the management of permissions 142 for tenants 114 and internal users 150. The permissions 142 are: fine grained enough to specify access down to the tenants, metropolitan area, fleets and/or users; flexible enough that a tenant 1141 can be given permissions to a subset of resource(s) 158 of other tenant(s) 114N; exposed in web authentication tokens to facilitate instant access by all services 156; and structured in a queryable format. The structure of the permissions will be discussed in detail below.
The service provider system 118 also may receive information from and/or send information to one or more external services via network 104. Example services include a traffic service 176 that supplies real-time, historic and/or predicted future traffic data and a weather service 178 that supplies real-time, historic and/or predicted future weather data for any of the geographic areas 1601 . . . 160N.
Various elements of the system described above may communicate with each other via one or more networks 104. Network 104 may include one or more wired or wireless networks. For example, the network 104 may include a cellular network (for example, a long-term evolution (LTE) network, a code division multiple access (CDMA) network, a 3G network, a 4G network, a 5G network, another type of next generation network, etc.). The network 104 may also include a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (for example, the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, and/or the like, and/or a combination of these or other types of networks.
At 202 the system will assign, to each of the partners, a respective primary fleet of vehicles. The assignment of a fleet to a partner generates or updates a data set that includes the vehicle identification codes for each vehicle in the partner's assigned fleet.
An example of this is shown in
Returning to
When assigning each primary fleet to a partner at 202, the system will associate each partner's primary fleet with, or store information indicating that each partner's primary fleet is associated with: (i) a service level requirement, which is a minimum number of vehicles that must be available for that partner at the time of allocation; and (ii) a set of parameters governing operation of each vehicle that is assigned to that partner's primary fleet. The system may maintain a database with this information, in which each partner's service level requirements and operational parameters are stored in the database. The number of vehicles assigned to a partner's primary fleet at 202 may be at least the minimum number of vehicles in the service level requirement. Alternatively, the number of vehicles initially assigned to a partner's primary fleet at 202 may be a smaller number, or even zero, so long as the system maintains a number of vehicles in the common fleet that is at least equal to the sum of the first partner's unfulfilled service level requirement plus the total of all partners' unfulfilled service level requirements.
This document may use the term “service level requirement,” “service level commitment,” “service level agreement,” or “SLA” for short, to refer to the number of vehicles that the service provider is required to be available for a partner's primary fleet. SLAs may vary for a given partner based on time of day, day of the week, and the like. For example, a partner may require a higher service level commitment during its business operating hours but no commitment when it is closed. The partner also may have higher SLA requirements at “peak” times corresponding to its typical busiest times, as compared to times when the partner typically is less busy. Also, in this document, the phrase “unfulfilled service level requirement” of a partner refers to a number of vehicles that the partner's service level requirement demands, but which are not yet specifically assigned to the first partner's primary fleet.
At 203 the system receives a service request (such as a trip request) from one of the partners. We will identify this partner as a “first partner” for purposes of this discussion. Optionally, as a first step at 204, the system may determine whether it can validate the request by examining the request to determine whether or not parameters of the request are consistent with certain identified conditions of service. For example, validation may require that the system confirm that: (i) the partner presents a proper authorization credential to the system; (ii) the service request includes for a starting point and ending point that are both within the system's map or other inventory of serviceable locations; (iii) the request will be completed within the fleet's designated operating hours; (iv) the service request does not exceed a capacity (number of passengers and/or weight or volume of goods) of available vehicles; and/or (v) one or more other conditions have been satisfied. If the request does not satisfy one or more of the validation conditions (204: NO), then the system may reject the request at 215.
If the request is valid, then optionally, if the first partner's primary fleet already has vehicles assigned to it, at 206 the system may determine whether any vehicle that is assigned the first partner's primary fleet can fulfill the request. If a vehicle in the first partner's primary fleet can fulfill the request (206: YES), then at 205 the system will transmit information to that vehicle that will cause the vehicle to fulfill the first trip request.
However, there may be many reasons why the first partner's primary fleet cannot fulfill the trip request. For example, if the first partner's primary fleet is empty at the time of the request, or if all of the first partner's primary fleet's vehicles are in service and will continue to serve other requests when the trip request is needed, then at 207 the system may determine whether it can assign a vehicle from the common fleet, or a vehicle from another partner's fleet, to the first partner's primary fleet.
The determination at 207 will depend on whether enough vehicles remain in the common fleet to satisfy all unfulfilled SLA commitments. If the number of vehicles remaining in the common fleet exceed unfulfilled SLA commitments, then the SLA commitments will support permit assigning vehicle from the common fleet (207: YES), and at 208 the system may assign a vehicle from the common fleet to the first partner's primary fleet, and it may assign the trip to the vehicle by transmitting information to that vehicle that will cause the vehicle to fulfill the first trip request. This is shown by way of example in
If at 207 the system determines that the number of vehicles remaining in the common fleet does not meet unfulfilled SLA commitments, but one or more other partner fleets has more vehicles allocated to it than that partner's SLA requires, then the SLA commitments will support assigning vehicle from the other partner's fleet (207: YES). Then, at 208 the system may assign a vehicle from the other partner's fleet to the first partner's primary fleet, and it may assign the trip to the vehicle by transmitting information to that vehicle that will cause the vehicle to fulfill the first trip request. This is also shown by way of example in
Returning to
After the assigned vehicle completes the trip request, then at 209 the system may determine whether to remove the vehicle from the first partner's primary fleet and return it to the common fleet. The system may employ various factors and/or rules when making this decision. For example, if the number of vehicles in the first partner's primary fleet exceeds the SLA commitment to the first partner at the time, then at 211 the system may reassign the vehicle to the common fleet. This is illustrated by way of example in
In some embodiments, the rules may require reassignment of each vehicle to the common fleet as soon as it fulfills a trip request (or, for other objects, as soon as it completes an assigned task). Otherwise, if the rules to do not require reassignment (209: NO), then at 210 the system may keep the vehicle in the primary fleet to which it is assigned until a rule triggers reassignment (209: YES).
Dynamic reallocation may occur in multiple directions, among multiple primary fleets in a concurrent manner. For example,
Some vehicles in a common fleet may not be appropriate for all applications. For example, vehicles that support ride sharing tenants may not be designed to support delivery of large packages. Similarly, package delivery trucks may not have sufficient passenger seating to support ride sharing services. Therefore, in some embodiments, the common fleet of vehicles may include various fleet subgroups, in which each fleet subgroup is associated with a class and includes vehicles that are designated to perform services for that class. This is illustrated by example in
In operation, the service provider may need to handle multiple, competing trip requests from multiple partners. This can create conflict if the system can only fulfill one of the requests, but not both of them, without violating SLA commitments. For example, referring to
The one or more factors compared at 604 may include one or more of the following:
Optionally, the system may permit a tenant to enter or otherwise provide data that, when considered in view of factors such as those listed above, will adjust the tenant's priority, whether on an assigned fleet basis or on a ride-specific basis. For example, some tenants may offer individual end users a premium pricing tier, or some tenants may generally pay for a premium level of service. In these situations, the tenant may offer a higher bid with a ride service request, which will result in that ride service request receiving a higher priority in the analysis of 604.
Various embodiments may include other variations of the processes described above. For example, the system may automatically identify or modify SLA requirements for a given partner at one or more periods of time. By way of example, if, over time, the system determines that a first partner submits requests at a frequency that is below a threshold (and that most or all other partners typically exceed the threshold), then the system may apply a minimum SLA to the first partner until the system has completed a number of service requests equal to the minimum SLA for that partner. This will help to ensure that vehicles or other objects are available for the first partner, even if other partners are more frequent users of the vehicles or other objects that the service manages.
In other embodiments, the system may move vehicles or other objects between fleets based on their geographic location. For example, if a vehicle assigned to a first tenant's primary fleet has a destination that is within the typical service area of a second tenant's primary fleet, upon completion of that vehicle's run the system may reassign that vehicle from the first tenant's fleet to the second tenant's fleet. (This is illustrated by way of example in
In some embodiments, the system may dynamically alter SLAs for one or more partners or for categories of partners, based on one or more external factors. For example, if a large public event such as a sporting event, theater event, concert, or other activity is expected to attract a large group of attendees, and if the system receives notice of the event's expected end time, then the system may increase the minimum SLA for one or more partners who are associated with the ride sharing service category, in anticipation of ride sharing service partners receiving a relatively higher volume of trip requests at the event when the event ends.
In some embodiments, the system may assign fleets to one or more virtual or “phantom” partners. A virtual partner is not associated with a particular entity, but instead is a virtual entity to which the system assigns a fleet that will be used for other purposes. For example, the system may assign vehicles to virtual partners and fulfill virtual trip requests for those partners in which the trip requests end at certain specified destinations. In this way, the system may pre-position vehicles in certain geographic areas in anticipation of expected demand in or near those areas, such as in an area where a highly attended event is expected to end, as described above.
Referring again to
As shown in
Operational parameter sensors that are common to both types of vehicles include, for example: a position sensor 736 such as an accelerometer, gyroscope and/or inertial measurement unit; a speed sensor 738; and an odometer sensor 740. The vehicle also may have a clock 742 that the system uses to determine vehicle time during operation. The clock 742 may be encoded into the vehicle on-board computing device, it may be a separate device, or multiple clocks may be available.
The vehicle also may include various sensors that operate to gather information about the environment in which the vehicle is traveling. These sensors may include, for example: a location sensor 760 (such as a Global Positioning System (“GPS”) device); object detection sensors such as one or more cameras 762; and/or a lidar system 764; and/or a radar and/or sonar system 766. The sensors also may include environmental sensors 768 such as a precipitation sensor and/or ambient temperature sensor. The object detection sensors may enable the vehicle to detect objects that are within a given distance range of the vehicle in any direction, while the environmental sensors collect data about environmental conditions within the vehicle's area of travel.
During operations, information is communicated from the sensors to a vehicle on-board computing device 720. The on-board computing device 720 may be implemented using the computer system of
Geographic location information may be communicated from the location sensor 760 to the on-board computing device 720, which may then access a map of the environment that corresponds to the location information to determine known fixed features of the environment such as streets, buildings, stop signs and/or stop/go signals. Captured images from the cameras 762 and/or object detection information captured from sensors such as lidar system 764 is communicated from those sensors) to the on-board computing device 720. The object detection information and/or captured images are processed by the on-board computing device 720 to detect objects in proximity to the vehicle. Any known or to be known technique for making an object detection based on sensor data and/or captured images can be used in the embodiments disclosed in this document.
Lidar information is communicated from lidar system 764 to the on-board computing device 720. Additionally, captured images are communicated from the camera(s) 762 to the vehicle on-board computing device 720. The lidar information and/or captured images are processed by the vehicle on-board computing device 720 to detect objects in proximity to the vehicle. The manner in which the object detections are made by the vehicle on-board computing device 720 includes such capabilities detailed in this disclosure.
In addition, the system architecture 700 may include an onboard display device 754 that may generate and output an interface on which sensor data, vehicle status information, or outputs generated by the processes described in this document are displayed to an occupant of the vehicle. The display device may include, or a separate device may be, an audio speaker that presents such information in audio format.
The on-board computing device 720 may include and/or may be in communication with a routing controller 732 that generates a navigation route from a start position to a destination position for an autonomous vehicle. The routing controller 732 may access a map data store to identify possible routes and road segments that a vehicle can travel on to get from the start position to the destination position. The routing controller 732 may score the possible routes and identify a preferred route to reach the destination. For example, the routing controller 732 may generate a navigation route that minimizes Euclidean distance traveled or other cost function during the route, and it may further access the traffic information and/or estimates that can affect an amount of time it will take to travel on a particular route. Depending on implementation, the routing controller 732 may generate one or more routes using various routing methods, such as Dijkstra's algorithm, Bellman-Ford algorithm, or other algorithms. The routing controller 732 may also use the traffic information to generate a navigation route that reflects expected conditions of the route (e.g., current day of the week or current time of day, etc.), such that a route generated for travel during rush-hour may differ from a route generated for travel late at night. The routing controller 732 may also generate more than one navigation route to a destination and send more than one of these navigation routes to a user for selection by the user from among various possible routes.
In various embodiments, the on-board computing device 720 may determine perception information of the surrounding environment of the vehicle. Based on the sensor data provided by one or more sensors and location information that is obtained, the on-board computing device 720 may determine perception information of the surrounding environment of the vehicle. The perception information may represent what an ordinary driver would perceive in the surrounding environment of a vehicle. The perception data may include information relating to one or more objects in the environment of the vehicle. For example, the on-board computing device 720 may process sensor data (e.g., lidar or radar data, camera images, etc.) in order to identify objects and/or features in the environment of the vehicle. The objects may include traffic signals, roadway boundaries, other vehicles, pedestrians, and/or obstacles, etc. The on-board computing device 720 may use any now or hereafter known object recognition algorithms, video tracking algorithms, and computer vision algorithms (e.g., track objects frame-to-frame iteratively over a number of time periods) to determine the perception.
In some embodiments, the on-board computing device 720 may also determine, for one or more identified objects in the environment, the current state of the object. The state information may include, without limitation, for each object: current location; current speed and/or acceleration, current heading; current pose; current shape, size, or footprint; type (for example: vehicle, pedestrian, bicycle, static object or obstacle); and/or other state information.
The on-board computing device 720 may perform one or more prediction and/or forecasting operations. For example, the on-board computing device 720 may predict future locations, trajectories, and/or actions of one or more objects. For example, the on-board computing device 720 may predict the future locations, trajectories, and/or actions of the objects based at least in part on perception information (e.g., the state data for each object comprising an estimated shape and pose determined as discussed below), location information, sensor data, and/or any other data that describes the past and/or current state of the objects, the vehicle, the surrounding environment, and/or their relationship(s). For example, if an object is a vehicle and the current driving environment includes an intersection, the on-board computing device 720 may predict whether the object will likely move straight forward or make a turn. If the perception data indicates that the intersection has no traffic light, the on-board computing device 720 may also predict whether the vehicle may have to fully stop prior to entering the intersection.
In various embodiments, the on-board computing device 720 may determine a motion plan for the autonomous vehicle. For example, the on-board computing device 720 may determine a motion plan for the autonomous vehicle based on the perception data and/or the prediction data. Specifically, given predictions about the future locations of proximate objects and other perception data, the on-board computing device 720 can determine a motion plan for the vehicle that best navigates the autonomous vehicle relative to the objects at their future locations.
In some embodiments, the on-board computing device 720 may receive predictions and make a decision regarding how to handle objects and/or actors in the environment of the vehicle. For example, for a particular actor (e.g., a vehicle with a given speed, direction, turning angle, etc.), the on-board computing device 720 decides whether to overtake, yield, stop, and/or pass based on, for example, traffic conditions, map data, state of the autonomous vehicle, etc. Furthermore, the on-board computing device 720 also plans a path for the vehicle to travel on a given route, as well as driving parameters (e.g., distance, speed, and/or turning angle). That is, for a given object, the on-board computing device 720 decides what to do with the object and determines how to do it. For example, for a given object, the on-board computing device 720 may decide to pass the object and may determine whether to pass on the left side or right side of the object (including motion parameters such as speed). The on-board computing device 720 may also assess the risk of a collision between a detected object and the vehicle. If the risk exceeds an acceptable threshold, it may determine whether the collision can be avoided if the autonomous vehicle follows a defined vehicle trajectory and/or implements one or more dynamically generated emergency maneuvers is performed in a time period (e.g., N milliseconds). If the collision can be avoided, then the on-board computing device 720 may execute one or more control instructions to perform a cautious maneuver (e.g., mildly slow down, accelerate, change lane, or swerve). In contrast, if the collision cannot be avoided, then the on-board computing device 720 may execute one or more control instructions for execution of an emergency maneuver (e.g., brake and/or change direction of travel).
As discussed above, planning and control data regarding the movement of the autonomous vehicle is generated for execution. The on-board computing device 720 may, for example, control braking via a brake controller; direction via a steering controller; speed and acceleration via a throttle controller (in a gas-powered vehicle) or a motor speed controller (such as a current level controller in an electric vehicle); a differential gear controller (in vehicles with transmissions); and/or other controllers.
Various embodiments described above can be implemented, for example, using one or more computer systems, such as the server 106 of service provider system 118 shown in
Computer system 800 includes one or more processors (also called central processing units, or CPUs), such as a processor 804. Processor 804 is connected to a communication infrastructure or bus 802. Optionally, one or more of the processors 804 may each be a graphics processing unit (GPU). In an embodiment, a GPU is a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.
Computer system 800 also includes user input/output device(s) 816, such as monitors, keyboards, pointing devices, etc., that communicate with communication infrastructure 802 through user input/output interface(s) 808.
Computer system 800 also includes a main or primary memory 806, such as random access memory (RAM). Main memory 806 may include one or more levels of cache. Main memory 806 has stored therein control logic (i.e., computer software) and/or data.
Computer system 800 may also include one or more secondary storage devices or memory 810. Secondary memory 810 may include, for example, a hard disk drive 812 and/or a removable storage device or drive 814. Removable storage drive 814 may be an external hard drive, a universal serial bus (USB) drive, a memory card such as a compact flash card or secure digital memory, a floppy disk drive, a magnetic tape drive, a compact disc drive, an optical storage device, a tape backup device, and/or any other storage device/drive.
Removable storage drive 814 may interact with a removable storage unit 818. Removable storage unit 818 includes a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 818 may be an external hard drive, a universal serial bus (USB) drive, a memory card such as a compact flash card or secure digital memory, a floppy disk, a magnetic tape, a compact disc, a DVD, an optical storage disk, and/any other computer data storage device. Removable storage drive 814 reads from and/or writes to removable storage unit 818 in a well-known manner.
According to an example embodiment, secondary memory 810 may include other means, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 800. Such means, instrumentalities or other approaches may include, for example, a removable storage unit 822 and an interface 820. Examples of the removable storage unit 822 and the interface 820 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.
Computer system 800 may further include a communication or network interface 824. Communication interface 824 enables computer system 800 to communicate and interact with any combination of remote devices, remote networks, remote entities, etc. (individually and collectively referenced by reference number 828). For example, communication interface 824 may allow computer system 800 to communicate with remote devices 828 over communications path 826, which may be wired and/or wireless, and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 800 via communication path 826.
In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon is also referred to in this document as a computer program product or program storage device. This includes, but is not limited to, computer system 800, main memory 806, secondary memory 810, and removable storage units 818 and 822, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 800), causes such data processing devices to operate as described in this document.
Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown in
Terms that are relevant to this disclosure include:
An “electronic device” or a “computing device” refers to a device that includes a processor and memory. Each device may have its own processor and/or memory, or the processor and/or memory may be shared with other devices as in a virtual machine or container arrangement. The memory will contain or receive programming instructions that, when executed by the processor, cause the electronic device to perform one or more operations according to the programming instructions.
The terms “memory,” “memory device,” “data store,” “data storage facility” and the like each refer to a non-transitory device on which computer-readable data, programming instructions or both are stored. Except where specifically stated otherwise, the terms “memory,” “memory device,” “data store,” “data storage facility” and the like are intended to include single device embodiments, embodiments in which multiple memory devices together or collectively store a set of data or instructions, as well as individual sectors within such devices. A computer program product is a memory device with programming instructions stored on it.
The terms “processor” and “processing device” refer to a hardware component of an electronic device that is configured to execute programming instructions. Except where specifically stated otherwise, the singular term “processor” or “processing device” is intended to include both single-processing device embodiments and embodiments in which multiple processing devices, which may be components of a single device or components of separate devices, together or collectively perform a process.
The term “vehicle” refers to any moving form of conveyance that is capable of carrying either one or more human occupants and/or cargo and is powered by any form of energy. The term “vehicle” includes, but is not limited to, cars, trucks, vans, trains, autonomous vehicles, aircraft, aerial drones and the like. An “autonomous vehicle” (or “AV”) is a vehicle having a processor, programming instructions and drivetrain components that are controllable by the processor without requiring a human operator. An autonomous vehicle may be fully autonomous in that it does not require a human operator for most or all driving conditions and functions, or it may be semi-autonomous in that a human operator may be required in certain conditions or for certain operations, or that a human operator may override the vehicle's autonomous system and may take control of the vehicle.
A “run” of a vehicle refers to an act of operating a vehicle and causing the vehicle to move about the real world. A run may occur in public, uncontrolled environments such as city or suburban streets, highways, or open roads. A run may also occur in a controlled environment such as a test track.
In this document, the terms “communication link” and “communication path” mean a wired or wireless path via which a first device sends communication signals to and/or receives communication signals from one or more other devices. Devices are “communicatively connected” if the devices are able to send and/or receive data via a communication link. “Electronic communication” refers to the transmission of data via one or more signals between two or more electronic devices, whether through a wired or wireless network, and whether directly or indirectly via one or more intermediary devices. The term “wireless communication” refers to communication between two devices in which at least a portion of the communication path includes a signal that is transmitted wirelessly, but it does not necessarily require that the entire communication path be wireless.
In this document, the terms “street,” “lane,” “road” and “intersection” are illustrated by way of example with vehicles traveling on one or more roads. However, the embodiments are intended to include lanes and intersections in other locations, such as parking areas. In addition, for autonomous vehicles that are designed to be used indoors (such as automated picking devices in warehouses), a street may be a corridor of the warehouse and a lane may be a portion of the corridor. If the autonomous vehicle is a drone or other aircraft, the term “street” or “road” may represent an airway and a lane may be a portion of the airway. If the autonomous vehicle is a watercraft, then the term “street” or “road” may represent a waterway and a lane may be a portion of the waterway.
In this document, when terms such as “first” and “second” are used to modify a noun, such use is simply intended to distinguish one item from another, and is not intended to require a sequential order unless specifically stated. In addition, terms of relative position such as “vertical” and “horizontal”, or “front” and “rear”, when used, are intended to be relative to each other and need not be absolute, and only refer to one possible position of the device associated with those terms depending on the device's orientation.
It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.
While this disclosure describes example embodiments for example fields and applications, it should be understood that the disclosure is not limited to the disclosed examples. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described in this document. Further, embodiments (whether or not explicitly described) have significant utility to fields and applications beyond the examples described in this document.
Embodiments have been described in this document with the aid of functional building blocks illustrating the implementation of specified functions and relationships. The boundaries of these functional building blocks have been arbitrarily defined in this document for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or their equivalents) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described in in this document.
The features from different embodiments disclosed herein may be freely combined. For example, one or more features from a method embodiment may be combined with any of the system or product embodiments. Similarly, features from a system or product embodiment may be combined with any of the method embodiments herein disclosed.
References in this document to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described in this document.
The breadth and scope of this disclosure should not be limited by any of the above-described example embodiments, but should be defined only in accordance with the following claims and their equivalents.
As described above, this document discloses system, method, and computer program product embodiments for managing groups of vehicles. The system embodiments include a processor and a memory with programming instructions. The computer program embodiments include programming instructions, e.g., stored in a memory, to cause a processor to perform the data management methods described in this document. The system embodiments also include a processor which is configured to perform the methods described in this document, e.g., via the programming instructions. More generally, the system embodiments include a system comprising means to perform the steps of the any of the methods described in this document.
Without excluding further possible embodiments, certain example embodiments are summarized in the following clauses:
