A high-low layer decoupling traffic robot task planning method

Abstract

The application provides a traffic robot task planning method for decoupling high and low layers, relates to the technical field of robots, and aims to solve the problems of poor interpretability and insufficient safety caused by dependence on general scripts in the prior art. The method comprises the following steps: a high-level strategy planner generates a subtask sequence based on acquired state information and a task target; a low-level strategy planner receives and processes the subtask sequence, and translates the subtask into an action sequence composed of a pre-defined domain-specific language; and an interpreter executes the action sequence to drive the robot to complete the task. The application decouples high and low layers by introducing a domain-specific language, translates abstract tasks into structured action sequences, enhances the interpretability and auditability of robot behavior, improves safety through permission verification and other mechanisms, and improves development efficiency and system maintainability.

Description

Technical Field

[0001] This application relates to the field of robotics technology, and in particular to a high-low layer decoupling method for traffic robot task planning. Background Technology

[0002] With the development of robotics technology, its application in complex scenarios such as traffic management is increasing. To achieve complex task planning, existing technologies typically employ a layered architecture. In this architecture, a high-level decision-making unit is usually set up to be responsible for macro-level task planning to generate task sequences; then a low-level execution unit interprets and executes these tasks. For example, in some solutions, the low-level execution unit executes instructions issued by the high-level unit by calling a general-purpose scripting language and invoking corresponding atomic actions from a pre-set skill library.

[0003] However, this reliance on general-purpose scripting languages ​​has significant drawbacks. First, the relatively free syntax and structure of general-purpose scripting languages ​​make it difficult to quickly understand and review the robot's specific execution logic, resulting in poor interpretability of its behavior. Second, in scenarios with extremely high safety requirements, such as traffic control, the flexibility of general-purpose scripts may introduce unforeseen security risks, and strict access control and behavior auditing are difficult to implement. Finally, when post-event analysis or troubleshooting of robot behavior is required, tracing and reproducing the complex execution process based on general-purpose scripts is also very difficult. Therefore, the existing layered architecture still has shortcomings in terms of security, auditability, and maintainability. Summary of the Invention

[0004] The purpose of this application is to provide a high-low layer decoupled traffic robot task planning method, which aims to solve the technical problems of poor interpretability, insufficient security, and difficulty in auditing and reuse caused by the reliance of the underlying execution logic on general scripts in the existing robot task planning methods.

[0005] To achieve the above objectives, this application provides a high-low layer decoupled traffic robot task planning method, comprising: a high-level policy planner generating a sub-task sequence based on acquired state information and task objectives; a low-level policy planner receiving and processing the sub-task sequence to translate the sub-tasks in the sub-task sequence into an action sequence composed of a predefined domain-specific language; and an interpreter executing the action sequence to drive the robot to complete the task.

[0006] As an optional implementation of this application, the robot is a traffic control robot; the status information is traffic status information.

[0007] As an optional implementation of this application, the traffic status information includes: a traffic image in the form of a bird's-eye view or a traffic event queue.

[0008] As an optional implementation of this application, the instructions in the domain-specific language correspond to atomic skills in a standard skill library.

[0009] As an optional implementation of this application, the atomic skill includes at least one of gestures, movement, voice, or whistle.

[0010] As an optional implementation of this application, before executing the action sequence, the method further includes: performing permission verification on the action sequence based on preset rules.

[0011] As an optional implementation of this application, the high-level policy planner is a rule-based decision tree or a policy network based on expert teaching.

[0012] As an optional implementation of this application, during or after the execution of the action sequence, the method further includes: logging the execution process or execution result of the action sequence.

[0013] As an optional implementation of this application, the status information includes a traffic image in the form of a bird's-eye view, and the method further includes: performing image recognition on the traffic image in the form of a bird's-eye view to extract traffic element information before the high-level strategy planner generates the sub-task sequence based on the traffic element information and the task objective.

[0014] As an optional implementation of this application, the high-level strategy planner is a strategy network based on expert teaching, and the data of the expert teaching comes from the command behavior of human traffic controllers.

