Vehicle trajectory screening method, electronic device, and program product

Abstract

The application relates to the field of intelligent driving, and discloses a vehicle trajectory screening method, an electronic device and a program product. The method comprises the following steps: acquiring the speed, state information and multiple candidate trajectories of a vehicle; performing data integrity checking on the candidate trajectories to obtain a first trajectory set; matching the state parameters with a preset piecewise linear function table to obtain corresponding piecewise functions; interpolating the piecewise functions with the speed as input to obtain parameter continuity thresholds corresponding to the state parameters; calculating the deviation values of the state parameters at the starting points of the candidate trajectories in the first trajectory set from the corresponding state parameters in the state information; screening the candidate trajectories with deviation values smaller than the corresponding parameter continuity thresholds to obtain a second trajectory set; performing dynamics limit checking on the second trajectory set to obtain a third trajectory set; and performing collision checking on the third trajectory set to obtain effective trajectories. The method can quickly eliminate invalid trajectories, reduce the consumption of computing resources and improve the real-time performance of trajectory screening.

Description

Technical Field

[0001] This application relates to the field of intelligent driving, and in particular to a vehicle trajectory screening method, electronic device and program product. Background Technology

[0002] The intelligent driving trajectory planning module needs to generate multiple candidate trajectories within a limited planning period and computing resources for the decision-making and control system to select from. Trajectory filtering is used to eliminate trajectories that do not meet basic requirements from the candidate trajectories, providing reliable input for subsequent scoring and optimization, and has high requirements for real-time performance and functional safety.

[0003] Existing technologies couple trajectory validity assessment with performance scoring, using a cost function or neural network scorer to traverse all candidate trajectories and calculate a comprehensive score. However, the inspection order is not arranged according to computational cost, basic safety checks are not performed upfront, and trajectories with fundamental defects may also enter the time-consuming inspection stage.

[0004] Existing technologies lack a hierarchical priority checking mechanism. Invalid trajectories must undergo complete scoring or time-consuming checks before being eliminated, resulting in low computational efficiency and difficulty in meeting real-time requirements within a limited planning period. Summary of the Invention

[0005] This application provides a vehicle trajectory screening method, electronic device, and program product to solve the problem that the existing trajectory screening process lacks a hierarchical priority check mechanism, resulting in invalid trajectories having to undergo complete scoring or time-consuming checks before being eliminated, and has low computational efficiency.

[0006] In a first aspect, embodiments of this application provide a vehicle trajectory filtering method, including:

[0007] The vehicle's speed, status information, and multiple candidate trajectories are acquired, wherein the status information includes multiple status parameters;

[0008] The candidate trajectories are subjected to data integrity verification to obtain a first trajectory set;

[0009] The state parameters are matched with a preset piecewise linear function table to obtain the piecewise function corresponding to each state parameter.

[0010] Using the speed as input, the piecewise function is interpolated to obtain the parameter continuity thresholds corresponding to each state parameter;

[0011] Calculate the deviation between each state parameter at the starting point of the candidate trajectory in the first trajectory set and the corresponding state parameter in the state information;

[0012] Candidate trajectories whose deviation values ​​are all less than the corresponding parameter continuity threshold are selected to obtain a second trajectory set;

[0013] The candidate trajectories in the second trajectory set are subjected to dynamic limit verification to obtain the third trajectory set;

[0014] Collision verification is performed on the candidate trajectories in the third trajectory set to obtain the valid trajectories.

[0015] In one possible implementation, the data integrity verification includes: verifying whether the data structure pointer of the candidate trajectory is not empty, and obtaining a pointer verification result; checking the length of the trajectory point sequence, and obtaining a length check result; filtering candidate trajectories whose pointer verification result is not empty and whose length check result is within a preset length range, and obtaining a first trajectory set.

[0016] In one possible implementation, interpolating the piecewise function with the speed as input further includes: obtaining the road curvature; and inputting the speed and the road curvature into the piecewise function to obtain the parameter continuity threshold.

[0017] In one possible implementation, the parameters of the piecewise function are obtained through the following steps: acquiring historical trajectory data; processing the historical trajectory data based on a pre-trained threshold optimization model to obtain the parameters of the piecewise function.

[0018] In one possible implementation, training the pre-trained threshold optimization model includes: acquiring historical trajectory data samples; training the initial model based on the historical trajectory data samples; and updating the parameters of the piecewise function.

[0019] In one possible implementation, the dynamic limit verification includes: obtaining the dynamic parameters of each trajectory point in the second trajectory set; interpolating the dynamic parameters based on a preset set of piecewise linear functions to obtain dynamic limits; and filtering candidate trajectories that do not exceed the dynamic limits to obtain a third trajectory set.

[0020] In one possible implementation, the dynamic limit verification further includes: obtaining the jerk of each trajectory point in the third trajectory set; comparing the jerk with a preset fixed threshold to obtain a comparison result; and filtering candidate trajectories whose comparison result does not exceed the threshold to obtain an updated third trajectory set.

[0021] In one possible implementation, the dynamic limit verification further includes: acquiring lateral acceleration data; correcting the dynamic limit based on the lateral acceleration data; and filtering candidate trajectories in the second trajectory set based on the corrected dynamic limit to obtain an updated third trajectory set.

[0022] In one possible implementation, the dynamic limit verification further includes: obtaining the rate of curvature change of candidate trajectories in the second trajectory set; filtering candidate trajectories whose rate of curvature change does not exceed a preset rate of change range to obtain an updated second trajectory set; and performing the dynamic limit verification on the updated second trajectory set.

[0023] In one possible implementation, the collision verification includes: obtaining the object occupancy of a static obstacle; performing time discretization on the candidate trajectories in the third trajectory set to generate vehicle occupancy at each time point; performing an intersection test between the vehicle occupancy and the object occupancy, and filtering out candidate trajectories whose test results show no intersection of occupancy, thereby obtaining an updated third trajectory set.

[0024] In one possible implementation, the collision verification further includes: acquiring the vehicle outline and the object outline of the static obstacle; detecting the vehicle outline and the object outline to obtain an outline detection result; and filtering candidate trajectories whose outline detection results are non-intersecting to obtain a valid trajectory.

[0025] In one possible implementation, performing an intersection test between the vehicle occupancy and the object occupancy includes: converting the object occupancy of the static obstacle into a bounding rectangle in a preset two-dimensional grid space index; querying static obstacles that overlap with the vehicle occupancy based on the bounding rectangle; and performing the intersection test on the queried static obstacles.

[0026] In one possible implementation, querying static obstacles that overlap with the vehicle's location based on the circumscribed rectangle includes: the preset two-dimensional grid spatial index is a spatiotemporal joint index; and querying static obstacles that overlap with the vehicle's location based on the spatiotemporal joint index and the location information of the static obstacles.

[0027] In one possible implementation, the collision verification further includes: classifying the static obstacles to obtain obstacle categories; determining the detection priority of each static obstacle based on the obstacle category; and performing the intersection test on the static obstacles according to the detection priority.

[0028] In one possible implementation, the method further includes: obtaining the system load of the vehicle and the computational costs of the data integrity verification, the dynamic limit verification, and the collision verification; and adjusting the execution order based on the system load and the computational costs.

[0029] In one possible implementation, before performing data integrity verification on the candidate trajectory, the method further includes: extracting the start point and end point of the candidate trajectory and calculating the Euclidean distance between the start point and end point; and filtering candidate trajectories whose Euclidean distance is less than or equal to a preset distance range.

[0030] Secondly, embodiments of this application provide a vehicle trajectory screening device, comprising:

[0031] The trajectory acquisition module is used to acquire the vehicle's speed, status information, and multiple candidate trajectories. The status information includes multiple status parameters.

[0032] A data integrity verification module is used to perform data integrity verification on the candidate trajectories to obtain a first trajectory set;

[0033] The function matching module is used to match the state parameters with a preset piecewise linear function table to obtain the piecewise function corresponding to each state parameter.

[0034] A continuity verification module is used to interpolate the piecewise function with the speed as input to obtain the parameter continuity threshold corresponding to each state parameter;

[0035] The deviation calculation module is used to calculate the deviation value between each state parameter at the starting point of the candidate trajectory in the first trajectory set and the corresponding state parameter in the state information;

[0036] The trajectory filtering module is used to filter candidate trajectories whose deviation values ​​are all less than the corresponding parameter continuity threshold, to obtain a second trajectory set;

[0037] The dynamic limit verification module is used to perform dynamic limit verification on the candidate trajectories in the second trajectory set to obtain the third trajectory set.

[0038] The collision verification module is used to perform collision verification on the candidate trajectories in the third trajectory set to obtain valid trajectories.

[0039] In one possible implementation, the data integrity verification module is specifically used to: verify whether the data structure pointer of the candidate trajectory is not empty, and obtain the pointer verification result; check the length of the trajectory point sequence, and obtain the length check result; filter the candidate trajectories whose pointer verification result is not empty and whose length check result is within a preset length range, and obtain the first trajectory set.

[0040] In one possible implementation, the continuity verification module is further configured to: obtain the road curvature; input the speed and the road curvature into the piecewise function to obtain the parameter continuity threshold.

[0041] In one possible implementation, the function matching module is further configured to: acquire historical trajectory data; process the historical trajectory data based on a pre-trained threshold optimization model to obtain the parameters of the piecewise function.

[0042] In one possible implementation, the function matching module is further configured to: acquire historical trajectory data samples; train the initial model based on the historical trajectory data samples; and update the parameters of the piecewise function.

[0043] In one possible implementation, the dynamic limit verification module is specifically used to: obtain the dynamic parameters of each trajectory point in the second trajectory set; interpolate the dynamic parameters based on a preset set of piecewise linear functions to obtain dynamic limits; and filter candidate trajectories that do not exceed the dynamic limits to obtain a third trajectory set.

[0044] In one possible implementation, the dynamic limit verification module is further configured to: obtain the jerk of each trajectory point in the third trajectory set; compare the jerk with a preset fixed threshold to obtain a comparison result; and filter candidate trajectories whose comparison result is not exceeded to obtain an updated third trajectory set.

[0045] In one possible implementation, the dynamic limit verification module is further configured to: acquire lateral acceleration data; correct the dynamic limit based on the lateral acceleration data; and filter candidate trajectories in the second trajectory set based on the corrected dynamic limit to obtain an updated third trajectory set.

[0046] In one possible implementation, the dynamic limit verification module is further configured to: obtain the rate of curvature change of candidate trajectories in the second trajectory set; filter candidate trajectories whose rate of curvature change does not exceed a preset rate of change range to obtain an updated second trajectory set; and perform the dynamic limit verification on the updated second trajectory set.

[0047] In one possible implementation, the collision verification module is specifically used to: obtain the object occupancy of static obstacles; perform time discretization on the candidate trajectories in the third trajectory set to generate vehicle occupancy at each time moment; perform an intersection test between the vehicle occupancy and the object occupancy, and filter the candidate trajectories whose test results show no intersection of occupancy, thereby obtaining an updated third trajectory set.

[0048] In one possible implementation, the collision verification module is further configured to: acquire the vehicle outline and the object outline of the static obstacle; detect the vehicle outline and the object outline to obtain an outline detection result; and filter candidate trajectories whose outline detection results are non-intersecting to obtain a valid trajectory.

[0049] In one possible implementation, the collision verification module is further configured to: convert the object occupancy of the static obstacle into a bounding rectangle in a preset two-dimensional grid space index; query static obstacles that overlap with the vehicle occupancy based on the bounding rectangle; and perform the intersection test on the queried static obstacles.

[0050] In one possible implementation, the collision verification module is further configured to: use the preset two-dimensional grid spatial index as a spatiotemporal joint index; and query static obstacles that overlap with the vehicle's position based on the spatiotemporal joint index and the location information of the static obstacles.

[0051] In one possible implementation, the collision verification module is further configured to: classify the static obstacles to obtain obstacle categories; determine the detection priority of each static obstacle based on the obstacle category; and perform the intersection test on the static obstacles according to the detection priority.

[0052] In one possible implementation, the trajectory acquisition module is further configured to: acquire the system load of the vehicle and the computational costs of the data integrity verification, the dynamic limit verification, and the collision verification; and adjust the execution order according to the system load and the computational costs.

[0053] In one possible implementation, the trajectory acquisition module is further configured to: extract the start point and end point of the candidate trajectory, and calculate the Euclidean distance between the start point and end point; and filter candidate trajectories whose Euclidean distance is less than or equal to a preset distance range.

[0054] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0055] The memory stores computer-executed instructions;

[0056] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0057] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0058] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0059] The vehicle trajectory filtering method, electronic device, and program product provided in this application obtain vehicle speed, status information, and multiple candidate trajectories. First, the candidate trajectories are checked for data integrity to obtain a first trajectory set. Then, multiple status parameters in the status information are matched with a preset piecewise linear function table to obtain the piecewise function corresponding to each status parameter. Using speed as input, the piecewise function is interpolated to obtain the parameter continuity threshold corresponding to each status parameter. Then, the deviation value of each status parameter at the starting point of the candidate trajectory in the first trajectory set is calculated from the corresponding status parameter in the status information. Candidate trajectories with deviation values ​​less than the corresponding parameter continuity threshold are filtered to obtain a second trajectory set. Subsequently, the second trajectory set is checked for dynamic limits to obtain a third trajectory set. The third trajectory set is checked for collisions to obtain valid trajectories. Invalid trajectories are eliminated step by step in a low-consumption stage, achieving the effects of quickly eliminating invalid trajectories, reducing computational resource consumption, and improving the real-time performance of trajectory filtering. Attached Figure Description

[0060] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0061] Figure 1 Flowchart of the vehicle trajectory filtering method provided in this application Figure 1 ;

[0062] Figure 2 Flowchart of the vehicle trajectory filtering method provided in this application Figure 2 ;

[0063] Figure 3 Flowchart of the vehicle trajectory filtering method provided in this application Figure 3 ;

[0064] Figure 4 Flowchart of the vehicle trajectory filtering method provided in this application Figure 4 ;

[0065] Figure 5 Flowchart of the vehicle trajectory filtering method provided in this application Figure 5 ;

[0066] Figure 6 Flowchart of the vehicle trajectory filtering method provided in this application Figure 6 ;

[0067] Figure 7 Flowchart of the vehicle trajectory filtering method provided in this application Figure 7 ;

[0068] Figure 8 A schematic diagram of the vehicle trajectory screening device provided in this application;

