Patent ID: 12222726

DETAILED DESCRIPTION

Those skilled in the art will appreciate that the steps, services and functions explained herein may be implemented using individual hardware circuitry, using software functioning in conjunction with a programmed microprocessor or general purpose computer, using one or more Application Specific Integrated Circuits (ASICs) and/or using one or more Digital Signal Processors (DSPs). It will also be appreciated that when the present invention is described in terms of a method, it may also be embodied in one or more processors and one or more memories coupled to the one or more processors, wherein the one or more memories store one or more programs that perform the steps, services and functions disclosed herein when executed by the one or more processors.

FIG.1is a schematic flow chart representation of a method100performed by an in-vehicle computing system for automated development of a path planning module of a vehicle. The vehicle is equipped with an Automated Driving System (ADS), which in the present context comprises all of the different levels of automation as for example defined by the SAE J3016 levels (0-5) of driving automation, and in particular level 4 and 5. In other words, the term ADS encompasses both Advanced Driver-Assistance System (ADAS) and Autonomous Driving (AD).

More specifically, the method100relates to open-loop evaluation of a path planning module of a vehicle, and subsequent updating thereof. The term “open loop” evaluation may also be referred to as “shadow mode” or “sandbox mode”, and may accordingly be understood as evaluation of the output of the path planning module without actuation of the generated candidate paths.

The method100comprises obtaining101a candidate path from the path planning module. The term “path planning module” may also be referred to as a “Module Under Test” (MUT), or path planning development-module, meaning that is a “new” (under development) software and/or hardware of a path planning feature for automotive applications. In other words, the path planning module may in the present context be understood as software and/or hardware configured to generate a candidate path based on perception data (e.g. raw sensor data or processed sensor data), where the path planning module is currently “under development”, and not yet “in production” (e.g. not verified/validated). The vehicle or more precisely, the ADS of the vehicle, may naturally be equipped with a “production path planner”, i.e. a path planning module that is part of the production platform/system that is configured to generate paths that are to be executed by the ADS of the vehicle. The term obtaining is herein to be interpreted broadly and encompasses receiving, retrieving, collecting, acquiring, and so forth.

Accordingly, the path planning module is configured to generate the candidate path for execution the vehicle based on a path planning model (e.g. a machine learning algorithm, artificial neural network, or the like) and data indicative of the surrounding environment of the vehicle. Thus, the data indicative of the surrounding environment (e.g. perception data) serves as input to the path planning model, and the output of the path planning model is one or more candidate paths. The data indicative of the surrounding environment of the vehicle may for example be perception output (e.g. fused sensor data) generated by a perception system of the vehicle. However, in some embodiments, the data indicative of the surrounding environment of the vehicle may be sensor data obtained directly from one or more vehicle-mounted sensors. Furthermore, the path planning model may also utilize the actuation capabilities of the vehicle as input. The term “actuation capability” as used herein may include one or more of a braking capacity of the vehicle, an acceleration capacity of the vehicle, a steering capacity of the vehicle, and so forth as readily appreciated by the skilled person in the art.

Further, the method100comprises obtaining102a reference framework for evaluating the candidate path. The reference framework is configured to indicate one or more risk values associated with the candidate path when the candidate path is applied in the reference framework. The reference framework may be understood as a framework where the evaluation of the candidate path is performed in the open-loop testing. In some embodiments, the reference framework is in the form of a risk map that is formed based on an actuation capability of the vehicle and a location of free-space areas in the surrounding environment. The risk map is discussed in further detail in reference toFIGS.2-4below. However, in some embodiments, the reference framework is in the form of a baseline worldview generated from a post-processing of the output of the production system's perception system. The post-processing and the baseline worldview are discussed in further detail in reference toFIGS.5,6a, and6bbelow.

The method100further comprises evaluating103the obtained candidate path by applying the candidate path in the reference framework in order to determine110,114a cost function based on the one or more risk values. The cost function is accordingly indicative of a performance of the path planning module within the reference framework.

Further, the method100comprises updating104one or more parameters of the path planning model by means of an optimization algorithm (e.g. gradient-based optimizers or derivative-free optimizers) configured to optimize the determined cost function. In the present disclosure, the terms cost function, loss function, and error function are used interchangeably. The purpose of the cost function as defined herein, is accordingly to provide a means to update the path planning model so to maximize desirable output and to minimize unwanted output from the path planning model. In more detail, the cost function is preferably set in relation to one or more predefined goals (i.e. predefined target values). For example, a defined risk value threshold may be used to form a “goal” for the cost function. In other words, a purpose of the cost function is to minimize the one or more risk values associated with the candidate path until a certain point. This is in order to avoid potential situations where the path planning is optimized to the level of “realizing” that the “safest” option is to stand still. However, one may also impose some fixed constraints (e.g. vehicle must move from A to B) in order to avoid such situations.

