Control method, device, equipment, medium and product of autonomous vehicle

Abstract

The application discloses a control method, device, equipment, medium and product of an automatic driving vehicle, and belongs to the technical field of automatic driving. The control method of the automatic driving vehicle comprises the following steps: in response to detecting that the automatic driving vehicle is in a static state, acquiring current scene information; in the case that it is determined that the current scene information does not hit a preset waiting white list, starting a first timer and a second timer; in the case that the first timer or the second timer reaches a corresponding preset threshold, determining whether the automatic driving vehicle is trapped based on at least two of the following: a planning failure number, an obstacle feature, a passable nature, a reversing space and a path progress; and in the case that it is determined that the automatic driving vehicle is trapped, performing an untrapping operation. The control method of the automatic driving vehicle of the application greatly reduces the false positive rate, makes the trapped recognition more accurate, and avoids the misjudgment of a single static duration criterion.

Description

Technical Field

[0001] This application belongs to the field of autonomous driving technology, and in particular relates to a control method, device, equipment, medium and product for an autonomous vehicle. Background Technology

[0002] Autonomous vehicles may become temporarily unable to move forward due to complex scenarios during operation (i.e., "stuck"). If this is not identified and handled in a timely manner, it will lead to road congestion. While some technologies use a single stationary time threshold to trigger stuck reporting, this method can trigger reports in normal parking scenarios such as waiting at traffic lights, vehicles queuing and crawling, and yielding to pedestrians, resulting in a large number of invalid work orders, a very high false alarm rate, and a single judgment criterion that cannot distinguish between being blocked by obstacles and normal waiting conditions, leading to a poor user experience. Summary of the Invention

[0003] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention proposes a control method, device, equipment, medium, and product for autonomous vehicles, which significantly reduces the false alarm rate, makes trapped vehicle identification more accurate, and avoids misjudgment based on a single criterion of stationary duration.

[0004] In a first aspect, this application provides a control method for an autonomous vehicle, applied to the autonomous vehicle, the autonomous vehicle being communicatively connected to a cloud; the method includes: In response to detecting that the autonomous vehicle is stationary, current scene information is acquired; If, based on the current scenario information, it is determined that the preset waiting whitelist has not been hit, a first timer and a second timer are started. The preset waiting whitelist is used to mark the autonomous vehicle as being in a normal waiting state. The first timer is used to accumulate the stationary duration under non-signal control constraints and pauses under signal control constraints. The second timer is used to accumulate the continuous stationary duration, and the accumulation after the second timer is started is unrelated to the hit status of the preset waiting whitelist. The preset threshold of the second timer is greater than the preset threshold of the first timer. If the first timer or the second timer reaches the corresponding preset threshold, it is determined whether the autonomous vehicle is trapped based on at least two of the following: number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress. If the vehicle is found to be stuck, an escape operation is performed. The escape operation includes executing a local active recovery strategy or sending the stuck scenario information and the escape request to the cloud. The stuck scenario information and the escape request are used for the cloud to output a work order. The work order is used for the cloud to confirm and then issue an escape command to the autonomous vehicle.

[0005] According to the control method for autonomous vehicles provided in the embodiments of this application, the false alarm rate is greatly reduced by filtering normal parking scenarios through a preset waiting whitelist. The risk of missed alarms in scenarios with repeated switching of traffic lights is eliminated by a dual timer mechanism (one pauses under signal control constraints and the other continues to accumulate). The identification of being trapped is more accurate by joint judgment of multi-dimensional auxiliary conditions, avoiding misjudgment based on a single static duration criterion.

[0006] One embodiment of the control method for an autonomous vehicle according to this application includes performing an escape operation, comprising: Based on at least two of the following factors: number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, determine whether the autonomous vehicle meets the local active recovery conditions. If the aforementioned local active recovery conditions are met, the local active recovery strategy will be executed. If the local active recovery conditions are not met, or if the local active recovery strategy is determined to have failed, the trapped scenario information and escape request are sent to the cloud.

[0007] One embodiment of the autonomous vehicle control method of this application, after sending the distress scene information and the escape request to the cloud, further includes: Once the autonomous vehicle resumes driving or is determined to be free from entrapment, it sends a message to the cloud to withdraw the entrapment request.

[0008] One embodiment of the control method for an autonomous vehicle according to this application includes sending information to the cloud to withdraw the extrication request when the autonomous vehicle resumes its driving state or is determined to be free from entrapment, comprising: If at least one of the following conditions is met, a message withdrawing the escape request will be sent to the cloud: The speed of the autonomous vehicle is restored to a level greater than or equal to a first speed threshold and remains there for a first duration; The planning confidence level of the path output by the planning module of the autonomous vehicle is greater than the first confidence level threshold, and the autonomous vehicle starts moving based on the path; Based on the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, it is determined that the autonomous vehicle is not trapped. The autonomous vehicle has been put into remote control.

[0009] One embodiment of the present application provides a method for controlling an autonomous vehicle, wherein the execution of a local active recovery strategy includes at least one of controlling the autonomous vehicle to sound its horn, replanning its driving path, and controlling the autonomous vehicle to move backward.

[0010] One embodiment of the control method for an autonomous vehicle in this application includes a preset waiting whitelist comprising at least one of the following: The current scene information indicates that the traffic light is in a red state; The current scene information indicates that there is a queue of vehicles ahead of the autonomous vehicle, and the speed of the queue of vehicles is lower than the second speed threshold. The current scene information indicates that there are pedestrians or non-motorized vehicles crossing, and the autonomous vehicle is in a waiting state; The current scene information indicates that there is a parking wait due to signal control traffic management constraints; The current scene information instructs the autonomous vehicle to pull over.

[0011] An embodiment of the autonomous vehicle control method of this application, wherein determining whether the autonomous vehicle is trapped based on at least two of the following: number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, includes: The autonomous vehicle is determined to be trapped if at least two of the following conditions are met: The number of planning failures is greater than or equal to the first failure threshold. The obstacle features indicate the presence of a static obstacle ahead; The lane availability indicator states that neither the left nor right adjacent lanes can be used for lane sharing. The reversing space indicator states that there is insufficient space behind the vehicle to complete the reversing operation; The path progress remains unchanged within the continuous determination window.

[0012] Secondly, this application provides a control method for an autonomous vehicle, applied in a cloud environment, wherein the cloud environment is communicatively connected to the autonomous vehicle; the method includes: Receive information about the distress situation and requests for escape from the autonomous vehicle; The trapped scenario information is matched with rules by a rule engine. If a preset rule is matched, a normal waiting flag or a high-risk escalation flag is output. If no preset rule is matched, the trapped scenario information is sent to a structured classification model. The trapped scene information is classified using the structured classification model, and classification labels are output based on the structured feature vectors. If the confidence level output by the structured classification model is less than the second confidence threshold, the trapped scene information is reviewed by a multimodal model, and the scene review results and suggested actions are output. Based on at least one of the normal waiting flag, high-risk escalation flag, classification label, scenario review result, and suggested action, a handling result corresponding to the trapped scenario is generated. The handling result is used to display or generate a work order. The work order is used to send to the autonomous vehicle for execution of the escape operation after confirmation.

[0013] The autonomous vehicle control method provided in this application uses a three-layer traffic splitting judgment architecture, enabling most cases to be processed directly at the rule layer, a small number of cases to be processed at the structured classification layer, and a very small number of cases to enter multimodal review. This significantly reduces overall cloud processing latency while ensuring that the quality of recommendations for complex scenarios is not degraded.

[0014] One embodiment of the control method for an autonomous vehicle according to this application further includes, after the output scenario review result and suggested actions: The suggested actions are subject to controlled action whitelist verification; If the suggested action is within the whitelist of controlled actions, a work order is generated based on the suggested action; The work order is sent to the autonomous vehicle.

[0015] One embodiment of the control method for an autonomous vehicle according to this application further includes, after the output scenario review result and suggested actions: The risk level of the suggested action is determined to obtain the risk level result; Based on the type of the suggested action and the risk level result, it is determined whether to display the suggested action or generate a work order based on the suggested action; If a work order is generated based on the suggested action and the work order has been confirmed, the work order is sent to the autonomous vehicle.

[0016] One embodiment of the control method for an autonomous vehicle according to this application further includes, after the output scenario review result and suggested actions: If the suggested action meets the access conditions corresponding to the vehicle remote management system, a work order is generated based on the suggested action. The work order is sent to the autonomous vehicle.

[0017] Thirdly, this application provides a control device for an autonomous vehicle, applied to the autonomous vehicle, which is communicatively connected to a cloud; the device includes: The first processing module is used to obtain current scene information in response to detecting that the autonomous vehicle is stationary. The second processing module is used to start a first timer and a second timer when it is determined that the preset waiting whitelist has not been hit based on the current scene information. The preset waiting whitelist is used to mark the autonomous vehicle as being in a normal waiting state. The first timer is used to accumulate the stationary time under non-signal control constraints and pause under signal control constraints. The second timer is used to accumulate the continuous stationary time. The accumulation after the second timer is started is unrelated to the hit status of the preset waiting whitelist. The preset threshold of the second timer is greater than the preset threshold of the first timer. The third processing module is used to determine whether the autonomous vehicle is trapped when the first timer or the second timer reaches the corresponding preset threshold, based on at least two of the following: the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress. The fourth processing module is used to perform an escape operation when it is determined that the vehicle is trapped. The escape operation includes executing a local active recovery strategy or sending the trapped scenario information and the escape request to the cloud. The trapped scenario information and the escape request are used for the cloud to output a work order. The work order is used for the cloud to confirm and then issue an escape command to the autonomous vehicle.

