Efficient vehicular route determination in the absence of detectable lane markings

Abstract

It is provided a method, device and apparatus for determining a navigational route for an ego vehicle, which may be performed by a mobile computing system. The method comprises: determining, based at least in part on sensor data from one or more sensors of the ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles (710); determining a plurality of candidate driving tubes based on at least in part on the historical trail data, wherein each candidate driving tube of the plurality of candidate driving tubes may comprise a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle is expected to remain once the ego vehicle enters into the candidate driving tube (720); outputting an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes (730).

Description

EFFICIENT VEHICULAR ROUTE DETERMINATION IN THE ABSENCE OF DETECTABLE LANE MARKINGSBACKGROUND

[0001] The present invention relates generally to the field of electronic vehicle systems, and more specifically to Advanced Driver-Assist Systems (ADAS) .

[0002] Lane centering control (LCC) and other ADAS functions are becoming increasingly prevalent in modern vehicles. However, to operate correctly, LCC typically relies on lane boundaries or similar road markers. This is typically not an issue in highway driving, where lane boundaries are often reliably present. In urban driving environments, however, there can be various scenarios in which these road markers are not present. When a vehicle encounters a section of a road without such markers, LCC functionality may need to rely on other information to successfully navigate through the section.

[0003] BRIEF SUMMARY

[0004] Embodiments herein enable navigation of a vehicle through a section of road, such as a section of road without lane boundaries, by utilizing historical trail data from one or more leading vehicles to generate a plurality of candidate driving tubes with which a vehicle may navigate through a section of road. A driving tube may then be selected based on safety and / or efficiency checks. The plurality of candidate driving tubes may be derived from one or more historical trails identified in the historical trail data, which may be obtained using one or more sensors of the vehicle. The one or more historical trails may be based on a polynomial fitting to the historical trail data. According to some embodiments, one or more historical trails may be generated, which can increase potential routes the vehicle may take.

[0005] An example method of determining a navigational route for an ego vehicle, according to this description, includes determining, based at least in part on sensor data from one or more sensors of the ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles. The method may also include determining a plurality of candidate driving tubes based at least in part on the historical trail data, where each candidate driving tube of the plurality of candidate driving tubes may include a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle  is expected to remain once the ego vehicle enters into the candidate driving tube. The method may furthermore include outputting an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes..

[0006] An example device for determining a navigational route for an ego vehicle, according to this description, may include one or more transceivers, one or more memories, and one or more processors communicatively coupled with the one or more transceivers and the one or more memories. The one or more processors may be configured to determine, based at least in part on sensor data from one or more sensors of the ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles. The one or more processors further may be configured to determine a plurality of candidate driving tubes based at least in part on the historical trail data, where each candidate driving tube of the plurality of candidate driving tubes may include a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle is expected to remain once the ego vehicle enters into the candidate driving tube. The one or more processors further may be configured to output an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes.

[0007] An example apparatus, according to this disclosure, comprises means for determining, based at least in part on sensor data from one or more sensors of an ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles. The apparatus may further comprise means for determining a plurality of candidate driving tubes based at least in part on the historical trail data, wherein each candidate driving tube of the plurality of candidate driving tubes comprises a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle is expected to remain once the ego vehicle enters into the candidate driving tube. The apparatus may further comprise means for outputting an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes.

[0008] This summary is neither intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification of this disclosure, any or all drawings, and each claim. The foregoing, together with other features and examples, will be described in more detail below in the following specification, claims, and accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 is an illustration providing an overhead view of an example traffic scenario.

[0010] FIG. 2 is an illustration providing an overhead view of another example traffic scenario.

[0011] FIG. 3A is a flow diagram of a traditional algorithm used by lane centering control (LCC) in the absence of lane markings.

[0012] FIG. 3B is a flow diagram of a proposed algorithm that may be used by LCC in the absence of lane markings, according to some embodiments.

[0013] FIG. 4 is a graph of data points and polynomial fittings of historical trails, according to an example.

[0014] FIG. 5 is a graph 500 illustrating a raw driving to cluster, corresponding to the example in FIG. 4.

[0015] FIG. 6 is an illustration providing an overhead view of a scenario similar to FIG. 2, showing a driving tube cluster, according to some embodiments.

[0016] FIG. 7 is a flow diagram of a method of determining a navigational route for an ego vehicle, according to some embodiments.

[0017] FIG. 8 is a block diagram of an example mobile computing system.

[0018] Like reference symbols in the various drawings indicate like elements, in accordance with certain example implementations. In addition, multiple instances of an element may be indicated by following a first number for the element with a letter or a hyphen and a second number. For example, multiple instances of an element 110 may be indicated as 110-1, 110-2, 110-3 etc. or as 110a, 110b, 110c, etc. When referring to such  an element using only the first number, any instance of the element is to be understood (e.g., element 110 in the previous example would refer to elements 110-1, 110-2, and 110-3 or to elements 110a, 110b, and 110c) .DETAILED DESCRIPTION

[0019] Several illustrative embodiments will now be described with respect to the accompanying drawings, which form a part hereof. The ensuing description provides embodiment (s) only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the embodiment (s) will provide those skilled in the art with an enabling description for implementing an embodiment. It is understood that various changes may be made in the function and arrangement of elements without departing from the scope of this disclosure.

[0020] As referred to herein, the term “ego vehicle” refers to a vehicle of interest. For all on-board systems of a particular vehicle, that vehicle would be considered the “ego vehicle, ” and the sensors of the ego vehicle would perceive the environment around the vehicle. For autonomous or semi-autonomous driving, navigation systems of an ego vehicle determine a route of travel for the ego vehicle to take. The ego vehicle is the central point of reference for the vehicle’s sensors and algorithms, which continuously monitor and respond to the surrounding environment to ensure safe and efficient navigation.

[0021] Additionally, as referred to herein, the term “trail” may refer to a path that a vehicle takes through a section of road (or other drivable terrain) . For an ego vehicle, a “historical trail” may refer to a path taken by one or more leading vehicles (vehicles in front of the ego vehicle) . Further, a “tube” or “driving tube” may refer to a path or trail having lateral boundaries. That is, where a “trail” may be defined by a single line that traces the center of a pathway, a “tube” may define boundaries (e.g., left and right boundaries) of a pathway. As described in more detail herein, a tube defined for a given vehicle, therefore, may depend on the width of the vehicle.

[0022] Lane Centering Control (LCC) is an advanced driver assistance system (ADAS) function designed to maintain a vehicle’s position within a designated lane. The system utilizes a combination of vehicle sensors (e.g., cameras, lidar, radar, etc. ) and software algorithms to detect lane markings and continuously monitor the vehicle’s  trajectory. LCC generally does not operate using high-definition (HD) maps that may be used in other ADAS functions. Upon detecting any deviation from the center of the lane, the LCC system may automatically the steering to realign the vehicle within the lane.

