Vehicle routing through dynamic selection of direction changes to cross 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 Art]]

[0001] Background Turning across oncoming traffic causes delays and increases the risk of collisions. For this reason, operators of delivery fleets implement "hard" rules against turning across traffic in vehicle routing, navigation, and delivery scheduling systems. However, such inflexible "hard" rules against turning across traffic introduce unnecessary complexity and impair the flexibility of vehicle routing, navigation, and delivery scheduling. [[Summary of Invention]] [[Problem to be Solved by the Invention]]

[0002] Accordingly, systems and methods that intelligently permit turns across traffic when such turns across traffic are advantageous are desired. [[Means for Solving the Problem]]

[0003] Summary In one embodiment, a non-transitory computer-readable medium storing computer-executable instructions is presented, wherein the instructions, when executed by at least one processor of a computer, cause the computer to: during development of a vehicle route from an arrival link passing through a node of a graph representing a road network, determine for a departure link that the vehicle's path from the arrival link to the departure link crosses oncoming traffic; in response to determining that the vehicle's path crosses oncoming traffic, add an additional estimated delay for the departure link to a route objective function representing the vehicle route; select a route including the path crossing 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 transmit the delivery schedule for execution.

[0004] In one embodiment of a non-temporary computer-readable medium, a command to cause a computer to determine that the vehicle's route from the arrival link to the departure link crosses oncoming traffic includes a command to cause the computer to: obtain an index of the road's direction of travel applicable to the graph; obtain the compass bearings of each entry and exit link to a node including the arrival link and the departure link; determine that the compass bearings of the arrival link and the departure link indicate that the route is a change of direction in the opposite direction to the road's direction of travel; and determine that the first compass bearings of the first link entering the node and the first link exiting the node are opposite to the compass bearing of the arrival link.

[0005] In one embodiment of a non-temporary computer-readable medium, the instruction causes the computer to further: (i) determine whether the oncoming traffic has low traffic volume; and (ii) control an additional estimated delay so that if the oncoming traffic has low traffic volume, it becomes a preset standard delay; and (ii) if the oncoming traffic has high traffic volume, it becomes a dynamically generated delay scale based on estimated traffic density.

[0006] In one embodiment of a non-temporary computer-readable medium, an instruction causing a computer to add an additional estimated delay to a departure link includes an instruction causing the computer to either (i) obtain a preset standard delay for a traffic crossing turn that will be the estimated delay, or (ii) calculate the additional estimated delay based at least in part on the historical speed and speed limit of the oncoming traffic.

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

[0008] In one embodiment of a non-temporary computer-readable medium, the instruction to transmit a delivery schedule for execution includes an instruction to transmit a load plan to a warehouse computing system regarding the selection and loading of items to be delivered by a delivery vehicle, and an instruction to transmit a delivery route to a mobile device associated with the delivery vehicle to display the delivery route to the driver and to instruct the driver to operate the vehicle to cross oncoming traffic.

[0009] In one embodiment of a non-temporary computer-readable medium, a command to transmit a delivery schedule for execution includes a command to transmit the delivery schedule to an autonomous delivery vehicle and to cause the autonomous delivery vehicle to proceed to a delivery stop position, crossing oncoming traffic, according to the delivery schedule.

[0010] In one embodiment, the method performed by the computer includes, while formulating a vehicle route from an arrival link through a node in a graph representing a road network, determining for an arrival link that the vehicle route from the arrival link to the departure link crosses oncoming traffic; adding an additional estimated delay for the departure link to the route objective function representing the vehicle route in response to the determination that the vehicle route crosses oncoming traffic; selecting the route including the route crossing oncoming traffic as the optimal route between a first location and a second location; including the optimal route as part of the vehicle delivery schedule; and transmitting the delivery schedule for execution.

[0011] In one embodiment, the method performed by the computer further includes navigating an autonomous delivery vehicle from the arrival link to the departure link, crossing oncoming traffic, and following the vehicle's route to the delivery stop location.

[0012] In one embodiment of the method performed by the computer, adding an additional estimated delay to the departure link involves calculating the estimated delay based at least in part on the historical traffic speed of one or more links that constitute the oncoming traffic during the time period in which the vehicle route arrives at the node.

[0013] In one embodiment, the method performed by the computer further includes, in response to a determination that the vehicle's route crosses oncoming traffic, adding an additional cost of the departure link to the route objective function representing the vehicle's route.

[0014] In one embodiment of the method performed by the computer, determining that the vehicle's route from the arrival link to the departure link crosses oncoming traffic includes: obtaining a road-side indicator applicable to the graph; obtaining the compass bearings of each entry and exit link to the node containing the arrival and departure links; determining that the compass bearings of the arrival link and departure link indicate that the route is a change of direction in the opposite direction to the road-side; and determining that the first compass bearings of the first link entering the node and the first link exiting the node are opposite to the compass bearing of the arrival link.

[0015] In one embodiment, the computing system comprises a processor, memory operably connected to the processor, an autonomous vehicle controlled by the processor, and a non-temporary computer-readable medium operably connected to the processor and the memory, wherein the non-temporary computer-readable medium stores computer-executable instructions that, when executed by at least one processor of the computer, cause the computing system to perform the following actions during the formulation of a route for the autonomous vehicle from an arrival link through nodes in a graph representing a road network: determine that the route for the autonomous vehicle from the arrival link to the departure link crosses oncoming traffic; add an additional estimated delay for the departure link to the route objective function representing the route in response to the determination that the route crosses oncoming traffic; select the route including the route crossing oncoming traffic as the optimal route between a first location and a second location; and operate the autonomous vehicle through the route, crossing oncoming traffic from the arrival link to the departure link.

[0016] In one embodiment of the computing system, the instruction causes the computing system to further perform the following: (i) if the oncoming traffic has low traffic volume, control an additional estimated delay so that it becomes a preset standard delay; and (ii) if the oncoming traffic has high traffic volume, control an additional estimated delay so that it becomes a dynamically generated delay scale based on estimated traffic density.

[0017] In one embodiment of the computing system, a command to cause the computing system to determine that the route of an autonomous vehicle from the arrival link to the departure link crosses oncoming traffic includes a command to cause the computing system to: obtain an index of the road's travel side applicable to the graph; obtain the compass bearings of each entry and exit link to the node including the arrival link and the departure link; determine that the compass bearings of the arrival link and the departure link indicate that the route is changing direction in the opposite direction to the road's travel side; and determine that the first compass bearings of the first link entering the node and the first link exiting the node are opposite to the compass bearing of the arrival link.

[0018] The accompanying drawings, which by means of this specification constitute part of this specification, illustrate various systems, methods, and other embodiments of this disclosure. It will be apparent that the element boundaries shown in the drawings (e.g., boxes, groups of boxes, or other shapes) represent one embodiment of the boundary. In some embodiments, one element may be realized as multiple elements, and multiple elements may be realized as one element. In some embodiments, an element shown as an internal component of another element may be realized as an external component, and vice versa. Furthermore, the depiction of elements may not be proportional to the actual size. [Brief explanation of the drawing]

[0019] [Figure 1]Figure illustrating an embodiment of a computing system associated with vehicle route scheduling and navigation through dynamic selection of turns crossing oncoming traffic [Figure 2] Figure showing an exemplary graph representing a road map associated with vehicle route scheduling and navigation through dynamic selection of turns crossing oncoming traffic, including a detailed portion of the graph [Figure 3] Figure illustrating an embodiment of a method associated with vehicle route scheduling and navigation through dynamic selection of turns crossing oncoming traffic [Figure 4] Figure illustrating an embodiment of a method, associated with vehicle route scheduling and navigation through dynamic selection of turns crossing oncoming traffic, for determining whether a route from an arrival link to a departure link crosses oncoming traffic [Figure 5A] Figure showing an example of a traffic-crossing turn route passing through a four-way intersection [Figure 5B] Figure showing an example of a non-traffic-crossing turn route passing through a T-intersection [Figure 5C] Figure showing an example of a traffic-crossing turn route passing through a multi-lane four-way intersection [Figure 5D] Figure showing an example of a non-traffic-crossing turn route passing through a four-way intersection [Figure 5E] Figure showing an example of a traffic-crossing turn route passing through a T-intersection [Figure 5F] Figure showing an example of a non-traffic-crossing turn route passing through an intersection including a one-way road [Figure 5G] Figure showing an example of a traffic-crossing U-turn route passing through a four-way intersection [Figure 6] Figure illustrating an exemplary autonomous vehicle control system configured and / or programmed to operate in accordance with one or more of the systems and methods described herein and / or equivalents thereof [Figure 7]It is a diagram illustrating an exemplary mobile device configured and / or programmed with one or more of the systems and methods described herein and / or equivalents thereof. [Figure 8] It is a diagram illustrating an exemplary computing system configured and / or programmed as a dedicated computing device with one or more of the exemplary systems and methods described herein and / or equivalents thereof. MODE FOR CARRYING OUT THE INVENTION

[0020] DETAILED DESCRIPTION Described herein are systems and methods that enable vehicle route scheduling and navigation via dynamic selection of turns crossing opposing traffic. For example, vehicle routing generated by the systems and methods described herein intelligently incorporates a turn that crosses opposing (or oncoming) traffic when such a turn that crosses traffic is more advantageous than a routing option that avoids it. In one embodiment, systems and methods for route scheduling and navigation are described herein that enable solving the multiple traveling salesman problem (MTSP) involving turns crossing traffic.

[0021] Historical travel times of available road networks, which are required to provide accurate travel times for MTSP solvers (retail delivery, public utilities), do not include the additional delay caused by turning maneuvers. A turn crossing oncoming traffic on a high-traffic road can cause significant delay and introduce the risk of accidents. Therefore, it is considered desirable to minimize the overall need for turns crossing traffic by reconfiguring transportation tasks and / or change vehicle routes between tasks to avoid such turns. Accounting for these hidden delays when solving transportation problems reduces both total travel time and the risk of 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 traffic crossings while calculating a route and assign estimated delays to such crossings. The additional delays are passed to the routing and scheduling objective functions to adapt the resulting schedule to the solver so that the impact of "crossing opposing traffic" crossings is minimized. However, a "hard" rule for traffic crossings in all cases may add unnecessary complexity and associated delays to the vehicle's route. Therefore, it is desirable for systems and methods to generate routes that incorporate traffic crossings only in appropriate circumstances (for example, when opposing traffic has low volume and therefore the delay and increased risk are small, or when opposing traffic has higher volume and there are no other low-objective-cost routing options).

[0023] In one embodiment of the systems and methods described herein, the dynamic model takes into account the fact that turnaround time is greatly affected by traffic density. For example, in this dynamic model, (1) links are tagged with their respective compass orientations so that a routing algorithm can quickly determine whether a candidate route through a node crosses oncoming traffic; (2) links are tagged as residential or non-residential so that turnarounds across residential traffic do not usually result in delays; and (3) links are tagged with speed limits so that turnaround delays can be estimated from the ratio of the speed limit to the historical speed.

