Multi-scene switching scheduling method and system for embodied intelligent robot

Abstract

This invention relates to the field of artificial intelligence technology, specifically to a multi-scene switching scheduling method and system for embodied intelligent robots. The method includes: arranging various scene tasks faced by the robot to obtain a scene task arrangement file; loading scene tasks into memory according to the content of the scene task arrangement file and constructing a scene task tree; understanding the semantics of user input based on a large model, identifying user intent, and identifying and locating the scene tree branch to be executed according to the user intent; creating a corresponding scene task instance for the located scene tree branch, scheduling the scene task execution according to the scene task instance, and controlling the robot to perform corresponding actions according to the scene task. This invention reduces the repetitive training process of embodied intelligent robots by scheduling tasks from a pre-arranged scene task file when facing changing conditions.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and more specifically to a multi-scene switching scheduling method and system for an embodied intelligent robot. Background Technology

[0002] Robot task orchestration is a core component for robots to efficiently execute complex tasks, involving multiple levels such as task decomposition, scheduling optimization, and resource allocation. In traditional industrial robot systems, task orchestration mainly relies on pre-programmed logic and fixed rule engines, such as defining action sequences through PLCs (Programmable Logic Controllers) or robot-specific scripts (such as KUKA KRL and ABB RAPID). Embodied AI Robotics, as a convergence of artificial intelligence and robotics, is driving the leap from passive execution to proactive perception and decision-making in robots. Traditional industrial robots, limited by pre-programmed logic, struggle to cope with dynamic scenarios (such as sudden obstacles and multi-task switching), while embodied AI, through multimodal perception (vision, force, and voice), real-time environmental modeling, and online decision-making, endows robots with similar "body-environment" interaction capabilities.

[0003] Current technology has evolved from single-skill execution (such as grasping and walking) to cross-scenario task generalization (such as the fully autonomous "identification-grasping-placement" process in home services). In this technological context, the common approach is to utilize large models to analyze multimodal input data, including sound and images, interact with the external environment (including humans), understand semantics, recognize intent, decompose and orchestrate tasks to form feasible task sequences, and then manipulate the robot's actions based on these task sequences to complete tasks in specific scenarios. For example, given an input like "Please help me move certain materials," the robot, through a large model, would recognize the intent and decompose it into the following task sequence: 1. Identify the material's location; 2. Navigate to the material; 3. Identify and grasp the material; 4. Navigate to the target location; 5. Place the material.

[0004] In these tasks, each task corresponds to a specific skill or sequence of actions for the robot, and requires the robot to be controlled using pre-trained algorithms or preset action sequences to complete each task. After recognizing the intent, identifying and decomposing the task for a specific scenario also requires pre-training a large model. Therefore, in current engineering practice, based on the actual scenario, a large model is often trained to perform intent recognition, task decomposition, and orchestration for that scenario, while simultaneously training the model or developing action sequences for newly added tasks.

[0005] Current industrial robots primarily rely on pre-programmed logic and fixed rule engines for task orchestration, making them ill-suited to dynamic scene changes. Each time the scene changes, rules must be re-edited or redeveloped. For embodied intelligent robots based on large models, the existing method of task decomposition and orchestration entirely depends on the large model. Even for the same scene, if the decomposed tasks change, the large model still needs to be retrained. Fine-tuning the large model often requires preparing the necessary corpus, computing power, and environment, followed by fine-tuning by algorithm engineers. This not only consumes considerable manpower, computing power, and time but also requires highly skilled technical personnel. In practical applications, conditions in a given scene often change in different locations. Once conditions change, the decomposed and orchestrated tasks also often change. Therefore, while embodied intelligent robots based on large models have better generalization and flexibility compared to traditional industrial robots, the need for repeated adjustments and training of the large model still persists.

[0006] Therefore, how to reduce the repetitive training process of embodied intelligent robots in the face of changing conditions is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0007] In view of this, the present invention provides a multi-scene switching scheduling method and system for embodied intelligent robots. When facing changing conditions, the repeated training process of embodied intelligent robots can be reduced by scheduling tasks from pre-arranged scene task files.