[0015] Compared with existing technologies, this application has the following beneficial effects: By introducing a structured domain-specific language to replace the general scripting language, every action and decision-making logic of the robot is defined and recorded in a clear, human-readable form, greatly enhancing the interpretability and auditability of robot behavior and facilitating safety compliance review and post-event analysis. By performing permission verification on the action sequence before execution, high-risk actions can be pre-reviewed and restricted based on preset rules, preventing the robot from executing dangerous actions beyond the safety range from the underlying mechanism, significantly improving the operational safety of the system in public transportation environments. The complete decoupling of high-level strategy and low-level execution allows strategy designers to focus on traffic logic without worrying about the implementation details of underlying actions. At the same time, standardized underlying atomic skills can be reused in different tasks and scenarios, improving development efficiency and reusability. In addition, the structured logging function provides powerful diagnostic tools for development and maintenance personnel. When abnormal behavior occurs, the problem scenario can be accurately traced, the cause of the failure can be quickly located, and fault diagnosis and system optimization can be facilitated. Attached Figure Description

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

[0017] Figure 1 A schematic diagram of a traffic robot task planning method with high-low layer decoupling provided in this application embodiment;

[0018] Figure 2 A flowchart illustrating a high-low layer decoupling traffic robot task planning method provided in this application embodiment;

[0019] Figure 3 This is a schematic diagram of the signaling interaction timing of the DSL interpreter provided in the embodiments of this application under a specific task scenario.

[0020] The main reference numerals in the attached diagrams are explained as follows: 10 – High-level strategy planner; 20 – Low-level strategy planner; 30 – DSL interpreter; 40 – Standard skill library; 50 – Robot hardware; 100 – Traffic status; 110 – Task objective; 120 – Subtask sequence; 130 – DSL script; S201 – High-level strategy planner acquires traffic status and task objective; S202 – High-level strategy planner generates subtask sequence; S203 – Low-level strategy planner acquires a subtask; S204 – Low-level strategy planner translates the subtask into a DSL script; S205 – DSL interpreter parses and executes the DSL script; S206 – Execution permission verification; S207 – Calling atomic skills from the skill library to drive the hardware; S208 – Recording execution log; S209 – Determining whether all subtasks have been completed. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0022] Example 1

[0023] This embodiment provides an application scenario for a high-low layer decoupling method for traffic robot task planning, specifically involving the complete process of a traffic control robot performing traffic congestion mitigation tasks at an urban intersection. This embodiment aims to elaborate on the decoupling of task planning, the generation and execution of domain-specific languages, and the collaborative working methods between various system modules.

[0024] Please see Figure 1 This illustration shows a system architecture diagram of a high-low layer decoupled traffic robot task planning method provided in an embodiment of this application. The system can be deployed within the computing unit of a traffic control robot. The robot can be an autonomous device equipped with a mobile chassis, a multi-degree-of-freedom robotic arm, a speaker, warning lights, and a perception system integrated with a camera. The system architecture mainly includes a high-level strategy planner 10, a low-level strategy planner 20, a domain-specific language interpreter 30, a standard skill library 40, and robot hardware 50.

[0025] The high-level strategy planner 10 is responsible for making macro-level strategic decisions. As a software module, it can run on the robot's main computing unit, such as an embedded computer equipped with a high-performance processor and graphics processing unit. Its main function is to receive external input, perform reasoning based on the input, and finally output an abstract subtask sequence 120 that does not contain specific action details. In this embodiment, the input received by the high-level strategy planner 10 includes a task objective 110 and a traffic state 100. The task objective 110 can be issued by a human operator in a remote command center via a wireless communication network, for example, a string instruction containing the content "manage traffic at the intersection". The traffic state 100 is collected in real time by the robot's own sensor system, which in this embodiment is mainly manifested as a bird's-eye view of traffic images obtained by a camera installed on the top of the robot or at a high point at the intersection.

[0026] The low-level policy planner 20 is used to translate macro-level decisions into specific execution instructions. This software module is responsible for receiving the subtask sequence 120 generated by the high-level policy planner 10. Its core function is to translate each abstract subtask in the sequence (e.g., "allowing southbound traffic flow") into a structured, precisely executable action sequence script written in a predefined domain-specific language, i.e., a DSL script 130. To complete this translation process, the low-level policy planner 20 queries the internally maintained standard skill library 40.