[0018] The control device for autonomous vehicles provided in the embodiments of this application significantly reduces the false alarm rate by filtering normal parking scenarios through a preset waiting whitelist, eliminates the risk of missed alarms in scenarios with repeated traffic light switching through a dual timer mechanism (one pauses under signal control constraints and the other continues to accumulate), and makes the identification of being trapped more accurate through joint judgment of multi-dimensional auxiliary conditions, avoiding misjudgment based on a single static duration criterion.

[0019] Fourthly, this application provides a control device for an autonomous vehicle, applied in a cloud environment, wherein the cloud environment is communicatively connected to the autonomous vehicle; the device includes: The fifth processing module is used to receive the distress scenario information and escape request sent by the autonomous vehicle; The sixth processing module is used to perform rule matching on the trapped scenario information through the rule engine. If a preset rule is matched, a normal waiting flag or a high-risk escalation flag is output. If no preset rule is matched, the trapped scenario information is sent to the structured classification model. The seventh processing module is used to classify the trapped scene information using the structured classification model and output classification labels based on the structured feature vectors. The eighth processing module is used to review the trapped scene information through a multimodal model when the confidence level output by the structured classification model is less than the second confidence level threshold, and output the scene review result and suggested actions. The ninth processing module is used to generate a handling result corresponding to the trapped scenario based on at least one of the normal waiting flag, high-risk escalation flag, classification label, scenario review result and suggested action. The handling result is used to display or generate a work order. The work order is used to send to the autonomous vehicle for execution of the escape operation after confirmation.

[0020] The control device for autonomous vehicles provided in this application uses a three-layer traffic splitting architecture, enabling most cases to be processed directly at the rule layer, a small number of cases to be processed at the structured classification layer, and a very small number of cases to enter multimodal review. This significantly reduces overall cloud processing latency while ensuring that the quality of recommendations for complex scenarios is not degraded.

[0021] Fifthly, this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the control method for an autonomous vehicle as described in the first and second aspects above.

[0022] In a sixth aspect, this application provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the control method for an autonomous vehicle as described in the first and second aspects above.

[0023] In a seventh aspect, this application provides a computer program product, including a computer program that, when executed by a processor, implements the control method for an autonomous vehicle as described in the first and second aspects above.

[0024] The above-described one or more technical solutions in the embodiments of this application have at least one of the following technical effects: By filtering normal parking scenarios through a pre-set waiting whitelist, the false alarm rate is significantly reduced. The risk of missed alarms in scenarios with repeated traffic light switching is eliminated through a dual timer mechanism (one pauses under signal control constraints and the other continues to accumulate). The joint judgment of multi-dimensional auxiliary conditions makes the identification of being trapped more accurate and avoids misjudgment based on a single static duration criterion.

[0025] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0026] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is a schematic diagram of the architecture of the control method for an autonomous vehicle provided in an embodiment of this application; Figure 2 This is one of the flowcharts illustrating the control method for an autonomous vehicle provided in this application embodiment; Figure 3 This is a second schematic flowchart of the control method for an autonomous vehicle provided in the embodiments of this application; Figure 4 This is the third flowchart illustrating the control method for an autonomous vehicle provided in this application embodiment; Figure 5 This is the fourth flowchart illustrating the control method for an autonomous vehicle provided in this application embodiment; Figure 6 This is the fifth flowchart illustrating the control method for an autonomous vehicle provided in this application embodiment; Figure 7 This is the sixth flowchart illustrating the control method for an autonomous vehicle provided in this application embodiment; Figure 8 This is the seventh flowchart illustrating the control method for an autonomous vehicle provided in this application embodiment; Figure 9 This is the eighth flowchart illustrating the control method for an autonomous vehicle provided in this application embodiment; Figure 10 This is the ninth flowchart illustrating the control method for an autonomous vehicle provided in this application embodiment; Figure 11 This is the tenth flowchart illustrating the control method for an autonomous vehicle provided in this application embodiment; Figure 12 This is one of the structural schematic diagrams of the control device for an autonomous vehicle provided in the embodiments of this application; Figure 13 This is a second schematic diagram of the structure of the control device for an autonomous vehicle provided in the embodiments of this application; Figure 14 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0028] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0029] The following description, in conjunction with the accompanying drawings, details the control method, control device, electronic equipment, and readable storage medium for autonomous vehicles provided in this application, through specific embodiments and application scenarios.

[0030] The control method for autonomous vehicles can be applied to the terminal, and can be executed by the hardware or software in the terminal.

[0031] The autonomous vehicle control method provided in this application can be executed by a vehicle-side (i.e., an onboard computing platform deployed on the autonomous vehicle and the software system running thereon), a cloud-side (i.e., a server deployed in a remote data center and the software system running thereon), or by a combination of vehicle-side and cloud-side execution. The autonomous vehicle control method provided in this application is described below with reference to the accompanying drawings.

[0032] Combination Figure 1 The overall system architecture applicable to this application is described. Figure 1 This is a schematic diagram of the overall system architecture provided for an embodiment of this application. Figure 1 As shown, the system includes a vehicle-side perception and initial screening module, a vehicle-side multi-dimensional judgment module, a cloud-based three-layer traffic triage judgment module, an execution and closed-loop feedback module, and an automatic withdrawal module. The vehicle-side perception and initial screening module is used to perform NW-List whitelist filtering and dual-timer judgment. The vehicle-side multi-dimensional judgment module is used to determine if a vehicle is trapped by considering multiple dimensions of information, such as planning failure, obstacle features, lane availability, and reversing space. The cloud-based three-layer traffic triage judgment module is used to process reported cases in a tiered manner. The execution and closed-loop feedback module is used to execute suggestions and feed back optimized data. The automatic withdrawal module is used to proactively withdraw the report after the vehicle recovers.

[0033] like Figure 5 As shown, the control method for the autonomous vehicle includes steps 510, 520, 530, and 540.

[0034] This control method for autonomous vehicles can be applied to autonomous vehicles that communicate with the cloud.

[0035] Autonomous vehicles refer to vehicles with autonomous driving capabilities, and in this application, they can refer to vehicles that are in operation and may encounter difficult situations.

[0036] The cloud refers to a server or server cluster deployed remotely, which connects to the autonomous vehicle through a vehicle-cloud communication network to receive information reported by the vehicle and send out processing results.

[0037] Step 510: In response to detecting that the autonomous vehicle is stationary, obtain current scene information; In this step, the stationary state refers to the state in which the speed of the autonomous vehicle is zero or close to zero and cannot continue to move forward.

[0038] Current scene information refers to the perceived information about the vehicle's current environment, including but not limited to the status of traffic lights, the status of the vehicle queue ahead, the status of pedestrians or non-motorized vehicles crossing the road, the status of traffic signal control and management constraints, and whether the vehicle is executing a pull-over instruction.

[0039] Step 520: If it is determined from the current scene information that the preset waiting whitelist has not been hit, start the first timer and the second timer; In this step, a pre-defined waiting whitelist (NW-List) is used to mark autonomous vehicles in a normal waiting state, meaning that although the vehicle is stationary, it falls under a reasonable and normal parking scenario that should not trigger a entrapment determination. If any condition in the whitelist is met, the system does not initiate the entrapment determination process, and the vehicle continues to wait.

[0040] The first timer is used to accumulate the duration of stillness under non-signal control constraints and to pause under signal control constraints. The second timer is used to accumulate the duration of continuous stillness. The preset threshold of the second timer is greater than the preset threshold of the first timer.

[0041] The first timer is the first timer in the dual-timer mechanism, used to accumulate the duration of the vehicle's stationary time under non-signal control constraints, and to pause accumulation under signal control constraints. Its preset threshold can be set to 60 seconds by default.

[0042] The second timer is the second timer in the dual-timer mechanism. It is used to accumulate the duration of continuous vehicle stillness and is unaffected by signal control status. After the second timer is started, the accumulation operation is independent of the hit status of the preset waiting whitelist. Its preset threshold can be set to 180 seconds by default, which is greater than the preset threshold of the first timer.

[0043] Traffic signal control constraints refer to the constraints that require vehicles to stop due to traffic signals such as traffic lights and police hand signals. When a traffic signal control constraint such as waiting at a red light or a police hand signal to stop is detected, the first timer pauses its accumulation; when the traffic signal control constraint is released, the first timer resumes its accumulation. The second timer is unaffected by the traffic signal control status and, once started, continues to accumulate as long as the vehicle is stationary, regardless of whether it is under a traffic signal control constraint.

[0044] The dual timers are initially set to zero. When the vehicle resumes driving or a retraction is triggered, both timers are reset to zero. When either timer reaches its preset threshold, the timer pauses its accumulation (latches), waiting for the entrapment determination process to conclude before deciding whether to reset or retain it based on the result.