An equivalent solution would be to determine110,114a corresponding “reward function” in the evaluation103step and update104the one or more model parameters of the path planning model by means of an optimization algorithm configured to maximize the determined “reward function”.

The development, testing, and validation of path planning algorithms for ADSs are generally thought of as an expensive and time-consuming endeavour as the testing needs to be safe and it requires a huge effort for validation. Both of these stages (development and testing) are costly and prolongs the lead-time of delivering new path planning solutions to the market. However, it was realized by the present inventors that many of the costly steps could potentially be relieved by building on top of already released production vehicles because parts of the development, testing, and validation can be done in the production vehicles without the need for dedicated vehicles with testing personnel. Accordingly, the method and apparatus as proposed herein provides a fully-automated solution for performing open-loop development, testing, and/or validation of new path-planning modules in a sufficiently safe manner.

In other words, the present invention provides for a learning platform for autonomous vehicles where the production system and sensors of the production ADS are utilized to carry out federated learning of next versions of path planning features for ADSs. Thereby providing advantages in terms of cost and time for development, testing, and/or validation of path planning features for autonomous vehicles.

The open-loop evaluation as proposed herein may advantageously be allowed to continue iteratively as long as it appears that the open-loop learning continues to improve the path planning module at a sufficient rate. For example, one could run the open-loop evaluation until the performance of the path planning module is such that the majority (over a set period of time) of the candidate paths would be allowed to be executed with respect to their estimated risk in the reference framework. Additionally, or alternatively, the open-loop evaluation could be used until the estimated risk of the candidate paths in the reference framework (over a set period of time) is at least on par with the path planner of the production platform (or at least within some tolerance margin).

Accordingly, some of the technical advantages of the invention as disclosed herein are:Cost-effective and time-efficient development, testing, and/or validation of new path planning features.It is possible to capitalise on the available production resources in the launched cars to further develop, test, and/or validate the path planning system.

Further, in the scheme of federated learning, the updated104parameters of each of a plurality of vehicles may advantageously be consolidated in a central or cloud unit, whereby a “global update” may be pushed to the entire fleet of vehicles. Therefore, in some embodiments, the method100further comprises transmitting105the one or more updated104parameters of the path planning model to a remote entity (e.g. a back-office or fleet management system). Moreover, the method100may comprise receiving106a set of globally updated parameters of the path planning model of the path planning module from the remote entity. The set of globally updated parameters are accordingly based on information obtained from a plurality of vehicles comprising a corresponding path planning module. Then, the method100may comprise updating107the path planning model of the path planning module based on the received set of globally updated parameters.

Still further, in some embodiments, the step of obtaining102a reference framework comprises obtaining108a risk map of a surrounding environment of the vehicle. The risk map is formed based on an actuation capability of the vehicle and a location of free-space areas in the surrounding environment. More specifically, the actuation capability includes an uncertainty estimation for the actuation capability and the location of free-space areas comprises an uncertainty estimation for the estimated location of free-space areas.

The risk map comprises a risk parameter for each of a plurality of area segments comprised in the surrounding environment of the vehicle. Moreover, the risk map further has a temporal component indicative of a time evolution of the risk parameters of the area segments based on a predicted temporal evolution of the free-space areas for at least a duration of time defined by a predicted duration of the candidate path. Accordingly, the risk map then forms the reference framework that the obtained101candidate path is to be evaluated103against. The temporal component may for example be dependent on predicted trajectories (for at least the duration of time defined by the predicted duration of the candidate path) of dynamics objects, such as external vehicles, in the surrounding environment of the ego-vehicle.

The risk map may for example be retrieved or received from a risk map engine configured to generate the risk map based on a risk map model given one or more real-time variables (originating from one or more on-board sensors) such as e.g. current speed, vehicle properties (vehicle dimensions, vehicle weight, etc.), road surface properties, and so forth, as readily understood by the skilled person in the art. The uncertainty estimates may be derived from predefined statistical models associated with each actuation parameters, where the actuation capability is given by the mean or mode value and the uncertainty estimate is given by e.g. one or two standard deviations above or below the mean.

The free-space areas may for example be derived from sensor data of one or more vehicle-mounted sensors configured to monitor the surrounding environment of the vehicle. Nevertheless, the sensor data may also originate from other sensors in the vicinity of the vehicle, e.g. sensors mounted on other vehicles or on infrastructure elements and obtained via a V2V or V2X communication network.

Free-space areas may in the present context be understood as areas in the surrounding environment of the ego-vehicle absent of objects (e.g. other vehicles, pedestrians, barriers, animals, bicycles, static objects, etc.). Thus, the obtained location of free-space areas may be understood as estimates of areas absent of external objects (static and dynamic objects) as well as an estimate of the uncertainty of this determination, i.e. the likelihood of the determined location of the free-space area actually being true.