[0027] The standard skill library 40 can be understood as a predefined collection of atomic skills that the robot can execute. These atomic skills are modular and reusable functional units. In the traffic control scenario of this embodiment, the skill library includes at least: gesture skills (such as straight-ahead gesture, left-turn gesture, stop gesture, and pull over gesture), movement skills (such as moving to a specified coordinate point, moving along a preset path, and rotating in place by a specified angle), voice communication skills (such as reading specified text, adjusting volume, and selecting speech rate), and whistle warning skills (such as sounding a long whistle and sounding a short warning sound). At the software level, each skill can be a function or method that encapsulates a complex interface for calling the underlying robot hardware 50 (such as a motor controller, servo driver, and audio decoder).

[0028] The domain-specific language interpreter 30 is responsible for parsing and executing the final task instructions. As a lightweight software module, it can run directly on the embedded microcontroller responsible for real-time control to ensure real-time performance and reliability. This interpreter receives the DSL script 130 generated by the low-level policy planner 20 and is responsible for parsing and executing each instruction. When executing instructions, the DSL interpreter 30 calls the corresponding atomic skill functions in the standard skill library 40, thereby driving the robot hardware 50 (e.g., robotic arm, wheeled chassis, speaker, etc.) to perform actual physical actions.

[0029] Please combine Figure 2 This document illustrates a flowchart of a high-low layer decoupling traffic robot task planning method provided in an embodiment of this application. The following will combine... Figure 1 and Figure 2 The working process of the traffic control robot performing the task of easing traffic congestion at intersections in this embodiment is described in detail.

[0030] The working process of this method is explained by taking the traffic control robot deployed at a busy intersection in the city as an example.

[0031] Specifically, in step S201, the high-level strategy planner acquires the traffic status and task objective. The robot receives task objective 110 from the command center, which states "manage traffic at the intersection." Simultaneously, the wide-angle camera on top of the robot continuously captures a panoramic view of the intersection and generates a real-time bird's-eye view traffic image through its internal image processing unit. As an optional implementation, before inputting the traffic image as status information to the high-level strategy planner 10, the system first performs image recognition on the bird's-eye view image to extract structured traffic element information. This image recognition step can be performed by a deep learning-based object detection and tracking model, such as using algorithms like YOLO or Faster R-CNN. The recognition result is quantitative information on all traffic participants in the current scene, such as: 125 vehicles detected in the southbound lane, with an average speed of 5 km / h and a queue length of 150 meters; 80 pedestrians in the eastbound / westbound pedestrian waiting area; and relatively low traffic volume in other directions. This structured traffic element information constitutes the precise traffic status 100 upon which the high-level strategy planner 10 bases its decisions.

[0032] Subsequently, in step S202, the high-level strategy planner generates a sequence of subtasks. Upon receiving the aforementioned task objectives and structured traffic conditions, the high-level strategy planner 10 initiates its internal decision-making logic. In this embodiment, this decision-making logic can be a rule-based system. This system makes judgments based on a preset traffic management knowledge base. For example, the rule base includes "Rule 1: When the queue length in a certain direction exceeds 100 meters and the average speed is less than 10 km / h, that direction is the main congested direction and should be given priority" and "Rule 2: When the number of pedestrians waiting at the sidewalk exceeds 50, pedestrians should be allowed to pass during the gaps in traffic flow." Based on these rules, the high-level strategy planner 10 analyzes the input state information and identifies the primary problem as severe congestion of southbound traffic and the secondary problem as the backlog of eastbound pedestrians. Accordingly, it generates an ordered sequence of subtasks 120, the content of which can be a string array: ["Release southbound traffic", "Easy flow of eastbound and westbound pedestrians", "Restore normal monitoring"]. This sequence represents a macro-level strategy for solving the current traffic problem.

[0033] After this, the system enters the task execution phase. In step S203, the low-level policy planner obtains a subtask, that is, takes the first element "allow southbound traffic flow" from the subtask sequence 120.

