Vehicle routing with dynamic selection of turns across oncoming traffic

Abstract

Presented herein are systems, methods, and other embodiments for vehicle route scheduling and navigation with dynamic selection of turns across oncoming traffic. In one embodiment, the method includes, during planning of a vehicle route from an arrival link through nodes of a graph representing a road network, determining, for a departure link, that a path of the vehicle from the arrival link to the departure link crosses oncoming traffic, in response to determining that the path of the vehicle crosses oncoming traffic, adding an additional delay of the departure link to a route objective function representing the vehicle route, selecting a route that includes a path that crosses oncoming traffic as an optimal route between a first location and a second location, including the optimal route in a delivery schedule for the vehicle, and submitting the delivery schedule for execution.

Description

[Background technology]

[0001] background Turning across oncoming traffic causes delays and increases the risk of collisions, so delivery convoy operators implement "hard" rules for turning across traffic in their vehicle routing, navigation, and delivery scheduling systems. However, these inflexible "hard" rules for turning across traffic introduce unnecessary complexity and reduce flexibility in vehicle routing, navigation, and delivery scheduling. Summary of the Invention [Problem to be solved by the invention]

[0002] What is needed, therefore, is a system and method that intelligently allows a turn across traffic when such a turn is advantageous. [Means for solving the problem]

[0003] overview In one embodiment, a non-transitory computer-readable medium having computer-executable instructions stored thereon is presented that, when executed by at least one processor of the computer, causes the computer to: determine, for a departure link, during planning of a vehicle route from an arrival link through nodes of a graph representing a road network, that a path of the vehicle from the arrival link to the departure link will cross oncoming traffic; in response to determining that the path of the vehicle will cross oncoming traffic, add an additional estimated delay of the departure link to a route objective function representing the vehicle route; select a route that includes a path that crosses oncoming traffic as an optimal route between a first location and a second location; include the optimal route as part of a delivery schedule for the vehicle; and submit the delivery schedule for execution.

[0004] In one embodiment of the non-transitory computer-readable medium, the instructions for causing a computer to determine, for an outgoing link, that a path of the vehicle from the incoming link to the outgoing link crosses oncoming traffic include instructions for causing a computer to obtain an indication of a driving side of the road applicable to the graph; obtain a compass bearing of each incoming and outgoing link to a node that includes the incoming link and the outgoing link; determine that the compass bearing of the incoming link and the compass bearing of the outgoing link indicate that the path is a turn in a direction opposite to the driving side of the road; and determine that a first compass bearing of a first link entering the node and a first link exiting the node is opposite to the compass bearing of the incoming link.

[0005] In one embodiment of the non-transitory computer-readable medium, the instructions further cause the computer to determine whether oncoming traffic is light and to control the additional estimated delay to be (i) a preset standard delay if oncoming traffic is light and (ii) a dynamically generated measure of delay based on estimated traffic density if oncoming traffic is not light.

[0006] In one embodiment of the non-transitory computer-readable medium, the instructions to cause the computer to add the additional estimated delay for the outgoing link include instructions to cause the computer to either (i) obtain a preset standard delay for the traffic crossing turn that results in the estimated delay, or (ii) calculate the additional estimated delay based at least in part on historical speeds and speed limits of oncoming traffic.

[0007] In one embodiment, the non-transitory computer-readable medium further includes instructions that, when executed by at least the processor, cause the computer to add an additional cost of the outgoing link to a route objective function representing the vehicle route in response to determining that the vehicle's path crosses oncoming traffic.

[0008] In one embodiment of the non-transitory computer readable medium, the instructions for transmitting the delivery schedule for execution include instructions for transmitting a load plan to a warehouse computing system for selection and loading of items to be delivered in a delivery vehicle, and instructions for transmitting a delivery route to a mobile device associated with the delivery vehicle to display the delivery route to a driver and to have the driver navigate the vehicle across oncoming traffic.

[0009] In one embodiment of the non-transitory computer readable medium, the instructions for transmitting the delivery schedule for execution include instructions for transmitting the delivery schedule to an autonomous delivery vehicle and navigating the autonomous delivery vehicle across oncoming traffic to a delivery stop according to the delivery schedule.

[0010] In one embodiment, a computer-implemented method includes, during planning of a vehicle route from an arrival link through nodes of a graph representing a road network, determining, for a departure link, that a path of the vehicle from the arrival link to the departure link will cross oncoming traffic; in response to determining that the path of the vehicle will cross oncoming traffic, adding an additional estimated delay of the departure link to a route objective function representing the vehicle route; selecting a route that includes a path that crosses oncoming traffic as an optimal route between the first location and the second location; including the optimal route as part of a delivery schedule for the vehicle; and submitting the delivery schedule for execution.

[0011] In one embodiment, the computer-implemented method further includes navigating the autonomous delivery vehicle through a vehicle path from the arrival link to the departure link across oncoming traffic to the delivery stop.

[0012] In one embodiment of the computer-implemented method, adding the additional estimated delay of the outgoing link includes calculating the estimated delay based at least in part on historical traffic speeds of one or more links that comprise opposing traffic during a time period when the vehicle route arrives at the node.

[0013] In one embodiment, the computer-implemented method further includes adding an additional cost of the outgoing link to a route objective function representing the vehicle route in response to determining that the path of the vehicle crosses oncoming traffic.

[0014] In one embodiment of the computer-implemented method, for an outgoing link, determining that a path of the vehicle from the incoming link to the outgoing link crosses oncoming traffic includes obtaining an indication of a driving side of the road applicable to the graph, obtaining a compass bearing of each incoming and outgoing link to a node that includes the incoming link and the outgoing link, determining that the compass bearing of the incoming link and the compass bearing of the outgoing link indicate that the path is a turn in a direction opposite to the driving side of the road, and determining that a first compass bearing of a first link entering the node and a first link exiting the node is opposite to the compass bearing of the incoming link.

[0015] In one embodiment, a computing system includes a processor, a memory operatively connected to the processor, an autonomous vehicle controlled by the processor, and a non-transitory computer-readable medium operatively connected to the processor and the memory, the non-transitory computer-readable medium storing computer-executable instructions that, when executed by at least one processor of the computer, cause the computing system to: determine, for a departure link, that a path of the autonomous vehicle from the arrival link to the departure link will cross oncoming traffic; in response to determining that the path crosses oncoming traffic, add an additional estimated delay of the departure link to a route objective function representing the route; select a route that includes the path that crosses oncoming traffic as an optimal route between the first location and the second location; and operate the autonomous vehicle through the path from the arrival link to the departure link, crossing oncoming traffic.

[0016] In one embodiment of the computing system, the instructions further cause the computing system to determine whether oncoming traffic has low traffic volume and control the additional estimated delay to be (i) a pre-set standard delay if oncoming traffic has low traffic volume, and (ii) a dynamically generated measure of delay based on estimated traffic density if oncoming traffic does not have low traffic volume.

[0017] In one embodiment of the computing system, for an outgoing link, the instructions for causing the computing system to determine that a path of the autonomous vehicle from the incoming link to the outgoing link crosses oncoming traffic include instructions for causing the computing system to obtain an indication of a driving side of the road applicable to the graph; obtain a compass bearing for each incoming and outgoing link to a node that includes the incoming link and the outgoing link; determine that the compass bearing of the incoming link and the compass bearing of the outgoing link indicate that the path is a turn in a direction opposite the driving side of the road; and determine that a first compass bearing of a first link entering the node and a first link exiting the node is opposite the compass bearing of the incoming link.

[0018] The accompanying drawings, which are incorporated herein by reference, illustrate various systems, methods, and other embodiments of the present disclosure. It will be apparent that the element boundaries (e.g., boxes, boxes, or other shapes) depicted in the drawings represent one embodiment of the boundaries. In some embodiments, an element may be realized as multiple elements, or multiple elements may be realized as an element. In some embodiments, an element shown as an internal component of another element may be realized as an external component, or vice versa. Additionally, the depictions of elements may not be to scale. [Brief description of the drawings]

[0019] [Figure 1]FIG. 1 illustrates an embodiment of a computing system associated with scheduling and navigating vehicle routes with dynamic selection of turns across opposing traffic. [Diagram 2] FIG. 1 illustrates an example graph representing a road map associated with vehicle route scheduling and navigation with dynamic selection of turns across oncoming traffic (including graph details). [Diagram 3] FIG. 1 illustrates an embodiment of a method associated with scheduling and navigating a vehicle route with dynamic selection of turns across opposing traffic. [Figure 4] FIG. 2 illustrates an embodiment of a method for determining that a route from an arrival link to a departure link crosses oncoming traffic associated with scheduling and navigating a vehicle route with dynamic selection of turns across oncoming traffic. [Figure 5A] FIG. 2 illustrates an example of a traffic crossing turn route through a four-way intersection. [Figure 5B] FIG. 1 illustrates an example of a non-cross-traffic turning route through a T-intersection. [Figure 5C] FIG. 2 illustrates an example of a cross-traffic maneuver route through a four-way intersection with multiple lanes. [Figure 5D] FIG. 2 illustrates an example of a non-cross-traffic turning route through a four-way intersection. [Figure 5E] FIG. 1 illustrates an example of a traffic crossing turnaround route through a T-junction. [Figure 5F] FIG. 1 illustrates an example of a non-cross-traffic turn route through an intersection including a one-way road. [Figure 5G] FIG. 1 is a diagram showing an example of a traffic crossing U-turn route passing through a four-way intersection. [Figure 6] FIG. 1 illustrates an example autonomous vehicle control system configured and / or programmed to operate according to one or more of the systems and methods described herein and / or equivalents. [Figure 7]FIG. 1 illustrates an example mobile device configured and / or programmed with one or more of the systems and methods described herein and / or equivalents. [Figure 8] FIG. 1 illustrates an exemplary computing system configured and / or programmed with one or more of the exemplary systems and methods described herein and / or equivalents as a dedicated computing device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0020] Detailed Description Described herein are systems and methods that enable vehicle route scheduling and navigation with dynamic selection of turns across opposing traffic. For example, vehicle routings generated by the systems and methods described herein intelligently incorporate turns across opposing (or oncoming) traffic when the cross-traffic turn is more advantageous than a routing alternative that avoids it. In one embodiment, described herein are route scheduling and navigation systems and methods that enable solving the Multiple Traveling Salesman Problem (MTSP) with cross-traffic turns.

[0021] The historical travel times of the available road network required to provide accurate travel times to the MTSP solvers (retail distribution, utilities) do not include additional delays due to turns. Turns across oncoming traffic on busy roads can result in significant delays and risk of accidents. It may therefore be desirable to reconfigure transportation missions to minimize the overall need to turn across traffic and / or reroute vehicles between missions to avoid such turns. Accounting for these hidden delays when solving the transportation problem reduces both the total travel time and the margin for accidents. As used herein with respect to traffic, the terms "opposing" and "oncoming" are synonymous.

[0022] In one embodiment, the systems and methods described herein identify turns that cross traffic while calculating a route and assign estimated delays to such turns. The additional delays are passed to the routing and scheduling objective function, causing the solver to adapt the resulting schedule so that the impact of "crossing opposite traffic" turns is minimized. However, a "hard" rule against turning across traffic in all cases may add unnecessary complexity and associated delays to a vehicle's route. Therefore, it may be desirable to have a system and method that generates routes that incorporate turns across traffic only in appropriate circumstances (e.g., when opposite traffic has low traffic volume, resulting in low delays and increased risk, or when opposite traffic has higher traffic volume but no other routing options with low objective cost exist).

[0023] In one embodiment of the systems and methods described herein, the dynamic model takes into account the fact that turn times are strongly affected by traffic density, for example, in which (1) links are tagged with their respective compass headings so that the routing algorithm can quickly determine if a candidate route through a node crosses oncoming traffic, (2) links are tagged as residential or non-residential so that turns across residential traffic typically do not incur delays, and (3) links are tagged with speed limits so that turn delays can be estimated from the ratio of the speed limit to the historical speed.