[0069] Figure 9 A schematic diagram of the structure of the electronic device provided in this application.

[0070] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0071] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0072] First, let me explain the terms used in this application:

[0073] Speed: refers to the real-time longitudinal speed of the vehicle at the current moment, which is used as the interpolation input for the preset piecewise linear function table.

[0074] Status information refers to the set of motion status data of a vehicle at the current moment, including multiple status parameters.

[0075] State parameters: These are parameters used to characterize the current motion state of a vehicle, including at least one of position, heading angle, curvature, velocity, and acceleration.

[0076] Candidate trajectory: refers to the trajectory generated by the upstream planning module that has not yet been validated, including the sequence of trajectory points arranged in chronological order.

[0077] Trajectory point: refers to a single data item in the candidate trajectory arranged in chronological order, including at least one of two-dimensional plane coordinates, heading angle, curvature, velocity, and acceleration.

[0078] Data integrity verification refers to the steps of checking the validity of the data structure pointers of candidate trajectories, the length of the trajectory point sequence, and the key fields of trajectory points.

[0079] The first trajectory set refers to the set of candidate trajectories that have passed the data integrity verification among multiple candidate trajectories.

[0080] Preset piecewise linear function table: refers to a pre-configured lookup table consisting of piecewise linear functions defined by velocity values ​​and corresponding threshold data points. Each piecewise linear function is associated with a state parameter.

[0081] Piecewise function: refers to a piecewise linear function corresponding to a certain state parameter in a pre-defined piecewise linear function table, with velocity as the independent variable and the parameter continuity threshold of the state parameter as the dependent variable.

[0082] Parameter continuity threshold: refers to the maximum allowable deviation of a certain state parameter obtained by interpolating the velocity through a piecewise function.

[0083] Deviation value: refers to the difference between each state parameter at the starting point of the candidate trajectory and the corresponding state parameter in the state information.

[0084] The second trajectory set refers to the set of candidate trajectories in the first trajectory set whose deviation values ​​are all less than the corresponding parameter continuity threshold.

[0085] Dynamic limit verification: This refers to the check step of comparing the dynamic parameters of each trajectory point in the second trajectory set with the dynamic limit to eliminate candidate trajectories that exceed the dynamic limit.

[0086] Dynamic parameters: These are parameters used to characterize the motion state of a vehicle at a trajectory point, including at least one of curvature, rate of change of curvature, longitudinal acceleration, lateral acceleration, and jerk.

[0087] Dynamic limit: refers to the allowable range of values ​​for a dynamic parameter obtained by interpolating the dynamic parameter based on a preset set of piecewise linear functions.

[0088] The third trajectory set refers to the set of candidate trajectories in the second trajectory set that have not exceeded the dynamic limit.

[0089] Collision verification refers to the process of checking whether candidate trajectories in the third trajectory set intersect with static obstacles to eliminate candidate trajectories that intersect.

[0090] Static obstacles: These are obstacles whose position does not change within a certain period of time and do not move with time.

[0091] Object occupancy: refers to the geometrically occupied area of ​​a static obstacle on a two-dimensional plane.

[0092] Vehicle occupancy: refers to the geometrically occupied area of ​​a vehicle on a two-dimensional plane after the candidate trajectory is discretized at a certain moment.

[0093] Intersection test: refers to the process of detecting whether there is an overlapping area between the vehicle's position and the object's position on a two-dimensional plane.

[0094] Valid trajectory: refers to a candidate trajectory that has been marked as usable after passing data integrity check, continuity check, dynamic limit check and collision check in sequence.

[0095] Preset length range: refers to the pre-configured range of values ​​used to determine whether the length of the trajectory point sequence is valid.

[0096] Data structure pointer: is a pointer to the starting address of the candidate trajectory data structure.

[0097] Pointer verification result: refers to the result obtained by verifying whether a pointer to a data structure is not null.

[0098] Length check result: refers to the result obtained by checking the length of the trajectory point sequence.

[0099] Road curvature: refers to the degree of curvature of the road where the vehicle is currently located.

[0100] Historical trajectory data refers to trajectory data accumulated during past planning or driving processes, which is used to determine the parameters of the piecewise function.

[0101] Pre-trained threshold optimization model: refers to a model that is pre-trained based on historical trajectory data and used to process historical trajectory data to obtain piecewise function parameters.

[0102] Historical trajectory data samples: refers to sample data selected from historical trajectory data for training the pre-trained threshold optimization model.

[0103] Initial model: refers to a pre-trained threshold optimization model that has not yet been trained or updated in terms of parameters.

[0104] Jerk: refers to the rate of change of acceleration over time.

[0105] Lateral acceleration data: refers to sensor data that characterizes the lateral acceleration of a vehicle.

[0106] Curvature change rate: refers to the rate of change of curvature in the candidate trajectory as the trajectory points change.

[0107] Preset range of rate of change: refers to the pre-configured range of values ​​used to determine whether the rate of change of curvature is valid.

[0108] Preset fixed threshold: refers to a pre-configured fixed limit value used to determine whether the jerk is legal.

[0109] System load: refers to the resource usage status of the on-board computing device during the trajectory screening process.

[0110] Computational cost: refers to the computational overhead required for each of the data integrity verification, dynamic limit verification, and collision verification processes.

[0111] Preset 2D grid space index: refers to the index structure formed by dividing a 2D plane into grid cells and storing the obstacle's position in the corresponding grid cell.

[0112] Circumscribed rectangle: refers to a rectangle that is externally tangent to the static obstacle object and whose sides are parallel to the coordinate axes.

[0113] Spatiotemporal composite index: refers to an index structure that organizes obstacles based on both location and time information to support queries.

[0114] Obstacle category: refers to the category obtained by classifying static obstacles according to their type.

[0115] Detection priority: refers to the order in which static obstacles are subjected to intersection tests.

[0116] Euclidean distance: refers to the straight-line distance between the starting point and the ending point of a candidate trajectory in a two-dimensional plane.

[0117] Preset distance range: refers to the pre-configured range of values ​​used to determine whether the Euclidean distance between the starting point and the ending point of a candidate trajectory is valid.

[0118] In the field of intelligent driving motion planning, when vehicles are driving on urban roads, highways, and complex intersections, they need to filter and select the best candidate trajectory within a limited planning period. This process is usually deployed within the autonomous driving domain controller, working in conjunction with perception, localization, high-precision mapping, and chassis control modules to receive vehicle speed and status information as well as multiple candidate trajectories, and to make trajectory decisions based on the surrounding traffic environment.

[0119] Existing vehicle trajectory screening technologies typically begin by performing a completeness check on candidate trajectories, followed by initial filtering based on the matching relationship between the vehicle's current state and the trajectory's starting point. Subsequently, they also verify the trajectory's dynamic feasibility and collision risk with surrounding targets to eliminate trajectories that do not meet the execution conditions. Some solutions further incorporate map information, lane boundaries, and traffic rules for additional judgments to reduce obviously unreasonable driving paths.

[0120] However, in real-world road environments, there are often short-term deviations between vehicle states and the starting points of candidate trajectories. Without continuity constraints, trajectories with insufficient dynamic executability are easily retained in subsequent stages, leading to redundant calculations and selection. Relying solely on static rules or single collision detection can result in overly broad or insufficient filtering under complex traffic flows, causing instability in the number of available trajectories and affecting the continuity and reliability of the planning output. To address these issues, a clearer segmented verification logic needs to be introduced into the trajectory selection process, and the continuity relationship between the trajectory and the current vehicle state needs to be constrained to improve the stability and executability of the selection results.

[0121] The vehicle trajectory filtering method provided in this application first verifies the data integrity of candidate trajectories, then uses vehicle speed as input to interpolate through a preset piecewise linear function table to obtain the parameter continuity threshold of each state parameter and filters accordingly. Subsequently, dynamic limit verification and collision verification are performed in sequence, so that invalid trajectories are eliminated step by step in a low-cost stage. This solves the technical problem in the prior art that invalid trajectories need to undergo complete scoring or time-consuming checks before being eliminated, resulting in low computational efficiency.

[0122] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0123] Figure 1 Flowchart of the vehicle trajectory filtering method provided in this application Figure 1 ,like Figure 1 As shown, the method includes:

[0124] S101. Obtain the vehicle's speed, status information, and multiple candidate trajectories. The status information includes multiple status parameters.

[0125] Specifically, during vehicle operation, the onboard computing device reads multiple candidate trajectories generated by the planning module through the planning module interface, and reads the real-time speed and status information at the current moment through the vehicle status interface. The candidate trajectories consist of a sequence of trajectory points arranged in chronological order and have not yet undergone validity determination. The status information includes multiple status parameters such as position, heading angle, curvature, speed, and acceleration, used to characterize the vehicle's current motion state.

[0126] By collecting the output data from the planning module and the real-time vehicle status data simultaneously, subsequent verification at all levels share the same data benchmark, avoiding verification deviations caused by different data sources or different collection times. This establishes a unified data source for the trajectory screening process, ensuring that the judgment results of subsequent verification at all levels reflect the vehicle status and trajectory status at the same time, guaranteeing the consistency of verification results.

[0127] S102. Perform data integrity verification on the candidate trajectories to obtain the first trajectory set.

[0128] Specifically, the onboard computing device reads the data structure pointer, trajectory point sequence length, and key fields of each candidate trajectory one by one, verifying whether the data structure pointer is not empty, whether the trajectory point sequence length is within a preset length range, and whether the key fields are valid values. The preset length range refers to a pre-configured range of values ​​used to determine whether the trajectory point sequence length is valid. Candidate trajectories with non-empty data structure pointers, trajectory point sequence lengths within the preset length range, and valid key fields are retained to form the first trajectory set.

[0129] Since the above verification mainly involves memory address access, container length lookup, and numerical validity verification, it has the lowest computational overhead and can intercept data with abnormal structure or invalid values ​​at the process entry point. After this filtering layer, candidate trajectories with abnormal data structure, abnormal number of trajectory points, or invalid key fields do not need to enter the more computationally intensive subsequent continuity verification, dynamic limit verification, and collision verification, thereby reducing invalid calculations.

[0130] For example, the execution entity can be deployed within the autonomous driving domain controller or in a separate trajectory planning and processing unit, receiving speed, status information, and candidate trajectories from the vehicle state bus, positioning module, or planning module. Candidate trajectories are multiple trajectory data generated during the planning phase. Each trajectory includes at least a sequence of trajectory points, a start point, an end point, and temporal or spatial sampling information for subsequent judgment. Status information characterizes the vehicle's current motion and attitude state. Multiple status parameters can include one or more of the following: longitudinal velocity, lateral velocity, yaw rate, heading angle, acceleration, and lateral offset. The specific parameters are selected based on their ability to characterize the current vehicle state required for trajectory continuity judgment. Data integrity verification eliminates candidate trajectories with missing data fields, insufficient trajectory point sequence length, empty trajectory structure pointers, or abnormal trajectory coordinates, resulting in a first set of trajectories that can enter subsequent processing stages. Based on the above analysis, this step constitutes the entry point of the trajectory filtering chain. By first completing basic data checks and then generating the first set of trajectories, it provides stable input for subsequent continuity, dynamics, and collision filtering.

[0131] S103. Match the state parameters with the preset piecewise linear function table to obtain the piecewise function corresponding to each state parameter.

[0132] Specifically, the onboard computing device searches for the piecewise linear function associated with the state parameter in a preset piecewise linear function table based on the category of the state parameter. The preset piecewise linear function table is a pre-configured lookup table composed of piecewise linear functions defined by speed values ​​and corresponding threshold data points. Each piecewise linear function in the table is associated with a state parameter. A piecewise function is a piecewise linear function with speed as the independent variable and the parameter continuity threshold of the state parameter as the dependent variable.

[0133] By organizing the thresholds for different inspection dimensions into the same lookup table as independent functions, each dimension can independently configure its threshold curve based on its own characteristics. This allows for the determination of piecewise functions corresponding to each state parameter in subsequent interpolation calculations. Consequently, threshold calculations become dimension-specific, and different state parameters can have their allowable deviations calculated independently based on their respective functions.

[0134] S104. Using velocity as input, interpolate the piecewise function to obtain the parameter continuity thresholds corresponding to each state parameter.

[0135] Specifically, the onboard computing device uses the current speed as the independent variable and performs linear interpolation calculations in each piecewise function determined in S103 to obtain the parameter continuity threshold corresponding to each state parameter. Interpolation calculation refers to the process of calculating the corresponding threshold from the current speed based on the linear relationship between adjacent data points in the piecewise function. The parameter continuity threshold refers to the maximum allowable deviation value for a certain state parameter.

[0136] By querying the piecewise functions with speed as the independent variable, the allowable deviation is adjusted according to the vehicle speed, and the threshold is matched with the current vehicle speed, thus providing a judgment benchmark that adapts to vehicle speed for continuity verification. Compared with a fixed threshold, this method can avoid misjudgments at different vehicle speeds, making the judgment criteria for continuity verification consistent with the actual driving conditions.

[0137] For example, a pre-defined piecewise linear function table can be stored in the vehicle control unit, planning controller, or parameter configuration file. The function table records the piecewise linear relationships of each state parameter under different speed ranges. Matching state parameters with the function table can be performed one by one according to parameter category. For example, when the state parameter is lateral velocity, the system reads the piecewise function corresponding to the lateral velocity from the function table; when the state parameter is yaw rate, it reads another set of corresponding piecewise functions. The piecewise function describes the allowed continuity of state changes within different speed ranges, and its function nodes can be determined based on historical trajectory data, calibration results, or offline training results. After speed is used as the interpolation input, the system performs linear interpolation between adjacent segment nodes to calculate the parameter continuity threshold corresponding to each state parameter under the current speed condition. The parameter continuity threshold characterizes the range within which the state parameter at the candidate trajectory starting point can deviate from the current vehicle state. As the speed increases or the speed range changes more significantly, the threshold changes continuously with the interpolation result to avoid abrupt changes in the threshold at the segment boundaries. Based on the above analysis, the core of this step is to convert discrete state parameter rules into thresholds that change continuously with speed, thereby providing a unified standard for subsequent deviation judgment and enabling trajectory screening to adapt to changes in vehicle operating status.

[0138] S105. Calculate the deviation between the state parameters at the starting point of each candidate trajectory in the first trajectory set and the corresponding state parameters in the state information.