[0024] U-turns across opposing traffic are a source of delays and accidents that are not captured by current traffic models used by commercially available MTSP solvers. The systems and methods described herein minimize the total number of low-speed, risky "opposing traffic crossing" U-turns by reorganizing MTSP solutions to include this delay source, either by reducing the number of low-speed U-turns through reconfiguration of vehicle-to-vehicle operations or by rerouting vehicles. The result is a more accurate real-world model, enabling the solver to generate solutions with shorter actual travel times and higher safety. Notably, the systems and methods described herein do not apply "hard" avoidance of U-turns across traffic. Instead, the systems and methods described herein enable dynamic avoidance of U-turns across traffic. U-turns across traffic are avoided only when a better alternative can be found.

[0025] In one embodiment, the systems and methods of this specification perform a preprocessing step to create a graph used as input to a shortest path solver algorithm (such as Dijkstra's algorithm) that generates a route in the route calculation step. In one embodiment, the preprocessing step calculates a "residential area" flag from source road data and stores the flag for each link. In one embodiment, the preprocessing step obtains speed limits from source road data and stores the speed limits for each link. In one embodiment, when constructing the graph, the preprocessing step obtains endpoint coordinates for each link and uses these to tag each link with a compass bearing.

[0026] In one embodiment, the systems and methods of this specification implement a route calculation stage by executing a route solver algorithm to generate a route. In one embodiment, when formulating or processing links arriving at a node in the route calculation stage, this stage checks, for each departure link, whether the arriving non-residential road crosses the path of vehicles crossing an intersection. If it does, this stage calculates an estimated delay and adds the delay to the objective function. If reducing traffic accidents is of significant importance, another charge may be added to the objective function as a numerical value in addition to the delay.

[0027] None of the actions or functions described or claimed herein are performed by the human mind. Any interpretation that any action or function may be performed by the human mind is inconsistent with and contrary to this disclosure.

[0028] Exemplary environment Figure 1 shows one embodiment of a computing system 100 associated with scheduling and navigation of vehicle routes through dynamic selection of direction changes across oncoming traffic.

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

[0030] In one embodiment, the dynamic traffic crossing direction change component 120 comprises one or more components configured to realize the methods, functions, and features described herein associated with route scheduling and navigation by solving a MTSP involving a traffic crossing direction change. The dynamic traffic crossing direction change component 120 may comprise a route generation engine 170 configured to formulate the shortest path between nodes in a road network graph that dynamically include traffic crossing direction changes 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 find the “shortest” path at the point where the objective cost of travel is lowest, based on an objective cost function. The objective cost function may include inputs of travel time, travel distance, traffic crossing direction changes or other traffic disruptions, or other items that constitute the overall burden of travel along the path. The dynamic traffic crossing direction change component 120 may comprise a route generation engine 170 that identifies the lowest cost route between geographic locations in a road network represented as a graph. The dynamic traffic crossing direction change component 120 may include a scheduling engine 173 that determines which delivery items are assigned to which routes and the delivery order of these items. The dynamic traffic crossing direction change component 120 may include a map extension (preprocessing) module that generates information used by the systems and methods described herein for the dynamic inclusion of traffic crossing direction changes into vehicle routing and inserts this information into a graph representing the road network for use. The dynamic traffic crossing direction change component 120 may include a map database 180 that stores one or more graphs representing the road network which can be configured to accommodate the dynamic inclusion of traffic crossing direction changes into vehicle routing.

[0031] Each component of the scheduling, dispatch, and routing system 105 consists of logic that performs the function described as being implemented. In one embodiment, each component of the scheduling, dispatch, and routing system 105 may be implemented as one or more sets of software modules executed by one or more computing devices specifically configured for such execution. In one embodiment, the components of the scheduling, dispatch, 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, dispatch, and routing system 105 may be executed by a central processing unit (CPU) or a network-attached computing device in one or more computing hardware forms such as a general-purpose form factor, a high-density input / output (I / O) form factor, a graphics processing unit (GPU) form factor, and a high-performance computing (HPC) form factor. In one embodiment, each component of the scheduling, dispatch, and routing system 105 is implemented by one or more dedicated computing devices. In one embodiment, several or all components of the scheduling, dispatch, and routing system 105 are implemented by a common (or shared) computing device, although they are represented as discrete units in Figure 1. In one embodiment, the components of the scheduling, dispatch, and routing system 105 may be implemented across multiple computing devices. In one embodiment, the scheduling, dispatch, and routing system 105 may be implemented as a service on a cloud infrastructure.In one embodiment, the scheduling, dispatch, and routing system 105 may be hosted by a dedicated third party, for example, in an IAAS (Infrastructure-as-a-Service), PAAS (Platform-as-a-Service), or SaaS (Software-as-a-Service) architecture. In one embodiment, the scheduling, dispatch, and routing system 105 may be implemented on on-premises infrastructure, such as a set of one or more servers within an enterprise network 115 dedicated to the operation of the scheduling, dispatch, and routing system 105.

[0032] In one embodiment, the components of the scheduling, dispatch, and routing system 105 communicate with each other by electronic messages or signals. These electronic messages or signals may be configured as calls to functions or procedures that access the characteristics or data of the components, such as application programming interface (API) calls. In one embodiment, these electronic messages or signals are transmitted between hosts in a format compliant with the Transmission Control Protocol / Internet Protocol (TCP / IP) or other computer networking protocol. Each component of the scheduling, dispatch, and routing system 105 (i) generates or configures an electronic message or signal that issues a command or request to another component, (ii) uses the infrastructure of the scheduling, dispatch, and routing system 105 to send the message or signal to the other component, and (iii) parses the contents of the received electronic message or signal to identify a command or request that the component can execute, and automatically executes the command or request in response to the command identification.

[0033] API calls may include queries against a database. When executed on a graph, the queries may be configured and executed in, for example, Oracle® Property Graph Query Language (PGQL) and its associated runtime, GraphQL and its associated runtime, or other suitable graph query environment.

[0034] The enterprise network 115 may be associated with a business such as a delivery service operating a convoy or other entity. For simplicity and clarity, 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 operationally connected, together with one or more remote user computers 155, mobile devices 160, handheld delivery information terminals 161, or autonomous or self-driving vehicles 165 connected to the enterprise network 115 via the Internet 110. Each personal computer 145, remote user computer 155, mobile device 160, or handheld delivery information terminal 161 is generally specialized for a specific end user, such as an employee or contractor associated with the business, but this specialization is not required. The personal computers 145 and remote user computers 155 may 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 that can connect to the local area network 140 or the internet 110 via a wireless network such as a mobile phone 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 the USPS® Mobile Delivery Device (MDD), the UPS® Delivery Information Acquisition Device (DIAD), or other similar devices).

[0035] Users of the enterprise network 115 establish an interface with the scheduling, dispatch, and routing system 105 via the internet 110 (or another preferred communication network or combination of networks). In one embodiment, a remote computing system (such as a system of the enterprise network 115, including an autonomous vehicle 165) may access information or applications provided by the scheduling, dispatch, and routing system 105 through a web interface server 135. In one embodiment, the remote computing system 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 by using a web browser on a personal computer 145, a remote user computer 155, a mobile device 160, or the autonomous vehicle 165. In one example, access to the information or applications may be provided by using 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, and 161 on the enterprise network 115 can request the display of a delivery schedule (in whole or in part) in a graphical user interface. In one example, communication is exchanged between a web interface server 135 and a personal computer 145, a server 150, a remote user computer 155, or a mobile device 160, and may take the form of a Remote Representation State Transfer (REST) ​​request using, for example, Java Script Object Notation (JSON) as the data exchange format, or a Simple Object Access Protocol (SOAP) request to an XML server. For example, computers 145, 150, and 155 on the enterprise network 110 can request a delivery schedule.

[0036] In one embodiment, the data store 160 includes one or more databases, including a map database 180 configured to store and provide maps, as well as other databases configured to store and provide routes, loading plans, shipping information, cargo manifests, vehicles or service crews, or other information used by the scheduling, dispatch, and routing system 105. In one embodiment, the databases used herein are Oracle® databases. In some exemplary configurations, the data store 160 may be implemented using one or more Oracle® Exadata computer form factors, 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 a 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, freight vehicles, construction vehicles, garbage collection vehicles, worker transport vehicles, public transport vehicles, rideshare vehicles 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 geographical location where a change of direction is possible, such as a road intersection or bend. In a graph data structure representing a road network, a link (or directed edge) is a data structure that represents a traffic route between neighboring nodes in the graph (intersections, bends, or other geographical locations) or between nodes separated by no more than one link. Links are directed.

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

[0040] Figure 2 shows an exemplary graph 200 representing an exemplary road network associated with scheduling and navigation of vehicle routes through dynamic selection of direction changes across opposing traffic, and includes an enlarged view 205 of a portion 210 of graph 200 superimposed on a visualization of the corresponding portion of the exemplary road network 215. Graph 200 consists of nodes 220 representing specific intersections 225 (or geographical features such as bends) in the exemplary road network 215, and links 230 representing specific directed road segments 235 in the exemplary road network 215. In one embodiment, node 220 may also represent locations of delivery, collection, or service along the road network (e.g., specific addresses). The discussion of nodes referring to intersections may also be understood to represent road bends, locations of specific addresses, and other geographical features of the road network represented by the graph.

[0041] In the exemplary graph 200, node 220 may be represented as a node data structure, such as node data structure 240, which describes the lower-level intersection 225. In one embodiment, the 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 coordinates (nodeCoordinates) field or other data structure for storing coordinate values ​​(latitude and longitude, etc.) of the geographical location of the lower-level intersection 225 represented by the node, a list of incoming links (nodeIncomingLinks) and outgoing links (nodeOutgingLinks), the minimum cost (fastest / shortest) route (nodeRoutes) to all other nodes in the graph, and relevant characteristics such as the travel time and distance for each route (or other costs to reach the node from the starting node), as well as other data structures representing other characteristics of the node.

[0042] In the exemplary graph 200, a link 230 may be represented as a link data structure, such as a link data structure 245, which describes the underlying traffic route (or road segment) 235. In one embodiment, the link data structure, such as the link data structure 245, is configured to include a data structure that describes specific features 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. The value of the link identifier data structure is uniquely associated with the link in the graph. The link data structure 245 may be configured to include a "starting point" node ID (nodeA_ID) field or other data structure that indicates the starting point node of the link, and a "ending point" node ID (nodeB_ID) field or other data structure that indicates the ending point node of the link. The "starting point" node ID and "ending point" node ID data structures together describe the starting point and ending point of the traffic movement represented by the link along the road segment, respectively. The link data structure 245 may include a speed limit (linkSpeedLimit) field or other data structure indicating the statutory speed limit along the road segment represented by the link. The link data structure 245 may 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 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 along the link is low-traffic (residential) or not (non-residential), assuming that traffic along residential areas is generally low-traffic and there is little delay in turning around to cross oncoming traffic. The link data structure 245 may include a toll (linkToll) field or other data structure. As used herein, "toll" is a penalty associated with travel along a given road segment represented by a link.The link data structure 245 may be configured to include additional data structures that represent other characteristics of the link.

