Distributed vehicle routing

Abstract

Techniques described herein relate to controlling and / or influencing routes driven by vehicles (autonomous or other vehicles, e.g., vehicles in a fleet managed by a fleet management system). In some cases, the techniques described herein involve centrally generating road weights using a remote system, such as a fleet management system, and providing these pre-calculated weights to vehicles to simplify on-board routing. In contrast to sending a large amount of raw traffic, road conditions, and other data to each vehicle, the remote system pre-processes the data into compressed road weights that are optimized for route planning. The architecture provides various technical advantages, such as reduced data transmission, reduced computational load on the vehicle, and decentralized control of route planning of the entire fleet.

Description

Cross-reference to related applications

[0001] This application claims priority to U.S. non-provisional application No. 18 / 478,698, filed on September 29, 2023, entitled “DISTRIBUTED VEHICLE ROUTEPLANNING,” the entire disclosure of which is incorporated herein by reference. Background Technology

[0002] Vehicles (autonomous or other vehicles) can utilize route planning techniques to determine driving routes from their current location to their desired destination within an environment. For convoys of associated vehicles, this route planning technique can be performed independently by the vehicle itself and / or by an off-vehicle fleet routing service configured to determine and provide driving routes to vehicles in the convoy. In either case, determining safe and efficient driving routes to get vehicles to their destinations can be challenging, especially when guiding vehicles through complex, congested, and dynamic driving environments. Attached Figure Description

[0003] The specific embodiments are described with reference to the accompanying drawings. In the drawings, the leftmost number(s) of the reference numerals identify the drawing in which that reference numeral first appears. The same reference numerals are used in different drawings to indicate similar or identical components or features.

[0004] Figure 1 Example environments are depicted that can be used for route planning for fleets to perform various driving trips in the environment.

[0005] Figure 2 A data flow diagram of an example architecture for route planning for a fleet to perform various driving trips in an environment is provided.

[0006] Figure 3 This is a flowchart of an example process for determining the weights of roads using a computer system (e.g., a fleet management system) that is located away from the vehicle's computing devices.

[0007] Figure 4 This is a flowchart illustrating an example process for managing ride requests using a fleet management system.

[0008] Figure 5 Block diagrams are depicted for example systems used to implement the various techniques described in this paper. Detailed Implementation

[0009] The techniques described herein relate to controlling and / or influencing routes driven by vehicles (autonomous vehicles or other vehicles, such as vehicles in a fleet managed by a fleet management system). In some cases, the techniques described herein involve using a remote system, such as a fleet management system, to centrally generate road weights and provide these pre-computed weights to the vehicles to simplify onboard route planning. Instead of sending large amounts of raw traffic, road condition, and other data to each vehicle, the remote system preprocesses the data into compressed road weights optimized for route planning. This architecture offers various technical advantages, such as reduced data transmission, reduced computational load on vehicles, and centralized control over route planning for the entire fleet. This decentralized control can provide flexibility to vehicles, for example, by allowing vehicles in the fleet to deviate from their originally planned routes if certain other or unforeseen events affect their driving. The generated road weights can reflect the expected travel time on each road, determined based on factors such as traffic and / or road conditions.

[0010] In some cases, the techniques described herein involve generating weights for roads (e.g., road segments) by a remote system. The remote system can be a system located remotely from the vehicle and / or vehicle computing devices, enabling the remote system to interact with the vehicle and / or vehicle computing devices using a network. In some cases, the remote system is a cloud computing platform, for example, a cloud computing platform executing software associated with a fleet management system. In some cases, the remote system includes a fleet management system.

[0011] In some cases, the remote system generates road weights based on at least one of the following: traffic data associated with the road, road condition data associated with the road (e.g., whether the road is open or closed, the current traffic direction or speed limit associated with that section of the road, etc.), and fleet density data associated with the road. In some cases, the road weights at least partially represent or indirectly relate to the expected travel time associated with the road. Therefore, the remote system can use at least one of the traffic data, road condition data, or fleet density data to infer the expected travel time on different roads. The remote system can then use the travel time inference to determine the weights associated with the roads.

[0012] For example, in some cases, remote systems determine the expected travel time associated with a road based at least in part on historical traffic data associated with the road. Historical travel data can represent the expected travel time for different times of day and / or different days of week, based on actual measured travel times of vehicles during one or more previous time periods. For example, historical travel data could indicate that expected peak-hour traffic will increase the expected travel time for a particular road by twenty minutes. As highlighted in this example, weights may vary over time, such that the road weights for the same portion of the road can differ within a time period of day, on different days of week, at different times of year, etc.

[0013] As another example, in some cases, remote systems determine the expected travel time associated with a road based at least in part on real-time traffic data associated with the road and / or the road environment. Real-time traffic data can be determined based on data received from traffic speed databases, observed convoy passage times, commercial traffic monitors, and / or traffic reports. Real-time traffic data can include real-time or recent data on vehicles in a convoy, and / or mobile device movement data on mobile devices on the road. In some cases, real-time traffic data can represent the current speed associated with vehicles crossing the road. Such real-time traffic data can indicate abnormal road congestion and is therefore used to adjust the expected travel time associated with that road. As used herein, the term "real-time" includes data that describes current traffic conditions but does not necessarily imply immediacy or accuracy at every moment. Therefore, it should be understood that "real-time" can encompass a range of time resolutions, from data that is practically instantaneous to data that may be hours ago but still describes current (relative to historical) traffic conditions. In some cases, real-time traffic data includes recent (e.g., within threshold time periods such as 1 minute, 10 minutes, 30 minutes, 1 hour, etc.) or near-real-time traffic data.

[0014] As another example, in some cases, a remote system can determine the expected travel time associated with a road based at least in part on road state data associated with the road. Road state data can represent temporary modifications to the road network. In some cases, road state data can represent lane reductions (e.g., due to lane closures), altered traffic flows, detour requirements, road closures, traffic light malfunctions, etc. The remote system can use such data to adjust the expected travel time. For example, if a road is closed, the remote system can set the expected travel time associated with that road to a larger value (e.g., up to and including positive infinity). As another example, if a road is experiencing lane closures, the remote system can increase the expected travel time associated with that road based on the expected congestion level associated with the lane closure. In some cases, a remote system can determine the expected travel time associated with a road based on both traffic data and road state data. For example, during low-traffic periods, lane closures may not increase the expected travel time associated with the corresponding road, or the increase in expected travel time may be less than the increase associated with high-traffic periods.

[0015] As an additional example, in some cases, a remote system may determine the expected travel time associated with a road based at least in part on fleet density data associated with that road. In some cases, the remote system is configured to receive data from and / or manage fleets (e.g., fleets of autonomous vehicles, semi-autonomous vehicles, and / or manually operated vehicles). In some cases, the remote system uses fleet density data to infer traffic conditions and / or road congestion. Such inference can then be used to determine the expected travel time. For example, the system may use data indicating a high concentration of fleets in an area to infer that the area is experiencing a proportionally increasing overall traffic volume. In some cases, the remote system may use fleet density data to infer travel speeds and / or congestion levels associated with a road, and use such inference to determine the expected travel time associated with that road.

[0016] In some cases, the techniques described herein involve determining weights associated with a road based at least in part on traffic data associated with that road. Traffic data may include historical traffic data and / or real-time traffic data. In some cases, traffic data is determined based on sensor data captured and / or provided by one or more vehicles (e.g., image data captured and / or provided by one or more vehicles). In some cases, vehicles may provide traffic-related sensor data from onboard sensors (e.g., cameras). For example, images of roads surrounding the vehicle can be processed to estimate traffic density on those roads. In some cases, traffic data is determined based on fleet density data (e.g., data describing high fleet density on a road and / or in an area including that road). In some cases, if the traffic data indicates high congestion on a road, the weights associated with that road may be reduced accordingly.

[0017] In some cases, the techniques described herein involve determining the weights associated with a road based at least in part on road state data associated with the road. For example, if the road state data indicates that the road is closed, the weight for that road can be set to zero. As another example, if the road state data indicates that the road is experiencing lane closure, the weight for that road can be reduced based on the expected congestion caused by the lane closure. In some cases, the system can determine the weight of a road based on both traffic data and road state data. For example, lane closures during low traffic times may have a lower impact on road weights compared to their impact during high traffic times.