[0034] In step S204, the low-level policy planner translates the subtask into a DSL script. The translation process here involves converting the abstract subtask name into a concrete DSL script. For the subtask "allowing southbound traffic flow," the translation process may include: first, identifying the robot itself as the action subject; second, identifying the key action as a "straight-ahead gesture," with auxiliary actions including "movement," "turning," and "voice announcement"; third, determining various action parameters, such as the target point of movement, the duration of the gesture, and the specific content of the voice announcement; and finally, combining the above actions and parameters in a logical order into a structured DSL script 130. This script is in plain text format with strict syntax, facilitating interpreter parsing and human reading and auditing. An example of the generated DSL script 130 is shown below:

[0035] TASK allows southbound traffic to proceed.

[0036] STEP Move to [Point: (10.5, 2.3)]

[0037] STEP Turn [Orientation: 180 degrees] / / Assuming true north is 0 degrees, or orientation is true south

[0038] STEP Execution Gesture [Type: Straight-Ahead Gesture, Duration: 20s]

[0039] STEP announcement [Text: "Vehicles traveling south to north, please proceed quickly", Volume: 90%]

[0040] STEP Wait [Time: 20s]

[0041] END

[0042] As an optional implementation, step S206 can be performed to verify permissions before executing the script. The specific function of this step will be explained in detail in Example 3.

[0043] In step S205, the DSL interpreter parses and executes the DSL script. After receiving the script, the DSL interpreter 30 begins parsing and executing it line by line:

[0044] Parse the TASK line and record the current task name;

[0045] The robot moves to the [point: (10.5, 2.3)] row and identifies the instructions and parameters. Accordingly, in step S207, the move_to_coordinate(x, y) function in the standard skill library 40 is called to drive the wheeled chassis of the robot hardware 50 to move to the specified position;

[0046] Once in position, parse the next row of directions [orientation: 180 degrees] and call the rotate_to_angle(angle) function in the skill library to drive the chassis to rotate to the specified orientation;

[0047] Next, the execution gesture [type: straight gesture, duration: 20s] is parsed and the perform_gesture(type, duration) function in the skill library is called to control the robotic arm of the robot hardware 50 to make a standard straight gesture and hold it for 20 seconds;

[0048] At the same time, the next non-conflicting instruction can be processed in parallel to broadcast the voice [text: "Vehicles traveling from south to north, please proceed quickly", volume: 90%] by calling the broadcast_audio(text, volume) function in the skill library to drive the speaker hardware to broadcast the specified text;

[0049] When parsing reaches the wait time [20s], the interpreter starts an internal timer, pausing the parsing of subsequent instructions during this period;

[0050] After the waiting period ends, the END line is parsed, indicating that the DSL script for this subtask has been executed.

[0051] Throughout the task execution process, the system continuously records execution logs in step S208. The DSL interpreter 30 writes the execution status of each instruction, including instruction content, start and end times, and execution results (such as success, failure, or being blocked), into a log file in a structured format. For example, a log record could be: {"timestamp": "2023-10-27T15:30:10Z", "task_id": "Release southbound traffic", "step": 3, "command": "Execution gesture", "params": {"type": "straight-through gesture", "duration": "20s"}, "result": "Success"}. This type of log greatly enhances the system's auditability and facilitates post-event analysis and troubleshooting.

[0052] After the current subtask is completed, in step S209, it is determined whether all subtasks have been completed. At this time, the system checks whether the subtask sequence 120 is empty. Since the sequence still contains ["Guiding east-west pedestrians", "Restoring normal monitoring"], the result is "No". The process returns to step S203, the low-level strategy planner 20 obtains the next subtask "Guiding east-west pedestrians", and repeats steps S204 to S209 to generate and execute the corresponding DSL script. Until all subtasks are completed, and the result of the determination in step S209 is "Yes", the entire task process ends.

