An automatic driving scene generation method, device, equipment and storage medium

Abstract

The application relates to an automatic driving scene generation method and device, equipment and a storage medium, which comprises the following steps: acquiring scene planning data based on a natural language description corresponding to an automatic driving scene to be created; screening a matched candidate road from a road index data set by using a road screening key of the scene planning data; determining a road connection path based on the candidate road and a turning intention of the scene planning data; and generating an automatic driving scene file based on the scene planning data and the road connection path. The application can solve the problem of low efficiency of manually editing a scene file in the prior art.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle testing and simulation technology, and in particular to an autonomous driving scenario generation method, device, equipment and storage medium. Background Technology

[0002] With the advancement of technology, people are paying more and more attention to autonomous driving technology. Autonomous driving has become a hot research field in recent years. However, due to factors such as complex and ever-changing traffic scenarios and high testing costs, traditional open road testing and closed test track testing are difficult to meet the stringent requirements of autonomous driving technology for reliability and robustness. Therefore, driving simulation based on digital virtual simulation technology has become one of the important means of autonomous driving simulation testing.

[0003] Currently, the main approach relies on manually writing scenario files, where engineers manually edit Open Scenario files (file extension .xosc) to describe each participant, behavior, and triggering logic. This manual editing method has many drawbacks, such as low efficiency, error-proneness, dependence on personal experience, and lack of scalability for large-scale and diverse needs. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for generating autonomous driving scenes, in order to solve the problem of low efficiency in manually editing scene files in related technologies.

[0005] In a first aspect, embodiments of this application provide a method for generating an autonomous driving scene, which includes:

[0006] Obtain scenario planning data based on the natural language description of the autonomous driving scenario to be created;

[0007] Using the key road selection criteria from the scenario planning data, matching candidate roads are selected from the road index data set;

[0008] Based on the candidate roads and the turning intentions in the scenario planning data, the road connection path is determined;

[0009] Based on the scenario planning data and road connection paths, an autonomous driving scenario file is generated.

[0010] In conjunction with the first aspect, in one implementation, a road index file is parsed to obtain the road index data set consisting of different roads and the road features corresponding to each road.

[0011] In conjunction with the first aspect, in one implementation, the road features include one or more of the following: road length, total number of left and right lanes, typical lane width, curvature statistics, typical speed limit, intersection type, and road type.

[0012] In conjunction with the first aspect, in one implementation, scene planning data is obtained based on the natural language description corresponding to the autonomous driving scene to be created, including:

[0013] The first language model is used to parse the input natural language description to obtain scene planning data.

[0014] In conjunction with the first aspect, in one implementation, after parsing and before obtaining scene planning data, the method further includes:

[0015] The first structural constraint is used to perform compliance verification on the parsed results.

[0016] If compliance verification fails, the first large language model is used to repair the parsed results in order to obtain the scenario planning data.

[0017] In conjunction with the first aspect, in one implementation, the scene planning data includes one or more of the following: scene name, duration, road selection key items, turning intention, participant list, and event timeline;

[0018] The key road selection criteria include one or more of the following: road length, total number of left and right lanes, typical lane width, curvature statistics, typical speed limit, intersection type, and road type.

[0019] In conjunction with the first aspect, in one implementation, using the road screening key items of the scene planning data, matching candidate roads are selected from the road index data set, including:

[0020] Obtain key road selection items from scene planning data, including numerical features and categorical features;

[0021] For each road in the road index dataset, calculate its similarity to the scene planning data;

[0022] The roads with the highest similarity in the road index dataset are selected as candidate roads for matching.

[0023] The calculation of similarity includes:

[0024] Using the roads in the road index data set as the roads to be matched and the roads expected by the scene planning data as the target roads, the normalized weighted distance of each numerical feature is obtained based on the absolute value of the difference between the numerical features of the target road and the roads to be matched, the normalization factor of the numerical features, and the weight coefficient.

[0025] Based on the inconsistency penalty function of categorical features between the target road and the road to be matched, and the weight coefficient of numerical features, the normalized weighted distance of each categorical feature is obtained.

[0026] Based on the normalized weighted distance of numerical features and the normalized weighted distance of categorical features, a normalized comprehensive weighted distance is obtained;

[0027] The difference between 1 and the normalized weighted distance is used as the similarity.

[0028] In conjunction with the first aspect, in one implementation, determining a road connection path based on the candidate roads and the turning intentions in the scene planning data includes:

[0029] Parse the road index file to obtain the road network connectivity, contact points, and geometric headings based on the start and end points of each candidate road;

[0030] Based on the road network connection relationship and contact points, the association relationship between each of the candidate roads is determined;