[0139] Specifically, the onboard computing device extracts the state parameters at the starting point of each candidate trajectory in the first trajectory set, and compares them item by item with the corresponding state parameters in the state information to obtain the deviation value for each state parameter. The deviation value refers to the difference between the state parameter at the starting point of the candidate trajectory and the corresponding state parameter in the state information.

[0140] The smoothness of the connection between the candidate trajectory starting state and the current state of the vehicle is measured by the difference between the two. The connection degree is converted into a comparable value, which can provide a quantitative basis for continuity verification and make the judgment of the connection degree have a comparable numerical basis.

[0141] S106. Select candidate trajectories whose deviation values ​​are all less than the corresponding parameter continuity threshold to obtain the second trajectory set.

[0142] Specifically, the on-board computing device compares each deviation value obtained in S105 with the corresponding parameter continuity threshold obtained in S104, and retains the candidate trajectories whose deviation values ​​are all less than the corresponding thresholds to form the second trajectory set.

[0143] The threshold values ​​of each dimension together constitute the continuity judgment condition. The connection is considered qualified only when the deviation value of all dimensions is less than the corresponding threshold. Based on this, candidate trajectories with unsmooth connection are removed from the first trajectory set, thereby reducing the number of trajectories entering the subsequent dynamic limit verification and collision verification, and reducing the amount of computation in the subsequent stages.

[0144] For example, for each candidate trajectory in the first trajectory set, the system extracts the state parameters at its starting point and compares them one by one with the corresponding state parameters in the current state information to calculate the deviation value of each parameter. The deviation value can be represented as an absolute difference, a vector magnitude difference, or a difference normalized according to the parameter dimension, and the specific form is determined by the data type of the state parameter. For example, for scalar parameters, numerical difference can be used directly, and for attitude angle parameters, angle normalization can be performed first before calculating the difference. Each calculated deviation value is compared with the corresponding parameter continuity threshold. The candidate trajectory is retained and included in the second trajectory set only if the deviation values ​​of all state parameters at the starting point of the candidate trajectory are less than the corresponding threshold; if the deviation of any state parameter exceeds the threshold, the candidate trajectory is eliminated in the continuity screening stage. The state parameters at the starting point of the candidate trajectory are used to characterize the connection relationship between the planned trajectory and the current vehicle state. Only when the starting state and the current state are continuously consistent within the threshold range can the trajectory have the basis for entering subsequent processing. This step allows the system to eliminate trajectories that do not meet state continuity requirements in advance, reducing the computational load on subsequent dynamics and collision verification, and improving the consistency between trajectories entering subsequent stages and the current vehicle state.

[0145] S107. Perform dynamic limit verification on the candidate trajectories in the second trajectory set to obtain the third trajectory set.

[0146] Specifically, the onboard computing device traverses each trajectory point in the second trajectory set, reads its dynamic parameters, and interpolates the dynamic parameters based on a preset set of piecewise linear functions to obtain dynamic limits. Candidate trajectories that do not exceed the dynamic limits are retained to form the third trajectory set. Dynamic parameters are parameters characterizing the vehicle's motion state at a trajectory point, including curvature, rate of change of curvature, longitudinal acceleration, lateral acceleration, and jerk. Dynamic limits refer to the allowable range of values ​​for a given dynamic parameter, obtained by interpolating the dynamic parameter based on the preset set of piecewise linear functions.

[0147] The physical executability of the trajectory is constrained by vehicle dynamics characteristics. The dynamic parameters at the trajectory points are compared with the limits that vary with speed to determine whether the trajectory is within the vehicle's executable range, thus eliminating candidate trajectories that are physically unexecutable. The retained candidate trajectories conform to the actual driving capabilities of the vehicle, providing physically feasible input for subsequent collision verification.

[0148] For example, each candidate trajectory in the second trajectory set contains trajectory points discretized in time or space. The system reads the dynamic parameters corresponding to these trajectory points and interpolates them based on a preset piecewise linear function set to obtain dynamic limits that match the current trajectory state. Dynamic parameters may include one or more of acceleration, lateral acceleration, curvature, rate of change of curvature, and jerk; the specific combination is determined by the constraint model of the planning controller on the vehicle chassis's execution capability. The preset piecewise linear function set can store the limit relationships of different dynamic parameters in different operating ranges. The system calculates the dynamic limits corresponding to the current trajectory point through interpolation and then determines whether the dynamic parameters of that trajectory point exceed the limits. For any candidate trajectory, if the dynamic parameters of any trajectory point exceed the corresponding dynamic limit, the candidate trajectory is removed from the second trajectory set; if all trajectory points do not exceed the limits, the candidate trajectory is retained and a third trajectory set is formed. Based on the above analysis, this step performs a secondary screening of trajectory execution feasibility through dynamic constraints, further eliminating candidate trajectories that meet the requirements in terms of state continuity but are not executable in terms of vehicle dynamics, thereby forming the third trajectory set.

[0149] S108. Perform collision verification on the candidate trajectories in the third trajectory set to obtain the valid trajectories.

[0150] Specifically, the onboard computing device acquires the object occupancy of static obstacles, discretizes the candidate trajectories in the third trajectory set over time to generate vehicle occupancy at each moment, performs an intersection test between the vehicle occupancy and the object occupancy, and retains the candidate trajectories that do not intersect, thus obtaining the valid trajectories. A static obstacle is an obstacle whose position does not change within a certain time and does not move with time. An object occupancy refers to the geometrically occupied area of ​​a static obstacle on a two-dimensional plane. A vehicle occupancy refers to the geometrically occupied area of ​​a vehicle on a two-dimensional plane after the candidate trajectory is discretized at a certain moment. The intersection test is the process of detecting whether there is an overlapping area between the vehicle occupancy and the object occupancy on the two-dimensional plane.

[0151] Geometric intersection is used to determine whether candidate trajectories spatially conflict with static obstacles at each discrete time step. The time dimension of the trajectory is expanded into several discrete time steps, and the determination is performed time-by-time. Based on the verification in the first three steps, spatial safety verification is completed. This ensures that the final retained valid trajectory is spatially feasible and can be used as input for subsequent decision-making modules.

[0152] For example, the system first acquires the object occupancy or outline of static obstacles in the environment, then performs time discretization processing on each candidate trajectory in the third trajectory set, generating vehicle occupancy at each time step according to the time step corresponding to the trajectory. Vehicle occupancy describes the spatial area occupied by the vehicle at a certain time, while object occupancy describes the spatial area occupied by the static obstacle. The two can be judged by occupancy intersection test; vehicle outline and object outline can be judged by geometric outline detection. When using occupancy intersection test, the system judges the intersection of vehicle occupancy and object occupancy of static obstacles. If there is any intersection between vehicle occupancy and any obstacle occupancy at any time, the candidate trajectory is considered to have a collision risk and is eliminated. When using outline detection, the system compares whether there is an intersection relationship between vehicle outline and object outline. If they do not intersect, the corresponding candidate trajectory is retained. After collision verification, candidate trajectories that do not intersect or do not have a detected collision risk are determined as valid trajectories and output to the subsequent planning or control module. Based on the above analysis, this step further filters dynamically executable trajectories that may still have spatial conflicts, so that the final output effective trajectory simultaneously satisfies state continuity, dynamic constraints, and spatial safety constraints, thereby completing the vehicle trajectory screening.

[0153] Based on the above analysis, this application provides a vehicle trajectory filtering method, which includes acquiring the vehicle's speed, state information, and multiple candidate trajectories; performing data integrity verification on the candidate trajectories; generating a parameter continuity threshold by combining state parameters with a preset piecewise linear function table; and progressively filtering and outputting valid trajectories based on the state deviation at the starting point of the candidate trajectory, dynamic limits, and collision results. In this application, by associating the continuity threshold with speed and establishing a progressively advancing filtering relationship between continuity filtering, dynamic verification, and collision verification, the trajectory filtering process maintains a clear piecewise verification logic, reduces the probability of invalid trajectories entering subsequent stages, and ensures that the output trajectory is consistent with the current vehicle state, vehicle dynamic capabilities, and environmental obstacle constraints. It should be understood that the above example is merely illustrative and not limiting.

[0154] In practical applications, this method can be deployed in the planning controller of passenger vehicles equipped with intelligent driving systems. Taking a multi-lane urban road environment as an example, the vehicle is traveling in the central lane of a six-lane dual carriageway. Approximately 30 meters ahead is an intersection, and the current traffic light is green. A silver sedan is traveling at a slightly higher speed in the adjacent lane to the left of the vehicle, and there is a continuous solid-line guardrail to the right. At this moment, the driver actively activates the left turn signal lever, indicating a desire to change lanes to the left and pass through the intersection. The environmental perception module captures the position, speed, and direction of surrounding vehicles in real time, and the positioning module confirms that the vehicle is in the straight-ahead / left-turn lane. Based on the above environmental information, the upstream multimodal trajectory generator outputs multiple candidate trajectories in parallel within a planning cycle of hundreds of milliseconds, including a straight-ahead trajectory for the current lane, a left-lane merging trajectory, a deceleration trajectory for the current lane, and a right-turn avoidance trajectory, along with motion prediction curves of surrounding vehicles and traffic light status data at the intersection. After receiving the above trajectory set, the system outputs a unique optimal control trajectory that conforms to the current traffic environment, driver intention and ride comfort within a strict planning cycle through a three-step serial processing flow: safety and compliance pre-filtering, high-level driving intention game decision-making and low-level physical comfort optimization. This trajectory is then sent to the chassis actuator in real time.

[0155] This invention first performs data integrity verification, then uses velocity as input to interpolate through a piecewise function to obtain a parameter continuity threshold and completes continuity verification accordingly. Subsequently, dynamic limit verification and collision verification are performed sequentially, so that various invalid trajectories are eliminated at the verification level corresponding to their defects, reducing the overall computational overhead and improving the real-time performance of trajectory selection.

[0156] Figure 2 Flowchart of the vehicle trajectory filtering method provided in this application Figure 2 ,like Figure 2 As shown, this embodiment, based on the above embodiments, provides a detailed description of data integrity verification. The method includes:

[0157] S201. Verify whether the data structure pointer of the candidate trajectory is not null, and obtain the pointer verification result.

[0158] Specifically, the onboard computing device reads the data structure pointers of each candidate trajectory and determines whether they point to valid memory addresses. The data structure pointer is a pointer to the starting address of the candidate trajectory data structure. The pointer verification result refers to the result obtained by verifying whether the data structure pointer is not null.

[0159] Verifying data structure pointers involves memory address access, which has relatively low computational overhead and can be performed preferentially at the process entry point. If the pointer is null, it indicates that the candidate trajectory's data structure has not yet been established or has been released; in this case, any subsequent field reading is meaningless. Placing this verification as the first step in data integrity checking can eliminate invalid addresses before accessing trajectory point sequence length and key fields, reducing access operations to invalid addresses.

[0160] S202. Check the length of the trajectory point sequence and obtain the length check result.

[0161] Specifically, the onboard computing device counts the number of trajectory points contained in the trajectory point sequence of each candidate trajectory and determines whether this number is within a preset length range. The length check result refers to the result obtained by checking the length of the trajectory point sequence.

[0162] The length of the trajectory point sequence reflects whether the data size of the candidate trajectory is within a reasonable range. Candidate trajectories are generated by the planning module within a finite planning period, and the number of trajectory points is usually related to the planning period and sampling interval. Sequences that are too long or too short may correspond to anomalies in the data generation or transmission process. Length checks can further narrow down the range of data to be processed before numerical verification, allowing subsequent verification of key fields to focus on candidate trajectories with a reasonable number of points.

[0163] S203. Filter the candidate trajectories whose pointer verification results are not empty and whose length check results are within the preset length range to obtain the first trajectory set.

[0164] Specifically, the on-board computing device retains candidate trajectories whose pointer verification results are not empty and whose length check results are within a preset length range, forming a first trajectory set.

[0165] The pointer verification results and length check results together constitute the data integrity judgment conditions. When both conditions are met, the data is considered complete. This completes the data integrity filtering of candidate trajectories, preventing trajectories with structural or quantitative abnormalities from entering subsequent verification stages. The first set of trajectories, serving as the input for subsequent continuity verification, is smaller in size than the original candidate trajectories, providing a basis for controlling the computational load in subsequent stages.

[0166] In the specific implementation, data integrity verification is used to perform basic validity confirmation before candidate trajectories enter subsequent filtering. The data structure pointer of the candidate trajectory is used to represent the loading status of the trajectory data in memory, and the pointer verification result is used to record whether the data structure pointer is usable. The trajectory point sequence length is used to represent the completeness of the number of trajectory points in the candidate trajectory, and the preset length range is used to limit the minimum and maximum values ​​of the number of trajectory points so that the trajectory structure meets the requirements of subsequent processing.

[0167] After receiving multiple candidate trajectories, the autonomous driving domain controller first reads the structure pointer address corresponding to each candidate trajectory and determines whether the address is a null pointer. If the pointer is null, it indicates that the data for the candidate trajectory has not been successfully loaded or has expired, and it will not proceed to further processing. Subsequently, for candidate trajectories with non-null pointers, the length of the trajectory point sequence is read. The length can be obtained directly from the number of elements in the trajectory point array, or it can be calculated from the difference between the start and end indices of the trajectory points. This length is then compared with a preset length range. The preset length range can be set according to the minimum number of executable trajectory points and the maximum storage constraint within the planning cycle, for example, limited to between ten and two hundred trajectory points. This ensures that the candidate trajectories have enough discrete points to describe the trajectory shape, but the length is not too short or too long, which would affect subsequent screening processing. For candidate trajectories with non-null pointer verification results and length check results within the preset length range, the system writes them into the first trajectory set for subsequent continuous matching, dynamics verification, and collision verification with vehicle state.

[0168] This processing method first checks the validity of the data structure pointer, then verifies the length of the trajectory point sequence. Candidate trajectories with invalid structures or abnormal lengths are directly eliminated, and only trajectories that meet the basic integrity conditions are retained to enter the first trajectory set. As a result, the input data received by the subsequent filtering module is more stable, the size of the trajectory set is more controllable, the redundant processing caused by invalid trajectories participating in the calculation is reduced, and the continuity and executability of the trajectory filtering results are improved.

[0169] This invention embodiment completes data integrity verification at the front end of the trajectory filtering process by first verifying the data structure pointer, then checking the length of the trajectory point sequence, and finally filtering based on both results, thereby reducing the computational load in subsequent steps.