[0045] It should be noted that the second timer is activated under the same conditions as the first timer, requiring a false positive in the preset waiting whitelist. Once activated, the second timer's cumulative operations are no longer affected by the whitelist's status.

[0046] If the autonomous vehicle is in a red light waiting scenario when it first enters a stationary state (i.e., it is on the preset waiting whitelist), the second timer will not start, the vehicle will continue to wait, and the entrapment determination process will not be triggered. This situation is considered a normal waiting scenario and does not require reporting.

[0047] If an autonomous vehicle has already started its second timer in a non-whitelisted scenario, and subsequently enters a red light waiting state (i.e., it hits the preset waiting whitelist after starting), the second timer will continue to accumulate the stationary time, unaffected by the red light state. In this case, if the vehicle remains stationary for more than the preset threshold of the second timer due to repeated red light switching or other reasons, the entrapment determination process can still be triggered to avoid missed detections.

[0048] Step 530: If the first timer or the second timer reaches the corresponding preset threshold, determine whether the autonomous vehicle is trapped based on at least two of the following: number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress. In this step, the number of planning failures refers to the number of consecutive failures the autonomous driving system's planning module makes when attempting to generate a feasible driving path. The planning module attempts to plan a path at a fixed frequency (e.g., 10Hz), and each failure is counted as one when the planning module cannot output a valid path. If the number of consecutive failures exceeds a preset threshold (e.g., 5 times), it indicates that the planning module cannot find a feasible path, and the vehicle may be stuck.

[0049] Obstacle characteristics refer to the attribute information of obstacles ahead. The perception module detects obstacles ahead using sensors such as cameras, LiDAR, and millimeter-wave radar, and tracks their position and motion. When an obstacle's speed remains below 0.1 m / s and its position change is less than 0.2 m within a continuous judgment window (e.g., 3 seconds), it is identified as a static obstacle. In addition, the perception module also determines the type of obstacle (such as stationary vehicles, construction facilities, roadblocks, etc.) as an auxiliary basis for judgment.

[0050] Lane availability refers to whether a vehicle can use the adjacent lanes on either side to bypass an obstacle. The assessment of lane availability includes: the existence of adjacent lanes, lane markings (solid lines prohibit lane changing, dashed lines allow lane changing), whether adjacent lanes are occupied by oncoming vehicles or obstacles, and whether there is sufficient space for lane changing. When both the left and right lanes are impassable, lane availability indicates that neither the left nor right adjacent lanes are permissible for lane changing.

[0051] Reversing space refers to the amount of space behind a vehicle that can be used for reversing. The assessment of reversing space is based on factors including the presence of obstacles behind the vehicle, the distance of any obstacles, and the width and length of the available space behind. When the distance to an obstacle is less than a preset distance threshold (e.g., 2 meters), or the available width behind is less than the vehicle width plus a preset allowance, the reversing space indicator indicates that there is insufficient space behind the vehicle to complete the reversing operation.

[0052] Path progress refers to the degree of vehicle advancement along the planned path, usually expressed as a percentage of the total path length traveled. When the path progress changes by less than a preset threshold (e.g., 0.5%) within a continuous judgment window (e.g., 5 seconds), it indicates that although the vehicle has planned a path, it has not actually moved forward.

[0053] Being stuck refers to a state in which an autonomous vehicle is blocked by obstacles or other factors and cannot continue to move along the planned path.

[0054] Step 540: If the vehicle is determined to be stuck, perform a scramble operation. Performing a scramble operation includes executing a local active recovery strategy or sending the stuck scenario information and scramble request to the cloud. The stuck scenario information and scramble request are used for the cloud to generate a work order. The work order is used for the cloud to confirm and then issue a scramble command to the autonomous vehicle.

[0055] In this step, getting out of trouble refers to the actions a vehicle takes after it is determined to be stuck, including attempting local active recovery (such as honking the horn, rerouting, or slightly reversing), or reporting to the cloud to request remote assistance.

[0056] Trapped scenario information refers to structured data describing the trapped scenario, including the type of trapped scenario, rescue level, evidence of being trapped, and type of obstructing target.

[0057] A distress request is a command sent by a vehicle to the cloud requesting remote assistance.

[0058] A work order is a work task order generated in the cloud based on information reported by the vehicle terminal, used to guide subsequent processing. Subsequent processing may include displaying it to the operator or issuing execution instructions after the operator confirms it.

[0059] In actual operation, when a vehicle detects that it has entered a stationary state, it first obtains the current scene information. Then, based on the scene information, it determines whether the vehicle is on a preset waiting whitelist. If it is (e.g., waiting at a red light, crawling in front of another vehicle, yielding to pedestrians, or other normal parking scenarios), the entrapment determination process is not initiated, and the vehicle continues to wait. If it is not on the whitelist, a first timer and a second timer are started: the first timer accumulates the stationary time under non-signal control constraints and pauses accumulation under signal control constraints (such as waiting at a red light); the second timer continuously accumulates the stationary time, unaffected by signal control status, and the preset threshold of the second timer is greater than the preset threshold of the first timer. When either timer reaches its preset threshold, the entrapment determination process is triggered, which comprehensively determines whether the vehicle is truly entrapped based on at least two of the five auxiliary conditions: the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress. If the vehicle is determined to be entrapped, an escape operation is performed: attempting local active recovery (e.g., honking the horn, replanning the route, or slightly reversing), or sending entrapment scene information and an escape request to the cloud. After receiving this information, the cloud can generate a work order. Once the operator confirms the work order, the cloud can issue a distress command to the vehicle.

[0060] In some embodiments, five auxiliary conditions can be evaluated one by one when determining whether a path is blocked. **Planning Failure Count Condition:** Monitor the output status of the planning module and count the number of consecutive failures. This condition is marked as satisfied when the planning module fails to generate a valid path N times consecutively (N=5). **Obstacle Characteristic Condition:** Track the position and speed of obstacles ahead. If an obstacle's speed remains below 0.1 m / s and its position changes by less than 0.2 m within 3 seconds, it is considered a static obstacle, and this condition is marked as satisfied. **Passability Condition:** Evaluate whether adjacent lanes are passable. If the left lane is not passable due to a solid line, oncoming vehicle, or obstacle, and the right lane is also not passable, this condition is marked as satisfied. **Reversing Space Condition:** Detect the distance to obstacles behind and the width of available space. If the distance to obstacles behind is less than 2 meters or the available space is insufficient, this condition is marked as satisfied. **Path Progress Condition:** Monitor the percentage of progress of the planned path. If the progress change is less than 0.5% within 5 seconds, this condition is marked as satisfied. The system determines that the vehicle is trapped when at least two of the above five conditions are marked as met.

[0061] Combination Figure 1As shown, the vehicle-side perception and initial screening module (including NW-List and dual timers) is responsible for initial screening, while the vehicle-side multi-dimensional judgment module is responsible for determining whether a vehicle is trapped by integrating information such as planning, obstacles, lane borrowing, and reversing space.

[0062] Combination Figure 2 As shown, Figure 2 This is a flowchart illustrating the logic for determining the dual timer on the vehicle side. Figure 2 As shown, after the vehicle comes to a stop, both timers are updated: Timer A accumulates when the vehicle is stationary (excluding red lights) and pauses when waiting at red lights; Timer B continuously accumulates. A multi-dimensional judgment is triggered when there is clear evidence of entrapment, or when Timer B reaches 180 seconds, or when Timer A reaches 60 seconds; otherwise, the vehicle continues to wait for observation.

[0063] Figure 7 This is a flowchart illustrating the vehicle-side NW-List whitelist filtering and multi-dimensional feature aggregation process. Figure 7 As shown, after the vehicle enters a stationary state, it first acquires real-time perception / planning / location information and map information. Then, it determines whether the vehicle belongs to a normal waiting scenario, specifically including: whether the current scenario information indicates the traffic light is red (traffic light waiting); whether it indicates there is a queue of vehicles ahead and their speed is below the second speed threshold (queueing and creeping); whether it indicates pedestrians or non-motorized vehicles are crossing and the vehicle is in a yielding waiting state (yielding to pedestrians / non-motorized vehicles); whether it indicates a stop due to signal control traffic management constraints (planning constraint stop); and whether it instructs the autonomous vehicle to execute a pull-to-the-side parking instruction. If any of the above normal waiting scenarios are matched, a NormalWait flag is output, and the vehicle continues to wait without reporting. If the normal waiting whitelist is not matched, the system enters the multi-dimensional feature aggregation module, aggregating stagnation time (i.e., the accumulated stagnation time under non-signal control constraints from the first timer), path progress, number of consecutive planning failures, obstacle stability, reversing space, left and right lane availability, risk boundaries, and other multi-dimensional information. After multi-dimensional feature aggregation, the system integrates this information into the subsequent entrapment determination process.

[0064] According to the control method for autonomous vehicles provided in the embodiments of this application, the false alarm rate is greatly reduced by filtering normal parking scenarios through a preset waiting whitelist. The risk of missed alarms in scenarios with repeated switching of traffic lights is eliminated by a dual timer mechanism (one pauses under signal control constraints and the other continues to accumulate). The identification of being trapped is more accurate by joint judgment of multi-dimensional auxiliary conditions, avoiding misjudgment based on a single static duration criterion.