[0031] Based on the difference in geometric heading between two associated candidate roads and a preset heading threshold, the turning classification result between the two associated candidate roads is obtained.

[0032] The steering classification result and the steering intention Figure 1 Based on the criteria, a road connection path consisting of each of the candidate roads is obtained.

[0033] In conjunction with the first aspect, in one implementation, an autonomous driving scenario file is generated based on the scenario planning data and road connection paths, including:

[0034] The second language model is used to parse the input scene planning data and road connection paths to generate autonomous driving scene files.

[0035] In conjunction with the first aspect, in one implementation, after parsing and before generating the autonomous driving scenario file, the method further includes:

[0036] The second structural constraint is used to perform compliance verification on the parsed results.

[0037] If compliance verification fails, the second language model is used to repair the parsed results in order to generate an autonomous driving scenario file.

[0038] Secondly, embodiments of this application provide an autonomous driving scene generation device, the device comprising:

[0039] The language parsing module is used to obtain scene planning data based on the natural language description corresponding to the autonomous driving scene to be created;

[0040] The road filtering module is used to filter out matching candidate roads from the road index data set by utilizing the road filtering key items of the scene planning data.

[0041] A path connection module is used to determine the road connection path based on the candidate roads and the turning intentions of the scene planning data;

[0042] The file generation module is used to generate autonomous driving scenario files based on the scenario planning data and road connection paths.

[0043] Thirdly, embodiments of this application provide an autonomous driving scene generation device, which includes a processor, a memory, and an autonomous driving scene generation program stored in the memory and executable by the processor, wherein when the autonomous driving scene generation program is executed by the processor, it implements the steps of the autonomous driving scene generation method as described in any of the preceding claims.

[0044] Fourthly, embodiments of this application provide a computer-readable storage medium storing an autonomous driving scene generation program, wherein when the autonomous driving scene generation program is executed by a processor, it implements the steps of the autonomous driving scene generation method as described in any of the preceding claims.

[0045] The beneficial effects of the technical solution provided in this application include:

[0046] This application provides a method, apparatus, device, and storage medium for generating autonomous driving scenarios. By using structured processing of natural language descriptions, this application reduces manual editing costs and solves the problems of low efficiency, high professional knowledge requirements, and susceptibility to errors associated with manually writing scenario files. It automatically extracts key information from the natural language descriptions and matches them with road features, avoiding mismatches between road and steering caused by manual judgment. A road index-based filtering mechanism ensures logical consistency between the scenario description and road conditions, eliminating invalid scenarios caused by subjective interpretation differences. The automated process of generating driving scenarios from scratch reduces manual intervention, makes the scenario generation process repeatable, improves the accuracy and reliability of test scenarios, and provides a more realistic verification basis for autonomous driving systems. Attached Figure Description

[0047] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 This is a flowchart illustrating an embodiment of the autonomous driving scene generation method of this application;

[0049] Figure 2 This is a flowchart illustrating the JSON compliance verification process for this application.

[0050] Figure 3 This is a schematic diagram of the functional modules of an embodiment of the autonomous driving scene generation device of this application;

[0051] Figure 4 This is a schematic diagram of the hardware structure of the autonomous driving scene generation device involved in the embodiments of this application. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0053] First, some of the technical terms used in this application will be explained to help those skilled in the art understand this application.

[0054] ASAM OpenDRIVE: ASAM stands for "Automotive Software and Systems Modeling," an automotive industry standards organization dedicated to developing and maintaining standards related to automotive software and systems. OpenDRIVE is an open standard for virtual simulation scenarios designed to describe detailed information about road networks and scenarios, namely road index data (file extension .xodr), which is a static component of the simulation scenario to support the development and testing of autonomous driving and driver assistance systems.

[0055] The ASAM Open Scenario includes specifications and file schemas (file extension .xosc) for describing dynamic content in driving simulation applications.

[0056] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0057] The main methods for obtaining simulation scenarios in current autonomous driving simulation testing are as follows:

[0058] (1) Manually write scenario files. Engineers manually edit Open Scenario files (file extension .xosc), describing each participant, behavior, and triggering logic. The advantages are strong controllability and accessibility of details; the disadvantages are low efficiency, error-proneness, reliance on personal experience, and lack of scalability under large-scale and diverse requirements.

[0059] (2) Template-based parameter replacement. Many projects use existing .xosc file templates as the skeleton and only replace a few adjustable parameters (such as target speed and initial position). The advantage is that it is easy to use and has low reuse cost; the disadvantage is that the semantic expressiveness is insufficient, and the difference in the scenario is often only reflected in small numerical changes (such as "only change the speed"), which cannot fully cover the combination of "turning intention - road network connectivity - multi-entity interaction - triggering mechanism".