[0170] Figure 3 Flowchart of the vehicle trajectory filtering method provided in this application Figure 3 ,like Figure 3 As shown, this embodiment, based on the above embodiments, provides a detailed description of the continuity verification method, which includes:

[0171] S301, Obtain road curvature.

[0172] Specifically, the onboard computing unit reads the road curvature of the road the vehicle is currently on. Road curvature refers to the degree of curvature of the road the vehicle is currently on.

[0173] Road curvature reflects the geometry of the path a vehicle is currently on. On straight and curved road sections, a vehicle's tolerance for deviations from its trajectory starting point differs. Using road curvature as one of the interpolation inputs allows the continuity threshold to further reflect road morphology beyond just changes in vehicle speed, ensuring that the continuity verification criterion is aligned with the geometric characteristics of the vehicle's current path.

[0174] S302. Input the speed and road curvature into the piecewise function to obtain the parameter continuity threshold.

[0175] Specifically, the onboard computing device uses the current speed and road curvature as independent variables to input the piecewise functions corresponding to each state parameter, and then calculates the parameter continuity threshold corresponding to each state parameter through interpolation.

[0176] Using both speed and road curvature as inputs to the piecewise function, the parameter continuity threshold is further adjusted according to road morphology, in addition to changing with vehicle speed. Compared to interpolation methods that only use speed as input, introducing road curvature allows the threshold to be adjusted accordingly in curved road sections, thus matching the continuity verification criterion with the curvature of the road the vehicle is currently on. The resulting parameter continuity threshold serves as the benchmark for subsequent deviation value comparisons and participates in the selection of the first trajectory set.

[0177] In practical implementation, road curvature is used to characterize the degree of curvature of the road the vehicle is currently traveling on. It can be calculated from the road centerline, lane boundary fitted curve, or local road geometry information after localization fusion in a high-precision map, and can be expressed in any form, such as the reciprocal of the radius of curvature, the curvature fitted at discrete sampling points, or the rate of change of curvature. In this application, a piecewise function is used to describe the parameter continuity requirements under different vehicle speeds and different road curvature conditions, and a parameter continuity threshold is used to limit the allowable deviation range between the vehicle state parameters at the starting point of the candidate trajectory and the current state parameters.

[0178] After receiving the vehicle speed, the controller first synchronously reads the road curvature corresponding to the current position and sends both as inputs to a pre-established piecewise function table or piecewise fitting model. This piecewise function can be defined by multiple curvature and speed intervals, with different intervals corresponding to different threshold outputs. The controller performs interpolation calculations based on the current speed and the road curvature interval to obtain a continuously changing parameter continuity threshold. This threshold can be directly used by the subsequent trajectory filtering module, ensuring a consistent computational framework for the continuity constraint of the trajectory starting point under conditions of straight roads, gently curving roads, and sharp curves, while the threshold value adaptively adjusts with changes in road geometry.

[0179] In practical applications, this piecewise function can be stored in the controller's non-volatile memory unit and implemented using a lookup table combined with linear interpolation, resulting in low computational overhead and suitability for real-time operation within the vehicle planning cycle. Other models of this component can also be selected in practical applications, and this application does not impose any limitations on them. By incorporating road curvature into the interpolation input, the system enables the parameter continuity threshold to simultaneously reflect vehicle speed and road curvature, thereby ensuring that subsequent judgments on the continuity of candidate trajectories are consistent with the current road environment, reducing deviations caused by fixed thresholds, and improving the stability and executability of trajectory selection results.

[0180] In one optional implementation, after continuity verification, an intent recognition step based on feature space density clustering is further included: the lateral endpoint offset, lane occupancy, target lane occupancy, and average acceleration of each candidate trajectory are converted into feature vectors; the feature vectors are normalized and input into an unsupervised clustering algorithm or Gaussian mixture model to automatically discover the natural grouping boundaries of trajectory features, and output a confidence-weighted intent label. Further, the system maintains a sliding intent state buffer and uses a hidden Markov model or Kalman filter to perform temporal state estimation on the intent label sequence for continuous planning cycles; when the intent switching frequency exceeds a preset jitter threshold or adjacent cycle label conflicts are detected, the holding period of the current intent is automatically extended and a smoothed locking label is output.

[0181] This invention improves the adaptability of continuity verification under different road conditions by introducing road curvature into the interpolation input of piecewise functions, so that the parameter continuity threshold can simultaneously reflect vehicle speed and road shape.

[0182] Figure 4 Flowchart of the vehicle trajectory filtering method provided in this application Figure 4 ,like Figure 4 As shown, this embodiment, based on the above embodiments, provides a detailed explanation of how to obtain the parameters of a piecewise function. The method includes:

[0183] S401. Obtain historical trajectory data.

[0184] Specifically, the onboard computing device acquires historical trajectory data accumulated during past planning or driving processes. Historical trajectory data refers to trajectory data accumulated during past planning or driving processes, which is used to determine the parameters of the piecewise function.

[0185] Historical trajectory data records the continuous deviation distribution of past effective trajectories, reflecting the actual range of permissible deviations under different vehicle speeds and road conditions. Compared to manually setting fixed values, using historical trajectory data as a parameter source allows the parameters of the piecewise function to be determined based on actual operating data, providing a data source for the piecewise function parameters.

[0186] S402. Based on the pre-trained threshold optimization model, the historical trajectory data is processed to obtain the parameters of the piecewise function.

[0187] Specifically, the onboard computing device inputs historical trajectory data into a pre-trained threshold optimization model, which processes the historical trajectory data and outputs the parameters of the piecewise function. The pre-trained threshold optimization model refers to a model pre-trained based on historical trajectory data to process the historical trajectory data and obtain the piecewise function parameters.

[0188] A pre-trained threshold optimization model is used to process historical trajectory data, enabling the piecewise function parameters to be determined based on the actual distribution of previously valid trajectories. The historical trajectory data contains continuous deviation information under different vehicle speeds and road conditions. By processing this information, the model outputs piecewise function parameters corresponding to each state parameter. Compared to manually configuring parameters, this method reduces biases caused by experience-based settings, making the parameter continuity thresholds more closely reflect actual driving conditions. The obtained parameters are used to determine the specific form of the piecewise function, which then participates in interpolation calculations with speed as input.

[0189] Historical trajectory data is used to characterize the vehicle's trajectory start-up state, speed changes, and trajectory continuity threshold calibration results under different road scenarios. This historical trajectory data can originate from the operation logs of mass-produced vehicles, simulation playback data, or manually verified test road data. A pre-trained threshold optimization model is used to perform correlation analysis between the state deviation distribution in the historical trajectory data and the executable trajectory results, and outputs the piecewise function parameters corresponding to each state parameter. These piecewise function parameters include the position of each segment node and the threshold coefficient within each segment interval.

[0190] In implementation, vehicle speed, lateral deviation, heading angle deviation, and acceleration deviation from historical trajectory data can be uniformly encoded and input into a pre-trained threshold optimization model. The model then fits the threshold variation patterns across different speed ranges based on the learned statistical characteristics of retained and discarded trajectory samples, thereby generating piecewise function parameters for interpolation calculations. This pre-trained threshold optimization model can be constructed using a neural network regression model, a gradient boosting tree model, or a combination thereof, and is trained offline using a large number of historical trajectory samples to ensure that the output parameters match the trajectory filtering requirements in urban roads, highways, and complex intersection scenarios. In practical applications, other model types can also be selected, and this application does not limit this choice.

[0191] During operation, the pre-trained threshold optimization model first extracts features and performs threshold regression on historical trajectory data. Then, based on the trajectory validity label, it jointly optimizes the segmentation points and threshold slope, ultimately obtaining the piecewise function parameters and writing them into the parameter table of the trajectory filtering module. Subsequently, during online trajectory filtering, the system can call this parameter table to interpolate the continuity thresholds corresponding to the current speed and road curvature, ensuring that the starting point deviation verification of candidate trajectories is based on a unified piecewise threshold.

[0192] With this implementation method, the piecewise function parameters can be generated by historical trajectory data and remain consistent with the statistical fitting results of the pre-trained threshold optimization model, enabling the trajectory continuity threshold to have a more stable scene adaptability, thereby improving the consistency and executability of the candidate trajectory screening results.

[0193] In some alternative implementations, S402 above includes:

[0194] S4021. Obtain historical trajectory data samples.

[0195] Specifically, the onboard computing device selects historical trajectory data samples for training from historical trajectory data. Historical trajectory data samples refer to sample data selected from historical trajectory data used to train the pre-trained threshold optimization model.

[0196] Using historical trajectory data samples as training input ensures that model training has a clear data source. Sample selection can be based on conditions such as vehicle type, driving scenario, or data time range, ensuring that the data used for training corresponds to the current application scenario and provides a basis for parameter updates.

[0197] S4022. Train the initial model based on historical trajectory data samples and update the parameters of the piecewise function.

[0198] Specifically, the onboard computing device trains the initial model using historical trajectory data samples and updates the parameters of the piecewise function based on the training results. The initial model refers to a pre-trained threshold optimization model that has not yet been trained or updated in terms of parameters.

[0199] The initial model is trained using historical trajectory data samples, allowing the parameters of the piecewise function to be continuously updated based on the sample data. As historical trajectory data accumulates, the model can adjust the parameters based on new samples, adapting the piecewise function parameters to the deviation distribution under different vehicle types, driving habits, or environmental conditions. The updated parameters are used to determine the piecewise function, which then participates in interpolation calculations with speed as input.

[0200] Historical trajectory data samples are used to characterize the trajectory evolution patterns of vehicles under different road scenarios. The samples can consist of historical driving records from urban roads, highways, and complex intersections, and include vehicle speed, trajectory start-point state parameters, trajectory point sequences, and trajectory executability annotation information. The initial model is used to carry the parameterized expression of the piecewise function, which can take a piecewise linear form to model the mapping relationship between speed and parameter continuity thresholds. In practical applications, this initial model can also use other models with parameter update capabilities; this application does not impose any limitations on this.

[0201] After acquiring historical trajectory data samples, the velocity characteristics, state deviation characteristics, and trajectory selection results from the samples are input into the initial model. This allows the model to adjust the slope, inflection point position, and threshold boundary parameters of each segment of the piecewise function based on the selection conclusions under different operating conditions in the historical samples. The training process can be performed by minimizing the error between the predicted threshold and the historically labeled threshold. Combined with gradient descent or other parameter optimization methods, the model parameters are iteratively updated until the continuity threshold output of the piecewise function for different velocity ranges meets the preset convergence condition. After training, the obtained piecewise function parameters reflect the correspondence between the continuity and executability of the trajectory starting point in the historical trajectory data and serve as the basis for threshold interpolation in subsequent trajectory selection.

[0202] The training process uses historical trajectory data samples to correct the parameters of the initial model, enabling the piecewise function to adapt to threshold variations under different speeds and road conditions. Since the parameter updates are derived from real historical trajectory samples, the continuity threshold output by the model has a consistent mapping relationship with vehicle state deviations, thus providing a stable threshold basis for subsequent trajectory filtering. After training, the piecewise function parameters no longer rely on fixed empirical values ​​but instead form a threshold expression that matches historical driving behavior, thereby improving the stability and executability of continuity verification in the trajectory filtering process.

[0203] In one alternative implementation, a scenario-context-adaptive scoring mechanism can be introduced in the generation of parameter continuity thresholds or subsequent game decision-making: scenario context features such as road grade, vehicle speed range, and surrounding vehicle density are extracted in real time, and a weight allocation matrix for each decision factor is dynamically generated through a lightweight attention network. Based on this, a non-cooperative game theory model is introduced to calculate the Nash equilibrium payoff under each intention, replacing the fixed linear weighted summation. Furthermore, the system continuously monitors the driver's micro-operation signals and calculates their deviation from the selected optimal intention; when the deviation consistently exceeds a safety threshold, an intention confidence decay mechanism is triggered, downgrading the original optimal intention to a candidate set and re-enabling the conservative strategy output.

[0204] The embodiments of the present invention obtain the parameters of the piecewise function by processing historical trajectory data with a pre-trained threshold optimization model, and support training and updating the model based on historical trajectory data samples, so that the parameter continuity threshold can be adjusted with actual data.

[0205] Figure 5 Flowchart of the vehicle trajectory filtering method provided in this application Figure 5 ,like Figure 5 As shown, this embodiment, based on the above embodiments, provides a detailed explanation of the dynamic limit verification method, which includes:

[0206] S501. Obtain the dynamic parameters of each trajectory point in the second trajectory set.

[0207] Specifically, the onboard computing device traverses the trajectory points of each candidate trajectory in the second trajectory set and reads the dynamic parameters at each trajectory point. Dynamic parameters refer to parameters that characterize the vehicle's motion state at the trajectory point, including curvature, rate of change of curvature, longitudinal acceleration, lateral acceleration, and jerk.

[0208] Dynamic parameters reflect the vehicle's motion state at trajectory points and are the basis for determining whether a trajectory is within the vehicle's executable range. The point-by-point reading method allows subsequent limit comparisons to be performed point-by-point, thereby identifying candidate trajectories that do not meet dynamic constraints at the point-level granularity.

[0209] S502. Based on a preset set of piecewise linear functions, interpolate the dynamic parameters to obtain dynamic limits.

[0210] Specifically, the onboard computing device takes the velocity or dynamic parameters at the trajectory points as input and performs interpolation calculations within a preset set of piecewise linear functions to obtain the dynamic limits corresponding to each dynamic parameter. The dynamic limit refers to the allowable range of values ​​for a given dynamic parameter obtained by interpolating it based on the preset set of piecewise linear functions.

[0211] By interpolating dynamic parameters using a pre-defined set of piecewise linear functions, the dynamic limits are adjusted according to the changes in motion state at the trajectory points. Vehicles exhibit varying tolerances to parameters such as curvature and acceleration at different speeds. Describing these differences using a set of piecewise linear functions allows the limits to match the vehicle's capabilities at that point, providing a benchmark for point-by-point comparisons.

[0212] S503. Filter out candidate trajectories that do not exceed the dynamic limit to obtain the third trajectory set.

[0213] Specifically, the on-board computing device compares the dynamic parameters of each trajectory point with the corresponding dynamic limits one by one, and retains the candidate trajectories in which none of the trajectory points exceed the dynamic limits, thus forming a third trajectory set.