[0065] In some embodiments, performing an escape operation may include: Based on at least two of the following factors: number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, determine whether the autonomous vehicle meets the local active recovery conditions. If the conditions for local active recovery are met, execute the local active recovery strategy; If the conditions for local active recovery are not met, or if it is determined that the local active recovery strategy has failed, send the distress scenario information and escape request to the cloud.

[0066] In this embodiment, local active recovery conditions refer to the set of conditions under which a vehicle can attempt to extricate itself from a difficult situation without relying on cloud assistance. These conditions can be evaluated based on five auxiliary conditions: the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress. For example, the system determines that the vehicle meets the local active recovery conditions when the obstacle is identified as movable or temporary, or when there is a lane available for borrowing in the left or right adjacent lanes, or when there is sufficient reversing space behind. Local recovery conditions emphasize the existence of feasible extrication methods, while the determination of being trapped emphasizes whether the vehicle is actually obstructed. For example, if there is a temporary obstacle ahead and at least one lane available for borrowing in the left or right lanes, the local recovery conditions are met; if there is a static obstacle ahead and neither lane is available for borrowing, the local recovery conditions are not met.

[0067] Local active recovery strategy refers to the specific actions a vehicle takes to get out of trouble after it is determined that it can be recovered locally. These actions include controlling the vehicle to sound the horn to warn of obstacles ahead, replanning the driving route to find an alternative route, and controlling the vehicle to move backward to obtain more operating space.

[0068] Once a vehicle is determined to be stuck, the system can determine whether it meets the local active recovery conditions based on at least two auxiliary conditions: the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress. The system determines that the vehicle meets the local active recovery conditions when the obstacle is identified as temporary (pedestrians are slowly crossing, or vehicles ahead may be about to move), or at least one of the adjacent lanes is available for lane borrowing, or there is sufficient reversing space behind. If met, the system prioritizes implementing local active recovery strategies, such as honking the horn, replanning the path, or slightly reversing to attempt to extricate itself. If the vehicle does not meet the local active recovery conditions (e.g., a static obstacle ahead, no lane borrowing on either side, and insufficient reversing space), or if an attempt at local active recovery fails (e.g., honking is ineffective, replanning the path still fails, or moving backward still leaves insufficient space to maneuver), the system sends stuck scenario information and an extrication request to the cloud for remote assistance.

[0069] Figure 8 This is a flowchart illustrating the local vehicle recovery and reporting decision-making process. (Example) Figure 8As shown, after multi-dimensional feature aggregation, the system determines whether the vehicle can recover locally based on the aggregated multi-dimensional features (stagnation duration, path progress, number of consecutive planning failures, obstacle stability, reversing space, left and right lane availability, risk boundaries, etc.). If it is determined to be locally recoverable, it enters the Local Recovery module: executing local active recovery strategies such as waiting, replanning the driving path, reversing, parking on the side of the road, and detour evaluation. If local recovery is successful, the vehicle resumes driving and continues normal ADS (Autonomous Driving System) driving. If local recovery fails, or if it is initially determined to be unable to recover locally, it reports "suspected_stuck" and uploads structured features, keyframes, BEV bird's-eye view, and candidate action set to the cloud. After receiving the report, the cloud rule engine performs secondary filtering: secondary filtering is performed on normal parking scenarios, fallback processing is performed on high-risk scenarios, and results are directly output if the preset rules are matched.

[0070] According to the autonomous vehicle control method provided in the embodiments of this application, by adopting a hierarchical strategy of prioritizing local recovery and providing a backup for cloud reporting, most scenarios where the vehicle can extricate itself from trouble can be resolved on the vehicle side without consuming cloud processing resources, thus improving overall processing efficiency; at the same time, it ensures that scenarios that truly require remote assistance are not overlooked.

[0071] In some embodiments, after sending the stranded scenario information and the escape request to the cloud, the method may further include: Once the autonomous vehicle resumes driving or is determined to be free from distress, it sends a message to the cloud to withdraw the distress request.

[0072] In this embodiment, resuming driving state means that the autonomous vehicle starts moving again from a stationary state, and the speed recovers to a level exceeding a preset threshold and remains there for a certain period of time, indicating that the vehicle has gotten rid of the trapped state on its own.

[0073] Determining that the vehicle is no longer trapped means that the system has reassessed the situation and determined that the vehicle no longer meets the trapping conditions. For example, the obstacle has disappeared, the planning module has re-output a valid path, or the multi-dimensional conditions for trapping are no longer met.

[0074] The information to withdraw the distress request refers to the instruction sent by the vehicle to the cloud to cancel the previously reported distress request. After receiving the instruction, the cloud closes the corresponding work order.

[0075] In actual operation, after the vehicle sends information about the stuck situation and a request for assistance to the cloud, the vehicle's operational status is continuously monitored. When the vehicle resumes its driving state on its own (e.g., the obstacle in front is removed, or the vehicle starts moving again), or when the system reassesses and determines that the vehicle is no longer stuck (e.g., the planning module outputs a valid path again, or the assist conditions for getting stuck are no longer met), the vehicle proactively sends a message to the cloud to withdraw the request for assistance. Upon receiving the withdrawal message, the cloud closes the corresponding work order to avoid duplicate processing.

[0076] Combination Figure 1 As shown, the automatic withdrawal module triggers withdrawal when the vehicle resumes driving, the obstacle disappears, or remote takeover is handed over, forming a closed loop of vehicle-side reporting and withdrawal.

[0077] According to the control method for autonomous vehicles provided in the embodiments of this application, the automatic withdrawal mechanism actively cancels the report after the vehicle recovers on its own, reducing the consumption of cloud processing resources by redundant work orders; at the same time, it avoids the delay of manually closing work orders and improves operational efficiency.

[0078] In some embodiments, the information sent to the cloud to withdraw the extrication request after the autonomous vehicle has resumed driving or is determined to be no longer trapped may include: A message to withdraw the escape request is sent to the cloud if at least one of the following conditions is met: The autonomous vehicle's speed recovers to a level greater than or equal to a first speed threshold and remains there for a first duration; The planning confidence of the path output by the planning module of the autonomous vehicle is greater than the first confidence threshold, and the autonomous vehicle starts moving based on the path; Based on the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, it is determined that the autonomous vehicle is not trapped. The autonomous vehicle has been put into remote control.

[0079] In this embodiment, the first speed threshold is a reference speed value used to determine whether the vehicle has resumed movement, for example, it can be set to 0.5 m / s. When the vehicle speed recovers to a value greater than or equal to this threshold, it indicates that the vehicle has begun to move.

[0080] The first duration refers to the length of time required after the vehicle speed recovers to above the first speed threshold. For example, it can be set to 3 seconds to confirm that the vehicle has indeed resumed driving rather than just moving briefly.

[0081] Planning confidence score is a quantitative assessment of the reliability of the output planned path by the autonomous driving planning module. When generating a path, the planning module outputs a confidence score (between 0 and 1), which comprehensively reflects the path's safety, feasibility, and harmony with the surrounding environment. A high planning confidence score indicates that the planning module is confident that the path is feasible and safe.

[0082] The first confidence threshold is a baseline value used to determine whether a planned path is feasible; for example, it can be set to 0.8. When the planning confidence is greater than this threshold, it indicates that the path is credible and feasible.

[0083] When a vehicle is unable to extricate itself from a difficult situation, a cloud operator or remote control system takes over control of the vehicle.

[0084] In actual execution, after a vehicle sends a distress request, it sends a withdrawal request to the cloud when any of the following conditions are met: the vehicle speed recovers to a level exceeding a first speed threshold and remains there for a first duration, for example, a speed exceeding 0.5 m / s for 3 seconds, indicating that the vehicle has resumed stable driving; the planning confidence of the path output by the planning module is greater than the first confidence threshold, and the vehicle begins to move based on that path, for example, a planning confidence exceeding 0.8 and the vehicle traveling along that path, indicating that the planning module has found a credible feasible path again; after reassessment based on the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, it is determined that the vehicle is no longer distressed, for example, obstacles have been removed, and fewer than two of the five auxiliary conditions meet the distress judgment, indicating that the distress conditions have disappeared; remote takeover has been initiated, indicating that the cloud has taken over control, and the vehicle no longer needs to retain reporting.

[0085] The control method for autonomous vehicles provided in the embodiments of this application ensures that redundant work orders can be withdrawn in a timely manner under various recovery scenarios by setting multiple withdrawal trigger conditions, thereby improving system response efficiency.

[0086] In some embodiments, implementing a local active recovery strategy includes at least one of controlling the autonomous vehicle to honk its horn, replanning the driving route, and controlling the autonomous vehicle to move backward.

[0087] In this embodiment, controlling the autonomous vehicle to sound its horn means that the vehicle uses its horn to alert obstacles ahead (such as pedestrians, non-motorized vehicles, or other vehicles), prompting them to move or give way, thereby creating passage conditions for the vehicle. This strategy is applicable to scenarios where there are movable obstacles ahead (such as pedestrians, non-motorized vehicles, or temporarily parked vehicles).

[0088] Replanning the driving route refers to the vehicle's planning module recalculating a new drivable path to bypass the obstacle when the original path is blocked. This strategy is suitable for scenarios where there are alternative routes (such as using adjacent lanes).