[0053] This embodiment demonstrates the technical advantages of the method provided in this application: the high-level strategy planner 10 focuses on "what to do" (determining the dredging sequence), while the low-level strategy planner 20 and DSL interpreter 30 focus on "how to do it" (generating and executing precise, auditable action sequences). Understandably, this decoupled design makes the system logic clearer, easier to develop and maintain, and ensures a high degree of interpretability and safety of robot behavior through structured DSL and logging.

[0054] Example 2

[0055] This embodiment further illustrates the flexibility and scalability of the method architecture provided in this application. Specifically, this embodiment demonstrates that the high-level strategy planner 10 can be implemented using different technologies without modifying other parts of the system (such as the low-level strategy planner 20, DSL interpreter 30, standard skill library 40, etc.), thus showcasing the technical effectiveness of the method in decoupling high and low levels. The overall system architecture remains as follows. Figure 1 As shown, the process is as follows: Figure 2 As shown, the core difference in this embodiment lies in the implementation method of the decision-making logic within the high-level strategy planner 10.

[0056] In the same traffic congestion scenario as in Example 1, the task objective 110 is also "to alleviate traffic at the intersection". The high-level strategy planner 10 needs to output a subtask sequence 120 ["allowing southbound traffic", "guiding eastbound pedestrians", "restoring normal monitoring"] based on the input traffic state 100. Two optional implementation methods are described below.

[0057] Alternatively, as a first implementation, the high-level strategy planner 10 can be constructed based on a rule-based decision tree. In this implementation, the decision logic consists of a set of explicit "if-then" rules pre-written by human experts, which can be organized into a decision tree structure. Its advantage lies in the complete interpretability of the decision process, facilitating the verification, debugging, and modification of the decision path. Specifically, after receiving structured traffic state information, the high-level strategy planner 10 performs reasoning through a decision tree. Nodes in the decision tree represent a judgment condition, branches represent judgment results, and leaf nodes represent a decision output. A simplified decision tree segment can be:

[0058] The root node determines: "Does a major congestion direction exist?" (Condition: There is a lane C whose traffic flow is greater than threshold A and whose queue length is greater than threshold B).

[0059] If the answer is "yes", proceed to the next node to determine: "Is there an emergency pedestrian crossing need?" (Condition: There is a pedestrian crossing P, and the number of people waiting there is greater than the threshold C).

[0060] If the answer is "No" (i.e., there is no urgent pedestrian demand), the decision tree leads to a leaf node, which outputs the subtask "Prioritize passage in the main congested direction".

[0061] If the result is "yes" (meaning that both vehicle congestion and pedestrian backlog exist simultaneously), then a deeper level of judgment is performed to determine the priority of the subtask.

[0062] In this embodiment, the input state information satisfies the conditions of "southbound lane congestion" and "eastbound pedestrian backlog." Based on its internal rules, the decision tree ultimately outputs "allow southbound traffic to proceed" as the primary subtask and places it at the head of subtask sequence 120. This implementation's decision-making process is a "white-box" operation, making it highly suitable for scenarios with clear rules, relatively fixed scenarios, and high requirements for security and compliance.

[0063] Alternatively, as a second implementation, the high-level policy planner 10 can be built based on a policy network taught by experts. Internally, this implementation uses a deep neural network model trained through machine learning (particularly imitation learning or reinforcement learning), i.e., the policy network. This implementation can learn decision patterns for handling complex or ambiguous traffic situations from massive amounts of data, and these patterns may contain tacit knowledge from human experts. Specifically, the steps for building such a high-level policy planner 10 include:

[0064] Data collection: Recording the traffic control behaviors of experienced human traffic controllers in real or simulated environments to form (traffic status) data. Expert decision-making The data pairs include expert decision-making. This corresponds to a subtask in the method of this application.

[0065] Model Training: Using the above data pairs, a deep neural network model (e.g., containing a convolutional neural network for processing image input and a recurrent neural network for processing temporal information) is trained as a policy network through supervised learning, enabling it to mimic the decision-making behavior of human experts.