Moreover, in some embodiments, the location of free-space areas comprises a position of external objects located in the surrounding environment of the ego-vehicle. The estimated position of the external objects may include uncertainties of the position of the external objects, estimated trajectories of any dynamic objects of the external objects and uncertainties of the estimated trajectories of the dynamic objects. However, in some embodiments the location of free-space areas is determined by a dedicated module of the vehicle, where the dedicated module is configured to obtain sensor data indicative of the surrounding environment of the vehicle, and to derive the location of the free-space areas with respect to the vehicle based on the sensor data. Thus, there does not have to be an intermediate step or layer where objects are detected before the location of the free-space areas is obtained, i.e. the “free-space area” may be obtained directly. For example, a signal emitted by a Lidar may propagate through space for a certain distance before it is reflected from some surface, then this area between the Lidar and the surface may be defined as a “free-space area” without any operation or step to define the surface that the signal was reflected from.

FIGS.2and3are two schematic top view illustrations of a risk map40with some example components41-46″ contributing to the risk map40, at two consecutive time steps, in accordance with an embodiment of the present invention. Furthermore, the planned path for execution47a-bof the ego-vehicle is indicated in the map40. In more detail, dashed line arrows indicate the “candidate path”47afrom the preceding time instance/sample and the current candidate path47bis indicated by the arrow in front of the vehicle inFIG.3.

Further, the risk map40comprises information indicative of an estimated braking capacity43of the vehicle41including uncertainty estimation43′,43″ of the same. Further, the risk map40comprises a geographical position41of the ego-vehicle in the map, the uncertainty estimation42of the geographical position41, a position of external objects44,46, uncertainties of the position of the external objects44′,44″,46′, trajectories45of dynamic objects44and uncertainties45′45″ of the trajectories45. The estimated uncertainties may for example be computed based on models (predefined or self-learning/machine-learning) defining a tolerance or error-margin in the measurements provided from the sensors of the vehicle (e.g. cameras, radar, LiDAR, ultrasonic sensors, etc.). Thereby, the formed risk map40also accounts for uncertainties inherent in such measurements of the ego-vehicle's worldview caused by for example, sensor manufacturing tolerances, noise, and so forth. Accordingly, the whole risk estimation is rendered more accurate and reliable, more accurately reflecting the actual risk exposure of the ADS of the vehicle. However, in some embodiments, the estimated uncertainties are inherently provided by the production platform's perception system and subsequently incorporated in the generated risk map40as readily understood by the skilled artisan.

FIG.4is a schematic top view illustration of a risk map at a subsequent time step/sample relative to the risk map depicted inFIG.3, with area segments51indicated in the form of a grid50in accordance with an embodiment of the present invention. As described in the foregoing, in order to determine the aggregated risk value of a candidate path47, one may sum and/or form an average of the risk values associated with the area segments that the planned path47intersects52.

Moreover, the bottom left corner ofFIG.4shows a schematic top view of a risk map and serves to illustrate how the total risk value may be determined in accordance with some embodiments of the present invention. In more detail, there is depicted a candidate path47extending through the risk map40, which further has an overlaid grid framework50in order to exemplify how the area segments may be formed. As described in the foregoing, the risk map40has a plurality of area segments51, each associated with a risk parameter indicative of at least one of a probability of an accident event if the path were to intersect an associated area segment and a probability of violating a predefined safety threshold. The “value” of the risk parameter is indicated in each box51by the pattern in the boxes51. Accordingly, the risk map40depicts certain “high risk” area segments44, “low risk” area segments43, and values in between.

The risk of a candidate path47(i.e. the risk value associated with the candidate path) may be evaluated through one or more ways using the risk map40. For example one may use the aggregated risk for the candidate path47when executed across the risk map40(i.e. integral of the path on the risk map). Accordingly, one may aggregate the risk values of the area segments51that the candidate path47intersects52, in order to derive a compounded risk or average risk of the candidate path47. The aggregated risk value may in some embodiments subsequently be used to define the cost function.

Reverting back toFIG.1, the step of evaluating103the obtained candidate path may comprise determining109an aggregated risk value for the candidate path based on the risk parameters of a set of area segments intersected by the candidate path. The aggregated risk value accordingly defines the one or more risk values. Further, the step of evaluating103the obtained candidate path may comprise determining110the cost function based on the determined109aggregated risk value.

As mentioned, in some embodiments, the reference framework is in the form of a baseline world generated from a post-processing of the output of the production system's perception system. Thus, in some embodiments, the step of obtaining102a reference framework comprises storing111, during a time period, a set of perception data obtained from a perception system of the vehicle. The perception system being configured to generate the set of perception data based on sensor data obtained from one or more vehicle-mounted sensors during the time period. A perception system (of the production platform/system) is in the present context to be understood as a system responsible for acquiring raw sensor data from on-board sensors such as cameras, LIDARs and RADARs, ultrasonic sensors, and converting this raw data into scene understanding.