[0018] In some cases, the techniques described herein involve determining the weights associated with a road based at least in part on fleet density data associated with that road. For example, in some cases, the system can use fleet density data to make congestion-related inferences and use such inferences to determine road weights. In some cases, if fleet density data indicates that a road is experiencing high congestion, the system can reduce the weight of that road proportionally to the indicated level of congestion. In some cases, it can be assumed that roads with a high concentration of fleet vehicles have a proportionally higher traffic volume. In some cases, the system can use fleet density data to distribute the different vehicles in a balanced manner. For example, if the system detects that 80 percent of the fleet vehicles are traveling on Highway 1 and 20 percent of the fleet vehicles are traveling on Highway 2, the system can increase the weight associated with Highway 2 to balance the traffic volume on the two highways.

[0019] In some cases, the techniques described herein involve determining weights associated with a road based at least in part on road surface quality data associated with that road. For example, road surface quality data can indicate factors such as bumps, cleanliness, and / or surface friction. Poor road surface quality may require lower vehicle speeds and result in increased travel time on the road. Therefore, the system can incorporate road surface quality when determining weights, for example, by assigning lower weights to roads with lower surface quality to account for longer expected travel times due to vehicle deceleration on these road surfaces.

[0020] In some cases, the techniques described herein involve determining weights associated with a road based at least in part on weather data associated with that road. For example, the system can process current and / or predicted weather data for an area containing a road, such as precipitation, temperature, wind, visibility conditions, etc. Certain weather conditions may require slower speeds, more cautious driving, or even avoidance of certain roads. For example, heavy rain or snow can significantly increase expected travel time on a road. Therefore, by incorporating real-time and predicted weather into the road weighting calculation, the resulting weights can more accurately reflect weather-adjusted travel times. This allows route planning to account for adverse weather and enables vehicles to reroute away from roads estimated to be most severely affected within the estimated travel time range. Weather data can come from public application programming interfaces (APIs) of weather data providers, vehicle sensor data, proprietary weather models, etc.

[0021] In some cases, the techniques described herein involve providing road weights, calculated by a remote device (e.g., a remote fleet management system, such as a cloud-based fleet management system), to the vehicle computing device. In some cases, instead of sending input data (e.g., traffic data, road condition data, and / or fleet density data) for calculating the road weights to the vehicle computing device, the remote system sends the road weights. This reduces both the size of the data that needs to be transferred from the remote system to the vehicle computing device and the computational load on the vehicle computing device, as the vehicle computing device does not need to process the input data and can use the road weights provided by the remote system to perform route planning and / or calculate estimated time of arrival (ETA). In some cases, the computational load on the vehicle computing device is significantly reduced because it can perform route planning and / or calculate ETA by solving a graph problem (e.g., a graph problem where roads correspond to edges and road weights correspond to edge weights) based on the road weights provided by the remote system.

[0022] In some cases, the remote system provides the same road weights associated with a road to all vehicle computing devices that receive weighted data associated with that road. In other cases, the remote system provides different road weights associated with a road to different computing devices that receive the same weighted data. For example, given a first weight for road computing, the remote system may provide a second weight for that road to a first vehicle computing device and a third weight for that road to a second vehicle computing device. The second and third weights can be determined by adjusting the first weight by a first and a second amount, respectively, where the first and second amounts can be randomly selected from a predefined range. In some cases, the goal behind providing different weights for the same road to different vehicle computing devices can be to enhance fleet diversity, allowing different vehicles in the fleet to perform route planning using different sets of weights. Fleet diversity may be desirable because it can prevent congestion, ensure efficient resource utilization, make the fleet more robust to unreliable data scenarios (e.g., where traffic data and / or road condition data do not represent real-world conditions), and enhance overall fleet performance. By assigning different weights to vehicles, the system can ensure that not all vehicles choose the same path simultaneously, which can help avoid overloading or potential bottlenecks on specific routes. Furthermore, fleet diversity can be an effective strategy for testing and comparing different route optimizations in real-world conditions, for example, to obtain data to improve the system's route planning algorithm. Additionally, by diversifying routes, there is a higher probability that at least one subset of the fleet will always be on the most efficient path, even in the event of unforeseen conditions, unreliable data scenarios, and / or unexpected obstacles.

[0023] In some cases, the remote system periodically recalculates the road weights associated with roads that may be relevant to route planning tasks performed by the vehicle computing device and sends the recalculated road weights to the vehicle computing device. In some cases, based on (e.g., in response to) receiving new input data (e.g., new traffic data, new road condition data, and / or new fleet density data), the remote system recalculates the road weights associated with roads that may be relevant to route planning tasks performed by the vehicle computing device and sends the recalculated road weights to the vehicle computing device. In some cases, based on (e.g., in response to) receiving new vehicle locations, the remote system recalculates the road weights associated with roads that may be relevant to route planning tasks performed by the vehicle computing device and sends the recalculated road weights to the vehicle computing device.