[0023] As previously noted, LCC functionality typically relies on lane boundaries, which are typically detected by cameras onboard a vehicle. When lane markings are not detected on a section of the road, a vehicle may rely on other data to navigate through the section. Traditionally, an ego vehicle would follow a path, or trail, generated from one or more paths that one or more vehicles in front of it ( “leading vehicles” ) have taken. However, the quality of the generated trail may be unsteady, and the generated trail can result in overall inefficiencies in traffic.

[0024] Embodiments herein address these and other issues by enabling navigation of an ego vehicle through a section of road using a robust algorithm that uses historical trail data from one or more leading vehicles to generate a plurality of candidate driving tubes with which a vehicle may navigate through a section of road. Various aspects relate generally to vehicle navigation and / or autonomous driving Some aspects more specifically relate to LCC functionality in an environment in which lane markings are not detected by an ego vehicle or cannot otherwise be used, and without reliance on an HD map. In some examples, a plurality of candidate trails may be determined based, at least in part, on historical trail data from one or more leading vehicles. A plurality of candidate driving tubes may then be determined from the plurality of candidate trails, and a driving tube for the ego vehicle may be selected from the plurality of candidate driving tubes based on the results of a safety and / or efficiency check. According to some embodiments, rather than using a traditional linear least squares (LLS) algorithm to perform a traffic flow fitting that combines trails from leading vehicles into a single trail, embodiments may use historical trail data from one or more leading vehicles to determine a plurality of candidate trails from which the plurality of driving tubes may be derived.

[0025] Particular aspects of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. In some examples, by generating and evaluating a plurality of driving tubes, the described techniques can be used to select a navigation route for the ego vehicle in a manner that is more robust than traditional techniques. Further, embodiments herein can increase traffic  efficiency while maintaining safety requirements. These and other advantages will be apparent to a person of ordinary skill in the art in view of the following disclosure.

[0026] FIG. 1 is an illustration providing an overhead view of an example traffic scenario 100 in which there may be insufficient lane markings for a section of a road 110 to allow vehicles to provide LCC functionality. In this example, the road 110 includes not only a crosswalk 120, but also a construction area 130, identified by construction markers 140, resulting in the need for vehicle 150 to merge into an adjacent lane. As can be seen, lane markings 160 are disrupted by the construction and crosswalk 120. Automated navigation through this section of the road 110 can be particularly challenging, especially for vehicle 150, which has to change lanes.

[0027] The root of the challenge for these vehicles may come from the way in which lanes are determined. Vehicles may often comprise one or more cameras that capture images of the vehicle’s surroundings. For example, a front-facing camera located on a vehicle may take images (e.g., video) of the environment in front of a vehicle. Also, one or more motion sensors (e.g., accelerometers, gyroscopes, etc. ) on and / or in the vehicle can provide motion data indicative of movement of the vehicle. Such sensors may be incorporated into inertial measurement unit (IMU) . In some embodiments, the image and motion data can be fused to provide additional positioning information. This can then be used to help identify and track lane boundaries on a road along which the vehicle is traveling. This identification and tracking of lane boundaries can be a primary enabler for several ADAS functionalities for a vehicle, including LCC functionality. Often, a filter, such as an extended Kalman filter (EKF) or particle filter, is used to jointly track lane boundaries and the vehicle position. However, this functionality can be thwarted in situations such as scenario 100, in which lane markings are absent, unclear, or obscured.

[0028] FIG. 2 is an illustration providing an overhead view of a simplified scenario 200, used to help illustrate how solutions can provide LCC functionality in the absence of clear lane markings (e.g., such as in scenario 100 of FIG. 1) . In the scenario 200 of FIG. 2, an ego vehicle 210 is preceded by two leading vehicles 220-1 and 220-2 (collectively and generically referred to herein as leading vehicles 220) along a road 230 (or other drivable area) . The road 230 lacks lane markings that would enable the ego vehicle 210 to simply use lane markings to navigate this section of the road 230. Further,  an obstacle 240 (e.g., construction area) requires that the ego vehicle 210 alter its current heading 250 in order to continue down the road 230.

[0029] In situations such as scenario 200, traditional techniques for determining a navigation path for the ego vehicle 210 often use a simple traffic flow fitting process. This process, illustrated in FIG. 3A, typically utilizes a linear least squares (LLS) algorithm to combine the trajectories of one or more leading vehicles 220 into a single trail 260 for the ego vehicle 210 to use to navigate the section of the road 230.

[0030] However, this process can be problematic. One reason is that the generated trail (e.g., trail 260) is based on traffic flow. Thus, this process typically leads an ego vehicle 210 into high-traffic areas even when other routes (e.g., trail 270) are available. This can reduce traffic efficiency. Another reason is that the quality and shape of the generated trail often can be unsteady due to raw data quality from different sensors. More specifically, different sensor types (e.g., radar, lidar, and cameras) can have different qualities when sensing the location and route of leading vehicles 220, leading to unsteadiness and the resulting generated trail. Any unsteadiness or uncertainty in a route for an ego vehicle 210 can raise safety and / or comfort concerns.

[0031] Embodiments address these and other issues by utilizing a more robust process for determining a navigational route for an ego vehicle in the absence of lane markers. Details are provided in FIG. 3B, described below.

[0032] FIG. 3B is a flow diagram of a process 310 by which a navigation path for an ego vehicle through a no-lane area may be determined, according to an embodiment. Operations are illustrated as blocks, and outputs are illustrated as arrows. The process 310 may be executed by a mobile computing system, such as a vehicle computer, and may be incorporated into other functionality in the vehicle, such as LCC functionality. Example components of a mobile computing system are discussed below with respect to FIG. 8. As with other figures herein, FIG. 3B is provided as a nonlimiting example only, and alternative embodiments may incorporate variations of the process 310, depending on desired functionality.

[0033] The process 310 may begin at block 320 with a traffic flow fitting that outputs a raw trail cluster. That is, in contrast with traditional techniques (e.g., as illustrated in FIG. 3A) that combine paths from multiple leading vehicles to a single trail using an LLS algorithm, the traffic flow fitting at block 320 may comprise identifying multiple trails  and fitting the trails to a mathematical function. An example of this is illustrated in FIG. 4.

[0034] FIG. 4 is a graph 400 providing an example of how multiple historic trails may be fitted to multiple mathematical functions. In graph 400, the X and Y axes may represent spatial dimensions in the X and Y directions, respectively. The X and Y dimensions may be based, for example, on a coordinate system of an ego vehicle in which the Y dimension represents a forward (positive Y values) and backward (negative Y values) direction with respect to the ego vehicle and the Y dimension represents left (positive X values) and right (negative X values) with respect to the ego vehicle. (In alternative embodiments, alternative coordinate systems may be used. ) Data points 410, represented by circles as shown, include a first set of data points 410-1 corresponding to a first historical trail, a second set of data points 410-2 corresponding to a second historical trail 410-2, and a third set of data points 410-3 corresponding to a third historical trail. (To avoid clutter, only some data points are labeled. )