The set of perception data may for example be stored or saved in a data buffer (not shown), where this set of perception data may be understood as data indicative of the vehicle's surroundings. This may for example be detected objects or objects' states and/or vehicle localization, and/or statistical and physical model predictions of future states, derived continuously and/or intermittently from a first time point T1to a second time point T2. The time period—and correspondingly the length of the optional data buffer—may be of any arbitrary size deemed feasible, e.g. in consideration of data capacity restraints and/or characteristics of the ADS, and may for instance range from under a second up to several minutes, or more preferred, from a few seconds up to less than a minute.

Further, the step of obtaining102a reference framework comprises forming112, by post-processing the set of perception data, a baseline worldview indicative of a scenario in the surrounding environment of the vehicle during the time period. Accordingly, this baseline worldview forms the reference framework. A “scenario” may be one or more momentary scenes at one or more points in time during the time period including the positions of detected objects, object classes/types, positions of lane markers, extensions of lane markers, free-space detections, and/or trajectories of detected objects in the surrounding environment of the vehicle. It should be noted that this list merely serves to exemplify the parameters included in a “scenario” and may include other parameters detectable by the vehicle's perception module as readily understood by the skilled person in the art.

The post-processing step112will now be further exemplified in reference toFIG.5, which depicts a series (a)-(d) of schematic top-view illustrations of a vehicle1moving a road portion towards an external object24. Each illustration is associated with a point in time within the time period21ranging from a first moment in time T1to a second moment in time T2.

In the first illustration (a) the vehicle1(may also be referred to as ego-vehicle1) is moving towards an external object, here in the form of a truck24, that is traveling in the same direction on an adjacent lane on the road portion. However, due to the distance to the truck24, the vehicle's perception system/module may not be able to determine, with a sufficiently high level of accuracy, the position of the external object, and to classify it as a truck. This is indicated by the box22aenclosing the truck24, which serves to schematically indicate the “uncertainties” of the detection and classification.

At a subsequent moment in time, i.e. illustration (b) ofFIG.5, the vehicle1is closer to the external object, and the uncertainties regarding the external object's24position and class/type are reduced, as indicated by the reduced size of the box22bas compared to the first box22a.

At yet another subsequent moment in time, i.e. illustration (c) ofFIG.5, the vehicle's1perception system/module is able to accurately determine the external object's2position and classify it as a truck2. More specifically, the ego-vehicle1is now sufficiently close to the truck2to be able to classify it and estimate the truck's position on the road with a higher level of accuracy as compared to when the ego-vehicle1was located further away from the truck.

Then, by means of a suitable filtering technique and based on the temporal development of the “scenario”, one is able to establish a “baseline worldview” at an intermediate point23in time between T1and T2, as indicated in the bottom illustration inFIG.5, i.e. in illustration (d) ofFIG.5. In more detail, the filtering may for example be based on the temporal development of the trajectories, positions, etc. in combination with predefined models (e.g. motion models) of the vehicle1and external objects2. This established baseline worldview may subsequently used as a “ground truth” for training and/or validation of the output obtained from the path planning module.

In accordance with some embodiments, the step of forming the baseline worldview comprises determining, based on post-processing a portion of the set of perception data ranging back from the second time point to an intermediate time point between the first time point T1and second time point T2the baseline worldview indicative of the surrounding environment of the vehicle. The baseline worldview accordingly being conditional on the portion of the set of perception data. Moreover, in accordance with some embodiments, the post-processing of the portion of the set of perception data comprises running the portion of the set of perception data through a backwards filter. Here, the backwards filter is configured to align a set of perceptive parameters of the set of perception data at the intermediate time point based on a development of the state(s) of the set of perceptive parameters from the intermediate time point to the second time point T2. A perceptive parameter may in the present context be an object detection estimation, an object classification estimation, an object state estimation, a road reference feature estimation, a free-space estimation, a road friction estimation, an object trajectory estimation, and/or a drivable-area estimation.

In other words, with the increased knowledge of vehicle1surroundings as time passes from the intermediate time point23to the second time point T2and by analyzing data in reverse temporal direction, one may be able to determine, with a higher level of accuracy, the “state” (i.e. classes, positions, trajectories, etc.) of the objects in the vehicle's1surroundings at the intermediate time point, than it was able to do at “run-time”. Thus, the post-processing may be understood as a type of automated “ex-post-facto” analysis of data indicative of the surrounding environment of the vehicle. In more detail, the post processing may for example comprise running the set of perception data through a backwards filter configured to align e.g. the objects current and predicted future states with what happened in the future—i.e. from the intermediate time point to the second time point T2. The post-processing may include further processing steps than running it through a backwards filter. More specifically, the post-processing may include fusion of data from various sensors, as well as applying backward and forward filtering on the fused information. Suitable filters for this purpose may for example be Particle filters or different types of Kalman filters (e.g. extended Kalman filters).