[0043] Exemplary Method In one embodiment, each step of the computer method described herein may be performed by a processor of one or more computing devices (such as a processor 810 as shown in Figure 8) which has (i) access to memory (such as memory 815 and / or other computing device components illustrated and described with reference to Figure 8) and (ii) logic (such as dynamic traffic crossing direction change vehicle route scheduling and navigation logic 830 as shown in Figure 8) configured to cause the system to perform the steps of the method. For example, the processor performs the steps of the computer method described herein by accessing and reading from memory. These steps may include (i) obtaining any necessary information, (ii) calculating, determining, generating, classifying, or creating any data, and (iii) storing any data that has been calculated, determined, generated, classified, or created for later use. References to storage or storage 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 computing device 805 or remote computer 865 illustrated and described in Figure 8, or the datastore 130 illustrated and described in Figure 1).

[0044] In one embodiment, each subsequent step of the method is automatically initiated in response to an received signal or analysis of acquired and stored data indicating that the preceding step has been performed to at least the extent necessary for the commencement of the subsequent step. Generally, the received signal or acquired and stored data indicates the completion of the preceding step.

[0045] Figure 3 shows one embodiment of Method 300 associated with scheduling and navigation of vehicle routes by dynamic selection of turning around to cross oncoming traffic. In one embodiment, the steps of Method 300 are performed by a scheduling and dispatch system 105 (as illustrated and described with reference to Figure 1), and at least part of the steps are performed by a dynamic traffic crossing turning component 120. In one embodiment, the dynamic traffic crossing turning component 120 is implemented by a dedicated computing device (e.g., computing device 805) in which dynamic traffic crossing turning vehicle route scheduling and navigation logic is configured. In one embodiment, the dynamic traffic crossing turning component 120 is one or more modules of a dedicated computing device in which logic 830 is configured.

[0046] In one embodiment, Method 300 may be automatically initiated based on various triggers, such as (i) a user (or administrator) of the scheduling, dispatch, and routing system 105 initiates Method 300; (ii) Method 300 is scheduled to be initiated at a specified time or time interval (for example, daily, before items are loaded onto vehicles and delivered); or (iii) a system component of the scheduling, dispatch, and routing system 105 is configured to be automatically initiated based on its internal logic, such as receiving a signal over the network or responding to the analysis of stored data. In one embodiment, Method 300, once initiated, operates repeatedly as described herein, continuously evaluating alternative routing scenarios to find a better route than the currently best route and determining the travel time of the alternative options. This method can evaluate hundreds of alternative route scenarios per second. Thus, according to the method and system described herein, traffic crossings can be dynamically evaluated in real-time alternative route evaluation, and traffic crossings that are dynamically included in running vehicle navigation can be used. Method 300 starts in start block 305 in response to analyzing the received signal or acquired and stored data and determining that the signal or stored data indicates that Method 300 should be started. The process continues to process block 310.

[0047] In one embodiment, the operation of process blocks 310, 315, and 320 is performed during the formulation of a vehicle route by a route generation engine from arrival links through nodes in a graph representing a road network. In one embodiment, the formulation (or generation or creation) of a vehicle route includes processing links or nodes in the graph to be included (or not included) in the route between nodes by performing a step of a shortest path solver. In one embodiment, the route generation engine is a module of the dynamic traffic crossing direction change 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 the graph. In one embodiment, the route generation engine executes Dijkstra's algorithm. In one embodiment, the route generation engine A * The shortest path between nodes in the graph is determined by executing an algorithm such as breadth-first search, Warshall-Floyd algorithm, Bellman-Ford algorithm, Johnson algorithm, or another algorithm. In one embodiment, the route generation engine operates to search for the shortest path between each pair of nodes in the graph.

[0048] In process block 310, the processor determines that, for the departure link, the vehicle's route from the arrival link to the departure link crosses oncoming traffic.

[0049] An arrival link is a link representing the road segment from which a vehicle arrives at the intersection represented by the node. The arrival link is a link from the immediately preceding node to the current node included in the route, generated by the route generation engine 170. An departure link is a link representing the road segment from which a vehicle departs from the intersection represented by the node. The departure link is included in the route by the route generation engine 170 after the traffic crossing direction change characteristics of the route leading to the departure link via the node have been formulated. Oncoming traffic is traffic passing through the intersection represented by the node from a compass direction approximately opposite to the traffic entering the intersection from the road segment represented by the arrival link.

[0050] Figure 4 shows one embodiment of Method 400 for determining whether a route from an arrival link to an departure link crosses oncoming traffic, which is associated with vehicle route scheduling and navigation by dynamic selection of direction changes across oncoming traffic. In one embodiment, at least part of the steps of Method 400 are performed by the route generation engine 170, as well as by execution by a dedicated computing device (such as computing device 805) on which dynamic traffic crossing direction change vehicle route scheduling and navigation logic 830 is configured. Method 400 may be automatically initiated based on various triggers, such as (i) the process block 310 of Method 300 being started, (ii) a user (or administrator) of the scheduling, dispatch, and routing system starting Method 300, (iii) the route generation engine 170 evaluating routes passing through intersections for inclusion in a route from one intersection to another in the road network, or (iv) the reception of a signal over the network indicating that Method 400 is scheduled to start at a specified time or time interval, or in response to analysis of stored data. Method 400 is initiated in start block 405 in response to analyzing the received signal or acquired and stored data and determining that the signal or stored data indicates that Method 400 should be initiated. The process continues to process block 410.

[0051] In process block 410, the processor obtains road-side metrics applicable to the graph.

[0052] In two-way traffic, the right side of the road is the side on which you are permitted to travel forward. In some jurisdictions, such as the United States, the right side of the road is the right side. In some jurisdictions, such as Australia, the right side of the road is the left side. Therefore, in jurisdictions with right-hand traffic, a turn to cross traffic (or a turn to cross oncoming traffic) is considered a left turn, while in jurisdictions with left-hand traffic, a turn to cross traffic is considered a right turn.

[0053] Each graph is associated with a location (such as a city) within a traffic jurisdiction. In one embodiment, road rules (left-hand or right-hand traffic) are stored in the graph's data structure as a characteristic of the graph representing the road network. This road characteristic rule can function as an indicator of the direction of travel on the road. If the road rules are not included in the graph, they may be set by the administrator as a universal characteristic of the scheduling, dispatch, and routing system 105, for example, in the dynamic traffic crossing direction change component 120. In one embodiment, the processor may configure and execute a query to retrieve the direction of travel indicator of the road from the graph (if applicable) in the map database 180 or from system 105 (if applicable). The processor may then store the direction of travel indicator of the road in memory or storage for later processing.

[0054] Thus, once the processor has finished acquiring the road-side indicators applicable to the graph, processing in process block 410 is complete, and processing continues to process block 415.

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

[0056] Compass bearings are vectors that define direction on Earth. In one embodiment, each link in the graph is assigned a compass bearing indicating the direction of traffic flow along the road segment represented by the link, for example by the map extension module 175, as described herein. In one embodiment, the compass bearings are stored as a data structure within the link data structure, as illustrated and described with reference to Figure 2, for example. Incoming links are links leading to a node and represent traffic flowing along the road segment to the intersection represented by the node. Exiting links are links leaving a node and represent traffic flowing along the road segment from the intersection represented by the node. Arrival links belong to a set of incoming links for a node, and departure links belong to a set of exiting links for a node. In one embodiment, the processor may configure and execute a query to retrieve a set of links for a node, including both incoming and outgoing links. The processor then holds the set of links in memory for later processing. Subsequently, for each set of links, the processor constructs and executes a query to obtain the compass bearing, and stores the compass bearing in memory or storage for later processing.

[0057] Thus, once the processor has completed obtaining the compass bearings for each entry and exit link with the node, including the arrival and departure links, the processing in process block 415 is complete, and the process proceeds to decision block 420.

[0058] In decision block 420, the processor determines whether the compass bearing of the arrival link and the compass bearing of the departure link indicate that the route is a change of direction in the opposite direction to the direction of travel on the road.

[0059] In one embodiment, the processor obtains the compass bearings of the arrival link and the departure link from memory or storage, compares them with each other, and determines whether the compass bearing along the path from the arrival link to the departure link through the intersection indicates a clockwise (within 180°) or counterclockwise rotation. 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 with respect to the side of the road being traveled.

[0060] If the direction of the turn and the side of the road being traveled on coincide (right turn and right-hand travel or left turn and left-hand travel), the route through the intersection is not a turn in the opposite direction to the side of the road being traveled on. The processor stores this decision in memory or storage for later processing. Thus, if the processor determines that the compass bearing of the arrival link and the compass bearing of the departure link do not indicate that the route is a turn in the opposite direction to the side of the road being traveled on ("No" in 420), processing in 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 (right turn and left-hand traffic or left turn and right-hand traffic), the route through the intersection is a turn in the opposite direction to the side of the road. The processor stores this decision in memory or storage for later processing. Thus, if the processor determines that the compass bearing of the arrival link and the compass bearing of the departure link indicate that the route is a turn in the opposite direction to the side of the road that was just completed ("yes" in 420), processing in decision block 420 is complete, and processing continues to decision block 430.

[0062] In special cases, if the compass directions of the arrival and departure links are approximately opposite to each other, a U-turn may be identified as a change of direction for traffic crossing. The processor determines that if the compass directions of the arrival and departure links are approximately opposite, the route passing through the intersection is a change of direction in the opposite direction to the direction of travel on the road. The processor stores this decision in memory or storage for later processing. Thus, once the processor determines that the compass directions of the arrival and departure links indicate that the route is a change of direction in the opposite direction to the direction of travel on the completed road ("yes" in 420), processing in decision block 420 is complete, and processing continues to decision block 430.

[0063] In decision block 430, the processor determines whether the first compass bearing 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 bearing of the arrival link.

[0064] In one embodiment, the processor obtains the compass bearing for each incoming and outgoing link. The processor compares the compass bearing of the node's arrival link with the compass bearing of each of the other incoming links to determine if the compass bearing of the incoming link is approximately opposite to that of the arrival link. In this specification, such incoming links may be referred to as opposite traffic arrival links. The processor compares the compass bearing of the node's arrival link with the compass bearing of each outgoing link (excluding the departure link in one embodiment) to determine if the compass bearing of the outgoing link is approximately opposite to that of the arrival link. In this specification, such outgoing links may be referred to as opposite traffic departure links. The processor then determines whether the compass bearings of any pair of opposite traffic arrival links and opposite traffic departure links are approximately opposite to that of the arrival link. The processor stores the result of this determination and processes and stores it later. The presence of both opposite traffic arrival links and opposite traffic departure links indicates the presence of opposite traffic. The absence of both an arrival link for opposing traffic and an departure link for opposing traffic indicates the absence of opposing traffic.