[0089] Controlling an autonomous vehicle to move backward refers to reversing the vehicle to gain more maneuvering space, such as creating space for changing lanes or maneuvering around obstacles. This strategy is suitable for scenarios where there is insufficient space in front but sufficient space behind.

[0090] When the obstacle is movable, honking the horn is the preferred option; when the adjacent lane allows for lane borrowing, replanning the route is the preferred option; when there is sufficient space behind, moving backward is the preferred option. These three strategies can be combined, for example, honking the horn may be ineffective before replanning the route and moving backward.

[0091] By combining various local recovery methods, the success rate of vehicles getting out of trouble on their own was improved, the reliance on remote cloud assistance was reduced, and operating costs were lowered.

[0092] In some embodiments, the preset waiting whitelist includes at least one of the following: The current scene information indicates that the traffic light is red; The current scene information indicates that there is a queue of vehicles ahead of the autonomous vehicle, and the speed of the queue of vehicles is lower than the second speed threshold. The current scene information indicates that there are pedestrians or non-motorized vehicles crossing, and the autonomous vehicle is in a waiting state; The current scene information indicates that there is a parking wait due to traffic signal control constraints; The current scene information instructs the autonomous vehicle to pull over.

[0093] In this embodiment, a red light means that the traffic light in front of the vehicle is red, and the vehicle should stop and wait at the stop line in accordance with the law, which is a normal signal control waiting scenario.

[0094] A queue of vehicles ahead refers to a situation where multiple vehicles are lined up in front of a vehicle. When the speed of the queue is below a second speed threshold, the vehicle following the vehicle in front is in a waiting state, which is a normal scenario of creeping along while waiting.

[0095] The second speed threshold is a reference value used to determine whether the preceding convoy is traveling at a low speed; for example, it can be set to 0.5 m / s. When the speed of the preceding convoy is lower than this threshold, it indicates that the preceding vehicles are moving slowly or almost stationary.

[0096] Pedestrian or non-motorized vehicle crossing refers to the perception module recognizing that a pedestrian or non-motorized vehicle is crossing the road in front of the vehicle, and the vehicle actively stops to yield, which is a normal yielding and waiting scenario.

[0097] Traffic signal control constraints refer to stopping and waiting caused by traffic management signals other than traffic lights, such as traffic police hand signals and temporary traffic control.

[0098] Executing a pull-over instruction means that the vehicle is actively pulling over to the side of the road, which is a normal instruction execution phase.

[0099] By systematically defining a whitelist of normal waiting scenarios, scenarios such as waiting at traffic lights, waiting while following another vehicle at low speed, and yielding to pedestrians are excluded from the entrapment determination process, significantly reducing the false alarm rate.

[0100] In some embodiments, determining whether an autonomous vehicle is trapped based on at least two of the following: number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, may include: An autonomous vehicle is determined to be trapped if at least two of the following conditions are met: The number of planning failures is greater than or equal to the first failure threshold; Obstacle features indicate the presence of a static obstacle ahead; The lane-sharing indicator shows that adjacent lanes on either side are not allowed to be used by other lanes. The reversing space indicator shows that there is insufficient space behind the vehicle to complete the reversing operation. The path progress remained unchanged within the continuous judgment window.

[0101] In this embodiment, the first failure threshold is a baseline value used to determine whether the planning module has failed multiple times consecutively, for example, it can be set to 5 times. When the number of planning failures reaches or exceeds this threshold, it indicates that the planning module cannot find a feasible path.

[0102] Static obstacles are those that do not change position over a period of time, such as parked vehicles, construction facilities, and roadblocks. When obstacle characteristics indicate the presence of a static obstacle ahead, it means that the vehicle is blocked by a fixed obstacle.

[0103] "Neither adjacent lane is available for lane changing" means that both the left and right adjacent lanes are assessed as unavailable, such as when there is oncoming traffic, the lane is occupied, or the lane does not exist. When the lane availability indicator shows that neither adjacent lane is available for lane changing, it means that the vehicle cannot change lanes to bypass the obstacle.

[0104] Insufficient rear space for reversing means that the available space behind the vehicle is insufficient to allow the vehicle to complete the reversing maneuver, such as due to obstacles or a narrow space behind it. When the reversing space indicator shows insufficient rear space for reversing, it means that the vehicle cannot gain more operating space by reversing.

[0105] A continuous decision window is a time window used to assess whether the path progress has changed; for example, it can be set to 5 seconds. When the path progress does not change within the continuous decision window, it indicates that although the vehicle has a planned path, it has not actually moved.

[0106] In actual execution, the following five conditions can be comprehensively evaluated: 1) Whether the number of planning failures reaches or exceeds the first failure threshold (e.g., 5 times). The planning module attempts planning at a frequency of 10Hz; 5 consecutive failures satisfy this condition. 2) Whether obstacle features indicate the presence of a static obstacle ahead. The perception module tracks the obstacle for 3 seconds; if the speed remains below 0.1m / s and the position change is less than 0.2m, it is determined to be a static obstacle. 3) Whether lane availability indicates that neither adjacent lanes are available for lane borrowing. The lane availability of the left and right lanes is evaluated separately; if neither is available, this condition is satisfied. 4) Whether reversing space indicates insufficient space behind to complete the reversing operation. This condition is satisfied when the distance to the obstacle behind is less than 2 meters or the available width is insufficient. 5) Whether the path progress remains unchanged within a continuous judgment window. This condition is satisfied when the path progress changes by less than 0.5% within 5 seconds. When at least two of the above five conditions are met, the system determines that the vehicle is indeed trapped.

[0107] The autonomous vehicle control method provided in the embodiments of this application achieves more accurate identification of trapped scenarios than a single time threshold by comprehensively utilizing information such as planning status, obstacle features, lane availability, reversing space and path progress through multi-dimensional joint criteria, thus avoiding misjudgment and omission by a single criterion.

[0108] like Figure 6 As shown, this application also provides a control method for an autonomous vehicle, applied in the cloud, wherein the cloud is communicatively connected to the autonomous vehicle; the method includes steps 610, 620, 630, 640 and 650.

[0109] Step 610: Receive the distress scenario information and escape request sent by the autonomous vehicle; In this step, the cloud connects with the autonomous vehicle, and if the autonomous vehicle is stuck, it can send information about the stuck situation and a request to get out of trouble to the cloud.

[0110] Step 620: Perform rule matching on the trapped scenario information through the rule engine. If a preset rule is matched, output a normal waiting flag or a high-risk escalation flag. If no preset rule is matched, send the trapped scenario information to the structured classification model. In this step, the rule engine is the first layer of the cloud-based three-layer traffic splitting and judgment, used to match the structured fields reported by the vehicle with rules. The rule engine has several pre-defined deterministic rules, such as "perceived health abnormality - high-risk escalation," "location failure - high-risk escalation," "MRM activation cannot be restored - high-risk escalation," and "traffic light status is red and the vehicle in front is present - normal waiting." When the reported scenario information matches a pre-defined rule, the rule engine directly outputs the corresponding processing result; when the reported scenario information does not match any pre-defined rule, the case is marked as a "gray zone case" and passed to the second layer of processing.

[0111] Structured classification models are the second layer in the cloud-based three-layer traffic splitting and judgment process. They are machine learning models used to classify structured feature vectors reported by the vehicle, such as lightweight gradient boosting classifiers (e.g., LightGBM / XGBoost). Structured feature vectors include: stagnation duration, path progress changes, number of consecutive planning failures, number of candidate trajectories, duration and static marking of obstacles ahead, left and right lane availability scores, reversing space scores, number of local recovery attempts, map confidence, and perception confidence.

[0112] Step 630: Classify the trapped scene information using a structured classification model and output classification labels based on structured feature vectors; In this step, the classification label refers to the category label output by the structured classification model, including normal waiting (normal_wait, more like normal parking, it is recommended not to intervene), confirmed stuck (stuck, more like real stuck, it is recommended to intervene), self-recovery probability (self_recovery, the vehicle has a high probability of self-recovery, it is recommended to trigger local retry), and handling priority (cloud handling priority score, used for work order sorting).

[0113] Step 640: If the confidence level output by the structured classification model is less than the second confidence level threshold, the trapped scene information is reviewed by a multimodal model, and the scene review results and suggested actions are output. In this step, the second confidence threshold refers to the baseline confidence level used to determine whether the output of the structured classification model is sufficiently reliable; for example, it can be set to 0.85. When the confidence level of the model output is lower than this threshold, it indicates that the model's judgment is not reliable enough and needs to proceed to the third layer of verification.

[0114] A multimodal model is a model capable of processing multiple modalities of data (such as images, text, and structured data) simultaneously, used to combine information about the trapped scene for semantic understanding of the scene. The inputs of a multimodal model include: forward-looking keyframes (retrieved via keyframe indexing), BEV bird's-eye view (retrieved via bird's-eye view indexing), map and lane topology, obstacle layout, second-layer structured judgment results, and a set of candidate actions.

[0115] Scene verification results refer to the conclusions output by the multimodal model after verifying the trapped scene, including the re-judgment and confirmation of the scene.

[0116] The suggested actions refer to the Top-K escape suggestions (e.g., Top-3) output by the multimodal model, which are ordered by priority. Each action is accompanied by a reason code and confidence level, risk label, whether manual review is required, and whether authorization conditions are involved.