[0008] To achieve the above objectives, the present invention adopts the following technical solution:

[0009] In a first aspect, the present invention provides a multi-scene switching scheduling method for an embodied intelligent robot, comprising the following steps:

[0010] The various scenario tasks that the robot faces are arranged to obtain a scenario task arrangement file;

[0011] The scene tasks are loaded into memory according to the contents of the scene task orchestration file, and a scene task tree is constructed.

[0012] Based on the large model, the semantics of user input are understood, user intent is identified, and the scene tree branch that needs to be executed is identified and located in the scene task tree according to the user intent.

[0013] A corresponding scene task instance is created for the identified scene tree branch. The scene task is scheduled to be executed according to the scene task instance, and the robot is controlled to perform corresponding actions according to the scene task.

[0014] Furthermore, the scenario task orchestration file includes the following fields: task_id, task_name, description, is_active, trigger_mode, steps, node_id, node_type, action_id, action_name, part_id, and params;

[0015] Here, `task_id` represents the unique ID of the scene task; `task_name` represents the name of the scene task; `description` provides a description of the current execution scene, explaining its purpose and applicable situations; `is active` indicates whether the scene task should be activated during the current execution; `trigger_mode` represents the execution mode; `steps` defines and orchestrates all tasks of the current scene task, with each task contained within a node; `node_id` represents the globally unique ID of the current node, used to identify each node during task execution; `node_type` represents the type of the current node; `action_id` represents the uniqueness of each task; `action_name` represents the name of the task; `part_id` represents the robot parts required for the current task execution; and `params` represents the input parameters and their values ​​required for the current task execution.

[0016] Furthermore, trigger_mode includes three execution modes: EVENT, INVOKE, and TIMER;

[0017] Among them, EVENT means event triggering, and the current scene task can only be triggered when an external event occurs;

[0018] INVOKE indicates that it is called directly from the outside. When the large model recognizes the user intent and the specific scenario, it directly calls to trigger the execution of the current scenario task.

[0019] TIMER indicates that the task in the current scenario is executed periodically and repeatedly.

[0020] Furthermore, the steps field contains three node types: Sequence, Parallel, and Wait;

[0021] Here, Sequence means that all tasks in a node are executed sequentially; Parallel means that all tasks in a node can be executed concurrently; Wait means that all tasks in a node are executed sequentially, but the next task must wait for the previous task to finish executing and obtain the result before the next task can be executed.

[0022] Furthermore, the process of constructing the scene task tree includes:

[0023] Automatically construct a root node and treat each scene as an independent branch;

[0024] In each scene, each node in the scene task is traversed sequentially. For each node, a corresponding branch node is constructed according to its type. There are three types of branch nodes: Sequence, Parallel, and Wait.

[0025] Within each node, based on its action_id field, iterate through them one by one, and create a child node for each task node corresponding to action_id, connecting it to the branch node of the corresponding node.

[0026] Furthermore, once the large model identifies the scenario that needs to be executed, the following actions are performed:

[0027] a. If the identified scene ID1 is the same as the currently executing scene ID2, no switching is performed. Otherwise, it is determined whether the robot still has any unfinished tasks being executed. If so, the robot waits for the current task to be completed before performing the following actions. If not, step b is executed directly.

[0028] b. Delete the scene task instance corresponding to the currently executing scene id2;

[0029] c. Assign the currently executing scene id2 to the identified scene id1 to complete the scene switching and scheduling.

[0030] Furthermore, when performing scene scheduling, it also includes: directly setting the scene to be executed through the work scene setting method, and scheduling it through the scene switching scheduler.

[0031] Furthermore, before the scheduling scenario is executed, a scenario validity verification step is also included. The scenario validity verification step includes:

[0032] a. Traverse the part_id field of all task nodes in the current scene task tree to obtain the robot parts that each task node depends on for execution;

[0033] b. Form a set of robot components that all task nodes depend on, forming set A of robot components that all tasks depend on in the current scene;

[0034] c. Obtain the set B of all components connected to the working robot based on the robot body hardware connection module;

