Amr robot scheduling method and device, scheduling equipment and readable storage medium

Abstract

The application relates to an AMR robot scheduling method and device, a scheduling device and a readable storage medium. By introducing a large language model and a model context protocol (MCP) technology, the scheduling agent can automatically parse a fuzzy and high-level natural language instruction into a specific and executable task to drive a complex robot cluster, thereby realizing robot cluster scheduling without human intervention and reducing the dependence on manual supervision. The problems of low efficiency of manual task decomposition and supervision and rigid traffic control in a complex scene in the traditional technology are solved.

Description

Technical Field

[0001] This application relates to the field of intelligent control technology, and in particular to an AMR robot scheduling method, apparatus, scheduling equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the deepening of intelligent manufacturing, Autonomous Mobile Robots (AMRs) have been widely used in industrial production and daily life, encompassing various forms such as unmanned forklifts, transport vehicles, robotic arms, and humanoid robots. In practical applications, these robots undertake diverse functions such as material handling, goods grasping, and automated assembly. To cope with complex production or daily life needs, multiple heterogeneous robots are often required to work collaboratively. For example, in a complex warehousing or manufacturing task, multiple unmanned forklifts may be needed to gather goods from a specific area, followed by robotic arms to shelving the goods, and finally, transport vehicles to transport them to a designated destination. This multi-robot collaborative mode greatly enhances the overall operational capability and flexibility of the system.

[0003] However, existing multi-robot collaborative scheduling systems still face significant technical bottlenecks when dealing with complex tasks. Traditional AMRs essentially operate more as "passive execution terminals," heavily reliant on manual intervention or backend systems to operate under preset paths and fixed instructions. When faced with scenarios involving multiple concurrent tasks, complex paths, dense equipment, or dynamically changing environments, traditional systems have weak autonomous adjustment capabilities, often requiring deep human intervention. Specifically, the execution of complex tasks typically requires professionals to manually break down tasks, allocate resources, plan paths, and write underlying execution programs, while also monitoring the entire execution process. Once congestion, temporary obstacles, or sudden demands occur on-site, the system is highly susceptible to scheduling rigidity and delayed response. This highly manual intervention-dependent model not only leads to high initial investment and maintenance costs but also requires repetitive and arduous manual operations for production changes and task adjustments, severely restricting the system's flexibility and overall efficiency. Summary of the Invention

[0004] Therefore, it is necessary to provide an AMR robot scheduling method, apparatus, scheduling equipment, computer-readable storage medium, and computer program product to address the aforementioned technical problems.

[0005] In a first aspect, this application provides an AMR robot scheduling method, which is applied to a scheduling agent, and the method includes: Obtain task instructions issued in natural language, the task instructions including a brief description of the task content and the type of robot required for the task; The task instruction is matched with the task description information of multiple predefined task types using a large language model to determine the target task type to which the task instruction belongs. Each task type is associated with at least one robot type. From the preset Model Context Protocol (MCP) toolset, target MCP tools that match the robot type required for the target task type are selected to obtain the target MCP toolset; Based on the task description, execution steps, and execution guidelines of the target task type, the large language model is invoked to generate a task execution plan; Based on the task execution plan, the target MCP tool in the target MCP tool set is invoked to drive the corresponding robot to execute the task. During the task execution process, the status of the task execution plan is recorded and read through the task plan read / write tool until the task in the task execution plan is completed.

[0006] In one embodiment, each MCP tool in the MCP toolset is configured with tool metadata, which identifies one or more robot types to which the MCP tool is adapted; The step of selecting target MCP tools from a preset Model Context Protocol (MCP) toolset that match the robot type required for the target task type includes: Obtain the first list of robot types associated with the target task type; Traverse the tool metadata of each MCP tool in the MCP toolset to determine the list of second robot types that the MCP tool is compatible with; If it is determined that there is an intersection between the first robot type list and the second robot type list, the MCP tool corresponding to the intersection is determined as the target MCP tool.

[0007] In one embodiment, after invoking the target MCP tool in the target MCP toolset to drive the corresponding robot to perform the task, the method further includes: The robot's real-time location is monitored during task execution, and traffic control is implemented based on the real-time location. The traffic control is used to manage the robot's passage within a preset mutually exclusive zone.

[0008] In one embodiment, the mutex region includes a regular mutex region and a dedicated mutex region; The ordinary mutual exclusion zone is set in a narrow road area. When the ordinary mutual exclusion zone is occupied, robots traveling in the same direction are allowed to enter. The exclusive mutual exclusion zone is set in the loading and unloading area. When the exclusive mutual exclusion zone is occupied, other robots are not allowed to enter.

[0009] In one embodiment, monitoring the robot's real-time location during task execution and implementing traffic control based on the real-time location includes: Obtain the area range in which the robot performs its tasks, and determine at least one mutually exclusive region and its corresponding location range based on the area range; Monitor the robot's real-time position during task execution; If the distance between the robot's real-time position and any mutual exclusion zone is determined to be less than a set distance threshold, the type and lock identifier of any mutual exclusion zone are obtained. If it is determined that the lock is unlocked and the type of any mutex is a normal mutex, then the robot satisfies the passage condition for any mutex. If it is determined that the lock is locked, the type of any mutual exclusion zone is a normal mutual exclusion zone, and the robot's travel direction is the same as that of the currently locked robot, then it is determined that the robot meets the passage conditions for any mutual exclusion zone. If it is determined that the lock is unlocked, the type of any mutual exclusion zone is an exclusive mutual exclusion zone, and there are no other queuing robots, then the robot is determined to meet the passage conditions for any mutual exclusion zone. The robot that meets the passage conditions is allowed to pass normally through any of the mutually exclusive zones.