[0060] (3) Rule-based or script-based systems. The logic that can generate .xosc files is maintained through a rule base or scripting language. The advantage is that the expression can be extended within a certain range; the disadvantages are that the coupling between rules is complex, the maintenance cost is high, the migration across scenarios is difficult, and the consistency and debugging complexity of rules increase significantly with the expansion of scale.

[0061] In summary, the main problems are as follows:

[0062] (1) The conversion from natural language to structured scenarios lacks a stable, standardized, and reusable "translation chain".

[0063] (2) The problem of road network consistency is prominent: the template value cannot guarantee that the intention of "go straight / turn left / turn right" is consistent with the intersection connection relationship in the .xodr file, resulting in the behavior not being executed as expected.

[0064] (3) Insufficient compliance and compatibility: Problems such as non-compliant .xosc file structure, non-standard trigger expression or lane / position boundary violations can easily cause loading / running errors in simulators (such as esmini), resulting in high rework costs.

[0065] (4) Limited diversity: Under the paradigm of changing only a few parameters, it is difficult to form a sample set that is significantly different at both the road and behavioral structure levels.

[0066] In a first aspect, embodiments of this application provide a method for generating autonomous driving scenarios.

[0067] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the autonomous driving scene generation method of this application. Figure 1 As shown, the method for generating autonomous driving scenarios includes:

[0068] 101: Obtain scene planning data based on the natural language description corresponding to the autonomous driving scene to be created.

[0069] In step 101, the natural language description is the natural language used to describe the autonomous driving scenario to be created. For example, the natural language description could be "town road, located at an intersection, turning left; vehicle Ego initially 12m / s, 16m / s after 5s, changing lanes to the right after 12s".

[0070] Scene planning data is a structured description obtained from natural language descriptions, and it contains key information extracted from natural language descriptions.

[0071] For example, the scenario planning data may include one or more of the following: scenario name, duration, key road selection criteria, turning intention, participant list, and event timeline.

[0072] The key road selection criteria include one or more of the following: road length, total number of left and right lanes, typical lane width, curvature statistics, typical speed limit, intersection type, and road type. These key criteria are used to retrieve a set of elements for candidate road segments from the index.

[0073] Scene planning data can be in JSON file format, with the file extension .JSON.

[0074] 102: Using the road screening key items of the scenario planning data, select matching candidate roads from the road index data set.

[0075] In step 102, by using the road screening key item, candidate roads that match the natural language description can be selected from a large number of roads.

[0076] For example, one segment of the natural language description is: "Town road, located at an intersection, left turn; vehicle's initial speed is 12 m / s, 16 m / s after 5 seconds, lane change to the right after 12 seconds." From this, we can see that there is a left turn first, followed by a right turn. Therefore, in addition to the first road before the left turn, there is also a second road after the left turn and a third road after the right turn. For the first, second, and third roads, matching candidate roads can be selected from the road index dataset based on the corresponding road filtering keywords.

[0077] 103: Determine the road connection path based on the candidate roads and the turning intentions of the scene planning data.

[0078] In step 103, based on the turning intention, path planning is performed on each candidate road to obtain a road connection path formed by connecting each candidate road.

[0079] 104: Based on the scenario planning data and road connection paths, generate an autonomous driving scenario file.

[0080] This application addresses the problems of low efficiency, high expertise requirements, and high error rates associated with manually writing scenario files by structuring natural language descriptions, thus reducing manual editing costs. It automatically extracts key information from the natural language descriptions and matches them with road features, avoiding road and steering mismatches caused by manual judgment. A road index-based filtering mechanism ensures logical consistency between the scenario description and road conditions, eliminating invalid scenarios arising from subjective interpretations. The automated process of generating driving scenarios from scratch reduces manual intervention, making the scenario generation process repeatable, improving the accuracy and reliability of test scenarios, and providing a more realistic verification basis for autonomous driving systems.

[0081] Furthermore, in one embodiment, the road index file is parsed to obtain the road index data set consisting of different roads and the road features corresponding to each road.

[0082] The road index file mentioned above is in xodr file format, and its file extension is .xodr.

[0083] The road index dataset can be in JSON file format, with the file extension .JSON.

[0084] The road features can be divided into numerical features and categorical features. Numerical features include one or more of the following: road length, total number of left and right lanes, curvature statistics (including average absolute curvature and maximum absolute curvature), and typical speed limit values. Categorical features include one or more of the following: whether it is located at an intersection, intersection type (such as crossroads, T-junctions, etc.), and road type (such as expressway, national highway, rural road, etc.).