[0035] d. Compare and verify the component set A with the component set B. If set A is a subset of set B or set A is equal to set B, the verification passes. If set B is a subset of set A or some components in set B are not present in set A, the verification fails. This indicates that the robot is missing the components required for the current task. Report an error, notify the user through human-machine dialogue, and refuse to execute the current task.

[0036] After validating the scenario validity, it is determined whether the strategy model on which the current scenario task depends has been loaded into the video memory. If it has not been loaded, the strategy model in the video memory is first unloaded, and then the new strategy model is loaded into the video memory to complete the initialization of the strategy model. Then, the scenario tasks and related execution semantics defined in the current scenario task instance are scheduled and executed one by one.

[0037] Secondly, the present invention provides a multi-scene switching scheduling system for an embodied intelligent robot, which employs the method described above, including:

[0038] The scene task orchestration module is used to orchestrate various scene tasks that the robot faces, and obtain scene task orchestration files;

[0039] The scene task management and loading module is used to load scene tasks into memory according to the content of the scene task arrangement file and construct a scene task tree;

[0040] The scene switching and scheduling module is used to understand the semantics of user input based on a large model, identify user intent, locate the scene tree branch to be executed in the scene task tree according to the user intent, and create a corresponding scene task instance for the located scene tree branch.

[0041] The scene task execution engine module is used to schedule the execution of scene tasks based on the scene task instance and control the robot to perform corresponding actions according to the scene task.

[0042] Furthermore, the system also includes: a scene validity verification module and a scene model dynamic management module;

[0043] The scenario legality verification module is used to compare and verify the robot components on which each task node in the current scenario task depends for execution with the components actually connected to the robot.

[0044] The scene model dynamic management module is used to determine whether the strategy model on which the current scene task execution depends has been loaded into the video memory after the scene legality verification is passed. If it is not loaded, the strategy model in the video memory is first unloaded, and then the new strategy model is loaded into the video memory to complete the initialization of the strategy model.

[0045] As can be seen from the above technical solution, compared with the prior art, the present invention has the following beneficial effects:

[0046] This invention transforms the task decomposition and orchestration of scenarios into configuration through configuration files, while using the large model only for semantic understanding and intent recognition. Once the scenario expressed by the user is identified, the tasks corresponding to the scenario configured in the configuration file are scheduled for that scenario. Furthermore, based on changes in scenario conditions and task decomposition, multi-scenario switching and scheduling are achieved, reducing the time spent on repeated training of the large model, improving the generalization of the large model, accelerating application efficiency, and saving training costs.

[0047] By switching scenarios, automatically verifying, and dynamically loading strategy models, the versatility and generalization ability of embodied intelligent robots are improved, accelerating the practical application efficiency of embodied intelligent robots and reducing the actual promotion and application costs of robots. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0049] Figure 1 A flowchart of the multi-scene switching and scheduling method for the embodied intelligent robot provided by the present invention;

[0050] Figure 2 This is a schematic diagram of the multi-scene switching scheduling system for the embodied intelligent robot provided by the present invention. Detailed Implementation

[0051] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0052] In the process of human-computer interaction using large models, recognizing intents and decomposing and orchestrating tasks, the fundamental reason for the need to repeatedly train these large models is that the task decomposition changes due to altered conditions in specific scenarios. If the task decomposition and orchestration of a scenario are configured through a configuration file, and the large model is only used for semantic understanding and intent recognition, then once the user's expressed scenario is identified, the tasks corresponding to that scenario are scheduled according to the orchestration configured in the configuration file. This solves the problem of needing to retrain the large model due to changes in scenario conditions and task decomposition.

[0053] To implement scenario switching and scheduling based on configuration orchestration files, the following three issues need to be addressed:

[0054] 1) Format definition of scene task configuration file: In order to realize scene switching and scheduling, what semantics need to be clearly defined in the configuration file?

[0055] 2) The scenarios corresponding to the scenario task configuration file are far more numerous than the scenarios that the robot needs to perform. In particular, some scenarios may require the robot to use certain special equipment. For example, when using the robot to perform electric welding, it is also necessary to equip the robot with a mask and welding iron tools. Therefore, when the robot's hardware peripherals cannot perform the scenario task that the user wants it to perform on the current day, it needs to be able to reply to the user and refuse to perform the scenario task.