[0010] In one embodiment, the method further includes: If it is determined that the lock is locked, the type of any mutual exclusion zone is a normal mutual exclusion zone, and the robot's travel direction is different from that of the currently locked robot, it is determined that the robot does not meet the passage conditions for any mutual exclusion zone, and the robot is controlled to wait outside any mutual exclusion zone. If it is determined that the lock is locked and the type of any mutex is an exclusive mutex, then if it is determined that the robot does not meet the passage conditions for any mutex, the robot is added to the queuing queue and waits according to the arrival time. If it is determined that the lock is unlocked, the type of any mutex is exclusive mutex, and there are other queuing robots, then it is determined that the robot does not meet the passage conditions for any mutex, and the robot is added to the queuing queue and waits according to the arrival time.

[0011] In one embodiment, the task execution plan includes at least one subtask, and the task plan read / write tool includes a read plan tool and a write plan tool; The process of recording and reading the status of the task execution plan using a task plan read / write tool during task execution includes: The task execution plan subtasks and initial states in the task execution plan are written into memory by the writing plan tool, wherein the initial state is a pending state. Before executing each subtask, the read plan tool is invoked to read the subtask to be executed and its corresponding status from the memory; During the execution of the subtask to be executed, the status of the corresponding subtask is updated to "in progress"; after the execution of the subtask to be executed is completed, the status of the corresponding subtask is updated to "completed", and the status of the subtask is synchronously updated to memory through the write plan tool.

[0012] Secondly, this application also provides an AMR robot scheduling device, which is applied to a scheduling agent, and the device includes: The task acquisition module is used to acquire task instructions issued in natural language, which include a brief description of the task content and the type of robot required for the task. The target task determination module is used to match the task instruction with the task description information of multiple predefined task types using a large language model, and determine the target task type to which the task instruction belongs. Each task type is associated with at least one robot type. The target tool determination module is used to filter out target MCP tools that match the robot type required by the target task type from a preset Model Context Protocol (MCP) toolset, thereby obtaining a target MCP toolset. The task plan generation module is used to generate a task execution plan by calling the large language model based on the task description, execution steps and execution instructions of the target task type. The task execution module is used to call the target MCP tools in the target MCP toolset to drive the corresponding robot to perform tasks based on the task execution plan, and to record and read the status of the task execution plan through the task plan read and write tool during the task execution process until the task execution in the task execution plan is completed.

[0013] Thirdly, this application also provides a scheduling device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in the first aspect above.

[0014] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0015] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect above.

[0016] The aforementioned AMR robot scheduling method, apparatus, scheduling equipment, computer-readable storage medium, and computer program product acquire task instructions issued in natural language form; use a large language model to match the task instructions with task description information of multiple predefined task types to determine the target task type to which the task instructions belong; select target MCP tools from a pre-set Model Context Protocol (MCP) toolset that match the robot type required by the target task type to obtain a target MCP toolset; generate a task execution plan by calling the large language model based on the task description, execution steps, and execution guidance of the target task type; and drive the corresponding robot to execute the task by calling the target MCP tools in the target MCP toolset based on the task execution plan, and record and read the status of the task execution plan through a task plan read / write tool during the task execution process until the task execution in the task execution plan is completed. By introducing large language model and Model Context Protocol (MCP) technology, the scheduling agent can automatically parse fuzzy, high-level natural language instructions into specific, executable task types, thereby realizing human-free robot cluster scheduling and reducing reliance on human supervision. Attached Figure Description

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

[0018] Figure 1 This is an application environment diagram of the AMR robot scheduling method in one embodiment; Figure 2 This is a flowchart illustrating an AMR robot scheduling method in one embodiment; Figure 3 This is a flowchart illustrating the steps for screening target MCP tools in one embodiment; Figure 4 This is a flowchart illustrating the traffic control steps in one embodiment; Figure 5 This is a structural block diagram of an AMR robot scheduling device in one embodiment; Figure 6 This is an internal structure diagram of the scheduling device in one embodiment. Detailed Implementation

[0019] 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 embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0020] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0021] The AMR robot scheduling method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, the scheduling agent 102 communicates with the AMR robot 104 via a network. The data storage system can store the data that the scheduling agent 102 needs to process. The data storage system can be integrated into the scheduling agent 102 or placed in the cloud or on another network server.

[0022] Among them, AMR robot 104 is an autonomous mobile robot that perceives its environment in real time through LiDAR and cameras, navigates autonomously using Simultaneous Localization and Mapping (SLAM) technology, and has intelligent obstacle avoidance capabilities. For example, AMR robot 104 can be a driverless forklift, a transport vehicle, a robotic arm, a humanoid robot, etc.

[0023] The scheduling agent 102 is a software system that integrates a Large Language Model (LLM) or is capable of interacting with a LLM. It understands natural language commands and translates them into specific control operations for an AMR robot swarm. During robot execution, it dynamically adjusts the robot's movement order and path based on on-site road conditions to ensure efficient task completion. The scheduling agent 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, drones, low-altitude aircraft, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart vehicle devices, and projection devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses. The scheduling agent 102 can also be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. In one exemplary embodiment, such as Figure 2 As shown, an AMR robot scheduling method is provided, aiming to solve the problems of traditional multi-robot collaborative operations, such as reliance on manual task decomposition, low efficiency of supervision and execution, and rigid traffic control in complex scenarios, by introducing AI agents and Model Context Protocol (MCP) technology, thereby achieving unmanned or minimally human-intensive robot swarm management. This embodiment applies this method to... Figure 1 Taking the scheduling agent 102 in the example, the specific steps may include: Step 202: Obtain task instructions issued in natural language.

[0024] The task instruction can be a specific instruction or command to perform the task. The task instruction can include a brief description of the task content and the type of robot required for the task.

