Port test scene generation method

Abstract

The invention relates to the technical field of port test scene generation, in particular to a port test scene generation method, which comprises the following steps: S1, determining the grade of an automatic driving algorithm of a tested port container truck; s2, determining a port area included in a test range, splitting a port area container truck daily operation process, and designing a test scene according to a coverage area and the container truck operation process; s3, compiling python codes, and carrying out conditional constraint and permutation and combination on derivative parameters according to scene coverage requirements; and S4, generating an xml scene file by using a python program, and verifying the scene file on a simulation platform. The method for generating the openSCENARIO format test scene of the port automatic driving technology test through the python language has the advantages that compared with a port real road test, the method has the advantages that the test period is shortened, and the test cost is reduced; the operation process is split, and the scene design is scientific and reasonable; the scene making efficiency is improved, and the derivation mode is convenient and fast.

Description

Technical Field

[0001] The invention relates to the technical field of port test scene generation, and in particular to a port test scene generation method. Background Art

[0002] At present, as the frontier where the automotive industry and computer science meet, autonomous driving technology is leading the profound changes in the automotive industry and even the entire transportation field at an unprecedented speed. Especially in the special and complex operating environment of ports, the application of autonomous driving technology is regarded as a key way to improve operational efficiency, ensure personnel safety, and optimize resource allocation. With the continuous development of port autonomous driving technology, major manufacturers and scientific research institutions have invested heavily to develop distinctive port container truck autonomous driving planning, high-precision perception and intelligent decision-making algorithms, striving to gain an advantage in this frontier position of ports.

[0003] However, in the face of the high dynamics, high complexity and high risk of the port environment, the ability of real road testing is particularly insufficient and it is difficult to meet the growing needs of algorithm verification and iterative optimization. In this context, simulation testing, with its advantages of high efficiency, safety and controllability, has gradually become an indispensable means for the development and verification of port autonomous driving technology. As a result, a variety of simulation platforms and software have emerged in the market, providing strong support for the development of port autonomous driving technology.

[0004] However, the diversity and technical barriers among these simulation platforms, especially the lack of standardization of scene definition and description, and the non-uniformity of data transmission methods, have seriously restricted the efficient use and cross-platform sharing of simulation test resources. In order to break this bottleneck, the German Association for Standardization of Automation and Measuring Systems (ASAM) timely launched the OpenX series of standards. Among them, the OpenSCENARIO standard defines in detail the full range of scene descriptions from environmental factors such as weather and lighting to dynamic elements such as vehicles, pedestrians, mechanical equipment and traffic lights. It greatly improves the coverage of test cases and the authenticity and value of test scenarios, laying a solid foundation for the comprehensive verification and continuous optimization of autonomous driving systems.

[0005] Although field testing and verification of port autonomous driving algorithms have begun in some modern intelligent ports, due to various limitations of real roads and environmental factors, there are still problems, including but not limited to the following:

[0006] 1. Uncontrollable environmental factors. The port environment is complex and may experience weather conditions such as rain, snow, and fog. The emergence of natural factors is difficult to control artificially, resulting in a relatively long test cycle.

[0007] 2. Singleness of road testing. To avoid affecting the normal operation of the port, port road testing is generally carried out in specific areas or routes. This results in the test content being incomplete and it is difficult to fully cover the working conditions of autonomous container trucks operating in the port area.

[0008] 3. Road test cost and safety issues. There are many expensive large equipment and vehicles in the port area. If an accident occurs during the test, it may cause significant property and personnel losses.

[0009] 4. Imperfect infrastructure and communication equipment. Some ports lack key equipment such as V2X and IoT communication base stations. In port autonomous driving tests, the problem of multi-vehicle collaborative operation also needs to be considered. Due to the lack of equipment, it is difficult for the autonomous driving system to achieve real-time and efficient communication and coordination with other vehicles and port facilities, thus affecting the overall operation efficiency and safety.

[0010] With the development of autonomous driving simulation technology, we can fully migrate the port's autonomous driving algorithm testing to advanced simulation platforms. On the simulation platform, we can not only easily simulate a variety of weather conditions according to test requirements, but also conduct tests on the challenging working conditions encountered by port container trucks at a very low cost and risk. Simulate the real scene of multi-vehicle collaborative operation. These advantages not only help to verify the performance of autonomous driving algorithms in port operations, but also accelerate the iteration and optimization process of the algorithm, and improve test efficiency and accuracy.