[0056] 3) The strategy models that each task in each scenario depends on are also different. Due to the limitations of hardware memory, it is impossible to load all the strategy models in the scenario task configuration file into the memory. Therefore, when switching scenarios, it is also necessary to be able to dynamically unload and load the models to ensure the smooth execution of scenario tasks.

[0057] To address the above three issues, this invention discloses a multi-scene switching scheduling method for an embodied intelligent robot, comprising the following steps:

[0058] The various scenario tasks that the robot faces are arranged to obtain a scenario task arrangement file;

[0059] The scene tasks are loaded into memory based on the content of the scene task orchestration file, and a scene task tree is constructed.

[0060] Based on the large model, the semantics of user input are understood, user intent is identified, and the scene tree branch that needs to be executed is identified and located in the scene task tree according to the user intent.

[0061] Create a corresponding scene task instance for the identified scene tree branch, schedule the execution of scene tasks based on the scene task instance, and control the robot to perform corresponding actions based on the scene task.

[0062] The following is combined with Figure 1 Further explanation of each of the above steps:

[0063] 1) Scene task arrangement:

[0064] Define a scene task orchestration file, which contains the following fields: task_id, task_name, description, is_active, trigger_mode, steps, node_id, node_type, action_id, action_name, part_id, and params; the file format is as follows:

[0065]

[0066]

[0067] In this file, all tasks in a scene and the orchestration between tasks are defined in a scene task, where:

[0068] task_id represents the unique ID of the task in this scenario.

[0069] task_name represents the name of the scenario task.

[0070] The description provides an explanation of the current execution scenario, clarifying its purpose and applicable situations.

[0071] `is_active` indicates whether the scenario task should be activated during the current execution. `false` means that the scenario task is not activated. For inactive scenario tasks, even if the user requests the robot to execute the scenario task, the robot will not execute it.

[0072] trigger_mode indicates the execution mode, which includes three execution modes: EVENT, INVOKE, and TIMER;

[0073] Among them, EVENT means event triggering, and the current scene task can only be triggered when an external event occurs;

[0074] INVOKE indicates that it is called directly from the outside. When the large model recognizes the user intent and the specific scenario, it directly calls to trigger the execution of the current scenario task.

[0075] TIMER indicates that the task in the current scenario is executed periodically and repeatedly.

[0076] In practical applications, the triggering mode of the scenario task can be determined by following these steps:

[0077] A. Does the triggering of scene tasks need to be integrated with third-party applications, including apps, third-party systems, etc.? If not, and the robot only needs to execute periodically according to a certain time rhythm, then the TIMER method can be used for triggering. For example, a robot vacuum cleaner in home services can clean the house according to a time rhythm, such as cleaning at 8 o'clock every morning.

[0078] B. When a scenario task needs to be triggered by APP operation or third-party system integration, the appropriate method can be determined based on the time requirements of the scenario task execution. When a scenario task is integrated with other business processes and triggered by events generated by those processes, the EVENT method can be used. For example, when integrated with an industrial production line and operating in accordance with the production rhythm, such as loading and unloading materials, the EVENT method is required. Whenever materials need to be moved, an event is generated, triggering the robot to perform the material handling. When a scenario task is integrated with an APP or third-party system and directly called and triggered by the APP or third-party system, the INVOKE method can be used. For example, in a hotel service robot, the hotel management system controls the robot to perform food delivery services. When a food delivery task needs to be performed, the hotel management system can call the robot interface to execute the scenario task; this triggering method is the INVOKE triggering mode.

[0079] steps represents the definition and orchestration of all tasks in the current scene task. Each task is contained in a node, which includes three types of nodes: Sequence, Parallel, and Wait.

[0080] Here, Sequence means that all tasks in a node are executed sequentially; Parallel means that all tasks in a node can be executed concurrently; Wait means that all tasks in a node are executed sequentially, but the next task must wait for the previous task to finish executing and obtain the result before the next task can be executed.