Thus, by performing the above-described post-processing112method for series of “intermediate time points”, one can establish a more reliable description of the temporal evolution of the “state” of the objects in the ego-vehicle's surroundings than is possible to do at “run-time”. This post-processed “description” of the surrounding environment accordingly constitutes the baseline worldview, which can then be used to evaluate the obtained101candidate path. Preferably, the predicted duration of the candidate path is comprised within the “duration” of the formed baseline worldview. For example, if the generated baseline worldview is indicative of a scenario in the surrounding environment of the vehicle during a time period extending from T1to T5, the duration of the candidate path may be from T2to T4.

Accordingly, the step of evaluating103the obtained101candidate path may comprise comparing113the candidate path with the baseline worldview in order to obtain the one or more risk values. Then, a cost function can be determined114based on the obtained one or more risk values, where each risk value is indicative of a temporal evolution of a collision threat measure for the candidate path during at least a portion of the time period.

A pair of illustrative examples of a candidate path evaluation in view of a baseline worldview are provided inFIGS.6a-6b. In these example embodiments (FIGS.6a-6b), Post Encroachment Time (PET) is used to define the collision threat measure. Post Encroachment Time (PET) may be understood as the time difference between a vehicle leaving the area of encroachment and a conflicting vehicle entering the same area. In other words, PET at any time point may be construed as the time gap (difference) between two objects occupying any overlap in space. Accordingly, in the present case PET is the time between the moment that the ego-vehicle leaves the path of an external vehicle and the moment that the external vehicle reaches the path of the ego-vehicle, or vice versa.

Thus,FIGS.6aand6bare schematic top-view illustrations of an ADS-equipped vehicle1comprising an apparatus for automated development of a path planning module in accordance with an embodiment of the invention. More specifically,FIGS.6aand6bdepict two different situations where PET is used to perform a pass/fail evaluation of a plurality of candidate paths61,62generated by the path planning module of the vehicle1.

However, PET may be used as a factor in order to determine a cost function using PET so to maximize the PET up until a set level as it may not be desirable to maximize PET infinitely. Thus, the cost may be defined as max (−PET, −PETmax, value) or −min (PET, PETmax, value).

When utilizing the baseline worldview as the reference framework, a defined performance value (i.e. the collision threat measure) is required to perform the evaluation. This performance value is accordingly calculated after the situation has been post-processed in accordance with the methodology described in the foregoing. It should be noted that PET is only one example of an applicable performance value/collision threat measure, and that other metrics may be utilized such as e.g. Brake-Threat Number (BTN) and Steer-Threat Number (STN) as readily understood by the skilled artisan.

In the first situation, depicted inFIG.6a, the ego-vehicle's1path planning module1(i.e. the Module-Under-Test) generates a number of candidate paths61,62based on its path planning model and data indicative of the surrounding environment of the vehicle. These candidate paths may then be stored (in e.g. a data buffer of a suitable length) similarly as the perception data generated by the production platform's perception system that is to be used for the post-processing and generation of the baseline worldview. Once the baseline worldview has been formed over a suitable time period, the candidate paths61,62are evaluated based on a PET threshold T. As indicated inFIG.6adepicting the “first” situation, one of the candidate paths61fails the evaluation, while the remaining paths62pass the evaluation.

In the “second” situation, depicted inFIG.6b, the external vehicle2atraveling in the neighbouring lane is traveling at a higher speed as compared to the first situation depicted inFIG.6a. Thus, the candidate paths that involve a change of lanes to the left-most lane are affected, which is indicated by a higher number of candidate paths61that failed the evaluation. It should be noted that the depicted examples inFIGS.6aand6bare simplified examples of a binary evaluation (pass/fail), and that further parameters may be used in the evaluation to determine the one or more risk values for each candidate path.

Moreover, it should be noted that in neither of the two evaluation processes (risk map/post-processing) is the candidate path actually executed by the ADS of the vehicle. Moreover, the cost function for the open loop learning may be constructed based on any combination of the results from these two evaluation processes. Thus, in some embodiments, the reference framework is in fact two reference frameworks, one defined by the risk map and one defined by the baseline worldview generated by the post-processing process.

Executable instructions for performing these functions are, optionally, included in a non-transitory computer-readable storage medium or other computer program product configured for execution by one or more processors.

FIG.7is a schematic block diagram representation of an apparatus or system10for automated development of a path planning module73of an ADS-equipped vehicle in accordance with an embodiment of the present invention. In general,FIG.7depicts the flow of information through exposure to an event in the vehicle surroundings, to the path evaluation processes, and further to the transmission and subsequent consolidation in the “back-office”2. The apparatus/system10comprises various control circuitry configured to perform the functions of the methods disclosed herein, where the functions may be included in a non-transitory computer-readable storage medium or other computer program product configured for execution by the control circuitry.FIG.7serves to better elucidate the present invention by depicting various “modules” each of them linked to one or more specific functions described in the foregoing.