[0117] Step 650: Based on at least one of the following: normal waiting flag, high-risk escalation flag, classification label, scenario review result, and suggested action, generate a handling result corresponding to the trapped scenario. The handling result is used for display or to generate a work order. The work order is used to send to the autonomous vehicle for execution of the escape operation after confirmation.

[0118] In this step, the processing result refers to the final processing conclusion generated by the cloud based on the judgment results of each layer, which is used to display to the operator or generate a work order.

[0119] Figure 3 This is a logic diagram for the three-layer traffic distribution in the cloud. (Example:) Figure 3 As shown, the vehicle-side structured reporting first enters the first-layer rule engine, which outputs normal_wait or high_risk_escalation; gray area cases that do not hit the rules enter the second-layer structured classification model, which outputs four-class classification labels; complex gray area cases with insufficient confidence enter the third-layer multimodal review, which outputs Top-K suggestions and risk labels.

[0120] Figure 9 This is a flowchart illustrating the cloud-based three-tier traffic splitting decision process. (Example:) Figure 9As shown, after receiving a report from the vehicle, the cloud first enters the cloud rule engine (first layer). The rule engine performs rule matching on the reported structured features to determine whether the direct rule output conditions are met. If the direct rule output conditions are met, the direct rule output result is output directly: for normal waiting / delayed re-inspection scenarios, a normal waiting flag (NormalWait) is output, and the vehicle is displayed in the HMI, continuing to wait without reporting; for high-risk fault / direct escalation scenarios, a high-risk escalation flag is output, and a formal work order is generated. If the direct rule output conditions are not met, the gray area case judgment is entered, and the result is passed to the structured classification model (second layer). The structured classification model performs classification processing based on structured feature vectors, outputting four classification labels: normal_wait (normal waiting probability), stuck (actual stuck probability), self_recovery (vehicle self-recovery probability), and priority (cloud handling priority). After classification, it is determined whether multimodal verification is needed: if the model confidence is sufficient (reaching a preset confidence threshold), the initial judgment result is directly output without proceeding to the third layer; if the confidence is insufficient, it is passed to the multimodal proposal engine (third layer). The multimodal proposal engine receives forward-looking keyframes, BEV bird's-eye view, scene semantics, and other information, performs scene semantic understanding, and outputs policy suggestions (Top-K suggested actions), including candidate actions such as waiting, changing lanes left or right, detouring left or right, reversing and then changing lanes, and parking on the side of the road.

[0121] The autonomous vehicle control method provided in this application uses a three-layer traffic splitting judgment architecture, enabling most cases to be processed directly at the rule layer, a small number of cases to be processed at the structured classification layer, and a very small number of cases to enter multimodal review. This significantly reduces overall cloud processing latency while ensuring that the quality of recommendations for complex scenarios is not degraded.

[0122] In some embodiments, after outputting the scenario review results and suggested actions, the following may also be included: Perform controlled action whitelist verification on the suggested actions; If the suggested action is within the whitelist of controlled actions, a work order is generated based on the suggested action; Send work orders to autonomous vehicles.

[0123] In this embodiment, the controlled action whitelist refers to a predefined list of actions that the cloud is allowed to suggest and generate work orders for. A work order is only allowed to be generated based on a suggested action if it is within the controlled action whitelist. The controlled action whitelist includes compliant maneuvering actions such as lane changing, reversing, and pulling over. Unconventional maneuvers (such as using oncoming lanes or continuous lane changes) are not in the whitelist and require additional authorization.

[0124] In actual implementation, after the multimodal model outputs the scenario verification results and suggested actions, the suggested actions must undergo safety gate verification before generating a work order. First, the suggested actions are checked against a controlled action whitelist to see if they are within the predefined whitelist (e.g., compliant maneuvers such as lane changes and reversing are explicitly defined in the whitelist; non-compliant maneuvers require additional authorization). If the suggested action is in the controlled action whitelist, a work order is generated based on the suggestion and sent to the autonomous vehicle; if the suggested action is not in the whitelist, no work order is generated, and it is only displayed as a suggestion for the operator's reference.

[0125] By verifying the whitelist of controlled actions, we ensure that only predefined safe actions can enter the execution phase, thus preventing the AI ​​model from outputting dangerous or unauthorized action instructions.

[0126] In some embodiments, after outputting the scenario review results and suggested actions, the following may also be included: The risk level of the recommended actions is determined to obtain the risk level result; Based on the type and risk level of the suggested action, determine whether to display the suggested action or generate a work order based on the suggested action; Once a work order is generated based on the suggested actions and has been confirmed, the work order is sent to the autonomous vehicle.

[0127] In this embodiment, the risk level refers to the classification of the suggested action after a risk assessment, including high risk, medium risk, and low risk. The assessment criteria for the risk level include: whether the action involves the oncoming lane, whether it involves continuous lane changes, whether it is performed at an intersection or on a narrow road, and whether it involves complex maneuvers such as reversing and then changing lanes. High-risk actions (such as using the oncoming lane, reversing and then changing lanes) are automatically marked as "requires manual confirmation".

[0128] After the multimodal model outputs the scenario verification results and suggested actions, the suggested actions still need to undergo risk level assessment and manual confirmation. The system first determines the risk level of the suggested actions, obtaining risk level results. For example, complex maneuvers such as oncoming lane changes and reversing then changing lanes are marked as high-risk, while conventional maneuvers such as changing lanes and reversing are marked as low-risk. Then, based on the type of suggested action and the risk level result, it determines whether to only display the suggestion to the operator (for reference) or generate a formal work order based on the suggestion. Low-risk actions can directly generate work orders, while high-risk actions must be manually confirmed. If a work order is generated, it must be confirmed by the operator before being sent to the vehicle.

[0129] Figure 4 This is a flowchart illustrating the safety gate and its closed-loop operation. (Example:) Figure 4As shown, the cloud-based recommendations go through whitelist verification, risk level assessment, manual confirmation of requirements, and VRM arbitration access verification in sequence. After all of them pass, they enter the HMI display and operator confirmation stage. After confirmation, the VRM performs the troubleshooting action, and the execution result is fed back for optimization.

[0130] By employing risk level assessment and manual confirmation mechanisms, high-risk actions are ensured to be performed under operator supervision, thus avoiding safety hazards caused by AI models directly controlling the vehicle and meeting functional safety requirements.

[0131] In some embodiments, after outputting the scenario review results and suggested actions, the following may also be included: If the suggested action meets the access conditions corresponding to the vehicle remote management system, a work order is generated based on the suggested action. Send work orders to autonomous vehicles.

[0132] In this embodiment, the Vehicle Remote Management system (VRM) refers to a control system used for remotely managing vehicles, responsible for receiving operator-confirmed instructions and executing corresponding remote assistance actions.

[0133] The access conditions corresponding to the vehicle remote management system refer to the conditions that must be met before the suggested action enters the VRM execution stage, including: the communication link between the vehicle and the VRM system is normal, the current state of the vehicle allows the action to be executed (such as the vehicle speed is within the allowable range, the vehicle is not in a fault state), and the action does not exceed the execution capability range of the VRM system.

[0134] After the multimodal model outputs the scenario verification results and suggested actions, the suggested actions must also undergo VRM arbitration access verification. The system checks whether the suggested actions meet the access conditions of the vehicle remote management system, including checking whether the communication link between the vehicle and the VRM system is normal, whether the vehicle's current state allows the execution of the action, and whether the action exceeds the execution capability range of the VRM system. If the access conditions are met, a work order is generated based on the suggestion and sent to the autonomous vehicle; if the access conditions are not met, the suggested action must not enter the execution stage.

[0135] Combination Figure 4 As shown, once the VRM arbitration access verification is passed, the VRM execution phase can begin.

[0136] By using VRM arbitration access verification, it is ensured that all suggestions entering the execution phase meet the access conditions of the remote management system, forming an independent safety gate between AI suggestions and vehicle control.

[0137] Figure 10 This is a flowchart for the safety gate verification process. Figure 10As shown, after the policy suggests Top-K recommended actions, they enter the Policy & Safety Gate for verification. The safety gate verification includes the following steps: controlled action whitelist verification (checking if the recommended action is within the predefined controlled action whitelist), risk level assessment (determining the risk level of the recommended action), manual confirmation requirement judgment (determining whether manual confirmation is needed based on the recommendation type and risk level), and VRM arbitration verification (checking if the access conditions of the vehicle remote management arbitration system are met). After the above verifications pass, the entire verification process is recorded in the audit log. If any verification fails, "Recommendation only, no work order generated" is output, indicating the recommendation is only for operator reference. If all verifications pass, a formal work order is generated and displayed in the HMI (Guidance Panel). For scenarios where the safety gate verification fails or the rule engine directly outputs "Normal Wait" (continue waiting / delayed re-inspection), the system outputs "NormalWait" (continue waiting / delayed re-inspection), and the vehicle continues to wait without reporting.