[0214] By comparing point by point using dynamic limits as the criterion, candidate trajectories with dynamic violations can be identified and eliminated. When a trajectory point exceeds the corresponding dynamic limit for any dynamic parameter, the candidate trajectory does not satisfy the dynamic constraints. The retained candidate trajectories are all within the dynamic limit range for each trajectory point and each dynamic parameter, making the third trajectory set physically executable.

[0215] In this embodiment, dynamic parameters are used to characterize the motion constraint state of candidate trajectories at each trajectory point, and may include control quantities corresponding to velocity, acceleration, jerk, lateral acceleration, yaw rate, or curvature. Each candidate trajectory in the second trajectory set consists of trajectory points arranged in time or arc length order. The system reads the dynamic parameters of each trajectory point in the trajectory filtering module and maps them uniformly to the same evaluation dimension for subsequent consistency verification.

[0216] The pre-defined piecewise linear function set consists of multiple linear functions divided according to dynamic parameter intervals. Each linear function describes the correspondence between dynamic limits and input variables under different operating conditions. During interpolation, the system takes the dynamic parameters of each trajectory point as input, finds the corresponding linear function in its interval, and calculates the corresponding dynamic limit based on the running speed, road curvature, or lateral motion state of the trajectory point, enabling the limit to change in real time with the vehicle state. This piecewise linear function set can be pre-stored in the controller's calibration table. In practical applications, different parameters can be configured according to vehicle type, tire adhesion conditions, or road grade; this application does not impose any limitations on this.

[0217] After obtaining the dynamic limits, the system compares the dynamic parameters of each candidate trajectory in the second trajectory set with the corresponding dynamic limits point by point. When the dynamic parameters of any trajectory point do not exceed the dynamic limit corresponding to that point, the trajectory is determined to satisfy the dynamic constraints; when any trajectory point exceeds the dynamic limit, the trajectory is removed from the set to be retained. After the above verification, candidate trajectories in which all trajectory points do not exceed the limits are retained to form the third trajectory set, which is then output to the subsequent collision verification module.

[0218] This implementation method enables dynamic constraints to be updated in conjunction with the vehicle's current operating state, and transforms discrete calibration relationships into continuous limit judgments through piecewise linear interpolation. This ensures that the trajectory selection results are consistent with the actual executable capability, reduces the probability of trajectories that do not meet the dynamic constraints entering subsequent stages, and improves the stability and availability of the third trajectory set.

[0219] In some alternative implementations, it also includes:

[0220] S504. Obtain the jerk of each trajectory point in the third trajectory set.

[0221] Specifically, the onboard computing device reads the jerk at each trajectory point in the third trajectory set. Jerk refers to the rate of change of acceleration over time.

[0222] Jeep acceleration reflects the drastic change in a vehicle's motion state and is an indicator of trajectory smoothness. While dynamic parameters such as curvature and acceleration reflect the instantaneous state at a trajectory point, jeep acceleration reflects the rate of change in state between adjacent trajectory points. Using jeep acceleration as a subsequent comparison object can further constrain the trajectory's performance in terms of motion smoothness.

[0223] S505. Compare the jerk with a preset fixed threshold to obtain the comparison result.

[0224] Specifically, the onboard computing device compares the jerk at each trajectory point with a preset fixed threshold to obtain the comparison result. The preset fixed threshold refers to a pre-configured fixed limit value used to determine whether the jerk is legal.

[0225] The allowable range of jerk is relatively weakly correlated with velocity; using a fixed threshold for comparison can reduce the number of query steps. By comparing whether the jerk of each trajectory point exceeds the limit, a judgment basis is provided for subsequent screening, reducing computational overhead while ensuring the effectiveness of the judgment.

[0226] S506. Select candidate trajectories that do not exceed the limit after comparison and obtain the updated third trajectory set.

[0227] Specifically, the onboard computing device retains the candidate trajectories whose comparison results are within the limit, forming the updated third trajectory set.

[0228] The smoothness of the trajectory is constrained by jerk, and candidate trajectories with excessively drastic changes in motion are eliminated. The retained candidate trajectories are within the limit in the jerk dimension, ensuring that the updated third trajectory set meets the smoothness requirements and provides input for subsequent collision verification.

[0229] The third trajectory set refers to the candidate trajectory set retained after the preceding continuity check and dynamic limit check. The jerk is the rate of change of acceleration at the trajectory point with respect to time, used to characterize the smoothness constraint of the vehicle trajectory in longitudinal or lateral dynamic changes. The preset fixed threshold is a constant threshold pre-configured in the vehicle trajectory planning controller. Its value can be determined according to the vehicle chassis response capability, comfort constraints and the sampling period of the control system. In practical applications, this fixed threshold can also be configured according to different vehicle platforms, which is not limited in this application.

[0230] In its implementation, after generating the third trajectory set, the trajectory planning controller sequentially reads the discrete trajectory points contained in each candidate trajectory and calculates the jerk of each trajectory point based on the velocity, acceleration, or pose change of adjacent trajectory points. The jerk can be calculated using a finite difference method, combining the acceleration difference between adjacent sampling times with the sampling time interval to obtain a dynamic change that can be used for verification under discrete trajectory data conditions. Subsequently, the controller compares the jerk of each trajectory point with a preset fixed threshold point by point. If the jerk of a trajectory point does not exceed the threshold, the candidate trajectory to which that point belongs is retained; if the jerk of any trajectory point exceeds the threshold, the candidate trajectory is removed from the third trajectory set. After this processing, the updated third trajectory set output only contains candidate trajectories that satisfy the jerk constraint.

[0231] This verification method not only constrains trajectory selection by static dynamic boundaries but also further restricts the dynamic variation amplitude between trajectory points, thereby ensuring that the retained candidate trajectories have more consistent acceleration continuity and control accessibility during execution. For scenarios such as urban roads, ramp merging, and intersection turning, this constraint enables subsequent collision verification and final trajectory output to be based on a more stable trajectory, thus improving the executability and continuity of the selection results.

[0232] In some alternative implementations, it also includes:

[0233] S507, Obtain lateral acceleration data.

[0234] Specifically, the onboard computing device reads the vehicle's lateral acceleration data. Lateral acceleration data refers to sensor data that characterizes the vehicle's lateral acceleration.

[0235] Lateral acceleration data reflects the lateral forces experienced by a vehicle during actual driving, and can demonstrate the impact of factors such as road adhesion conditions on the vehicle's capabilities. Using sensor data as the basis for limit correction allows the limits to extend beyond the range given by a pre-defined set of piecewise linear functions, further reflecting the vehicle's actual operating state.

[0236] S508, Dynamic limits are corrected based on lateral acceleration data.

[0237] Specifically, the onboard computing device corrects the dynamic limit based on the lateral acceleration data to obtain the corrected dynamic limit.

[0238] The dynamic limits are corrected using lateral acceleration data to ensure that the limits reflect the actual lateral forces experienced by the vehicle. When road surface adhesion conditions change, the lateral acceleration that the vehicle can withstand also changes. Correcting the limits based on sensor data can reduce deviations caused by differences between model assumptions and actual conditions, making the corrected dynamic limits more closely match the vehicle's current actual capabilities.

[0239] S509. Based on the corrected dynamic limit, candidate trajectories in the second trajectory set are selected to obtain the updated third trajectory set.

[0240] Specifically, the onboard computing device compares the dynamic parameters of each trajectory point in the second trajectory set with the corrected dynamic limits, retains the candidate trajectories that do not exceed the corrected dynamic limits, and forms the updated third trajectory set.

[0241] Using the corrected dynamic limits as the judgment criterion ensures that the results of the dynamic limit verification match the actual driving conditions. Compared to comparing limits given by a preset set of piecewise linear functions alone, the limits corrected based on sensor data can reflect the vehicle's current actual capacity, improving the accuracy of the retained trajectory in terms of physical feasibility.

[0242] The lateral acceleration data is used to characterize the lateral dynamic state of the vehicle during trajectory tracking. This data can be calculated from the vehicle chassis controller, inertial navigation sensors, or by fusing wheel speed and yaw rate. The sampling time is synchronized with the trajectory points in the second trajectory set. The dynamic limit is a pre-calculated constraint boundary for the dynamic parameters corresponding to the candidate trajectories in the second trajectory set. Its value can correspond to at least one of lateral acceleration, yaw rate, or steering-related parameters. When correcting the dynamic limit, the current lateral acceleration data is compared with a preset benchmark lateral acceleration threshold. Based on the comparison result, the original dynamic limit is increased or decreased in compensation. The compensation amount can be determined by a linear proportional coefficient, a piecewise function, or a lookup table to ensure that the corrected dynamic limit matches the vehicle's current lateral load state. In practical applications, the proportional coefficient, threshold, and lookup table parameters can be configured according to the vehicle model, tire adhesion conditions, and road type; this application does not impose any limitations on these.

[0243] After obtaining the corrected dynamic limits, candidate trajectories in the second trajectory set are screened one by one to determine whether the dynamic parameters corresponding to each candidate trajectory meet the corrected dynamic limit constraints. When a candidate trajectory does not exceed the corrected dynamic limits at any trajectory point, the candidate trajectory is retained and included in the updated third trajectory set; if any trajectory point exceeds the limit, the candidate trajectory is removed. By introducing lateral acceleration into the dynamic limit correction process, the dynamic constraints can be adaptively changed with the real-time lateral state of the vehicle, thus making the retained candidate trajectories closer to the current vehicle's executable boundaries.

[0244] This method first corrects the original dynamic limits based on the vehicle's real-time lateral acceleration, then uses the corrected constraint boundaries to perform a second round of filtering on the second trajectory set, finally outputting an updated third trajectory set. Because the dynamic limits are consistent with the vehicle's current lateral state, the trajectories in the resulting third trajectory set are more consistent in lateral dynamics, and the filtering results are more stable, providing more reliable candidate trajectory input for subsequent collision verification.

[0245] In some alternative implementations, it also includes:

[0246] S5001. Obtain the rate of curvature change of the candidate trajectories in the second trajectory set.

[0247] Specifically, the onboard computing device reads the rate of curvature change of each candidate trajectory in the second trajectory set. The rate of curvature change refers to the rate of change of curvature of the candidate trajectory with respect to the trajectory points.

[0248] The rate of change of curvature reflects the local bending trend of a trajectory and can characterize the motion characteristics of a trajectory segment within a local range. When the rate of change of curvature of a trajectory segment is large, the trajectory segment may be unexecutable within a local range. Using the rate of change of curvature as the object for overall screening can provide a basis for judging local feasibility.

[0249] S5002: Filter candidate trajectories whose rate of curvature change does not exceed the preset rate of change range to obtain the updated second trajectory set.

[0250] Specifically, the onboard computing device retains candidate trajectories whose rate of curvature change does not exceed the preset range, forming an updated second trajectory set.

[0251] By screening candidate trajectories using the rate of curvature change, localized unexecutable trajectory segments can be identified in advance. Compared to point-by-point dynamic limit comparison, screening by the rate of curvature change first can eliminate candidate trajectories with local problems at the trajectory segment level, avoiding point-by-point dynamic limit comparisons for trajectories with local problems and reducing the number of point-by-point comparisons.

[0252] S5003, Perform dynamic limit verification on the updated second trajectory set.

[0253] Specifically, the onboard computing device uses the updated second trajectory set as input for dynamic limit verification and performs dynamic limit verifications from S501 to S503.

[0254] Candidate trajectories screened for curvature change rate are used as input for dynamic limit verification, allowing point-by-point comparisons to be performed on a smaller set of trajectories. Since the updated second set of trajectories has excluded candidate trajectories with local problems, subsequent point-by-point comparisons do not need to be performed on these trajectories, thus reducing the number of point-by-point comparisons.

[0255] The rate of change of curvature is used to characterize the magnitude of curvature change of a candidate trajectory between adjacent trajectory points. Specifically, it can be calculated from the difference in curvature and the corresponding difference in arc length at two adjacent discrete trajectory points, or it can be obtained by differentiating the trajectory parameters with respect to the fitted trajectory curvature function. The preset range of the rate of change can be jointly determined by the vehicle steering system capability, tire adhesion conditions, and the allowable trajectory smoothness within the planning period, and can be stored in a threshold table within the controller.

[0256] After obtaining the curvature change rate of each candidate trajectory in the second trajectory set, the controller compares the curvature change rate with a preset range for each trajectory. When the curvature change rate of a candidate trajectory is within the range, it is retained in the updated second trajectory set; when the curvature change rate exceeds the range, the candidate trajectory is discarded. This process can be completed by the onboard processor calling the trajectory evaluation module. The trajectory evaluation module can be implemented using a discrete point traversal method or a batch calculation method of curvature sequences. In practical applications, other models of this module can also be selected, and this application does not limit this.

[0257] When performing dynamic limit verification on the updated second trajectory set, the controller can continue to read dynamic parameters such as velocity, acceleration, jerk, lateral acceleration, or yaw rate of each trajectory point, and perform verification based on the limit curve matching the current operating conditions of the vehicle. Candidate trajectories that exceed the limits are further filtered out. Since the curvature change rate screening has been completed before the dynamic limit verification, the trajectory set input to this verification stage has better smoothness and continuity, thus making the subsequent limit judgment more focused on the vehicle's actual executable boundaries.

[0258] During the process, the curvature change rate screening is used to first eliminate candidate trajectories with large abrupt changes in trajectory shape. The updated second trajectory set then enters the dynamic limit verification, thus forming a series relationship between the pre-smoothing constraint and the dynamic constraint. This series relationship enables the trajectory screening results to simultaneously satisfy curvature continuity and vehicle dynamics feasibility, and eliminates candidate trajectories that do not meet the execution conditions as early as possible.

[0259] By adopting this implementation method, the number of curvature change trajectories entering subsequent dynamic judgment can be reduced without increasing the collision verification burden, thus reducing the amount of invalid calculations and ensuring that the final retained candidate trajectories maintain consistency in geometry and dynamic executability, thereby improving the stability and usability of trajectory selection results.

[0260] In one optional implementation, prior to data integrity verification, a segment-level compliance verification based on road topology is included: using Voronoi diagrams or Lanelet2 topological relationships, candidate trajectories are divided into several spatial intervals, and the lateral deviation distribution between trajectory points and corresponding lane centerlines and boundaries within each interval is calculated; simultaneously, combined with the semantic information of temporary traffic signs extracted in real time by onboard vision sensors, a dynamic rule weight matrix is ​​constructed to perform segmented compliance scoring on the global trajectory path, and those below a threshold are eliminated. Further, after passing the verification, the system can also perform a traffic light phase tolerance prediction step: combining the periodicity of traffic lights with the vehicle's current position, the theoretical time interval for each candidate trajectory to reach the stop line is predicted; if the trajectory arrival time slightly overlaps with the green light phase but is physically feasible, the system does not directly eliminate it, but instead assigns a yellow light tolerance label to the trajectory and passes it to the subsequent game-theoretic decision-making module for weighted evaluation.