[0035] Each data point 410 may represent a location of a leading vehicle at given time, and each set of data points 410 may correspond with a respective leading vehicle, leaving a historical trail of data points 410 over time. The data points 410 may represent locations of leading vehicles detected by one or more sensors (e.g., camera, radar, lidar, etc. ) of the ego vehicle. Data from multiple sensors may be fused to result in a data point 410. In general, data points 410 created from fused data may be more reliable than data points 410 determined from data of a single sensor, although different types of sensors may have different reliability. Moreover, in some embodiments, leading vehicles may determine their own location and send location information (e.g., using wireless communications) to the ego vehicle.

[0036] As illustrated, each set of data points (e.g., the first set of data points 410-1, the second set of data points 410-2, and the third set of data points 410-3) may be fitted to a respective mathematical function. According to some embodiments, historical trails may be fitted to 3-order polynomials. (In alternative embodiments, different mathematical functions and / or different order polynomials may be used. ) The 3-order polynomial equations for three different vehicles (e.g., as shown in FIG. 4) may be as follows:

[0037] y1=a1+b*x+c*x2+ d*x3          (Eqn. 1)

[0038] y2=a2+b*x+c*x2+ d*x3          (Eqn. 2)

[0039] y3=a3+b*x+c*x2+ d*x3         (Eqn. 3)

[0040] In this set of equations, y1 , y2, and y3 may correspond to polynomial fittings 420-1, 420-2, and 420-3 of FIG. 4, respectively. Moreover, the polynomial fittings may correspond to the rock trail cluster output of the traffic flow fitting f block 320 shown in FIG. 3B. Coefficients of the order higher than zero (b , c , and d ) may be commonly estimated, while the coefficient of order zero (a1 , a2 , and a3 ) may represent a lateral offset for each respective leading vehicle. By using common coefficients (other than the zero-order coefficients) , the problem is simplified, lowering computational requirements for fitting data points to three-order polynomials. This can also increase the consistency or robustness of the solution.

[0041] In matrix form, all coefficients (a, b, c, and d) may be represented by θ, and Eqns. 1-3 above may be represented as:

[0042] To estimate the best parameters (coefficients) for fitting data points (e.g., 410) to polynomial fittings (e.g., 420) , a weighted linear least squares (WLLS) operation may be performed by minimizing ERR (θ) using the following equation:

[0043] In Eqn. 5, the weighting matrix W consists of the weight factor of every data point (e.g., data points 410) , which is calculated by its distance with the ego vehicle when it was recorded, the source of the sensor type, and the object type. Generally, the closer the distance, the more reliable the detected data point. And thus, the greater the weight. Further, data points derived from more reliable sources may be given greater weight. (As noted, data points derived from the fusion of multiple sensors may be more reliable than data points derived from a single sensor. ) Object types may comprise different types of vehicles (trucks, motorcycles, cars, etc. ) .

[0044] The best parameters can be calculated by the following equations, which repeats at every cycle:

[0045] θ*= (XTWX) -1XTWY. (Eqn. 6)

[0046] Here, a “cycle” may reflect the frequency at which the route is updated. For example, if the route is updated every 100 ms, each cycle would be 100 ms. Other embodiments may have longer or shorter cycles, which may vary depending on desired functionality and / or other factors.

[0047] Once the best parameters (coefficients) are determined, the fitting of data to polynomials is complete the polynomials may be reasons represented as follows:

[0048] These polynomials may then serve as center lines for raw driving tubes in the driving tube generation process (e.g., block 330 of the process 310 of FIG. 3B) , described in more detail below.

[0049] It can be noted that, according to some embodiments, some filtering of data points (e.g., data points 410 of FIG. 4) may be made prior to their use in the process outlined above with respect to Eqns. 1-7. For example, data points may be filtered if they do not meet a reliability and / or accuracy threshold. To this end, some embodiments may perform outlier detection to identify and filter out outlying data points. Additionally or alternatively, sets of data points corresponding with respective leading vehicles may be excluded from the traffic flow fitting process above in certain circumstances, such as if the ego vehicle has an insufficient number of data points in a data point set. According to some embodiments, sets of data points corresponding with respective leading vehicles may be included into the traffic flow fitting process to help maximize spatial diversity in the rock trail cluster produced by the traffic flow fitting process, which can lead to an increased spatial diversity in candidate driving tubes and a potentially more efficient navigation path for the ego vehicle to take.

[0050] According to some embodiments, it may be desirable to have the zero-order coefficients (e.g., a1, …, an) sparsely positioned on both sides of the ego vehicle to help broaden the variety of optional routes (driving tubes) available to the ego vehicle to choose from to navigate through a no-lane area. Thus, as noted above, data points from historical trails may be selected for the traffic flow fitting process above based at least in part on meeting a threshold spatial diversity of the zero-order coefficients. If there are insufficient data points to provide such spatial diversity, an ego vehicle may generate additional trails (center lines for driving tubes) . This can be done, for example, by  generating additional zero-order coefficients for Eqn. 7 above, and using other coefficients as determined by the traffic flow fitting process. As discussed in more detail below, safety and efficiency checks can help ensure that these generated trails do not result in the ego vehicle taking a dangerous path.

[0051] The generation of additional trails may use one or more factors to determine a number and / or location of the additional trails (e.g., spatial offsets defined by the zero-order coefficients) . Some factors may be static, such as the width of the ego vehicle. Other factors may be dynamic, such as the vehicle heading and speed. Ultimately, these and / or other factors may be considered to enable an ego vehicle to generate one or more additional trails to provide the desired spatial diversity for subsequently generated driving tubes.

[0052] Referring again to FIG. 3B, the traffic flow fitting process of block 320 results in a “raw trail cluster, ” or plurality of polynomial fittings (e.g., polynomial fittings 420 of FIG. 4) . As previously noted, these raw trails / polynomial fittings can then serve as center lines of driving tubes in a raw driving tube cluster, which may be generated as part of the driving tube generation process at block 330.