[0138] In some embodiments, all key decision thresholds can be remotely configured and distributed without redeployment. These thresholds include: a preset threshold for a first timer (e.g., configurable range of 30 to 120 seconds, default 60 seconds), a preset threshold for a second timer (e.g., configurable range of 120 to 300 seconds, default 180 seconds), a preset threshold for the number of planning failures (e.g., configurable range of 3 to 10 times, default 5 times), a threshold for the passability rating (e.g., configurable range of 0.3 to 0.7, default 0.5), a threshold for the reversing space evaluation (e.g., configurable range of 1 meter to 5 meters, default 2 meters), and a confidence threshold for the structured classification model (e.g., configurable range of 0.7 to 0.95, default 0.85).

[0139] In some embodiments, the system supports gray-scale verification by region and scenario, and A / B testing of new rules or model versions according to fleet ratio. The optimization effect is confirmed by data comparison before full deployment.

[0140] In some embodiments, the execution results are fed back to the rule engine, structured classification model, and multimodal model for rule optimization, incremental model training, and case library expansion. The fed-back data includes whether the execution was successful, whether it was a false alarm, the final adopted action and operator modifications, execution time, and the vehicle's status after escaping the predicament.

[0141] In some embodiments, after the VRM performs the escape action, the execution results are fed back to the cloud in the following dimensions: whether the execution was successful (whether the vehicle successfully escaped), whether it was a false alarm (manually marking the case as a normal parking situation), the final adopted action and operator modifications, execution time, and the vehicle status after escape.

[0142] The returned data is used for: rule engine optimization (supplementing direct rules based on false positive cases), incremental training of structured classification models (adding labeled data to participate in model iteration), expansion of the case library (adding high-quality cases for use in similar case retrieval), and optimization of Prompt templates and knowledge retrieval.

[0143] Figure 11 This is a flowchart illustrating the closed-loop and data feedback process. (See attached diagram.) Figure 11 As shown, the formal work order enters the HMI observation phase, where the HMI displays scenario information, Top-K suggested actions, and risk markers to the operator. The operator manually confirms or makes a takeover decision. After confirmation, the instruction enters the VRM arbitration system, where the VRM executes the escape action. After the escape action is executed, the system obtains the execution results, including: whether the escape was successful, the action ultimately adopted by the operator, and whether it was a false alarm. The execution results are fed back to the data loop module for the following purposes: false alarms are fed back to the structured classification model for iterative training (retraining or incrementally updating the classification boundaries of normal_wait / stuck / self_recovery / priority); and suggestions are used to optimize the Prompt template and knowledge retrieval strategy for the multimodal model.

[0144] The autonomous vehicle control method provided in this application can be executed by an autonomous vehicle control device. This application uses the autonomous vehicle control device executing the autonomous vehicle control method as an example to illustrate the autonomous vehicle control device provided in this application.

[0145] This application also provides a control device for an autonomous vehicle.

[0146] like Figure 12 As shown, the control device for the autonomous vehicle is applied to the autonomous vehicle, which is connected to the cloud for communication; the device includes: a first processing module 1210, a second processing module 1220, a third processing module 1230 and a fourth processing module 1240.

[0147] The first processing module 1210 is used to obtain current scene information in response to detecting that the autonomous vehicle is stationary. The second processing module 1220 is used to start a first timer and a second timer when it is determined that the preset waiting whitelist has not been hit based on the current scene information. The preset waiting whitelist is used to mark the autonomous vehicle as being in a normal waiting state. The first timer is used to accumulate the stationary time under non-signal control constraints and pauses under signal control constraints. The second timer is used to accumulate the continuous stationary time. The accumulation after the second timer is started is unrelated to the hit status of the preset waiting whitelist. The preset threshold of the second timer is greater than the preset threshold of the first timer. The third processing module 1230 is used to determine whether the autonomous vehicle is trapped based on at least two of the following when the first timer or the second timer reaches the corresponding preset threshold: the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress. The fourth processing module 1240 is used to perform an escape operation when it is determined that the vehicle is trapped. The escape operation includes executing a local active recovery strategy or sending the trapped scenario information and escape request to the cloud. The trapped scenario information and escape request are used for the cloud to output a work order. The work order is used for the cloud to confirm and then issue an escape command to the autonomous vehicle.

[0148] The control device for autonomous vehicles provided in the embodiments of this application significantly reduces the false alarm rate by filtering normal parking scenarios through a preset waiting whitelist, eliminates the risk of missed alarms in scenarios with repeated traffic light switching through a dual timer mechanism (one pauses under signal control constraints and the other continues to accumulate), and makes the identification of being trapped more accurate through joint judgment of multi-dimensional auxiliary conditions, avoiding misjudgment based on a single static duration criterion.

[0149] In some embodiments, the fourth processing module 1240 can also be used for: Based on at least two of the following factors: number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, determine whether the autonomous vehicle meets the local active recovery conditions. If the conditions for local active recovery are met, execute the local active recovery strategy; If the conditions for local active recovery are not met, or if it is determined that the local active recovery strategy has failed, send the distress scenario information and escape request to the cloud.

[0150] In some embodiments, the control device of the autonomous vehicle may further include a tenth processing module, which is used to send information to the cloud to withdraw the withdrawal request after sending the distress scenario information and the escape request to the cloud, once the autonomous vehicle resumes driving or is determined to be free from distress.

[0151] In some embodiments, the tenth processing module can also be used for: A message to withdraw the escape request is sent to the cloud if at least one of the following conditions is met: The autonomous vehicle's speed recovers to a level greater than or equal to a first speed threshold and remains there for a first duration; The planning confidence of the path output by the planning module of the autonomous vehicle is greater than the first confidence threshold, and the autonomous vehicle starts moving based on the path; Based on the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, it is determined that the autonomous vehicle is not trapped. The autonomous vehicle has been put into remote control.

[0152] In some embodiments, the fourth processing module 1240 may also be used to: include at least one of controlling the autonomous vehicle to sound its horn, replanning the driving route, and controlling the autonomous vehicle to move backward.

[0153] In some embodiments, the second processing module 1220 may also be used to include at least one of the following in the preset waiting whitelist: The current scene information indicates that the traffic light is red; The current scene information indicates that there is a queue of vehicles ahead of the autonomous vehicle, and the speed of the queue of vehicles is lower than the second speed threshold. The current scene information indicates that there are pedestrians or non-motorized vehicles crossing, and the autonomous vehicle is in a waiting state; The current scene information indicates that there is a parking wait due to traffic signal control constraints; The current scene information instructs the autonomous vehicle to pull over.

[0154] In some embodiments, the third processing module 1230 can also be used for: An autonomous vehicle is determined to be trapped if at least two of the following conditions are met: The number of planning failures is greater than or equal to the first failure threshold; Obstacle features indicate the presence of a static obstacle ahead; The lane-sharing indicator shows that adjacent lanes on either side are not allowed to be used by other lanes. The reversing space indicator shows that there is insufficient space behind the vehicle to complete the reversing operation. The path progress remained unchanged within the continuous judgment window.

[0155] This application also provides a control device for an autonomous vehicle.

[0156] like Figure 13As shown, the control device for the autonomous vehicle is applied to the autonomous vehicle and is applied to the cloud. The cloud communicates with the autonomous vehicle. The device includes: a fifth processing module 1310, a sixth processing module 1320, a seventh processing module 1330, an eighth processing module 1340, and a ninth processing module 1350.

[0157] The fifth processing module 1310 is used to receive information about the distress situation and the request for escape from the autonomous vehicle. The sixth processing module 1320 is used to perform rule matching on the trapped scene information through the rule engine. If a preset rule is matched, it outputs a normal waiting flag or a high-risk escalation flag. If no preset rule is matched, it sends the trapped scene information to the structured classification model. The seventh processing module 1330 is used to classify the trapped scene information through a structured classification model and output classification labels based on structured feature vectors. The eighth processing module 1340 is used to review the trapped scene information through a multimodal model when the confidence level output by the structured classification model is less than the second confidence level threshold, and output the scene review results and suggested actions. The ninth processing module 1350 is used to generate a handling result corresponding to the trapped scenario based on at least one of the following: normal waiting flag, high-risk escalation flag, classification label, scenario review result and suggested action. The handling result is used to display or generate a work order. The work order is used to send to the autonomous vehicle for execution of the escape operation after confirmation.

[0158] The control device for autonomous vehicles provided in this application uses a three-layer traffic splitting architecture, enabling most cases to be processed directly at the rule layer, a small number of cases to be processed at the structured classification layer, and a very small number of cases to enter multimodal review. This significantly reduces overall cloud processing latency while ensuring that the quality of recommendations for complex scenarios is not degraded.

[0159] In some embodiments, the control device of an autonomous vehicle may further include an eleventh processing module, which is used to perform controlled action whitelist verification on the suggested actions after outputting the scenario review results and suggested actions. If the suggested action is within the whitelist of controlled actions, a work order is generated based on the suggested action; Send work orders to autonomous vehicles.

[0160] In some embodiments, the control device of an autonomous vehicle may further include a twelfth processing module, which is used to determine the risk level of the suggested actions after outputting the scenario review results and suggested actions, and obtain the risk level result. Based on the type and risk level of the suggested action, determine whether to display the suggested action or generate a work order based on the suggested action; Once a work order is generated based on the suggested actions and has been confirmed, the work order is sent to the autonomous vehicle.

[0161] In some embodiments, the control device of an autonomous vehicle may further include a thirteenth processing module, which, after outputting the scenario review result and suggested actions, generates a work order based on the suggested actions, provided that the suggested actions meet the access conditions corresponding to the vehicle remote management system. Send work orders to autonomous vehicles.