[0066] Deployment and Application: The trained policy network is deployed to the high-level policy planner 10. During runtime, it receives real-time traffic conditions 100 and, through network forward propagation, directly outputs one or a series of most probable subtasks, forming a subtask sequence 120. In this embodiment, when the policy network receives the state input "severe congestion from south to north," it will output the subtask "allow south-to-north traffic flow" with high probability, as it has learned a large number of similar situations during training. This implementation can handle more complex and dynamic traffic scenarios than fixed rules, exhibiting better adaptability and generalization capabilities.

[0067] It is important to emphasize that regardless of the implementation method used by the high-level strategy planner 10, its final output to the downstream modules is always a standardized subtask sequence 120. After receiving this sequence, the subsequent DSL translation, script generation, and execution process of the DSL interpreter 30 by the low-level strategy planner 20 are exactly the same as described in Embodiment 1, requiring no modification. Therefore, this embodiment demonstrates that this modular "plug-and-play" characteristic significantly improves the adaptability, maintainability, and development efficiency of the entire robot task planning system.

[0068] Example 3

[0069] This embodiment focuses on how the method of this application improves the safety and intelligence of robots in public safety scenarios by leveraging the advanced functions of domain-specific languages ​​and their interpreters when handling dynamic and interactive tasks. The application scenario of this embodiment is: a traffic control robot detecting a pedestrian jaywalking while on duty at a zebra crossing. This embodiment will combine... Figure 3 The signaling interaction timing diagram shown illustrates in detail how the DSL interpreter 30 processes such dynamic interactive tasks through mechanisms such as permission verification, condition judgment, and sensor interaction.

[0070] Its working process is as follows:

[0071] High-level decision-making: The robot's perception system detects an event: when the pedestrian crossing light is red, a target identified as "pedestrian A" enters the danger zone of the motor vehicle lane. This event is encapsulated and reported to the high-level policy planner 10. The high-level policy planner 10 recognizes this as an emergency danger situation and immediately generates a subtask sequence 120 of a single subtask: ["persuading pedestrian A who has crossed the line"], and sends it down to the low-level policy planner 20.

[0072] Low-level translation and DSL script generation: After receiving the subtask, the low-level policy planner 20 translates it into a more complex DSL script 130 containing conditional logic and security checks. This script not only specifies the actions but also defines the preconditions and contingency measures for those actions. An example of the generated DSL script is shown below:

[0073] TASK: Advise pedestrians who have crossed the line (A)

[0074] STEP Turn to target [Target ID: Pedestrian A]

[0075] STEP Permission Verification [Action: Point to, Area: Sidewalk]

[0076] STEP Execute Gesture [Type: Stop Gesture, Target: Pedestrian A]

[0077] STEP voice prompt [Text: "You have crossed the line, please return to the safe zone!"]

[0078] STEP Wait for feedback [Timeout: 5s, Condition: Pedestrian A is in the safe zone]

[0079] IF condition not met

[0080] STEP voice prompt [Text: "Danger, please retreat immediately!", Volume: 100%]

[0081] STEP - Sound a whistle [Type: Short warning sound, Number of times: 3]

[0082] ELSE

[0083] STEP executes a gesture [Type: Restore to standby stance]

[0084] STEP will play a voice message: [Text: "Thank you for your cooperation."]

[0085] END

[0086] 3. Advanced Execution Process of the DSL Interpreter: After receiving this script, the internal interaction process of the DSL interpreter 30 is as follows: Figure 3 As shown.