[0024] In some cases, to further reduce the amount of data sent from a remote system to the vehicle computing device, if the remote system has previously sent the same road weights associated with the same road to the vehicle computing device, then the remote system will not send road weights associated with that road to the vehicle computing device. In some cases, after initially sending a set of road weights for a set of roads determined to be relevant to the route planning task performed by the vehicle computing device, the remote system only sends new weight data if recalculating the road weights generates modified road weights or generates road weights for new roads newly determined to be relevant to the route planning task. Therefore, in some cases, after the initial road weights, the road weight data sent by the remote system excludes previously sent road weights, thereby reducing the amount of data sent from the remote system to the vehicle computing device. The route planning task may be characterized by a destination location (e.g., a destination location provided by a fleet management application operated by a user on a user's device).

[0025] In some cases, the remote system sends road weights for a set of roads identified as being within an area relevant to the route planning task. For example, this set of roads can be determined by identifying a geographic area or radius surrounding the vehicle's current location and / or destination location. The defined area can also be dynamically adjusted based on real-time factors such as changes in vehicle direction, updated destinations, and / or unexpected roadblocks.

[0026] In some cases, the techniques described herein involve using a vehicle computing device and determining the optimal route for traversing an environment based on road weights provided to the vehicle computing device by a remote system (e.g., a fleet management system). As described above, in some cases, the vehicle computing device can determine the optimal route for traversing the environment from a starting location (e.g., a passenger boarding location) and / or to a requested destination location. In some cases, the vehicle computing device can use a graph of the vehicle environment, where roads represent edges and road weights represent edge weights. In some cases, to determine the optimal route, the vehicle computing device can perform graph processing operations on the graph. This graph processing operation can use a graph search algorithm (such as Dijkstra's algorithm) to find the shortest path across the graph from the starting location to the destination location based on the edge weights.

[0027] In some cases, the techniques described in this paper enable remote systems to further optimize transmission efficiency and traffic assignment by selectively transmitting updated weights. For example, if the updated weights deviate from the previous weight threshold, the remote system can send only the updated weights to the vehicle's computing device to reduce unnecessary data transmissions.

[0028] In some cases, remote systems can perturb weights using randomized amplitudes before sending weights to different vehicles. This can introduce diversity in route planning, prevent road congestion, and / or ensure a more uniform distribution of fleet vehicles across the road network. The perturbation amplitude can be randomly generated or determined based on the current distribution of the fleet across the road network (e.g., to balance the presence of different roads across the network). Therefore, remote systems can efficiently manage fleet and road utilization through strategic weight adjustments and / or transmissions.

[0029] In some cases, the techniques described in this paper enable improved transmission efficiency between remote systems and vehicle computing devices. Instead of sending large amounts of raw data (such as traffic data, road condition data, and / or fleet density data) to each vehicle, the remote system preprocesses this data into road weights and sends only the road weights. This significantly reduces the amount of data that needs to be sent to each vehicle. For example, the remote system can initially send a set of weights for the relevant roads and then selectively send updates only when it determines that the weights have changed, thus avoiding resending weights that have not yet been changed.

[0030] In some cases, the techniques described in this paper enable a reduction in the computational load on vehicle computing devices. Since the remote system preprocesses the raw data into road weights, the vehicle computing device can directly use these weights for route planning without having to process large amounts of data. This allows route planning computations to be simplified to a graph search algorithm based on the provided edge weights. Offloading the raw data processing to the remote system saves significant computational resources that would otherwise have to be performed on the vehicle computing device. This is crucial considering that most vehicle computing devices have limited hardware resources compared to remote systems. The reduced computational load also enables faster route planning using vehicle computing devices.

[0031] In some cases, the techniques described in this paper enable centralized and efficient control of fleet systems via remote systems. For example, a remote system can adjust how it calculates road weights to balance traffic across roads or create fleet diversity. The remote system can also selectively determine which updated weights to send to each vehicle to further optimize transmission efficiency. This centralized control allows for optimization of the entire fleet.

[0032] The techniques described herein can be implemented in various ways. Example implementations are provided below with reference to the accompanying figures. In the example implementations discussed below, the delivery vehicle is implemented as an autonomous vehicle. However, the methods, apparatus, and systems described herein can be applied to fully or partially autonomous delivery vehicles, robots, and / or robotic systems, and are not limited to autonomous vehicles. Furthermore, at least some of the techniques described herein can be used with driver-controlled vehicles. While the various techniques described herein involve determining optimal routes by vehicle computing devices of vehicles as part of a fleet, those skilled in the art will recognize that the techniques described herein can also be used by vehicle computing devices associated with vehicles that are not part of a fleet.

[0033] Figure 1 An example environment 100 is depicted that can be used for route planning for a fleet to perform various driving trips within an environment. As shown in this example, a fleet management system 102 can receive driving trip requests and can determine road weight data 122 to provide to the individual vehicles 104-108 in the fleet that will perform the requested driving trip. In this example, environment 100 may include a first vehicle 104, a second vehicle 106, and a third vehicle 108, each of which can be instructed to perform a specific driving trip via a separate road weight dataset 122 provided by the fleet management system 102. Vehicles 104-108 can be autonomous vehicles, semi-autonomous vehicles, and / or driver-controlled vehicles. In some cases, vehicles 104-108 may be autonomous vehicles configured to operate according to a Level 5 classification issued by the National Highway Traffic Safety Administration (NHTSA), which describes vehicles capable of performing all safety-critical functions throughout the trip, where the driver (or occupant) is not expected to control the vehicle at any time. However, in other examples, vehicles 104-108 may be fully or partially autonomous vehicles with any other level or classification. As described above, vehicles 104-108 may be associated with ride-hailing services (e.g., taxi services) and / or may be delivery service vehicles. Ride-hailing vehicles may operate within example environment 100 to provide transportation to passengers from their origin to their destination. Delivery service vehicles may operate within example environment 100 to deliver items to various delivery locations.

[0034] Within example environment 100, vehicles 104-108 can be managed by fleet management system 102. In some examples, fleet management system 102 can be implemented as a component integrated into a separate server-based system (e.g., a system operating in a cloud computing environment). As described above, fleet management system 102 can transmit road weight data 122, including weights associated with roads, via one or more networks. Additionally, in some examples, vehicles 104-108 can also send various data back to fleet management system 102, including but not limited to location data, sensor data captured by sensors of vehicles 104-108, and / or complete driving routes determined by route planning components of vehicles 104-108.

[0035] In various examples, the fleet management system 102 can deploy and manage any number of vehicles, including but not limited to coordinating pick-up and drop-off requests from prospective passengers, providing location data for supplying services or delivering goods, and providing suggested routes to individual vehicles in the fleet. In some examples, the fleet management system 102 can dynamically control vehicle activity by converting vehicles from taxi service vehicles to delivery service vehicles and / or converting delivery service vehicles back to taxi service vehicles. In various examples, the fleet management system 102 can manage the entire fleet covering the entire driving environment, or it can manage only a subset of vehicles within a specified portion of the environment.

[0036] like Figure 1 As depicted, the fleet management system 102 may include various components configured to perform different functions of the vehicle route planning technology described herein. For example, the fleet management system 102 may include a processor 110 and a memory 112. The memory 112 may store operations corresponding to the traffic aggregator 114, the route planning aggregator 116, and the remote route planner 118, and the processor 110 may perform these operations. The memory 112 may also store historical traffic data 120.

[0037] Traffic aggregator 114 can be configured to determine traffic volume estimates for a road (e.g., a metric for estimating traffic volume). To determine one or more traffic volume estimates, traffic aggregator 114 can use historical traffic data 120, real-time traffic data, fleet density data, and / or sensor data provided by one or more sensors 124 and / or perception components 126 of vehicles 104-108. Traffic aggregator 114 can provide one or more traffic volume estimates to route planning aggregator 116.

[0038] Route planning aggregator 116 can be configured to determine road weight data 122 (e.g., one or more weights for one or more roads) based on traffic volume estimates and / or road condition data (e.g., road condition data provided by a map system and / or road network system) provided by traffic aggregator 114. Route planning aggregator 116 can be configured to provide road weight data 122 to at least one of: remote route planner 118 or one or more of vehicles 104-108 (e.g., the vehicle's mission master component).

[0039] The remote route planner 118 can be configured to determine the optimal route to a requested destination location and / or the ETA associated with that optimal route. In some cases, the remote route planner 118 executes as an encapsulated software unit (e.g., using a wrapper function and / or wrapper class). In other cases, the remote route planner 118 is executed by a cloud management system associated with the fleet management system 102.

[0040] In some cases, after a request is made to use a fleet to travel to a destination location, the fleet management system 10 assigns a vehicle to the request. In some cases, the route planning aggregator 116 then calculates a set of road weights for a set of roads associated with the area involved in the request. The route planning aggregator 116 can then provide this road weight data 122 to at least one of a remote route planner 118 and a local route planner 130. The remote route planner 118 can use the road weight data 122 to determine the optimal route to the requested destination location and / or the ETA associated with that optimal route. The remote route planner 118 can provide the optimal route and / or ETA to vehicles 104-108, which can provide data associated with the optimal route and / or ETA using vehicle display 134 before the optimal route and / or ETA determined by the vehicles themselves becomes available. In some cases, vehicles 104-108 perform decision-making operations using the optimal route and / or ETA determined by the remote route planner 118 until an optimal route and / or ETA determined by the vehicle 104 itself becomes available. In some cases, the fleet management system 102 sends the optimal route and / or ETA determined by the remote route planner 118 to user equipment (e.g., a smartphone device), for example, for display using a software application running on the user equipment.

[0041] In some cases, the fleet management system 102 calculates a set of road weights for an entire area (e.g., the entire map) associated with the mapping data available to the fleet management system 102. In some cases, the fleet management system 102 calculates a set of road weights for an area determined based on at least one of a predefined radius around the vehicle location, a predefined radius around the passenger pick-up location, or a predefined radius around the destination location. In some cases, the fleet management system 102 sends all calculated weights (e.g., all weights associated with the entire area associated with the map data available to the fleet management system 102) to the vehicle 104. In some cases, the fleet management system 102 sends a subset of the calculated weights (e.g., a subset associated with an area determined based on at least one of a predefined radius around the vehicle location, a predefined radius around the passenger pick-up location, or a predefined radius around the destination location) to the vehicle 104.

[0042] In some cases, the optimal route and / or ETA generated by the remote route planner 118 may differ from the optimal route and / or ETA generated by the local route planner 130. In some cases, the ride engine 128 displays the optimal route and / or ETA generated by the remote route planner 118 on the vehicle display 134 before generating the optimal route and / or ETA generated by the local route planner 130. In some cases, the generated optimal route and / or ETA is displayed on the vehicle display 134 after the local route planner 130 has generated it. In some cases, the ride engine 128 provides the optimal route and / or ETA generated by the local route planner 130 to the fleet management engine 210. In some cases, the fleet management engine 210 provides the optimal route and / or ETA generated by the remote route planner 118 to the user equipment 208 before receiving the optimal route and / or ETA generated by the local route planner 130. In some cases, after receiving the optimal route and / or ETA generated by the local route planner 130, the fleet management engine 210 provides the optimal route and / or ETA generated by the local route planner 130 to the user equipment 208. In some cases, after generating the optimal route and / or ETA generated by the local route planner 130, the local route planner 130 provides the generated route and / or ETA to the fleet management engine 210 only if the generated route and / or ETA differs from the optimal route and / or ETA generated by the fleet management engine 210. In some cases, after generating the optimal route and / or ETA generated by the local route planner 130, the local route planner 130 only provides the generated route and / or ETA to the fleet management engine 210.

[0043] exist Figure 1In example environment 100, each of vehicles 104-108 (and other vehicles in the fleet) can be configured to determine an optimal route and driving trajectory based on road weight data 122 provided by the fleet management system 102, including specific trajectories and turn-by-turn driving routes for the vehicle to perform the requested driving trip. As shown in this example, vehicles 104-108 in the fleet may include various components configured to determine the complete driving route, including sensors 124, perception components 126, a ride engine 128, a local route planner 130, a decision planner 132, and a vehicle display 134.

[0044] Sensor 124 may include, for example, image sensors (e.g., cameras), lidar sensors, radar sensors, time-of-flight sensors, environmental sensors, audio sensors, inertial sensors, sonar sensors, position sensors (e.g., Global Positioning System (GPS)), and various other sensors configured to capture data representing the external environment surrounding vehicle 104. Perception component 126 may be configured to use sensor data (and / or additional data) from sensor 124 to detect and classify objects in the environment surrounding vehicle 104. Decision planner 132 may be configured to determine a driving trajectory for controlling vehicle 104 based on the output of perception component 126 and / or based on the optimal route determined by local route planner 130.

[0045] Ride engine 128 can be configured to receive tasks from fleet management system 102 to pick up passengers from an originating location and / or transport passengers to a requested destination location. Ride engine 128 can also be configured to initiate the execution of tasks received from fleet management system 102 (e.g., by providing the task to the task master component of vehicle 104). Ride engine 128 can also be configured to interact with passengers during boarding and / or during the ride. For example, ride engine 128 can be configured to open the doors of vehicle 104 for passengers during boarding. In some cases, ride engine 128 is configured to display data on vehicle display 134. For example, ride engine 128 can be configured to receive optimal route data and / or ETA data determined by remote route planner 118 and display such received data on vehicle display 134.

[0046] The local route planner 130 can be configured to determine the optimal route to a requested destination and / or the associated ETA based on road weight data 122 provided by the fleet management system 102. In some cases, the local route planner 130 executes as a wrapped software unit (e.g., using wrapper functions and / or wrapper classes). This wrapped software unit may have the same codebase and / or the same operational logic as the wrapped software unit associated with the remote route planner 118. The local route planner 130 can provide the optimal route and / or ETA to the ride engine 128, which can use the vehicle display 134 to provide data associated with the optimal route and / or ETA.

[0047] Figure 2 A sample architecture 200 is provided for route planning for a fleet to perform various driving trips in an environment. (Example architecture 200) Figure 2 As depicted, traffic aggregator 114 uses historical traffic data 120, real-time traffic data provided by traffic system 202, and object detection data provided by perception component 126 to determine traffic volume estimates for roads (e.g., a set of traffic volume estimates for a set of roads), and provides one or more of these traffic volume estimates to route planning aggregator 116. Of course, such an example is provided for illustrative purposes, and this disclosure is not intended to be so limiting, as additional sources are contemplated. Additionally, road network system 204 (e.g., a map system) can be configured to provide road status data to road network overlay 206. Road network overlay 206 can be configured to determine one or more road status alerts based on the road status data provided by road network system 204.

[0048] like Figure 2Further described, route planning aggregator 116 uses traffic volume estimates generated by route planning aggregator 116 and road condition alerts generated by road network coverage 206 to determine road weights for a set of roads, and provides the determined weights to vehicle computing devices operating on fleet vehicles and remote route planner 118. Roads can be any segment of a path (e.g., a fixed distance along a lane, a portion of a lane's fixed length, a portion of a lane with the same or similar geometry, etc.), and in some cases may not correspond to addressing designations of the path. In some cases, route planning aggregator 116 generates the same road weights relative to all vehicles, while in other cases, route planning aggregator 116 generates different road weights relative to different vehicles and different corresponding vehicle computing devices. For example, different weights can be provided to different vehicle computing devices by adjusting (e.g., randomly adjusting) the generated weights. The goal behind this different weighting is to enhance fleet diversity. Route planning aggregator 116 provides the generated road weights to both remote route planner 118 and local route planner 130.

[0049] like Figure 2 As further described, the remote route planner 118 receives road weights generated by the route planning aggregator 116 and uses these road weights to generate an optimal route and its corresponding ETA. The remote route planner 118 can run as a wrapper function executed by the fleet management engine 210, which can be a cloud management system. After the remote route planner 118 generates the road weights, these road weights are displayed to the user using a user device 208 (e.g., a smartphone device) and provided to the ride engine 128 of the vehicle computing device 212. Before the local route planner 130 generates the optimal route and its corresponding ETA based on the road weights generated by the route planning aggregator 116, the ride engine 128 can display data associated with the optimal route and its corresponding ETA using the vehicle display 134.

[0050] like Figure 2Further described, the remote route planner 118 receives a ride request from the user equipment 208, determines which vehicle in the fleet to assign the request to, and provides the ride request to the ride engine 128 of the vehicle to which the request was assigned. The ride engine 128 then provides the ride request to the local route planner 130 to generate an optimal route and corresponding ETA based on road weights generated by the route planning aggregator 116. The local route planner 130 can run as a wrapper function executed by the task master 214. After the local route planner 130 generates the optimal route and corresponding ETA, this optimal route and corresponding ETA are provided to the fleet management engine 210 to update the data provided to the user via the user equipment 208. In some cases, when the local route planner 130 generates a new optimal route and ETA during a ride, this new data is also provided to the fleet management engine 210. The local route planner 130 also provides the optimal route to the decision planner 132, which generates a trajectory for the vehicle based on the optimal route. For example, in response to a ride request to destination 136, the local route planner 130 can generate an optimal route 138 and provide the optimal route to the decision planner 132 for trajectory planning.

[0051] like Figure 2 Further described, decision planner 132 determines the vehicle's trajectory based on the optimal route generated by local route planner 130 and road condition alerts generated by road network coverage 206. In some cases, road network coverage 206 generates at least two types of road condition alerts: route planning-related road condition alerts that affect route planning, and route planning-independent road condition alerts that do not affect route planning. Examples of route planning-related road condition alerts include road closure alerts and lane closure alerts. Examples of route planning-independent road condition alerts include alerts that affect the vehicle's driving trajectory but not its route planning, such as alerts about road supervision requirements, alerts about avoiding parking at specific locations, and alerts about high pedestrian concentration in specific areas. In some cases, road network coverage 206 provides route planning-related road condition alerts to route planning aggregator 116, which uses such alerts to generate road weights. In some cases, road network coverage 206 provides route planning-independent road condition alerts to decision planner 132, which uses such data to generate the vehicle's trajectory.

[0052] Figure 3This is a flowchart of an example process 300 for determining road weights using a computer system (e.g., a fleet management system) that operates remotely from the vehicle's computing devices. In some cases, process 300 allows for centralized determination of road weights. These weights can then be sent to the vehicle to reduce the computational complexity of onboard route planning. In other cases, periodically repeating process 300 allows for weight updates based on changing conditions.

[0053] At operation 302, process 300 includes receiving traffic data associated with the road. The traffic data may include historical traffic data and real-time traffic data. Historical traffic data may indicate the expected travel time on the road based on time of day, day of week, etc. Real-time traffic data may indicate the current speed and congestion level on the road.

[0054] At operation 304, process 300 includes receiving road status data associated with the road. The road status data may indicate one or more temporary changes to the road, such as closure, detour, accident, etc.

[0055] At operation 306, process 300 includes determining the expected travel time for a road based on traffic data and road condition data. In some cases, operation 306 includes adjusting historical travel times based on any real-time driving conditions and / or road condition alerts. For example, a road might historically take 20 minutes during peak hours. However, if real-time data shows an accident, the expected travel time might increase to 30 minutes.

[0056] At operation 308, process 300 includes determining the weight of a road based on its expected travel time. In some cases, the weight of a road is proportional to its expected travel time, such that roads with higher expected travel times have lower weights, and vice versa.

[0057] At operation 310, process 300 includes providing the calculated road weights to the vehicle computing device. In some cases, instead of sending the input data (e.g., traffic data, road condition data, and / or fleet density data) used to calculate the road weights to the vehicle computing device, the remote system sends the road weights.

[0058] Figure 4 This is a flowchart of an example process 400 for managing ride requests using a fleet management system. (Example:) Figure 4As depicted, at operation 402, in some cases, in addition to or instead of the weights(s), a set of transition probabilities is generated and provided to the vehicle computing device. The transition probabilities may represent the probability of transitioning from one lane of a road to another (e.g., ease, safety, etc.). Process 400 includes receiving first traffic data and first road state data associated with a first time. The first traffic data and first road state data may reflect current traffic and road state data associated with the current time (e.g., the time of requesting a ride and / or the time the ride begins).

[0059] At operation 404, process 400 includes determining a first set of road weights based on first traffic data and first road condition data. The first set of road weights can be determined based on the expected travel time calculated from the first traffic data and the first road condition data.

[0060] At operation 406, process 400 includes providing a first set of road weights to the computing device of the assigned vehicle. In some cases, the first set of road weights is sent to the vehicle computing device so that the vehicle computing device can use the first set of road weights to begin route planning.

[0061] At operation 408, process 400 includes receiving new traffic data and new road condition data associated with the second time. This new data may reflect any changes in road conditions since the original ride request time.

[0062] At operation 410, process 400 involves determining an updated set of weights based on new traffic data and new road condition data. In some cases, the fleet management system recalculates the road weights to determine the updated set of weights. These new weights can reflect changed road conditions.

[0063] At operation 412, process 400 includes determining whether the updated set of weights includes weights that were not previously sent (e.g., weights for new roads or modified weights for roads whose weights were previously provided). For example, if new weights for roads along the updated optimal route have been generated, or if the weights of existing roads have changed, process 400 may determine that the updated set of weights includes weights that were not previously sent. In some cases, modified weights for existing roads are reported only if the weight change exceeds a threshold.

[0064] If no new or significantly changed weights are detected, process 400 skips the transmission of updated weight data at operation 414 and loops back to operation 408 to await further data updates. If new or changed weights are detected at operation 414, process 400 sends these new weights to the vehicle at operation 416. This allows the vehicle to incorporate the updated weights into its ongoing route planning. After operation 414 or 416, process 400 returns to operation 408 to continue receiving new traffic and road condition data, recalculating weights, and selectively sending weight updates to the vehicle for the remainder of the ride. This allows the assigned vehicle's route planning to dynamically adapt to changing conditions during the journey.

[0065] Figure 5 A block diagram depicts an example system 500 for implementing the various techniques described herein. In some instances, the example system 500 may include a vehicle 502 and one or more computing devices 540, the vehicle 502 representing the above-described... Figures 1-4 The vehicle 104 discussed herein, and the one or more computing devices 540, may represent the fleet management system 102 discussed above. In some instances, vehicle 502 may be an autonomous vehicle configured to operate according to a Level 5 classification issued by the National Highway Traffic Safety Administration (NHTSA), which describes vehicles capable of performing all safety-critical functions throughout the journey, where the driver (or occupant) is not expected to control the vehicle at any time. However, in other examples, vehicle 502 may be a fully or partially autonomous vehicle with any other level or classification. Furthermore, in some instances, the techniques described herein may also be used by non-autonomous vehicles. These are merely examples, and the systems and methods described herein can be incorporated into any land, air, or water vehicle, ranging from those requiring constant manual control by a driver to those requiring partial or full autonomous control.

[0066] Vehicle 502 may be configured to perform various techniques described herein, including receiving road weight data 122 from computing device(s) 540 based on a requested driving trip, and determining a driving route based on the road weight data 122. Similarly, computing device(s) 540 may be configured to perform various techniques of the fleet management system 102 described herein, including modifying route data for vehicles in the fleet based on current and / or previous driving trips performed by the fleet.

[0067] Vehicle 502 may include one or more vehicle computing devices 504, one or more sensors 506, one or more transmitters 508, one or more network interfaces 510, at least one direct connection 512 (e.g., for physical coupling with the vehicle to exchange data and / or provide power), and one or more drive systems 514. In this example, vehicle 502 may correspond to vehicle 104 discussed above. System 500 may additionally or alternatively include one or more computing devices 504.

[0068] In some instances, one or more sensors 506 may include lidar sensors, radar sensors, ultrasonic transducers, sonar sensors, position sensors (e.g., Global Positioning System (GPS), compasses), inertial sensors (e.g., inertial measurement units (IMUs), accelerometers, magnetometers, gyroscopes), image sensors (e.g., red-green-blue (RGB), infrared (IR), intensity, depth, time-of-flight, cameras, etc.), microphones, wheel encoders, environmental sensors (e.g., thermometers, hygrometers, light sensors, pressure sensors), etc. One or more sensors 506 may include multiple instances of each of these or other types of sensors. For example, radar sensors may include individual radar sensors located at corners, front, rear, sides, and / or top of vehicle 502. As another example, cameras may include multiple cameras positioned at various locations around the exterior and / or interior of vehicle 502. One or more sensors 506 may provide input to one or more vehicle computing devices 504 and / or one or more computing devices 540.

[0069] Vehicle 502 may also include one or more transmitters 508 for emitting light and / or sound, as described above. In this example, transmitters 508 may include one or more internal audio and visual transmitters for communicating with passengers of vehicle 502. By way of example, and not limitation, internal transmitters may include speakers, lights, signs, displays, touchscreens, one or more haptic transmitters (e.g., vibration and / or force feedback), mechanical actuators (e.g., seatbelt tensioners, seat positioners, headrest positioners, etc.), etc. In this example, transmitters 508 may also include one or more external transmitters. By way of example, and not limitation, the external transmitters in this example include lights or other indicators (e.g., indicator lights, signs, light arrays) for signaling the direction of travel, and one or more audio transmitters (e.g., speakers, speaker arrays, horns) for audible communication with pedestrians or other nearby vehicles, one or more of which include beam steering technology.

[0070] Vehicle 502 may also include one or more network interfaces 510 that enable communication between vehicle 502 and one or more other local or remote computing devices. For example, network interfaces 510 may facilitate communication with one or more other local computing devices and / or one or more drive systems 514 on vehicle 502. Furthermore, network interfaces 510 may additionally or alternatively allow the vehicle to communicate with other nearby computing devices (e.g., other nearby vehicles, traffic signals, etc.). Network interfaces 510 may additionally or alternatively enable vehicle 502 to communicate with one or more computing devices 540. In some examples, computing devices 540 may include one or more nodes of a distributed computing system (e.g., a cloud computing architecture).

[0071] One or more network interfaces 510 may include physical and / or logical interfaces for connecting one or more vehicle computing devices 504 to another computing device or network (e.g., one or more networks 538). For example, network interfaces 510 may enable Wi-Fi-based communication, such as via frequencies defined by the IEEE 200.11 standard, short-range wireless frequencies (e.g., Bluetooth®), cellular communication (e.g., 2G, 3G, 4G, 4G LTE, 5G, etc.), or any suitable wired or wireless communication protocol that enables the respective computing device to engage with one or more other computing devices. In some instances, one or more vehicle computing devices 504 and / or one or more sensors 506 may transmit sensor data to one or more computing devices 540 via one or more networks 538 at a specific frequency, after a predetermined time period, or in near real-time.

[0072] In some instances, vehicle 502 may include one or more drive systems 514 (or drive components). In some instances, vehicle 502 may have a single drive system 514. In some instances, drive system(s) 514 may include one or more sensors to detect the conditions of the environment surrounding drive system(s) 514 and / or vehicle 502. By way of example and not limitation, the sensors(s) of drive system(s) 514 may include: one or more wheel encoders (e.g., rotary encoders) to sense the rotation of the wheels of the drive component; inertial sensors (e.g., inertial measurement units, accelerometers, gyroscopes, magnetometers, etc.) to measure the orientation and acceleration of the drive component; cameras or other image sensors; ultrasonic sensors to acoustically detect objects in the environment surrounding the drive component; lidar sensors; radar sensors, etc. For drive system(s) 514, some sensors such as wheel encoders may be unique. In some cases, sensors(s) on drive system(s) 514 may overlap with or complement corresponding systems (e.g., one or more sensors 506) of vehicle 502.

[0073] One or more drive systems 514 may include a number of vehicle systems within the vehicle system, including: a high-voltage battery, an electric motor propelling the vehicle, an inverter converting direct current from the battery into alternating current for use by other vehicle systems, a steering system including a steering motor and a steering frame (which may be electric), a braking system including hydraulic or electric actuators, a suspension system including hydraulic and / or pneumatic components, a stability control system for distributing braking force to mitigate traction loss and maintain control, an HVAC system, lighting (e.g., headlights / taillights for illuminating the exterior environment of the vehicle), and one or more other systems (e.g., cooling systems, safety systems, on-board charging systems, other electrical components such as DC / DC converters, high-voltage junctions, high-voltage cables, charging systems, charging ports, etc.). Additionally, one or more drive systems 514 may include a drive component controller that can receive and preprocess data from one or more sensors and control the operation of various vehicle systems. In some instances, the drive component controller may include one or more processors and a memory communicatively coupled to the one or more processors. The memory may store one or more components to perform various functions of one or more drive systems 514. In addition, drive system 514 may include one or more communication connections that enable the respective drive components to communicate with one or more other local or remote computing devices.

[0074] One or more vehicle computing devices 504 may include one or more processors 516 and a memory 518 communicatively coupled to the one or more processors 516. The memory 518 may represent the memory 112 of the fleet management system 102. One or more computing devices 540 may also include one or more processors 542 and / or a memory 544. As described above, the memory 544 of the one or more computing devices 540 that may be implemented as the fleet management system 102 may store and execute traffic aggregator 114, route planning aggregator 116, and remote route planner 118, and the one or more computing devices 540 may be configured to perform any combination of the functions of the fleet management system 102 described herein. The memory 544 may also store historical traffic data 120.

[0075] The processors 516 and / or 542 may be any suitable processor capable of executing instructions to process data and perform the operations described herein. By way of example and not limitation, the processors 516 and / or 542 may include one or more central processing units (CPUs), graphics processing units (GPUs), integrated circuits (e.g., application-specific integrated circuits (ASICs)), gate arrays (e.g., field-programmable gate arrays (FPGAs)), and / or any other device or part of a device that processes electronic data to convert that electronic data into other electronic data that may be stored in registers and / or memory.

[0076] Memory 518 and / or 544 may be examples of non-transitory computer-readable media. Memory 518 and / or 544 may store an operating system and one or more software applications, instructions, programs, and / or data to implement the methods described herein and the functions belonging to various systems. In various implementations, the memory may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash memory, or any other type of memory capable of storing information. The architectures, systems, and various elements described herein may include many other logical, program, and physical components, wherein those shown in the figures are merely examples relevant to the discussion herein.

[0077] In some instances, memory 518 and / or memory 544 may store positioning component 520, sensing component 522, map 524, (one or more) system controllers 526, prediction component 528 and / or planning component 530.

[0078] In at least one example, the localization component 520 may include hardware and / or software for receiving data from one or more sensors 506 to determine the position, velocity, and / or orientation (e.g., one or more of x-position, y-position, z-position, roll, pitch, or yaw) of the vehicle 502. For example, the localization component 520 may include one or more maps of the environment and may continuously determine the position, velocity, and / or orientation of the autonomous vehicle within one or more maps. In some instances, the localization component 520 may utilize SLAM (Simultaneous Localization and Mapping), CLAMS (Simultaneous Calibration, Localization, and Mapping), relative SLAM, beamforming, nonlinear least squares optimization, etc., to receive image data, lidar data, radar data, IMU data, GPS data, wheel encoder data, etc., to accurately determine the position, attitude, and / or velocity of the autonomous vehicle. In some instances, the localization component 520 may provide data to various components of the vehicle 502 to determine the initial position of the autonomous vehicle for generating trajectories and / or for generating map data, as discussed herein. In some examples, the positioning component 520 may provide the planning component 530 and / or the prediction component 528 with the position and / or orientation of the vehicle 502 relative to the environment and / or the associated sensor data.

[0079] The memory 518 may also include one or more maps 524, which can be used by the vehicle 502 for navigation within the environment. For the purposes of this discussion, the maps can be any number of data structures modeled in two, three, or N dimensions, capable of providing information about the environment, such as, but not limited to, topology (e.g., intersections), streets, mountains, roads, terrain, and the general environment. In one example, the map may include a three-dimensional mesh generated using the techniques discussed herein. In some instances, the map may be stored in a tile format, such that individual tiles of the map represent discrete portions of the environment, and can be loaded into working memory as needed. In at least one example, one or more maps 524 may include at least one map (e.g., an image and / or a mesh) generated according to the techniques discussed herein. In some examples, the vehicle 502 may be controlled at least in part based on the map 524. That is, the map 524 may be used in conjunction with the positioning component 520, the perception component 522, and / or the planning component 530 to determine the location of the vehicle 502, identify objects in the environment, and / or generate routes and / or trajectories for navigation within the environment.

[0080] In some instances, perception component 522 may include a primary perception system and / or prediction system implemented in hardware and / or software. Perception component 522 may detect one or more objects in the environment surrounding vehicle 502 (e.g., identify the presence of objects), classify one or more objects (e.g., determine the object type associated with the detected objects), segment sensor data and / or other representations of the environment (e.g., identify portions of the sensor data and / or environmental representations as associated with the detected objects and / or object types), determine characteristics associated with the objects (e.g., identify trajectories of current, predicted, and / or previous positions, headings, speeds, and / or accelerations associated with the objects), etc. The data determined by perception component 522 is referred to as perception data.

[0081] In some examples, sensor data and / or perception data can be used to generate an environmental state representing the current state of the environment. For example, the environmental state can be a data structure containing object identification data (e.g., object location, area of ​​the environment occupied by the object, object heading, object velocity, historical object data), environmental layout data (e.g., a map of the environment or a sensor-generated layout), environmental condition data (e.g., location and / or area associated with environmental features (e.g., water or ice), whether it is raining, visibility measures), sensor data (e.g., images, point clouds), etc. In some examples, the environmental state can include a top-down two-dimensional representation of the environment and / or a three-dimensional representation of the environment, either of which can be augmented with object data. In yet another example, the environmental state can include only sensor data. In still another example, the environmental state can include both sensor data and perception data.

[0082] Prediction component 528 may include functionality for generating predictive information associated with objects in the environment. As an example, prediction component 528 may be implemented to predict the position of a pedestrian in the environment near a crosswalk area (or other areas or locations associated with the pedestrian crossing the road) when the pedestrian is crossing or preparing to cross a crosswalk area. As another example, the techniques discussed herein may be implemented to predict the positions of other objects (e.g., vehicles, bicycles, pedestrians, etc.) as vehicle 502 crosses the environment. In some examples, prediction component 528 may generate one or more predicted positions, predicted speeds, predicted trajectories, etc., for such a target object based on attributes of the target object and / or other objects near the target object.

[0083] The planning component 530 may receive the position and / or orientation of the vehicle 502 from the positioning component 520, receive sensing data from the sensing component 522, and / or receive a predicted trajectory from the prediction component 528, and may determine instructions for controlling the operation of the vehicle 502 based at least in part on any of these data. In some examples, determining the instructions may include determining the instructions based at least in part on the format associated with the system to which the instructions are associated (e.g., a first instruction for controlling the motion of the autonomous vehicle may be formatted as a message and / or signal (e.g., analog, digital, aerodynamic, kinematic) in a first format that can be parsed / executed by (one or more) system controllers 526 and / or (one or more) drive systems 514, and a second instruction for (one or more) transmitters 508 may be formatted according to a second format associated therewith). In at least one example, the planning component 530 may include a nominal trajectory generation subcomponent that generates a set of candidate trajectories and selects a trajectory for implementation by the drive system(s) 514 based at least in part on determining the cost associated with the trajectory, in accordance with U.S. Patent Application No. 16 / 517,506 filed July 19, 2019 and / or U.S. Patent Application No. 16 / 852,284 filed May 11, 2020 (the entire contents of which are incorporated herein by reference for all purposes).

[0084] Memory 518 and / or 544 may additionally or alternatively store mapping systems (e.g., maps generated at least in part based on sensor data), planning systems, ride management systems, etc. Although positioning component 520, sensing component 522, prediction component 528, planning component 530 and / or (one or more) system controllers 526 are shown as stored in memory 518, any of these components may include processor-executable instructions, (one or more) machine learning models (e.g., neural networks) and / or hardware, and all or part of any of these components may be stored on memory 544 or configured as part of computing device (one or more) 540.

[0085] As described herein, the localization component 520, perception component 522, prediction component 528, planning component 530, and / or other components of system 500 may include one or more ML models. For example, the localization component 520, perception component 522, prediction component 528, and / or planning component 530 may each include different ML model pipelines. The prediction component 528 may use different ML models or combinations of different ML models under different conditions. For example, the prediction component 528 may use different GNNs, RNNs, CNNs, MLPs, and / or other neural networks that are customized to output predicted agent trajector trajector trajector trajector trajector trajector trajector trajector trajector trajectories based on different seasons (e.g., summer or winter), different driving conditions and / or visibility conditions (e.g., when the boundaries between road lanes may be unclear or may be covered by snow), and / or based on different crowds or traffic conditions (e.g., more conservative trajectories in congested traffic conditions (e.g., urban areas, etc.). In various examples, any or all of the ML models described above may include attention mechanisms, GNNs, and / or any other neural networks. Exemplary neural networks are biologically heuristic algorithms that pass input data through a sequence of connected layers to produce an output. Each layer in a neural network may also include another neural network, or may include any number of layers (whether convolutional or not). As will be understood in the context of this disclosure, neural networks can utilize machine learning, which can refer to a large class of such algorithms that generate outputs based on learned parameters.

[0086] Although discussed in the context of neural networks, any type of machine learning can be used in accordance with this disclosure. For example, machine learning algorithms can include, but are not limited to, regression algorithms (e.g., ordinary least squares regression (OLSR), linear regression, logistic regression, stepwise regression, multivariate adaptive regression splines (MARS), local estimation scatter smoothing (LOESS)), instance-based algorithms (e.g., ridge regression, minimum absolute shrinkage and selection operator (LASSO), elastic nets, minimum angle regression (LARS)), decision tree algorithms (e.g., classification and regression trees (CART), iterative bisection method 3 (ID3), chi-square automatic interaction detection (CHAID), decision stumps, conditional decision trees), Bayesian algorithms (e.g., Naive Bayes, Gaussian Naive Bayes, multinomial Naive Bayes, average one-dependency estimator (AODE), Bayesian belief network (BNN), Bayesian network), clustering algorithms (e.g., k-means, k-median, expectation maximization (EM), hierarchical clustering), and association rule learning algorithms. (e.g., perceptron, backpropagation, Hopfield network, radial basis function network (RBFN)), deep learning algorithms (e.g., deep Boltzmann machine (DBM), deep belief network (DBN), convolutional neural network (CNN), stacked autoencoder), dimensionality reduction algorithms (e.g., principal component analysis (PCA), principal component regression (PCR), partial least squares regression (PLSR), Sammon mapping, multidimensional scaling (MDS), projection pursuit, linear discriminant analysis (LDA), mixture discriminant analysis (MDA), quadratic discriminant analysis (QDA), flexible discriminant analysis (FDA)), ensemble algorithms (e.g., boosting, bootstrap aggregation (bagging), AdaBoost, stacked generalization (mixture), gradient boosting machine (GBM), gradient boosting regression tree (GBRT), random forest), SVM (support vector machine), supervised learning, unsupervised learning, semi-supervised learning, etc.). Additional examples of architectures include neural networks, such as ResNet-50, ResNet-101, VGG, DenseNet, PointNet, etc.

[0087] The memory 518 may additionally or alternatively store one or more system controllers 526, which may be configured to control the steering, propulsion, braking, safety, transmitter, communication and other systems of the vehicle 502. These system controllers 526 may communicate with and / or control corresponding systems of the drive system(s) 514 and / or other components of the vehicle 502.

[0088] In additional or alternative examples, vehicle 502 and / or one or more computing devices 540 may communicate with one or more passenger devices (not shown) (e.g., sending and / or receiving messages via one or more networks 538). Passenger devices may include, for example, smartphones, portable computers (e.g., laptops or tablets), wearable devices (e.g., smart glasses, smartwatches, headphones), etc. Although passenger devices may be passenger-associated and separate from the autonomous vehicle's devices, it is conceivable that passenger devices may be subsystems and / or devices of vehicle 502. For example, passenger devices may additionally or alternatively include displays and / or one or more input / output devices, such as touchscreens, microphones, speakers, etc. In some examples, vehicle 502 may send and / or receive messages from passenger devices.

[0089] It should be noted that, although Figure 5 While shown as a distributed system, in an alternative example, components of vehicle 502 may be associated with computing device(s) 540 and / or components of computing device(s) 540 may be associated with vehicle 502. That is, vehicle 502 may perform one or more functions associated with computing device(s) 540, and vice versa. Example Terms

[0090] Although the example clauses described below pertain to a particular implementation, it should be understood that, within the context of this document, the content of the example clauses can be implemented via methods, devices, systems, computer-readable media, and / or other implementations. Furthermore, any of the example clauses can be implemented alone or in combination with any other one or more of the example clauses.

[0091] A: A system comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the system to perform operations including: receiving data associated with a road network, wherein the data includes real-time traffic data associated with a first road in the road network and road state data associated with a second road in the road network; determining a plurality of weights based on the data, the plurality of weights including a first weight associated with the first road and a second weight associated with the second road; and transmitting the plurality of weights to a vehicle computing device associated with an autonomous vehicle remote from the system, wherein the vehicle computing device is configured to calculate a route for traversing the road network based on the plurality of weights.

[0092] B: According to the system described in paragraph A, the data further includes real-time vehicle density data associated with the first road, and the real-time vehicle density data is determined based on at least one of the following: location data or sensor data received from a second vehicle associated with the second autonomous vehicle.

[0093] C: According to the system described in paragraph A or B, determining the first weight includes: determining the expected travel time associated with the first road based on data; and determining the first weight based on the expected travel time.

[0094] D: The system according to any one of paragraphs A and C, wherein: the vehicle computing device is further configured to determine a first estimated time of arrival associated with the route, and the operation further includes: calculating a second route for traversing the road network based on multiple weights; determining a second estimated time of arrival for the second route; and sending the second estimated time of arrival to the vehicle computing device, wherein the vehicle computing device is configured to display the second estimated time of arrival.

[0095] E: The system according to any one of paragraphs A and D, wherein: the data further includes road condition data associated with the first road, the road condition data including at least one of road surface quality data, vehicle density data, or weather data.

[0096] F: One or more non-transitory computer-readable media storing instructions executable by one or more processors, wherein, when executed, the instructions cause the one or more processors to perform operations including: receiving data associated with a first road; determining a first weight associated with the first road based on the data; sending the first weight to a vehicle computing device associated with a vehicle, wherein the vehicle computing device is configured to: determine a route for traversing a road network including the first road and an estimated time of arrival for the route based on the first weight; and at least one of: controlling the vehicle based on the route, or displaying the estimated time of arrival.

[0097] G: According to one or more non-transitory computer-readable media as described in paragraph F, the operation further includes: receiving state data associated with the second road; determining a second weight associated with the second road based on the state data; and providing the second weight to a vehicle computing device.

[0098] H: One or more non-transitory computer-readable media as described in paragraph G, wherein the data includes at least one of the following: road surface quality data, fleet density data associated with a fleet of vehicles, or weather data.

[0099] I: According to any one or more non-transitory computer-readable media in paragraphs F to H, the operation further includes: receiving real-time vehicle density data associated with the first road, and determining a first weight based on the real-time vehicle density data.

[0100] J: According to one or more non-transitory computer-readable media as described in paragraph I, wherein the real-time vehicle density data is determined based on at least one of the following: location data or sensor data received from sensors associated with the second vehicle.

[0101] K: One or more non-transitory computer-readable media according to any one of paragraphs FJ, wherein: the data includes real-time traffic data associated with the first road and historical traffic data associated with the first road, and determining the first weight includes: determining the expected travel time based on historical traffic data, and adjusting the expected travel time based on real-time traffic data.

[0102] L: One or more non-transitory computer-readable media according to any one of paragraphs FK, wherein the operation further includes: determining a transition probability based on data, the transition probability being associated with a transition from a first lane associated with a first road to a second lane associated with a first road; and sending the transition probability to a vehicle computing device.

[0103] M: According to any one of paragraphs F to L, the operation further includes: calculating a second route for traversing the road network and a second estimated time of arrival associated with the second route based on a first weight; and providing the second route and the second estimated time of arrival to a vehicle computing device, wherein the vehicle computing device is configured to generate display data based on the second route and the second estimated time of arrival.

[0104] N: According to any one or more non-transitory computer-readable media in paragraphs FM, the operation further includes: receiving updated data representing modifications to the first road; determining an updated first weight based at least in part on the updated data; and sending the updated first weight to the vehicle.

[0105] O: According to one or more non-transitory computer-readable media as described in paragraph N, the updated first weight is sent to the vehicle based on determining that the updated first weight deviates from the first weight by a threshold amount.

[0106] P: One or more non-transitory computer-readable media according to any one of paragraphs FO, wherein determining the first weight comprises: determining a second weight associated with the first road; and determining the first weight by perturbing the first weight with a first amplitude, wherein the first amplitude is randomly determined; wherein the operation further comprises: determining a third weight by perturbing the first weight with a second amplitude, wherein the second amplitude is randomly determined; and sending the third weight to a second vehicle computing device associated with the second vehicle.

[0107] Q: One or more non-transitory computer-readable media according to any one of paragraphs FP, wherein determining the first weight includes: determining a second weight associated with a first road; and determining the first weight by perturbing the first weight with a first amplitude; wherein the operation further includes: determining a third weight by perturbing the first weight with a second amplitude; and sending the third weight to a second vehicle computing device associated with a second vehicle, and wherein the first amplitude and the second amplitude are determined based on the distribution of a fleet of vehicles and the second vehicle across a road network including the first road.

[0108] R: A method comprising: receiving data associated with a first road; determining a first weight associated with the first road based on the data; sending the first weight to a vehicle computing device associated with a vehicle, wherein the vehicle computing device is configured to: determine a route for traversing a road network including the first road and an estimated time of arrival for the route based on the first weight; and at least one of: controlling the vehicle based on the route, or displaying the estimated time of arrival.

[0109] S: The method according to paragraph R further includes: receiving state data associated with the second road; determining a second weight associated with the second road based on the state data; and providing the second weight to a vehicle computing device.

[0110] T: The method according to paragraph S, wherein: receiving condition data associated with a first road, wherein the condition data includes at least one of the following: road condition data, road surface quality data, vehicle density data, or weather data; and determining a first weight based on the condition data. in conclusion

[0111] Although one or more examples of the techniques described herein have been described, various modifications, additions, substitutions, and equivalents thereof are also included within the scope of the techniques described herein.

[0112] In the description of the examples, reference is made to the accompanying drawings, which form part of the description, illustrating specific examples of the claimed subject matter by way of illustration. It should be understood that other examples may be used, and changes or alterations such as structural modifications may be made. Such examples, changes, or alterations do not necessarily deviate from the scope of the claimed subject matter. Although the steps herein may be presented in a certain order, in some cases the order may be changed so that certain inputs are provided at different times or in a different order without altering the function of the described system and method. The disclosed processes may also be performed in a different order. Furthermore, it is not necessary to perform the various calculations herein in the disclosed order, and other examples using alternative orders of calculations can be readily implemented. In addition to being reordered, these calculations may also be decomposed into sub-computations with the same results.

[0113] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described. Rather, specific features and actions are disclosed as exemplary forms for implementing the claims.

[0114] The components described herein represent instructions that can be stored in any type of computer-readable medium and can be implemented in software and / or hardware. All the methods and processes described above can be embodied in software code modules and / or computer-executable instructions executed by one or more computers or processors, hardware, or some combination thereof, and are fully automated via these software code modules and / or computer-executable instructions. Some or all of the methods may alternatively be embodied in dedicated computer hardware.

[0115] Unless otherwise explicitly stated, conditional language (e.g., “can,” “able,” “may,” or “possibly”) is understood in context to indicate that certain features, elements, and / or steps are included in some examples but not in others. Therefore, such conditional language is generally not intended to imply that certain features, elements, and / or steps are required in any way for one or more examples, or that one or more examples must include logic for determining whether certain features, elements, and / or steps are included in or will be executed in any particular example, with or without user input or prompts.

[0116] Unless otherwise explicitly stated, connecting language (e.g., the phrase "at least one of X, Y, or Z") should be understood to mean that items, terms, etc., can be X, Y, or Z, or any combination thereof, including plural of each element. Unless explicitly stated as singular, "a" means both singular and plural.

[0117] Any routine description, element, or block depicted in the flowcharts described herein and / or in the accompanying drawings should be understood as potentially representing a module, segment, or portion of code comprising one or more computable instructions for implementing a particular logical function or element in the routine. Alternative implementations are included within the scope of the examples described herein, wherein elements or functions may be omitted or performed in a different order than shown or discussed, including substantially synchronous execution, execution in reverse order, with additional operations, or omitted operations, depending on the functionality involved, as will be understood by those skilled in the art.

[0118] Many variations and modifications can be made to the above examples, and their elements should be understood as existing in other acceptable examples. All such modifications and variations are intended to be included herein, within the scope of this disclosure, and protected by the appended claims.

Claims

1. A system comprising: One or more processors; as well as One or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the system to perform operations, including: Receive data associated with the first road; Based on the data, a first weight associated with the first road is determined; The first weight is sent to a vehicle computing device associated with the vehicle, wherein the vehicle computing device is configured to: Based on the first weight, a route for traversing the road network including the first road and an estimated arrival time of the route are determined; and At least one of the following: Control the vehicle based on the route, or This displays the estimated arrival time.

2. The system according to claim 1, wherein the operation further includes: Receive status data associated with the second road; A second weight associated with the second road is determined based on the state data; as well as The second weight is provided to the vehicle computing device.

3. The system according to claim 2, wherein, The data includes at least one of the following: road surface quality data, fleet density data associated with a fleet including the vehicle, or weather data.

4. The system according to any one of claims 1-3, wherein the operation further comprises: Receive real-time vehicle density data associated with the first road, and The first weight is determined based on the real-time vehicle density data.

5. The system according to claim 4, wherein, The real-time vehicle density data is determined based on at least one of the following: location data or sensor data received from sensors associated with the second vehicle.

6. The system according to any one of claims 1-5, wherein: The data includes real-time traffic data associated with the first road and historical traffic data associated with the first road, and Determining the first weight includes: Determine the expected travel time, which is based on the historical traffic data, and The expected travel time is adjusted based on the real-time traffic data.

7. The system according to any one of claims 1-6, wherein, The operation also includes: A transition probability is determined based on the data, the transition probability being associated with a transition from a first lane associated with the first road to a second lane associated with the first road; and The conversion probability is sent to the vehicle computing device.

8. The system according to any one of claims 1-7, wherein the operation further comprises: A second route for traversing the road network and a second estimated arrival time associated with the second route are calculated based on the first weight; as well as The vehicle computing device is provided with the second route and the second estimated arrival time, wherein the vehicle computing device is configured to generate display data based on the second route and the second estimated arrival time.

9. The system according to any one of claims 1-8, wherein the operation further comprises: Receive updated data indicating modifications to the first road; as well as The updated first weight is determined at least in part based on the updated data; as well as The updated first weight is sent to the vehicle.

10. The system according to claim 9, wherein, Sending the updated first weight to the vehicle is based on determining that the updated first weight deviates from the first weight by a threshold amount.

11. The system according to any one of claims 1-10, wherein, Determining the first weight includes: Determine the second weight associated with the first road; and The first weight is determined by perturbing the first weight with a first amplitude, wherein the first amplitude is randomly determined; The operation further includes: The third weight is determined by perturbing the first weight with a second amplitude, wherein the second amplitude is randomly determined; and The third weight is sent to the second vehicle computing device associated with the second vehicle.

12. The system according to any one of claims 1-11, wherein, Determining the first weight includes: Determine the second weight associated with the first road; and The first weight is determined by perturbing the first weight with a first amplitude; The operation further includes: The third weight is determined by perturbing the first weight with a second amplitude; and The third weight is sent to the second vehicle computing device associated with the second vehicle, and The first amplitude and the second amplitude are determined based on the distribution of the convoy including the vehicle and the second vehicle across the road network including the first road.

13. A method comprising: Receive data associated with the first road; Based on the data, a first weight associated with the first road is determined; The first weight is sent to a vehicle computing device associated with the vehicle, wherein the vehicle computing device is configured to: Based on the first weight, a route for traversing the road network including the first road and an estimated arrival time of the route are determined; and At least one of the following: Control the vehicle based on the route, or This displays the estimated arrival time.

14. The method of claim 13, further comprising: Receive status data associated with the second road; A second weight associated with the second road is determined based on the state data; as well as The second weight is provided to the vehicle computing device.

15. A non-transitory computer-readable medium having instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 13-14.

Images