It should be noted that the “candidate path” that is compared in the “evaluation engine”74may comprise a plurality of candidate paths.

The system10has a path planning module73that is configured to generate the candidate path for the vehicle based on a path planning model and data indicative of the surrounding environment of the vehicle (such as e.g. perception data generated by a perception system78of the vehicle). Accordingly, the perception system78is configured to generate a perception output based on sensor data71obtained from one or more vehicle-mounted sensors during the time period. The sensor data71may for example output from one or more of a RADAR device, a LIDAR device, a camera, and ultrasonic sensor, and so forth. In other words, a “perception system” (i.e. the perception system of the production platform) is in the present context to be understood as a system responsible for acquiring raw sensor data from on-board sensors such as cameras, LIDARs and RADARs, ultrasonic sensors, and converting this raw data into scene understanding including state estimates and predictions thereof.

The vehicle's production platform/system72is configured to supply a reference framework for evaluating the candidate path. The reference framework is configured to indicate one or more risk values associated with the candidate path when the candidate path is applied in the reference framework. Moreover, the reference framework may be in the form of a risk map generated by a risk map engine79and/or a baseline worldview generated by a post-processing module77.

Thus, in some embodiments, the perception data is stored or saved in a data buffer (not shown), where this perception data may be understood as data indicative of the vehicle's surroundings. This may for example be detected objects or objects' states and/or vehicle localization, and/or statistical and physical model predictions of future states, derived continuously and/or intermittently from a first time point T1to a second time point T2. The time period—and correspondingly the length of the optional data buffer—may be of any arbitrary size deemed feasible, e.g. in consideration of data capacity restraints, a predicted duration of the candidate path(s), and/or characteristics of the ADS, and may for instance range from under a second up to several minutes, or more preferred, from a few seconds up to less than a minute.

Further, the production platform72may accordingly comprise a post-processing module77for forming a baseline worldview indicative of a scenario in the surrounding environment of the vehicle during the time period. The baseline worldview is formed based on the perception data generated by the perception system78of the production ADS. It should be noted that the term “forming, by post-processing the first set of perception data” does not necessarily mean that all of the stored data is post-processed, but should be construed as that at least a portion or at least a range of the stored perception data is post-processed.

In some embodiments, production platform72has a risk map engine79configured to generate a risk map based on an actuation capability of the vehicle and a location of free-space areas in the surrounding environment. The actuation capability includes an uncertainty estimation for the actuation capability and the location of free-space areas includes an uncertainty estimation for the estimated location of free-space areas. In other words, the risk map engine79is configured to compile the risk map from the detections and predictions including uncertainties from the perception system72and the capabilities and uncertainties reported by the vehicle platform (e.g. steering capabilities, braking capacity, etc.). The risk map may be understood as a virtual map of the surrounding environment of the vehicle with a number of defined area segments, each being associated with a corresponding risk parameter.

Moreover, the risk map further has a temporal component indicative of a time evolution of the risk parameters of the area segments based on a predicted temporal evolution of the free-space areas for at least a duration of time defined by a predicted duration of the candidate path. The predicted temporal evolution may for example be based on the perception data and one or more prediction models (e.g. trajectory predictions, statistical models, etc.).

In accordance with an illustrative example, the obtained actuation capability may comprise a braking capacity and an uncertainty estimation or a type of “error margin” of the obtained braking capacity. For example, if the obtained braking capacity is indicative of the vehicle being able to come to a complete stop (assuming emergency braking actuation) within a distance of 150 meters, then an uncertainty estimation for this estimation may include an error margin of ±15 meters (i.e. ±10%). As mentioned in the foregoing, the actuation capability may be given from statistical models of one or more actuation parameters where the uncertainty estimation for each actuation parameter may be defined by the standard deviation in those statistical models.

Further, the risk map engine79obtains a location of free-space areas in the surrounding environment of the vehicle (e.g. from the perception system78of the vehicle), where the obtained location of free-space areas comprises an uncertainty estimation for the estimated location of free-space areas. As mentioned in the foregoing, free-space areas may in the present context be understood as areas in the surrounding environment of the ego-vehicle absent of objects (e.g. other vehicles, pedestrians, barriers, animals, bicycles, static objects, etc.). Thus, the obtained location of free-space areas may comprise a determined location of external objects (static and dynamic objects), determined trajectories of dynamic objects, as well as an estimate of the uncertainty of the determinations, i.e. the likelihood of the determined location of the free-space area actually being true.