[0261] The embodiments of the present invention complete the dynamic limit verification by comparing trajectory points one by one with dynamic limits, and support further refinement of the verification process with jerk, lateral acceleration data and curvature change rate, so that the retained candidate trajectory meets the requirements in terms of physical executability and smoothness.

[0262] Figure 6 Flowchart of the vehicle trajectory filtering method provided in this application Figure 6 ,like Figure 6 As shown, this embodiment, based on the above embodiments, provides a detailed description of collision verification. The method includes:

[0263] S601, Obtain the object occupancy of static obstacles.

[0264] Specifically, the onboard computing device reads the object occupancy of static obstacles. Static obstacles refer to obstacles whose position does not change within a certain period of time and do not move over time. Object occupancy refers to the geometric area occupied by a static obstacle on a two-dimensional plane.

[0265] Object occupancy describes the spatial extent of static obstacles in the form of geometric regions, providing a comparison object for subsequent intersection tests. Compared to describing obstacles using a single coordinate point, describing them using geometric occupancy regions provides a clear geometric basis for collision determination, enabling the accurate expression of the spatial relationship between vehicle occupancy and obstacles.

[0266] S602. Discretize the candidate trajectories in the third trajectory set in time to generate vehicle occupancy at each time point.

[0267] Specifically, the onboard computing device discretizes the candidate trajectories in the third trajectory set at time intervals, generating vehicle occupancy at each discrete moment. Vehicle occupancy refers to the geometrically occupied area of ​​a vehicle on a two-dimensional plane after the candidate trajectory is discretized at a certain moment.

[0268] The continuous trajectory is decomposed into several discrete time points, transforming the time dimension of the trajectory into multiple positions that can be determined moment by moment. The candidate trajectory describes the vehicle's motion process over a future period of time, and a collision may occur at any of these time points. By discretizing the trajectory into several time points, the spatial relationship between the vehicle's position and the obstacle can be determined at each time point, providing input for subsequent moment-by-moment intersection tests.

[0269] S603. Perform an intersection test between the vehicle occupancy and the object occupancy, and filter out candidate trajectories whose test results do not show any intersection, to obtain the updated third trajectory set.

[0270] Specifically, the onboard computing device performs intersection tests on vehicle and object occupancy at each time step, retaining candidate trajectories where no occupancy intersection occurs, thus forming an updated third trajectory set. Intersection testing refers to the process of detecting whether there is an overlapping area between vehicle and object occupancy on a two-dimensional plane.

[0271] The collision determination criteria are formed by the intersection test results at each time step. When there is no intersection of occupants at any time step, the candidate trajectory is considered to have no collision. If the vehicle occupant and the object occupant overlap at a certain time step, it indicates that the candidate trajectory has a spatial conflict with the static obstacle at that time step. Therefore, candidate trajectories that have a spatial conflict with the static obstacle at any discrete time step are eliminated, making the updated third trajectory set spatially feasible.

[0272] In this embodiment, the object occupancy of static obstacles is used to characterize the geometric boundary of stationary targets in a two-dimensional plane within a road environment. Static obstacles may include roadside guardrails, fixed posts, curbs, construction barriers, parked vehicles, or other targets whose positions do not change significantly within the current planning period. Object occupancy can be represented by the obstacle contour point set, minimum bounding rectangle, circular envelope, or polygonal envelope output by the perception module, and uniformly transformed to the local coordinate system where the vehicle is located for unified calculation with the trajectory occupancy area. The candidate trajectories in the third trajectory set represent feasible trajectory sequences that have undergone prior screening; their trajectory points typically include position, heading angle, curvature, and corresponding time parameters.

[0273] After acquiring the object occupancy of static obstacles, the candidate trajectories are discretized at preset time intervals. These time intervals can be consistent with the control refresh cycle within the planning period. The discretized trajectory points at each moment are used to represent the vehicle's estimated position at different times. Vehicle occupancy can be constructed based on the vehicle's external dimensions and discrete trajectory points. Specifically, the rectangular shape, the expanded shape with a safety margin, or the discrete polygon shape of the vehicle in its current posture can be mapped to each moment, thus obtaining the vehicle occupancy set for each moment. If the vehicle undergoes a turning angle change, the vehicle occupancy can also be combined with the heading angle to rotate the external contour, ensuring that the occupancy shape matches the vehicle's actual posture.

[0274] When performing intersection tests between vehicle occupancy and object occupancy, it can be determined whether there is geometric overlap, boundary contact, or crossing relationship between the two. When a vehicle occupancy intersects with the object occupancy of any static obstacle at any discrete moment, the corresponding candidate trajectory is identified as a collision risk trajectory and is eliminated. When no occupancy intersection is detected at any discrete moment, the candidate trajectory is retained in the updated third trajectory set. This updated third trajectory set serves as the output result after collision verification and can continue to the subsequent trajectory optimization or control distribution stages.

[0275] This implementation model unifies the geometric occupancy of static obstacles and the temporal occupancy of vehicles, and performs intersection determination in the discrete time dimension. This matches the collision judgment with the dynamic evolution of the trajectory, enabling the screening results to accurately reflect the actual traffic safety of candidate trajectories within the planning period. Since only candidate trajectories without occupancy intersections are retained, the executability and stability of the output set are maintained, and the invalid calculations caused by collision-risk trajectories entering subsequent decision-making stages are reduced.

[0276] In some alternative implementations, after S603 above, the following is also included:

[0277] S604. Obtain the vehicle outline and the object outline of static obstacles.

[0278] Specifically, the onboard computing unit reads the vehicle's outline and the object outline of static obstacles. The vehicle outline refers to the geometric boundaries of the vehicle in a two-dimensional plane. The object outline refers to the geometric boundaries of static obstacles in a two-dimensional plane.

[0279] Vehicle and object contours provide a more refined description of boundaries than geometrically occupied areas. Object and vehicle occupancy are typically represented by simplified geometry, while contours describe the actual boundaries. Using contours as the objects of intersection detection can provide a basis for refining intersection testing.

[0280] S605. Detect the vehicle outline and object outline to obtain the outline detection result.

[0281] Specifically, the onboard computing device performs geometric intersection detection on the vehicle outline and the object outline to obtain the outline detection result.

[0282] Instead of comparing simplified geometric regions, the intersection detection of vehicle and object contours allows collision determination to proceed at the boundary description level. In S603, intersection testing using occupants can quickly eliminate candidate trajectories that obviously do not conflict. For candidate trajectories where occupants overlap, further contour detection can improve the accuracy of the determination.

[0283] S606. Select candidate trajectories that do not intersect with the contour detection results to obtain the effective trajectory.

[0284] Specifically, the onboard computing device retains candidate trajectories that do not intersect with the contour detection results, thus obtaining the effective trajectory.

[0285] The contour detection results are used as the final judgment criterion to ensure that the retained trajectories do not have spatial conflicts at the boundary level. The candidate trajectories retained after two levels of judgment, namely, the occupancy intersection test and the contour intersection test, meet the requirements in terms of spatial safety and can be used as input for subsequent decision modules.

[0286] The vehicle contour represents the vehicle's circumscribed boundary in its current posture and can be determined by the vehicle's length, width, wheelbase, and body offset parameters. The object contour represents the outer boundary of a static obstacle in the map coordinate system or vehicle coordinate system, and is typically composed of obstacle polygons, grid occupants, or fused boundary point sets output by the perception module. In practical applications, the vehicle contour can be a rectangular envelope, a polygonal envelope, or a convex hull contour generated based on the vehicle body model. The object contour of a static obstacle can be a polygonal contour obtained by fitting laser point clouds or a fixed occupant contour annotated by a high-precision map; this application does not impose any limitations on these aspects.

[0287] After acquiring the vehicle contour and the object contour of the static obstacle, the system maps the vehicle pose corresponding to the candidate trajectory to a unified coordinate system and performs geometric detection based on the vehicle contour and object contour. Geometric detection can be implemented using polygon intersection judgment, boundary separation axis judgment, or overlap judgment. The detection results are used to output two types of states: the vehicle contour and the object contour have an intersection relationship, or the vehicle contour and the object contour do not intersect. When the contour detection result shows no intersection, the corresponding candidate trajectory is retained as a valid trajectory; when the contour detection result shows intersection, the corresponding candidate trajectory is discarded.

[0288] In this implementation, the contour detection results directly reflect the spatial safety relationship between candidate trajectories and static obstacles. Based on this, the system completes the end-point screening of the third trajectory set and outputs the valid trajectories. Since the detection is based on the geometric relationship between the vehicle contour and the object contour, it can promptly eliminate trajectories that interfere with the boundary of static obstacles, thereby ensuring that the final retained trajectory satisfies the static collision constraints and complements the preceding continuity check and dynamic limit check.

[0289] In some alternative implementations, S603 above includes:

[0290] S6031. Convert the object space of a static obstacle into an outer rectangle in a preset two-dimensional grid space index.

[0291] Specifically, the onboard computing device converts the object occupancy of static obstacles into a circumscribed rectangle and stores it in a preset two-dimensional grid spatial index according to its position. A circumscribed rectangle is a rectangle that is externally tangent to the object occupancy of the static obstacle and whose sides are parallel to the coordinate axes. A preset two-dimensional grid spatial index is an index structure formed by dividing a two-dimensional plane into grid cells and storing the obstacle's position in the corresponding grid cell.

[0292] By organizing the bounding rectangles of obstacles into grid cells, the relevant grid cells can be located based on their position during the query. Compared to comparing all obstacles one by one, storing obstacles in grid cells by position can narrow down the range of obstacles to be compared during the query phase, reducing the need for one-by-one comparisons of all obstacles.

[0293] S6032. Based on the bounding rectangle query, static obstacles that overlap with vehicle occupancy are identified.

[0294] Specifically, the onboard computing device queries for static obstacles that overlap with the vehicle's location based on the grid cell where the vehicle occupies the space.

[0295] By using grid cells as the query scope, the number of static obstacles participating in the intersection test is reduced. A vehicle occupies only a limited area in a two-dimensional plane at any given time, and the number of grid cells associated with that area is limited. Querying based on grid cells can localize the scope of the intersection test and avoid comparing irrelevant obstacles in the distance.

[0296] S6033. Perform an intersection test on the static obstacles found.

[0297] Specifically, the onboard computing unit performs intersection tests on the identified static obstacles.

[0298] The size of the query results is smaller than that of all static obstacles. Performing intersection tests with the query results as input allows the intersection tests to be performed on a smaller set of obstacles, reducing the computational cost of the intersection tests.

[0299] In this embodiment, object occupancy is used to characterize the area occupied by a static obstacle in the planned coordinate system, vehicle occupancy is used to characterize the outline occupied by a vehicle at a discrete moment, and a preset two-dimensional grid spatial index is used to organize the spatial range by grid cells and establish a retrieval mapping. The circumscribed rectangle is the smallest axis-aligned rectangle that encloses the outline of the static obstacle occupancy, and its boundary is determined by the maximum and minimum coordinates of the obstacle occupancy and written into the cell set corresponding to the two-dimensional grid index, so as to quickly locate candidate obstacles according to their spatial position.

[0300] In actual processing, the system first calculates the bounding rectangle of the static obstacle based on its polygonal, rectangular, or point set contours, and then associates this bounding rectangle with the grid cells in the 2D grid index. When a vehicle occupies a grid cell, the system queries the set of static obstacles corresponding to the bounding rectangles that intersect with that cell and its adjacent cells, and then performs a precise intersection test on each obstacle in the set. The intersection test can be completed by combining polygonal edge intersection judgment, bounding box overlap judgment, and contour intersection point judgment. If the vehicle's position and the obstacle's position have overlapping areas or boundary crossings, it is determined to be an intersection.

[0301] By first performing spatial index screening based on the circumscribed rectangle, and then performing intersection tests on candidate obstacles, the large-scale static obstacle retrieval can be transformed into local candidate set calculation. By combining coarse screening with fine judgment, collision verification can reduce unnecessary computation while meeting geometric accuracy requirements, thus making collision judgment in vehicle trajectory screening more stable and suitable for real-time operation.

[0302] In some alternative implementations, S6032 above includes:

[0303] S60321, The preset two-dimensional grid spatial index is a spatiotemporal joint index.

[0304] Specifically, the preset two-dimensional grid spatial index adopts a spatiotemporal composite index. A spatiotemporal composite index refers to an index structure that organizes obstacles based on both location and time information to support queries.

[0305] Introducing time information in addition to location information allows the index to distinguish the location of obstacles by time. For obstacles that are in different locations at different times, the spatiotemporal composite index can make query results correspond to discrete time points, providing a time-matched set of obstacles for time-by-time intersection tests.

[0306] S60322. Based on the spatiotemporal joint index and the location information of static obstacles, query the static obstacles that overlap with the vehicle's parking space.

[0307] Specifically, the onboard computing device queries static obstacles that overlap with the vehicle's location based on a spatiotemporal joint index and the location information of static obstacles.

[0308] Executing queries using a spatiotemporal composite index ensures that the query results are related to both location and time. In the process of determining the spatial relationship between vehicle occupancy and obstacles at each time step, the spatiotemporal composite index provides the corresponding set of obstacles for each time step, providing input for time-by-time intersection testing.

[0309] The two-dimensional grid spatial index is an index structure obtained by dividing the space within a preset planar coordinate system according to a fixed grid size. Grid cells can be encoded according to the coordinate range of the vehicle's driving area, and the identifier of the grid cell into which a static obstacle falls is recorded. The spatiotemporal joint index is a composite index formed by introducing time-dimensional correlation information on the basis of the two-dimensional grid spatial index. It can map the location information of a static obstacle at the current planning time to the index nodes, so as to facilitate fast retrieval based on spatial adjacency. The location information of a static obstacle includes the coordinates of the obstacle's center, the coordinates of its circumscribed rectangle, or the area enclosed by its outline. The vehicle's occupancy can be represented by the circumscribed rectangle of the vehicle's outline at the current time.