[0025] For example, in real-world industrial or daily life scenarios, users can issue task commands via natural language. For instance, a user-input task command could be "Call two intelligent forklifts to move goods from warehouse A to production area B." Here, the task content is briefly described as "move goods from warehouse A to production area B," and the required robot type is "two intelligent forklifts."

[0026] After receiving the task instruction, the scheduling agent can perform scheduling processing based on subsequent steps, thereby achieving unmanned scheduling.

[0027] Step 204: Use a large language model to match the task instruction with the task description information of multiple predefined task types to determine the target task type to which the task instruction belongs.

[0028] In this embodiment, the scheduling agent predefines multiple task types (such as area handling, fixed-point grasping, patrolling, etc.). Each task type has a unique task identifier and is associated with task description information (briefly describing the content to be completed and the type of robot used), execution steps (describing the specific steps to execute this task), execution instructions (describing the constraints on the large model), and the required robot type (specifying the type of robot to complete the task, such as an intelligent forklift, a transport vehicle, a humanoid robot, etc.). The target task type is the task type that matches the task instruction among the predefined multiple task types.

[0029] Upon receiving the task instruction, the scheduling agent sends the user-input task instruction along with task descriptions for all predefined task types to the large language model. The large language model analyzes whether a task type matches the task instruction. If a matching task type exists, it becomes the target task type, and the agent returns the task identifier and description information for that target task type. If no matching task type exists, the scheduling process ends, and a prompt message can be issued to remind staff to perform manual scheduling. The large language model can be Deepseekv4-flash, glm-5.1, etc.

[0030] For example, the scheduling agent can interact with a large language model based on preset prompts to determine the target task type to which the task instruction belongs. For instance, the preset prompts might be as follows: "You are a task classification expert for a robot scheduling system. Your job is to analyze task instructions input in natural language and determine what type of task they describe."

[0031] Please return only the task identifier and task description information in JSON format. Do not return any other content. If no suitable option is available, return 0. For example: {{"task_type_id":xxx,"task_type_name":xxx}} Task Type: <Task description information for all predefined task types> User input: "<User-input task command>" For example, if the user inputs a task instruction of "call two smart forklifts to move goods from warehouse area A to production area B", the large language model semantically matches the task instruction with the task description information of each task type based on the above prompt words. It determines that the task instruction belongs to the "area handling task" type, with a task identifier of "1" and a task description of "using forklifts or handling vehicles for area handling". Then, it returns a classification result in JSON format: {"task_type_id":1,"task_type_name":"using forklifts or handling vehicles for area handling"}.

[0032] Step 206: Select target MCP tools from the preset Model Context Protocol (MCP) toolset that match the robot type required for the target task type, and obtain the target MCP toolset.

[0033] The MCP (Model Context Protocol) toolset serves as a bridge connecting large language models with the capabilities of physical robots. In this embodiment, the MCP protocol can be used to construct the robot's MCP toolset. Each MCP tool corresponds to a specific skill of the robot, such as "forklift movement," "forklift picking up goods," and "transport vehicle moving to a designated location."

[0034] In one scenario, to address the slow response issues caused by the limitations of large language model context length and the sheer number of MCP tools, each MCP tool is configured with tool metadata. The tool metadata identifies one or more robot types that the MCP tool is compatible with.

[0035] For example, when defining an MCP tool, developers can use the `@register_tool_with_metadata` decorator to annotate it and define the `tool_types` field in the metadata to identify which types of robots the tool can be used on. For example: "@register_tool_with_metadata( meta={"tool_types":[FOOD_DELIVERY_ROBOT,FORKLIFT,GUIDE_ROBOT,HANDLING_ROBOT_NO_LIFT,HANDLING_ROBOT_LIFT,WHEELED_EMBODIED_ROBOT] } )” In this context, FOOD_DELIVERY_ROBOT represents a food delivery robot, FORKLIFT represents a smart forklift, GUIDE_ROBOT represents a guided robot, HANDLING_ROBOT_NO_LIFT represents a non-lifting transport vehicle, HANDLING_ROBOT_LIFT represents a transport vehicle with a lift, and WHEELED_EMBODIED_ROBOT represents a wheeled automaton robot. This indicates that the MCP tool can be used on these types of robots. By binding the MCP tool to robot types in a one-to-many manner, it effectively reduces the number of tools injected into the context of large language models, lowers token consumption, and improves the efficiency and accuracy of model selection tools.

[0036] Therefore, by examining the metadata of each MCP tool, we can determine which type of robot each tool can be used on. Furthermore, based on the target task type of the task instruction identified in the aforementioned steps, we can determine which type of robot is needed to complete the task. Using these two pieces of information, we can filter out the target MCP tools needed to complete the task, thus obtaining the target MCP toolset.

[0037] Step 208: Based on the task description, execution steps, and execution guidelines of the target task type, call the large language model to generate a task execution plan.

[0038] In this embodiment, the scheduling agent can generate a detailed task execution plan by invoking a large language model based on the task description, execution steps, and execution instructions of the target task type. This task execution plan typically includes multiple subtasks and their execution order.

[0039] For example, the scheduling agent can construct prompt words based on the task description, execution steps, and execution instructions of the target task type to interact with the large language model, instructing the large language model to generate a task execution plan. For instance, the constructed prompt words could be as follows: "You are the expert in scheduling robots to complete tasks. Please think in Chinese."

[0040] ## Task Description: <Description information of the task type> ## Execution Steps: <Execution Steps for Task Type> ## Execution Guidelines: <Execution Guidelines for Task Types> For complex tasks (more than 3 steps), task decomposition is necessary. The decomposed tasks are recorded using the `write_plan` tool. Initially, each task is in a "pending" state. After execution, the status changes to "in progress," and the `write_plan` tool is called to record it. Upon completion, the status changes to "completed," and the `write_plan` tool is called again to record it.