Further, the reference framework is supplied to the evaluation engine74configured to evaluate the obtained candidate path by applying the candidate path in the reference framework in order to determine a cost function based on the one or more risk values. The output of the cost function is accordingly indicative of a performance of the path planning module within the reference framework, or more specifically, indicative of a level of risk associated with the candidate path. Thus, in some embodiments the cost function is indicative of whether or not the generated candidate path can be considered safe (given one or more predefined criteria).

For example, the evaluation engine74may be configured to evaluate the candidate path by determining an aggregated risk value for the candidate path based on the risk parameters of a set of area segments intersected by the candidate path, where the aggregated risk value defines the one or more risk values associated with the candidate path. Accordingly, the evaluation engine74may be configured to determine the cost function based on the determined aggregated risk value.

Alternatively, or additionally, the evaluation engine74may be configured to evaluate the candidate path by comparing the candidate path with the baseline worldview, and determining the cost function based on the one or more risk values. Each risk value is accordingly indicative of a temporal evolution of a collision threat measure for the candidate path during at least a portion of the time period.

Further, the system10has a learning engine75configured to update one or more parameters of the path planning model by means of an optimization algorithm configured to optimize the determined cost function. Moreover, the learning engine75may be configured to transmit the one or more updated parameters of the path planning model of the path planning module to a remote entity2, and then receive a set of globally updated parameters of the path planning model of the path planning module from the remote entity. The set of globally updated parameters are based on information obtained from a plurality of vehicles comprising a corresponding path planning module. Thereafter, the learning engine75may update the path planning model of the path planning module based on the received set of globally updated parameters. Thus may be construed as a “consolidation” process across an entire fleet of vehicles.

FIG.8is a schematic side view illustration of a vehicle1comprising an apparatus10for automated development of a path planning module of an ADS-equipped vehicle in accordance with an embodiment of the present invention. The vehicle1further comprises a perception module/system6(i.e. the perception system of the production platform), and a localization system5. The localization system5is configured to monitor a geographical position and heading of the vehicle, and may in the form of a Global Navigation Satellite System (GNSS), such as a GPS. However, the localization system may alternatively be realized as a Real Time Kinematics (RTK) GPS in order to improve accuracy.

In more detail, the perception module/system6may refer to any commonly known system and/or functionality, e.g. comprised in one or more electronic control modules and/or nodes of the vehicle1, adapted and/or configured to interpret sensory information—relevant for driving of the vehicle1—to identify e.g. obstacles, vehicle lanes, relevant signage, appropriate navigation paths etc. The exemplified perception system6may thus be adapted to rely on and obtain inputs from multiple data sources, such as automotive imaging, image processing, computer vision, and/or in-car networking, etc., in combination with sensory information. Such exemplifying sensory information may for instance be derived from one or more optional surrounding detecting sensors6a-ccomprised in and/or provided on-board the vehicle1. The surrounding detecting sensors6a-cmay be represented by any arbitrary sensors adapted to sense and/or perceive the vehicle's1surroundings and/or whereabouts, and may e.g. refer to one or a combination of one or more of radar, LIDAR, sonar, camera, navigation system e.g. GPS, odometer and/or inertial measurement units.

The apparatus10comprises one or more processors11, a memory12, a sensor interface13and a communication interface14. The processor(s)11may also be referred to as a control circuit11or control circuitry11. The control circuitry11is configured to execute instructions stored in the memory12to perform a method f for automated development of a path planning module of a vehicle1according to any one of the embodiments disclosed herein. Stated differently, the memory12of the apparatus10can include one or more (non-transitory) computer-readable storage mediums, for storing computer-executable instructions, which, when executed by one or more computer processors11, for example, can cause the computer processors11to perform the techniques described herein. The memory12optionally includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices; and optionally includes non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices.

The control circuitry11is configured to obtain a candidate path from the path planning module. The path planning module is configured to generate the candidate path for the vehicle based on a path planning model and data indicative of the surrounding environment of the vehicle. The control circuitry11is further configured to obtain a reference framework for evaluating the candidate path. The reference framework is configured to indicate one or more risk values associated with the candidate path when the candidate path is applied in the reference framework. Further, the control circuitry11is configured to evaluate the obtained candidate path by applying the candidate path in the reference framework in order to determine a cost function based on the one or more risk values. The cost function is indicative of a performance of the path planning module within the reference framework. Moreover, the control circuitry11is configured to update one or more parameters of the path planning model by means of an optimization algorithm configured to optimize the determined cost function.