[0011] The scenes in the OpenSCENARIO format solve the problems of uniformity and standardization, but if used for the production of port scenes, there are still problems such as limited software support, difficulty in describing complex scenes, and inconvenient editing of file contents in XML format. Companies generally develop graphical editors, but this requires developers to work hard in multiple dimensions such as user interface design, back-end logic construction, and data model optimization, and the development cycle is long. However, before the editor matures and is widely used, the direct editing of XML files, although giving users extremely high flexibility and customization space, is also particularly inefficient and error-prone. Therefore, it is particularly urgent and critical to explore and practice an efficient method that can quickly generate OpenSCENARIO scenes for port autonomous driving technology testing. Summary of the invention

[0012] In order to overcome the technical defects in the prior art, optimize the production and editing process of the OpenSCENARIO scene for port autonomous driving technology testing, and effectively solve the technical problems in the background technology, the present invention provides the following technical solutions:

[0013] A method for generating a port test scenario, characterized in that it comprises the following steps:

[0014] S1: Determine the algorithm level:

[0015] Clarify the level of the tested port container truck autonomous driving algorithm in the automatic algorithm level, and clarify the production specifications of the scene according to the algorithm level;

[0016] S2: Design test scenarios after clarifying the test scope:

[0017] Clarify the port areas covered by the test scope, split the daily operation process of container trucks in the port area, and design the test scenarios according to the coverage area and container truck operation process;

[0018] S3: Python code writing:

[0019] By calling the function modules in the scenario generation tool library, the Python code is written according to the level of the intelligent driving standard, and the conditional constraints and permutations of the derived parameters are performed according to the scenario coverage requirements;

[0020] S4: Generate xosc file and verify:

[0021] Use Python program to generate XML scene files and verify the scene files on the simulation platform.

[0022] As a preferred technical solution of the present invention, in S3, when designing the working conditions, different actions and timings to be applied in the storyboard can be reasonably selected according to the test requirements.

[0023] As a preferred technical solution of the present invention, in S4, the verification process includes:

[0024] (1) The action of the target vehicle in the scene is consistent with the design content;

[0025] (2) The vehicles in the scene are driving correctly on the road network;

[0026] (3) There is no interpenetration between entities in the scene;

[0027] (4) The entities in the scene do not violate the laws of physics;

[0028] If the above conditions are met, the scene verification is completed; if not, the scene file is regenerated by modifying the Python code for re-verification.

[0029] Compared with the prior art, the present invention has the following beneficial effects: the present invention provides a method for generating openSCENARIO format test scenarios for port autonomous driving technology testing using Python language, which has the following significant advantages over real road testing in port areas:

[0030] 1. Shorten the test cycle and reduce the test cost:

[0031] Migrating the test environment from the real port area to the simulation platform has enabled all-weather, uninterrupted simulation testing without relying on expensive container trucks and physical equipment in the port area. This not only ensures the effectiveness of the test, but also greatly shortens the test cycle and effectively reduces the test cost.

[0032] 2. Split the operation process and design the scene scientifically and reasonably:

[0033] By breaking down the daily operating procedures of large container trucks at ports, we fully cover the working conditions encountered by self-driving container trucks during operation, classify the working conditions scientifically and rationally, and ensure the objectivity of subsequent test analysis results.

[0034] 3. Improve scene production efficiency and make the derivation method convenient and fast:

[0035] Avoid the long period of time required to develop graphical editing tools. Instead, you can quickly create, modify, and derive scene files by editing simple Python programs.

[0036] The concise Python syntax is used to flexibly build a conditional constraint framework, realize automatic permutation and combination of parameters, and batch generate high-coverage, high-quality derivative scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 It is a flow chart of the present invention. DETAILED DESCRIPTION

[0038] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0039] See also Figure 1 The present invention provides a technical solution: a method for generating a port test scenario, characterized in that it comprises the following steps:

[0040] S1: Determine the algorithm level:

[0041] It is necessary to clarify the level of the tested port container truck autonomous driving algorithm in the automatic algorithm level, and clarify the production specifications of the scene according to the algorithm level. Specifically, the level classification of autonomous driving technology follows the standards set by the Society of Automotive Engineers (SAE), which divides autonomous driving into six levels from L0 (no automation) to L5 (full automation), for example:

[0042] (1) The L0 level autonomous driving algorithm for port areas only includes the warning function of identifying obstacles ahead (1) The L0 level autonomous driving algorithm needs to control the main vehicle in the scene horizontally and vertically to ensure the correct occurrence of the working condition);

[0043] (2) L3-level autonomous driving algorithms in port areas can realize autonomous driving of container trucks in the port area, but manual takeover is required at any time (autonomous driving algorithms above L3 levels are not allowed to perform any control over the main vehicle in the scene);