[0065] In one embodiment, the compass direction is "approximately" that direction if it is within 45° on either side of that direction. A narrow range from that direction to 0° is also considered appropriate. This approximation allows the compass direction of each link to be derived from the coordinates of the link's "start" and "end" nodes, rather than strictly matching the physical arrangement of the lower road segments at the intersection. This approximation also allows for intersections that are not perfect right angles. This simple approximation may result in the existence of edge-case intersections where traffic crossing direction changes are not correctly identified. Additional logic may be implemented to improve identification.

[0066] Thus, once the processor has determined that the first compass bearings of the first link entering and leaving the node are not opposite to the compass bearing of the arrival link (430 "No"), the processing in decision block 430 is complete, and the process continues to process block 425. Also, once the processor has determined that the first compass bearings of the first link entering and leaving the node are opposite to the compass bearing of the arrival link (430 "Yes"), the processing in decision block 430 is complete, and the process continues to process block 435.

[0067] In process block 435, the processor registers the determination that the route passing through the intersection is a change of direction for traffic crossing, for example by writing the result to memory or storage, and retrieves and uses this information in subsequent processing. After that, processing in process block 435 is completed, and processing continues to termination block 440, where process 400 terminates.

[0068] In process block 425, the processor registers the determination that the route through the intersection is not a traffic crossing turn, for example by writing the result to memory or storage, and retrieves and uses this information in subsequent processing. After that, processing in process block 425 is completed, and processing continues to termination block 440, where process 400 terminates.

[0069] Referring again to process block 310 of method 300 in Figure 3, once the processor has determined that the vehicle's path from the arrival link to the departure link crosses oncoming traffic, the processing in process block 310 is complete, and the processing continues to process block 320.

[0070] Figures 5A to 5F selectively show exemplary routes through intersections to which Method 400 may be applicable. These selected routes are not exhaustive, and Method 400 is applicable to most common types of intersections. There may also be edge-case intersections where additional logic is required to determine whether a U-turn crosses oncoming traffic. In Figures 5A to 5F, the right side of the road is the driving side, and north is at the top of the page.

[0071] Figure 5A is a Figure 500 showing an example of a traffic crossing direction change route 502 passing through a four-way intersection 504, and includes a graph section showing a node 506 representing the intersection 504 and links representing road segments entering and leaving the intersection 504. The graph section shows, in particular, route arrival link 508, route departure link 510, opposite traffic arrival link 512, and opposite traffic departure link 514 among the links entering and leaving the node.

[0072] According to Method 400, the compass bearing of arrival link 508 is north, and the compass bearing of departure link 510 is west, 90° counterclockwise, indicating that route 502, passing through intersection 504, is a left turn. Since the "left" in a left turn does not coincide with the "right" in right-hand traffic, and route 502 may cross oncoming traffic, the compass bearings of the other links must be checked. The compass bearings of both the oncoming traffic arrival link 512 and the oncoming traffic departure link 514 are south, which is opposite to the north bearing of arrival link 508. Therefore, route 502 is identified as crossing oncoming traffic (turning direction of traffic crossing).

[0073] Figure 5B is a diagram of Figure 515 showing an example of a non-traffic crossing direction change route 517 passing through a T-junction 519, and includes a graph section showing a node 521 representing the T-junction 519 and links representing road segments entering and exiting the T-junction 519. The graph section shows, in particular, the route arrival link 523, the route departure link 525, and the opposite traffic departure link 527 among the links entering and exiting the node. The absence of an opposite traffic arrival link is because there is no traffic entering the intersection 519 in the opposite compass direction to the route arrival link 523.

[0074] The compass bearing of arrival link 523 is north, and the compass bearing of departure link 525 is west, 90° counterclockwise, indicating that route 517, passing through intersection 519, is a left turn. Since the "left" in a left turn does not coincide with the "right" in right-hand traffic, and route 517 may cross oncoming traffic, the compass bearings of the other links need to be checked. Although the opposite traffic departure link 527 has the opposite compass bearing of arrival link 523, there is no opposite traffic arrival link. Therefore, route 517 is identified as not crossing oncoming traffic.

[0075] Figure 5C is a diagram of Figure 530 showing an example of a traffic crossing direction change route 532 in which lanes pass through multiple four-way intersections 534, and includes a graph section showing a node 536 representing the intersections 534 and links representing road segments entering and exiting the intersections 534. The graph section shows, in particular, route arrival link 538, route departure link 540, opposite traffic arrival link 542, and opposite traffic departure link 544 among the links entering and exiting the node.

[0076] No special consideration is needed for multi-lane, two-way roads. Similar to the example diagram 500 in Figure 5A, the compass direction of arrival link 538 is north, and the compass direction of departure link 540 is west, 90° counterclockwise, indicating that route 532, passing through intersection 534, is a left turn. Since the "left" in a left turn does not coincide with the "right" in right-hand traffic, and route 532 may cross oncoming traffic, the compass directions of other links will be checked. The compass directions of both the opposite traffic arrival link 542 and the opposite traffic departure link 544 are south, opposite to the north direction of arrival link 538. Therefore, route 532 is identified as crossing oncoming traffic (a change of direction for traffic crossing). Method 400 will also 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 the opposing traffic arrival link 542 and the opposing traffic departure link 544 are duplicated, the method 400 will still identify a pair of opposing traffic arrival and departure links whose direction is opposite to that of the arrival link 538, thus allowing for the identification of a traffic crossing change of direction.

[0077] Figure 5D is a diagram of Figure 545 showing an example of a non-traffic crossing direction change route 547 through a four-way intersection 549, and includes a graph section showing a node 551 representing the intersection 549 and links representing road segments entering and leaving the intersection 549. The graph section shows, in particular, route arrival link 553, route departure link 555, opposite traffic arrival link 557, and opposite traffic departure link 559 among the links entering and leaving the node.

[0078] The compass bearing for arrival link 553 is north, and the compass bearing for departure link 555 is 90° east clockwise, indicating that route 547, passing through intersection 549, is a right turn. Since the "right" in "right turn" corresponds to the "right" in "right-hand traffic," route 547 cannot cross oncoming traffic. Therefore, route 547 is identified as not crossing oncoming traffic.

[0079] Figure 5E is a diagram of Figure 560 showing an example of a traffic crossing direction change route 562 through a T-junction 564, which includes a graph section showing a node 566 representing the intersection 564 and links representing road segments entering and leaving the intersection 564. The graph section shows, in particular, route arrival link 568, route departure link 570, opposite traffic arrival link 572, and opposite traffic departure link 574 among the links entering and leaving the node.

[0080] T-junction 564 differs from T-junction 519 in Figure 5B in terms of the position of arrival link 568 relative to the other links. The compass bearing of arrival link 568 is north, and the compass bearing of departure link 570 is west, 90° counterclockwise, indicating that route 562 passing through junction 564 is a left turn. Since the "left" in a left turn does not coincide with the "right" in right-hand traffic, and route 562 may cross oncoming traffic, the compass bearings of the other links must be checked. The compass bearings of both the oncoming traffic arrival link 572 and the oncoming traffic departure link 574 are south, opposite to the north bearing of arrival link 568. Therefore, route 562 is identified as an oncoming traffic crossing (a change of direction for traffic crossing). The absence of an eastbound link does not affect this determination.

[0081] Figure 5F is a diagram showing an example of a non-traffic crossing direction change route 577 passing through intersection 579, which includes a one-way road. The diagram includes a node 581 representing intersection 579 and a graph section showing links representing road segments entering and leaving intersection 579. The graph section specifically shows the route arrival link 583 and the route departure link 585 among the links entering and leaving the node. Since the road of arrival link 583 is a one-way road, there are no arrival or departure links for opposing traffic.

[0082] The compass bearing of arrival link 583 is north, and the compass bearing of departure link 585 is west, 90° counterclockwise, indicating that route 577, passing through intersection 579, is a left turn. Since the "left" in a left turn does not coincide with the "right" in right-hand traffic, and route 577 may cross oncoming traffic, the compass bearings of the other links should be checked. However, there are no oncoming traffic departure links or oncoming traffic arrival links. Therefore, route 577 is identified as not crossing oncoming traffic.

[0083] Figure 5G is a diagram of Figure 590 showing an example of a traffic crossing U-turn route 591 in which lanes pass through multiple four-way intersections 592, and includes a graph section showing a node 593 representing an intersection 592 and links representing road segments entering and exiting the intersection 592. The graph section shows, in particular, route arrival links 594, opposite traffic arrival links 595, and integrated route departure links and opposite traffic departure links 596 among the links entering and exiting the node.

[0084] The compass bearing for route arrival link 594 is north, while the compass bearings for the integrated route departure link and the opposite traffic departure link 596 are south. This is a special case indicating a U-turn. A U-turn can obstruct oncoming traffic and is therefore considered a traffic crossing turn. For this reason, route 591 is identified as a traffic crossing turn.

[0085] Referring again to method 300 in Figure 3, in process block 320, in response to the determination that the vehicle's path crosses oncoming traffic, the processor adds an additional estimated delay of the departure link to the route objective function representing the vehicle's route (and may also prevent the traffic crossing by applying an additional charge or crossing cost for the traffic crossing reversal, as discussed herein).