[0081] node_id represents the globally unique ID of the current node. During task execution, each node is identified based on this ID.

[0082] node_type represents the type of the current node, and its value can be any one of the three types above: Sequence, Parallel, and Wait.

[0083] `action_id` represents the uniqueness of each task; `action_name` represents the name of the task; `part_id` represents the robot parts required for the current task execution, such as the chassis, robotic arm, etc.; `model_id` represents the ID of the strategy model to be called for the current task execution; this field is empty if no strategy model is needed; `params` represents the input parameters and their values ​​required for the current task execution. Once a strategy model is specified, the robot will be controlled to perform corresponding actions according to the action values ​​output by the strategy model by calling the strategy model.

[0084] Next, the scene task orchestration file defined above can be edited offline or online. When editing online, the scene task management and loading will be triggered to dynamically load and refresh the scene tasks and their orchestration after editing is completed. Offline editing can be performed when the robot is not performing tasks or is powered off; while online editing can be performed while the robot is performing tasks.

[0085] 2) Scene Task Management and Loading: Responsible for loading scene tasks into memory based on the content of the scene task orchestration file, forming a scene task tree, specifically including:

[0086] Automatically construct a root node and branch each scene (task) as an independent tree branch;

[0087] In each task, each node in the task is traversed sequentially. For each node, a corresponding branch node is constructed according to its type. There are three types of branch nodes: Sequence, Parallel, and Wait.

[0088] Within each node, based on its action_id field, iterate through them one by one, and create a child node for each task node corresponding to action_id, connecting it to the branch node of the corresponding node.

[0089] Subsequently, whenever a scene task needs to be executed, it is only necessary to traverse the scene task tree according to the scene task ID, find the corresponding scene tree branch, copy all the nodes under the scene tree branch to form a new tree node, and then create a corresponding scene task instance for the scene task tree, and schedule the execution of the scene task according to the scene task instance.

[0090] 3) Human-Computer Interaction and Intent Understanding Recognition Based on a Large Model: Each scene has a unique ID. After defining the scene IDs, during normal dialogue in the large model, it is desirable for the large model to output the corresponding scene ID at the end of each scene's dialogue. This ID can then be used to locate the corresponding scene task branch on the scene task tree and create the corresponding scene task instance. Therefore, corresponding prompts need to be designed for the large model and attached to each round of dialogue, inputting them into the large model. After the dialogue, the large model can return the corresponding scene ID based on the recognition result.

[0091] 4) Scene switching scheduling: After the large model identifies the scene that needs to be executed, the following actions are performed:

[0092] a. If the identified scene ID1 is the same as the currently executing scene ID2, no switching is performed. Otherwise, it is determined whether the robot still has any unfinished tasks being executed. If so, the robot waits for the current task to be completed before performing the following actions. If not, step b is executed directly.

[0093] b. Delete the scene task instance corresponding to the currently executing scene id2;

[0094] c. Assign the currently executing scene id2 to the identified scene id1 to complete the scene switching and scheduling.

[0095] 5) Work scene setting: In addition to understanding intent through human-computer interaction of large models, identifying the scene to be executed and calling the scene switching scheduler for scene scheduling, the current scene to be executed can also be set directly through the work scene setting method and scheduled through the scene switching scheduler.

[0096] 6) Scenario Validation: Before the scheduling scenario is executed, a scenario validity verification step is also included. The scenario validity verification step includes:

[0097] a. Traverse the part_id field of all task nodes in the current scene task tree to obtain the robot parts that each task node depends on for execution.

[0098] b. Form a set of robot components that all task nodes depend on, forming a set A of robot components that all tasks in the current scene depend on.

[0099] c. Obtain the set B of all components connected to the working robot based on the robot body hardware connection module.

[0100] d. Compare and verify the component set A with the component set B. If set A is a subset of set B or set A is equal to set B, the verification passes. If set B is a subset of set A or some components in set B are not present in set A, the verification fails. This indicates that the robot is missing the components required for the current task. Report an error, notify the user through human-machine dialogue, and refuse to execute the current task.