[0053] FIG. 5 is a graph 500 that illustrates a raw driving tube cluster generated from the polynomial fittings 420 of FIG. 4. Again, the X and Y coordinates may be based on a vehicle coordinate system of the ego vehicle in which the ego vehicle may be located at coordinates (0, 0) . In graph 500, the raw driving tube cluster comprises three driving tubes: 510-1, 510-2, and 510-3. The center lines 520-1, 520-2, and 520-3 of the various driving tubes 510 may be based on the raw trail cluster (polynomial fittings 420) of FIG. 4. (Other driving tube clusters may comprise a larger or smaller number of driving tubes, which may correspond with a larger or smaller number of historical trails and corresponding polynomial fittings used in the traffic flow fitting process than illustrated in FIG. 4. ) As previously noted, a driving tube 510 may refer to a path that the ego vehicle may take, similar to a trail. Unlike a trail, however, a driving tube 510 may include boundary lines 530. When using a driving tube 510, the ego vehicle is intended to stay within the boundary lines 530. The width 540 of each driving tube 510, which define boundary lines 530 based on center lines 520, may be based on the width of the ego vehicle, with some buffer. As described in more detail below, the ego vehicle may be  subject to collision if there are objects that are within the boundary lines 530 of a driving tube 510.

[0054] FIG. 6 is an illustration providing an overhead view of a scenario 600, similar to FIG. 2, provided to help illustrate how a safety and efficiency check may be used to select a driving tube from the raw driving tube cluster. Similar to the scenario 200 of FIG. 2, the scenario 600 of FIG. 6 includes an ego vehicle 610 is preceded by two leading vehicles 620-1 and 620-2 (collectively and generically referred to herein as leading vehicles 620) along a road 630 (or other drivable area) . The road 630 lacks lane markings that would enable the ego vehicle 610 to simply use lane markings to navigate this section of the road 230 (e.g., using traditional LCC) . Further, obstacle 640 (e.g., construction area) requires that the ego vehicle 610 alter its current heading 650 in order to continue down road 630.

[0055] In this scenario, the ego vehicle 610 may perform a process as described herein (e.g., process 310) for performing a traffic flow fitting (e.g., using historical trails detected from the leading vehicles 620 and / or generating trails as described above) and driving tube generation. As a result, the ego vehicle 610 may generate a driving cluster comprising driving tubes 660-1, 660-2, and 660-3 (collectively and generically referred to herein as driving tubes 660) . Referring again to the process 310 of FIG. 3B, the ego vehicle 610 may then perform a safety and efficiency check, as shown at block 340, to select a driving tube with which the ego vehicle 610 may navigate this section of road 630.

[0056] The safety and efficiency check may evaluate the safety and efficiency of each driving tube 660 in a raw driving tube cluster. According to embodiments, this may comprise calculating a cost function for each driving tube 660 and selecting the driving tube 660 with the lowest resulting value. According to some embodiments, the cost function may be as follows:

[0057] where the first portion of the cost function comprises a safety check:

[0058] wc·CollisionRisk,

[0059] and the second portion of the cost function comprises an efficiency check:

[0060] Put generally, the safety check of a given driving tube may be a result of an analysis of whether there is a collision if the ego vehicle takes the driving tube. In Eqn. 8, the term CollisionRisk may comprise a 0 or 1, based on an analysis of hether a collision is unlikely (0) or whether a collision is possible (1) . In some embodiments, the weight wcthat is multiplied with CollisionRisk may be a very large number (or infinitely large) to ensure that the resulting cost function of any driving tube with a risk of collision sufficiently high so that the driving tube is not selected. In the scenario 600 of FIG. 6, because obstacle 640 intrudes on the first driving tube 660-1, the resulting cost function of the driving tube 660-1 will not be selected over any driving tube (e.g., second driving tube 660-2 or third driving tube 660-3) that does not have a collision risk. According to some embodiments, if all driving tubes 660 have an infinitely large cost function value (or a value above a maximum threshold) , this may mean that all tubes have a collision rest and fail the safety check. In this case, the ego vehicle 610 may not select any driving tube. In such instances, a driver of the ego vehicle 610 may be notified to take over driving functionality of the ego vehicle.

[0061] The determination of whether there is a collision risk may be based on sensor information and / or other information available to the ego vehicle 610. For example, information similar to how the ego vehicle 610 detects leading vehicle 620, the ego vehicle may determine the size, shape, and location of the obstacle 640. This can include, for example, sensors on the ego vehicle such as cameras, lidar, radar, etc. Additionally or alternatively, it may include information received from leading vehicles 620 (e.g., which may use their sensors to detect obstacle 640) , roadside units (RSUs) , vulnerable road users (VRUs, such as bicycles, pedestrians, etc. ) , or the like. This information may be received, for example, using wireless communications, such as vehicle-two-everything (V2X) and / or other cellular communications, Wi-Fi communications, Bluetooth, etc.

[0062] With respect to the efficiency check of Eqn. 8, speed and distance are considered. The term TrafficSpeed may refer to an average speed of leading vehicles that traveling in the tube. For example, in FIG. 6, TrafficSpeed may reflect the average speed of leading vehicles 620-1 and 620-2. Again, this speed may be detected by the ego vehicle  610 and / or provided to that the ego vehicle 610 (e.g., via RF communications) by the leading vehicles 620 and / or other information sources. According to some embodiments, if there is no vehicle in this tube, the traffic speed may be set as the speed limit applicable to this portion of the road 630. The weight ws may be set to a reasonable value for a given implementation, which may depend on how strongly speed should be factored into driving tube selection.

[0063] The term LateralDistanceToEgofor a given driving tube may refer to a distance from the ego vehicle 610 of the driving tube. According to some embodiments, the absolute value of the zero-order coefficient (e.g., a1, …, an) of the polynomials fitting corresponding to the center line of the driving tube may be used for this term. A larger value may be generally undesirable because, when a driving tube is laterally far from the ego, it can increase the possibility of the ego vehicle 610 cutting in and out of other driving tubes, which can lower the traffic efficiency. Again, the weight wd may be set to a reasonable value for a given implementation, which may depend on how strongly lateral distance should be factored into driving tube selection.

[0064] FIG. 7 is a flow diagram of a method 700 of determining a navigational route for an ego vehicle, according to an embodiment. As noted herein, the method 700 may be performed responsive to a determination that the ego vehicle is unable to detect lane markings on a road on which the ego vehicle is located. Means and / or structure for performing the functionality illustrated in one or more of the blocks shown in FIG. 7 may be performed by hardware and / or software components of a mobile computing system, which may be incorporated into and / or otherwise integrated into or with a vehicle. Example components of a mobile computing system 800 are illustrated in FIG. 8, which is described in more detail below.

[0065] At block 710, the functionality comprises determining, based at least in part on sensor data from one or more sensors of the ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles. As discussed in the above-described embodiments (e.g., with respect to FIG. 4) , a historical trail may comprise a path or route taken by a leading vehicle, and historical trail data may be data indicative of the path or route. According to some embodiments, historical trail data may comprise points or locations of the leading vehicle at different times along the historical trail, which may be detected by the ego vehicle (e.g., using one or more sensors) , detected  by another vehicle or entity (e.g., a roadside unit (RSU) ) , reported by the leading vehicle, or the like, for example.