[0310] In practical implementation, the bounding rectangle of a static obstacle can be calculated first based on its location information, and then mapped to one or more grid cells in the spatiotemporal joint index. Next, the set of grid cells covered by the bounding rectangle corresponding to the vehicle's location is determined, and then grid cells with spatial overlap with the vehicle's location are retrieved from the spatiotemporal joint index to obtain a candidate static obstacle set. Subsequently, the coordinate boundaries of each obstacle in the candidate static obstacle set are compared to determine whether its bounding rectangle overlaps with the bounding rectangle of the vehicle's location, and static obstacles that meet the overlap condition are output. If static obstacles are stored using a unified coordinate system, the retrieval process can be completed directly based on coordinate range queries; if static obstacles are stored using local road coordinates, coordinate transformation can be performed first, followed by index query. In this application, the spatiotemporal joint index can be implemented using a hash grid, a chained grid, or a compressed grid. In practical applications, other types of indexes can also be selected, and this application does not limit this.

[0311] This scheme combines spatial indexing with temporal correlation information, enabling the candidate set of static obstacles to be quickly determined within a small index range. It then utilizes the overlap of bounding rectangles to filter collision-related obstacles, thereby reducing the retrieval volume of irrelevant obstacles and improving query stability. Since the query results directly point to static obstacles that overlap with vehicle occupancy, the computational load of subsequent intersection tests can be significantly reduced, thus improving the processing efficiency and output consistency of trajectory collision verification.

[0312] In some alternative implementations, after S601 above, the following is also included:

[0313] Static obstacles are classified into obstacle categories. The detection priority of each static obstacle is determined based on its category. Intersection tests are then performed on the static obstacles according to their detection priority.

[0314] Specifically, the onboard computing device classifies static obstacles by type, resulting in obstacle categories. An obstacle category refers to the classification of static obstacles based on their type. Different categories of static obstacles have varying degrees of impact on trajectory passage. Distinguishing obstacles by category provides a basis for determining the detection order, ensuring that the sequence of intersection tests corresponds to the degree of impact of obstacles on trajectory passage.

[0315] Specifically, the onboard computing unit determines the detection priority of each static obstacle based on its category. Detection priority refers to the order in which static obstacles are subjected to intersection testing. Determining detection priority by category ensures that obstacles with a greater impact on trajectory passage are prioritized for intersection testing. Under conditions of limited computing resources, prioritizing the judgment of obstacles with a greater impact allows computing resources to be used more effectively for the judgment of critical obstacles, ensuring that the judgment results are obtained first on critical obstacles.

[0316] Specifically, the onboard computing unit performs intersection tests on static obstacles sequentially according to their detection priority. Performing intersection tests in order of priority ensures that the judgment result is obtained first for critical obstacles. For lower-priority obstacles, if the candidate trajectories identified in the previous judgment already conflict, a complete comparison is not required, reducing the computational investment for obstacles with less impact.

[0317] In this application, static obstacles can include roadside guardrails, roadside posts, traffic cones, traffic sign poles, stationary vehicles, and other targets whose positions remain unchanged during the planning period. Obstacle categories can be classified based on target size, geometric contour, occupied area, relative position to the lane centerline, and whether it is located at the boundary of a drivable area, and are jointly determined by target attributes output by the perception module, map element information, and historical frame stability information. Detection priority can be determined comprehensively by category, distance from the vehicle reference point, probability of potential contact with the current candidate trajectory, and obstacle occupancy complexity. Obstacles closer to the candidate trajectory, with more complex contour boundaries, or more likely to affect trajectory passability can be assigned higher priority, facilitating intersection judgment of high-risk targets first under limited computing resources. Intersection testing can use the occupancy polygon corresponding to the vehicle at discrete time points to perform geometric intersection judgment with the occupancy polygon of the static obstacle. If necessary, a coarse screening can be performed first using the circumscribed rectangle, followed by precise polygon intersection calculation for the hit targets. Obstacle attributes used for classification and priority calculation can be stored in the target cache area within the autonomous driving controller, and implemented in combination with a preset rule table or a lightweight classification model. The model used can be a rule-based label mapping model, a tree model, or a neural network model. In practical applications, other models can also be selected, and this application does not limit this.

[0318] This application categorizes static obstacles and establishes detection priorities, enabling intersection tests to be performed in order of risk and complexity. This allows high-impact targets to be verified first, while low-impact targets participate in the calculation only when necessary. Consequently, the computational allocation in the collision verification process is more concentrated, resulting in more stable output trajectories. Because intersection tests are organized according to priority, the controller can identify static obstacles that substantially affect the trajectory more quickly within the planning cycle and perform trajectory filtering accordingly, improving the real-time performance and consistency of collision verification results.

[0319] In one optional implementation, after collision verification, a safety fallback trajectory generation and injection step is also included: when the number of valid trajectories in the output results of data integrity verification, dynamic continuity filtering, dynamic limit verification and collision verification is lower than a preset threshold or is an empty set, the system immediately calls the preset emergency braking or safe side-by-side path model; combined with the current vehicle position, speed and surrounding obstacle distribution, a backup trajectory that meets the dynamic constraints and safety distance requirements is generated in real time, and the backup trajectory is forcibly injected into the downstream intention decision layer or control module to maintain the system's continuous control capability.

[0320] The embodiments of the present invention complete collision verification by intersecting vehicle and object occupancy, and support narrowing the query range with circumscribed rectangles and spatial indexes, using spatiotemporal joint indexes to correspond to discrete time points, and determining detection priority by obstacle category, so that collision verification reduces the amount of computation while ensuring the accuracy of the judgment.

[0321] Figure 7 Flowchart of the vehicle trajectory filtering method provided in this application Figure 7 ,like Figure 7 As shown, this embodiment, based on the above embodiments, provides a detailed explanation of the verification execution order and pre-screening. The method includes:

[0322] S701. Obtain the computational cost of vehicle system load and data integrity verification, dynamic limit verification and collision verification.

[0323] Specifically, the onboard computing unit reads the vehicle's system load and determines the computational costs of data integrity verification, dynamic limit verification, and collision verification. System load refers to the resource occupancy status of the onboard computing unit during trajectory screening. Computational cost refers to the computational overhead required for each of the data integrity verification, dynamic limit verification, and collision verification processes.

[0324] System load reflects the current resource utilization of the onboard computing device, while computing cost reflects the overhead differences of each verification level. Both provide a basis for adjusting the execution order, ensuring that the determination of the execution order takes into account both the current resource status of the device and the overhead characteristics of each verification level.

[0325] S702. Adjust the execution order based on system load and computing cost.

[0326] Specifically, the onboard computing device adjusts the execution order of each verification level based on the system load and the computational cost of each verification level.

[0327] When the system load is high, prioritizing verifications with lower computational costs allows invalid traces to be eliminated as early as possible in low-cost stages. Since invalid traces are eliminated in low-cost stages and do not enter high-cost stages, the number of traces entering high-cost stages is reduced accordingly, making the allocation of computational resources among verification levels adaptable to the current resource status of the device.

[0328] System load characterizes the resource occupancy status of the current planning controller, perception fusion module, and trajectory selection module. Computational cost characterizes the computational overhead required for data integrity verification, dynamic limit verification, and collision verification under the current number of candidate trajectories and environmental complexity. System load can be determined by processor utilization, memory utilization, cache hit status, task queue length, or communication bandwidth usage. Computational cost can be statistically analyzed based on the number of operations, number of trajectory points, number of obstacles, number of grid queries, and number of intersection tests for each verification stage. The statistical results can be converted into a unified cost index from a pre-calibrated time overhead model.

[0329] After acquiring the system load and computational cost, the controller maps the three types of verification steps to tasks to be executed and rearranges the task order according to the current load level. When the system load is high, data integrity verification, which has lower computational cost and a stronger effect on eliminating candidate trajectories, can be performed first, followed by dynamic limit verification, and finally collision verification. When the system load is low or the trajectory set is small, collision verification can be performed directly according to a preset priority. The order adjustment result can be written to the task scheduling queue, and the trajectory filtering main loop calls each verification module in the updated order to complete the filtering.

[0330] In terms of working principle, the system load reflects the current available computing power of the controller, and the computing cost reflects the resource consumption characteristics of each verification module. The combination of the two forms a dynamic scheduling basis, enabling the trajectory screening link to select a more suitable execution order under different working conditions, and to prioritize the allocation of limited computing resources to the verification link that is more critical to the identification of effective trajectories.

[0331] By adopting the above method, the execution order of data integrity verification, dynamic limit verification and collision verification can be adaptively adjusted according to the system load, thereby maintaining stable computational overhead in the trajectory selection process under complex traffic scenarios and making the output of effective trajectories more continuous.

[0332] In some optional implementations, prior to S701 above, the following is also included:

[0333] S7001. Extract the start and end points of the candidate trajectories and calculate the Euclidean distance between the start and end points.

[0334] Specifically, the onboard computing device extracts the start and end points of each candidate trajectory and calculates the Euclidean distance between them. Euclidean distance refers to the straight-line distance between the start and end points of a candidate trajectory in a two-dimensional plane.

[0335] The Euclidean distance between the starting and ending points reflects the overall range of the candidate trajectory. The candidate trajectory describes the vehicle's movement over a future period, and the distance between its starting and ending points is related to the planning cycle and vehicle speed. Using the Euclidean distance as a criterion allows for an assessment of the overall range of the candidate trajectory before full verification, providing a basis for determining whether further processing is needed.

[0336] S7002: Filter candidate trajectories whose Euclidean distance is less than or equal to a preset distance range.

[0337] Specifically, the onboard computing device retains candidate trajectories whose Euclidean distance is less than or equal to a preset distance range.

[0338] Candidate trajectories are pre-screened using Euclidean distance, eliminating those whose extension range exceeds a reasonable interval before proceeding to subsequent verification stages. This pre-screening reduces the number of candidate trajectories entering each subsequent verification stage, thus reducing the processing workload at each stage.

[0339] The candidate trajectory can be understood as a planning result composed of a sequence of trajectory points, with the starting point being the first trajectory point in the sequence and the ending point being the last trajectory point. Euclidean distance is used to characterize the straight-line distance between the starting and ending points in a two-dimensional or three-dimensional coordinate system, and it can be calculated based on the square root of the sum of the squares of the coordinate differences between the two points. A preset distance range can be stored in the vehicle controller's parameter table, and its value can be configured according to the trajectory span of the current planning scenario to limit the spatial closure of the candidate trajectory.

[0340] In its implementation, after receiving multiple candidate trajectories, the trajectory filtering module first parses the starting and ending points of each candidate trajectory and reads their position coordinates. Then, it inputs these coordinates into the distance calculation unit to obtain the corresponding Euclidean distance. If this distance is not greater than a preset distance range, the candidate trajectory is retained for subsequent data integrity verification; if the distance is greater than the preset distance range, it is directly discarded. The preset distance range can be set as a threshold interval related to the current vehicle speed, road curvature, or planning time domain. In practical applications, this threshold can also be configured according to different vehicle types, road grades, or control cycles; this application does not impose any limitations on this.

[0341] This processing method adds an initial screening constraint based on the spatial span of the trajectory's start and end points before data integrity verification. This causes candidate trajectories whose start and end points are too far apart and clearly do not conform to the current planned closed-loop characteristics to be excluded from subsequent processing. As a result, the set of trajectories entering integrity verification is more concentrated within the executable range. This reduces the number of invalid trajectories participating in subsequent judgments and makes the subsequent trajectory verification results more stable.

[0342] In one optional implementation, during the dynamic limit verification or final optimization stage, a multi-order kinematic comfort assessment based on human vestibular sensitivity can be constructed: in addition to the integrals of longitudinal and lateral jerk, a weighted combination of jerk and yaw rate of change is introduced to construct a nonlinear cost model that conforms to human comfort response standards for smoothness evaluation. Furthermore, the system can obtain the multi-occupant position distribution and personalized comfort preference labels through cabin environment sensors or user accounts to construct a multi-objective preference weight vector; when calculating the comprehensive comfort cost, the penalty coefficients for longitudinal stability and lateral steering are dynamically adjusted according to the passenger spatial distribution to output the optimal trajectory that takes into account the experience of multiple passengers.

[0343] In addition to data integrity verification, dynamic limit verification, and collision verification, this invention supports adjusting the execution order based on system load and computational cost, and supports pre-screening candidate trajectories based on the Euclidean distance between the start and end points, thereby enabling reasonable allocation of computational resources and reducing the number of invalid trajectories processed.

[0344] In this application, the vehicle's speed, status information, and multiple candidate trajectories are first acquired. The status information includes multiple status parameters. The start and end points of the candidate trajectories are extracted, and the Euclidean distance between the start and end points is calculated. Candidate trajectories whose Euclidean distance is less than or equal to a preset distance range are selected. When performing data integrity verification on the selected candidate trajectories, the data structure pointer of the candidate trajectory is first verified to be non-empty. Then, the length of the trajectory point sequence is checked. Candidate trajectories whose pointer verification result is non-empty and whose length check result is within the preset length range are retained as the first trajectory set. Subsequently, the status parameters are matched with a preset piecewise linear function table to obtain the piecewise function corresponding to each status parameter. The road curvature is also obtained. The speed and road curvature are input into the piecewise function for interpolation to obtain the parameter continuity threshold corresponding to each status parameter.

[0345] In one possible implementation, historical trajectory data samples are acquired, and an initial model is trained based on these samples to update the parameters of the piecewise function. Then, historical trajectory data is acquired again, and the model is optimized based on a pre-trained threshold to process the historical trajectory data and obtain the parameters of the piecewise function. For each candidate trajectory in the first trajectory set, the deviation between each state parameter at its starting point and the corresponding state parameter in the state information is calculated. Candidate trajectories with deviation values ​​less than the corresponding parameter continuity threshold are selected to form a second trajectory set. The dynamic parameters of each trajectory point in the candidate trajectories in the second trajectory set are acquired, and the dynamic parameters are interpolated based on a preset piecewise linear function set to obtain dynamic limits. Candidate trajectories that do not exceed the dynamic limits are selected to form a third trajectory set. Simultaneously, the jerk of each trajectory point in the third trajectory set is acquired, and the jerk is compared with a preset fixed threshold. Candidate trajectories whose comparison results do not exceed the threshold are retained. Lateral acceleration data is acquired, and the dynamic limits are corrected based on the lateral acceleration data. Finally, the candidate trajectories in the second trajectory set are selected based on the corrected dynamic limits.