[0044] (3) The L4-level autonomous driving algorithm in the port area can realize fully autonomous driving of container trucks in the port area without the need for manual control;

[0045] The level of the test algorithm can determine key factors such as the design of the specific test scenario, whether the main vehicle is controlled in the scenario, and the specific evaluation criteria for subsequent tests.

[0046] S2: Design test scenarios after clarifying the test scope:

[0047] The scope of the test should clearly define the port areas (including the dock surface, container area, guide roads, container area, container area roads, access roads, parking lots, refueling areas, etc.), split the daily operation process of container trucks in the port area, and design test scenarios based on the coverage area and container truck operation process, for example:

[0048] (1) Enter the port via the access road (via the ramp);

[0049] (2) Entering the container road and dock surface road to load and unload containers (positioning parking);

[0050] (3) Parking area / charging area driving ability (parallel / vertical parking);

[0051] (4) Driving ability on port-oriented roads (following, meeting, and obstacle avoidance capabilities);

[0052] (5) Driving in bad weather (bad weather algorithm perception capability).

[0053] Specifically, after determining the level of the port autonomous driving algorithm (for example, a level between L0 and L4) and the test scope, using map software to draw the port road network will help the test team have an intuitive understanding of the test environment and provide accurate spatial information for subsequent test scenario design.

[0054] After the port road network is mapped and the driving range of the test vehicle is determined, the next step is to design the test scenario. The design of the test scenario is a key step to ensure that the autonomous driving algorithm can fully accept the challenge and verify its performance. At this stage, it is necessary to summarize and classify the various challenges that autonomous driving vehicles may face in the port area, including but not limited to perception, driving decision-making, oncoming vehicle interaction, edge case challenges, etc., in order to conduct scientific and comprehensive testing, as well as the analysis and interpretation of the test results after the test is completed.

[0055] After clarifying the test scope and designing the test scenarios, a series of physical models that are essential in the process of making these scenarios can be identified. These models include but are not limited to: containers, gantry cranes, bridge cranes, gas stations and other port-specific facilities and equipment. After the modeling is completed, these models will be properly placed in the catalog (i.e., model library or resource library) to facilitate quick call and combination in the subsequent scene production process.

[0056] S3: Python code writing:

[0057] By calling the function modules in the scenariogeneration / xosc (scenario generation tool) library, the Python code is written according to the level of openSCENARIO (intelligent driving standard), and the conditional constraints and permutations of the derived parameters are performed when designing the working conditions according to the scenario coverage requirements:

[0058] (1) Conditional constraints: constrain the parameters of the target vehicle, such as limiting the maximum and minimum speeds of the target vehicle, limiting the speed of target vehicle 1 to no greater than that of target vehicle 2, etc.

[0059] (2) Permutation and combination: Under the condition of satisfying the parameter constraints, python / product is used to generate all possible parameter combinations. Each combination is the working condition parameter of the derived scenario.

[0060] Specifically, the method of generating openSCENARIO (intelligent driving standard) in Python language is mainly to call the functional modules in the scenariogeneration / xosc (scenario generation tool) library, and write codes corresponding to the road network, directory, storyboard and other levels of openSCENARIO. For example, the method of writing a storyboard is as follows:

[0061] Eg1: The container truck in front drives to the operation area and stops to load;

[0062] (1) Action: Use AbsoluteSpeedAction to write the action of decelerating the target vehicle to a stop;

[0063] (2) Trigger: Use ReachPositionCondition to specify that the target vehicle drives to a certain position to trigger the action;

[0064] Eg2: The truck in front of the left lane cuts in front of the main vehicle;

[0065] (1) Action: Write the lane change action to the target vehicle through RelativeLaneChangeAction;

[0066] (2) Trigger: Use TimeToCollisionCondition to specify that the action is triggered when the TTC between the test vehicle and the target vehicle is less than a certain value;

[0067] Eg3. The oncoming lane is stuck at the intersection

[0068] (1) Action: Write the target vehicle’s U-turn trajectory through FollowTrajectoryAction;

[0069] (2) Trigger: Use SimulationTimeCondition to specify how many seconds after the scene starts that the target vehicle turns around according to the trajectory.

[0070] In addition to writing the basic hierarchical structure of openSCENARIO, the xosc file generated by Python can also be used to directly derive the working parameters of the scene and add constraints to ensure the coverage and rationality of the derived scene parameters.

[0071] S4: Generate xosc file and verify:

[0072] Use Python program to generate XML scene files and verify the scene files on the simulation platform.