[0086] In one embodiment, a shortest path solver (such as Dijkstra's algorithm) executed by the route generation engine searches for the shortest possible path between nodes by operating on (at least partially) travel time. Each link includes a travel time weight representing the expected time to travel along the road segment represented by the link from the starting intersection (represented by the link's "starting" node) to the ending intersection (represented by the link's "ending" node). Travel time is stored as a value in the link data structure. The travel time for a link may be a historical average of travel times derived from road source data for that link. Travel time may vary depending on the time of day and / or day of the week on which travel along the link occurs. For example, since the expected travel time for a link may be provided on an hourly basis, the processor will use the expected travel time for the time of day when a vehicle will travel along the link. This may be determined by adding the total travel time of the route being planned from the route start time when the vehicle begins travel on the route to the time it enters the link.

[0087] In one embodiment, the objective function of a route or route segment is the cumulative cost of the links between the starting node and an arbitrary given node in the graph (expressed in one embodiment as a function of travel time, travel distance, traffic crossing turnaround delay, and traffic crossing turnaround obstacle cost). Alternatively, the objective function of the route to this arbitrary given node may also be referred to as the cost of the node or the cost to reach the node.

[0088] If the processor determines that a vehicle's path through an intersection reaching a road segment represented by a link involves a U-turn across oncoming traffic, it considers the time required to perform the traffic-crossing U-turn by adding an additional estimated delay to the estimated travel time along the link, thereby increasing the expected travel time. This additional estimated delay (time measurement cost) is included in the objective function for all subsequent nodes following the link. Furthermore, the time of the additional estimated delay added to the estimated travel time may even act to prevent low-risk, low-delay U-turns across light traffic. This prevention is separate from any explicitly added charge for the specific purpose of preventing traffic-crossing U-turns.

[0089] In one embodiment, with respect to the departure link, the processor determines whether the vehicle's route from the arrival link to the departure link crosses oncoming traffic, and also determines whether the oncoming traffic has a low volume of traffic. The processor controls an additional estimated delay so that (i) if the oncoming traffic has a low volume of traffic, it uses a preset standard delay, and (ii) if the oncoming traffic does not have a low volume of traffic, i.e., if the traffic volume is high, it uses a dynamically generated delay scale based on the estimated traffic density.

[0090] In one embodiment, if the daily traffic volume of oncoming traffic is below a threshold of 1,000 vehicles / day, the oncoming traffic is considered to be "lightly congested" or "residential." This is generally a satisfactory threshold, as on average it is less than 1 vehicle / minute of oncoming traffic and allows more than enough time to complete a U-turn across traffic. It is also possible to select a higher or lower value for the threshold based on the estimated time required for a vehicle using the system and method herein to complete a U-turn across traffic, although this time can vary considerably depending on the specific vehicle. For example, a tractor-trailer might take more than 15 seconds to complete a U-turn across traffic from a complete stop, while a small delivery vehicle might take less than 5 seconds to complete the same U-turn. In one embodiment, the processor may calculate or obtain the traffic volume of oncoming traffic, for example from road source data, and compare it to a threshold below which the traffic is considered lightly congested, and above which the traffic is considered not to be lightly congested.

[0091] Alternatively, the system may infer whether traffic volume is low or low based on the location of the road represented by the opposing traffic link in the road hierarchy. Links representing local roads are assumed to represent "low traffic volume" or "residential area" traffic, while auxiliary arterial roads and arterial roads are considered to represent "not low traffic volume" or "non-residential area" traffic. Restricted freeways are generally not considered because traffic crossings on such routes are prohibited, but restricted freeways are also considered to represent "not low traffic volume" or "non-residential area" traffic. In one embodiment, the processor may obtain the location of the road segment responsible for opposing traffic in the road hierarchy from, for example, road source data, and determine that (i) if the road segment is a local road, the traffic volume is low, or (ii) if the road segment is a route with heavy traffic (auxiliary arterial road, arterial road, or restricted freeway), the traffic volume is not low.

[0092] The results of these determinations regarding whether the traffic along the road segment represented by the link is in a "residential area" or has "low traffic volume" may be recorded as an index in the link's data structure. In one embodiment, this allows the opposing traffic to be considered to have low traffic volume based on an index in one or more links indicating that the traffic on one or more links constituting the opposing traffic has low traffic volume. For example, such an index may be included in the link's data structure, such as setting a link to the "true" value of the "residential area" flag (as described herein with reference to Figure 2). Alternatively, the "residential area" flag may be set to a "false" value indicating that the traffic along the road segment represented by the link is in a "non-residential area" or has "not low traffic volume" (i.e., high traffic volume). The processor may obtain the value of the "residential area" flag by querying the graph and accept the obtained value as a determination of whether the traffic on the link is considered to be in a "residential area" or has "low traffic volume".

[0093] After the processor has determined that the oncoming traffic has low traffic volume, it controls the additional estimated delay so that (i) if the oncoming traffic has low traffic volume, it uses a preset standard delay, and (ii) if the oncoming traffic does not have low traffic volume, i.e., if the traffic volume is high, it uses a dynamically generated delay scale based on the estimated traffic density. In one embodiment, the processor controls the additional estimated delay by using different processes to select the additional estimated delay based on whether the traffic has low traffic volume or not.

[0094] In one embodiment, the additional estimated delay of the departure link may be a preset standard delay for traffic crossings that the system receives and stores. For example, the processor may receive a value entered by the system administrator as the standard delay (e.g., 30 seconds or 60 seconds). The processor stores this in storage or memory for later use. Then, when the additional estimated delay is invoked (if a residential traffic crossing turnaround is included in the route), the processor retrieves the value of the standard delay and uses that value as the value of the additional estimated delay in calculations. Thus, in one embodiment, in response to a determination that the oncoming traffic has low traffic volume (or is in a residential area), 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 departure 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 has a considerable volume of traffic, the dynamically generated estimated delay of that heavy oncoming traffic is generated and applied. An observed historical speed below the legal speed limit indicates high traffic density and may result in increased delays for turning around traffic crossings. On the other hand, an observed historical speed at (or above) the legal speed limit indicates lower traffic density and may result in decreased delays for turning around traffic crossings. For this reason, the standard delay may be modified using the ratio of the observed speed to the legal speed limit to more closely fit the situation at the intersection. For example, the processor may receive, store, and retrieve the standard delay as described above. The processor may then generate an adjusted delay (A) by dividing the standard delay (D) by the ratio of the historical average speed (H) to the legal speed limit (L). A lower historical average speed results in a larger adjusted delay, and a higher historical average speed results in a smaller adjusted delay. Optionally, the influence of the ratio on the adjusted delay can be changed by applying a positive multiplier (M) to the ratio of H to L. In one embodiment, the processor generates the adjusted delay by executing Equation 1.

[0096]

number

[0097] The processor retrieves administrator settings D and M from storage. The processor retrieves values ​​H and L from data structures associated with the opposing traffic departure link and / or opposing traffic arrival link. The processor then calculates the adjusted delay A. Thus, the adjusted delay A is a dynamically generated measure of delay as a function of estimated traffic density. In one embodiment, in response to a determination that the opposing traffic has a significant traffic volume (i.e., is in a non-residential area), the processor retrieves pre-configured standard delay (D), historical average speed (H), legal speed limit (L), and multiplier (M) values ​​from memory, calculates the adjusted delay (A) as described herein, and controls the value of the additional estimated delay by providing the adjusted delay as the additional estimated delay.

[0098] In one embodiment, the additional estimated delay of the departure link is calculated based at least in part on the historical traffic speed of one or more links that constitute the oncoming traffic during the time period in which the vehicle route arrives at the node. The historical traffic speed can be broken down into a set of speeds for different time blocks of the day (e.g., a set of 24 hour blocks). This allows the processor to determine, in one embodiment, the time period in which a traffic crossing change of direction occurs, select the H value for the block containing this time period, and then calculate the A value.

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

[0100] In one embodiment, an intersection may have multiple departure links, including traffic crossings. For example, there may be a K-shaped intersection where two or more roads connect on only one side of the intersection, or there may be an intersection where five or more roads approach the intersection to form a star-shaped intersection. Therefore, in one embodiment, for each additional departure link that leaves the node in conjunction with the departure links, the processor identifies the additional departure links, determining whether there is an exit route for vehicles from the arrival link to an additional departure link that crosses light oncoming traffic, and adds the estimated delay for the additional departure link to the route objective function representing the vehicle route. For example, the processor identifies each exit link of the node in conjunction with the departure links, determines whether the route from the arrival link to the link crosses oncoming traffic, determines if the traffic is light if it does, and finally adds the estimated delay by obtaining a standard delay and using it as an estimated delay, or by using it to calculate an adjusted delay and using that adjusted delay as the estimated delay.

[0101] The additional delays incurred on routes involving traffic crossings provide a baseline level of bias against traffic crossings. In one embodiment, a policy can be incorporated into the operation of the system and method herein that further rejects traffic crossings beyond the resulting delays. The introduction of such a policy can reduce the likelihood of traffic accidents inherent in traffic crossings. For example, a standard charge (or crossing cost) can be added to the objective function for each traffic crossing to make routes including traffic crossings more costly. This charge is not based on the cost of vehicle operation along the road segment represented by a given link, but rather is a penalty imposed to prevent the use of the road segment represented by a given link. As used herein, the charge is imposed as a crossing cost, i.e., an obstacle penalty cost for introducing a traffic crossing to a given link. This charge (crossing cost), i.e., penalty, quantifies the degree to which the policy rejects traffic crossings. In one embodiment, the charge reflects the degree of obstacle or risk associated with traffic crossings.

[0102] In one embodiment, in response to a determination that a vehicle's route crosses oncoming traffic, the processor adds an additional cost for the departure link to the route objective function representing the vehicle route. The processor may determine that the vehicle crosses oncoming traffic as described herein with reference to the addition of an additional delay (for example, as illustrated and described with reference to process blocks 310-320). The processor then retrieves a charge value from memory or storage and uses this value as the charge. The charge value may be set by the system administrator. A higher charge implies a stronger policy against traffic crossing diversions. A higher charge implies a lower probability that the shortest route from one node to another will involve a traffic crossing diversion.

[0103] In process block 325, the processor, using a route generation engine, selects a route that includes a path crossing oncoming traffic as the optimal (lowest 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 minimum cost of travel time to reach it. Accordingly, the processor maintains (stores and retrieves and uses later) the routes (including routes that cross oncoming traffic). For example, the processor may write each route from the first location to another location into a data structure associated with the first location in the graph (for example, it may write the routes into an all-node data structure associated with the node representing the first location). A route that crosses oncoming traffic starts at the first location and ends at the second location, and is stored in the all-node data structure at the location associated with the second location in the route.

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

[0106] Thus, once the processor has finished selecting the optimal route between the first and second locations, which includes a route that crosses oncoming traffic, using the route generation engine, the processing in process block 325 is complete, and the processing continues to process block 330.

[0107] In process block 330, the processor includes the optimal route as part of the vehicle delivery schedule, as determined by the scheduling engine. In one embodiment, the scheduling engine 173 runs an MTSP solver. When run by the processor, the MTSP solver accepts as input a set of delivery locations, available delivery convoys, a set of complete routes from each node to each other, and the travel time and distance associated with these routes. From these inputs, the MTSP solver generates a delivery schedule for the set of delivery locations.

[0108] In one embodiment, a delivery schedule describes which goods are delivered by which vehicle and the order in which the vehicles make deliveries. The delivery schedule describes a set of vehicle routes that return to the warehouse from a warehouse through a series of delivery locations (each delivery location being visited collectively only once to perform delivery, collection, or other services). The MTSP selects the optimal route from each node (representing a warehouse or delivery location) to the next node in the assigned set of delivery locations from a set of optimal or minimum cost routes from each node in the graph to each other. Depending on the selected route, the MTSP may also select a route that includes one or more turns across residential traffic.

[0109] MTSP minimizes the delivery objective function for the cost of deliveries across all vehicle routes by distributing delivery locations (and associated deliveries) across vehicle routes. In one embodiment, the delivery objective function may represent one or more of the following: 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 involves a change of direction across residential traffic, the processor includes that 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 a delivery vehicle based on the delivery route (to the delivery location) of the delivery vehicle and include this loading plan in the delivery schedule. The loading plan includes at least a list of delivery items to be delivered to the delivery location. The loading plan may also allow access to the delivery items in the scheduled delivery order by indicating the order in which the delivery items are loaded. The loading plan may also specify the locations within the delivery vehicle where the delivery items are placed.

[0111] In one embodiment, the schedule corresponds to a specific delivery time window that requires delivery at the delivery location. In one embodiment, the MTSP server may identify a better delivery schedule based on the input by training and using a machine learning model.

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

[0113] In process block 335, the processor transmits a delivery schedule for execution. In one embodiment, the processor retrieves the delivery schedule, constructs a message such as a REST request containing the delivery schedule, and transmits the delivery schedule to a remote computer such as computing devices 145, 155, 160, 161. In one embodiment, the message causes all or part of the delivery schedule to be displayed on the 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, allowing the driver to see the route and to direct the vehicle to cross oncoming traffic. In one embodiment, the processor transmits the delivery schedule to a handheld delivery information terminal 161, displaying the vehicle route on a GPS navigation GUI and presenting delivery item (e.g., package) information on the delivery terminal GUI.

[0114] In one embodiment, the processor transmits a loading plan to a warehouse computing system regarding the selection and loading of items to be delivered by a delivery vehicle. In one embodiment, this transmission allows the user to manually execute loading commands to place the appropriate delivery items in the vehicle. In another embodiment, the processor executes the loading 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 approve, reject, or modify the delivery schedule. Such user feedback may be used to train an ML model in the MTSP solver to generate better delivery schedules.

[0116] In one embodiment, the processor transmits a delivery schedule to the autonomous delivery vehicle, causing it to proceed across oncoming traffic to a delivery stop location according to the delivery schedule. In one embodiment, the processor retrieves the delivery schedule, constructs a message such as a REST request containing all or part of the delivery schedule, and instructs the autonomous delivery vehicle to perform deliveries on a specific vehicle route included in the delivery schedule. In response to the transmission of the delivery schedule to the autonomous delivery vehicle, these instructions cause it to proceed across oncoming traffic to a delivery stop location according to the delivery schedule. In one embodiment, the system and method described herein causes the autonomous delivery vehicle to travel across oncoming traffic from the arrival link to the departure link and along the vehicle route to a delivery stop location by providing the autonomous delivery vehicle with delivery routes and completion instructions for deliveries along the route.

[0117] Thus, once the processor has finished sending the delivery schedule for execution, processing in process block 335 is complete, and processing continues to termination block 340, where process 300 terminates.

[0118] In one embodiment, method 300 relies on the availability of values ​​that cannot exist in the graph or in the graph's road source data. In one embodiment, a map extension module (e.g., map extension module 175) may generate these values ​​for the graph from the road source data and store them in the node and link data structure in the map database. In one embodiment, the functions of map extension module 175 are performed by a dedicated computing device (e.g., computing device 805) on which dynamic traffic crossing direction change vehicle route scheduling and navigation logic 830 is configured.

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

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

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

[0122] Exemplary pseudocode In one embodiment, Dijkstra's algorithm is a shortest path solver algorithm executed by the route generation engine 170. At a high level, Dijkstra's algorithm works by overestimating the cost of reaching each other node in the graph from the starting node and visiting each node and its adjacent nodes to see if there are lower-cost route segments (or alternative routes) to each adjacent node. Dijkstra's algorithm may, with modifications according to the systems and methods herein, allow for dynamic cost weighting of traffic crossing diversions to be included in the minimum-cost route formulated by the algorithm, based on whether the oncoming traffic has low traffic volume (or is in a residential area). Table 1 shows pseudocode of an exemplary embodiment of Dijkstra's algorithm, which has been modified to allow for dynamic inclusion of traffic crossing diversions based on the volume of oncoming traffic in the vehicle route.

[0123] [Table 1] TIFF0007917596000003.tif142155

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

[0125] Rows 03-11 of Table 1 contain the initialization steps for the algorithm in Table 1. In rows 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 node cost) is initialized to infinity, the travel time to reach the node from the origin (travelTime[n]) is initialized to infinity, and the previous node (previous[n]) of the optimal path from the origin to the node is set to undetermined. In row 08, the cost to reach the origin (cost[origin]) is set to zero because if the node is already at the origin, there is no cost to reach it. In row 09, all nodes in a set in the graph are placed in array Q, which is a set of unconfirmed nodes in the graph. In row 10, a constant estimated delay time (estimatedDelayTime) is set for residential / low-traffic traffic crossings. In one embodiment, this is the average delay time for all residential traffic crossings based on observed delay times for historical residential traffic crossings. In one example, the estimated delay time may be, for example, 30 seconds, as shown in row 10. Row 10 also sets an additional charge constant (crossingCost). This charge is an additional cost that generally represents the degree to which the system administrator wants to prevent traffic crossings. In the example in Table 1, the charge is set to 0, indicating that residential traffic crossings will not be prevented. Higher charge levels indicate a higher level of prevention of residential traffic crossings. In one embodiment, the estimated delay cost and / or charge may vary depending on the time of day in which the crossing occurs. This may be based on the travel time elapsed from the start of the route to reaching the node.

[0126] Rows 17-60 of Table 1 are while loops for checking all nodes in the graph, and are repeated as long as there are still unchecked nodes in Q. Rows 18 and 19 extract the currently under consideration node (u) from a pair of unchecked nodes Q. The currently under consideration node is the node with the lowest cost. Therefore, in the first iteration of the while loop, the first node extracted from Q becomes the starting node. This is because its cost is 0, while all other nodes have an infinite cost. Rows 20-59, the processor determines, for each unvisited adjacent node (n) of the currently under consideration node (u), whether the path from u to n is a traffic crossing turnaround, as illustrated and described herein with reference to, for example, Figure 4. If the path from u to n is a traffic crossing turnaround, rows 22-50 are executed. If the path from u to n is not a traffic crossing turnaround, another method is executed in rows 51-58.

[0127] If the route from u to n involves a change of direction across traffic, line 22 determines whether the traffic crossing has low traffic volume. If the traffic crossing has low traffic volume, lines 23-24 calculate a provisional cost (tempCost), which is the sum of the cost of the node currently under consideration (cost[u]), the travel time to reach n from u (travelBetween(u,n)), the estimated delay time (estimatedDelayTime), and the fare (crossingCost). In line 25, the provisional cost (tempCost) is compared with the cost of the adjacent node n (cost[n]). If the provisional cost (tempCost) is less than the cost of the neighboring node n (cost[n]), then (i) in line 26, the cost of the neighboring node n (cost[n]) is replaced by the provisional cost (tempCost) whichever is smaller, (ii) in lines 27-29, the travel time to the neighboring node n (travelTime[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 neighboring node n (travelBetween(u,n)), and the estimated delay time (estimatedDelayTime), and (iii) in line 30, the preceding node in the path to the neighboring node (n) is set as the node (u) currently under consideration. If traffic volume is not insignificant, a provisional cost (tempCost) is calculated in rows 37-40, which is the sum of the cost to reach the node currently under consideration (cost[u]), the travel time from u to n (travelBetween(u,n)), the estimated delay time (estimatedDelayTime), the fare (crossingCost), and the dynamically generated traffic density cost (densityCost()). In row 42, the provisional cost (tempCost) is compared to the cost of the adjacent node n (cost[n]).If the provisional cost (tempCost) is less than the cost (cost[n]) of the adjacent node n, then (i) in line 43, the provisional cost (tempCost) is replaced by the cost (cost[n]) of the adjacent node n, (ii) in lines 44-46, the travel time to the adjacent node n (travelTime[n]) is set as the sum of the travel time to 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 preceding node on the path to the adjacent node (n) is set as the node (u) currently under consideration. In one embodiment, the density cost is a function of the estimated traffic density at the intersection represented by the current node (u), as illustrated and described herein with reference to, for example, Equation 1.

[0128] If the path from u to n does not involve a change of direction across traffic (for example, going directly through an intersection or making a change of direction without crossing traffic), a provisional cost (tempCost) is calculated in row 52. This is the sum of the cost of the node currently under consideration (cost[u]) and the travel time to reach n from u (travelBetween(u,n)). In row 53, the provisional cost (tempCost) is compared with the cost of the adjacent node n (cost[n]). If the provisional cost (tempCost) is less than the cost (cost[n]) of the neighboring node n, then (i) in line 54, the cost (cost[n]) of the neighboring node n is replaced by the provisional cost (tempCost) whichever is smaller, (ii) in line 55, the travel time to reach the neighboring node n (travelTime[n]) 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 neighboring node n (travelBetween(u,n)), and (iii) in line 56, the preceding node in the path to reach the neighboring node (n) is set as the node (u) currently under consideration.

[0129] When there are no more unconfirmed nodes Q and every node in the graph has been confirmed, the while loop terminates, and line 63 returns all preceding nodes (or predecessors) of a pair of nodes in the graph. This pair of preceding nodes can be used to construct a set of minimum-cost (optimal) routes from the starting point of the graph to all other nodes. Furthermore, the cost to reach each node in the graph is recorded, including any estimated delay costs and / or charges imposed for turning around traffic crossings in residential areas. Potential routes are not excluded; that is, traffic crossings in non-residential areas (i.e., high-traffic areas) are considered potential routes. The final route is selected based on minimum cost, which may even include turning around traffic crossings of light or heavy traffic (if such turning around is included in the minimum-cost route). Additional criteria for routes to nodes may also be recorded. For example, regardless of the criteria in the cost function of the algorithm, both the total travel time and the total distance of the route may be recorded. The minimum cost routes to all other nodes in the graph, along with their associated costs, travel times, and distances, may be stored as data structures associated with the data structure of the starting node. In one embodiment, the algorithm in Table 1 is executed for each node in the graph set as the starting point, so that a complete set of minimum cost routes is formulated from each node in the graph to each other. Thus, the set of minimum cost routes, along with their respective associated costs, travel times, and distances, are available for acquisition and use by a multi-traveling salesman solver / optimizer, such as by execution by the scheduling engine 173. In one embodiment, the scheduling engine 173 employs continuous optimization with simulated annealing, approximating a globally optimal set of routes in the map by probabilistically selecting between alternative variations of the schedule based on the route objective function and decreasing annealing parameters.

[0130] Selective advantages The systems and methods described herein improve the safety of travel on routes involving traffic crossings and turns.

[0131] One of the challenges overcome here is the use of graphical representations of road networks in digital navigation and routing. These graphs do not include information for evaluating whether a traffic crossing turn is appropriate. For example, a graphical representation of a road network does not indicate which side the road traffic is coming from. The systems and methods described herein enable the evaluation of traffic crossing turns in a graphical representation of a road network that does not indicate which side the road traffic is coming from. This allows a computer to evaluate the feasibility of a traffic crossing turn, taking into account the nature of oncoming traffic, and to evaluate whether or not to include a traffic crossing turn in the travel route (something that was previously not possible for computers). In this way, the systems and methods described herein improve digital navigation technology by enabling a conditional dynamic evaluation of traffic crossing turns when routing vehicles.

[0132] Furthermore, by allowing traffic to roughly perform cross-traffic turns with a nominal standard delay when traffic volume is low, and by dynamically generating a scale of delay applied to cross-traffic turns when traffic volume is high, the same level of safety is maintained, excessive cross-traffic turns are avoided, and safety is improved to the same extent as implementing a "hard" cross-traffic turn-prohibition rule, while providing vehicles with more diverse routing options than a "hard" cross-traffic turn-prohibition rule. This allows the system to ensure similar safety benefits while still making faster routes that occasionally involve cross-traffic turns available.

[0133] Embodiment of a software module Generally, software instructions are designed to be executed by one or more suitably programmed processors that access memory, such as CPU or GPU resources. These software instructions may include, for example, computer executable code and source code that can be compiled into computer executable code. They may also include instructions written in interpreted programming languages ​​such as scripting languages.

[0134] In complex systems, such instructions may be structured as program modules, each performing a specific task, process, function, or action. The overall operation of a set of modules may be controlled or coordinated by the system's main program, operating system (OS), or other form of organizational platform.

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

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

[0137] Embodiments of autonomous vehicles Figure 6 shows an exemplary autonomous vehicle control system 605 configured and / or programmed to operate in accordance with one or more of the systems and methods and / or equivalents described herein. An autonomous vehicle 165 may be operable by the autonomous vehicle control system 605. In one embodiment, the autonomous vehicle control system 605 comprises an on-board computing device 610, such as an exemplary computing system 800, operably connected to the system of the autonomous vehicle 165. In one embodiment, the autonomous vehicle control system 605 comprises vehicle sensors 615. 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 photodetector, 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 the steering wheel, brakes, accelerator, shifter, or indicator systems. The autonomous vehicle control system 605 can access the scheduling, dispatch, and routing system 105 and external data sources 620 such as the traffic / road data source 195 via a wireless or (intermittent) wired communication network such as network 110. The autonomous vehicle control system 605 includes a vehicle actuator 625 configured to produce motion or other actions of the autonomous vehicle 165 in response to control by the autonomous driving logic 630.

[0138] The autonomous driving logic 630 controls, guides, or operates the autonomous vehicle 165 along a route to one or more endpoints through traffic crossing turns 635 by acquiring or receiving a route with traffic crossing turns 635 generated according to the system and method described herein, a map 640, and inputs from vehicle sensors 615, and transmitting control signals to vehicle actuators 625. The autonomous driving logic 630 also acquires or receives current traffic data 645 to notify its control decisions. The route with traffic crossing turns 635 may include a delivery schedule to endpoints along the route. The route 635, map 640, and traffic data may be acquired continuously or intermittently from an external data source 620 by the in-vehicle computing device 610 and stored as a local data structure of the in-vehicle computing device 610 for rapid access by the autonomous driving logic 630.

[0139] The autonomous vehicle 165 may be a full-size road-legal vehicle or a compact vehicle configured to move along sidewalks. In one embodiment, the autonomous vehicle 165 may be equipped with a delivery / recovery device 650 which can be used to deposit, allow access to, receive, and collect deliveries. The delivery / recovery device 650 may be operated by a vehicle actuator 625 in response to control signals sent by the autonomous driving logic. The delivery / recovery device 650 may comprise an automatically operated door configured to allow deliveries, such as packages, to enter and exit the autonomous vehicle 165, and a robotic arm and conveyor device configured to grasp and / or maneuver deliveries into and out of the autonomous vehicle 165. The delivery / recovery device 650 may be used to load deliveries prior to travel along a route involving traffic crossings or to complete deliveries after travel along a route involving traffic crossings.

[0140] In one embodiment, the in-vehicle computing device 610 is configured to generate a route 635 with traffic crossing turns by performing the methods described herein, such as method 300 or method 400, using dynamic traffic crossing direction reversal vehicle route scheduling and navigation logic 655. The in-vehicle computing device 610 may operate as described above in response to the provision of a list or schedule of one or more endpoints for item delivery or collection. Alternatively, a pre-generated route 635 with traffic crossing turns may be provided directly from the scheduling, dispatch, and routing system 105. In one embodiment, the list of endpoints (or routes 635) may be provided to the in-vehicle computing device 610 via a wireless network while the autonomous vehicle 165 is away from its “home” location, which may be particularly useful in item collection operations.

[0141] The formulated routes include only left turns, which are safer and lower-risk U-turns in light traffic; therefore, the risk of collisions for autonomous vehicles permitted to make U-turns across traffic is significantly reduced by implementing the systems and methods described herein. U-turns across traffic in heavy traffic are avoided.

[0142] Embodiments of Mobile Devices Referring here to Figure 7, this figure shows 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 traffic crossing reversal vehicle route scheduling and navigation logic 705 configured to facilitate vehicle route scheduling and navigation by dynamic selection of reversals across oncoming traffic, similar to the logic, systems and methods illustrated and described with reference to Figures 1 to 6. The mobile device 700 may also include a cellular antenna 710. In exemplary embodiments, signal processing and / or control circuits, broadly identified as 720 in Figure 7, may be implemented. In some embodiments, the mobile device 700 includes an audio output 740 such as a microphone 730, a speaker and / or an audio output jack, a display 750, and / or input devices 760 such as a keypad, pointing device, touchscreen, voice-activated, and / or other input devices. The signal processing and / or control circuits 720 and / or other circuits (not shown) of the mobile device 700 may perform data processing, coding and / or encryption, perform calculations, format data, and / or perform other mobile phone functions.

[0143] The mobile device 700 may communicate with a high-capacity data storage 770 that stores data non-volatilely, such as an optical storage device and / or a magnetic storage device (including, for example, an HDD and / or DVD). The HDD may be a mini-HDD containing one or more platters having a diameter smaller than about 1.8 inches. The mobile phone 700 may be connected to memory 780 such as low-latency non-volatile memory such as RAM, ROM, 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 be equipped with a WLAN antenna 795. In this exemplary embodiment, the exemplary system and method can be realized by using this WLAN network interface 790, while other configurations are also 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. The mobile device 700 configured as a handheld delivery terminal may include special software for displaying delivery information, such as the schedule of delivery, pickup, or service sequences at specific locations, as well as order details, on the display 750. The mobile device 700 configured as a handheld delivery terminal may also include special GPS navigation software for displaying routes between scheduled locations on the display 750, guiding the user from one delivery, pickup, or service location to the next.

[0145] Embodiment of a Computing Device Figure 8 shows an exemplary computing system 800, which, as a dedicated computing device, is comprised and / or programmed with one or more exemplary systems and methods and / or equivalents described herein. The exemplary computing device may be a computer 805 comprising a processor 810, memory 815, and input / output ports 820 operably connected by bus 825. In one example, the computer 805 may comprise dynamic traffic crossing reversal vehicle route scheduling and navigation logic 830 configured to facilitate vehicle route scheduling and navigation by dynamic selection of reversals across oncoming traffic, similar to the logic, systems, and methods illustrated and described with reference to Figures 1 to 6. In a different example, the dynamic traffic crossing reversal vehicle route scheduling and navigation logic 830 may be implemented in hardware, a non-temporary computer-readable medium on which instructions are stored, firmware, and / or a combination thereof. Although the dynamic traffic crossing direction change vehicle route scheduling and navigation logic 830 is shown as a hardware component mounted on the bus 825, in other embodiments, the dynamic traffic crossing direction change vehicle route scheduling and navigation logic 830 can also be implemented in the processor 810, stored in memory 815, or stored on disk 835 on computer-readable media 837.

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

[0147] This means may be implemented as an ASIC programmed to perform vehicle route scheduling and navigation, for example, by dynamic selection of turning around to cross oncoming traffic, as illustrated and described herein. Alternatively, this means may be implemented as a stored computer executable instruction that is temporarily stored in memory 815 and then presented to computer 805 as data 840 executed by processor 810.

[0148] Furthermore, the dynamic traffic crossing direction change vehicle route scheduling and navigation logic 830 may provide means (e.g., hardware, non-temporary computer-readable media for storing executable instructions, firmware) for performing vehicle route scheduling and navigation by dynamic selection of direction changes across opposing traffic.

[0149] In a typical configuration of computer 805, the processor 810 may be a wide variety of processors, including dual microprocessors and other multiprocessor architectures. Memory 815 may include volatile memory 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 operably connected to computer 805 by, for example, an input / output (I / O) interface (e.g., a card or device) 845 and input / output ports 820 controlled by at least an input / output (I / O) controller 847. Disk 835 may be, for example, a magnetic disk drive, a solid-state disk drive, a floppy disk drive, a tape drive, a Zip drive, a flash memory card, a memory stick, etc. Furthermore, disk 835 may be a CD-ROM drive, a CD-R drive, a CD-RW drive, a DVD-ROM, etc. Memory 815 may store processes 850 and / or data 840, formatted, for example, as one or more data structures. Disks 835 and / or memory 815 may store an operating system that controls and allocates the 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 I / O port 820.The input / output devices include one or more displays 870, a printer 872 (such as an inkjet, laser, or 3D printer), an audio output device 874 (such as a speaker or headphones), a text input device 880 (such as a keyboard), a pointing and selection device 882 (such as a mouse, trackball, touchpad, touchscreen, joystick, pointing stick, or stylus mouse), an audio input device 884 (such as a microphone), a video input device 886 (such as a video and still camera), a video card (not shown), a disk 835, a network device 855, an autonomous vehicle 890, an IoT (Internet of Things) sensor (not shown), and the like. The input / output ports 820 may include, for example, a serial port, a parallel port, and a USB port.

[0150] Since computer 805 is capable of operating in a network 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 that computer 805 may interact with 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 by computer executable instructions. Thus, in one embodiment, a non-temporary computer-readable / storage medium comprises computer executable instructions containing algorithms / executable applications that, when executed by a machine, cause the machine (and / or associated components) to perform the methods described above. Examples of machines include, but are not limited to, processors, computers, servers operating in cloud computing systems, servers configured in a Software-as-a-Service (SaaS) architecture, and smartphones. In one embodiment, a computing device is implemented by one or more executable algorithms configured to perform any of the disclosed methods.

[0152] In one or more embodiments, the disclosed method or each equivalent is embodied in computer hardware configured to perform the method, or in a module stored in a non-temporary computer-readable medium, and when executed by at least the processor of a computing device, is executed by computer instructions configured as an executable algorithm configured to perform the method.

[0153] For the sake of simplicity, the methods shown in the diagrams are illustrated and described as a series of blocks of algorithms, but it should be understood that these methods are not restricted by the order of the blocks. Some blocks may occur in a different order and / or simultaneously with other blocks than those illustrated and described. Furthermore, not all illustrated blocks may be used to implement the exemplary methods. Blocks may be combined or separated into multiple actions / components. In addition, additional and / or alternative methods may employ additional actions not shown in the blocks.

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

[0155] References such as "one embodiment" or "one example" indicate that while the embodiments or examples described herein may include certain features, structures, characteristics, elements, or limitations, not all embodiments or examples necessarily include such specific features, structures, characteristics, elements, or limitations. Furthermore, repeated use of the expression "in one embodiment" may, but does not necessarily, refer to the same embodiment.

[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 Salesperson 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: Extended Markup Language WAN: Wide Area Network As used herein, “data structure” refers to organized data in a computing system stored in memory, a storage device, or other computer system. A data structure may be any one of the following: 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 (for example, a database contains many data records). Other examples of data structures are similarly possible according to other embodiments.

[0157] As used herein, “computer-readable medium” or “computer storage medium” refers to a non-temporary medium that stores instructions and / or data configured, when executed, to perform one or more of the functions disclosed. In some embodiments, data may function as instructions. Computer-readable medium may include, but is not limited to, non-volatile and volatile media. Non-volatile media may include, for example, optical discs, magnetic discs, etc. Volatile media may include, for example, semiconductor memory, dynamic memory, etc. Common forms of computer-readable medium 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 discs (CDs), other optical media, random-access memory (RAM), read-only memory (ROM), memory chips or cards, memory sticks, solid-state storage (SSDs), flash drives, and other media on which a computer, processor, or other electronic device can function. Various media may include storage instructions for algorithms configured to perform one or more of the functions disclosed and / or claimed, when selected for implementation in one embodiment.

[0158] As used herein, “logic” refers to a component implemented by a computer or electrical hardware, an executable application or program module instruction set on a non-transient medium, or a combination thereof, for performing any of the functions or operations disclosed herein, and / or causing another logic, method, and / or system to perform a function or operation as disclosed herein. Equivalent logic may include firmware, an algorithm-programmed microprocessor, discrete logic (e.g., ASIC), at least one circuit, analog circuit, digital circuit, programmed logic device, memory device containing algorithm instructions, etc., any of which may be configured to perform one or more of the functions disclosed. In one embodiment, logic may include one or more gates, combinations of gates, or other circuit components configured to perform one or more of the functions disclosed. Where multiple logics are described, it may be possible to combine multiple logics into one. Similarly, where a single logic is described, it may be possible to distribute that single logic among multiple logics. In one embodiment, one or more of these logics are corresponding structures associated with the execution of the function disclosed and / or claimed. The selection of the type of logic to implement may be based on desired system conditions or specifications. For example, if higher speed is a consideration, hardware will be selected to implement the function. If lower cost is a consideration, stored instruction / executable application will be selected to implement the function.

[0159] An "operable connection," or a connection in which an entity is "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 between two entities may transmit signals directly to each other, or through one or more intermediate entities (e.g., a processor, operating system, logic, or non-transient computer-readable medium). An operable connection may also be formed by the use of logical and / or physical communication channels.

[0160] As used herein, "user" includes, but is not limited to, one or more people, one or more computers, or other devices, or a combination thereof.

[0161] Although embodiments of the disclosure have been illustrated and described in considerable detail above, this is not intended to limit, nor does it limit, the scope of the attached claims in any way. Naturally, it is impossible to describe all conceivable combinations of components or methods for the purpose of illustrating various aspects of the subject matter. Therefore, this disclosure is not limited to the specific details or examples illustrated and described. Accordingly, this disclosure is intended to encompass changes, improvements, and variations included in the attached claims.

[0162] To the extent that the term “include” or “including” is used in the detailed description or claims, it is intended to be comprehensive in a manner similar to the interpretation of the term “comprising” when used as a transition word in a claim.

[0163] To the extent that the term “or” is used in the detailed description or claims (for example, A or B), it is intended to mean “A, B, or both.” If the applicants intend to indicate “only A or B, but not both,” the expression “only A or B but not both” would be used. Thus, the use of the term “or” in this specification is inclusive and not exclusive.

Claims

1. It is a program, During the process of formulating vehicle routes from arrival links through nodes in a graph representing the road network, Regarding the departure link, it is determined that the vehicle's route from the arrival link to the departure link crosses oncoming traffic, In response to the determination that the vehicle's route crosses oncoming traffic, an additional estimated delay of the departure link is added to the route objective function representing the vehicle's route, Selecting the route, including the path that crosses oncoming traffic, as the optimal route between the first location and the second location, The optimal route is included as part of the vehicle's delivery schedule, Send the aforementioned delivery schedule for execution, It has instructions to cause the computer to execute, With respect to the departure link, the command causing the computer to determine that the vehicle's route from the arrival link to the departure link crosses oncoming traffic is, To obtain indicators for the driving side of the road applicable to the graph, Obtaining the compass bearing of each entry and exit link to the node, including the arrival link and the departure link, It is determined that the compass bearing of the arrival link and the compass bearing of the departure link indicate that the aforementioned route is a change of direction in the opposite direction to the side of the road being traveled. Determining that the first compass bearing of the first link entering the node and the first link leaving the node is opposite to the compass bearing of the arrival link, A program that includes instructions to cause the computer to execute the following.

2. The aforementioned instruction is, To determine whether the aforementioned oncoming traffic has a low volume of traffic, (i) when the traffic volume of the oncoming traffic is low, the additional estimated delay is controlled to be a predetermined standard delay; (ii) when the traffic volume of the oncoming traffic is not low, the additional estimated delay is controlled to be a dynamic generation scale of delay based on the estimated traffic density. The program according to claim 1, which causes the computer to further execute the following.

3. The program according to claim 1, wherein the instruction causing the computer to add an additional estimated delay to the departure link includes an instruction causing the computer to either (i) obtain a preset standard delay for a traffic crossing turn that constitutes the estimated delay, or (ii) calculate the additional estimated delay based at least in part on the historical speed and speed limit of the oncoming traffic.

4. The program according to any one of claims 1 to 3, further comprising an instruction causing the computer to add an additional cost of the departure link to the route objective function representing the vehicle route in response to a determination that the vehicle's route crosses oncoming traffic.

5. The instruction to transmit the delivery schedule for execution is: Instructions are sent to the warehouse computing system to select and load items to be delivered by delivery vehicles, and to send a loading plan. The delivery route is transmitted to a mobile device associated with the delivery vehicle, causing the driver to see the delivery route, and an order is given to the driver to operate the vehicle so as to cross the oncoming traffic. A program according to any one of claims 1 to 3, including the program described in any one of claims 1 to 3.

6. The instruction to transmit the delivery schedule for execution is: The program according to any one of claims 1 to 3, which includes transmitting the delivery schedule to the autonomous delivery vehicle and issuing a command to move the autonomous delivery vehicle across the oncoming traffic to the delivery stop position in accordance with the delivery schedule.

7. During the process of formulating vehicle routes from arrival links through nodes in a graph representing the road network, Regarding the departure link, it is determined that the vehicle's route from the arrival link to the departure link crosses oncoming traffic, In response to the determination that the vehicle's route crosses oncoming traffic, an additional estimated delay of the departure link is added to the route objective function representing the vehicle's route, Selecting the route, including the path that crosses oncoming traffic, as the optimal route between the first location and the second location, The optimal route is included as part of the vehicle's delivery schedule, Send the aforementioned delivery schedule for execution, Includes, With respect to the aforementioned departure link, determining that the vehicle's route from the aforementioned arrival link to the aforementioned departure link crosses oncoming traffic means that To obtain indicators for the driving side of the road applicable to the graph, Obtaining the compass bearing of each entry and exit link to the node, including the arrival link and the departure link, It is determined that the compass bearing of the arrival link and the compass bearing of the departure link indicate that the aforementioned route is a change of direction in the opposite direction to the side of the road being traveled. Determining that the first compass bearing of the first link entering the node and the first link leaving the node is opposite to the compass bearing of the arrival link, The way a computer performs actions, including [specific actions].

8. The method performed by the computer according to claim 7, further comprising driving the autonomous delivery vehicle from the arrival link to the departure link, across the oncoming traffic, and along the vehicle's route to the delivery stop position.

9. The method performed by a computer according to claim 7 or 8, wherein adding an additional estimated delay to the departure link includes calculating the estimated delay based at least in part on the historical traffic speed of one or more links that constitute the oncoming traffic during the time period in which the vehicle route arrives at the node.

10. A method performed by a computer according to claim 7 or 8, further comprising adding an additional cost of the departure link to the route objective function representing the vehicle route in response to a determination that the vehicle's route crosses oncoming traffic.

11. A computing system, Processor and Memory that is operablely connected to the aforementioned processor, An autonomous vehicle controlled by the aforementioned processor, It is operablely connected to the aforementioned processor and memory, and when executed by at least one processor of the computer, During the process of formulating the route for the autonomous vehicle from arrival links passing through nodes in a graph representing the road network, Regarding the departure link, it is determined that the route of the autonomous vehicle from the arrival link to the departure link crosses oncoming traffic, In response to the determination that the aforementioned route crosses oncoming traffic, an additional estimated delay of the departure link is added to the route objective function representing the aforementioned route, Selecting the route, including the path that crosses oncoming traffic, as the optimal route between the first location and the second location, The autonomous vehicle is operated from the arrival link to the departure link, crossing the oncoming traffic, and along the aforementioned route. A computer-readable medium that stores computer-executable instructions for causing the computing system to perform the above, Equipped with, With respect to the departure link, the command causing the computing system to determine that the route of the autonomous vehicle from the arrival link to the departure link crosses oncoming traffic is, To obtain indicators for the driving side of the road applicable to the graph, Obtaining the compass bearing of each entry and exit link to the node, including the arrival link and the departure link, It is determined that the compass bearing of the arrival link and the compass bearing of the departure link indicate that the aforementioned route is a change of direction in the opposite direction to the side of the road being traveled. Determining that the first compass bearing of the first link entering the node and the first link leaving the node is opposite to the compass bearing of the arrival link, A computing system including instructions to cause the computing system to perform the above.

12. The aforementioned instruction is, To determine whether the aforementioned oncoming traffic has a low volume of traffic, (i) when the traffic volume of the oncoming traffic is low, the additional estimated delay is controlled to be a predetermined standard delay; (ii) when the traffic volume of the oncoming traffic is not low, the additional estimated delay is controlled to be a dynamic generation scale of delay based on the estimated traffic density. The computing system according to claim 11, further having the computing system perform the above.

Images