[0162] The control device for the autonomous vehicle in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the scope of the device.

[0163] The control device for the autonomous vehicle in this application embodiment can be a device with an operating system. This operating system can be a Microsoft (Windows) operating system, an Android operating system, an iOS operating system, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.

[0164] The control device for autonomous vehicles provided in this application embodiment can achieve… Figures 1 to 11 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0165] In some embodiments, such as Figure 14As shown, this application embodiment also provides an electronic device 1400, including a processor 1401, a memory 1402, and a computer program stored in the memory 1402 and executable on the processor 1401. When the program is executed by the processor 1401, it implements the various processes of the above-described autonomous vehicle control method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0166] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0167] This application also provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described autonomous vehicle control method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0168] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0169] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described control method for an autonomous vehicle.

[0170] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0171] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described autonomous vehicle control method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0172] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0173] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

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

[0175] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0176] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0177] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

Claims

1. A control method for an autonomous vehicle, characterized in that, The method is applied to the autonomous vehicle, which is connected to the cloud; the method includes: In response to detecting that the autonomous vehicle is stationary, current scene information is acquired; If, based on the current scenario information, it is determined that the preset waiting whitelist has not been hit, a first timer and a second timer are started. The preset waiting whitelist is used to mark the autonomous vehicle as being in a normal waiting state. The first timer is used to accumulate the stationary duration under non-signal control constraints and pauses under signal control constraints. The second timer is used to accumulate the continuous stationary duration, and the accumulation after the second timer is started is unrelated to the hit status of the preset waiting whitelist. The preset threshold of the second timer is greater than the preset threshold of the first timer. If the first timer or the second timer reaches the corresponding preset threshold, it is determined whether the autonomous vehicle is trapped based on at least two of the following: number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress. If the vehicle is found to be stuck, an escape operation is performed. The escape operation includes executing a local active recovery strategy or sending the stuck scenario information and the escape request to the cloud. The stuck scenario information and the escape request are used for the cloud to output a work order. The work order is used for the cloud to confirm and then issue an escape command to the autonomous vehicle.

2. The control method for an autonomous vehicle according to claim 1, characterized in that, The execution of the escape operation includes: Based on at least two of the following factors: number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, determine whether the autonomous vehicle meets the local active recovery conditions. If the aforementioned local active recovery conditions are met, the local active recovery strategy will be executed. If the local active recovery conditions are not met, or if the local active recovery strategy is determined to have failed, the trapped scenario information and escape request are sent to the cloud.

3. The control method for an autonomous vehicle according to claim 2, characterized in that, After sending the trapped scenario information and the escape request to the cloud, the process also includes: Once the autonomous vehicle resumes driving or is determined to be free from entrapment, it sends a message to the cloud to withdraw the entrapment request.

4. The control method for an autonomous vehicle according to claim 3, characterized in that, The step of sending information to the cloud to withdraw the extrication request after the autonomous vehicle has resumed driving or is determined to be free from distress includes: If at least one of the following conditions is met, a message withdrawing the escape request will be sent to the cloud: The speed of the autonomous vehicle is restored to a level greater than or equal to a first speed threshold and remains there for a first duration; The planning confidence level of the path output by the planning module of the autonomous vehicle is greater than the first confidence level threshold, and the autonomous vehicle starts moving based on the path; Based on the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress, it is determined that the autonomous vehicle is not trapped. The autonomous vehicle has been put into remote control.

5. The control method for an autonomous vehicle according to claim 2, characterized in that, The implementation of the local active recovery strategy includes at least one of controlling the autonomous vehicle to sound its horn, replanning the driving route, and controlling the autonomous vehicle to move backward.

6. The control method for an autonomous vehicle according to any one of claims 1-5, characterized in that, The preset waiting whitelist includes at least one of the following: The current scene information indicates that the traffic light is in a red state; The current scene information indicates that there is a queue of vehicles ahead of the autonomous vehicle, and the speed of the queue of vehicles is lower than the second speed threshold. The current scene information indicates that there are pedestrians or non-motorized vehicles crossing, and the autonomous vehicle is in a waiting state; The current scene information indicates that there is a parking wait due to signal control traffic management constraints; The current scene information instructs the autonomous vehicle to pull over.

7. The control method for an autonomous vehicle according to any one of claims 1-5, characterized in that, The determination of whether the autonomous vehicle is trapped is based on at least two of the following: number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress: The autonomous vehicle is determined to be trapped if at least two of the following conditions are met: The number of planning failures is greater than or equal to the first failure threshold. The obstacle features indicate the presence of a static obstacle ahead; The lane availability indicator states that neither the left nor right adjacent lanes can be used for lane sharing. The reversing space indicator states that there is insufficient space behind the vehicle to complete the reversing operation; The path progress remains unchanged within the continuous determination window.

8. A control method for an autonomous vehicle, characterized in that, The method is applied in the cloud, and the cloud is communicatively connected to the autonomous vehicle; the method includes: Receive information about the distress situation and requests for escape from the autonomous vehicle; The trapped scenario information is matched with rules by a rule engine. If a preset rule is matched, a normal waiting flag or a high-risk escalation flag is output. If no preset rule is matched, the trapped scenario information is sent to a structured classification model. The trapped scene information is classified using the structured classification model, and classification labels are output based on the structured feature vectors. If the confidence level output by the structured classification model is less than the second confidence threshold, the trapped scene information is reviewed by a multimodal model, and the scene review results and suggested actions are output. Based on at least one of the normal waiting flag, high-risk escalation flag, classification label, scenario review result, and suggested action, a handling result corresponding to the trapped scenario is generated. The handling result is used to display or generate a work order. The work order is used to send to the autonomous vehicle for execution of the escape operation after confirmation.

9. The control method for an autonomous vehicle according to claim 8, characterized in that, Following the output scenario review results and suggested actions, the following is also included: The suggested actions are subject to controlled action whitelist verification; If the suggested action is within the whitelist of controlled actions, a work order is generated based on the suggested action; The work order is sent to the autonomous vehicle.

10. The control method for an autonomous vehicle according to claim 8, characterized in that, Following the output scenario review results and suggested actions, the following is also included: The risk level of the suggested action is determined to obtain the risk level result; Based on the type of the suggested action and the risk level result, it is determined whether to display the suggested action or generate a work order based on the suggested action; If a work order is generated based on the suggested action and the work order has been confirmed, the work order is sent to the autonomous vehicle.

11. The control method for an autonomous vehicle according to claim 8, characterized in that, Following the output scenario review results and suggested actions, the following is also included: If the suggested action meets the access conditions corresponding to the vehicle remote management system, a work order is generated based on the suggested action. The work order is sent to the autonomous vehicle.

12. A control device for an autonomous vehicle, characterized in that, The device is applied to the autonomous vehicle, which is connected to the cloud for communication; the device includes: The first processing module is used to obtain current scene information in response to detecting that the autonomous vehicle is stationary. The second processing module is used to start a first timer and a second timer when it is determined that the preset waiting whitelist has not been hit based on the current scene information. The preset waiting whitelist is used to mark the autonomous vehicle as being in a normal waiting state. The first timer is used to accumulate the stationary time under non-signal control constraints and pause under signal control constraints. The second timer is used to accumulate the continuous stationary time. The accumulation after the second timer is started is unrelated to the hit status of the preset waiting whitelist. The preset threshold of the second timer is greater than the preset threshold of the first timer. The third processing module is used to determine whether the autonomous vehicle is trapped when the first timer or the second timer reaches the corresponding preset threshold, based on at least two of the following: the number of planning failures, obstacle characteristics, lane availability, reversing space, and path progress. The fourth processing module is used to perform an escape operation when it is determined that the vehicle is trapped. The escape operation includes executing a local active recovery strategy or sending the trapped scenario information and the escape request to the cloud. The trapped scenario information and the escape request are used for the cloud to output a work order. The work order is used for the cloud to confirm and then issue an escape command to the autonomous vehicle.

13. A control device for an autonomous vehicle, characterized in that, The device is applied in the cloud and is communicatively connected to the autonomous vehicle; the device includes: The fifth processing module is used to receive the distress scenario information and escape request sent by the autonomous vehicle; The sixth processing module is used to perform rule matching on the trapped scenario information through the rule engine. If a preset rule is matched, a normal waiting flag or a high-risk escalation flag is output. If no preset rule is matched, the trapped scenario information is sent to the structured classification model. The seventh processing module is used to classify the trapped scene information using the structured classification model and output classification labels based on the structured feature vectors. The eighth processing module is used to review the trapped scene information through a multimodal model when the confidence level output by the structured classification model is less than the second confidence level threshold, and output the scene review result and suggested actions. The ninth processing module is used to generate a handling result corresponding to the trapped scenario based on at least one of the normal waiting flag, high-risk escalation flag, classification label, scenario review result and suggested action. The handling result is used to display or generate a work order. The work order is used to send to the autonomous vehicle for execution of the escape operation after confirmation.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the control method for an autonomous vehicle as described in any one of claims 1-11.

15. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the control method for an autonomous vehicle as described in any one of claims 1-11.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the control method for the autonomous vehicle as described in any one of claims 1-11.

Images