[0085] Parsing xodr files generates a structured road index dataset, transforming unstructured road data into a computable set of attributes, making it easier to accurately understand road geometry and traffic rules. Based on precise road features, the scene generation process can automatically match actual road conditions that match the description, avoiding logical inconsistencies in steering due to manual judgment. This structured index provides an objective basis for subsequent road selection, ensuring that the generated test scenarios conform to the real traffic environment at the road structure level, thus improving the effectiveness of the scenarios and the reliability of the test results.

[0086] Furthermore, in one embodiment, obtaining scene planning data based on the natural language description corresponding to the autonomous driving scene to be created includes: using a first large language model to parse the input natural language description to obtain scene planning data.

[0087] By leveraging the largest language model, complex semantic relationships within user intent can be accurately captured, transforming ambiguous natural language into precise structured data. This allows for high-fidelity conversion of natural language into structured scene planning data. Compared to manual conversion, the large language model provides a more comprehensive understanding of the logical connections within traffic scenarios, avoiding the omission or misinterpretation of crucial information. This semantic understanding-based conversion method preserves the complete intent of the original description, providing an accurate input foundation for subsequent road matching and scene generation. This makes the entire process more aligned with human thinking habits, lowers the professional threshold, and improves the logical consistency of scene construction.

[0088] Understandably, the primary language model could be a model like DeepSeek.

[0089] Furthermore, in one embodiment, after parsing the input natural language description using the first large language model and before obtaining the scene planning data, the method further includes:

[0090] The first structural constraint is used to perform compliance verification on the parsed results.

[0091] If compliance verification fails, the first large language model is used to repair the parsed results in order to obtain the scenario planning data.

[0092] Adding a structural constraint verification step can identify logical contradictions and format errors in the parsing results at an early stage, preventing invalid data from entering subsequent processes. For example, when semantic issues such as conflicts between turning intentions and road features are detected, a large language model is used for targeted repair, preserving the user's original intent while ensuring data compliance. This closed-loop mechanism improves the application's fault tolerance to natural language input, reduces invalid scenarios caused by semantic ambiguity, and makes the entire generation process more robust and reliable, handling complex and diverse descriptions without human intervention.

[0093] As an example, see Figure 2 As shown, the scene planning data uses a JSON file format with the .JSON extension. The JSON Schema, defined by structural constraints, can be used to perform compliance checks on the parsed results. If compliance checks fail, an "error list" is generated, and a closed-loop repair is performed using the first major language model until compliance checks succeed, thus obtaining the scene planning data. Alternatively, an upper limit can be set for the number of closed-loop repairs. When the upper limit is reached, regardless of whether compliance checks succeed, the result after the last closed-loop repair is used as the scene planning data.

[0094] Using JSON Schema for structured validation systematically identifies format and logical defects in scenario planning data, ensuring the integrity of key elements and compliance with industry standards. A closed-loop repair mechanism automatically corrects errors while preserving the user's original intent, preventing invalid data from entering subsequent processes. Setting a repair cap ensures the determinism of the processing, improving the application's adaptability to diverse inputs and ensuring the stable operation of the scenario generation process, providing a reliable data foundation for autonomous driving testing.

[0095] It should be noted that the structural constraint specification (JSON Schema) is a set of rules for verifying the structural consistency of the scenario planning data (JSON).

[0096] The error list is a structured list of issues discovered during the JSON compliance verification phase, including the issue type, location, and description.

[0097] Furthermore, in one embodiment, using the road screening key items of the scene planning data to filter matching candidate roads from the road index data set includes:

[0098] 201: Obtain key road selection parameters from the scene planning data, wherein the key road selection parameters include numerical features and categorical features;

[0099] 202: For each road in the road index dataset, calculate its similarity to the scene planning data;

[0100] The calculation of similarity includes:

[0101] Using the roads in the road index data set as the roads to be matched and the roads expected by the scene planning data as the target roads, the normalized weighted distance of each numerical feature is obtained based on the absolute value of the difference between the numerical features of the target road and the roads to be matched, the normalization factor of the numerical features, and the weight coefficient.

[0102] Based on the inconsistency penalty function of categorical features between the target road and the road to be matched, and the weight coefficient of numerical features, the normalized weighted distance of each categorical feature is obtained.

[0103] Based on the normalized weighted distance of numerical features and the normalized weighted distance of categorical features, a normalized comprehensive weighted distance is obtained;

[0104] The difference between 1 and the normalized weighted distance is used as the similarity.

[0105] 203: Select the roads with the highest similarity from the road index data set as matching candidate roads.

[0106] In this embodiment, the similarity between roads is calculated based on the weighted L1 distance (Manhattan distance). Similarity is defined as the complement of the distance; that is, the smaller the distance, the higher the similarity. Assume there are two road data points: target road A and road B to be matched.

[0107] Similarity between target road A and road B to be matched The calculation formula is:

[0108]