Further, the vehicle1may be connected to external network(s)20via for instance a wireless link (e.g. for retrieving map data). The same or some other wireless link may be used to communicate with other vehicles2in the vicinity of the vehicle or with local infrastructure elements. Cellular communication technologies may be used for long range communication such as to external networks and if the cellular communication technology used have low latency it may also be used for communication between vehicles, vehicle to vehicle (V2V), and/or vehicle to infrastructure, V2X. Examples of cellular radio technologies are GSM, GPRS, EDGE, LTE, 5G, 5G NR, and so on, also including future cellular solutions. However, in some solutions mid to short range communication technologies are used such as Wireless Local Area (LAN), e.g. IEEE 802.11 based solutions. ETSI is working on cellular standards for vehicle communication and for instance 5G is considered as a suitable solution due to the low latency and efficient handling of high bandwidths and communication channels.

The present invention has been presented above with reference to specific embodiments. However, other embodiments than the above described are possible and within the scope of the invention. Different method steps than those described above, performing the method by hardware or software, may be provided within the scope of the invention. Thus, according to an exemplary embodiment, there is provided a non-transitory computer-readable storage medium storing one or more programs configured to be executed by one or more processors of a vehicle control system, the one or more programs comprising instructions for performing the method according to any one of the above-discussed embodiments. Alternatively, according to another exemplary embodiment a cloud computing system can be configured to perform any of the methods presented herein. The cloud computing system may comprise distributed cloud computing resources that jointly perform the methods presented herein under control of one or more computer program products.

Generally speaking, a computer-accessible medium may include any tangible or non-transitory storage media or memory media such as electronic, magnetic, or optical media—e.g., disk or CD/DVD-ROM coupled to computer system via bus. The terms “tangible” and “non-transitory,” as used herein, are intended to describe a computer-readable storage medium (or “memory”) excluding propagating electromagnetic signals, but are not intended to otherwise limit the type of physical computer-readable storage device that is encompassed by the phrase computer-readable medium or memory. For instance, the terms “non-transitory computer-readable medium” or “tangible memory” are intended to encompass types of storage devices that do not necessarily store information permanently, including for example, random access memory (RAM). Program instructions and data stored on a tangible computer-accessible storage medium in non-transitory form may further be transmitted by transmission media or signals such as electrical, electromagnetic, or digital signals, which may be conveyed via a communication medium such as a network and/or a wireless link.

The processor(s)11(associated with the apparatus10) may be or include any number of hardware components for conducting data or signal processing or for executing computer code stored in memory12. The apparatus10has an associated memory12, and the memory12may be one or more devices for storing data and/or computer code for completing or facilitating the various methods described in the present description. The memory may include volatile memory or non-volatile memory. The memory12may include database components, object code components, script components, or any other type of information structure for supporting the various activities of the present description. According to an exemplary embodiment, any distributed or local memory device may be utilized with the systems and methods of this description. According to an exemplary embodiment the memory12is communicably connected to the processor11(e.g., via a circuit or any other wired, wireless, or network connection) and includes computer code for executing one or more processes described herein.

It should be appreciated that the sensor interface13may also provide the possibility to acquire sensor data directly or via dedicated sensor control circuitry6in the vehicle. The communication/antenna interface14may further provide the possibility to send output to a remote location (e.g. remote operator or control centre) by means of the antenna8. Moreover, some sensors in the vehicle may communicate with the system10using a local network setup, such as CAN bus, I2C, Ethernet, optical fibres, and so on. The communication interface14may be arranged to communicate with other control functions of the vehicle and may thus be seen as control interface also; however, a separate control interface (not shown) may be provided. Local communication within the vehicle may also be of a wireless type with protocols such as WiFi, LoRa, Zigbee, Bluetooth, or similar mid/short range technologies.

Accordingly, it should be understood that parts of the described solution may be implemented either in the vehicle, in a system located external the vehicle, or in a combination of internal and external the vehicle; for instance in a server in communication with the vehicle, a so called cloud solution. For instance, data may be sent to an external system and that system performs the steps to evaluate the candidate paths. The different features and steps of the embodiments may be combined in other combinations than those described.

It should be noted that the word “comprising” does not exclude the presence of other elements or steps than those listed and the words “a” or “an” preceding an element do not exclude the presence of a plurality of such elements. It should further be noted that any reference signs do not limit the scope of the claims, that the invention may be at least in part implemented by means of both hardware and software, and that several “means” or “units” may be represented by the same item of hardware.

Although the figures may show a specific order of method steps, the order of the steps may differ from what is depicted. In addition, two or more steps may be performed concurrently or with partial concurrence. For example, the steps of obtaining a candidate path and obtaining a reference framework may be interchanged based on a specific realization. Such variation will depend on the software and hardware systems chosen and on designer choice. All such variations are within the scope of the invention. Likewise, software implementations could be accomplished with standard programming techniques with rule-based logic and other logic to accomplish the various connection steps, processing steps, comparison steps and decision steps. The above mentioned and described embodiments are only given as examples and should not be limiting to the present invention. Other solutions, uses, objectives, and functions within the scope of the invention as claimed in the below described patent embodiments should be apparent for the person skilled in the art.