Patent Application
20130197797
Various systems exist for assisting individuals with planning a route between a source point (e.g., starting location) and a destination point (e.g., ending location). Many route planning systems allow users to alter routes by “dragging” portions of the routes around via a graphical user interface (GUI), for example. Some navigation systems can provide guidance (e.g., turn by turn) to direct a user along a route (e.g., following existing roads, streets, highways, etc.). Such navigation systems often provide auditory and/or visual information directing users toward their destination and can redirect users toward their destination if they stray from a planned route, for example.
Such route planning and/or navigation systems are often based on modeled maps of an environment and can be referred to as model-based systems and/or map-based systems. Modeling errors associated with maps of such systems can occur due to changes to the environment, for instance. As an example, particular roads may become congested (e.g., due to traffic) or impassible (e.g., due to a blockade, flooding, a bridge being out, etc.). As such, model-based systems can require frequent updating to the model to ensure that accurate models are maintained (e.g., such that safe and/or efficient routes are provided).
Many model-based route planning systems automatically generate a number of routes for a user based on a user-provided source and destination. The automatically generated route(s) are often cost-minimal routes (e.g., routes generated based on cost analysis) based on user preferences (e.g., shortest distance, fastest, fewest turns, no highways, etc.). The system can then automatically generate the cost-minimal route(s) based on one or more of the user preferences.
Route planning systems can be useful for planning various types of routes corresponding to various modes of transport. For instance, route planning systems can be used for planning walking routes, jogging routes, bicycling routes, and/or motorized vehicle routes, among other types of routes and/or combinations thereof
The present disclosure includes systems and methods for route planning. As an example, a computer implemented method for route planning can include generating a first portion of a planned route between a first location and a second location by assembling a set of previously traversed route segments each corresponding to one or more of a number of previously traversed routes, aggregating the set of previously traversed route segments with a number of route segments determined by a model-based route planning subsystem and corresponding to a second portion of the planned route, and causing the planned route to be provided to a display of a computing device.
A number of embodiments can include instructions stored on a computer readable medium and which are executed by a processor to perform methods for route planning as described herein. As one example, instructions stored on a computer readable medium can be executed by a processor to generate a planned route between a first location and a second location, the planned route comprising a number of route segments. The number of route segments can include: a set of previously traversed route segments each corresponding to one or more of a number of previously traversed routes, and a number of model-based route segments aggregated with the set of previously traversed route segments. Instructions stored on a computer readable medium can be executed by a processor to evaluate the planned route based on stored previous execution data corresponding to a number of previously executed traversals of at least one of the number of previously traversed route segments of the set, and stored map data corresponding to at least one of the number of model-based route segments.
As an example, a system for route planning can comprise: a computing device including processor and memory resources and a user interface configured to receive user input corresponding to a source, a destination, and a number of user preferences associated with a route to be planned; a previous execution subsystem including a previous execution database and an assembly module configured to assemble a set of previously traversed route segments stored in the previous execution database and representing at least a first portion of a planned route between the source and destination; a model-based subsystem including a map database and a map-based planning module configured to determine a number of route segments based on information stored in the map database and corresponding to at least a second portion of the planned route; and an aggregation module configured to generate a complete planned route between the source and destination by aggregating one or more previously traversed route segments of the set assembled by the assembly module and representing the at least a first portion of the planned route and one or more of the number of route segments determined by the map-based planning module and corresponding to the at least a second portion of the planned route.
In the following detailed description of the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how one or more embodiments of the disclosure may be practiced. These embodiments are described in sufficient detail to enable those of ordinary skill in the art to practice the embodiments of this disclosure, and it is to be understood that other embodiments may be utilized and that process, electrical, and/or structural changes may be made without departing from the scope of the present disclosure.
The figures herein follow a numbering convention in which the first digit or digits correspond to the drawing figure number and the remaining digits identify an element or component in the drawing. Similar elements or components between different figures may be identified by the use of similar digits. For example, 112 may reference element “12” in
As described further herein, user interface 130 can allow a user to provide system 100 with information such as source and destination information along with user preferences associated with a route from the source to destination. Examples of user preferences include preferences associated with distance (e.g., shortest route), time (e.g., fastest route), simplicity (e.g., fewest turns), congestion (e.g., traffic), concealment level, anti-prediction (e.g., number of times route has been travelled and/or whether route has been travelled recently), mode of transport (e.g., on foot, bicycle, all-terrain vehicle, car, truck, bus, etc.), among various other preferences.
The model-based route planning subsystem 102 can be based on modeled maps of an environment and can employ cost analysis to generate cost-minimal routes based on source, destination, and preference information, for instance. In the example illustrated in
The information overlay module 106 can include context-specific information (e.g., metadata) associated with the map database 104. For instance, information overlay module 106 can include metadata associated with the locations of construction projects, traversability information based on mode of travel, information concerning degree of concealment, estimated traversal time information, and/or other information associated with map database 104 and which can be used for cost analysis by subsystem 102.
The model-based planning module 108 includes executable instructions associated therewith and which are executable by a processor to generate (e.g., determine) routes, or portions thereof (e.g., route segments), based on information corresponding to map database 104 and information overlay module 106. The planning module 108 can, responsive to information (e.g., source, destination, and user preference information) provided to subsystem 102 via user interface 130, for instance, generate the routes, or portions thereof, based on cost analysis. As described further herein, in various embodiments, subsystem 102 can be employed in conjunction with subsystem 110 to generate planned routes, which can be displayed to a user (e.g., via user interface 130 or otherwise). For instance, as indicated by arrow 109, routes or route segments determined by model-based module 108 can be provided to a route segment aggregation module 120, in various embodiments. In a number of embodiments, and as described further below, the aggregation module 120 is configured to generate a planned route by aggregating a number of route segments determined by a model-based route planning subsystem (e.g., subsystem 102) and an assembled set of previously traversed route segments as determined by a previous execution subsystem (e.g., subsystem 110).
The previous execution subsystem 110 can be used to plan routes based on data corresponding to previous traversals of routes between particular sources and destinations (e.g., previous execution data corresponding to as-executed traversals of a route). In various embodiments, the routes can correspond to previously planned routes between the source and destination. As such, in various embodiments, the subsystem 110 can be used to compare and/or contrast routes as planned with actual traversals (e.g., executions) of those planned routes. For example, in various instances, an individual may stray from a route as planned for various reasons. As described further herein, previous execution data corresponding to previous traversals of a planned route, including differences between the route as planned and the route as executed, can provide useful information that may be used for future route planning, for instance. Such previous execution data can be incorporated into future route planning and analysis without requiring explicit information input from a user, for example. As one example, a previously planned route between source A and destination B may include traversal of a bridge. Previous execution data corresponding to a number of recent actual traversals of the route indicates that various users did not traverse the bridge, but rather went around it in one fashion or another. Such previous execution data can be incorporated into future route planning such that future routes avoid traversal of the bridge. For instance, the bridge may be assumed to be hazardous, inoperable, etc., to account for the purposeful avoidance of it by users. Tracking actual execution of as planned routes including tracking of the context associated with the actual execution can provide valuable information that can be used in future route planning.
In the example illustrated in
The contextual metadata module 114 includes contextual metadata corresponding to the previously traversed routes and/or route segments associated with database 112. The contextual metadata can include, for example, data regarding mode of transport, time of day, weather, traversal time, and/or safety concerns, among various other types of contextual metadata associated with a previously traversed route or route segment. In a number of embodiments, the contextual metadata can include previously planned routes (e.g., route plans) associated with previous execution data stored in database 112. Such contextual metadata can be used for various purposes. For instance, the contextual metadata can be considered in association with ranking a number of generated route plans (e.g., according to user preferences. The contextual metadata can also be used in association with evaluating (e.g., critiquing) a route planned by a user. For instance, the contextual metadata can indicate that a user-planned route goes through an extremely crowded area at a particular time (e.g., rush hour). As described further below, in a number of embodiments, a user can be informed of such information (e.g., via a display associated with user interface 130) and provided an opportunity to modify the planned route in response to the same. Although shown as a separate module, the contextual metadata 114 can be included within database 112. Furthermore, the contextual metadata can be appended to the previous execution data on a segment by segment basis.
As indicated by arrows 105 and 113, data can be shared between subsystems 102 and 110. For instance, data stored in map database 104 can be used to update contextual metadata corresponding to module 114, and data stored in previous execution database 112 can be used to update module 106.
The context-aware segment retrieval module 116 can include instructions executed (e.g., by a processor) to retrieve particular route segments from database 112 based on the contextual metadata corresponding thereto. For example, a user may have a preference that his/her planned route not include traffic congestion. As such, route segments associated with traffic congestion (e.g., as indicated by contextual metadata corresponding to those route segments) may not be retrieved from database 112, or may be assigned a lower ranking, in association with generating the planned route for the user. As another example, route segments corresponding to deviations from a corresponding route plan may be assigned a higher ranking, based upon an assumption that an error in the planned route resulted in the deviations. Therefore, the context-aware segment retrieval module 116 can be used to filter undesirable route segments, and/or to prefer other route segments, based on their associated contextual metadata.
The previous execution segment retrieval and assembly module 118 includes instructions executable to generate at least a portion of a planned route by assembling a number of route segments (e.g., a number of route segments provided by context-aware segment retrieval module 116). In a number of embodiments, the module 118 can generate multiple planned routes (or at least portions thereof) between a source and destination by assembling a set of previously traversed route segments each corresponding to one or more of a number of previously traversed routes. The routes or segments generated by module 118 can be ranked (e.g., according to user preferences) and, as indicated by arrow 119, can be provided to route segment aggregation module 120. The aggregation module 120 can generate a planned route by aggregating the assembled set of previously traversed route segments (as determined by module 118) and a number of route segments determined by a model-based route planning subsystem (e.g., route segments generated by module 108 of subsystem 102).
In a number of embodiments, a planned route can be generated by route planning system 100 (and provided to a user via user interface 130) without the use of route segment aggregation module 120. That is, a planned route generated solely by the previous execution subsystem 110 (e.g., without aggregating route segments assembled by module 118 and route segments generated by module 108 of model-based subsystem 102) can be provided to a user. Similarly, a planned route generated solely by the model-based subsystem 102 (e.g., without aggregating route segments generated by module 108 and route segments assembled by module 118 of previous execution subsystem 110) can be provided to a user. However, aggregating route segments generated by modules 108 and 118 (e.g., via aggregation module 120) can provide benefits such as possibly providing a user with a more optimal planned route as compared to a route generated solely by one of subsystems 102 and 110. For example, in some instances, previous execution data may not be available for one or more route segments. As such, in a number of embodiments, route segments generated by subsystem 102 can be used to fill in for those route segments for which previous execution data is unavailable (e.g., does not exist). Moreover, it can be beneficial to present a user of system 100 with the option of being provided a route generated solely by subsystem 102, solely by subsystem 108, or based on an aggregation of route segments generated by both subsystems 102 and 110.
Arrow 121 shown in
Although not explicitly illustrated in
In a number of embodiments, and as illustrated by arrow 123, a user can (e.g., via user interface 130) make manual adjustments (e.g., edits) to a planned route provided by the aggregation module 120 (e.g., based on the plan critique/analysis or otherwise). For instance, a user may decide to adjust one or more preferences associated with the planned route or may decide to manually adjust one or more of the route segments corresponding to the planned route. As illustrated by arrow 124, one or more adjusted route plans can be provided to user interface 130 (e.g., based on manual plan edits of the user).
In a number of embodiments, the execution of the planned route (e.g., the actual traversal of the planned route) can be monitored. For instance, instructions associated with planning improvement module 126 can be executed to determine whether the route is traversed as planned, or whether the traversing entity (which may be the user interacting with user interface 130 or a different individual being tracked via a separate computing device, for example) deviates from the planned route. In a number of embodiments, certain information can be inferred by system 100 responsive to monitoring of the actual execution of the planned route. For instance, system 100 can infer that a certain point associated with one or more planned routes is undesirable (e.g., dangerous, congested, or blocked) responsive to determining (e.g., detecting) a number of divergences (e.g., deviations) from planned routes at a particular point, for instance. Such information can be used to update contextual metadata associated with system 100 (e.g., metadata 114 and/or 106) via route planning improvement module 126, for example.
Although arrow 125 is shown from user interface 130 to planning improvement module 126, in a number of embodiments, the information corresponding to the actual traversal of the planned route can be provided to module 126 via a different computing device (e.g., a mobile navigation device used by the traversing entity). As an example, the user interface 130 can correspond to a computing device used by a mission planner, and the planned route can be transmitted to a separate computing device of an entity traversing the route as part of mission execution.
In a number of embodiments, monitoring the actual traversal of the planned route can be used for planning future routes. For example, divergence from the planned route can be incorporated into future route planning by system 100 (e.g., such that a user providing the same source, destination, and preferences in the future may not be presented with the same route). As such, the system 100 can, in effect, learn from monitoring planned routes as executed and incorporate the learned information into future planned routes. As indicated by arrow 127, information from planning improvement module 126 can be provided to subsystem 110 (e.g., to update contextual metadata 114 based on the monitored execution of planned routes). Similarly, arrow 129 indicates that information from planning improvement module 126 can be provided to subsystem 102 (e.g., to update informational overlay 106 based on the monitored execution of planned routes). In a number of embodiments, a user can manually provide information to planning improvement module 126 (e.g., via user interface 130). Such information can include context information (e.g., contextual metadata) associated with one or more segments of the planned route (e.g., information regarding reasons why the user did or did not traverse the route as planned, for instance).
In a number of embodiments, and as shown in
The computer readable instructions 243 can include various sets of instructions in the form of application and/or program modules (e.g., software), which can be executed by processor resources 244 in association with performing various route planning embodiments as described herein. As an example, the instructions 243 can include instructions (e.g., instructions corresponding to aggregation module 120) that are executed to generate a planned route and provide the planned route to user interface 230 (e.g., to display 248) in association with embodiments described herein. In various embodiments, portions of subsystems such as subsystems 102 and 110 shown in
As shown in
As illustrated in
In a number of embodiments, the previous execution data associated with the previously traversed routes 351-1, 351-2, 351-3, . . . , 351-N can be segmented. As such, database 312 can include previous execution data corresponding to segments of previously planned routes. For example, previous execution data corresponding to previously traversed routes 351-1, 351-2, 351-3, . . . , 351-N can be segmented based on intersections between the previously traversed routes and/or based on divergences between the previously traversed routes.
In the example shown in
As shown in
In various embodiments, route segments from database 312 can be retrieved based on their corresponding context data (e.g., via context-aware retrieval module 116 shown in
In this example, the ranked route list 364 includes three ranked routes (RRs) 366-1 (RR_1), 366-2 (RR_2), and 366-3 (RR_3), although embodiments are not limited to a particular number of routes provided to a user in the form of a ranked list of routes. The ranked route 366-1 includes assembled route segments (S_1, S_2, and S5), the ranked route 366-2 includes assembled route segments (S_1, S_2, and S_6), and the ranked route 366-3 includes assembled route segments (S_8, S_9, and S_6). The assembled routes 366-1, 366-2, and 366-3 can be listed in a variety of manners. For example, a “best” route (e.g., optimal) of the assembled routes 366-1, 366-2, and 366-3 of list 364 may be listed first. As another example, the ranked list 364 may be organized such that each of the assembled routes represents a “best” route based on maximizing a particular user preference, for instance.
As described above, in various embodiments, the assembled routes (which can represent at least a portion of a planned route) can be aggregated with one or more route segments provided by a model-based route planning subsystem (e.g., subsystem 102 shown in
As an example, one or more of the assembled routes 366-1, 366-2, and 366-3 may not represent a complete planned route between a particular source and destination. In such instances, a complete planned route between the source and destination can be generated by aggregating the assembled route segments corresponding to previously executed route segments and one or more route segments provided by a model-based route planning subsystem.
The example shown in
The first portion 470-1 of the planned route between locations 472 and 492 comprises a set of previously traversed route segments 474-1, 474-2, 474-3, and 474-4. Route segment 474-1 spans from location 472 to location 473, route segment 474-2 spans from location 473 to location 475, route segment 474-3 spans from location 477 to location 479, and route segment 474-4 spans from location 481 to location 492. The previously traversed route segments 474-1, 474-2, 474-3, and 474-4 can each correspond to one or more of a number of previously traversed routes, which may or may not be routes from location 472 to location 492, for instance.
As illustrated in the example of
In a number of embodiments, and as illustrated in
In a number of embodiments, and as illustrated in
As described herein, in a number of embodiments, a planned route such as route 470-3 can be displayed on a computing device and/or can be evaluated based on stored previous execution data corresponding to one or more of the previously traversed route segments 474-1, 474-2, 474-3, and 474-4 and/or based on stored map data corresponding to one or more of the model-based route segments 476-1 and 476-2.
The planned route 570 can comprise a number of previously traversed route segments (e.g., segments 474-1, 474-2, 474-3, and 474-4 shown in
In a number of embodiments, information corresponding to the as-planned route segment 582-2 can be inferred based on the tracking of the actual traversal of route 570. For instance, it may be inferred that traversing segment 582-2 is undesirable based on the fact that the actual traversal of the route 570 involved deviation 588. This information can be inferred regardless of whether a route planning system is aware (or is made aware) of the actual reason for the deviation 588 from the as-planned route 570 and can be used in future route planning. For instance, a future planned route may comprise a path other than segment 582-2 between locations 583 and 585 (e.g., based on an inference that segment 582-2 is undesirable).
As an example, information associated with a previous execution subsystem such as subsystem 110 described in
The present disclosure includes systems and methods for route planning. As an example, a computer implemented method for route planning can include generating a planned route between a first location and a second location. The planned route comprises a number of route segments and the method can include evaluating the planned route using stored previous execution data associated with a number of previously executed traversals of at least one of the number of route segments.
Although specific embodiments have been illustrated and described herein, those of ordinary skill in the art will appreciate that an arrangement calculated to achieve the same results can be substituted for the specific embodiments shown. This disclosure is intended to cover adaptations or variations of one or more embodiments of the present disclosure. It is to be understood that the above description has been made in an illustrative fashion, and not a restrictive one.
Combination of the above embodiments, and other embodiments not specifically described herein will be apparent to those of skill in the art upon reviewing the above description. The scope of the one or more embodiments of the present disclosure includes other applications in which the above structures and methods are used. Therefore, the scope of one or more embodiments of the present disclosure should be determined with reference to the appended claims, along with the full range of equivalents to which such claims are entitled.
In the foregoing Detailed Description, some features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the disclosed embodiments of the present disclosure have to use more features than are expressly recited in each claim.
Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
The subject matter of this disclosure was made with government support under Contract Number N1OPC20185 awarded by the Department of Interior. Accordingly, the U.S. Government has certain rights to subject matter disclosed herein.