[0101] 7) Dynamic management of scene models: After the scene legality is verified, it is determined whether the strategy model on which the current scene task depends has been loaded into the video memory. If it is not loaded, the strategy model in the video memory is unloaded first, and then the new strategy model is loaded into the video memory to complete the initialization of the strategy model.

[0102] 8) Scene Task Execution Engine: After ensuring that the strategy model has been loaded into the video memory, it schedules and executes scene tasks one by one according to the scene tasks and related execution semantics defined in the current scene task instance.

[0103] 9) Robot body hardware connection: Connects to various components of the robot body to obtain the current status and data of the components, and controls the robot hardware to execute corresponding action commands according to the control commands issued in the scenario task.

[0104] In another embodiment, such as Figure 2 As shown, the present invention also provides a multi-scene switching scheduling system for embodied intelligent robots, which employs the above-described method, including:

[0105] The scene task orchestration module is used to orchestrate various scene tasks that the robot faces, and obtain scene task orchestration files;

[0106] The scene task management and loading module is used to load scene tasks into memory according to the content of the scene task orchestration file and build a scene task tree;

[0107] The scene switching and scheduling module is used to understand the semantics of user input based on a large model, identify user intent, locate the scene tree branch to be executed in the scene task tree according to the user intent, and create a corresponding scene task instance for the located scene tree branch.

[0108] The scene task execution engine module is used to schedule the execution of scene tasks according to the scene task instance, and control the robot to perform corresponding actions according to the scene task.

[0109] The scene legality verification module is used to compare and verify the robot components that each task node in the current scene task depends on with the actual components connected to the robot.

[0110] The scene model dynamic management module is used to determine whether the strategy model on which the current scene task depends has been loaded into the video memory after the scene legality verification is passed. If it is not loaded, the strategy model in the video memory is unloaded first, and then the new strategy model is loaded into the video memory to complete the initialization of the strategy model.

[0111] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0112] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A multi-scene switching scheduling method for an embodied intelligent robot, characterized in that, Includes the following steps: The various scenario tasks that the robot faces are arranged to obtain a scenario task arrangement file; The scene tasks are loaded into memory according to the contents of the scene task orchestration file, and a scene task tree is constructed. Based on the large model, the semantics of user input are understood, user intent is identified, and the scene tree branch that needs to be executed is identified and located in the scene task tree according to the user intent. A corresponding scene task instance is created for the identified scene tree branch, the scene task is scheduled to be executed according to the scene task instance, and the robot is controlled to perform corresponding actions according to the scene task. Before the scheduling scenario is executed, a scenario validity verification step is also included. The scenario validity verification step includes: a. Traverse all task nodes in the current scene's task tree. part_id The field retrieves the robot components that each task node depends on for execution; part_id represents the robot components required for the current task execution. b. Form a set of robot components that all task nodes depend on, forming set A of robot components that all tasks depend on in the current scene; c. Obtain the set B of all components connected to the working robot based on the robot body hardware connection module; d. Compare and verify the component set A with the component set B. If set A is a subset of set B or set A is equal to set B, the verification passes. If set B is a subset of set A or some components in set B are not present in set A, the verification fails. This indicates that the robot is missing the components required for the current task. Report an error, notify the user through human-machine dialogue, and refuse to execute the current task.

2. The multi-scene switching and scheduling method for embodied intelligent robots according to claim 1, characterized in that, The scenario task orchestration file contains the following fields: task_id , task_name , description , is_active , trigger_ mode , steps , node_id , node_type , action_id , action_name , part_id and params ; in, task_id This represents a unique ID for the task in this scenario; task_name Indicates the name of the scene / task; description This indicates a description of the current execution scenario, explaining its purpose and applicable circumstances; is_active This indicates whether the task in this scenario should be activated during the current execution. trigger_mode Indicates the execution mode; steps This indicates that all tasks in the current scene are defined and arranged, with each task contained in a node; node_id This represents the globally unique ID of the current node, which is used to identify each node during task execution. node_type Indicates the type of the current node; action_id This indicates the uniqueness of each task; action_name represents the name of the task; params represents the input parameters and their values ​​required for the execution of the current task.