[0066] Means and / or structure for performing functionality at block 710 may comprise one or more processors 810, a digital signal processor (DSP) 820, a wireless communication interface 830, one or more sensors 840, a memory 860, one or more input devices 870, a GNSS receiver 880, and / or other components of a mobile computing system 800, as illustrated in FIG. 8.

[0067] At block 720, the functionality comprises determining a plurality of candidate driving tubes based at least in part on the historical trail data, wherein each candidate driving tube of the plurality of candidate driving tubes comprises a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle is expected to remain once the ego vehicle enters into the candidate driving tube. As noted in the above-described embodiments (e.g., with respect to FIGS. 3B, 4, and 5) , determining a plurality of candidate driving tubes may include performing one or more of various operations described herein. For example, according to some embodiments, determining a plurality of candidate driving tubes comprises determining a plurality of center lines for the plurality of candidate driving tubes based at least in part on the historical trail data. According to some embodiments, determining the plurality of center lines may comprise generating one or more center lines of the plurality of center lines. Optionally, generating one or more center lines may be responsive to a determination that the one or more historical trails does not satisfy a minimum a spatial diversity threshold. According to some embodiments, determining the plurality of center lines comprises performing a polynomial fitting of the one or more historical trails. Optionally, in such embodiments, a weighted linear least squares (WLLS) method is used to perform the polynomial fitting of the one or more historical trails comprises using. According to some embodiments, determining the plurality of candidate driving tubes based may comprise determining the width of each candidate driving tube based at least in part on a heading of the ego vehicle, a speed of the ego vehicle, or both.

[0068] Means and / or structure for performing functionality at block 720 may comprise a one or more processors 810, a digital signal processor (DSP) 820, a wireless communication interface 830, a memory 860, one or more input devices 870, and / or other components of a mobile computing system 800, as illustrated in FIG. 8.

[0069] At block 730, the functionality comprises outputting an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes. As noted in the above-described embodiments (e.g., with respect to FIGS. 5 and 6) , the analysis of each candidate driving tube may include one or more different functions. For example, according to some embodiments, the analysis of each candidate driving tube of the plurality of candidate driving tubes may comprise, for each candidate driving tube, an analysis of whether there is a collision risk associated with the ego vehicle using the candidate driving tube for navigation, an analysis of an efficiency associated with the ego vehicle using the candidate driving tube for navigation, or a combination thereof. Additionally, or alternatively, the analysis of each candidate driving tube of the plurality of candidate driving tubes may comprise determining a cost function value corresponding to each candidate driving tube of the plurality of candidate driving tubes, wherein the selected driving tube is the candidate driving tube having the lowest corresponding cost function value of the plurality of candidate driving tubes.

[0070] According to some embodiments, outputting the indication of the selected driving tube may be done in any of a variety of ways. For example, according to some embodiments outputting an indication of a selected driving tube for the ego vehicle to take comprises providing an indication of the selected driving tube from one component of a mobile computing system of the ego vehicle to another component of the mobile computing system of the ego vehicle, providing an indication of the selected driving tube from a mobile computing system of the ego vehicle to another system of the ego vehicle, navigating the ego vehicle along the selected driving tube, or any combination thereof.

[0071] Means and / or structure for performing functionality at block 730 may comprise a one or more processors 810, a wireless communication interface 830, a memory 860, and / or other components of a mobile computing system 800, as illustrated in FIG. 8.

[0072] FIG. 8 is a block diagram of an embodiment of a mobile computing system 800, which may be used to perform some or all of the functionality described in the embodiments herein, including the functionality of one or more of the blocks illustrated in FIGS. 3B and 7. The mobile computing system 800 may be incorporated into and / or  otherwise located in or on a vehicle (e.g., an ego vehicle, as described herein) and may include some or all of the components used to implement LCC and / or other ADAS functions for the vehicle. For example, the functionality of one or more of the blocks illustrated in FIGS. 3B and 7 may be executed by processor (s) 810, DSP 820, and sensor (s) 840, and the mobile computing system 800 further may be connected with one or more control systems of the vehicle to navigate the vehicle according to a selected driving tube / navigational route. A person of ordinary skill in the art will appreciate how a mobile computing system such as the mobile computing system 800 may be incorporated into and / or implemented by existing systems of a vehicle.

[0073] It should be noted that FIG. 8 is meant only to provide a generalized illustration of various components, any or all of which may be utilized as appropriate. FIG. 8, therefore, broadly illustrates how individual system elements may be implemented in a relatively separated or relatively more integrated manner. In addition, it can be noted that components illustrated by FIG. 8 can be localized to a single device and / or distributed among various networked devices, which may be disposed at different physical locations on a vehicle.

[0074] The mobile computing system 800 is shown comprising hardware elements that can be electronically / communicatively coupled via a bus 805 (or may otherwise be in communication, as appropriate) . The hardware elements may include processor (s) 810, which can include without limitation one or more general-purpose processors, one or more special-purpose processors (such as a digital signal processor (DSP) , graphical processing unit (GPU) , application specific integrated circuit (ASIC) , field-programmable gate array (FPGA) , and / or the like) , and / or other processing structure or means, which can be configured to perform one or more of the methods described herein, including at least a portion of the method described in FIG. 7. The mobile computing system 800 also can include one or more input devices 870, which can include without limitation a CAN bus (and / or another source of data for various vehicle systems) , vehicle feedback systems, user input (e.g., a touchscreen display, breaking input, steering input, dials, switches, etc. ) , and / or the like. The mobile computing system 800 can also include one or more output devices 815, which can include without limitation a display device (e.g., e.g., dash display, infotainment screen, etc. ) , lights, meters, vehicle automation and / or control systems, and / or the like.

[0075] The mobile computing system 800 may also include a wireless communication interface 830, which may comprise without limitation a modem, a network card, an infrared communication device, a wireless communication device, and / or a chipset (such as a device, an IEEE 802.11 device, an IEEE 802.15.4 device, a Wi-Fi device, a WiMAX device, a WAN device, and / or various cellular devices, etc. ) , and / or the like, which may enable the mobile computing system 800 to communicate with other devices as described in the embodiments above. The wireless communication interface 830 may permit data and signaling to be communicated (e.g., transmitted and received) with transmission / reception points (TRPs) of a network, for example, via access points, various base stations, and / or other access node types, and / or other network components, computer systems, and / or any other electronic devices communicatively coupled with TRPs, as described herein.