[0109] in, This is the normalized weighted distance, with values ​​ranging from [0, 1]. If the calculated... If the similarity is greater than 1, then the similarity is... It is 0.

[0110] Normalized weighted distance The calculation formula is:

[0111]

[0112] : Indicates the first of the key items in the road screening. The values ​​of each numerical feature on target road A and road B to be matched are given. n represents the total number of numerical features in the road selection criteria. These numerical features include: road length, total number of left and right lanes, typical lane width, average absolute curvature, and typical speed limit. =1, 2, ..., n.

[0113] Indicates the first A normalization factor for a numerical feature, used to eliminate the influence of different feature dimensions. Its value is usually taken as the maximum tolerance range allowed for the feature in the application scenario or the standard deviation of historical data.

[0114] : Indicates the first of the key items in the road screening. The values ​​of each categorical feature on target road A and road B to be matched. m represents the total number of categorical features in the road filtering keywords, including: whether it is located at an intersection, intersection type, and road type. =1, 2, ..., m.

[0115] : Represents the inconsistency penalty function for categorical features. When hour, ;when hour, It can also be set to other constants according to business needs.

[0116] : Indicates the first of the key items in the road screening. The weight coefficients corresponding to the numerical features and the first key item in road selection The weight coefficients corresponding to each categorical feature are such that the sum of all weight coefficients equals 1.

[0117] As an example, assuming this embodiment focuses more on the topological shape of the road and speed limit information, the weighting coefficients and normalization factors are set as follows:

[0118] Road length weight 0.1, Road length normalization factor 100 meters.

[0119] Weight of total number of left and right lanes 0.2, normalization factor for the total number of left and right lanes 4 items.

[0120] Mean Absolute Curvature Weight 0.3, mean absolute curvature normalization factor :0.05(1 / m).

[0121] Typical speed limit weight 0.2, typical speed limit normalization factor 40km / h.

[0122] Road type weight 0.2.

[0123] The feature data of target road A and road B to be matched are compared in the table below:

[0124]

[0125] Calculate the normalized weighted distance for each numerical or categorical feature:

[0126] Road length and distance: =0.1×10 / 100=0.01

[0127] Total distance between left and right lanes: =0.2×0 / 4=0

[0128] Mean absolute curvature distance: =0.3 × 0.003 / 0.05 = 0.018

[0129] Typical speed limit distance: =0.2×10 / 40=0.05

[0130] Road type penalty distance: =0.2×0=0

[0131] Normalized weighted distance for:

[0132] = + + + + =0.01+0+0.018+0.05+0=0.078

[0133] The final similarity is: =1-0.078=0.922.

[0134] Based on the above calculations, the overall similarity between target road A and road B to be matched is 0.922 (i.e., 92.2%). This value is close to 1, indicating that the two roads have highly similar features and belong to a high-confidence match.

[0135] Further, in one embodiment, determining the road connection path based on the candidate roads and the turning intentions in the scene planning data includes:

[0136] 301: Parse the road index file to obtain the road network connectivity, contact points, and geometric headings based on the start and end points of each candidate road.

[0137] 302: Based on the road network connection relationship and contact points, determine the association relationship between each of the candidate roads.

[0138] 303: Based on the difference in geometric heading between the two associated candidate roads and a preset heading threshold, obtain the turning classification result between the two associated candidate roads.

[0139] 304: Based on the stated steering classification result and the stated steering intention Figure 1 Based on the criteria, a road connection path consisting of each of the candidate roads is obtained.

[0140] Turning intention refers to directional preference at intersections or connections (such as going straight / turning left / turning right).