[0041] Before executing each subtask, the read_plan tool is called to read the task plan.

[0042] area_id: {area_id} User input: {input_text}” The task description information briefly describes what the task entails and the type of robot used. For example, the task description information could be "Use a forklift or pallet truck to move goods between areas. Move goods from one area to another."

[0043] Execution steps describe the specific steps involved in performing this task. For example, execution steps could be: "Analyze the required number and type of robots."

[0044] Analyze the supply area and the spot area.

[0045] Analyze the actions performed after each robot task is completed.

[0046] Before executing a task, a business ID must be created and used to lock the robot being used.

[0047] Call a specified number of robots to perform area transport. If no specific robot is specified, assign the nearest one to the job.

[0048] Once any machine completes its task, the robot is unlocked and released. After the lock is released, the operation for each robot after its task is completed is executed.

[0049] Execution guidelines are used to describe constraints on large models. For example, execution guidelines can be: "Think step by step."

[0050] Check the conditions before execution.

[0051] Before execution, output an execution plan based on the above execution steps.

[0052] "Do not make any assumptions; check the execution results by calling the tool."

[0053] For example, taking the user-input task instruction as "call two smart forklifts to move goods from the warehouse area to the production area", the task execution plan generated by the large language model based on the system prompt words can be in the following style: { "plan_id": "PLAN_20250718_001", "business_id": "BIZ_20250718_001", "sub_tasks": [ { "step_id": 1, "description": "Analysis of the required number and type of robots: 2 forklifts are needed", "status": "Pending", "tools": ["query_robot_status"] }, { "step_id": 2, "description": "Analyze the location of the loading area (warehouse area) and unloading area (production area)," "status": "Pending", "tools": ["query_area_info"] }, { "step_id": 3, "description": "Create a business ID and lock 2 forklifts", "status": "Pending", "tools": ["create_business_id", "lock_robot"] }, { "step_id": 4, "description": "Assign two of the nearest forklifts to move goods from the warehouse area to the production area", "status": "Pending", "tools": ["dispatch_robot", "move_to_area", "forklift_load", "forklift_unload"] }, { "step_id": 5, "description": "Unlocked and released after the first forklift completes the mission", "status": "Pending", "tools": ["unlock_robot"] }, { "step_id": 6, "description": "Unlocked and released after the second forklift completes the mission", "status": "Pending", "tools": ["unlock_robot"] } ] }” Step 210: Based on the task execution plan, call the target MCP tool in the target MCP tool set to drive the corresponding robot to execute the task, and record and read the status of the task execution plan through the task plan read and write tool during the task execution process until the task execution in the task execution plan is completed.

[0054] The scheduling agent can sequentially call specific tools from the target MCP toolkit according to the task execution plan. Each tool call is translated into low-level control instructions for a specific robot, driving the robot to complete corresponding actions, such as navigation, transportation, and grasping, until all subtasks in the entire task plan have been executed.

[0055] In one scenario, to address the potential "forgetting" problem that large language models may encounter when handling complex tasks (such as multi-step tasks), this embodiment introduces a task plan read / write tool, including a write plan tool `write_plan` and a read plan tool `read_plan`. For example, at the start of a task, the agent calls the `write_plan` tool to write the entire task execution plan (including all subtasks and their initial states, such as "pending") to external memory (such as Redis). Before executing each subtask, the agent calls the `read_plan` tool to read the currently pending subtask and its corresponding state from memory to ensure its decisions are based on the latest global information. During and after the execution of the pending subtask, the agent calls the `write_plan` tool again to update the subtask's state to "in progress" (corresponding to the subtask being executed) or "completed" (corresponding to the subtask being completed) and synchronizes it to memory. This embodiment, through this external memory mechanism, can prevent large models from forgetting the initial plan and its completion status when executing complex tasks, thus avoiding task interruptions or logical confusion, ensuring the continuity and reliability of task execution.

[0056] Understandably, before driving the robot to execute a task, the process includes creating a business identifier and locking the robot based on that identifier. Once the robot completes its task, the lock is released, and a pre-defined task completion operation is executed. This ensures that the same robot can only be exclusively used by one business task at a time, fundamentally avoiding resource contention and scheduling conflicts.

[0057] In the aforementioned AMR robot scheduling method, task instructions issued in natural language are acquired; a large language model is used to match the task instructions with task descriptions of multiple predefined task types to determine the target task type to which the task instructions belong; target MCP tools matching the robot type required by the target task type are selected from a pre-set Model Context Protocol (MCP) toolkit, resulting in a target MCP toolkit; a task execution plan is generated by calling the large language model based on the task description, execution steps, and execution guidelines of the target task type; based on the task execution plan, the target MCP tools in the target MCP toolkit are called to drive the corresponding robot to execute the task, and the status of the task execution plan is recorded and read through a task plan read / write tool during the task execution process until the task execution in the task execution plan is completed. By introducing a large language model and Model Context Protocol (MCP) technology, the scheduling agent can automatically parse fuzzy, high-level natural language instructions into specific, executable task types, thereby achieving human-free robot cluster scheduling and reducing reliance on human supervision.

[0058] In one exemplary embodiment, such as Figure 3 As shown, in step 206, target MCP tools that match the robot type required by the target task type are selected from the preset Model Context Protocol (MCP) toolset. Specifically, this may include: Step 302: Obtain the list of first robot types associated with the target task type.

[0059] Specifically, after determining the target task type, the agent first obtains the first robot type list associated with that target task type.

[0060] Step 304: Traverse the tool metadata of each MCP tool in the MCP tool set to determine the list of second robot types that the MCP tool is compatible with.