[0076] Communication may be carried out via an applicable communication standard for vehicular commute occasion, such as Vehicle-to-everything (V2X) . V2X can include vehicle-to-vehicle (V2V) communication between V2X-capable vehicles, vehicle-to-infrastructure (V2I) communication between the vehicle and infrastructure-based devices (commonly termed roadside units, or roadside units (RSUs) ) , vehicle-to-person (V2P) communication between vehicles and nearby people (pedestrians, cyclists, and other road users) , and the like. Further, V2X can use any of a variety of wireless radio frequency communication technologies. Cellular V2X (CV2X) , for example, is a form of V2X that uses cellular-based communication such as long-term evolution (LTE) , fifth-generation new radio (5G NR) , and / or other cellular technologies in a direct-communication mode as defined by the 3rd Generation Partnership Project (3GPP) . In this way, the mobile computing system 800 may comprise a V2X device or V2X user equipment (UE) .

[0077] The communication by the wireless communication interface 830 can be carried out via one or more wireless communication antenna (s) 832 that send and / or receive wireless signals 834. According to some embodiments, the wireless communication antenna (s) 832 may comprise a plurality of discrete antennas, antenna arrays, or any combination thereof. The antenna (s) 832 may be capable of transmitting and receiving wireless signals using beams (e.g., Tx beams and Rx beams) . Beam formation may be performed using digital and / or analog beam formation techniques, with respective digital and / or analog circuitry. The wireless communication interface 830 may include such circuitry.

[0078] Depending on desired functionality, the wireless communication interface 830 may comprise a separate receiver and transmitter or any combination of transceivers, transmitters, and / or receivers to communicate with base stations and other terrestrial transceivers, such as wireless devices and access points. The mobile computing system 800 may communicate with different data networks that may comprise various network types. For example, a Wireless Wide Area Network (WWAN) may be a Code-division multiple access (CDMA) network, a Time Division Multiple Access (TDMA) network, a Frequency Division Multiple Access (FDMA) network, an Orthogonal Frequency Division Multiple Access (OFDMA) network, a Single-Carrier Frequency Division Multiple Access (SC-FDMA) network, a WiMAX (IEEE 802.16) network, and so on. A CDMA network may implement one or more RATs such as CDMA2000, wideband CDMA (WCDMA) , and so on. CDMA2000 includes IS-95, IS-2000 and / or IS-856 standards. A TDMA network may implement Global System for Mobile Communications (GSM) , Digital Advanced Mobile Phone System (D-AMPS) , or some other RAT. An OFDMA network may employ LTE, LTE Advanced, 5G NR, and so on. 5G NR, LTE, LTE Advanced, GSM, and WCDMA are described in documents from 3GPP. Cdma2000 is described in documents from a consortium named “3rd Generation Partnership Project X3” (3GPP2) . 3GPP and 3GPP2 documents are publicly available. A wireless local area network (WLAN) may also be an IEEE 802.11x network, and a wireless personal area network (WPAN) may be a Bluetooth network, an IEEE 802.15x, or some other type of network. The techniques described herein may also be used for any combination of WWAN, WLAN and / or WPAN.

[0079] The mobile computing system 800 can further include sensor (s) 840. As previously noted, sensors may include any of the vehicle sensors described herein, including sensors 205 illustrated in FIG. 2 and previously described. Additionally or alternatively, sensor (s) 840 may comprise, without limitation, one or more inertial sensors and / or other sensors (e.g., accelerometer (s) , gyroscope (s) , camera (s) , magnetometer (s) , altimeter (s) , microphone (s) , proximity sensor (s) , light sensor (s) , barometer (s) , and the like) , some of which may be used to obtain position-related measurements and / or other information.

[0080] Embodiments of the mobile computing system 800 may also include a Global Navigation Satellite System (GNSS) receiver 880 capable of receiving signals 884 from one or more GNSS satellites using an antenna 882 (which could be the same as antenna  832) . Positioning based on GNSS signal measurement can be utilized to complement and / or incorporate the techniques described herein. The GNSS receiver 880 can extract a position of the mobile computing system 800, using conventional techniques, from GNSS satellites 120 of a GNSS system, such as GPS, Galileo, GLONASS, Quasi-Zenith Satellite System (QZSS) over Japan, Indian Regional Navigational Satellite System (IRNSS) over India, BeiDou Navigation Satellite System (BDS) over China, and / or the like. Moreover, the GNSS receiver 880 can be used with various augmentation systems (e.g., a Satellite Based Augmentation System (SBAS) ) that may be associated with or otherwise enabled for use with one or more global and / or regional navigation satellite systems, such as, e.g., Wide Area Augmentation System (WAAS) , European Geostationary Navigation Overlay Service (EGNOS) , Multi-functional Satellite Augmentation System (MSAS) , and Geo Augmented Navigation system (GAGAN) , and / or the like.

[0081] It can be noted that, although GNSS receiver 880 is illustrated in FIG. 8 as a distinct component, embodiments are not so limited. As used herein, the term “GNSS receiver” may comprise hardware and / or software components configured to obtain GNSS measurements (measurements from GNSS satellites) . In some embodiments, therefore, the GNSS receiver may comprise a measurement engine executed (as software) by one or more processing units, such as processor (s) 810, DSP 820, and / or a processing unit within the wireless communication interface 830 (e.g., in a modem) . A GNSS receiver may optionally also include a positioning engine, which can use GNSS measurements from the measurement engine to determine a position of the GNSS receiver using an EKF, Weighted Least Squares (WLS) , a hatch filter, particle filter, or the like. The positioning engine may also be executed by one or more processing units, such as processor (s) 810 or DSP 820.

[0082] The mobile computing system 800 may further include and / or be in communication with a memory 860. The memory 860 can include, without limitation, local and / or network accessible storage, a disk drive, a drive array, an optical storage device, a solid-state storage device, such as a random access memory (RAM) , and / or a read-only memory (ROM) , which can be programmable, flash-updateable, and / or the like. Such storage devices may be configured to implement any appropriate data stores, including without limitation, various file systems, database structures, and / or the like.

[0083] The memory 860 of the mobile computing system 800 also can comprise software elements (not shown in FIG. 8) , including an operating system, device drivers, executable libraries, and / or other code, such as one or more application programs, which may comprise computer programs provided by various embodiments, and / or may be designed to implement methods, and / or configure systems, provided by other embodiments, as described herein. Merely by way of example, one or more procedures described with respect to the method (s) discussed above may be implemented as code and / or instructions in memory 860 that are executable by the mobile computing system 800 (and / or processor (s) 810 or DSP 820 within mobile computing system 800) . In an aspect, then such code and / or instructions can be used to configure and / or adapt a general-purpose computer (or other device) to perform one or more operations in accordance with the described methods.

[0084] It will be apparent to those skilled in the art that substantial variations may be made in accordance with specific requirements. For example, customized hardware might also be used and / or particular elements might be implemented in hardware, software (including portable software, such as applets, etc. ) , or both. Further, connection to other computing devices such as network input / output devices may be employed.