[0346] In another possible implementation, the curvature change rate of candidate trajectories in the second trajectory set is also obtained. Candidate trajectories whose curvature change rate does not exceed a preset range are selected to form an updated second trajectory set. Then, a dynamic limit check is performed on the updated second trajectory set. When performing collision check on the third trajectory set, the object occupancy of static obstacles is obtained. The candidate trajectories in the third trajectory set are time-discretely processed to generate vehicle occupancy at each time point. The object occupancy of static obstacles is converted into a bounding rectangle in a preset two-dimensional grid spatial index. Based on the spatiotemporal joint index and the position information of static obstacles, static obstacles that overlap with vehicle occupancy are queried. Intersection tests are performed on the queried static obstacles, and candidate trajectories whose test results show no intersection are selected. Alternatively, vehicle contours and object contours of static obstacles can be obtained. Vehicle contours and object contours are detected, and candidate trajectories whose contour detection results show no intersection are selected to obtain valid trajectories. Static obstacles are classified, their detection priorities are determined, and intersection tests are performed on them according to these priorities. Simultaneously, the system load of the vehicle and the computational costs of data integrity verification, dynamic limit verification, and collision verification are obtained, and the execution order is adjusted based on the system load and computational costs.

[0347] Figure 8 A schematic diagram of the vehicle trajectory screening device provided in this application is shown below. Figure 8 As shown, the vehicle trajectory filtering device 80 provided in this embodiment includes:

[0348] The acquisition module 801 is used to acquire the vehicle's speed, status information, and multiple candidate trajectories. The status information includes multiple status parameters.

[0349] Processing module 802 is used to perform data integrity verification on candidate trajectories to obtain a first set of trajectories;

[0350] Processing module 802 is also used for:

[0351] Match the state parameters with a preset piecewise linear function table to obtain the piecewise function corresponding to each state parameter;

[0352] Processing module 802 is also used for:

[0353] Using velocity as input, the piecewise function is interpolated to obtain the parameter continuity thresholds corresponding to each state parameter;

[0354] Processing module 802 is also used for:

[0355] Calculate the deviation between the state parameters at the starting point of each candidate trajectory in the first trajectory set and the corresponding state parameters in the state information;

[0356] Processing module 802 is also used for:

[0357] Candidate trajectories whose deviation values ​​are all less than the corresponding parameter continuity threshold are selected to obtain the second trajectory set;

[0358] Control module 803 is used to perform dynamic limit verification on candidate trajectories in the second trajectory set to obtain the third trajectory set;

[0359] Control module 803 is also used for:

[0360] Collision checks are performed on the candidate trajectories in the third trajectory set to obtain the valid trajectories.

[0361] In one possible implementation, the processing module 802 is further configured to:

[0362] Verify whether the data structure pointer of the candidate trajectory is not null, and obtain the pointer verification result;

[0363] Check the length of the trajectory point sequence and obtain the length check result;

[0364] Candidate trajectories whose filter pointer verification results are not empty and whose length check results are within a preset length range are selected to obtain the first trajectory set.

[0365] In one possible implementation, the processing module 802 is further configured to:

[0366] Obtain the road curvature;

[0367] By inputting speed and road curvature into a piecewise function, the parameter continuity threshold is obtained.

[0368] In one possible implementation, the processing module 802 is further configured to:

[0369] Obtain historical trajectory data;

[0370] Historical trajectory data is processed using a pre-trained threshold optimization model to obtain the parameters of the piecewise function.

[0371] In one possible implementation, the processing module 802 is further configured to:

[0372] Obtain historical trajectory data samples;

[0373] The initial model is trained based on historical trajectory data samples, and the parameters of the piecewise function are updated.

[0374] In one possible implementation, the control module 803 is also used for:

[0375] Obtain the dynamic parameters of each trajectory point in the second trajectory set;

[0376] Dynamic limits are obtained by interpolating dynamic parameters based on a pre-defined set of piecewise linear functions;

[0377] Candidate trajectories that do not exceed the dynamic limit are filtered to obtain the third trajectory set.

[0378] In one possible implementation, the control module 803 is also used for:

[0379] Obtain the jerk of each trajectory point in the third trajectory set;

[0380] The jerk is compared with a preset fixed threshold to obtain the comparison result;

[0381] The candidate trajectories that do not exceed the limit are selected through a screening and comparison process, resulting in an updated third set of trajectories.

[0382] In one possible implementation, the control module 803 is also used for:

[0383] Obtain lateral acceleration data;

[0384] Dynamic limits are corrected based on lateral acceleration data;

[0385] Candidate trajectories in the second trajectory set are selected based on the revised dynamic limits to obtain the updated third trajectory set.

[0386] In one possible implementation, the control module 803 is also used for:

[0387] Obtain the rate of curvature change of the candidate trajectories in the second trajectory set;

[0388] Candidate trajectories whose rate of curvature change does not exceed the preset rate of change range are selected to obtain an updated second trajectory set;

[0389] Perform dynamic limit checks on the updated second trajectory set.

[0390] In one possible implementation, the control module 803 is also used for:

[0391] Obtain object placeholders for static obstacles;

[0392] Discretize the candidate trajectories in the third trajectory set in time to generate vehicle occupancy at each time point;

[0393] Intersection tests are performed between vehicle occupants and object occupants, and candidate trajectories with no occupant intersections are selected from the test results to obtain the updated third trajectory set.

[0394] In one possible implementation, the control module 803 is also used for:

[0395] Obtain the vehicle outline and the object outline of static obstacles;

[0396] Detect the vehicle outline and the object outline to obtain the outline detection results;

[0397] Candidate trajectories that do not intersect with each other are selected from the contour detection results to obtain the effective trajectories.

[0398] In one possible implementation, the control module 803 is also used for:

[0399] Convert the object space of static obstacles into the bounding rectangle in the preset two-dimensional grid space index;

[0400] Based on the query of static obstacles that overlap with vehicle occupancy, the bounding rectangle is used to locate them.

[0401] Perform an intersection test on the static obstacles found.

[0402] In one possible implementation, the control module 803 is also used for:

[0403] The preset two-dimensional grid spatial index is a spatiotemporal joint index;

[0404] Based on the spatiotemporal joint index and the location information of static obstacles, query static obstacles that overlap with vehicle occupancy.

[0405] In one possible implementation, the control module 803 is also used for:

[0406] Static obstacles are classified to obtain obstacle categories;

[0407] Determine the detection priority of each static obstacle based on its category;

[0408] Intersection tests are performed on static obstacles according to the detection priority.

[0409] In one possible implementation, the acquisition module 801 is also used for:

[0410] The computational costs of obtaining vehicle system load and data integrity verification, dynamic limit verification, and collision verification;

[0411] Adjust the execution order based on system load and computing costs.

[0412] In one possible implementation, the acquisition module 801 is also used for:

[0413] Extract the start and end points of the candidate trajectories, and calculate the Euclidean distance between the start and end points;

[0414] Filter candidate trajectories whose Euclidean distance is less than or equal to a preset distance range.

[0415] The vehicle trajectory screening device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0416] Figure 9 A schematic diagram of the structure of the electronic device provided in this application. Figure 9 As shown, the electronic device 90 provided in this embodiment includes at least one processor 901 and a memory 902. Optionally, the electronic device 90 further includes a communication component 903. The processor 901, memory 902, and communication component 903 are connected via a bus 904.

[0417] In the specific implementation process, at least one processor 901 executes computer execution instructions stored in memory 902, causing at least one processor 901 to perform the above method.

[0418] The specific implementation process of processor 901 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0419] This electronic device can be deployed in an autonomous driving domain controller. During the planning cycle, processor 901 reads vehicle speed, attitude, positioning information, and multiple candidate trajectories, and progressively completes trajectory filtering according to instructions in memory 902. Processor 901 first performs an integrity check on the candidate trajectories, then performs preliminary filtering based on the continuity relationship between the vehicle's current state and the trajectory's starting point, thus avoiding retaining obviously mismatched trajectories due to short-term deviations. Subsequently, processor 901 further verifies the dynamic feasibility of the trajectory and the collision risk with surrounding targets, and can combine map data, lane boundaries, and traffic rules for additional judgments, thereby eliminating trajectories that do not meet the execution conditions. Because the filtering link is segmented and constrained, redundant calculations and filtering are reduced, resulting in a more stable number of available trajectories and improved continuity and reliability of the planning output.

[0420] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0421] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0422] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0423] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0424] This computer program product can be deployed in autonomous driving domain controllers or onboard computing platforms. When executed by the processor, the program combines the vehicle's current speed, attitude, position, and candidate trajectory information to perform segmented verification and continuity constraint filtering of the trajectory. It further integrates perception, localization, high-precision maps, and chassis status to complete executability judgment, thereby avoiding retaining trajectories that are clearly mismatched with the current vehicle state, are dynamically unfeasible, or pose high risks in subsequent planning stages. Because the program can stably filter multiple candidate trajectories within a finite planning cycle, it reduces redundant and invalid calculations, resulting in a more stable number of usable trajectories and stronger executability in the final output. This improves the continuity and reliability of trajectory decision-making in urban roads, highways, and complex intersection scenarios.

[0425] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0426] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0427] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0428] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0429] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0430] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0431] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0432] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0433] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for selecting vehicle trajectories, characterized in that, include: The vehicle's speed, status information, and multiple candidate trajectories are acquired, wherein the status information includes multiple status parameters; The candidate trajectories are subjected to data integrity verification to obtain a first trajectory set; The state parameters are matched with a preset piecewise linear function table to obtain the piecewise function corresponding to each state parameter. Using the speed as input, the piecewise function is interpolated to obtain the parameter continuity thresholds corresponding to each state parameter; Calculate the deviation between each state parameter at the starting point of the candidate trajectory in the first trajectory set and the corresponding state parameter in the state information; Candidate trajectories whose deviation values ​​are all less than the corresponding parameter continuity threshold are selected to obtain a second trajectory set; The candidate trajectories in the second trajectory set are subjected to dynamic limit verification to obtain the third trajectory set; Collision verification is performed on the candidate trajectories in the third trajectory set to obtain the valid trajectories.

2. The method according to claim 1, characterized in that, The data integrity verification includes: Verify whether the data structure pointer of the candidate trajectory is not null, and obtain the pointer verification result; Check the length of the trajectory point sequence and obtain the length check result; Candidate trajectories whose filter pointer verification results are not empty and whose length check results are within a preset length range are selected to obtain the first trajectory set.

3. The method according to claim 1, characterized in that, Interpolating the piecewise function using the speed as input further includes: Obtain the road curvature; The speed and the road curvature are input into the piecewise function to obtain the parameter continuity threshold.

4. The method according to claim 1, characterized in that, The parameters of the piecewise function are obtained through the following steps: Obtain historical trajectory data; The historical trajectory data is processed based on a pre-trained threshold optimization model to obtain the parameters of the piecewise function.

5. The method according to claim 4, characterized in that, The training of the pre-trained threshold optimization model includes: Obtain historical trajectory data samples; The initial model is trained based on the historical trajectory data samples, and the parameters of the piecewise function are updated.

6. The method according to claim 1, characterized in that, The dynamic limit verification includes: Obtain the dynamic parameters of each trajectory point in the second trajectory set; Dynamic limits are obtained by interpolating the dynamic parameters based on a preset set of piecewise linear functions; Candidate trajectories that do not exceed the dynamic limit are filtered to obtain a third set of trajectories.

7. The method according to claim 6, characterized in that, The dynamic limit verification also includes: Obtain the jerk of each trajectory point in the third trajectory set; The jerk is compared with a preset fixed threshold to obtain the comparison result; The candidate trajectories that do not exceed the limit are selected through a screening and comparison process, resulting in an updated third set of trajectories.

8. The method according to claim 6, characterized in that, The dynamic limit verification also includes: Obtain lateral acceleration data; The dynamic limit is corrected based on the lateral acceleration data; The candidate trajectories in the second trajectory set are filtered based on the revised dynamic limits to obtain the updated third trajectory set.

9. The method according to claim 6, characterized in that, The dynamic limit verification also includes: Obtain the rate of curvature change of the candidate trajectories in the second trajectory set; Candidate trajectories whose rate of curvature change does not exceed the preset rate of change range are selected to obtain an updated second trajectory set; Perform the dynamic limit check on the updated second trajectory set.

10. The method according to claim 1, characterized in that, The collision verification includes: Obtain object placeholders for static obstacles; Discretize the candidate trajectories in the third trajectory set in time to generate vehicle occupancy at each time point; The intersection test is performed between the vehicle occupancy and the object occupancy, and candidate trajectories with no occupancy intersection are selected from the test results to obtain the updated third trajectory set.

11. The method according to claim 10, characterized in that, The collision verification also includes: Obtain the vehicle outline and the object outline of the static obstacle; The vehicle outline and the object outline are detected to obtain the outline detection result; Candidate trajectories that do not intersect with each other are selected from the contour detection results to obtain the effective trajectories.

12. The method according to claim 10, characterized in that, The intersection test between the vehicle's location and the object's location includes: The object space of the static obstacle is converted into the bounding rectangle in the preset two-dimensional grid space index; Based on the query of the bounding rectangle, there are static obstacles that overlap with the vehicle's position; Perform the intersection test on the static obstacles found.

13. The method according to claim 12, characterized in that, Based on the query of the circumscribed rectangle, static obstacles that overlap with the vehicle's location include: The preset two-dimensional grid spatial index is a spatiotemporal joint index; Based on the spatiotemporal joint index and the location information of the static obstacles, query the static obstacles that overlap with the vehicle's location.

14. The method according to claim 10, characterized in that, The collision verification also includes: The static obstacles are classified to obtain obstacle categories; The detection priority of each static obstacle is determined based on the obstacle category; The intersection test is performed on the static obstacle according to the detection priority.

15. The method according to claim 1, characterized in that, Also includes: The computational costs of obtaining the vehicle's system load and the data integrity verification, dynamic limit verification, and collision verification are calculated. The execution order is adjusted based on the system load and the computing cost.

16. The method according to claim 1, characterized in that, Before performing data integrity verification on the candidate trajectory, the method further includes: Extract the start and end points of the candidate trajectories, and calculate the Euclidean distance between the start and end points; Candidate trajectories whose Euclidean distance is less than or equal to a preset distance range are filtered.

17. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1 to 16.

18. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 16.

Images