Method, device and medium for determining simulation scenario
By performing scenario testing and genetic algorithm optimization on the initial scenario, a target simulation scenario that meets the performance boundary testing requirements is generated, which solves the safety problem of autonomous driving algorithms before real vehicle testing and ensures the safety of the algorithm.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHANGSHA INTELLIGENT DRIVING INST CORP LTD
- Filing Date
- 2024-11-26
- Publication Date
- 2026-06-02
Smart Images
Figure CN122132285A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of autonomous driving technology, and in particular relates to a method, apparatus, device and medium for determining a simulation scene. Background Technology
[0002] With the development and implementation of unmanned driving technology in mining, how to effectively test unmanned driving algorithms and ensure their safety and reliability has become a key concern in the industry. Due to the safety risks associated with real-vehicle testing in hazardous scenarios, simulation testing of unmanned driving algorithms before deployment in real-vehicle environments is increasingly favored and valued.
[0003] In existing methods, traffic information of various traffic parameters is extracted based on road data, and simulation test scenarios are generated based on the traffic information of various traffic parameters, so as to realize the simulation test of autonomous driving algorithms in the simulation test scenarios.
[0004] However, existing methods cannot meet the performance boundary testing requirements of autonomous driving algorithms, and cannot fully guarantee the safety of autonomous driving algorithms before deployment in real vehicles. Summary of the Invention
[0005] This application provides a method, apparatus, device, and medium for determining simulation scenarios, which can meet the performance boundary testing requirements of autonomous driving algorithms and ensure the safety of autonomous driving algorithms before deployment in real vehicles.
[0006] One aspect of this application provides a method for determining a simulation scene, including:
[0007] Obtain at least one initial scene corresponding to the target vehicle. The initial scene includes multiple scene parameters for describing the scene. The initial scene includes at least one of the target vehicle's basic scene and a first generalized scene obtained by generalizing the basic scene.
[0008] Scene tests were conducted on each initial scene to obtain the test boundary index for each initial scene. The test boundary index is used to characterize the distance relationship between the target vehicle and obstacles other than the target vehicle in the initial scene.
[0009] Using the test boundary index as fitness, the genetic operators of the genetic algorithm are used to select, cross over and / or mutate the scene parameters of the initial scene to obtain at least one optimized scene;
[0010] The initial scene is updated to the optimized scene, and the scene test is performed on each initial scene separately to obtain the test boundary index of each initial scene until the preset stopping condition is reached, and at least one candidate scene is obtained.
[0011] Candidate scenarios with fitness greater than a preset threshold are identified as target simulation scenarios that meet the performance boundary test requirements.
[0012] One aspect of this application provides a device for determining a simulation scene, comprising:
[0013] The scene acquisition module is used to acquire at least one initial scene corresponding to the target vehicle. The initial scene includes multiple scene parameters for describing the scene. The initial scene includes at least one of the target vehicle's basic scene and a first generalized scene obtained by generalizing the basic scene.
[0014] The scene testing module is used to perform scene testing on each initial scene to obtain the test boundary index of each initial scene. The test boundary index is used to characterize the distance relationship between the target vehicle and obstacles other than the target vehicle in the initial scene.
[0015] The scene optimization module is used to select, crossover, and / or mutate the scene parameters of the initial scene using genetic operators of a genetic algorithm, with the test boundary index as the fitness, to obtain at least one optimized scene.
[0016] The loop test module is used to update the initial scene to the optimized scene and return to perform scene tests on each initial scene separately to obtain the test boundary indicators of each initial scene until the preset stopping condition is reached, and at least one candidate scene is obtained.
[0017] The scenario determination module is used to identify candidate scenarios with fitness values greater than a preset threshold as target simulation scenarios that meet the performance boundary test requirements.
[0018] In one aspect of this application, an electronic device is provided, the device including: a memory and a program or instructions stored in the memory and executable on a processor, wherein when the program or instructions are executed by the processor, they implement the method for determining a simulation scene as provided in any aspect of the above-described embodiments of this application.
[0019] In one aspect of the embodiments of this application, a readable storage medium is provided, on which a program or instructions are stored, and when the program or instructions are executed by a processor, the method for determining a simulation scenario as provided in any aspect of the embodiments of this application above is implemented.
[0020] In one aspect of the embodiments of this application, a computer program product is provided, wherein when the instructions in the computer program product are executed by the processor of an electronic device, the electronic device performs the method for determining a simulation scenario as provided in any aspect of the embodiments of this application described above.
[0021] The simulation scenario determination method provided in this application embodiment involves conducting scenario tests on each initial scenario to obtain test boundary indicators characterizing the distance relationship between the target vehicle and obstacles other than the target vehicle in the initial scenario. Then, based on the test boundary indicators of the initial scenario, the fitness of the initial scenario is determined. Next, based on the fitness of the initial scenario and the genetic operators of the genetic algorithm, the initial scenario is optimized to further meet the performance boundary testing requirements of the autonomous driving algorithm. This process continues until a preset stopping condition is reached, thereby obtaining a target simulation scenario that meets the performance boundary testing requirements. Thus, this application embodiment continuously optimizes the initial scenarios through closed-loop iteration based on the fitness of each initial scenario. This results in a target simulation scenario that meets the performance boundary testing requirements of the autonomous driving algorithm, ensuring the safety of the autonomous driving algorithm before deployment in real-vehicle testing. Attached Figure Description
[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0023] Figure 1 This is a flowchart illustrating a method for determining a simulation scene according to an embodiment of this application;
[0024] Figure 2 This is a schematic diagram of target simulation scene classification and storage provided in one embodiment of this application;
[0025] Figure 3 This is a schematic diagram of parallel testing provided in one embodiment of this application;
[0026] Figure 4 This is a schematic diagram of the structure of a simulation scene determination device provided in one embodiment of this application;
[0027] Figure 5 This is a schematic diagram of the structure of a simulation scene determination device provided in one embodiment of this application. Detailed Implementation
[0028] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.
[0029] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.
[0030] It should be noted that the acquisition, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations.
[0031] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.
[0032] Existing methods extract traffic information from various traffic parameters based on road survey data, and generate simulation test scenarios based on this information to perform simulation tests on autonomous driving algorithms. However, existing methods cannot meet the performance boundary testing requirements of autonomous driving algorithms, nor can they guarantee the safety of autonomous driving algorithms before deployment in real vehicles.
[0033] The purpose of this application is to provide a method, apparatus, device, and medium for determining simulation scenarios. In the method for determining simulation scenarios provided in this application, scenario testing is performed on each initial scenario to obtain test boundary indicators characterizing the distance relationship between the target vehicle and obstacles other than the target vehicle in the initial scenario. Then, based on the test boundary indicators of the initial scenario, the fitness of the initial scenario is determined. Then, based on the fitness of the initial scenario and the genetic operators of the genetic algorithm, the initial scenario is optimized to further meet the performance boundary testing requirements of the autonomous driving algorithm. This continues until a preset stopping condition is reached, thereby obtaining a target simulation scenario that meets the performance boundary testing requirements. Thus, this application embodiment continuously optimizes the initial scenario based on its fitness through continuous closed-loop iteration. This allows for the acquisition of a target simulation scenario that meets the performance boundary testing requirements of the autonomous driving algorithm, ensuring the safety of the autonomous driving algorithm before deployment in real-vehicle testing.
[0034] The following describes specific embodiments of the simulation scene determination method, apparatus, equipment, and medium provided in this application. The method for determining the simulation scene will be described first.
[0035] Figure 1 A flowchart illustrating a method for determining a simulation scenario is provided. This method can be applied to a server and may include steps S101 to S105.
[0036] S101, obtain at least one initial scene corresponding to the target vehicle. The initial scene includes multiple scene parameters for describing the scene. The initial scene includes at least one of the target vehicle's basic scene and a first generalized scene obtained by generalizing the basic scene.
[0037] In this embodiment, the target vehicle is used to represent an autonomous vehicle that needs to undergo autonomous driving algorithm testing.
[0038] Scene parameters are used to characterize parameters that describe scene features. For example, scene parameters may include at least one of road type and obstacle type. The road type may be a city street or a mining road; the obstacle type may be at least one of other vehicles, pedestrians, and road obstacles.
[0039] As an example, the server can extract scene parameters from actual road data, historical driving data of the target vehicle, and other simulation environments. Then, it can construct at least one basic scene corresponding to the target vehicle based on the scene parameters.
[0040] Furthermore, the scene parameters in the base scene corresponding to the target vehicle can be generalized to obtain at least one first generalized scene corresponding to the target vehicle. The base scene and the first generalized scene are then determined as the initial scene corresponding to the target vehicle.
[0041] S102, Perform scene testing on each initial scene to obtain the test boundary index of each initial scene. The test boundary index is used to characterize the distance relationship between the target vehicle and obstacles other than the target vehicle in the initial scene.
[0042] In this embodiment, the test boundary metric corresponds to the performance boundary test requirement. Specifically, the performance boundary test requirement in this embodiment is to ensure that the autonomous driving algorithm can instruct the autonomous vehicle to drive safely when the target vehicle is relatively close to other obstacles. Therefore, the test boundary metric characterizes the distance relationship between the target vehicle and obstacles other than the target vehicle in the initial scenario.
[0043] As an example, the server uses simulation software or a simulator to simulate the initial scenario of vehicle movement, and then evaluates the relative position between the target vehicle and other obstacles in the scenario. The minimum relative position between the target vehicle and other obstacles in the scenario is then used as the test boundary metric for the corresponding initial scenario.
[0044] S103, using the test boundary index as fitness, the genetic operators of the genetic algorithm are used to select, cross over and / or mutate the scene parameters of the initial scene to obtain at least one optimized scene.
[0045] In this embodiment, the test boundary metric is used as the fitness of the genetic algorithm. The more extreme the performance boundary of the scene, the higher its fitness; for example, the reciprocal of the test boundary metric can be used to determine the fitness of the genetic algorithm. In this case, the closer the relative position of the target vehicle to other obstacles in the scene, the greater its fitness.
[0046] Optimized scenarios are used to characterize scenarios that better meet the performance boundary testing requirements after optimizing the scenario parameters of the initial scenario.
[0047] As an example, after obtaining the test boundary metrics for each initial scenario, the server determines the fitness by the reciprocal of the test boundary metrics. Then, based on the fitness value, the best initial scenario is selected as the parent. Next, the scenario parameters between the parent scenarios are cross-combined to generate new child scenarios, i.e., optimized scenarios. Additionally, some scenario parameters in the child scenarios can be randomly changed to increase population diversity.
[0048] S104, update the initial scene to the optimized scene, and return to perform scene testing on each initial scene separately to obtain the test boundary indicators of each initial scene until the preset stopping condition is reached, and obtain at least one candidate scene.
[0049] In this embodiment, the preset stopping condition can be that the number of iterations reaches a preset threshold or the fitness improvement reaches a preset threshold.
[0050] Candidate scenarios are used to characterize scenarios that better meet the performance boundary test requirements after iterative optimization of the initial scenario has stopped.
[0051] As an example, after obtaining the optimized scenario, the server replaces the initial scenario with the optimized scenario and retests the scenario to obtain the corresponding fitness. Through multiple rounds of selection, crossover, and mutation operations, the scenario parameters are gradually optimized until the number of iterations reaches a preset threshold, at which point the iteration stops, resulting in at least one candidate scenario.
[0052] S105: Candidate scenarios with fitness greater than a preset threshold are identified as target simulation scenarios that meet the performance boundary test requirements.
[0053] In this embodiment, a threshold is preset, and only candidate scenarios with fitness greater than the threshold can be regarded as target simulation scenarios that meet the performance boundary test requirements.
[0054] As an example, the server compares the fitness of each candidate scenario with a preset threshold, and identifies the candidate scenarios with fitness greater than the preset threshold as the target simulation scenarios that meet the performance boundary test requirements.
[0055] Then, the simulation scenarios for each target are stored. For example... Figure 2 The diagram illustrates a method for classifying and storing target simulation scenarios. Specifically, based on the algorithm testing requirements for different functions, each target simulation scenario is classified and stored to facilitate repeated testing and verification of the algorithm's functions, thereby ensuring the algorithm's safety before deployment in real-vehicle testing.
[0056] In the simulation scenario determination method provided in this embodiment, scenario testing is performed on each initial scenario to obtain test boundary indicators characterizing the distance relationship between the target vehicle and obstacles other than the target vehicle in the initial scenario. Then, based on the test boundary indicators of the initial scenario, the fitness of the initial scenario is determined. Then, based on the fitness of the initial scenario and the genetic operators of the genetic algorithm, the initial scenario is optimized to further meet the performance boundary testing requirements of the autonomous driving algorithm. This continues until a preset stopping condition is reached, thereby obtaining a target simulation scenario that meets the performance boundary testing requirements. In this way, this embodiment continuously optimizes the initial scenario based on the fitness of each initial scenario through continuous closed-loop iteration. This enables the obtaining of a target simulation scenario that meets the performance boundary testing requirements of the autonomous driving algorithm, ensuring the safety of the autonomous driving algorithm before deployment in real vehicles.
[0057] As an optional embodiment, the genetic operators include selection operators, crossover operators, and mutation operators;
[0058] S103 may specifically include:
[0059] Using the test boundary index as fitness, and according to the selection operator of the genetic algorithm, the first N initial scenarios are selected as parent simulation scenarios in descending order of fitness from each initial scenario, where N is a positive integer greater than or equal to 2.
[0060] Based on the crossover operator of the genetic algorithm, the scene parameters are exchanged between the parent simulation scenes to obtain at least one offspring simulation scene.
[0061] Based on the mutation operator of the genetic algorithm, perform mutation operation on the scenario parameters of at least one offspring simulation scenario to obtain at least one mutated simulation scenario;
[0062] The offspring simulation scenario and the mutation simulation scenario are merged to obtain the optimized scenario.
[0063] In this embodiment, the selection operator is used to characterize the execution strategy of selecting the parent simulation scene with better fitness, the crossover operator is used to characterize the execution strategy of exchanging scene parameters of the selected parent simulation scene, and the mutation operator is used to characterize the execution strategy of mutating scene parameters of the generated child simulation scene.
[0064] The optimization scenarios include at least one of the offspring simulation scenarios and the mutation simulation scenarios.
[0065] As an example, the server calculates the fitness value of each initial scenario based on test boundary metrics and sorts them from highest to lowest fitness value. Then, from the sorted scenarios, the top N are selected as parent simulation scenarios. N is a preset positive integer, usually determined based on population size and computing resources, but at least 2 to ensure genetic diversity.
[0066] Then, the selected parent simulation scenarios are paired, and their partial scenario parameters are exchanged according to the crossover rules of the genetic algorithm (such as single-point crossover, double-point crossover, etc.). Through the crossover operation, at least one child simulation scenario is generated. These child simulation scenarios inherit some characteristics of the parent simulation scenarios, but may also generate new combinations due to crossover, thereby increasing the exploration of the search space.
[0067] Then, the mutation operator is applied to some or all of the child simulation scenarios, randomly changing the values of their scenario parameters. Through the mutation operation, at least one mutated simulation scenario is obtained. These scenarios may differ significantly from the parent or child in some aspects, which helps to discover better solutions.
[0068] Finally, the offspring simulation scenarios are merged with the mutation simulation scenarios to form an optimized scenario set. For each optimized scenario in the optimized scenario set, the fitness value can be recalculated, and the above selection, crossover, mutation, and merging steps can be repeated until a termination condition is met. The termination condition may include reaching a preset number of iterations, finding a scenario that meets a specific fitness threshold, or converging to a stable solution.
[0069] This embodiment utilizes a genetic algorithm to optimize the initial scenario, improving the performance of test boundary indicators. This results in a target simulation scenario that meets the performance boundary testing requirements of autonomous driving algorithms, ensuring the safety of autonomous driving algorithms before deployment in real vehicles.
[0070] As an optional embodiment, S102 may specifically include:
[0071] Each initial scenario was tested separately, and the results of the scenario tests for each initial scenario were obtained.
[0072] If the scenario test results indicate that the target vehicle has not collided, the minimum distance between the target vehicle and the obstacle is determined as the test boundary index of the initial scenario.
[0073] In this embodiment, obstacles are used to represent all other scene elements in the initial scene besides the target vehicle.
[0074] As an example, the server defines a series of initial scenarios based on testing requirements. These scenarios may include different road conditions, traffic environments, target vehicle speed, acceleration, obstacle types, and locations, among other parameters. A simulation environment is then configured for scenario testing to ensure accurate simulation of the conditions in the initial scenarios.
[0075] Then, scenario tests are conducted one by one according to the defined initial scenarios. During the tests, the traffic environment and road conditions in the initial scenarios are simulated, and the behavior of the target vehicle and obstacles is monitored. Motion data of the target vehicle and obstacles during the tests are collected, including position, speed, acceleration, etc. The collected data is then analyzed to determine whether the target vehicle has collided with the obstacle. Specifically, this can be achieved by comparing the position data of the target vehicle and the obstacle, as well as using a set safe distance threshold.
[0076] If the scenario test results indicate that the target vehicle did not collide, the minimum distance between the target vehicle and the obstacle is further analyzed, and the calculated minimum distance is determined as the test boundary index for this initial scenario. Specifically, this can be achieved by calculating the shortest distance between the target vehicle and the obstacle during the test.
[0077] This embodiment performs scenario testing on each initial scenario, obtaining the scenario test results for each initial scenario. The minimum distance between the target vehicle and obstacles is then calculated and determined as the test boundary metric for the initial scenario. This helps to subsequently optimize the initial scenario using the test boundary metric as a fitness parameter, thereby obtaining a target simulation scenario that meets the performance boundary testing requirements of the autonomous driving algorithm and ensuring the safety of the autonomous driving algorithm before its deployment in real-vehicle testing.
[0078] As an optional embodiment, scene testing is performed on each initial scene to obtain the scene test results for each initial scene, which may specifically include:
[0079] Obtain the number of parallel tests, which represents the number of scenarios that can be tested simultaneously.
[0080] The initial scenarios corresponding to the number of parallel tests are obtained sequentially and tested in parallel until each initial scenario is traversed, and the scenario test results of each initial scenario are obtained.
[0081] In this embodiment, the number of parallel tests refers to the number of scenarios that can be tested simultaneously, and it is determined based on the test information. The test information may include at least one of test resource information, test requirement information, and system performance information.
[0082] Test resource information may include test equipment and test environment; test requirement information may include the number of scenarios to be tested, the complexity of each scenario, and the test time; system performance information may include the processing power and stability of the test system.
[0083] As an example, such as Figure 3 The diagram illustrates a parallel testing approach. The server first allocates resources for the initial scenario, determining a reasonable number of parallel tests by analyzing factors such as test resources, test requirements, and system performance. Then, it configures the appropriate test environment for each initial scenario, including hardware, software, and network. For each initial scenario, a corresponding test script is written to simulate user behavior and system interaction. This test script should include necessary input data, expected output, and error handling logic.
[0084] Then, after the scenario is launched, multiple test instances are launched simultaneously according to the number of parallel tests, each corresponding to a different initial scenario for testing. Specifically, this involves simulating the movement of the virtual vehicle in each initial scenario, as well as simulating the autonomous driving system's control of the target vehicle, until all initial scenarios have been traversed. During test execution, the test progress and results are monitored to ensure that each scenario can be executed correctly and achieve the expected results.
[0085] Finally, after conducting parallel tests on each initial scenario, the scenario test results for each initial scenario are collected and analyzed in parallel. Specifically, test analysis reports and test playback videos can be generated. The test analysis reports can include dynamic characteristic analysis and fault analysis of the autonomous driving system's planning, control, and positioning; the test playback videos can include displays of the target vehicle's trajectory and driving status, obstacle prediction trajectories and driving status, and driving road boundaries.
[0086] This embodiment obtains the number of parallel tests and sequentially performs parallel tests on the initial scenarios corresponding to those parallel test numbers, achieving fast and accurate testing of multiple scenarios. Thus, by performing parallel testing on the initial scenarios, testing efficiency can be improved while reducing testing costs.
[0087] As an optional embodiment, S101 may specifically include:
[0088] Based on the scene description information corresponding to the target vehicle, a basic scene corresponding to the target vehicle is generated. The scene description information is used to describe the scene picture of the basic scene.
[0089] By generalizing the basic scenario, at least one first generalized scenario corresponding to the basic scenario is obtained;
[0090] The basic scenario and the first generalized scenario are merged to obtain at least one initial scenario corresponding to the target vehicle.
[0091] In this embodiment, the scene description information is information that describes the basic scene. For example, the scene description information may include the scene's geographical location, weather conditions, time (e.g., daytime, nighttime), traffic conditions, road type (e.g., highway, urban road, rural road), obstacle type and location, other traffic participants (e.g., pedestrians, bicycles, other vehicles), etc.
[0092] The first generalized scenario is used to represent the generalized scenario obtained by adjusting the base scenario according to preset generalization rules. For example, the preset generalization rules may include changing weather conditions, adjusting traffic flow, changing the location or type of obstacles, changing time, etc.
[0093] As an example, the server first obtains the scene description information corresponding to the target vehicle, and uses natural language processing or structured data parsing technology to parse the scene description information into a format that can be understood and processed by a computer. Based on the parsed scene description information, a basic scene is created using 3D modeling software or a scene generation engine.
[0094] Then, based on the preset generalization rules, the base scenario is adjusted multiple times to generate several first generalized scenarios. Each first generalized scenario should retain the core features of the base scenario to some extent, while introducing new variations to increase the diversity and complexity of the scenario.
[0095] Finally, the base scenario is merged with all the first generalized scenarios to form a set containing multiple initial scenarios. This merging is not merely a physical combination, but more importantly, it ensures that the data structure and metadata of each initial scenario can be managed and accessed uniformly.
[0096] In this embodiment, scene description information is parsed to generate a basic scene, and then the basic scene is generalized to obtain a first generalized scene. Thus, this application can generate multiple initial scenes related to the target vehicle, thereby providing strong support for performance boundary testing of autonomous driving algorithms.
[0097] As an optional embodiment, scene parameters include scene elements, element behaviors of scene elements, and triggering events for element behaviors;
[0098] Based on the scene description information corresponding to the target vehicle, a basic scene corresponding to the target vehicle is generated, which may specifically include:
[0099] Obtain scene description information corresponding to the target vehicle;
[0100] Based on the scene description information, determine the scene elements, element behaviors, and triggering events corresponding to the basic scene;
[0101] Bind related scene elements, element behaviors, and triggering events to generate scene parameters for the basic scene;
[0102] Based on the parameters of each scenario, a basic scenario corresponding to the target vehicle is generated.
[0103] In this embodiment, the scene description information can be either a custom scene input by the user or a scene description information corresponding to an actual test scene.
[0104] Scene elements may include target vehicles, manned vehicles (mining trucks, water trucks, excavators, bulldozers, passenger cars, fuel trucks, and road rollers, etc.), and non-motorized obstacles (pedestrians, rocks, piles of earth, etc.).
[0105] The target vehicles are autonomous vehicles, which can be modeled using nonlinear vehicle dynamics theory. Specifically, this includes transmission models, tire models, overall vehicle motion models, suspension models, and hydraulic steering models. The descriptive parameters for autonomous vehicles can include dynamic characteristic parameters, physical dimensions, range parameters, perception models, and initial pose. Manned vehicles can be modeled using kinematics theory, and their descriptive parameters can include vehicle type, physical dimensions, trajectory, and initial pose. Non-motorized vehicle obstacles can also be modeled using kinematics theory, and their descriptive parameters can include type, physical dimensions, trajectory, initial pose, and stochastic characteristics. Among the descriptive parameters, the trajectory can be fitted using cubic spline curves, dynamically changing the curve shape based on user-defined coordinate points.
[0106] Element behaviors are effective for both the target vehicle and obstacles. For example, element behaviors may include longitudinal velocity, lateral offset, initial pose, trajectory, and perception enablement. The perception enablement controls whether scene elements can be detected by the target vehicle's perception functions.
[0107] To trigger an event, you need to define a triggering object and a triggering area. The event is triggered when the triggering object enters the triggering area. The triggering area is a fan-shaped ring, and its definition includes the coordinates of the center point, the range of the fan angle, and the range of the ring radius.
[0108] As an example, the server obtains scene description information related to the target vehicle from various sources (such as user input, database queries, sensor data, etc.). Then, it parses the obtained scene description information to extract key information, including scene elements, element behaviors, and triggering events.
[0109] Next, the associated scene elements, element behaviors, and triggering events are bound together, with multiple scene elements and element behaviors potentially bound to the same triggering event. These bound scene elements, element behaviors, and triggering events are then converted into parameterized representations and combined into a scene parameter set. This scene parameter set contains all the information needed to generate the basic scene. Finally, using the scene parameter set, the basic scene is constructed in the simulation environment.
[0110] This embodiment parses the scene description information to obtain scene elements, element behaviors, and triggering events, and binds the associated scene elements, element behaviors, and triggering events to obtain scene parameters. Thus, a basic scene corresponding to the target vehicle can be generated based on the scene parameters. By generating a basic scene related to the target vehicle, strong support is provided for the performance boundary testing of autonomous driving algorithms.
[0111] As an optional embodiment, the basic scenario is generalized to obtain at least one first generalized scenario corresponding to the basic scenario, which may specifically include:
[0112] The initial parameter values of the element behaviors of each scene parameter in the basic scene are adjusted to obtain the parameter set of each element behavior. The parameter set includes the initial parameter values of the element behaviors and the generalized parameter values obtained by adjusting the initial parameter values.
[0113] By performing Cartesian product operations on the parameter sets of each element's behavior, multiple parameter combinations can be obtained;
[0114] Based on various parameter combinations, parameter values are set for the behavior of each element in the basic scenario to obtain at least one first generalized scenario corresponding to the basic scenario.
[0115] In this embodiment, the initial parameter values for element behavior may include at least one of longitudinal velocity parameter values, lateral offset parameter values, initial pose parameter values, and travel trajectory parameter values.
[0116] The Cartesian product is a mathematical operation used to arrange and combine all the elements of multiple sets to generate all possible combinations.
[0117] As an example, the server retrieves the element behaviors of each scene parameter in the base scenario and obtains the initial parameter value for each element behavior. Then, based on the initial parameter values, a series of generalized parameter values are generated through adjustments (e.g., increasing, decreasing, randomizing, etc.). These generalized parameter values are used to explore the changes in element behavior under different conditions to enrich the diversity of the scenario.
[0118] Then, for each element behavior, the initial parameter values and generalized parameter values are combined into a parameter set. This parameter set not only includes the original settings of the element behavior, but also includes various possible states obtained through adjustments.
[0119] Then, a Cartesian product operation is performed on the parameter sets of all element behaviors. In this way, each parameter value of each element behavior is combined with each parameter value of other element behaviors, resulting in a variety of parameter combinations and generating a huge parameter combination space.
[0120] Finally, based on the generated parameter combinations, the parameter values for the behavior of each element in the basic scene are set one by one. Each parameter combination corresponds to a unique scene variant, namely the first generalized scene. These scene variants differ in element behavior, thus exhibiting diverse scene characteristics.
[0121] This implementation utilizes fine-grained parameter tuning and combination strategies to achieve flexible generalization of element behaviors in a basic scenario. It provides an effective technical approach for creating diverse scenarios, thus offering strong support for performance boundary testing of autonomous driving algorithms.
[0122] As an optional embodiment, after generalizing the basic scenario to obtain at least one first generalized scenario corresponding to the basic scenario, the method for determining the simulation scenario may further include:
[0123] Based on the preset rationality verification conditions, rationality verification is performed on each first generalization scenario to obtain the verification results;
[0124] The first generalized scenario, whose verification results indicate that it does not meet the preset reasonableness verification conditions, is filtered out to obtain the second generalized scenario;
[0125] The base scenario and the first generalized scenario are merged to obtain at least one initial scenario corresponding to the target vehicle, which may specifically include:
[0126] The basic scenario and the second generalized scenario are merged to obtain at least one initial scenario corresponding to the target vehicle.
[0127] In this embodiment, the preset rationality verification conditions are the result of comprehensive consideration of various factors such as actual application scenarios, business needs, and technical limitations. The aim is to ensure that the generated generalized scenario conforms to actual conditions and expected requirements in terms of logic, physics, and behavior. For example, the preset rationality verification conditions may include: Do the element behaviors of the scenario elements conform to physical laws and common sense? Is the scenario stable and will it not cause system errors or crashes?
[0128] As an example, the server performs rationality verification on each first generalized scenario based on preset rationality verification conditions. Specifically, this may include: verifying whether the physical phenomena and laws in the scenario conform to actual conditions, such as the trajectory of an object's motion and changes in speed; and ensuring that the operation of the scenario will not have a negative impact on the system, such as causing system errors, crashes, or performance degradation.
[0129] Then, after completing the rationality verification, the verification results for each first generalization scenario are obtained. Based on the verification results, the first generalization scenarios that do not meet the preset rationality verification conditions are filtered out, thus obtaining a set of second generalization scenarios that meet the preset rationality verification conditions.
[0130] In this embodiment, the first generalization scenario that does not meet the preset reasonableness verification conditions is filtered out to obtain the second generalization scenario. Thus, by filtering out the first generalization scenario that does not meet the preset reasonableness verification conditions, the reasonableness of the generated generalization scenario can be ensured, thereby avoiding the impact of unreasonable generalization scenarios on performance boundary testing.
[0131] A method for determining simulation scenarios is provided. Accordingly, this application also provides specific embodiments of a device for determining simulation scenarios.
[0132] like Figure 4 As shown, the simulation scene determination device 400 provided in this application embodiment includes a scene acquisition module 410, a scene testing module 420, a scene optimization module 430, a loop testing module 440, and a scene determination module 450.
[0133] The scene acquisition module 410 is used to acquire at least one initial scene corresponding to the target vehicle. The initial scene includes multiple scene parameters for describing the scene. The initial scene includes at least one of the target vehicle's basic scene and a first generalized scene obtained by generalizing the basic scene.
[0134] The scene testing module 420 is used to perform scene testing on each initial scene to obtain the test boundary index of each initial scene. The test boundary index is used to characterize the distance relationship between the target vehicle and obstacles other than the target vehicle in the initial scene.
[0135] The scene optimization module 430 is used to select, cross over and / or mutate the scene parameters of the initial scene using the test boundary index as the fitness and the genetic operators of the genetic algorithm to obtain at least one optimized scene.
[0136] The loop test module 440 is used to update the initial scene to the optimized scene and return to perform scene tests on each initial scene to obtain the test boundary indicators of each initial scene until the preset stopping condition is reached, and at least one candidate scene is obtained.
[0137] The scenario determination module 450 is used to determine the candidate scenarios with fitness greater than a preset threshold as the target simulation scenarios that meet the performance boundary test requirements.
[0138] As an optional embodiment, the genetic operators include selection operators, crossover operators, and mutation operators;
[0139] Scene optimization module 430 specifically includes the following units:
[0140] The scene selection unit is used to select the top N initial scenes as parent simulation scenes from each initial scene in descending order of fitness, based on the test boundary index and the selection operator of the genetic algorithm, where N is a positive integer greater than or equal to 2.
[0141] The parameter exchange unit is used to perform scene parameter exchange operations between parent simulation scenes according to the crossover operator of the genetic algorithm to obtain at least one offspring simulation scene.
[0142] The parameter mutation unit is used to perform a mutation operation on the scene parameters of at least one offspring simulation scene according to the mutation operator of the genetic algorithm, so as to obtain at least one mutated simulation scene.
[0143] The first scenario merging unit is used to merge the offspring simulation scenario and the mutation simulation scenario to obtain the optimized scenario.
[0144] As an optional embodiment, the scenario testing module 420 specifically includes the following units:
[0145] The scene testing unit is used to perform scene testing on each initial scene separately and obtain the scene test results for each initial scene.
[0146] The index determination unit is used to determine the minimum distance between the target vehicle and the obstacle as the test boundary index of the initial scenario, provided that the scenario test results indicate that the target vehicle has not collided.
[0147] As an optional embodiment, the scenario testing unit is specifically used for:
[0148] Obtain the number of parallel tests, which represents the number of scenarios that can be tested simultaneously.
[0149] The initial scenarios corresponding to the number of parallel tests are obtained sequentially and tested in parallel until each initial scenario is traversed, and the scenario test results of each initial scenario are obtained.
[0150] As an optional embodiment, the scene acquisition module 410 specifically includes the following units:
[0151] The scene generation unit is used to generate a basic scene corresponding to the target vehicle based on the scene description information corresponding to the target vehicle. The scene description information is used to describe the scene picture of the basic scene.
[0152] The scene generalization unit is used to generalize the basic scene to obtain at least one first generalized scene corresponding to the basic scene.
[0153] The second scene merging unit is used to merge the basic scene with the first generalized scene to obtain at least one initial scene corresponding to the target vehicle.
[0154] As an optional real-time example, scene parameters include scene elements, element behaviors of scene elements, and triggering events for element behaviors;
[0155] The scene generation unit is specifically used for:
[0156] Obtain scene description information corresponding to the target vehicle;
[0157] Based on the scene description information, determine the scene elements, element behaviors, and triggering events corresponding to the basic scene;
[0158] Bind related scene elements, element behaviors, and triggering events to generate scene parameters for the basic scene;
[0159] Based on the parameters of each scenario, a basic scenario corresponding to the target vehicle is generated.
[0160] As an optional embodiment, the scene generalization unit is specifically used for:
[0161] The initial parameter values of the element behaviors of each scene parameter in the basic scene are adjusted to obtain the parameter set of each element behavior. The parameter set includes the initial parameter values of the element behaviors and the generalized parameter values obtained by adjusting the initial parameter values.
[0162] By performing Cartesian product operations on the parameter sets of each element's behavior, multiple parameter combinations can be obtained;
[0163] Based on various parameter combinations, parameter values are set for the behavior of each element in the basic scenario to obtain at least one first generalized scenario corresponding to the basic scenario.
[0164] As an optional embodiment, after generalizing the basic scene to obtain at least one first generalized scene corresponding to the basic scene, the scene acquisition module 410 further includes the following units:
[0165] The scenario verification unit is used to perform rationality verification on each first generalized scenario according to preset rationality verification conditions, and obtain the verification results.
[0166] The scenario filtering unit is used to filter out the first generalized scenario whose verification result indicates that it does not meet the preset reasonableness verification conditions, and obtain the second generalized scenario.
[0167] The second scene merging unit is specifically used for:
[0168] The basic scenario and the second generalized scenario are merged to obtain at least one initial scenario corresponding to the target vehicle.
[0169] A method for determining simulation scenarios is provided. Accordingly, this application also provides specific embodiments of a device for determining simulation scenarios.
[0170] Figure 5 A schematic diagram of the hardware structure of the device for determining the simulation scenario provided in the embodiments of this application is shown.
[0171] The device for determining the simulation scene may include a processor 501 and a memory 502 storing computer program instructions.
[0172] Specifically, the processor 501 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.
[0173] Memory 502 may include mass storage for data or instructions. For example, and not limitingly, memory 502 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 502 may include removable or non-removable (or fixed) media. Where appropriate, memory 502 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 502 is non-volatile solid-state memory.
[0174] The processor 501 reads and executes computer program instructions stored in the memory 502 to implement any of the simulation scenario determination methods in the above embodiments.
[0175] In one example, the device for determining the simulation scenario may further include a communication interface 503 and a bus 510. Wherein, as... Figure 5 As shown, the processor 501, memory 502, and communication interface 503 are connected through bus 510 and complete communication with each other.
[0176] The communication interface 503 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.
[0177] Bus 510 includes hardware, software, or both, that couples components of a defined device in a simulation scenario together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 510 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.
[0178] Furthermore, in conjunction with the simulation scene determination method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the simulation scene determination methods in the above embodiments.
[0179] In addition, in conjunction with the simulation scene determination method in the above embodiments, this application embodiment can provide a computer program product to implement it. When the instructions in the computer program product are executed by the processor of an electronic device, the electronic device executes the simulation scene determination method provided by any aspect of the above embodiments of this application.
[0180] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.
[0181] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.
[0182] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.
[0183] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.
[0184] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.
Claims
1. A method for determining a simulation scene, characterized in that, include: Obtain at least one initial scene corresponding to the target vehicle. The initial scene includes multiple scene parameters for describing the scene. The initial scene includes at least one of the base scene of the target vehicle and a first generalized scene obtained by generalizing the base scene. Each initial scenario is tested to obtain a test boundary index for each initial scenario. The test boundary index is used to characterize the distance relationship between the target vehicle and obstacles other than the target vehicle in the initial scenario. Using the test boundary index as fitness, the genetic operators of the genetic algorithm are used to select, cross over and / or mutate the scene parameters of the initial scene to obtain at least one optimized scene; The initial scene is updated to the optimized scene, and the scene test is performed on each initial scene to obtain the test boundary index of each initial scene until the preset stopping condition is reached, so as to obtain at least one candidate scene. Candidate scenarios with fitness greater than a preset threshold are identified as target simulation scenarios that meet the performance boundary test requirements.
2. The method according to claim 1, characterized in that, The genetic operators include selection operators, crossover operators, and mutation operators; The step of using the test boundary index as fitness and employing genetic operators of a genetic algorithm to select, crossover, and / or mutate the scene parameters of the initial scene to obtain at least one optimized scene includes: Using the test boundary index as fitness, and according to the selection operator of the genetic algorithm, the first N initial scenarios are selected as parent simulation scenarios in descending order of fitness from each initial scenario, where N is a positive integer greater than or equal to 2. According to the crossover operator of the genetic algorithm, the scene parameters are exchanged between the parent simulation scenes to obtain at least one offspring simulation scene. According to the mutation operator of the genetic algorithm, the mutation operation of the scenario parameters is performed on the at least one offspring simulation scenario to obtain at least one mutated simulation scenario; The offspring simulation scenario and the mutation simulation scenario are merged to obtain the optimized scenario.
3. The method according to claim 1, characterized in that, The step of performing scenario testing on each of the initial scenarios to obtain the test boundary metrics for each initial scenario includes: Each initial scenario is tested separately to obtain the scenario test results for each initial scenario; If the scenario test results indicate that the target vehicle has not collided, the minimum distance between the target vehicle and the obstacle is determined as the test boundary index of the initial scenario.
4. The method according to claim 3, characterized in that, The step of performing scene tests on each of the initial scenes to obtain scene test results for each of the initial scenes includes: Obtain the number of parallel tests, which represents the number of scenarios that can be tested simultaneously. The initial scenarios corresponding to the number of parallel tests are sequentially obtained and tested in parallel until each initial scenario is traversed to obtain the scenario test results for each initial scenario.
5. The method according to any one of claims 1-4, characterized in that, The acquisition of at least one initial scene corresponding to the target vehicle includes: Based on the scene description information corresponding to the target vehicle, a basic scene corresponding to the target vehicle is generated, wherein the scene description information is used to characterize the scene scene of the basic scene; The basic scenario is generalized to obtain at least one first generalized scenario corresponding to the basic scenario; The basic scenario is merged with the first generalized scenario to obtain at least one initial scenario corresponding to the target vehicle.
6. The method according to claim 5, characterized in that, The scene parameters include scene elements, element behaviors of the scene elements, and triggering events for the element behaviors; The step of generating a basic scene corresponding to the target vehicle based on the scene description information corresponding to the target vehicle includes: Obtain scene description information corresponding to the target vehicle; Based on the scene description information, determine the scene elements, element behaviors, and triggering events corresponding to the basic scene; The associated scene elements, element behaviors, and triggering events are bound together to generate scene parameters for the basic scene; Based on the scene parameters, a basic scene corresponding to the target vehicle is generated.
7. The method according to claim 5, characterized in that, The generalization of the basic scenario to obtain at least one first generalized scenario corresponding to the basic scenario includes: The initial parameter values of the element behaviors of each scene parameter in the basic scene are adjusted to obtain the parameter set of each element behavior. The parameter set includes the initial parameter values of the element behaviors and the generalized parameter values obtained by adjusting the initial parameter values. A Cartesian product operation is performed between the parameter sets of each of the described element behaviors to obtain multiple parameter combinations; Based on various parameter combinations, parameter values are set for the behavior of each element in the basic scenario to obtain at least one first generalized scenario corresponding to the basic scenario.
8. The method according to claim 5, characterized in that, After generalizing the basic scenario to obtain at least one first generalized scenario corresponding to the basic scenario, the method further includes: Based on the preset rationality verification conditions, rationality verification is performed on each of the first generalized scenarios to obtain the verification results; The first generalized scenario that does not meet the preset reasonableness verification condition, as indicated by the verification result, is filtered out to obtain the second generalized scenario; The step of merging the basic scene with the first generalized scene to obtain at least one initial scene corresponding to the target vehicle includes: The basic scenario is merged with the second generalized scenario to obtain at least one initial scenario corresponding to the target vehicle.
9. A device for determining a simulation scene, characterized in that, include: A scene acquisition module is used to acquire at least one initial scene corresponding to the target vehicle. The initial scene includes multiple scene parameters for describing the scene. The initial scene includes at least one of the basic scene of the target vehicle and a first generalized scene obtained by generalizing the basic scene. The scene testing module is used to perform scene testing on each of the initial scenes to obtain the test boundary index of each initial scene. The test boundary index is used to characterize the distance relationship between the target vehicle and obstacles other than the target vehicle in the initial scene. The scene optimization module is used to select, crossover, and / or mutate the scene parameters of the initial scene using the test boundary index as the fitness and the genetic operators of the genetic algorithm to obtain at least one optimized scene. The loop test module is used to update the initial scene to the optimized scene and return to perform scene testing on each initial scene to obtain the test boundary index of each initial scene until a preset stopping condition is reached, thereby obtaining at least one candidate scene. The scenario determination module is used to determine the candidate scenarios with fitness greater than a preset threshold as target simulation scenarios that meet the performance boundary test requirements.
10. An electronic device, characterized in that, The device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the method for determining the simulation scene as described in any one of claims 1-8.
11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the method for determining a simulation scenario as described in any one of claims 1-8.