[0085] With reference to the appended figures, components that can include memory can include non-transitory machine-readable media. The term “machine-readable medium” and “computer-readable medium” as used herein, refer to any storage medium that participates in providing data that causes a machine to operate in a specific fashion. In embodiments provided hereinabove, various machine-readable media might be involved in providing instructions / code to processing units and / or other device (s) for execution. Additionally or alternatively, the machine-readable media might be used to store and / or carry such instructions / code. In many implementations, a computer-readable medium is a physical and / or tangible storage medium. Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. Common forms of computer-readable media include, for example, magnetic and / or optical media, any other physical medium with patterns of holes, a RAM, a programmable ROM (PROM) , erasable PROM (EPROM) , a FLASH-EPROM, any other memory chip or cartridge, or any other medium from which a computer can read instructions and / or code.

[0086] The methods, systems, and devices discussed herein are examples. Various embodiments may omit, substitute, or add various procedures or components as appropriate. For instance, features described with respect to certain embodiments may be combined in various other embodiments. Different aspects and elements of the embodiments may be combined in a similar manner. The various components of the figures provided herein can be embodied in hardware and / or software. Also, technology evolves and, thus many of the elements are examples that do not limit the scope of the disclosure to those specific examples.

[0087] It has proven convenient at times, principally for reasons of common usage, to refer to such signals as bits, information, values, elements, symbols, characters, variables, terms, numbers, numerals, or the like. It should be understood, however, that all of these or similar terms are to be associated with appropriate physical quantities and are merely convenient labels. Unless specifically stated otherwise, as is apparent from the discussion above, it is appreciated that throughout this Specification discussion utilizing terms such as “processing, ” “computing, ” “calculating, ” “determining, ” “ascertaining, ” “identifying, ” “associating, ” “measuring, ” “performing, ” or the like refer to actions or processes of a specific apparatus, such as a special purpose computer or a similar special purpose electronic computing device. In the context of this Specification, therefore, a special purpose computer or a similar special purpose electronic computing device is capable of manipulating or transforming signals, typically represented as physical electronic, electrical, or magnetic quantities within memories, registers, or other information storage devices, transmission devices, or display devices of the special purpose computer or similar special purpose electronic computing device.

[0088] Terms, “and” and “or” as used herein, may include a variety of meanings that also is expected to depend, at least in part, upon the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B, or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B, or C, here used in the exclusive sense. In addition, the term “one or more” as used herein may be used to describe any feature, structure, or characteristic in the singular or may be used to describe some combination of features, structures, or characteristics. However, it should be noted that this is merely an illustrative example and claimed subject matter is not limited to this example. Furthermore, the term “at least one of” if used to associate a list, such as A, B,  or C, can be interpreted to mean any combination of A, B, and / or C, such as A, AB, AA, AAB, AABBCCC, etc.

[0089] Having described several embodiments, various modifications, alternative constructions, and equivalents may be used without departing from the scope of the disclosure. For example, the above elements may merely be a component of a larger system, wherein other rules may take precedence over or otherwise modify the application of the various embodiments. Also, a number of steps may be undertaken before, during, or after the above elements are considered. Accordingly, the above description does not limit the scope of the disclosure.

[0090] In view of this description embodiments may include different combinations of features. Implementation examples are described in the following numbered clauses:

[0091] Clause 1: A method of determining a navigational route for an ego vehicle, the method comprising: determining, based at least in part on sensor data from one or more sensors of the ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles; determining a plurality of candidate driving tubes based at least in part on the historical trail data, wherein each candidate driving tube of the plurality of candidate driving tubes comprises a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle is expected to remain once the ego vehicle enters into the candidate driving tube; and outputting an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes.

[0092] Clause 2: The method of clause 1, wherein determining a plurality of candidate driving tubes comprises determining a plurality of center lines for the plurality of candidate driving tubes based at least in part on the historical trail data.

[0093] Clause 3: The method of clause 2, wherein determining the plurality of center lines comprises generating one or more center lines of the plurality of center lines.

[0094] Clause 4: The method of clause 3, wherein generating one or more center lines is responsive to a determination that the one or more historical trails does not satisfy a minimum a spatial diversity threshold.

[0095] Clause 5: The method of any one of clauses 2-4, wherein determining the plurality of center lines comprises performing a polynomial fitting of the one or more historical trails.

[0096] Clause 6: The method of clause 5, wherein a weighted linear least squares (WLLS) operation is used to perform the polynomial fitting of the one or more historical trails.

[0097] Clause 7: The method of any one of clauses 1-6, wherein the analysis of each candidate driving tube of the plurality of candidate driving tubes comprises, for each candidate driving tube: an analysis of whether there is a collision risk associated with the ego vehicle using the candidate driving tube for navigation, an analysis of an efficiency associated with the ego vehicle using the candidate driving tube for navigation, or a combination thereof.

[0098] Clause 8: The method of any one of clauses 1-7, wherein the analysis of each candidate driving tube of the plurality of candidate driving tubes comprises determining a cost function value corresponding to each candidate driving tube of the plurality of candidate driving tubes, wherein the selected driving tube is the candidate driving tube having the lowest corresponding cost function value of the plurality of candidate driving tubes.

[0099] Clause 9: The method of any one of clauses 1-8, wherein determining the plurality of candidate driving tubes comprises determining the width of each candidate driving tube based at least in part on a heading of the ego vehicle, a speed of the ego vehicle, or both.

[0100] Clause 10: The method of any one of clauses 1-9, wherein the method is performed responsive to a determination that the ego vehicle is unable to detect lane markings on a road on which the ego vehicle is located.

[0101] Clause 11: The method of any one of clauses 1-10, wherein outputting an indication of a selected driving tube for the ego vehicle to take comprises: providing an indication of the selected driving tube from one component of a mobile computing system of the ego vehicle to another component of the mobile computing system of the ego vehicle, providing an indication of the selected driving tube from a mobile computing  system of the ego vehicle to another system of the ego vehicle, navigating the ego vehicle along the selected driving tube, or any combination thereof.

[0102] Clause 12: A device for determining a navigational route for an ego vehicle, the device comprising: one or more transceivers; one or more memories; and one or more processors communicatively coupled with the one or more transceivers and the one or more memories, the one or more processors configured to: determine, based at least in part on sensor data from one or more sensors of the ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles; determine a plurality of candidate driving tubes based at least in part on the historical trail data, wherein each candidate driving tube of the plurality of candidate driving tubes comprises a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle is expected to remain once the ego vehicle enters into the candidate driving tube; and output an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes.

[0103] Clause 13: The device of clause 12, wherein, to determine a plurality of candidate driving tubes, the one or more processors are configured to determine a plurality of center lines for the plurality of candidate driving tubes based at least in part on the historical trail data.

[0104] Clause 14: The device of either of clause 13, wherein, to determine the plurality of center lines, the one or more processors are configured to generate one or more center lines of the plurality of center lines.

[0105] Clause 15: The device of clause 14, wherein the one or more processors are configured to generate the one or more center lines responsive to a determination that the one or more historical trails does not satisfy a minimum a spatial diversity threshold.