[0141] Steps 301-304 perform turn classification, and then connect the candidate roads according to the turn intention to form a road connection path. Specifically, the turn classification process includes: parsing the planView / geometry elements of the OpenDRIVE road index file to estimate the geometric headings of the road start / end point; determining the association between the candidate roads based on the link / junction road network connection relationship and contactPoint, marking the "entry point" and "exit point" of the current road segment in two associated candidate roads; calculating the difference Δθ between the geometric heading of the current road segment end point and the geometric headings of the start / end point of the connecting road segment, and normalizing Δθ to ( (π, π); Δθ is determined based on a preset heading threshold to obtain a straight / left turn / right turn classification result. The preset heading threshold can be configured in conjunction with the road dispersion and simulator tolerance; when there are multiple connectable road segments, the consistency between the classification result and the "turning intention" is used as the priority criterion for selecting the connecting path.

[0142] This example uses mathematically calculated steering classification to ensure that "left turns described in natural language" correspond to "left turns that can actually be performed on the road," and that the consistency between steering intentions (straight / left turn / right turn) and .xodr intersection connections / geometric headings avoids the generation of invalid test scenarios.

[0143] Furthermore, in one embodiment, generating an autonomous driving scenario file based on the scenario planning data and road connection paths includes: using a second language model to parse the input scenario planning data and road connection paths to generate an autonomous driving scenario file.

[0144] By leveraging a large language model to parse scene planning data and road connection paths, .xosc autonomous driving scene files are generated from scratch. This approach accurately understands the semantic logic of complex traffic scenarios, transforming structured data into scene files that conform to industry standards. Compared to traditional template-filling methods, the large language model can flexibly handle diverse road connection relationships, ensuring that the generated files conform to standards at both the syntactic and semantic levels. This semantic understanding-based generation method avoids the professional barriers of manual coding, improves the logical consistency and structural integrity of scene files, and makes test scenarios closer to real-world traffic environments.

[0145] Understandably, the second largest language model could be a model like Gemini 3 Pro.

[0146] In this example, an autonomous driving scene file (.xosc) is generated from scratch using the second largest language model. This file includes the head, road connection paths, entities (performance / shape (e.g., vehicle type, size) / axle system (e.g., wheelbase, wheel position)), initial phase (absolute / relative positioning, including initial speed), event timeline (speed / lane change / speed curve / optional longitudinal control), and triggers (simulation time or relative distance). External references irrelevant to execution are removed, such as references to external scene libraries, materials, and textures; only .xodr relative path references are retained.

[0147] Absolute positioning is expressed as (road sign, lane sign, longitudinal position); lateral offset is 0.0 by default; longitudinal position must be within [0, length]. [Safety Margin] Internal clipping.

[0148] Relative positioning: expressed as (reference entity, longitudinal / lateral displacement); the reference entity must be initialized before the referenced entity.

[0149] Lane selection: Prioritize driving lanes and try to stay as close to the center as possible; if the target lane does not exist, select the nearest compliant driving lane.

[0150] Speed ​​control: Set a new speed target at a given moment, using either step or smooth dynamics.

[0151] Lane change control: Switch to the target lane at a given time, with a recommended duration of ≥ 2 seconds.

[0152] Speed ​​curve: Expand the (time-speed) point column into multiple speed control segments.

[0153] Longitudinal control (optional): Configure key parameters such as following distance and time interval as attributes, and explicitly enable the longitudinal channel.

[0154] Triggering: Prioritize simulation time triggering, and use relative distance triggering when necessary (optional free space or entity envelope determination).

[0155] Furthermore, in one embodiment, after parsing and before generating the autonomous driving scenario file, the method further includes:

[0156] The second structural constraint is used to perform compliance verification on the parsed results.

[0157] If compliance verification fails, the second language model is used to repair the parsed results in order to generate an autonomous driving scenario file.

[0158] Adding a structural constraint verification step before generating autonomous driving scenario files can identify and correct potential format and logical errors in advance, preventing invalid scenarios from entering the testing process. For example, when problems such as mismatch between steering paths and road structures are detected, intelligent repair is performed using a large language model, ensuring file compliance while maintaining the original testing intent. This closed-loop repair approach reduces the need for manual debugging, improves the quality consistency of scenario files, makes the generated test scenarios more consistent with actual road conditions and industry standards, and enhances the credibility of test results.

[0159] It is understandable that the above parsing results and autonomous driving scenario files can be .xosc files, and the second structural constraint specification can be an XML rule set. The XML rule set is used to perform XSD compliance verification on the parsed results.

[0160] If compliance verification fails, a second language model can be used for closed-loop repair until compliance verification succeeds, at which point the autonomous driving scenario file can be obtained. Alternatively, an upper limit can be set for the number of closed-loop repair attempts. Once the upper limit is reached, regardless of whether compliance verification succeeds, the result of the last closed-loop repair will be used as the autonomous driving scenario file.

[0161] Secondly, embodiments of this application also provide an autonomous driving scene generation device.

[0162] In one embodiment, reference is made to Figure 3 , Figure 3 This is a functional module diagram of an embodiment of the autonomous driving scene generation device of this application. Figure 3 As shown, the autonomous driving scene generation device includes:

[0163] The language parsing module is used to obtain scene planning data based on the natural language description corresponding to the autonomous driving scene to be created.

[0164] The road filtering module is used to filter matching candidate roads from the road index data set by utilizing the road filtering key items of the scenario planning data.

[0165] The path connection module is used to determine the road connection path based on the candidate roads and the turning intentions of the scene planning data.

[0166] The file generation module is used to generate autonomous driving scenario files based on the scenario planning data and road connection paths.

[0167] Furthermore, in one embodiment, the autonomous driving scene generation device further includes a road index parsing module, used to parse the road index file to obtain the road index data set composed of different roads and the road features corresponding to each road.

[0168] Furthermore, in one embodiment, the language parsing module is used to obtain scene planning data based on the natural language description corresponding to the autonomous driving scene to be created. Specifically, it includes using a first language model to parse the input natural language description in order to obtain scene planning data.

[0169] Furthermore, in one embodiment, the language parsing module is also used to perform compliance verification on the parsing result using the first structural constraint specification after parsing and before obtaining the scene planning data; if the compliance verification fails, the parsing result is repaired using the first large language model to obtain the scene planning data.

[0170] Further, in one embodiment, the path connection module is used to determine the road connection path based on the candidate roads and the turning intention of the scene planning data, specifically including: parsing the road index file to obtain the road network connection relationship, contact point, and geometric heading based on the start and end points of each candidate road; determining the association relationship between each candidate road based on the road network connection relationship and contact point; obtaining the turning classification result between two associated candidate roads based on the difference in geometric heading between two associated candidate roads and a preset heading threshold; and comparing the turning classification result with the turning intention... Figure 1 Based on the criteria, a road connection path consisting of each of the candidate roads is obtained.

[0171] Furthermore, in one embodiment, the file generation module is used to generate an autonomous driving scenario file based on the scenario planning data and road connection paths, specifically including: using a second language model to parse the input scenario planning data and road connection paths to generate an autonomous driving scenario file.

[0172] Furthermore, in one embodiment, the file generation module is also used to perform compliance verification on the parsing result using the second structural constraint specification after parsing and before generating the autonomous driving scenario file; if the compliance verification fails, the second large language model is used to repair the parsing result in order to generate the autonomous driving scenario file.

[0173] The functions of each module in the above-mentioned autonomous driving scenario generation device correspond to the steps in the above-mentioned autonomous driving scenario generation method embodiment, and their functions and implementation processes will not be described in detail here.

[0174] Thirdly, embodiments of this application provide an autonomous driving scene generation device, which can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0175] Reference Figure 4 , Figure 4 This is a schematic diagram of the hardware structure of the autonomous driving scene generation device involved in the embodiments of this application. In the embodiments of this application, the autonomous driving scene generation device may include a processor, a memory, a communication interface, and a communication bus.