[0073] Furthermore, in S3, when designing working conditions, you can reasonably choose different actions and triggers to apply in the storyboard according to the test requirements. The two are classified as follows:

[0074] (1) Action:

[0075] userdefifineaction: user-defined action, such as calling the interface to open or close the doors and lights;

[0076] LateralDistanceAction: lateral distance action, such as lane change, lane departure, etc.;

[0077] longitudinalaction: longitudinal action, such as acceleration and deceleration;

[0078] Routingactions: trajectory control actions, specifying the movement trajectory of the entity by marking points;

[0079] Controller: Controller-related actions, such as activating a controller or assigning a controller.

[0080] (2) Trigger:

[0081] EntityTrigger: Triggered by determining that an entity meets a certain condition, such as the main vehicle reaches a certain position, the TTC between the main vehicle and the preceding vehicle is less than a certain value, the main vehicle speed is greater than a certain value, etc.

[0082] ValueTrigger: Triggered by reaching a certain numerical condition, such as the scene simulation time or other user-defined numerical conditions.

[0083] Furthermore, in S4, the verification process includes:

[0084] (1) The action of the target vehicle in the scene is consistent with the design content;

[0085] (2) The vehicles in the scene are driving correctly on the road network;

[0086] (3) There is no interpenetration between entities in the scene;

[0087] (4) The entities in the scene do not violate the laws of physics, such as suddenly appearing and disappearing, or experiencing sudden changes in speed, etc.

[0088] If the above conditions are met, the scene verification is completed; if not, the scene file is regenerated by modifying the Python code for re-verification.

[0089] Specifically, the hierarchical structure of openSCENARIO used in the present invention is as follows:

[0090] (1) FileHeader: The content includes the scene's creator, a brief description, and release date, etc.

[0091] (2) ParammeterDeclarations: declare the parameters set in the scene, such as time, speed, acceleration, etc.

[0092] (3) CatalogLocations file directory: Similar to a library for storing files. Vehicles, controllers, pedestrians, various objects, environments, maneuvers, trajectories, and routes can be stored in the Catalog. They can be called repeatedly when making different scenes.

[0093] (4) Road Network: OpenSCENARIO uses references to logical road network descriptions (e.g. OpenDRIVE files in .xodr format) to describe the behavior of road users. Various entities (consisting of vehicles, pedestrians and other objects, interactive behaviors defined by event sets, etc.) can be set based on the road network.

[0094] (5) Entity: The object that interacts with the test vehicle in the scene, which can be a pedestrian, a vehicle, or other dynamically placed objects used for testing.

[0095] (6) Storyboard: The storyboard is divided into more complex levels, as follows:

[0096] Init: Initialize the scene content. You can set the weather conditions during the scene, the initial position, initial speed, running track of the test vehicle and target vehicle, and the control method of the vehicle.

[0097] Act: This part is a key part of the scene file. In the ManeuverGroup, it specifies which target object (Actor) has what happened (Action) at which time (StartTrigger). The StartTrigger and StopTrigger at the same level as the ManeuverGroup specify the start and end time of this Act. At the same time, Triggers are divided into conditions triggered by entities and conditions triggered by values.

[0098] StopTrigger: Specifies the end time of the entire StoryBoard.

[0099] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for generating a port test scenario, characterized in that: The following steps are involved: S1: Determine the algorithm level: Clarify the level of the tested port container truck autonomous driving algorithm in the automatic algorithm level, and clarify the production specifications of the scene according to the algorithm level; S2: Design test scenarios after clarifying the test scope: Clarify the port areas covered by the test scope, split the daily operation process of container trucks in the port area, and design the test scenarios according to the coverage area and container truck operation process; S3: Python code writing: By calling the function modules in the scenario generation tool library, the Python code is written according to the level of the intelligent driving standard, and the conditional constraints and permutations of the derived parameters are performed according to the scenario coverage requirements; S4: Generate xosc file and verify: Use Python program to generate XML scene files and verify the scene files on the simulation platform.

2. The method for generating a port test scenario according to claim 1, characterized in that: In S3, when designing the working conditions, different actions and timings can be reasonably selected to be applied in the storyboard according to the test requirements.

3. The method for generating a port test scenario according to claim 1, characterized in that: In S4, the verification process includes: (1) The action of the target vehicle in the scene is consistent with the design content; (2) The vehicles in the scene are driving correctly on the road network; (3) There is no interpenetration between entities in the scene; (4) The entities in the scene do not violate the laws of physics; If the above conditions are met, the scene verification is completed; if not, the scene file is regenerated by modifying the Python code for re-verification.

Images