[0106] Clause 16: The device of any one of clauses 13-15, wherein, to determine the plurality of center lines, the one or more processors are configured to perform a polynomial fitting of the one or more historical trails.

[0107] Clause 17: The device of clause 16, wherein a weighted linear least squares (WLLS) operation is used to perform the polynomial fitting of the one or more historical trails comprises using.

[0108] Clause 18: The device of any one of clauses 12-17, wherein the one or more processors are configured to perform the analysis of each candidate driving tube of the plurality of candidate driving tubes, wherein to perform the analysis, the one or more processors are configured to perform, for each candidate driving tube: an analysis of whether there is a collision risk associated with the ego vehicle using the candidate driving tube for navigation, an analysis of an efficiency associated with the ego vehicle using the candidate driving tube for navigation, or a combination thereof.

[0109] Clause 19: The device of any one of clauses 12-18, wherein, to determine the plurality of candidate driving tubes, the one or more processors are configured to determine the width of each candidate driving tube based at least in part on a heading of the ego vehicle, a speed of the ego vehicle, or both.

[0110] Clause 20: An apparatus comprising: means for determining, based at least in part on sensor data from one or more sensors of an ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles; means for determining a plurality of candidate driving tubes based at least in part on the historical trail data, wherein each candidate driving tube of the plurality of candidate driving tubes comprises a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle is expected to remain once the ego vehicle enters into the candidate driving tube; and means for outputting an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes.

[0111] Clause 21: An apparatus having means for performing the method of any one of clauses 1-11.

[0112] Clause 22: A non-transitory computer-readable medium storing instructions, the instructions comprising code for performing the method of any one of clauses 1-11.

Claims

1.A method of determining a navigational route for an ego vehicle, the method comprising:determining, based at least in part on sensor data from one or more sensors of the ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles;determining a plurality of candidate driving tubes based at least in part on the historical trail data, wherein each candidate driving tube of the plurality of candidate driving tubes comprises a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle is expected to remain once the ego vehicle enters into the candidate driving tube; andoutputting an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes.2.The method of claim 1, wherein determining a plurality of candidate driving tubes comprises determining a plurality of center lines for the plurality of candidate driving tubes based at least in part on the historical trail data.3.The method of claim 2, wherein determining the plurality of center lines comprises generating one or more center lines of the plurality of center lines.4.The method of claim 3, wherein generating one or more center lines is responsive to a determination that the one or more historical trails does not satisfy a minimum a spatial diversity threshold.5.The method of claim 2, wherein determining the plurality of center lines comprises performing a polynomial fitting of the one or more historical trails.6.The method of claim 5, wherein a weighted linear least squares (WLLS) operation is used to perform the polynomial fitting of the one or more historical trails.7.The method of claim 1, wherein the analysis of each candidate driving tube of the plurality of candidate driving tubes comprises, for each candidate driving tube:an analysis of whether there is a collision risk associated with the ego vehicle using the candidate driving tube for navigation,an analysis of an efficiency associated with the ego vehicle using the candidate driving tube for navigation, ora combination thereof.8.The method of claim 1, wherein the analysis of each candidate driving tube of the plurality of candidate driving tubes comprises determining a cost function value corresponding to each candidate driving tube of the plurality of candidate driving tubes, wherein the selected driving tube is the candidate driving tube having the lowest corresponding cost function value of the plurality of candidate driving tubes.9.The method of claim 1, wherein determining the plurality of candidate driving tubes comprises determining the width of each candidate driving tube based at least in part on a heading of the ego vehicle, a speed of the ego vehicle, or both.10.The method of claim 1, wherein the method is performed responsive to a determination that the ego vehicle is unable to detect lane markings on a road on which the ego vehicle is located.11.The method of claim 1, wherein outputting an indication of a selected driving tube for the ego vehicle to take comprises:providing an indication of the selected driving tube from one component of a mobile computing system of the ego vehicle to another component of the mobile computing system of the ego vehicle,providing an indication of the selected driving tube from a mobile computing system of the ego vehicle to another system of the ego vehicle,navigating the ego vehicle along the selected driving tube, orany combination thereof.12.A device for determining a navigational route for an ego vehicle, the device comprising:one or more transceivers;one or more memories; andone or more processors communicatively coupled with the one or more transceivers and the one or more memories, the one or more processors configured to:determine, based at least in part on sensor data from one or more sensors of the ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles;determine a plurality of candidate driving tubes based at least in part on the historical trail data, wherein each candidate driving tube of the plurality of candidate driving tubes comprises a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle is expected to remain once the ego vehicle enters into the candidate driving tube; andoutput an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes.13.The device of claim 12, wherein, to determine a plurality of candidate driving tubes, the one or more processors are configured to determine a plurality of center lines for the plurality of candidate driving tubes based at least in part on the historical trail data.14.The device of claim 13, wherein, to determine the plurality of center lines, the one or more processors are configured to generate one or more center lines of the plurality of center lines.15.The device of claim 14, wherein the one or more processors are configured to generate the one or more center lines responsive to a determination that the one or more historical trails does not satisfy a minimum a spatial diversity threshold.16.The device of claim 13, wherein, to determine the plurality of center lines, the one or more processors are configured to perform a polynomial fitting of the one or more historical trails.17.The device of claim 16, wherein a weighted linear least squares (WLLS) operation is used to perform the polynomial fitting of the one or more historical trails comprises using.18.The device of claim 12, wherein the one or more processors are configured to perform the analysis of each candidate driving tube of the plurality of candidate driving tubes, wherein to perform the analysis, the one or more processors are configured to perform, for each candidate driving tube:an analysis of whether there is a collision risk associated with the ego vehicle using the candidate driving tube for navigation,an analysis of an efficiency associated with the ego vehicle using the candidate driving tube for navigation, ora combination thereof.19.The device of claim 12, wherein, to determine the plurality of candidate driving tubes, the one or more processors are configured to determine the width of each candidate driving tube based at least in part on a heading of the ego vehicle, a speed of the ego vehicle, or both.20.An apparatus comprising:means for determining, based at least in part on sensor data from one or more sensors of an ego vehicle, historical trail data indicative of one or more historical trails taken by one or more leading vehicles;means for determining a plurality of candidate driving tubes based at least in part on the historical trail data, wherein each candidate driving tube of the plurality of candidate driving tubes comprises a respective candidate navigational route for the ego vehicle having boundaries defining a width of the candidate driving tube, within which the ego vehicle is expected to remain once the ego vehicle enters into the candidate driving tube; andmeans for outputting an indication of a selected driving tube for the ego vehicle to take, the selected driving tube being selected from the plurality of candidate driving tubes based on an analysis of each candidate driving tube of the plurality of candidate driving tubes.

Images