[0061] Then, iterate through all MCP tools in the MCP tool set, read the robot type that each MCP tool is adapted to from its metadata, and obtain a second list of robot types adapted to each MCP tool.

[0062] Step 306: If it is determined that there is an intersection between the first robot type list and the second robot type list, the MCP tool corresponding to the intersection is determined as the target MCP tool.

[0063] By comparing the first list of robot types with the second list of robot types that each MCP tool is compatible with, if there is an intersection between the first list of robot types and the second list of robot types for a certain MCP tool, it indicates that the MCP tool can be used to perform the current task, and it is selected as the target MCP tool. Ultimately, all the selected target MCP tools constitute the target MCP toolset.

[0064] For example, if the target task type is "area handling task", the required robot type is extracted to obtain a first robot type list, such as [FORKLIFT, HANDLING_ROBOT_NO_LIFT].

[0065] If the MCP toolset includes four MCP tools: A, B, C, and D, then the second robot type list of MCP tool A is [FORKLIFT, HANDLING_ROBOT_NO_LIFT, HANDLING_ROBOT_LIFT]; the second robot type list of tool B is [FOOD_DELIVERY_ROBOT]; the second robot type list of tool C is [FORKLIFT]; and the second robot type list of tool D is [GUIDE_ROBOT].

[0066] This is achieved by intersecting the first list of robot types with the second list of robot types for each tool. For example, tool A: [FORKLIFT, HANDLING_ROBOT_NO_LIFT] ∩ [FORKLIFT, HANDLING_ROBOT_NO_LIFT, HANDLING_ROBOT_LIFT] = [FORKLIFT, HANDLING_ROBOT_NO_LIFT], since there is an intersection, it is selected.

[0067] Tool B: [FORKLIFT, HANDLING_ROBOT_NO_LIFT] ∩ [FOOD_DELIVERY_ROBOT]=[], no intersection, excluded.

[0068] Tool C: [FORKLIFT, HANDLING_ROBOT_NO_LIFT] ∩ [FORKLIFT] = [FORKLIFT], there is an intersection, select it.

[0069] Tool D: [FORKLIFT, HANDLING_ROBOT_NO_LIFT] ∩ [GUIDE_ROBOT] = [], no intersection, excluded.

[0070] The final target MCP toolset includes tools A and C. This embodiment, based on the robot type associated with the target task type, accurately selects a subset relevant to the current task from hundreds or thousands of general tools. This not only significantly reduces the number of tokens input to the large model, lowering costs, but also prevents the model from becoming confused with irrelevant tools, significantly improving the accuracy and response speed of tool selection.

[0071] In an exemplary embodiment, after calling the target MCP tool in the target MCP toolset to drive the corresponding robot to perform the task in step 210, the method may further include: monitoring the robot's real-time position during task execution and implementing traffic control based on the real-time position. The traffic control is used to manage the robot's passage within a preset mutually exclusive zone.

[0072] In this embodiment, a mutual exclusion zone mechanism is introduced to address the potential problem of AMR robots blocking each other in narrow roads in real-world scenarios. The mutual exclusion zone is a polygonal area used to control the robot's access rights within a specific area.

[0073] For example, the mutual exclusion zone includes a general mutual exclusion zone and a dedicated mutual exclusion zone. The general mutual exclusion zone is located in narrow road areas and is generally only allowed to be occupied by one robot at a time. However, to improve traffic efficiency, robots traveling in the same direction are allowed to follow. When a general mutual exclusion zone is occupied, all robots except those traveling in the same direction will wait in the mutual exclusion zone for an extended period.

[0074] Exclusive, mutually exclusive zones are set up in scenarios where robots frequently need to adjust their posture, such as loading and unloading areas. Once an exclusive, mutually exclusive zone is occupied, no other robot, including those traveling in the same direction, is allowed to enter. Exclusive, mutually exclusive zones ensure that only one robot is in the area at a time when it needs to adjust its position to pick up or unload goods, thus avoiding mutual interference.

[0075] In this embodiment, the location range and polygon boundaries of the mutual exclusion zone can be predefined through the map configuration interface. Each mutual exclusion zone is configured with a unique mutual exclusion zone ID, type identifier (normal / exclusive), and lock identifier (unlocked / locked). Unlocked indicates that there is no robot passing through the mutual exclusion zone, while locked indicates that there is a robot passing through the mutual exclusion zone.

[0076] In one exemplary embodiment, such as Figure 4 As shown, monitoring the robot's real-time location during task execution and implementing traffic control based on that location can specifically include: Step 402: Obtain the area range in which the robot performs the task, and determine at least one mutually exclusive region and its corresponding location range based on the area range.

[0077] Here, the region range represents the working area corresponding to the robot's task execution. Since the location range of the mutual exclusion zone is predefined, the agent can determine at least one mutual exclusion zone and its corresponding location range within that region range based on the region range in which the robot performs the task.

[0078] Step 404: Monitor the robot's real-time position during the task execution process.

[0079] In this embodiment, the scheduling agent can monitor the real-time position of each robot during the task execution process through the robot's built-in positioning module (such as LiDAR SLAM positioning, UWB positioning, etc.).

[0080] Step 406: If the distance between the robot's real-time position and any mutual exclusion zone is less than a set distance threshold, obtain the type and lock identifier of any mutual exclusion zone.

[0081] In this embodiment, when the distance between the robot's real-time position and any mutual exclusion zone is less than a set distance threshold (e.g., 5 meters), the scheduling agent obtains the type and lock identifier of any mutual exclusion zone and triggers the following passage condition judgment logic.