[0176] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0177] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components of the autonomous driving scenario generation device, as well as interfaces used for interconnecting the autonomous driving scenario generation device with other devices (such as other computing devices or user devices). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user devices can be displays, keyboards, etc.

[0178] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0179] The processor can be a general-purpose processor, which can call the autonomous driving scene generation program stored in the memory and execute the autonomous driving scene generation method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the autonomous driving scene generation program is called can be referred to in the various embodiments of the autonomous driving scene generation method of this application, and will not be repeated here.

[0180] Those skilled in the art will understand that Figure 4 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0181] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0182] The present application provides a computer-readable storage medium storing an autonomous driving scene generation program, wherein when the autonomous driving scene generation program is executed by a processor, it implements the steps of the autonomous driving scene generation method described above.

[0183] The method implemented when the autonomous driving scene generation program is executed can be referred to in various embodiments of the autonomous driving scene generation method of this application, and will not be repeated here.

[0184] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0185] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0186] In the description of the embodiments in this application, terms such as "exemplary," "for example," or "for example" are used to indicate that they are examples, illustrations, or explanations. Any embodiment or design that is described as "exemplary," "for example," or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a specific manner.

[0187] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0188] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0189] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0190] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An automatic driving scenario generation method, characterized by, It includes: Based on the natural language description of the autonomous driving scenario to be created, obtain scenario planning data; Using the key road selection criteria from the scenario planning data, matching candidate roads are selected from the road index data set; Based on the candidate roads and the turning intentions in the scenario planning data, the road connection path is determined; Based on the scenario planning data and road connection paths, an autonomous driving scenario file is generated; The process of using the road selection key items from the scenario planning data to select matching candidate roads from the road index data set includes: Obtain key road selection items from scene planning data, including numerical features and categorical features; For each road in the road index dataset, calculate its similarity to the scene planning data; The roads with the highest similarity in the road index dataset are selected as candidate roads for matching. The calculation of similarity includes: Using the roads in the road index data set as the roads to be matched and the roads expected by the scene planning data as the target roads, the normalized weighted distance of each numerical feature is obtained based on the absolute value of the difference between the numerical features of the target road and the roads to be matched, the normalization factor of the numerical features, and the weight coefficient. Based on the inconsistency penalty function of categorical features between the target road and the road to be matched, and the weight coefficient of numerical features, the normalized weighted distance of each categorical feature is obtained. Based on the normalized weighted distance of numerical features and the normalized weighted distance of categorical features, a normalized comprehensive weighted distance is obtained; The difference between 1 and the normalized weighted distance is used as the similarity score. The process of determining road connection paths based on the candidate roads and the turning intentions in the scene planning data includes: Parse the road index file to obtain the road network connectivity, contact points, and geometric headings based on the start and end points of each candidate road; Based on the road network connection relationship and contact points, the association relationship between each of the candidate roads is determined; Based on the difference in geometric heading between two associated candidate roads and a preset heading threshold, the turning classification result between the two associated candidate roads is obtained. Based on the criterion that the turning classification result is consistent with the turning intention, a road connection path composed of each of the candidate roads is obtained.