[0087] Command parsing and permission verification (corresponding) Figure 3 (Messages 1, 2, 3): The interpreter first parses the target instruction. Before executing the next instruction with a specific execution gesture, it encounters an authorization verification instruction. This instruction, as a critical security verification step (corresponding to step S206), causes the DSL interpreter 30 to suspend execution and communicate with the independent authorization verification module (…). Figure 3 P3 in the middle sends a verification request ( Figure 3Message 2 in the context of the request contains the content {Action: "pointing to", Target area: "sidewalk"}. The permission verification module can internally maintain a set of security rules, such as geofencing rules and action restriction rules. In this scenario, the permission verification module performs a compliance check on the "pointing to sidewalk" behavior and returns a "pass" result. Figure 3 (Message 3 in the code). If the verification fails, the interpreter will skip the instruction and log the exception, thus fundamentally preventing improper behavior.

[0088] Action execution and waiting for feedback (corresponding) Figure 3 Messages 4, 5, 6): After the permission verification is successful, the DSL interpreter 30 continues execution, sending data to the robot executor ( Figure 3 The P5 in the system issues a command, makes a stop gesture, and broadcasts a voice message ( Figure 3 (Message 4 in the original text). Subsequently, the interpreter executes a wait-for-feedback instruction. Understandably, this instruction is a blocking but continuously perceptive instruction regarding the external state. The interpreter starts a 5-second timer and continuously sends signals to the visual sensor during this period. Figure 3 P4 in the request retrieves the latest location data of "Pedestrian A". Figure 3 Message 5 in the document). The visual sensor module continuously tracks the target and returns its current position. Figure 3 (Message 6 in the script) The interpreter compares this information with the condition pedestrian A. location in the safe zone defined in the script.

[0089] Conditional branching logic (corresponding) Figure 3 (China News 7a, 7b)

[0090] In the first scenario (corresponding to the IF branch): if the condition for waiting for feedback is not met within the 5-second timeout period (i.e., the visual sensor feedback shows that pedestrian A is still in the danger zone), the interpreter determines that the conditional expression corresponding to the IF branch is true and jumps to the IF code block for execution. Subsequently, the interpreter will command the robot actuator (P5) to broadcast a more severe warning voice and sound a warning whistle to upgrade the warning level.

[0091] In the second case (corresponding to the ELSE branch): if at any moment within 5 seconds the visual sensor returns data showing that pedestrian A has returned to the safe area, then the condition for waiting for feedback is met. The interpreter will immediately interrupt the wait, determine that the IF condition is false, and jump to the ELSE code block for execution. It will command the robot actuator (P5) to retract its gesture, resume its standby posture, and broadcast a gentle thank-you message. Figure 3 (Message 7b in the text).

[0092] As can be seen from this embodiment, the method of this application, by designing a domain-specific language with rich expressiveness and a powerful DSL interpreter 30, enables the robot to transcend the passive execution of fixed sequences. Specifically, during task execution, the robot can perform proactive security self-checks through permission verification and dynamically adjust subsequent behaviors through conditional branching logic based on real-time environmental interaction results obtained from waiting for feedback instructions. This mechanism significantly improves the robot's autonomy, intelligence, and reliability in complex, dynamic, and security-critical public environments, thus demonstrating the beneficial effects of the technical solution of this application.

[0093] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A high-low layer decoupled task planning method for transportation robots, characterized in that, include: The high-level strategy planner generates a sequence of subtasks consisting of one or more subtasks based on the task objective and current state information. The low-level policy planner receives each subtask in the subtask sequence in sequence and translates each subtask into a corresponding action sequence script. An interpreter module parses and executes the action sequence script to drive the robot to perform actions.

2. The method according to claim 1, characterized in that, The robot is a traffic control robot, and the current status information is traffic status information.

3. The method according to claim 2, characterized in that, The traffic status information is in the form of a bird's-eye view of traffic images or a traffic event queue.

4. The method according to claim 1, characterized in that, The low-level strategy planner maintains a standard skill library, and the action instructions in the action sequence script correspond to the atomic skills in the standard skill library.

5. The method according to claim 4, characterized in that, The atomic skills include at least one of gestures, movement, voice, and whistle.

6. The method according to claim 1, characterized in that, The method further includes at least one of the following steps: Before the interpreter module parses and executes the action sequence script, a permission check is performed; Record execution logs to support subsequent action sequence replay.

7. The method according to claim 6, characterized in that, The permission verification is based on preset rules, which include at least one of geofencing rules or time window rules.

8. The method according to claim 1, characterized in that, The action sequence script, translated by the low-level policy planner, describes at least one of the following: task steps, action parameters, execution order, timeout logic, and conditional branches.

9. The method according to claim 8, characterized in that, The conditional branch is an IF-ELSE structure that makes a judgment based on the obtained feedback information.

10. The method according to claim 1, characterized in that, The high-level strategy planner is at least one of the following: Rule-based decision trees; Policy networks based on expert instruction.

Images