3. The multi-scene switching and scheduling method for embodied intelligent robots according to claim 2, characterized in that, trigger_mode It includes three execution modes: EVENT, INVOKE, and TIMER; Among them, EVENT means event triggering, and the current scene task can only be triggered when an external event occurs; INVOKE indicates that it is called directly from the outside. When the large model recognizes the user intent and the specific scenario, it directly calls to trigger the execution of the current scenario task. TIMER indicates that the task in the current scenario is executed periodically and repeatedly.

4. The multi-scene switching and scheduling method for embodied intelligent robots according to claim 2, characterized in that, steps The field contains three node types: Sequence, Parallel, and Wait; Here, Sequence means that all tasks in a node are executed sequentially; Parallel means that all tasks in a node can be executed concurrently; Wait means that all tasks in a node are executed sequentially, but the next task must wait for the previous task to finish executing and obtain the result before the next task can be executed.

5. The multi-scene switching and scheduling method for embodied intelligent robots according to claim 4, characterized in that, The process of constructing the scene task tree includes: Automatically construct a root node and treat each scene as an independent branch; In each scene, each node in the scene task is traversed sequentially. For each node, a corresponding branch node is constructed according to its type. There are three types of branch nodes: Sequence, Parallel, and Wait. In each node, according to its subordinate action_id The fields are iterated through one by one, and each task node corresponding to action_id is created as a child node and connected to the tree branch node of the corresponding node.

6. The multi-scene switching and scheduling method for embodied intelligent robots according to claim 1, characterized in that, Once the large model identifies the scenario that needs to be executed, the following actions are performed: a. If the identified scene ID1 is the same as the currently executing scene ID2, no switching is performed. Otherwise, it is determined whether the robot still has any unfinished tasks being executed. If so, the robot waits for the current task to be completed before performing the following actions. If not, step b is executed directly. b. Delete the scene task instance corresponding to the currently executing scene id2; c. Assign the currently executing scene id2 to the identified scene id1 to complete the scene switching and scheduling.

7. The multi-scene switching and scheduling method for embodied intelligent robots according to claim 1, characterized in that, When performing scene scheduling, it also includes: directly setting the scene to be executed through the work scene setting method, and scheduling it through the scene switching scheduler.

8. The multi-scene switching and scheduling method for embodied intelligent robots according to claim 1, characterized in that, After validating the scenario validity, it is determined whether the strategy model on which the current scenario task depends has been loaded into the video memory. If it has not been loaded, the strategy model in the video memory is first unloaded, and then the new strategy model is loaded into the video memory to complete the initialization of the strategy model. Then, the scenario tasks and related execution semantics defined in the current scenario task instance are scheduled and executed one by one.

9. A multi-scene switching and scheduling system for an embodied intelligent robot, characterized in that, It employs the method described in any one of claims 1-8, comprising: The scene task orchestration module is used to orchestrate various scene tasks that the robot faces, and obtain scene task orchestration files; The scene task management and loading module is used to load scene tasks into memory according to the content of the scene task arrangement file and construct a scene task tree; The scene switching and scheduling module is used to understand the semantics of user input based on a large model, identify user intent, locate the scene tree branch to be executed in the scene task tree according to the user intent, and create a corresponding scene task instance for the located scene tree branch. The scene task execution engine module is used to schedule the execution of scene tasks based on the scene task instance and control the robot to perform corresponding actions according to the scene task.

10. The multi-scene switching and scheduling system for embodied intelligent robots according to claim 9, characterized in that, Also includes: Scene validity verification module and scene model dynamic management module; The scenario legality verification module is used to compare and verify the robot components on which each task node in the current scenario task depends for execution with the components actually connected to the robot. The scene model dynamic management module is used to determine whether the strategy model on which the current scene task execution depends has been loaded into the video memory after the scene legality verification is passed. If it is not loaded, the strategy model in the video memory is first unloaded, and then the new strategy model is loaded into the video memory to complete the initialization of the strategy model.

Images