2. The autonomous driving scene generation method as described in claim 1, characterized in that: Parse the road index file to obtain the road index data set, which consists of different roads and the road features corresponding to each road.

3. The autonomous driving scene generation method as described in claim 2, characterized in that: The road features include one or more of the following: road length, total number of left and right lanes, typical lane width, curvature statistics, typical speed limit, intersection type, and road type.

4. The automatic driving scenario generation method of claim 1, wherein, Based on the natural language description of the autonomous driving scenario to be created, obtain scenario planning data, including: The first language model is used to parse the input natural language description to obtain scene planning data.

5. The autonomous driving scene generation method as described in claim 4, characterized in that, After parsing and before obtaining scene planning data, the method further includes: The first structural constraint is used to perform compliance verification on the parsed results. If compliance verification fails, the first large language model is used to repair the parsed results in order to obtain the scenario planning data.

6. The autonomous driving scene generation method as described in claim 4, characterized in that: The scenario planning data includes one or more of the following: scenario name, duration, key road selection items, turning intention, list of participants, and event timeline. The key road selection criteria include one or more of the following: road length, total number of left and right lanes, typical lane width, curvature statistics, typical speed limit, intersection type, and road type.

7. The automatic driving scenario generation method of claim 1, wherein, Based on the scenario planning data and road connection paths, an autonomous driving scenario file is generated, including: The second language model is used to parse the input scene planning data and road connection paths to generate autonomous driving scene files.

8. The automatic driving scene generation method of claim 7, wherein, After parsing and before generating the autonomous driving scenario file, the method further includes: The second structural constraint is used to perform compliance verification on the parsed results. If compliance verification fails, the second language model is used to repair the parsed results in order to generate an autonomous driving scenario file.

9. An autonomous driving scene generation device, characterized in that, The device includes: The language parsing module is used to obtain scene planning data based on the natural language description corresponding to the autonomous driving scene to be created; The road filtering module is used to filter matching candidate roads from a road index data set using road filtering key items from the scene planning data. Specifically, it includes: obtaining road filtering key items from the scene planning data, whereby the road filtering key items include numerical features and categorical features; calculating the similarity between each road in the road index data set and the scene planning data; and filtering out the road with the highest similarity in the road index data set as a matching candidate road. The similarity calculation includes: using roads in the road index data set as the roads to be matched, and... The expected road in the landscape planning data is used as the target road. Based on the absolute difference of numerical features between the target road and the road to be matched, the normalization factor of the numerical features, and the weight coefficient, the normalized weighted distance of each numerical feature is obtained. Based on the inconsistency penalty function of categorical features between the target road and the road to be matched and the weight coefficient of the numerical features, the normalized weighted distance of each categorical feature is obtained. Based on the normalized weighted distance of the numerical features and the normalized weighted distance of the categorical features, the normalized comprehensive weighted distance is obtained. The difference between 1 and the normalized comprehensive weighted distance is taken as the similarity. The path connection module is used to determine the road connection path based on the candidate roads and the turning intention of the scene planning data. Specifically, it includes: parsing the road index file to obtain the road network connection relationship, contact point, and geometric heading based on the start and end points of each candidate road; determining the association relationship between each candidate road based on the road network connection relationship and contact point; obtaining the turning classification result between two associated candidate roads based on the difference in geometric heading between two associated candidate roads and a preset heading threshold; and obtaining the road connection path composed of each candidate road based on the consistency between the turning classification result and the turning intention. The file generation module is used to generate autonomous driving scenario files based on the scenario planning data and road connection paths.

10. An autonomous driving scene generation device, characterized in that, The autonomous driving scene generation device includes a processor, a memory, and an autonomous driving scene generation program stored in the memory and executable by the processor, wherein when the autonomous driving scene generation program is executed by the processor, it implements the steps of the autonomous driving scene generation method as described in any one of claims 1 to 8.

11. A computer readable storage medium, characterized in that, The computer-readable storage medium stores an autonomous driving scene generation program, wherein when the autonomous driving scene generation program is executed by a processor, it implements the steps of the autonomous driving scene generation method as described in any one of claims 1 to 8.

Images