[0024] Turns across opposite traffic are a source of delays and accidents that are not captured in the current traffic models used by commercial MTSP solvers. The systems and methods described herein include this source of delay and reorganize the MTSP solution to minimize the total number of slow-speed risk-prone "cross opposite traffic" turns, either by reconfiguring vehicle-to-vehicle work to reduce the number of slow turns or by routing vehicles around them. The result is a more accurate model of the real world that allows the solver to generate solutions with lower actual travel times and higher safety. Notably, the systems and methods described herein do not apply "hard" avoidance of turns across traffic. Instead, the systems and methods described herein enable dynamic avoidance of turns across traffic. Turns across traffic are avoided only if a better alternative can be found.

[0025] In one embodiment, the systems and methods herein perform a pre-processing stage to create a graph that is used as input to a shortest path solver algorithm (such as Dijkstra's algorithm) that generates routes in the route computation stage. In one embodiment, the pre-processing stage computes a "residential" flag from the source road data and stores the flag for each link. In one embodiment, the pre-processing stage obtains speed limits from the source road data and stores the speed limits for each link. In one embodiment, when building the graph, the pre-processing stage obtains the endpoint coordinates for each link and uses these to tag each link with a compass bearing.

[0026] In one embodiment, the systems and methods herein implement a route calculation stage by running a path solver algorithm to generate a route. In one embodiment, when the route calculation stage develops or processes links arriving at a node, the calculation stage checks, for each outgoing link, whether the arriving non-residential road crosses the path of the vehicle crossing the intersection. If so, the calculation stage calculates an estimated delay and adds the delay to the objective function. If reducing traffic accidents is of significant importance, another fee may be added as a number to the objective function along with the delay.

[0027] No act or function described or claimed herein is performed by the human mind, and any interpretation that any act or function may be performed in the human mind is inconsistent with and contrary to this disclosure.

[0028] Example Environment FIG. 1 illustrates one embodiment of a computing system 100 associated with scheduling and navigating vehicle routes with dynamic selection of turns across opposing traffic.

[0029] In one embodiment, the system 100 includes a scheduling, dispatch, and routing system 105 connected to an enterprise network 115 by the Internet 110 (or another suitable communication network or combination of networks). In one embodiment, the scheduling, dispatch, and routing system 105 may be Oracle®'s Real-Time Scheduler (RTS), UPS®'s On-Road Integrated Optimization and Navigation (ORION), or other system configured to execute a method for scheduling and navigating vehicle routes with dynamic selection of turns across opposing traffic. In one embodiment, the scheduling, dispatch, and routing system 105 includes various systems and components including a dynamic traffic crossing turn component 120, other system components 125, a data store 130, and a web interface server 135.

[0030] In one embodiment, the dynamic traffic crossing turn component 120 comprises one or more components configured to implement the methods, functions, and features described herein associated with route scheduling and navigation by solving MTSPs involving crossing turns. The dynamic traffic crossing turn component 120 may comprise a route generation engine 170 configured to develop a shortest path between nodes of a road network graph that dynamically includes a crossing turn in the route according to the systems and methods described herein. The shortest path is not necessarily the shortest in terms of travel distance. In one embodiment, the shortest path solver operates to search for a "shortest" path based on an objective cost function at which the objective cost of the trip is lowest. The objective cost function may include inputs of travel time, travel distance, crossing turns or other traffic impediments, or other items that make up the overall burden of the trip along the route. The dynamic traffic crossing turn component 120 may comprise a route generation engine 170 that identifies a lowest-cost route between geographic locations in a road network represented as a graph. The dynamic cross traffic turns component 120 may include a scheduling engine 173 that determines which delivery items are assigned to which routes and the order of delivery of those items. The dynamic cross traffic turns component 120 may include a map augmentation (pre-processing) module that generates information used by the systems and methods described herein for dynamic inclusion of cross traffic turns in vehicle routing and uses this information to insert into a graph representing the road network. The dynamic cross traffic turns component 120 may include a map database 180 that stores one or more graphs representing a road network that may be configured for dynamic inclusion of cross traffic turns in vehicle routing.

[0031] Each of the components of the scheduling, dispatching, and routing system 105 is configured with logic to perform the functions that it is described as implementing. In one embodiment, each of the components of the scheduling, dispatching, and routing system 105 may be implemented as a set of one or more software modules executed by one or more computing devices specially configured for such execution. In one embodiment, the components of the scheduling, dispatching, and routing system 105 are implemented on one or more hardware computing devices or hosts interconnected by a data network. For example, the components of the scheduling, dispatching, and routing system 105 may be adapted to be executed by a central processing unit (CPU) or networked computing devices of one or more computing hardware forms, such as general purpose forms, high density input / output (I / O) forms, graphics processing unit (GPU) forms, and high performance computing (HPC) forms. In one embodiment, each of the components of the scheduling, dispatching, and routing system 105 is implemented by one or more special purpose computing devices. In one embodiment, some or all of the components of the scheduling, dispatching, and routing system 105 are implemented on a common (or shared) computing device, although they are depicted as discrete units in FIG. 1. In one embodiment, the components of the scheduling, dispatching, and routing system 105 may be implemented across multiple computing devices. In one embodiment, the scheduling, dispatching, and routing system 105 may be implemented as a service on a cloud infrastructure.In one embodiment, the scheduling, dispatching, and routing system 105 may be hosted by a dedicated third party, for example in an Infrastructure-as-a-Service (IAAS), Platform-as-a-Service (PAAS), or Software-as-a-Service (SAAS) architecture. In one embodiment, the scheduling, dispatching, and routing system 105 may be implemented on-premise infrastructure, such as a set of one or more servers in an enterprise network 115 dedicated to operating the scheduling, dispatching, and routing system 105.

[0032] In one embodiment, the components of the scheduling, dispatching, and routing system 105 communicate with each other by electronic messages or signals. These electronic messages or signals may be configured as function or procedure calls, such as, for example, application programming interface (API) calls, to access the features or data of the components. In one embodiment, these electronic messages or signals are transmitted between hosts in a format compatible with Transmission Control Protocol / Internet Protocol (TCP / IP) or other computer networking protocols. Each component of the scheduling, dispatching, and routing system 105 (i) generates or composes electronic messages or signals that issue commands or requests to another component, (ii) uses the infrastructure of the scheduling, dispatching, and routing system 105 to transmit the messages or signals to other components, and (iii) analyzes the content of received electronic messages or signals to identify commands or requests that the component can execute, and automatically executes the commands or requests in response to the command identification.

[0033] The API calls may include queries to a database, which, if executed on a graph, may be constructed and executed in, for example, Oracle's Property Graph Query Language (PGQL) and its associated runtimes, GraphQL and its associated runtimes, or any other suitable graph query environment.

[0034] The enterprise network 115 may be associated with a business, such as a delivery service or other entity that operates a fleet of vehicles. For simplicity and clarity of illustration, the enterprise network 115 is represented by an on-site local area network 140 to which one or more personal computers 145 or servers 150 are operatively connected, along with one or more remote user computers 155, mobile devices 160, handheld delivery information terminals 161, or autonomous or self-driving vehicles 165 that are connected to the enterprise network 115 through the Internet 110. Each personal computer 145, remote user computer 155, mobile device 160, or handheld delivery information terminal 161 is generally dedicated to a particular end user, such as an employee or contractor, associated with the business, although this specialization is not required. The personal computers 145 and remote user computers 155 can be, for example, desktop computers, laptop computers, tablet computers, or other devices that can connect to the local area network 140 or the Internet 110. The mobile device 160 may be, for example, a smartphone, tablet computer, mobile phone, or other handheld portable computing device capable of connecting to the local area network 140 or the Internet 110 through a wireless network, such as a cellular network, Wi-Fi, or Bluetooth®. The handheld delivery information terminal 161 may be, for example, a portable combination of a barcode / QR / other code scanning device, a delivery information access device, and a GPS navigation device, such as a USPS® Mobile Delivery Device (MDD), a UPS® Delivery Information Acquisition Device (DIAD), or other similar device.

[0035] Users of the enterprise network 115 interface with the scheduling, dispatch, and routing system 105 via the Internet 110 (or another suitable communications network or combination of networks). In one embodiment, information or applications provided by the scheduling, dispatch, and routing system 105 may be accessed by remote computing systems (such as systems of the enterprise network 115, including the autonomous vehicle 165) through a web interface server 135. In one embodiment, the remote computing systems may send requests to and receive responses from the web interface server 135. In one example, access to the information or applications may be provided through the use of a web browser on the personal computer 145, the remote user computer 155, the mobile device 160, or the autonomous vehicle 165. In one example, access to the information or applications may be provided through the use of a dedicated client application specific to the scheduling, dispatch, and routing system 105 running on the personal computer 145, the remote user computer 155, the mobile device 160, or the autonomous vehicle 165. For example, these computing devices 145, 155, 160, 161 of the enterprise network 115 can request a display of the delivery schedule (in whole or in part) in a graphical user interface. In one example, communications are exchanged between the web interface server 135 and the personal computer 145, server 150, remote user computer 155, or mobile device 160, and may be in the form of, for example, Remote Representational State Transfer (REST) ​​requests using Java Script Object Notation (JSON) as the data exchange format, or Simple Object Access Protocol (SOAP) requests between XML servers. For example, the computers 145, 150, 155 of the enterprise network 110 can request a delivery schedule.

[0036] In one embodiment, data store 160 includes one or more databases, such as a map database 180 configured to store and provide maps, as well as other databases configured to store and provide routes, load plans, shipping information, cargo manifests, vehicles or service crews, or other information used by scheduling, dispatch, and routing system 105. In one embodiment, the databases used herein are Oracle® databases. In some exemplary configurations, data store 160 may be implemented using one or more Oracle® Exadata computer configurations, network attached storage (NAS) devices, and / or other dedicated server devices.

[0037] In one embodiment, the routing of one or more autonomous vehicles 165 may be controlled by the scheduling, dispatch, and routing system 105. The autonomous vehicles 165 may be partially autonomous or fully autonomous. The autonomous vehicles 165 may be delivery vehicles, cargo vehicles, construction vehicles, refuse collection vehicles, personnel transport vehicles, public transportation vehicles, ride-share or taxi vehicles, personal transport vehicles, or other self-driving vehicles.

[0038] Graphs, Nodes, and Links In one embodiment, a graph data structure may represent a road network or road map as a set of interconnected nodes and links. In a graph data structure representing a road network, a node is a data structure that represents a geographic location where a turn can be made, such as a road intersection or turn. In a graph data structure representing a road network, a link (or directed edge) is a data structure that represents a traffic route between nodes (intersections, turns, or other geographic locations) that are adjacent to each other in the graph, or nodes that are no more than one link apart. Note that the links are directed.

[0039] In one embodiment, the road network is represented as a graph data structure in a graph database, with the accompanying road source data describing the map (or graph), traffic routes (or links), and intersections (or nodes) and their associated characteristics stored in data structures describing these components. For example, map database 180 may be a graph database that stores one or more road networks (or maps) in this form. The graph, link, and node data structures may be provided with additional data fields to accommodate the particular information used by the methods and systems described herein.

[0040] 2 illustrates an example graph 200 representing an example road network associated with vehicle route scheduling and navigation with dynamic selection of turns across oncoming traffic, including a close-up 205 of a portion 210 of the graph 200 superimposed on a visualization of a corresponding portion of the example road network 215. The graph 200 is composed of nodes 220 that represent particular intersections 225 (or other geographic features, such as turns) in the example road network 215, and links 230 that represent particular directed road segments 235 in the example road network 215. In one embodiment, the nodes 220 may also represent delivery pickup, delivery, or service locations (e.g., particular addresses) along the road network. Discussions of nodes referring to intersections may also be understood to represent road turns, particular address locations, and other geographic features of the road network represented by the graph.

[0041] In the example graph 200, the nodes 220 may be represented as node data structures that describe the underlying intersections 225, such as node data structure 240. In one embodiment, a node data structure, such as node data structure 240, is configured to include data structures such as a node identifier (nodeID) field or other data structure for storing a value uniquely associated with the node, a coordinate (nodeCoordinates) field or other data structure for storing coordinate values ​​(such as latitude and longitude) of the geographic location of the underlying intersection 225 represented by the node, a list of incoming links (nodeIncomingLinks) and outgoing links (nodeOutgingLinks), least-cost (fastest / shortest) routes to all other nodes in the graph (nodeRoutes) and associated characteristics such as travel time and distance (or other cost to reach the node from an origin node) for each route, and other data structures that represent other characteristics of the node.

[0042] In the example graph 200, the links 230 may be represented as link data structures, such as link data structure 245, that describe the underlying traffic route (or road segment) 235. In one embodiment, the link data structures, such as link data structure 245, are configured to include data structures that describe particular characteristics of the underlying traffic route 235. The link data structure 245 may be configured to include a link identifier (linkID) field or other data structure. A value of the link identifier data structure is uniquely associated with a link in the graph. The link data structure 245 may be configured to include an "origin" node ID (nodeA_ID) field or other data structure that indicates the node from which the link originates, and an "end" node ID (nodeB_ID) field or other data structure that indicates the node to which the link terminates. The "origin" node ID and "end" node ID data structures together describe the origin and end, respectively, of a traffic movement represented by the link along a road segment. The link data structure 245 may be configured to include a speed limit (linkSpeedLimit) field or other data structure indicating the legal speed limit along the road segment represented by the link. The link data structure 245 may be configured to include a direction (linkDirection) field or other data structure indicating the compass direction of travel along the road segment represented by the link. The link data structure 245 may be configured to include a residential (linkResidential) flag or other data structure indicating whether the road segment represented by the link is considered to have only "residential" traffic. The residential flag indicates whether the traffic movement along the link is light traffic (residential) or not (non-residential), given that traffic along residential streets is generally light traffic and experiences little turn delays across oncoming traffic. The link data structure 245 may be configured to include a toll (linkToll) field or other data structure. A "toll" as used herein is a penalty associated with travel along the road segment represented by a given link.Link data structure 245 may be configured to include additional data structures that represent other characteristics of the links.

[0043] Exemplary Methods In one embodiment, each step of the computer implemented method described herein may be performed by a processor (such as processor 810 as shown and described with reference to FIG. 8 ) of one or more computing devices that (i) accesses memory (such as memory 815 and / or other computing device components shown and described with reference to FIG. 8 ) and (ii) is configured with logic (such as dynamic traffic cross-direction vehicle route scheduling and navigation logic 830 as shown and described with reference to FIG. 8 ) to cause the system to perform the steps of the method. For example, the processor performs the steps of the computer implemented method described herein by accessing and reading and writing the memory. These steps may include (i) obtaining any required information, (ii) calculating, determining, generating, classifying, or creating any data, and (iii) storing any calculated, determined, generated, classified, or created data for later use. References to storage or storing refer to storage as a data structure in the memory or storage / disk of a computing device (such as the memory 815 or storage / disk 835 of the computing device 805 or remote computer 865 shown and described with reference to FIG. 8, or the data store 130 shown and described with reference to FIG. 1).

[0044] In one embodiment, each subsequent step of the method is initiated automatically in response to analysis of received signals or acquired and stored data indicating that a preceding step has been performed at least to the extent necessary for the initiation of the subsequent step. Typically, the received signals or acquired and stored data indicate completion of a preceding step.

[0045] 3 illustrates one embodiment of a method 300 associated with scheduling and navigating vehicle routes with dynamic selection of turns across opposing traffic. In one embodiment, the steps of method 300 are performed by scheduling and dispatch system 105 (as shown and described with reference to FIG. 1 ) and at least in part by dynamic traffic cross turning component 120. In one embodiment, dynamic traffic cross turning component 120 is implemented by a dedicated computing device (such as computing device 805) having dynamic traffic cross turning vehicle route scheduling and navigation logic configured thereon. In one embodiment, dynamic traffic cross turning component 120 is one or more modules of a dedicated computing device having logic 830 configured thereon.

[0046] In one embodiment, the method 300 may be automatically initiated based on various triggers, such as (i) a user (or administrator) of the scheduling, dispatching, and routing system 105 initiating the method 300, (ii) the method 300 being scheduled to start at a prescribed time or time interval (e.g., each day before items are loaded onto a vehicle for delivery), or (iii) in response to receiving a signal over a network or analyzing stored data indicating that a system component of the scheduling, dispatching, and routing system 105 has automatically initiated the method 300 based on the component's internal logic. In one embodiment, the method 300, once initiated, operates iteratively, as described herein, to continuously evaluate alternative routing scenarios for better routes than the current best route and determine travel times for the alternative options. The method can evaluate hundreds of alternative route scenarios per second. Thus, the methods and systems described herein can dynamically evaluate traffic crossing turns in real-time alternative route evaluation and use dynamically included traffic crossing turns in ongoing vehicle navigation. The method 300 begins at start block 305 in response to analyzing a received signal or acquired and stored data and determining that the signal or stored data indicates that the method 300 should begin. Processing continues to process block 310.

[0047] In one embodiment, the operations of process blocks 310, 315, and 320 are performed during planning of a vehicle route by a route generation engine from arrival links through nodes of a graph representing a road network. In one embodiment, planning (or generating or creating) a vehicle route includes processing links or nodes of the graph for inclusion (or exclusion) in a route between the nodes by execution of a shortest path solver step. In one embodiment, the route generation engine is a module of the dynamic traffic cross direction turning component 120, such as the route generation engine 170. In one embodiment, the route generation engine 170 performs the functions described with respect to process blocks 310, 315, and 320. In one embodiment, the route generation engine executes an algorithm for finding the shortest path between nodes in a graph. In one embodiment, the route generation engine executes Dijkstra's algorithm. In one embodiment, the route generation engine executes A * The route generation engine may perform a search algorithm, a breadth-first search, a Warshall-Floyd algorithm, a Bellman-Ford algorithm, a Johnson algorithm, or another algorithm to determine the shortest paths between nodes in the graph. In one embodiment, the route generation engine operates to find the shortest path between each pair of nodes in the graph.

[0048] At process block 310, the processor determines, for the outgoing link, that the path of the vehicle from the arrival link to the outgoing link crosses oncoming traffic.

[0049] An arrival link is a link representing a road segment where a vehicle arrives at the intersection represented by the node. An arrival link is a link directed by route generation engine 170 from a previous node included in the route to the current node. An outgoing link is a link representing a road segment where a vehicle departs the intersection represented by the node. An outgoing link will be included in a route by route generation engine 170 after traffic crossing turn characteristics of the path through the node toward the outgoing link have been developed. Oncoming traffic is traffic passing through the intersection represented by the node from a generally opposite compass direction to traffic entering the intersection from the road segment represented by the arrival link.

[0050] 4 illustrates an embodiment of a method 400 for determining that a route from an arrival link to a departure link crosses oncoming traffic associated with scheduling and navigating a vehicle route with dynamic selection of turns across oncoming traffic. In one embodiment, the steps of method 400 are performed at least in part by route generation engine 170, as well as by execution by a dedicated computing device (such as computing device 805) having dynamic traffic crossing turn vehicle route scheduling and navigation logic 830 configured thereon. Method 400 may be initiated automatically based on various triggers, such as (i) initiation of process block 310 of method 300, (ii) initiation of method 300 by a user (or administrator) of the scheduling, dispatch, and routing system, (iii) route generation engine 170 evaluating a route through an intersection for inclusion in a route from one intersection of the road network to another intersection, or (iv) in response to receiving a signal over the network or analysis of stored data indicating that method 400 is scheduled to be initiated at a prescribed time or time interval. The method 400 begins at start block 405 in response to analyzing a received signal or acquired and stored data and determining that the signal or stored data indicates that the method 400 should begin. Processing continues to process block 410.

[0051] At process block 410, the processor obtains an indication of the driving side of the road applicable to the graph.

[0052] In two-way traffic, the traveling side of the road is the side of the road on which forward travel is permitted. In some jurisdictions, such as the United States, the traveling side of the road is the right side of the road. In some jurisdictions, such as Australia, the traveling side of the road is the left side of the road. Thus, in jurisdictions with right-hand traffic, a turn across traffic (or across oncoming traffic) is a left turn, and in jurisdictions with left-hand traffic, a turn across traffic is a right turn.

[0053] Each graph is associated with a location (such as a city) within the traffic jurisdiction. In one embodiment, the rule of the road (keep left or keep right) is stored in the graph data structure as a property of the graph representing the road network. This road property rule may serve as an indication of the driving side of the road. If the rule of the road is not included in the graph, it may be set as a universal property of the scheduling, dispatching, and routing system 105 by an administrator, for example in the dynamic traffic cross turn component 120. In one embodiment, the processor may configure and execute a query to obtain the indication of the driving side of the road from the graph in the map database 180 (if applicable) or from the system 105 (if applicable). The processor may then store the indication of the driving side of the road in memory or storage for later processing.

[0054] Thus, once the processor has completed obtaining indicators of the driving sides of roads applicable to the graph, processing at process block 410 is complete and processing continues at process block 415.

[0055] At process block 415, the processor obtains the compass bearing of each incoming and outgoing link to the node, including the incoming and outgoing links.

[0056] A compass heading is a vector that defines a direction on the Earth. In one embodiment, each link in the graph is assigned a compass heading, e.g., by the map extension module 175, as described herein, that indicates the direction of traffic flow along the road segment represented by the link. In one embodiment, the compass headings are stored as data structures in the link data structure, e.g., as shown and described with reference to FIG. 2. An incoming link is a link that is directed toward a node and represents traffic flowing along the road segment to the intersection represented by the node. An outgoing link is a link that is directed away from a node and represents traffic flowing along the road segment from the intersection represented by the node. An incoming link belongs to the set of incoming links of the node, and a outgoing link belongs to the set of outgoing links of the node. In one embodiment, the processor may construct and execute a query to obtain a set of links of a node, including both incoming and outgoing links. The processor then retains the set of links in memory for later processing. Then, for each link in the set, the processor constructs and executes a query to obtain a compass heading, and persists the compass heading in memory or storage for later processing.

[0057] Thus, once the processor has completed obtaining compass orientations for each incoming and outgoing link to the node, including the incoming and outgoing links, processing at process block 415 is complete and processing continues to decision block 420.

[0058] At decision block 420, the processor determines whether the compass heading of the incoming link and the compass heading of the outgoing link indicate that the route is a turn in the opposite direction to the traveling side of the road.

[0059] In one embodiment, the processor retrieves from the memory or storage the compass bearing of the incoming link and the compass bearing of the outgoing link and compares them to each other to determine whether the compass bearing along the path from the incoming link to the outgoing link through the intersection indicates a clockwise (within 180°) or counterclockwise direction. The processor then determines the direction of the turn by interpreting the change in compass bearing. A clockwise change in compass bearing indicates a right turn. A counterclockwise change in compass bearing indicates a left turn. The processor then compares the direction of the turn to the traveling side of the road.

[0060] If the direction of the turn and the side of the road match (right turn and keep to the right or left turn and keep to the left), then the route through the intersection is not a turn in the opposite direction to the side of the road. The processor stores this determination in memory or storage for later processing. Thus, once the processor determines that the compass heading of the incoming link and the compass heading of the outgoing link do not indicate that the route is a turn in the opposite direction to the side of the road that was completed ("NO" at 420), processing at decision block 420 is complete and processing continues to process block 425.

[0061] If the direction of the turn and the side of the road do not match (turn right and keep left or turn left and keep right), then the route through the intersection is a turn in the opposite direction to the side of the road. The processor stores this determination in memory or storage for later processing. Thus, if the processor determines that the compass heading of the incoming link and the compass heading of the outgoing link indicate that the route is a turn in the opposite direction to the side of the road that was completed ("Yes" at 420), processing at decision block 420 is complete and processing continues to decision block 430.

[0062] In a special case, a U-turn may be identified as a cross-traffic turn if the compass orientations of the incoming and outgoing links are approximately opposite one another. The processor determines that the route through the intersection is a turn away from the traveling side of the road if the compass orientations of the incoming and outgoing links are approximately opposite one another. The processor stores this determination in memory or storage for later processing. Thus, once the processor determines that the compass orientation of the incoming and outgoing links indicates that the route is a turn away from the traveling side of the road that is completed ("Yes" at 420), processing at decision block 420 is complete and processing continues to decision block 430.

[0063] At decision block 430, the processor determines whether the first compass heading of the first link entering the node (or the first link leaving the node, or both the first link entering the node and the first link leaving the node) is opposite to the compass heading of the arrival link.

[0064] In one embodiment, the processor obtains a compass orientation for each of the incoming links and each of the outgoing links. The processor compares the compass orientation of the node's incoming link with the compass orientation of each of the other incoming links to determine whether the compass orientation of the incoming link is generally opposite to the compass orientation of the incoming link. Such an incoming link may be referred to herein as an anti-traffic incoming link. The processor compares the compass orientation of the node's incoming link with the compass orientation of each of the outgoing links (except for the outgoing link in one embodiment) to determine whether the compass orientation of the outgoing link is generally opposite to the compass orientation of the incoming link. Such an outgoing link may be referred to herein as an anti-traffic outgoing link. The processor then determines whether the compass orientation of any pair of anti-traffic incoming link and anti-traffic outgoing link is generally opposite to the compass orientation of the incoming link. The processor stores the results of the determination for later processing and storage. The presence of both an anti-traffic incoming link and an anti-traffic outgoing link indicates the presence of anti-traffic. The absence of both an opposing traffic arrival link and an opposing traffic departure link indicates the absence of opposing traffic.

[0065] In one embodiment, a compass heading is "approximately" in a given direction if it is within 45° on either side of that direction. A narrower range from that direction to 0° is also considered appropriate. This approximation allows the compass heading of each link to be derived from the coordinates of the link's "from" and "to" nodes, rather than strictly matching the physical placement of the underlying road segments at the intersection. This approximation also allows for intersections that are not perfect right angles. There may be edge case intersections where this simple approximation does not correctly identify a cross traffic turn. Additional logic may be implemented to improve identification.

[0066] Thus, once the processor has determined that the first compass bearing of the first link entering the node and the first link leaving the node is not opposite the compass bearing of the arriving link ("NO" at 430), processing at decision block 430 is complete and processing continues to process block 425. Alternatively, once the processor has determined that the first compass bearing of the first link entering the node and the first link leaving the node is opposite the compass bearing of the arriving link ("YES" at 430), processing at decision block 430 is complete and processing continues to process block 435.

[0067] At process block 435, the processor registers the determination that the route through the intersection is a traffic crossing turn, such as by writing the result to memory or storage for retrieval and use in subsequent processing. Processing at process block 435 is then complete and processing continues to end block 440, where process 400 ends.

[0068] At process block 425, the processor registers the determination that the route through the intersection is not a cross-traffic turn, such as by writing the result to memory or storage for retrieval and use in subsequent processing. Processing at process block 425 is then complete and processing continues to end block 440, where process 400 ends.

[0069] Returning to process block 310 of method 300 of FIG. 3, once the processor has thus completed a determination that, for the outgoing link, the vehicle's path from the arrival link to the outgoing link crosses oncoming traffic, processing at process block 310 is complete and processing continues to process block 320.

[0070] 5A-5F show selective example routes through intersections to which method 400 may be applied. These selected routes are not exhaustive, and method 400 is applicable to most common types of intersections. There may also be edge case intersections that may require additional logic to determine whether a turn crosses oncoming traffic. In FIGs. 5A-5F, the driving side of the road is to the right, and north is up on the page.

[0071] 5A is a diagram 500 illustrating an example of a traffic crossing turn route 502 through a four-way intersection 504, and includes a graph portion showing a node 506 representing the intersection 504 and links representing road segments entering and leaving the intersection 504. The graph portion shows a route arrival link 508, a route departure link 510, an oncoming traffic arrival link 512, and an oncoming traffic departure link 514, among other links entering and leaving the node.

[0072] According to method 400, the compass bearing of incoming link 508 is north and the compass bearing of outgoing link 510 is 90° west counterclockwise, indicating route 502 through intersection 504 is a left turn. The compass bearings of the other links are checked because the "left" of the left turn does not match the "right" of right-hand driving, and route 502 may cross oncoming traffic. The compass bearings of opposing traffic incoming link 512 and opposing traffic outgoing link 514 are both south, opposite the north bearing of incoming link 508. Thus, route 502 is identified as an oncoming traffic crossing (a cross-traffic turnaround).

[0073] 5B is a diagram 515 illustrating an example of a non-traffic crossing turn route 517 through a T-intersection 519, including a graph portion showing a node 521 representing the T-intersection 519 and links representing road segments entering and leaving the T-intersection 519. The graph portion shows, among other links entering and leaving the node, a route arrival link 523, a route departure link 525, and an opposite traffic departure link 527. The opposite traffic arrival link is not present because there is no traffic entering the intersection 519 in the opposite compass direction as the route arrival link 523.

[0074] The compass bearing of arriving link 523 is north and the compass bearing of departing link 525 is 90° west counterclockwise, indicating route 517 through intersection 519 is a left turn. The compass bearings of the other links are checked because the "left" of the left turn does not match the "right" of right-hand driving, and route 517 may cross oncoming traffic. Although oncoming traffic departure link 527 has an opposite compass bearing to arriving link 523, there is no oncoming traffic arriving link. Therefore, route 517 is identified as not an oncoming traffic crossing.

[0075] 5C is a diagram 530 illustrating an example of a traffic crossing turn route 532 that passes through a four-way intersection 534 with multiple lanes, and includes a graph portion showing a node 536 that represents the intersection 534 and links that represent road segments that enter and exit the intersection 534. The graph portion shows a route arrival link 538, a route departure link 540, an oncoming traffic arrival link 542, and an oncoming traffic departure link 544, among other links that enter and exit the node.

[0076] No special considerations are necessary for multi-lane two-way roads. Similar to the example diagram 500 of FIG. 5A, the compass direction of the incoming link 538 is north, the compass direction of the outgoing link 540 is 90° west counterclockwise, and route 532 through intersection 534 indicates a left turn. The compass direction of the other links will be checked because the "left" of the left turn does not match the "right" of right-hand driving, and route 532 may cross oncoming traffic. The compass direction of the opposing traffic incoming link 542 and the opposing traffic outgoing link 544 are both south, opposite the north direction of the incoming link 538. Thus, route 532 is identified as an oncoming traffic crossing (a traffic crossing turn). Also, the method 400 will operate similarly if there are links representing each lane of a multi-lane two-way road, rather than links representing the direction of traffic flow. For example, even if oncoming traffic arrival link 542 and oncoming traffic departure link 544 were duplicated, method 400 would still identify a pair of oncoming traffic arrival and departure links whose orientation is opposite to that of arrival link 538, and thus a cross-traffic turn would be identified.

[0077] 5D is a diagram 545 illustrating an example of a non-cross-traffic turning route 547 through a four-way intersection 549, including a graph portion showing a node 551 representing the intersection 549 and links representing road segments entering and leaving the intersection 549. The graph portion shows a route arrival link 553, a route departure link 555, an on-coming traffic arrival link 557, and an on-coming traffic departure link 559, among other links entering and leaving the node.

[0078] The compass direction of arrival link 553 is north and the compass direction of departure link 555 is 90° east clockwise, indicating route 547 is a right turn through intersection 549. Because the "right" of a right turn corresponds to the "right" of driving on the right, route 547 cannot possibly cross oncoming traffic. Therefore, route 547 is identified as not a crossing of oncoming traffic.

[0079] 5E is a diagram 560 illustrating an example of a traffic crossing turn route 562 through a T-intersection 564, including a graph portion showing a node 566 representing the intersection 564 and links representing road segments entering and leaving the intersection 564. The graph portion shows a route arrival link 568, a route departure link 570, an oncoming traffic arrival link 572, and an oncoming traffic departure link 574, among other links entering and leaving the node.

[0080] T-intersection 564 differs from T-intersection 519 of FIG. 5B with respect to the location of arriving link 568 relative to the other links. The compass bearing of arriving link 568 is north and the compass bearing of departing link 570 is 90° west counterclockwise, indicating route 562 through intersection 564 is a left turn. The compass bearings of the other links are checked because the "left" of a left turn does not match the "right" of right-hand driving, and route 562 may cross oncoming traffic. The compass bearings of opposite-traffic arriving link 572 and opposite-traffic departing link 574 are both south, opposite the north bearing of arriving link 568. Thus, route 562 is identified as an oncoming traffic crossing (a cross-traffic turnaround). The absence of an eastbound link has no effect on this determination.

[0081] 5F is a diagram 575 illustrating an example of a non-traffic cross-turn route 577 through an intersection 579 including a one-way road, including a node 581 representing the intersection 579 and a graph portion showing links representing road segments entering and leaving the intersection 579. The graph portion shows a route arrival link 583 and a route departure link 585, among other links entering and leaving the node. Because the road of arrival link 583 is a one-way road, there are no opposing traffic arrival or departure links.

[0082] The compass bearing of arriving link 583 is north and the compass bearing of departing link 585 is 90° west counterclockwise, indicating route 577 is a left turn through intersection 579. The compass bearings of the other links are checked because the "left" of the left turn does not match the "right" of right-hand driving, and route 577 may cross oncoming traffic. However, there are no oncoming traffic departure links or oncoming traffic arrival links. Therefore, route 577 is identified as not being an oncoming traffic crossing.

[0083] 5G is a diagram 590 illustrating an example of a traffic crossing U-turn route 591 through a four-way intersection 592 with multiple lanes, including a graph portion showing a node 593 representing the intersection 592 and links representing road segments entering and leaving the intersection 592. The graph portion shows route arrival links 594, oncoming traffic arrival links 595, and integrated route departure links and oncoming traffic departure links 596, among other links entering and leaving the node.

[0084] The route arrival link 594 has a compass direction of north, and the integrated route departure link and opposite traffic departure link 596 have compass directions of south. This is a special case that indicates a U-turn. A U-turn is considered a cross-traffic turn because it may impede oncoming traffic. Therefore, route 591 is identified as a cross-traffic turn.

[0085] Referring back to method 300 of FIG. 3, at process block 320, the processor, in response to determining that the vehicle's path crosses oncoming traffic, adds an additional estimated delay of the outgoing link to a route objective function representing the vehicle route (and may prevent the cross-traffic turn by applying an additional charge or crossing cost for the cross-traffic turn, as discussed herein).

[0086] In one embodiment, a shortest path solver (such as Dijkstra's algorithm) executed by the route generation engine operates (at least in part) based on travel time to find the fastest route between nodes to complete. Each link includes a travel time weight that represents the expected time to travel the road segment represented by that link from a start intersection (represented by the link's "from" node) to an end intersection (represented by the link's "to" node). The travel time is stored as a value in the link data structure. The travel time of a link may be a historical average of travel times derived from road source data for that link. The travel time may vary depending on the time of day and / or day of the week when travel along the link occurs. For example, the expected travel time of a link may be provided for each hour of the day, so that the processor would use the expected travel time for the time of day when the vehicle travels along the link. This may be determined by adding the total travel time of the route being developed from the route start time when the vehicle begins traveling on the route to the time when the link is entered.

[0087] In one embodiment, the objective function for a route or route segment is the accumulated cost of the links between the origin node and any given node in the graph (expressed in one embodiment as a function of travel time, travel distance, traffic crossing turn delay, and traffic crossing turn obstacle cost), and this objective function for a route to any given node is sometimes referred to as the cost of the node or the cost of reaching the node.

[0088] If the processor determines that a vehicle's path through an intersection to reach a road segment represented by a link includes a turn across oncoming traffic, it adds an additional estimated delay to the link's estimated travel time to lengthen the expected travel time along the link to account for the time to perform the cross-traffic turn. This additional estimated delay (a time measurement cost) is included in the objective function for all subsequent nodes following the link. Additionally, the additional estimated delay time added to the estimated travel time may serve to block even low-risk, low-delay turns across light traffic. This blocking is separate from any charges that are explicitly added to the cost of the specific objective of blocking the cross-traffic turn.

[0089] In one embodiment, for a departure link, in addition to determining that the vehicle's path from the arrival link to the departure link crosses oncoming traffic, the processor also determines whether the oncoming traffic has low traffic volume, and controls the additional estimated delay to be a pre-set standard delay if the oncoming traffic has low traffic volume, and to be a dynamically generated measure of delay based on estimated traffic density if the oncoming traffic does not have low traffic volume, i.e., has high traffic volume.

[0090] In one embodiment, oncoming traffic is considered "light" or "residential" if the daily volume of oncoming traffic is below a threshold of 1000 vehicles / day. This is generally a satisfactory threshold since, on average, it is less than 1 oncoming vehicle / minute, which may allow more than enough time to complete a turn across traffic. The threshold may be selected to be higher or lower based on the expected time it will take a vehicle using the systems and methods herein to complete a turn across traffic, which may vary significantly based on the particular vehicle. For example, a tractor trailer may require 15 seconds or more to complete a turn across traffic from a complete stop, whereas a small delivery vehicle may require less than 5 seconds to complete the same turn. In one embodiment, the processor may calculate or obtain the volume of oncoming traffic, for example from road source data, and compare it to a threshold below which traffic is considered light and above which traffic is considered not light.

[0091] Alternatively, traffic may be inferred to be light or non-light traffic based on the location of the road represented by the opposing traffic link in the road hierarchy. Links representing local roads are assumed to be "light" or "residential" traffic, while secondary and arterial roads are considered to be "non-light" or "non-residential" traffic. Limited access freeways are also considered to be "non-light" or "non-residential" traffic, although limited access freeways are generally not considered because cross traffic turns are prohibited on such routes. In one embodiment, the processor may obtain the location of the road segment carrying the opposing traffic in the road hierarchy, for example from the road source data, and determine that (i) the traffic is light if the road segment is a local road, and (ii) the traffic is not light if the road segment is a high volume route (secondary arterial, arterial, or limited access freeway).

[0092] The results of these determinations as to whether traffic along the road segment represented by the link is "residential" or "light traffic" may be recorded as an indication in the link data structure. Thus, in one embodiment, oncoming traffic is considered light traffic based on an indication on one or more links that constitute oncoming traffic that the traffic on the link or links is light traffic. For example, such an indication may be included in the link data structure, such as setting a "residential" flag (described herein with reference to FIG. 2) of the link to a "true" value. The "residential" flag may also be set to a "false" value indicating that traffic along the road segment represented by the link is "non-residential" or "not light traffic" (i.e., heavy traffic). The processor may obtain the value of the "residential" flag by performing a query on the graph, and accept the obtained value as a determination as to whether traffic on the link is considered "residential" or "light traffic".

[0093] After the processor has thus completed the determination that the oncoming traffic is light traffic, the processor controls the additional estimated delay to be (i) a preset standard delay if the oncoming traffic is light traffic, and (ii) a dynamically generated measure of delay based on estimated traffic density if the oncoming traffic is not light traffic, i.e., heavy traffic. In one embodiment, the processor controls the additional estimated delay by using different processes for selecting the additional estimated delay based on whether the traffic is light traffic or not.

[0094] In one embodiment, the additional estimated delay of the outgoing link may be a preset standard delay for the cross-traffic turn that is received and stored by the system. For example, the processor may receive a value (e.g., 30 seconds or 60 seconds) entered by an administrator of the system as the standard delay, which the processor stores in storage or memory for later use. Thereafter, when the additional estimated delay is called for (if a residential cross-traffic turn is included in the route), the processor retrieves the value of the standard delay and uses that value in the calculation as the additional estimated delay. Thus, in one embodiment, in response to determining that the oncoming traffic is light traffic (or residential), the processor controls the value of the additional estimated delay by retrieving the preset standard delay from memory and providing it as the additional estimated delay.

[0095] In one embodiment, the additional estimated delay of the outgoing link is calculated based at least in part on the historical speed and speed limit of the oncoming traffic. For example, if the oncoming traffic is not light, a dynamically generated estimated delay for the oncoming traffic is generated and applied. An observed historical speed below the legal speed limit indicates high traffic density and may result in increased cross-traffic turnaround delays. On the other hand, an observed historical speed at (or above) the legal speed limit indicates lower traffic density and may result in decreased cross-traffic turnaround delays. Thus, the ratio of the observed speed to the legal speed limit may be used to modify the standard delay to more closely match the conditions at the intersection. For example, the processor may receive, store, and retrieve the standard delay as described above. The processor may then divide the standard delay (D) by the ratio of the historical average speed (H) to the legal speed limit (L) to generate the adjusted delay (A). A lower historical average speed results in a larger adjusted delay, and a higher historical average speed results in a smaller adjusted delay. Optionally, a positive multiplier (M) can be applied to the ratio of H to L to vary the magnitude of the effect of the ratio on the adjusted delay. In one embodiment, the processor generates the adjusted delay by executing Equation 1.

[0096]

number

[0097] The processor retrieves from the storage administrator-set values ​​for D and M. The processor retrieves values ​​for H and L from a data structure associated with the opposing traffic departure link and / or the opposing traffic arrival link. The processor then calculates an adjusted delay A. The adjusted delay A is thus a dynamically generated measure of delay as a function of estimated traffic density. Thus, in one embodiment, in response to determining that the opposing traffic is not lightly trafficked (i.e., non-residential), the processor controls the value of the additional estimated delay by retrieving from the memory preset values ​​of the standard delay (D), the historical average speed (H), the legal speed limit (L), and the multiplier (M), and calculating the adjusted delay (A) as described herein, and providing the adjusted delay as the additional estimated delay.

[0098] In one embodiment, the estimated additional delay of the outgoing link is calculated based at least in part on historical traffic speeds of one or more links that make up the opposing traffic during the time period when the vehicle route arrives at the node. The historical traffic speeds may be decomposed into a set of speeds for different time blocks of a day (e.g., a set of 24 one-hour blocks). This allows the processor, in one embodiment, to determine the time period during which the traffic crossing turn occurs, select a value of H for the block that includes this time period, and then calculate a value of A.

[0099] Thus, once the processor has completed adding the additional estimated delay of the outgoing link to the route objective function representing the vehicle route in response to determining that the vehicle's path crosses oncoming traffic, processing at process block 320 is completed and processing continues to process block 325.

[0100] In one embodiment, an intersection may have multiple outgoing links that include a turn around crossing traffic. For example, there may be a K-shaped intersection with more than two roads connecting only one side of the intersection, or an intersection with more than five roads approaching the intersection to form a star-shaped intersection. Thus, in one embodiment, for each additional outgoing link that leaves the node along with the outgoing link, the processor identifies the additional outgoing link for a vehicle's exit route from the arrival link to the additional outgoing link that crosses oncoming traffic with low traffic volume, and adds the estimated delay of the additional outgoing link to a route objective function that represents the vehicle route. For example, the processor identifies each exit link of the node along with the outgoing link, determines whether the route from the arrival link to that link crosses oncoming traffic, and if so, determines whether the traffic is low traffic, and finally adds the estimated delay by taking the standard delay and using it as the estimated delay or using it to calculate an adjusted delay and using the adjusted delay as the estimated delay.

[0101] The additional delay incurred on a route involving a traffic crossing turn provides a baseline level of bias against traffic crossing turns. In one embodiment, a policy can be incorporated into the operation of the systems and methods herein that rejects traffic crossing turns more than the delay incurred. The introduction of such a policy can reduce the likelihood of traffic accidents inherent in traffic crossing turns. For example, a standard fee (or crossing cost) can be added to the objective function for each traffic crossing turn to make routes that include traffic crossing turns more costly. This fee is not based on the cost of operating a vehicle along the road segment represented by a given link, but is a penalty imposed to prevent the use of the road segment represented by a given link. As used herein, the fee is imposed as a crossing cost, i.e., an obstacle penalty cost of introducing a traffic crossing turn on a given link. This fee (crossing cost) or penalty quantifies the extent to which the policy rejects traffic crossing turns. In one embodiment, the fee reflects the degree of obstacle or risk of the traffic crossing turn.

[0102] In one embodiment, in response to determining that the vehicle's path crosses oncoming traffic, the processor adds an additional cost of the outgoing link to a route objective function representing the vehicle route. The processor may determine that the vehicle crosses oncoming traffic as described herein with reference to adding an additional delay (e.g., as shown and described with reference to process blocks 310-320). The processor then retrieves a fare value from memory or storage and uses the value as the fare. The fare value may be set by an administrator of the system. The higher the fare, the stronger the policy against turning around across traffic. The higher the fare, the less likely it is that a shortest route from one node to another will include a turning around across traffic.

[0103] At process block 325, the processor selects, via a route generation engine, a route that includes a path across oncoming traffic as the optimal (least cost) route between the first location and the second location.

[0104] In one embodiment, the processor determines that each node in the graph has been considered. This indicates to the processor that each path from a first location in the graph to each other location in the graph is optimal and has the lowest travel time cost to reach. In response, the processor persists (stores for later retrieval and use) routes, including routes that cross oncoming traffic. For example, the processor may write each route from the first location to another location in the graph in a data structure associated with the first location (e.g., write the route to an all-nodes data structure associated with the node representing the first location). Routes that include paths that cross oncoming traffic start at the first location and end at the second location and are stored in the all-nodes data structure at a location in the route associated with the second location.

[0105] In one embodiment, an optimal or least cost route from a node in the graph to every other node is stored at each node of the graph. In one embodiment, a set of optimal or least cost routes from every node in the graph to every other node is stored in memory or storage as a data structure. In one embodiment, the travel time for each route and the travel distance for each route are associated with the routes and stored in memory or storage as a data structure. The least cost routes may include one or more routes that include residential traffic crossing turns.

[0106] Thus, once the processor has completed using the route generation engine to select a route that includes a path across oncoming traffic as the optimal route between the first location and the second location, processing at process block 325 is complete and processing continues to process block 330.

[0107] At process block 330, the processor includes the optimal route as part of the vehicle's delivery schedule via the scheduling engine. In one embodiment, the scheduling engine 173 executes an MTSP solver. When executed by the processor, the MTSP solver accepts as input a set of delivery locations, available delivery convoys, a set of all routes from each node to each other node, and the travel times and distances associated with those routes. From these inputs, the MTSP solver generates a delivery schedule for the set of delivery locations.

[0108] In one embodiment, the delivery schedule describes which deliveries are to be delivered by which vehicles and the order in which the vehicles make the deliveries. The delivery schedule describes a set of vehicle routes from a warehouse through a set of delivery locations and back to the warehouse, collectively visiting each delivery location once (for delivery, pickup, or other service). The MTSP selects an optimal route from each node (representing a warehouse or delivery location) to the next node in the set of assigned delivery locations from a set of optimal or least-cost routes from each node in the graph to each other node. Depending on the route selected, the MTSP may select a route that includes one or more residential traffic crossing turns.

[0109] The MTSP minimizes a delivery objective function of the cost of deliveries across all vehicle routes by distributing delivery locations (and associated deliveries) among the vehicle routes. In one embodiment, the delivery objective function may represent one or more of travel distance, travel time, and financial cost. In one embodiment, the delivery objective function includes a weighted sum of travel distance and travel time. In one embodiment, the delivery objective function includes other weighted inputs, such as vehicle loading time. If the optimal route from one delivery location to the next is a route that involves a residential traffic crossing turn, the processor includes the optimal route in the delivery schedule. The processor writes the completed delivery schedule to memory or storage.

[0110] The scheduling engine 173 may generate a loading plan for the delivery vehicle based on the delivery route (of the delivery locations) of the delivery vehicle and include the loading plan in the delivery schedule. The loading plan includes at least a list of delivery items to be delivered to the delivery locations. The loading plan may also indicate the order in which the delivery items are to be loaded, thereby enabling access to the delivery items in the scheduled order of delivery. The loading plan may also specify locations within the delivery vehicle to place the delivery items.

[0111] In one embodiment, the schedule corresponds to a particular delivery time window during which delivery is required at the delivery location. In one embodiment, the MTSP server may train and use machine learning models to identify better delivery schedules based on the inputs.

[0112] Thus, once the processor has completed including the optimal route as part of the vehicle's delivery schedule with the scheduling engine, processing at process block 330 is complete and processing continues to process block 335.

[0113] At process block 335, the processor transmits the delivery schedule for execution. In one embodiment, the processor retrieves the delivery schedule, composes a message, such as a REST request, including the delivery schedule, and transmits the delivery schedule to a remote computer, such as computing device 145, 155, 160, 161. In one embodiment, the message causes all or a portion of the delivery schedule to be displayed on a graphical user interface of the remote computer. In one embodiment, the processor transmits the delivery route to a mobile device associated with the delivery vehicle to display the delivery route to the driver and to navigate the vehicle across oncoming traffic. In one embodiment, the processor transmits the delivery schedule to a handheld delivery information terminal 161 to display the vehicle route in a GPS navigation GUI and present delivery item (e.g., package) information in the delivery terminal GUI.

[0114] In one embodiment, the processor transmits a load plan to the warehouse computing system for the selection and loading of items to be delivered in the delivery vehicle. In one embodiment, this transmission results in a user manually executing loading instructions that place the appropriate delivery items in the vehicle. In another embodiment, the processor executes the load plan by transmitting the delivery schedule to a remote computer to automatically operate robotic loading equipment.

[0115] In one embodiment, the delivery schedule is displayed along with input options for the user to accept, reject, or modify the delivery schedule. Such user feedback may be used to train the MTSP solver's ML model to generate better delivery schedules.

[0116] In one embodiment, the processor transmits the delivery schedule to the autonomous delivery vehicle and navigates the autonomous delivery vehicle across oncoming traffic to the delivery stop according to the delivery schedule. In one embodiment, the processor retrieves the delivery schedule and constructs a message, such as a REST request, that includes all or a portion of the delivery schedule and instructs the autonomous delivery vehicle to perform deliveries for a particular vehicle route included in the delivery schedule. In response to transmitting the delivery schedule to the autonomous delivery vehicle, the instructions navigate the autonomous delivery vehicle across oncoming traffic to the delivery stop according to the delivery schedule. In one embodiment, the systems and methods described herein navigate the autonomous delivery vehicle across oncoming traffic from an arrival link to a departure link, through the vehicle's path to the delivery stop by providing the autonomous delivery vehicle with a delivery route and instructions to complete deliveries along the route.

[0117] Thus, once the processor has completed submitting the delivery schedule for execution, processing at process block 335 is complete and processing continues to end block 340 where process 300 ends.

[0118] In one embodiment, method 300 relies on the availability of values ​​that may not be present in the graph or in the road source data for the graph. In one embodiment, a map extension module (such as map extension module 175) may generate these values ​​for the graph from the road source data and store them in node and link data structures in the map database. In one embodiment, the functions of map extension module 175 are performed by a dedicated computing device (such as computing device 805) in which dynamic traffic cross-direction vehicle route scheduling and navigation logic 830 is configured.

[0119] In one embodiment, the processor determines, for each link of the graph, based on road source data (as may be provided or updated from time to time by traffic / road data source 195), whether the traffic along the link is light / residential or non-light / non-residential, and stores the determination of whether the traffic along the link is light / residential in a data structure describing the link. In one embodiment, this determination is based on a database of road source data that is separate from the graph. In one embodiment, the road source data is included in the graph (e.g., in a link and node data structure).

[0120] In one embodiment, for each link in the graph, the processor retrieves the link's speed limit from the road source data and stores the link's speed limit in a data structure describing the link.

[0121] In one embodiment, for each link in the graph, the processor obtains the start and end coordinates of the link, calculates a compass orientation of the link from the start and end coordinates of the link, and stores the compass orientation of the link in a data structure describing the link.

[0122] Example pseudocode In one embodiment, Dijkstra's algorithm is the shortest path solver algorithm executed by route generation engine 170. At a high level, Dijkstra's algorithm works by overestimating the cost to reach each other node in the graph from the origin node and visiting each node and its neighbors to see if there is a lower cost route segment (or sub-path) to each neighbor. Dijkstra's algorithm may be modified in accordance with the systems and methods herein to allow dynamic cost weighting of traffic crossing turns for inclusion in the least cost route developed by the algorithm based on whether the oncoming traffic is low volume (or residential). Pseudo code for one exemplary implementation of Dijkstra's algorithm, modified to allow dynamic inclusion of traffic crossing turns based on the oncoming traffic volume on the vehicle route, is shown in Table 1.

[0123] [Table 1] TIFF2024525585000004.tif142155

[0124] The algorithm in Table 1 searches for a route or path with the lowest objective cost from an origin node to each other node in the graph. Traffic crossing turns are dynamically included in the route if oncoming traffic is light and dynamically rejected as a function of traffic density if oncoming traffic is not light, but are still included in the route if no solution with a lower objective cost exists. "Cost" is not a financial cost, but a measure of the burden of travel between geographic locations that is used to search for the "most favorable" route that considers factors such as travel time, travel distance, and the degree of rejection of traffic crossing turns. In one embodiment, cost is expressed in terms of time, and the obstacle cost of traffic crossing turns is expressed in time even though it represents factors other than travel time (risk of collision).

[0125] Lines 03-11 of Table 1 include the initialization steps of the algorithm of Table 1. Lines 03-07 for each node (n) in the graph, the cost to reach the node from the origin (cost[n] (also referred to herein as the cost of the node)) is initialized to infinity, the travel time to reach the node from the origin (travelTime[n]) is initialized to infinity, and the previous node of the optimal path from the origin to the node (previous[n]) is set to undetermined. In line 08, the cost to reach the origin (cost[origin]) is set to zero since there is no cost to reach the origin if it is already at the origin. In line 09, the set of all nodes in the graph is placed in an array Q, which is the set of unconfirmed nodes in the graph. In line 10, a constant estimated delay time (estimatedDelayTime) for residential / low volume traffic cross turns is set. In one embodiment, this is the average delay time of all residential traffic cross turns based on the observed delay times of historical residential traffic cross turns. In one example, the estimated delay time may be, for example, 30 seconds, as shown in line 10. In line 10, an additional fare constant (crossingCost) is set. This fare is an additional cost that represents the degree to which system administrators generally want to block crossing traffic turns. In the example of Table 1, the fare is set to 0, indicating no blocking of residential crossing traffic turns. Higher levels of fare result in higher levels of blocking of residential crossing traffic turns. In one embodiment, the estimated delay cost and / or fare may vary depending on the time of day when the turn is occurring. This may be based on the travel time elapsed from the start time of the route to reaching the node.

[0126] Lines 17-60 of Table 1 are a while loop to check all nodes in the graph, which are repeated while there are still unconfirmed nodes in Q. In lines 18 and 19, a currently considered node (u) is extracted from the set of unconfirmed nodes Q. The currently considered node is the node with the smallest cost. Thus, in the first iteration of while, the first node extracted from Q becomes the origin node, since its cost is 0, while all other nodes have infinite cost. In lines 20-59, the processor determines, for each unvisited neighbor node (n) of the currently considered node (u), whether the path from u to n is a cross-traffic turnaround, e.g., as shown and described herein with reference to FIG. 4. If the path from u to n is a cross-traffic turnaround, lines 22-50 will be executed. If the path from u to n is not a cross-traffic turnaround, another method will be executed in lines 51-58.

[0127] If the route from u to n is a turnaround at a traffic crossing, then in line 22 it is determined whether the traffic crossing has low traffic. If the traffic crossing has low traffic, then in lines 23-24 a temporary cost (tempCost) is calculated, which is the sum of the cost of the node currently under consideration (cost[u]), the travel time to get from u to n (travelBetween(u,n)), the estimated delay time (estimatedDelayTime), and the toll (crossingCost). In line 25, the temporary cost (tempCost) is compared to the cost of the adjacent node n (cost[n]). If the tentative cost (tempCost) is less than the cost (cost[n]) of the adjacent node n, then (i) in line 26, the cost (cost[n]) of the adjacent node n is replaced with the smaller tentative cost (tempCost); (ii) in lines 27-29, the travel time (travelTime[n]) to the adjacent node n is set as the sum of the travel time to reach the current node u (travelTime[u]), the travel time between the current node u and the adjacent node n (travelBetween(u,n)), and the estimated delay time (estimatedDelayTime); and (iii) in line 30, the previous node on the path to reach the adjacent node (n) is set as the node currently under consideration (u). If the traffic crossing is not lightly traveled, then in lines 37-40 a tentative cost (tempCost) is calculated, which is the sum of the cost to reach the node currently under consideration (cost[u]), the travel time to reach n from u (travelBetween(u,n)), the estimated delay time (estimatedDelayTime), the toll (crossingCost), and the dynamically generated traffic density cost (densityCost()). In line 42, the tentative cost (tempCost) is compared with the cost of the adjacent node n (cost[n]).If the tentative cost (tempCost) is less than the cost (cost[n]) of the adjacent node n, then (i) in line 43, the cost (cost[n]) of the adjacent node n is replaced with the smaller tentative cost (tempCost); (ii) in lines 44-46, the travel time (travelTime[n]) to the adjacent node n is set as the sum of the travel time to reach the current node u (travelTime[u]), the travel time between the current node u and the adjacent node n (travelBetween(u,n)), and the estimated delay time (estimatedDelayTime); and (iii) in line 47, the previous node of the path to reach the adjacent node (n) is set as the currently considered node (u). In one embodiment, the density cost is a function of the estimated traffic density at the intersection represented by the current node (u), e.g., as shown and described herein with reference to Equation 1.

[0128] If the path from u to n is not a cross-traffic turn (e.g., going directly through an intersection or making a non-cross-traffic turn), then in line 52 a temporary cost (tempCost) is calculated, which is the sum of the cost of the node currently under consideration (cost[u]) and the travel time to get from u to n (travelBetween(u,n)). In line 53, the temporary cost (tempCost) is compared with the cost of the adjacent node n (cost[n]). If the tentative cost (tempCost) is less than the cost of the adjacent node n (cost[n]), then (i) in line 54, the cost of the adjacent node n (cost[n]) is replaced by the smaller tentative cost (tempCost), (ii) in line 55, the travel time to reach the adjacent node n (travelTime[u]) is set as the sum of the travel time to reach the current node u (travelTime[u]) and the travel time between the current node u and the adjacent node n (travelBetween(u,n)), and (iii) in line 56, the previous node on the path to reach the adjacent node (n) is set as the node currently under consideration (u).

[0129] Once there are no more unconfirmed nodes Q and each node in the graph has been confirmed, the while loop ends and, at line 63, a set of all predecessors (or predecessors) of the node in the graph is returned. With this set of predecessors, a set of least-cost (optimal) routes can be constructed from the origin of the graph to all other nodes. In addition, the cost to reach each node in the graph is recorded, including any estimated delay costs and / or fees imposed for including residential traffic crossing turns. Potential routes are not excluded; that is, non-residential (i.e., heavy traffic) traffic crossings are considered as potential routes. The final route is selected based on least cost, which may include turns at light traffic or even heavy traffic crossings (if such turns are included in the least-cost route). Additional criteria of the route to the node may also be recorded. For example, both the total travel time of the route and the total distance of the route may be recorded, regardless of the cost function criteria in the algorithm. The least-cost routes to all other nodes in the graph, as well as the associated costs, travel times, and distances of the routes, may be stored as a data structure associated with the data structure of the origin node. In one embodiment, the algorithm of Table 1 is run for each node in the graph that is set as the origin, thereby developing a complete set of least-cost routes from each node in the graph to each other node. Thus, the set of least-cost routes, as well as their associated costs, travel times, and distances, are available for retrieval and use by the multiple traveling salesman solver / optimizer, as run by the scheduling engine 173. In one embodiment, the scheduling engine 173 employs continuous optimization with simulated annealing to approximate a globally optimal set of routes in the map by probabilistically selecting between alternative variations of the schedule based on a route objective function and a decreasing annealing parameter.

[0130] Selective advantage The systems and methods described herein improve the safety of traveling routes involving cross-traffic turns.

[0131] Among the challenges overcome herein is the use of graph representations of road networks in digital navigation and routing. These graphs do not include information for evaluating the appropriateness of cross-traffic turns. For example, graph representations of road networks do not indicate which side of the road traffic is from an arrival link. The systems and methods described herein enable the evaluation of cross-traffic turns in graph representations of road networks that do not indicate which side of the road traffic is from an arrival link. This allows a computer to evaluate the feasibility of a cross-traffic turn while taking into account the nature of oncoming traffic, and also allows the evaluation of whether or not to include a cross-traffic turn in a travel route (which was not previously possible for a computer). Thus, the systems and methods described herein advance the art of digital navigation by enabling conditional dynamic evaluation of cross-traffic turns in vehicle routing.

[0132] Furthermore, by roughly allowing cross-traffic turns with a nominal standard delay when traffic is light, and dynamically generating a delay metric to be applied to cross-traffic turns when traffic is heavy, the same level of safety is maintained and excessive cross-traffic turns are avoided, improving safety similar to the implementation of a "hard" no-cross-traffic turn rule, while providing vehicles with more diverse routing options than a "hard" no-cross-traffic turn rule, allowing the system to provide similar safety benefits while still allowing faster routes that include occasional cross-traffic turns to be available.

[0133] Software Module Embodiments Generally, software instructions are designed to be executed by one or more suitably programmed processors with access to memory, such as access to CPU or GPU resources. These software instructions may include, for example, computer executable code and source code that may be compiled into computer executable code. These software instructions may also include instructions written in an interpreted programming language, such as a scripting language.

[0134] In a complex system, such instructions may be organized as program modules, each of which performs a particular task, process, function, or operation, the overall operation of which may be controlled or coordinated by the system's main program, operating system (OS), or other type of organizational platform.

[0135] In one embodiment, one or more of the components described herein are configured as modules stored on a non-transitory computer-readable medium, the modules comprising at least stored software instructions that, when executed by a processor accessing a memory or storage, cause a computing device to perform the corresponding functions as described herein.

[0136] Cloud or Enterprise Implementation In one embodiment, the system (such as scheduling, dispatching, and routing system 105) is a computing / data processing system that includes a computing application or a collection of distributed computing applications for access and use by other client computing devices associated with the enterprise (such as client devices 145, 150, 155, 160, 161, and 165 of enterprise network 115) that communicate with the system over a network (such as network 110). The applications and computing systems may be configured to operate with or implemented as a cloud-based networked computing system, infrastructure-as-a-service (IAAS), platform-as-a-service (PAAS), or software-as-a-service (SAAS) architecture, or other types of networked computing solutions. In one embodiment, the system provides at least one or more of the functionality disclosed herein and a graphical user interface for accessing and operating these functions.

[0137] Autonomous Vehicle Embodiments 6 illustrates an example autonomous vehicle control system 605 configured and / or programmed to operate according to one or more of the systems and methods described herein and / or equivalents. The autonomous vehicle 165 may be operable by the autonomous vehicle control system 605. In one embodiment, the autonomous vehicle control system 605 includes an on-board computing device 610, such as an example computing system 800, operably connected to the system of the autonomous vehicle 165. In one embodiment, the autonomous vehicle control system 605 includes vehicle sensors 615. The vehicle sensors may include a global positioning system (GPS) receiver, a monocular or binocular camera, a radar sensor, a lidar sensor, an ultrasonic sensor, an accelerometer, a gyroscope, a thermometer, a light detector, a rain sensor, a tachometer for determining wheel speed, wheel skid, and / or vehicle speed, a torque sensor, and a driver input sensor 617. The driver input sensor 617 includes sensors for detecting driver input to steering, brake, accelerator, shift, or indicator systems. Autonomous vehicle control system 605 can access external data sources 620, such as scheduling, dispatch, and routing system 105 and traffic / road data source 195, through a wireless or (intermittent) wired communication network, such as network 110. Autonomous vehicle control system 605 includes vehicle actuators 625 configured to effect movement or other actions of autonomous vehicle 165 in response to control by autonomous driving logic 630.

[0138] The autonomous driving logic 630 obtains or receives the route with traffic turns 635 generated according to the systems and methods described herein, the map 640, and inputs from the vehicle sensors 615, and sends control signals to the vehicle actuators 625 to control, guide, or operate the autonomous vehicle 165 along the route through the traffic turns to one or more endpoints. The autonomous driving logic 630 also obtains or receives current traffic data 645 to inform its control decisions. The route with traffic turns 635 may include a delivery schedule to the endpoints along the route. The route 635, map 640, and traffic data may be obtained by the on-board computing device 610 from the external data source 620 continuously or at intervals and stored as a local data structure on the on-board computing device 610 for rapid access by the autonomous driving logic 630.

[0139] An autonomous vehicle such as the autonomous vehicle 165 may be a full-sized roadworthy vehicle or a compact vehicle configured to travel along a sidewalk. In one embodiment, the autonomous vehicle 165 may be equipped with delivery / recovery equipment 650 that may be used to deposit, grant access to, receive, or retrieve a delivery. The delivery / recovery equipment 650 may be operated by vehicle actuators 625 in response to control signals sent by the autonomous driving logic. The delivery / recovery equipment 650 may include automatically actuated doors configured to allow delivery items, such as packages, to enter and exit the autonomous vehicle 165, and robotic arms and conveyor devices configured to grasp and / or steer delivery items into and out of the autonomous vehicle 165. The delivery / recovery equipment 650 may be used to load delivery items prior to travel along a route that involves a traffic crossing turn or to complete a delivery after travel along a route that involves a traffic crossing turn.

[0140] In one embodiment, the on-board computing device 610 is configured to execute a method described herein, such as method 300 or method 400, via dynamic traffic crossing turning vehicle route scheduling and navigation logic 655 to generate a route with traffic crossing turns 635. The on-board computing device 610 may operate as described above in response to being provided with a list or schedule of one or more destinations for delivery or pickup of an item. Alternatively, the pre-generated route with traffic crossing turns 635 may be provided directly from the scheduling, dispatching, and routing system 105. In one embodiment, the list of destinations (or routes 635) may be provided to the on-board computing device 610 over a wireless network while the autonomous vehicle 165 is away from a “home” location, which may be particularly useful in item pickup operations.

[0141] Crash risk for autonomous vehicles that are permitted to make cross-traffic turns is significantly reduced by implementing the systems and methods herein because the planned route includes only left turns, which are safer, lower-risk turns in light traffic. Cross-traffic turns in heavy traffic are avoided.

[0142] Mobile Device Embodiments Referring now to FIG. 7, this figure illustrates an exemplary mobile device 700 configured and / or programmed with one or more of the systems and methods and / or equivalents described herein. In one embodiment, the mobile device 700 may include dynamic cross-traffic maneuver vehicle route scheduling and navigation logic 705 configured to facilitate vehicle route scheduling and navigation with dynamic selection of turns across oncoming traffic, similar to the logic, systems, and methods shown and described with reference to FIGS. 1-6. The mobile device 700 may include a cellular antenna 710. In an exemplary embodiment, signal processing and / or control circuitry generally identified at 720 in FIG. 7 may be implemented. In some implementations, the mobile device 700 includes a microphone 730, an audio output 740, such as a speaker and / or audio output jack, a display 750, and / or an input device 760, such as a keypad, a pointing device, a touch screen, voice activation, and / or other input device. The signal processing and / or control circuitry 720 and / or other circuitry (not shown) of the mobile device 700 may process data, perform coding and / or encryption, perform calculations, format data, and / or perform other mobile phone functions.

[0143] The mobile device 700 may be in communication with mass data storage 770, such as optical and / or magnetic storage devices (including, for example, HDD and / or DVD) that store data in a non-volatile manner. The HDD may be a mini HDD that includes one or more platters having a diameter less than about 1.8 inches. The mobile phone 700 may be connected to memory 780, such as RAM, ROM, low latency non-volatile memory such as flash memory, and / or other suitable electronic data storage. The mobile device 700 may also support connection to a WLAN via a WLAN network interface 790. The mobile device 700 may include a WLAN antenna 795. While the exemplary system and method may be implemented using this WLAN network interface 790 in the exemplary embodiment, other configurations are possible.

[0144] In one embodiment, the mobile device 700 may be a handheld delivery information terminal and may include additional hardware components such as a barcode / QR code / other code scanning device, a signature input device, and a GPS receiver. A mobile device 700 configured as a handheld delivery terminal may include special software to present delivery information, such as a schedule of delivery, pickup, or service orders at specific locations, as well as order details on the display 750. A mobile device 700 configured as a handheld delivery terminal may include special GPS navigation software to present routes between scheduled locations on the display 750 to guide a user from one delivery, pickup, or service location to the next.

[0145] Computing Device Embodiments 8 illustrates an exemplary computing system 800 configured and / or programmed with one or more of the exemplary systems and methods described herein and / or equivalents as a dedicated computing device. The exemplary computing device may be a computer 805 including a processor 810, a memory 815, and input / output ports 820 operatively connected by a bus 825. In one example, the computer 805 may include dynamic traffic cross-turn vehicle route scheduling and navigation logic 830 configured to facilitate scheduling and navigation of vehicle routes with dynamic selection of turns across opposing traffic, similar to the logic, systems, and methods shown and described with reference to FIGS. 1-6. In different examples, the dynamic traffic cross-turn vehicle route scheduling and navigation logic 830 may be implemented in hardware, a non-transitory computer-readable medium having instructions stored thereon, firmware, and / or a combination thereof. Although the dynamic traffic cross-direction vehicle route scheduling and navigation logic 830 is shown as a hardware component mounted on the bus 825, it will be appreciated that in other embodiments, the dynamic traffic cross-direction vehicle route scheduling and navigation logic 830 can be implemented in the processor 810, stored in memory 815, or stored on a disk 835 on a computer-readable medium 837.

[0146] In one embodiment, the dynamic traffic cross-direction vehicle route scheduling and navigation logic 830 or computing system 800 is a means (structure, hardware, non-transitory computer-readable medium, firmware, etc.) for performing the described operations. In some embodiments, the computing device may be a server operating in a cloud computing system, a server configured in a Software-as-a-Service (SaaS) architecture, a smartphone, a laptop, a tablet computing device, etc.

[0147] The means may be implemented as an ASIC programmed to perform vehicle route scheduling and navigation, for example with dynamic selection of turns across oncoming traffic, as shown and described herein, or as stored computer-executable instructions temporarily stored in memory 815 and presented to computer 805 as data 840 for execution by processor 810.

[0148] Additionally, the dynamic traffic cross-maneuver vehicle route scheduling and navigation logic 830 may provide the means (e.g., hardware, non-transitory computer-readable medium storing executable instructions, firmware) for performing vehicle route scheduling and navigation with dynamic selection of maneuvers across oncoming traffic.

[0149] Generally describing one exemplary configuration of computer 805, processor 810 may be a wide variety of processors including dual microprocessors and other multi-processor architectures. Memory 815 may include volatile and / or non-volatile memory. Non-volatile memory may include, for example, ROM, PROM, EPROM, EEPROM, etc. Volatile memory may include, for example, RAM, SRAM, DRAM, etc. Storage disk 835 may be operatively connected to computer 805 by, for example, input / output (I / O) interface (e.g., card or device) 845 and input / output port 820 controlled by at least input / output (I / O) controller 847. Disk 835 may be, for example, a magnetic disk drive, solid state disk drive, floppy disk drive, tape drive, Zip drive, flash memory card, memory stick, etc. Additionally, disk 835 may be a CD-ROM drive, CD-R drive, CD-RW drive, DVD ROM, etc. Memory 815 may store processes 850 and / or data 840, for example, formatted as one or more data structures. Disk 835 and / or memory 815 may store an operating system that controls and allocates resources of computer 805. Computer 805 can interact with, control, and / or be controlled by input / output (I / O) devices via input / output (I / O) controller 847, I / O interface 845, and input / output ports 820.The input / output devices include one or more displays 870, printers 872 (such as inkjet, laser, or 3D printers), audio output devices 874 (such as speakers or headphones), text input devices 880 (such as a keyboard), pointing and selection devices 882 (such as a mouse, trackball, touchpad, touchscreen, joystick, pointing stick, stylus mouse, etc.), audio input devices 884 (such as a microphone), video input devices 886 (such as video and still cameras), video cards (not shown), disks 835, network devices 855, autonomous vehicle 890, Internet of Things (IoT) sensors (not shown), etc. The input / output ports 820 may include, for example, serial ports, parallel ports, and USB ports.

[0150] Since computer 805 is operable in a networked environment, it may be connected to network device 855 via I / O interface 845 and / or I / O port 820. Computer 805 may interact with network 860 through network device 855. Computer 805 may be logically connected to remote computer-controllable hardware, such as remote computer 865, remote mobile device, or autonomous vehicle 890, through network 860. Networks with which computer 805 may interact include, but are not limited to, LANs, WANs, and other networks.

[0151] Definitions and Other Embodiments In another embodiment, the described methods and / or their respective equivalents may be implemented in computer executable instructions. Thus, in one embodiment, a non-transitory computer readable / storage medium is configured with stored computer executable instructions of an algorithm / executable application that, when executed by a machine, causes the machine (and / or associated components) to perform the above-described method. Exemplary machines include, but are not limited to, processors, computers, servers operating in a cloud computing system, servers configured in a Software-as-a-Service (SaaS) architecture, smartphones, etc. In one embodiment, a computing device is implemented with one or more executable algorithms configured to perform any of the disclosed methods.

[0152] In one or more embodiments, the disclosed methods or respective equivalents are implemented in computer hardware configured to perform the methods, or in modules stored on a non-transitory computer readable medium, and are executed by computer instructions configured as executable algorithms that, when executed by at least a processor of a computing device, perform the methods.

[0153] For ease of explanation, the methods illustrated in the figures are illustrated and described as a series of algorithmic blocks, but it should be understood that these methods are not limited by the order of the blocks. Some blocks may occur in a different order than illustrated and described and / or concurrently with other blocks. Furthermore, not all illustrated blocks may be used to implement an example method. The blocks may be combined or separated into multiple operations / components. Furthermore, additional and / or alternative methods may employ additional operations not illustrated in the blocks.

[0154] The following are definitions of terms that are selectively employed herein. These definitions include various examples and / or forms of components that fall within the scope of the terms and that may be used for implementation. These examples are not intended to be limiting. Both singular and plural forms of terms may be included in the definitions.

[0155] References to "one embodiment," "an embodiment," "one example," "an example," and the like indicate that the embodiment or example so described may include a particular feature, structure, attribute, property, element, or limitation, but not every embodiment or example necessarily includes that particular feature, structure, attribute, property, element, or limitation. Moreover, repeated use of the phrase "in one embodiment" does not necessarily refer to the same embodiment, although it may.

[0156] ASIC: Application Specific Integrated Circuit CD:Compact Disc CD-R: Recordable CD CD-RW: Rewritable CD CPU: Central Processing Unit DVD: Digital Versatile Disc and / or Digital Video Disc GPS: Global Positioning System GPU: Graphics Processing Unit HDD: Hard Disk Drive HTTP: Hypertext Transfer Protocol IAAS:infrastructure-as-a-service LAN: Local Area Network MTSP: Multiple Traveling Salesman Problem PAAS: platform-as-a-service PCI: Peripheral Component Interconnect PCIE: PCI Express RAM: Random Access Memory DRAM: Dynamic RAM SAAS: software-as-a-service SRAM: Synchronous RAM ROM: Read-only memory PROM: Programmable ROM EPROM: Erasable PROM EEPROM: Electrically Erasable PROM SQL: Structured Query Language OQL: Object Query Language USB: Universal Serial Bus XML: Extensible Markup Language WAN: Wide Area Network A "data structure" as used herein is organized data in a computing system stored in memory, storage, or other computer system. A data structure may be, for example, any one of a data field, a data file, a data array, a data record, a database, a data table, a graph, a tree, a linked list, etc. A data structure may be formed from and contain many other data structures (e.g., a database contains many data records). Other examples of data structures are possible as well, according to other embodiments.

[0157] As used herein, a "computer-readable medium" or a "computer storage medium" refers to a non-transitory medium that stores instructions and / or data configured to perform one or more of the disclosed functions when executed. In some embodiments, data may function as instructions. A computer-readable medium may take forms including, but not limited to, non-volatile and volatile media. Non-volatile media may include, for example, optical disks, magnetic disks, and the like. Volatile media may include, for example, semiconductor memory, dynamic memory, and the like. Common forms of computer-readable media may include, but are not limited to, floppy disks, flexible disks, hard disks, magnetic tapes, other magnetic media, application specific integrated circuits (ASICs), programmable logic devices, compact disks (CDs), other optical media, random access memory (RAM), read-only memory (ROM), memory chips or cards, memory sticks, solid-state storage (SSD), flash drives, and other media on which a computer, processor, or other electronic device may function. Various media may include stored instructions for an algorithm that, when selected for implementation in an embodiment, is configured to perform one or more of the functions disclosed and / or claimed below.

[0158] "Logic" as used herein refers to a component implemented in computer or electrical hardware, a non-transitory medium having instructions of an executable application or program module stored thereon, and / or a combination thereof, for performing any of the functions or operations disclosed herein and / or for causing another logic, method, and / or system to perform a function or operation as disclosed herein. Equivalent logic may include firmware, a microprocessor programmed with an algorithm, a discrete logic (e.g., ASIC), at least one circuit, an analog circuit, a digital circuit, a programmed logic device, a memory device containing algorithmic instructions, and the like, any of which may be configured to perform one or more of the disclosed functions. In an embodiment, logic may include one or more gates, a combination of gates, or other circuit components configured to perform one or more of the disclosed functions. Where multiple logics are described, it may be possible for multiple logics to be incorporated into one logic. Similarly, where a single logic is described, it may be possible for the single logic to be distributed among multiple logics. In one embodiment, one or more of these logics are corresponding structures associated with performing the functions disclosed and / or claimed. The selection of the type of logic to implement may be based on desired system requirements or specifications. For example, if faster speed is considered, hardware will be selected to achieve the function. If lower cost is considered, stored instructions / executable applications will be selected to achieve the function.

[0159] An "operable connection" or a connection by which entities are "operably connected" is one that is capable of transmitting and / or receiving signals, physical communications, and / or logical communications. An operable connection may include physical interfaces, electrical interfaces, and / or data interfaces. An operable connection may include different combinations of interfaces and / or connections sufficient to enable operable control. For example, an operable connection of two entities may convey signals directly to each other or through one or more intermediate entities (e.g., processors, operating systems, logic, non-transitory computer-readable media). An operable connection may also be formed through the use of logical and / or physical communication channels.

[0160] A "user" as used herein includes, but is not limited to, one or more humans, one or more computers, or other devices, or any combination thereof.

[0161] Although the disclosed embodiments have been shown and described in considerable detail, it is not intended, and is not intended to limit the scope of the appended claims to such details in any way. It is, of course, not possible to describe every conceivable combination of components or methods for purposes of describing various aspects of the subject matter. Thus, the present disclosure is not limited to the specific details and examples shown and described. Thus, the present disclosure is intended to embrace changes, modifications, and variations that fall within the scope of the appended claims.

[0162] To the extent the term "include" or "including" is employed in the detailed description or claims, this term is intended to be inclusive in a similar manner to the interpretation of the term "comprising" when used as a transition word in a claim.

[0163] To the extent the term "or" is used in the detailed description or claims (e.g., A or B), this term is intended to mean "A, B, or both." Where applicants intend to indicate "only A or B but not both," the phrase "only A or B but not both" will be used. Thus, use of the term "or" herein is inclusive and not exclusive.

Claims

1. A program comprising: During the planning of a vehicle route from arrival links through nodes of a graph representing a road network, For an outgoing link, determining that a path of the vehicle from the arrival link to the outgoing link crosses oncoming traffic; responsive to determining that the path of the vehicle crosses oncoming traffic, adding an additional estimated delay of the outgoing link to a route objective function representing the vehicle route; selecting the route including the path across oncoming traffic as an optimal route between a first location and a second location; including the optimal route as part of a delivery schedule for the vehicle; and submitting the delivery schedule for execution; A program having instructions to cause a computer to execute the following.

2. The instruction: determining whether the oncoming traffic has a low traffic volume; (i) controlling the additional estimated delay to be a preset standard delay when the oncoming traffic has low traffic volume, and (ii) controlling the additional estimated delay to be a dynamically generated measure of delay based on an estimated traffic density when the oncoming traffic has non-low traffic volume; The program according to claim 1 , further causing the computer to execute the following:

3. 2. The program of claim 1, wherein the instructions to cause the computer to add the additional estimated delay for the outgoing link include instructions to cause the computer to either (i) obtain a preset standard delay for a traffic crossing turn that results in the estimated delay, or (ii) calculate the additional estimated delay based at least in part on historical speeds and speed limits of the oncoming traffic.

4. 4. The program of claim 1, further comprising instructions for causing the computer to execute, in response to determining that the path of the vehicle crosses oncoming traffic, adding an additional cost of the outgoing link to the route objective function representing the vehicle route.

5. The instructions for submitting the delivery schedule for execution include: instructions to transmit a loading plan to a warehouse computing system for selecting and loading items to be delivered in a delivery vehicle; sending a delivery route to a mobile device associated with the delivery vehicle to cause the driver to display the delivery route and to navigate the vehicle across the oncoming traffic; The program according to any one of claims 1 to 3, comprising:

6. The instructions for submitting the delivery schedule for execution include:

4. The program of claim 1, further comprising instructions for transmitting the delivery schedule to an autonomous delivery vehicle and directing the autonomous delivery vehicle across oncoming traffic to a delivery stop in accordance with the delivery schedule.

7. The instructions for causing the computer to execute for the outgoing link determining that the path of the vehicle from the arrival link to the outgoing link crosses oncoming traffic, obtaining an indication of a travel side of the road applicable to said graph; obtaining a compass bearing for each incoming and outgoing link to the node, including the incoming link and the outgoing link; determining that the compass heading of the arrival link and the compass heading of the departure link indicate that the route is a turn in a direction opposite to the travel side of the road; determining that a first compass heading of a first link entering the node and a first link exiting the node is opposite to the compass heading of the arriving link; The program according to any one of claims 1 to 3, further comprising instructions for causing the computer to execute the above steps.

8. During the planning of a vehicle route from arrival links through nodes of a graph representing a road network, For an outgoing link, determining that a path of the vehicle from the arrival link to the outgoing link crosses oncoming traffic; responsive to determining that the path of the vehicle crosses oncoming traffic, adding an additional estimated delay of the outgoing link to a route objective function representing the vehicle route; selecting the route including the path across oncoming traffic as an optimal route between a first location and a second location; including the optimal route as part of a delivery schedule for the vehicle; and submitting the delivery schedule for execution; A computer-implemented method comprising:

9. 10. The computer-implemented method of claim 8, further comprising navigating an autonomous delivery vehicle from the arrival link to the departure link across the oncoming traffic through the path of the vehicle to a delivery stop location.

10. 10. The computer-implemented method of claim 8 or 9, wherein adding the additional estimated delay of the outgoing link includes calculating the estimated delay based at least in part on historical traffic speeds of one or more links that comprise opposing traffic during a time period when the vehicle route arrives at the node.

11. 10. The computer-implemented method of claim 8 or 9, further comprising, in response to determining that the path of the vehicle crosses oncoming traffic, adding an additional cost of the outgoing link to the route objective function representing the vehicle route.

12. Determining, for the outgoing link, that the path of the vehicle from the arrival link to the outgoing link crosses oncoming traffic, comprises: obtaining an indication of a travel side of the road applicable to said graph; obtaining a compass bearing for each incoming and outgoing link to the node, including the incoming link and the outgoing link; determining that the compass heading of the arrival link and the compass heading of the departure link indicate that the route is a turn in a direction opposite to the travel side of the road; determining that a first compass heading of a first link entering the node and a first link exiting the node is opposite to the compass heading of the arriving link; 10. The computer implemented method of claim 8 or 9, comprising:

13. 1. A computing system comprising: A processor; a memory operatively connected to the processor; an autonomous vehicle controlled by the processor; operatively connected to said processor and said memory and executed by at least one processor of a computer, during planning a route for the autonomous vehicle from an arrival link through a node of a graph representing a road network; For an outgoing link, determining that a path of the autonomous vehicle from the arrival link to the outgoing link crosses oncoming traffic; in response to determining that the path crosses oncoming traffic, adding an additional estimated delay of the outgoing link to a route objective function representing the route; selecting the route including the path across oncoming traffic as an optimal route between a first location and a second location; navigating the autonomous vehicle through the path from the arrival link to the departure link across the oncoming traffic; a computer-readable medium storing computer-executable instructions for causing said computing system to A computing system comprising:

14. The instruction: determining whether the oncoming traffic has a low traffic volume; (i) controlling the additional estimated delay to be a preset standard delay when the oncoming traffic has low traffic volume, and (ii) controlling the additional estimated delay to be a dynamically generated measure of delay based on an estimated traffic density when the oncoming traffic has non-low traffic volume; The computing system of claim 13 , further comprising:

15. The instructions for causing the computing system to determine, for the departure link, that the path of the autonomous vehicle from the arrival link to the departure link crosses oncoming traffic, further comprising: obtaining an indication of a travel side of the road applicable to said graph; obtaining a compass bearing for each incoming and outgoing link to the node, including the incoming link and the outgoing link; determining that the compass heading of the arrival link and the compass heading of the departure link indicate that the route is a turn in a direction opposite to the travel side of the road; determining that a first compass heading of a first link entering the node and a first link exiting the node is opposite to the compass heading of the arriving link; 15. A computing system according to claim 13 or 14, comprising instructions for causing the computing system to:

Images