[0082] Understandably, to reduce invalid judgments, the passage condition judgment logic can be triggered only for mutually exclusive zones that the robot must pass through on its travel path during task execution. Then, when the distance between the robot's real-time position and the nearest mutually exclusive zone on its travel path is less than a set distance threshold (e.g., 5 meters), the scheduling agent obtains the type and lock identifier of the mutually exclusive zone and triggers the following passage condition judgment logic.

[0083] Step 408: Determine whether the robot meets the passage conditions based on the type and lock identifier of any mutually exclusive zone.

[0084] Step 410: Allow the robot to pass through either of the mutually exclusive zones normally.

[0085] Specifically, when it is determined that the robot meets the passage conditions, the robot is allowed to pass through any mutually exclusive zone normally.

[0086] Step 412: Control the robot to wait outside any of the mutually exclusive zones.

[0087] Specifically, when it is determined that the robot does not meet the passage conditions, the robot is controlled to wait outside any mutually exclusive zone.

[0088] For example, if it is determined that the lock is unlocked (i.e., there is no robot passing through the mutual exclusion zone), and the type of any mutual exclusion zone is a normal mutual exclusion zone, it is determined that the robot meets the passage conditions for any mutual exclusion zone, allowing it to pass through the mutual exclusion zone normally, and the lock of the mutual exclusion zone is set to locked, while the ID and direction of travel of the currently locked robot are recorded.

[0089] In one scenario, if it is determined that the lock is locked, the type of any mutex is a normal mutex, and the robot's travel direction is the same as the currently locked robot, then the robot meets the passage conditions for that mutex. It is then allowed to pass through the mutex normally, even though there are multiple robots traveling in the same direction within that mutex.

[0090] In one scenario, if it is determined that the lock is unlocked, the type of any mutex is an exclusive mutex, and there are no other queuing robots, and the robot meets the passage conditions for any mutex, then it is allowed to pass through the mutex normally. The lock is then set to locked, and the ID of the currently locking robot is recorded.

[0091] In one scenario, if it is determined that the lock is locked, any mutex is a regular mutex, and the robot's direction of travel is opposite to that of the currently locked robot (e.g., in the opposite direction), then the robot does not meet the passage conditions for any mutex, and is controlled to wait outside that mutex. For example, the robot can be added to a queue and wait to pass according to its arrival time.

[0092] In one scenario, if it is determined that the lock is locked and the type of any mutex is an exclusive mutex, it is determined that the robot does not meet the passage conditions for any mutex, so the robot is added to the queue and waits according to the arrival time.

[0093] In one scenario, if it is determined that the lock is unlocked, the type of any mutex is an exclusive mutex, and there are other queuing robots, it is determined that the robot does not meet the passage conditions for any mutex, and the robot is added to the queuing queue and waits according to the arrival time.

[0094] In the above embodiments, queuing through a queue can ensure the fairness of the queuing mechanism and prevent robots that arrive later from cutting in line and entering first.

[0095] In one exemplary embodiment, once the robot has completely left the mutex, the scheduling agent can reset the lock flag of the mutex to unlocked. For ordinary mutexes, if there are still other robots traveling in the same direction within the mutex, the mutex remains occupied, and the ID of the currently locked robot is updated to the ID of the robot closest to the exit of the mutex, until the last robot traveling in the same direction leaves and the lock flag of the mutex is released, i.e., the lock flag is updated to unlocked.

[0096] For a mutually exclusive zone, when the lock flag is released to unlocked, the scheduling agent checks the queue. If there are waiting robots in the queue, the robot at the top of the queue is removed from the queue according to its arrival order, allowing it to enter the mutually exclusive zone, and the lock flag is reset to locked.

[0097] In an exemplary embodiment, if it is determined that a robot malfunctions or abnormally stops in any mutual exclusion zone for more than a preset time (such as twice the time required for normal passage through the mutual exclusion zone), the lock icon of the mutual exclusion zone is forcibly released and an abnormal alarm is triggered to remind staff to check and handle the situation.

[0098] The aforementioned tiered traffic control strategy (general mutually exclusive zones and exclusive mutually exclusive zones) balances safety and efficiency. Allowing same-direction following in narrow sections avoids unnecessary waiting and improves road traffic efficiency; implementing strict exclusivity in critical work areas fundamentally eliminates the risk of collisions. This refined management approach makes collaborative operations of robot swarms smoother and safer in complex and dynamic environments.

[0099] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0100] Based on the same inventive concept, this application also provides an AMR robot scheduling device for implementing the AMR robot scheduling method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more AMR robot scheduling device embodiments provided below can be found in the limitations of the AMR robot scheduling method described above, and will not be repeated here.

[0101] In one exemplary embodiment, such as Figure 5 As shown, an AMR robot scheduling device is provided. This device is applied to a scheduling agent and includes: a task acquisition module 502, a target task determination module 504, a target tool determination module 506, a task plan generation module 508, and a task execution module 510, wherein: The task acquisition module 502 is used to acquire task instructions issued in natural language, the task instructions including a brief description of the task content and the type of robot required for the task. The target task determination module 504 is used to match the task instruction with the task description information of multiple predefined task types using a large language model, and determine the target task type to which the task instruction belongs, wherein each task type is associated with at least one robot type. The target tool determination module 506 is used to filter out target MCP tools that match the robot type required by the target task type from a preset Model Context Protocol (MCP) toolset, thereby obtaining a target MCP toolset. The task plan generation module 508 is used to call the large language model to generate a task execution plan based on the task description, execution steps and execution instructions of the target task type. The task execution module 510 is used to call the target MCP tool in the target MCP tool set to drive the corresponding robot to perform the task based on the task execution plan, and to record and read the status of the task execution plan through the task plan read and write tool during the task execution process until the task in the task execution plan is completed.

[0102] In an exemplary embodiment, each MCP tool in the MCP toolset is configured with tool metadata, which identifies one or more robot types that the MCP tool is adapted to; the target tool determination module is further configured to: obtain a first robot type list associated with the target task type; traverse the tool metadata of each MCP tool in the MCP toolset to determine a second robot type list that the MCP tool is adapted to; and if it is determined that the first robot type list and the second robot type list have an intersection, determine the MCP tool corresponding to the intersection as the target MCP tool.

[0103] In an exemplary embodiment, the device further includes a traffic control module, which is used to monitor the real-time position of the robot during the task execution process after calling the target MCP tool in the target MCP toolset to drive the corresponding robot to perform the task, and to perform traffic control based on the real-time position. The traffic control is used to manage the passage of the robot within a preset mutually exclusive zone.

[0104] In one exemplary embodiment, the mutual exclusion zone includes a general mutual exclusion zone and a dedicated mutual exclusion zone; the general mutual exclusion zone is located in a narrow road area, and when the general mutual exclusion zone is occupied, robots traveling in the same direction are allowed to enter; the dedicated mutual exclusion zone is located in the loading and unloading area, and when the dedicated mutual exclusion zone is occupied, other robots are not allowed to enter.

[0105] In an exemplary embodiment, the traffic control module is further configured to: acquire the area range in which the robot performs its task; determine at least one mutually exclusive zone and its corresponding location range based on the area range; monitor the real-time location of the robot during task execution; if the distance between the robot's real-time location and any mutually exclusive zone is less than a set distance threshold, acquire the type and lock identifier of any mutually exclusive zone; if the lock identifier is unlocked and the type of any mutually exclusive zone is a normal mutually exclusive zone, determine that the robot meets the passage conditions for any mutually exclusive zone; if the lock identifier is locked, the type of any mutually exclusive zone is a normal mutually exclusive zone, and the robot's travel direction is the same as that of the currently locked robot, determine that the robot meets the passage conditions for any mutually exclusive zone; if the lock identifier is unlocked, the type of any mutually exclusive zone is an exclusive mutually exclusive zone, and there are no other queuing robots, determine that the robot meets the passage conditions for any mutually exclusive zone; and allow the robot that meets the passage conditions to pass normally through the mutually exclusive zone.

[0106] In an exemplary embodiment, the traffic control module is further configured to: determine that the robot does not meet the passage conditions for any of the mutually exclusive zones when it is determined that the lock identifier is locked, the type of any mutually exclusive zone is a normal mutually exclusive zone, and the robot's travel direction is not the same as that of the currently locked robot; control the robot to wait outside any of the mutually exclusive zones when it is determined that the lock identifier is locked, the type of any mutually exclusive zone is an exclusive mutually exclusive zone; add the robot to the queuing queue and wait according to the arrival time order when it is determined that the lock identifier is unlocked, the type of any mutually exclusive zone is an exclusive mutually exclusive zone, and there are other queuing robots; determine that the robot does not meet the passage conditions for any of the mutually exclusive zones; add the robot to the queuing queue and wait according to the arrival time order when it is determined that the lock identifier is unlocked, the type of any mutually exclusive zone is an exclusive mutually exclusive zone, and there are other queuing robots; add the robot to the queuing queue and wait according to the arrival time order.

[0107] In an exemplary embodiment, the task execution plan includes at least one subtask, and the task plan read / write tool includes a read plan tool and a write plan tool. The task execution module is further configured to: call the write plan tool to write the subtasks and initial states in the task execution plan into memory, wherein the initial state is a pending state; before executing each subtask, call the read plan tool to read the subtask to be executed and its corresponding state from the memory; during the execution of the subtask to be executed, update the state of the corresponding subtask to the in-progress state; after the execution of the subtask to be executed is completed, update the state of the corresponding subtask to the completed state, and synchronously update the state of the subtask to memory through the write plan tool.

[0108] The modules in the aforementioned AMR robot scheduling device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0109] Based on the same inventive concept, this application also provides an AI-based unmanned robot assisted scheduling system. The solution provided by this system is similar to the solution described in the above method; therefore, the specific limitations of one or more AMR robot scheduling system embodiments provided below can be found in the limitations of the AMR robot scheduling method described above, and will not be repeated here.

[0110] This system is deployed within a scheduling agent and employs the MCP (Multi-Channel Programming) architecture to achieve standardized interaction between a large language model and various robots. The overall system architecture includes a user interaction layer, a task classification layer, a tool filtering layer, an agent execution layer, a traffic control layer, and a robot MCP tool layer.

[0111] The system consists of several layers: the user interaction layer receives task instructions from users in natural language; the task classification layer uses a large language model to semantically understand the task instructions and match them to predefined task types; the tool filtering layer dynamically selects target MCP tools from the MCP toolkit based on the robot type associated with the task type; the agent execution layer calls the large language model to generate a task execution plan and drives the corresponding robot to execute the task through the target MCP tool; the traffic control layer monitors the real-time location of the robot and implements traffic control through a mutual exclusion mechanism; and the robot MCP tool layer encapsulates the specific skills of various robots and exposes callable interfaces to the agent through a standardized MCP protocol.

[0112] In one exemplary embodiment, a scheduling device is provided, the internal structure of which can be shown in the following diagram. Figure 6 As shown, the scheduling device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements an AMR robot scheduling method. The display unit of the scheduling device forms a visually visible image and can be a display screen, projection device, or virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the scheduling device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the scheduling device, or external keyboards, touchpads, or mice, etc.

[0113] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the solution of this application and does not constitute a limitation on the scheduling device to which the solution of this application is applied. The specific scheduling device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0114] In one exemplary embodiment, a scheduling device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0115] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0116] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0117] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0118] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0119] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0120] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for scheduling AMR robots, characterized in that, The method is applied to a scheduling agent, and the method includes: Obtain task instructions issued in natural language, the task instructions including a brief description of the task content and the type of robot required for the task; The task instruction is matched with the task description information of multiple predefined task types using a large language model to determine the target task type to which the task instruction belongs. Each task type is associated with at least one robot type. From the preset Model Context Protocol (MCP) toolset, target MCP tools that match the robot type required for the target task type are selected to obtain the target MCP toolset; Based on the task description, execution steps, and execution guidelines of the target task type, the large language model is invoked to generate a task execution plan; Based on the task execution plan, the target MCP tool in the target MCP tool set is invoked to drive the corresponding robot to execute the task. During the task execution process, the status of the task execution plan is recorded and read through the task plan read / write tool until the task in the task execution plan is completed.

2. The method according to claim 1, characterized in that, Each MCP tool in the MCP toolset is configured with tool metadata, which identifies one or more robot types that the MCP tool is adapted to. The step of selecting target MCP tools from a preset Model Context Protocol (MCP) toolset that match the robot type required for the target task type includes: Obtain the first list of robot types associated with the target task type; Traverse the tool metadata of each MCP tool in the MCP toolset to determine the list of second robot types that the MCP tool is compatible with; If it is determined that there is an intersection between the first robot type list and the second robot type list, the MCP tool corresponding to the intersection is determined as the target MCP tool.

3. The method according to claim 1, characterized in that, After invoking the target MCP tool in the target MCP toolset to drive the corresponding robot to perform the task, the method further includes: The robot's real-time location is monitored during task execution, and traffic control is implemented based on the real-time location. The traffic control is used to manage the robot's passage within a preset mutually exclusive zone.

4. The method according to claim 3, characterized in that, The mutual exclusion area includes ordinary mutual exclusion areas and exclusive mutual exclusion areas; The ordinary mutual exclusion zone is set in a narrow road area. When the ordinary mutual exclusion zone is occupied, robots traveling in the same direction are allowed to enter. The exclusive mutual exclusion zone is set in the loading and unloading area. When the exclusive mutual exclusion zone is occupied, other robots are not allowed to enter.

5. The method according to claim 4, characterized in that, The monitoring of the robot's real-time location during task execution and the implementation of traffic control based on the real-time location include: Obtain the area range in which the robot performs its tasks, and determine at least one mutually exclusive region and its corresponding location range based on the area range; Monitor the robot's real-time position during task execution; If the distance between the robot's real-time position and any mutual exclusion zone is determined to be less than a set distance threshold, the type and lock identifier of any mutual exclusion zone are obtained. If it is determined that the lock is unlocked and the type of any mutex is a normal mutex, then the robot satisfies the passage condition for any mutex. If it is determined that the lock is locked, the type of any mutual exclusion zone is a normal mutual exclusion zone, and the robot's travel direction is the same as that of the currently locked robot, then it is determined that the robot meets the passage conditions for any mutual exclusion zone. If it is determined that the lock is unlocked, the type of any mutual exclusion zone is an exclusive mutual exclusion zone, and there are no other queuing robots, then the robot is determined to meet the passage conditions for any mutual exclusion zone. The robot that meets the passage conditions is allowed to pass normally through any of the mutually exclusive zones.

6. The method according to claim 5, characterized in that, The method further includes: If it is determined that the lock is locked, the type of any mutual exclusion zone is a normal mutual exclusion zone, and the robot's travel direction is different from that of the currently locked robot, it is determined that the robot does not meet the passage conditions for any mutual exclusion zone, and the robot is controlled to wait outside any mutual exclusion zone. If it is determined that the lock is locked and the type of any mutex is an exclusive mutex, then if it is determined that the robot does not meet the passage conditions for any mutex, the robot is added to the queuing queue and waits according to the arrival time. If it is determined that the lock is unlocked, the type of any mutex is exclusive mutex, and there are other queuing robots, then it is determined that the robot does not meet the passage conditions for any mutex, and the robot is added to the queuing queue and waits according to the arrival time.

7. The method according to any one of claims 1 to 6, characterized in that, The task execution plan includes at least one subtask, and the task plan read / write tool includes a plan read tool and a plan write tool; The process of recording and reading the status of the task execution plan using a task plan read / write tool during task execution includes: The task execution plan subtasks and initial states in the task execution plan are written into memory by the writing plan tool, wherein the initial state is a pending state. Before executing each subtask, the read plan tool is invoked to read the subtask to be executed and its corresponding status from the memory; During the execution of the subtask to be executed, the status of the corresponding subtask is updated to "in progress"; after the execution of the subtask to be executed is completed, the status of the corresponding subtask is updated to "completed", and the status of the subtask is synchronously updated to memory through the write plan tool.

8. An AMR robot scheduling device, characterized in that, The device is used in a scheduling agent, and the device includes: The task acquisition module is used to acquire task instructions issued in natural language, which include a brief description of the task content and the type of robot required for the task. The target task determination module is used to match the task instruction with the task description information of multiple predefined task types using a large language model, and determine the target task type to which the task instruction belongs. Each task type is associated with at least one robot type. The target tool determination module is used to filter out target MCP tools that match the robot type required by the target task type from a preset Model Context Protocol (MCP) toolset, thereby obtaining a target MCP toolset. The task plan generation module is used to generate a task execution plan by calling the large language model based on the task description, execution steps and execution instructions of the target task type. The task execution module is used to call the target MCP tools in the target MCP toolset to drive the corresponding robot to perform tasks based on the task execution plan, and to record and read the status of the task execution plan through the task plan read and write tool during the task execution process until the task execution in the task execution plan is completed.

9. A scheduling device, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images