Method of scheduling a robot to perform a task

Abstract

The application is suitable for the field of computer technology, and particularly relates to a method for scheduling robots to perform tasks, which comprises the following steps: in response to a user instruction for indicating a target task, generating a task sequence of at least one subtask corresponding to the target task; assigning a robot capable of performing each subtask to each subtask to obtain a robot scheduling strategy; controlling the robot corresponding to each subtask to perform the corresponding subtask; in the case that an abnormal working state of a first robot is detected, determining a first target subtask from the task sequence; and updating the robot scheduling strategy according to the first target subtask to obtain an updated robot scheduling strategy. Through the decoupled task planning and resource scheduling architecture, the target task can be dynamically decomposed and intelligently assigned to a heterogeneous robot group, optimization is realized in the aspects of dynamic fault tolerance and precise collaborative control, and the work efficiency, robustness and automation level of the multi-robot system in a complex scene are comprehensively improved.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a method, apparatus, equipment, medium, and product for scheduling robots to perform tasks. Background Technology

[0002] With the rapid development of intelligent manufacturing, smart logistics and other fields, the types and numbers of robots deployed in operational scenarios have increased significantly. Different types of robots typically differ significantly in their functional expertise, load capacity, mobility, and operational accuracy, forming a heterogeneous robot group.

[0003] Against this backdrop, how to efficiently coordinate and schedule heterogeneous robot groups to complete complex combined tasks and improve overall operational efficiency is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and product for scheduling robots to perform tasks. It can dynamically decompose and intelligently allocate target tasks to heterogeneous robot groups through a decoupled task planning and resource scheduling architecture, and optimize both dynamic fault tolerance and precise collaborative control, thereby comprehensively improving the operating efficiency, robustness, and automation level of multi-robot systems in complex scenarios.

[0005] In a first aspect, embodiments of this application provide a method for scheduling a robot to perform a task, the method comprising: In response to a user instruction indicating a target task, a task sequence of at least one subtask corresponding to the target task is generated; Based on the capability information of multiple candidate robots, at least one robot capable of performing the subtask is assigned to each subtask from among the multiple candidate robots, thus obtaining the robot scheduling strategy corresponding to the task sequence; According to the robot scheduling strategy, control the robot corresponding to each subtask to execute the corresponding subtask; If an abnormal working state of a first robot is detected, a first target subtask is determined from the task sequence. The first target subtask includes at least one of the following: a main subtask performed by the first robot and an auxiliary subtask that has a dependency relationship with the main subtask performed by the first robot. The robot scheduling strategy is updated based on the first objective sub-task, resulting in the updated robot scheduling strategy.

[0006] The first aspect of the beneficial effects is as follows: Effective decoupling of task planning and resource scheduling. By intelligently parsing and constructing a sequence of multiple sub-tasks with logical order and dependencies from comprehensive user-issued target tasks, complex workflows are modularized into clear and independent execution units. This decomposition process eliminates the dependence of high-level task planning on the real-time status of specific robots, thereby improving the system's design flexibility and maintainability. Based on this, the system can dynamically match the most suitable robot from a heterogeneous robot pool according to the execution conditions of each sub-task, thus generating an executable overall scheduling strategy. This decoupled architecture not only effectively solves the problem of optimal task and resource allocation in heterogeneous multi-robot systems but also enables the system to adapt to dynamically changing environments and resource conditions, significantly improving the automation level, response speed, and overall efficiency of job planning.

[0007] In one implementation, the robot scheduling strategy is updated based on the first target sub-task to obtain the updated robot scheduling strategy, including: The main subtask executed by the first robot in the robot scheduling strategy was replaced by the second robot, and the second robot's working status was normal. Under the condition of meeting the preset dynamic adjustment, the execution order of auxiliary sub-tasks that have a dependency relationship with the main sub-task executed by the first robot in the robot scheduling strategy is adjusted to obtain the updated robot scheduling strategy. The preset dynamic adjustment condition refers to the fact that the influence range of the first target sub-task causes resource allocation conflict or task timing conflict in the robot scheduling strategy.

[0008] In this implementation, when an anomaly occurs while any robot is performing a task, the system can automatically identify it and replace the task being performed by the abnormal robot with another robot. Because the task sequence and robot scheduling are logically separated, when a robot malfunctions, the system can independently and quickly intervene at the resource allocation layer without backtracking or reconstructing the overall task plan. This local replanning at the resource layer significantly shortens the system's recovery time from anomalies and minimizes interference with other parallel or independent task flows, making dynamic response efficient and precise. Furthermore, based on the aforementioned robot replacement, the system can further intelligently adjust the execution order of subtasks that depend on the first robot according to preset quantitative dynamic adjustment conditions. It can proactively optimize the cascading effects caused by anomalies and resource changes at the task flow level. By reordering subtasks, the system can resolve resource conflicts between newly assigned robots, reconstruct more efficient critical paths to compensate for delays caused by anomalies, or reorganize collaborative processes to meet new physical and temporal constraints. This further improves the overall robustness of the system and the quality of task completion.

[0009] In one implementation, the master-subtask executed by the first robot in the robot scheduling strategy is replaced by the execution of the second robot, including: A second robot is determined from a pool of candidate robots other than the first robot. The second robot is a robot that is not currently executing a subtask but is capable of executing the main subtask corresponding to the first robot. The second robot includes at least one of the following: a robot outside of the robot scheduling strategy; a robot whose task execution order in the task sequence precedes the main subtask corresponding to the first robot; or a robot in the task sequence that has a task to be executed, and there is no timing conflict between the task to be executed and the main subtask corresponding to the first robot.

[0010] In this implementation, for each subtask that needs to be rescheduled, the system performs an intelligent replacement evaluation and selects a replacement robot from a variety of eligible robots to perform the subtask.

[0011] In one implementation, in response to a user instruction indicating a target task, a task sequence of at least one subtask corresponding to the target task is generated, including: A task sequence is generated based on the dependencies between each subtask and other subtasks. The task sequence includes a first subtask, which is any subtask in the task sequence. Subtasks that have dependencies on the first subtask include subtasks that need to utilize the execution results of the first subtask.

[0012] In this implementation, it is clear that the construction process of the task sequence is determined based on the dependencies between subtasks, where the dependency refers to the direct result transfer relationship between subtasks.

[0013] In one implementation, from a pool of candidate robots, based on the capability information of the candidate robots, at least one robot capable of performing the subtask is assigned to each subtask, resulting in a robot scheduling strategy corresponding to the task sequence, including: Acquire capability information from multiple candidate robots; Determine the execution conditions that must be met to execute each subtask; For each subtask, obtain the matching degree between the execution conditions of the subtask and the capability information of multiple candidate robots; The candidate robot with the highest matching degree is selected as the robot to perform the sub-task.

[0014] In this implementation, the task-robot matching process is achieved through refined capability modeling and condition matching. By comprehensively considering the execution conditions of each sub-task and the capability information of each robot, the matching degree is calculated and the best robot is selected, ensuring that the most suitable robot is assigned to each sub-task at the starting point of the task, thereby improving the stability and efficiency of the entire scheduling plan.

[0015] In one implementation, the method further includes: The capability information of each robot is updated based on the execution results of its corresponding sub-tasks.

[0016] In this implementation, the system possesses the ability to continuously learn and optimize. By recording and analyzing the results data of each robot's actual task execution, its capability information model is dynamically updated. This ensures that the system's knowledge base continuously aligns with reality, making subsequent task allocation and capability assessment more accurate and reliable, thus forming a positive cycle of scheduling optimization.

[0017] In one implementation, the task sequence includes a second subtask, which needs to be executed collaboratively by at least two robots. According to the robot scheduling strategy, control the robot corresponding to each subtask to execute the corresponding subtask, including: For the second subtask, control commands are sent to at least two types of robots performing the second subtask. The control commands are used to instruct at least two types of robots to perform the second subtask under the condition of satisfying cooperative constraints. The cooperative constraints are used to constrain at least one of the following: the relative position between at least two types of robots, the relative motion speed between at least two types of robots, the joint movement path between at least two types of robots, and the range of force output by at least two types of robots simultaneously.

[0018] This implementation provides a refined collaborative control mechanism for subtasks requiring multiple robots to complete together. By sending unified control commands to the relevant robots and explicitly defining key constraints such as their relative positions, speeds, paths, or resultant forces during the collaboration process, it ensures that complex collaborative tasks can be executed accurately and safely, solving the problem of coarse-grained collaboration in traditional methods.

[0019] Secondly, embodiments of this application provide an apparatus for scheduling robots to perform tasks, comprising: The task acquisition module is used to generate a task sequence of at least one subtask corresponding to the target task in response to a user instruction indicating the target task; The scheduling module is used to allocate at least one robot capable of performing the subtask from multiple candidate robots based on the capability information of multiple candidate robots, thereby obtaining the robot scheduling strategy corresponding to the task sequence. The scheduling module is also used to control the robot corresponding to each subtask to execute the corresponding subtask according to the robot scheduling strategy; The scheduling module is also used to determine a first target subtask from the task sequence when an abnormal working state of a first robot is detected. The first target subtask includes at least one of the following: a main subtask executed by the first robot and an auxiliary subtask that has a dependency relationship with the main subtask executed by the first robot. The scheduling module is also used to update the robot scheduling strategy based on the target sub-task, and obtain the updated robot scheduling strategy.

[0020] Thirdly, this application also provides an electronic device. The electronic device includes a memory, one or more processors, and a computer program stored in the memory and executable on the processor. The electronic device executes the computer program to implement any of the implementations of the first aspect described above.

[0021] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the method of any of the implementations of the first aspect described above.

[0022] Fifthly, this application also provides a computer program product that, when run on an electronic device, causes the electronic device to execute any of the implementation methods of the first aspect described above.

[0023] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect above, and will not be repeated here. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of this application, 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a structural block diagram of a system for scheduling robots to perform tasks according to an embodiment of this application; Figure 2 This is a schematic diagram of a directed acyclic graph provided in an embodiment of this application; Figure 3 This is a schematic diagram of a scenario where a scheduling robot performs a task, according to an embodiment of this application. Figure 4 This is a flowchart of a method for scheduling a robot to perform a task according to an embodiment of this application; Figure 5 This is a structural block diagram of a device for scheduling robots to perform tasks according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] With the rapid development of intelligent manufacturing, smart logistics and other fields, the types and numbers of robots deployed in operational scenarios have increased significantly. Different types of robots, such as autonomous mobile robots (AMRs), robotic arms, and drones, typically have significant differences in core capabilities such as functional specialization, load capacity, mobility, and operational accuracy, forming heterogeneous robot clusters. In other words, a heterogeneous robot cluster refers to a cluster composed of different types of robots.

[0027] Against this backdrop, how to efficiently coordinate and schedule this heterogeneous group to complete complex combined tasks involving sequential, parallel, and even precise collaboration, thereby maximizing the overall system efficiency and resource utilization, has become a key technical challenge that urgently needs to be addressed.

[0028] Currently, traditional multi-robot task scheduling methods face three main limitations when addressing the aforementioned challenges.

[0029] First, at the modeling and matching level, existing solutions struggle to effectively characterize and utilize the dynamic, fine-grained capabilities of heterogeneous robots. They typically rely on static, pre-defined robot capability models, failing to reflect real-time changes in robot power, workload, skill proficiency, and even environmental adaptability. This results in coarse "capability-task" matching, hindering optimal resource allocation.

[0030] Secondly, at the scheduling optimization level, most solutions employ static or offline global planning. Once a scheduling scheme is generated (often represented as a task sequence or graph), an efficient dynamic adjustment mechanism is lacking. When the system encounters robot malfunctions, task timeouts, sudden environmental obstacles, or the insertion of emergency tasks, it often has to terminate or undergo costly global replanning, resulting in slow response, long interruption times, and poor system robustness.

[0031] Furthermore, at the control execution level, while cloud-based control architectures offer powerful computing capabilities, they inevitably introduce network latency. For multi-robot precision collaborative tasks requiring millisecond-level response times (such as collaborative handling and assembly), this latency leads to delayed control commands, severely impacting collaborative accuracy and operational safety. Although existing research has attempted to utilize large models for natural language task parsing or leverage edge computing to reduce latency, these technologies often exist in isolation, failing to systematically integrate task understanding, dynamic scheduling, and low-latency control. Consequently, they cannot fundamentally solve the overall performance optimization problem of heterogeneous clusters in dynamic and uncertain environments.

[0032] Based on this, embodiments of this application provide a method for scheduling robots to execute tasks, which can solve the above-mentioned problems. This method first understands user intent through a large language model, decoupling complex tasks into multiple subtasks with dependencies. Each subtask is also called an atomic subtask, that is, the smallest indivisible subtask unit. Multiple subtasks together form a task sequence. Simultaneously, relying on a dynamically updated robot capability information database, the real-time capabilities of heterogeneous robots are accurately modeled.

[0033] Through an incremental optimization mechanism, when robot anomalies or subtask failures are detected during task execution, efficient rescheduling is performed only on the subtasks directly affected by the dynamic event in the task sequence and their downstream dependent subtasks, rather than global replanning of the entire task sequence. This achieves dynamic adaptation and rapid recovery of the scheduling scheme with lower computational and time costs.

[0034] A cloud-edge collaborative control architecture is adopted to decouple and coordinate intelligent decision-making and real-time execution. The cloud, as the execution entity and decision-making center of the entire scheduling method, is responsible for task parsing, global resource matching, and macro-level strategy generation. The edge refers to the lightweight computing units deployed on each robot, which can convert control commands obtained from the cloud into specific control operations and actions for the robot to perform tasks. This architecture ensures the global intelligence of scheduling decisions, significantly reduces command latency, and thus meets the stringent requirements of high precision and high real-time performance for complex collaborative tasks.

[0035] Therefore, this solution can systematically improve the overall resource utilization, system operational robustness, and execution level of complex collaborative operations of heterogeneous robot clusters.

[0036] Figure 1 This is a structural block diagram of a system for scheduling robots to perform tasks according to an embodiment of this application. The system 100 is implemented by the cloud and the edge (robot end), including a task understanding and capability modeling layer 110, a scheduling planning and optimization layer 120, and a cloud-edge collaborative execution layer 130.

[0037] The task understanding and capability modeling layer 110 is deployed on a cloud server and includes a task parsing module 111 and a robot capability information database 112.

[0038] The task parsing module 111 is implemented by a pre-trained large language model, which is responsible for receiving and parsing the comprehensive user instructions given by the user in natural language. Through its semantic understanding ability, it intelligently decomposes the complex target task into a set of subtasks with logical dependencies (each subtask is the smallest indivisible task unit), thereby constructing a clear initial task sequence.

[0039] Robot Capability Information Database 112 is a dynamic, heterogeneous digital twin database of robot capabilities. This database not only statically registers the inherent attributes of each robot, such as model, load, and skill interfaces, but also dynamically updates its real-time status and performance evaluation, including battery level, location, workload, and skill proficiency, by continuously receiving robot heartbeat data and historical execution records, forming accurate and up-to-date robot capability information. This design directly addresses the limitations of traditional solutions that rely on static capability models and cannot effectively characterize and utilize the dynamic capabilities of robots.

[0040] The scheduling planning and optimization layer 120 is also deployed on a cloud server and is used to generate and dynamically adjust robot scheduling strategies based on task sequences and robot capability information. The scheduling planning and optimization layer 120 includes a scheduling decision module 121, which generates robot scheduling strategies based on the received task sequences and robot capability information, and dynamically optimizes and adjusts the robot scheduling strategies based on the robot's working status and performance during task execution.

[0041] The scheduling decision module 121 first converts the task sequence into a graphical representation, namely a Directed Acyclic Graph (DAG), based on the dependencies between subtasks. Each node in the DAG represents a subtask. (See reference...) Figure 2 , Figure 2 This is a schematic diagram of a directed acyclic graph provided in an embodiment of this application. In the directed acyclic graph 200, each node represents a subtask, and the arrows between the subtasks represent the dependencies between them. There are nodes representing the first subtask 21 and the second subtask 22 in the graph. The node of the first subtask 21 points to the node of the second subtask 22, indicating that the second subtask 22 depends on the node of the first subtask 21. That is, the second subtask 22 needs to use the execution result of the first subtask 21 to start execution.

[0042] The scheduling decision module 121 then assigns a suitable robot to each node (subtask) in the directed acyclic graph (DAG) by matching the robot's capability information with the execution conditions of each subtask, and estimates its execution time window, thus forming an initial robot scheduling strategy. The core of the scheduling decision module 121 lies in its incremental optimization mechanism: when dynamic events such as robot malfunctions or environmental anomalies are detected, the entire DAG is not reconstructed; instead, the affected nodes and their subsequent dependent nodes are quickly identified, and robots are reassigned only to this local area to update the scheduling strategy. This approach significantly reduces the computational overhead and response time of rescheduling.

[0043] The cloud-edge collaborative execution layer 130 is used to control the robot to execute corresponding sub-tasks according to the robot scheduling strategy. Its architecture reflects the collaboration between the cloud (cloud) and the robot body (edge). This layer includes a cloud instruction distribution module 131 and a reinforcement learning control module 132.

[0044] The cloud-based instruction distribution module 131, acting as the main executor of the entire scheduling method, is responsible for sending the control instructions corresponding to each subtask in the robot scheduling strategy to the robot assigned to execute that subtask. The reinforcement learning control module 132, deployed on each robot (edge), receives control instructions from the cloud and converts them into fine-grained, low-latency control instructions to drive the robot to perform the specific operations and actions required for the task. For subtasks requiring collaboration among multiple robots, the control instructions issued from the cloud contain explicit collaborative constraints; when generating specific actions, the control modules of each robot will jointly adhere to these constraints to achieve precise collaboration. This architecture decouples global scheduling decisions from local real-time control, effectively reducing control latency caused by network transmission while ensuring the globality of the strategy.

[0045] In summary, through the collaborative operation of the task understanding and capability modeling layer 110, the scheduling planning and optimization layer 120, and the cloud-edge collaborative execution layer 130, this system fully realizes a closed loop from task parsing and dynamic scheduling to precise control, ultimately achieving the goal of improving the overall resource utilization rate of heterogeneous robot clusters, system operational robustness, and collaborative operation accuracy.

[0046] Figure 3 This is a schematic diagram of a scenario where a scheduling robot performs a task according to an embodiment of this application, illustrating the use of a cloud-based scheduling robot to perform cargo sorting and transportation tasks in a smart warehousing scenario.

[0047] First, the cloud receives the user's instruction: "Take 3 items A from the third shelf of shelf S12 and put them into the shipping box of workstation W5" (S401).

[0048] The large language model deployed in the cloud parses the instruction, breaks it down into 4 sub-tasks (T1, T2, T3, T4) and clarifies the dependencies: T1 (autonomous mobile robot AMR navigates to S12), T2 (robotic arm grabs product A), T3 (autonomous mobile robot AMR carries the robotic arm to transport product A to W5), T4 (robotic arm places product A), where T2 depends on T1, T3 depends on T2, and T4 depends on T3, forming a task sequence: T1-T2-T3-T4.

[0049] Among them, autonomous mobile robots (AMRs) and robotic arms are different types of robots. AMRs are mainly responsible for autonomous navigation and transportation in space, while robotic arms focus on performing precise operations and grasping on fixed or mobile bases.

[0050] Next, the cloud queries the local robot capability information database, which dynamically stores the skills and real-time status of each robot. Matching is performed based on the requirements of each subtask: T1 and T3 require mobility and are matched to the autonomous mobile robot AMR_001; T2 and T4 require grasping capabilities and are matched to the robotic arm Arm_002. Since T3 requires both robots to complete the task, T3 also needs grasping capabilities and is matched to the robotic arm Arm_002. This generates the initial robot scheduling strategy as follows: T1(Autonomous Mobile Robot AMR_001)→T2(Arm_002)→T3(Autonomous Mobile Robot AMR_001+Arm_002)→T4(Arm_002).

[0051] Subsequently, according to the robot scheduling strategy, the first control command was issued to the autonomous mobile robot AMR_001, initiating execution T1. The autonomous mobile robot AMR_001 began moving towards S12 and continuously reported its status and position information to the cloud.

[0052] During execution, the environmental monitoring camera detected an obstacle on the predetermined path of the autonomous mobile robot AMR_001 and reported this "path blockage" event to the cloud. The cloud determined that this event caused an abnormal working state of the autonomous mobile robot AMR_001. The system immediately performed incremental optimization: it locked the affected subtask range, namely T1 and all its downstream tasks (T2, T3, T4). The system re-queried the robot capability information database and found that another idle autonomous mobile robot, AMR_002, although located further away, calculated that its total time to complete T1 and T3 (12 minutes) was shorter than the waiting time for clearing (15 minutes). Therefore, the system generated an updated scheduling strategy: reassigning T1 and T3 to the autonomous mobile robot AMR_002. The cloud then issued new navigation instructions to the autonomous mobile robot AMR_002 and sent a task delay notification to Arm_002.

[0053] After AMR_002 completes T1 and Arm_002 completes T2, the system enters the crucial collaborative transport phase. The cloud simultaneously sends a control command to both AMR_002 and Arm_002: collaboratively transport item A from S12 to W5. Constraints must be met during this collaborative process, including a maximum speed of 0.5 m / s and a relative pose tolerance of ±5 cm. Upon receiving this command, AMR_002's local reinforcement learning controller, combined with real-time environmental data collected by its LiDAR, autonomously generates a smooth movement path and speed command. Arm_002's local reinforcement learning controller also receives this command and, based on the box sway sensed by its wrist force sensor, adjusts its joint torque in real-time to maintain stability. Through physical connection and shared policy objectives, the two achieve low-latency compliant transport without direct communication until the task is completed.

[0054] Figure 4 This is a flowchart of a method for scheduling a robot to perform a task according to an embodiment of this application. The method includes the following steps.

[0055] S401, in response to a user instruction for indicating a target task, generates a task sequence of at least one subtask corresponding to the target task.

[0056] First, obtain user instructions. These user instructions are used to direct the target task.

[0057] Specifically, users can issue complex user commands in natural language through the cloud platform to instruct the target tasks that the user expects the robot to perform.

[0058] For example, users can directly input user commands through a command input interface provided by the cloud, or users can input user commands through a mobile terminal that corresponds to the cloud and can send user commands to the cloud.

[0059] For example, if the user instruction is "to take inventory of the shelves in warehouse area A and generate a discrepancy report", after the user instruction is received by the cloud, the cloud will perform intent recognition on the user instruction and understand that the user needs to perform inventory operations and generate a report.

[0060] In response to user commands, a task sequence of multiple subtasks corresponding to the target task is generated.

[0061] The generation of task sequences is mainly accomplished by a Large Language Model (LLM) deployed in the cloud. The trained model decomposes complex tasks into a series of indivisible atomic operations based on the robot scheduling domain knowledge it has learned.

[0062] For example, the above objective task can be broken down into the following sub-tasks: Sub-task 1: "Navigate to shelf 1 in area A"; Sub-task 2: "Scan the barcode of the goods on shelf 1"; Sub-task 3: "Compare the scan results with the inventory database"; Sub-task 4: "Generate the difference data of shelf 1"; Sub-task 5: "Move to the next shelf", etc.

[0063] During the decomposition process, the system performs semantic annotation on each subtask to clarify the execution conditions required to execute the subtask, including at least one of the following: the type of robot resources required to execute the subtask (such as mobile robot, robotic arm), the type of robot skills (such as navigation, visual recognition), the expected time to complete each subtask, the time interval between adjacent subtasks, the priority of subtask execution, and the logical dependencies between tasks (such as sequential or parallel execution).

[0064] Optionally, a task sequence is generated based on the dependencies between each subtask and other subtasks, wherein the task sequence includes a first subtask, which is any subtask in the task sequence, and subtasks that have dependencies on the first subtask include subtasks that need to utilize the execution result of the first subtask.

[0065] Analyzing the logical dependencies between subtasks and sorting them according to their identifiers, since each subsequent subtask depends on the result of the previous subtask (i.e., subtask 2 depends on subtask 1, subtask 3 depends on subtask 2, subtask 4 depends on subtask 3, and subtask 5 depends on subtask 4), the task sequence is determined as follows: Subtask 1 - Subtask 2 - Subtask 3 - Subtask 4 - Subtask 5.

[0066] In the above example, the result of each subtask affects the execution of the next subtask, and each subtask is executed strictly according to a preset timing sequence. However, in some embodiments, some subtasks need to be executed in parallel, or some subtasks can be executed independently without affecting each other. In this case, the dependency relationship in the task sequence is different from the dependency relationship in the above example.

[0067] To more intuitively explain the logic between subtasks in a task sequence, a directed acyclic graph (DAG) is typically generated based on the decomposed subtasks and their logical dependencies. This DAG uses nodes to represent subtasks and arrows to represent dependencies, visually describing a structured task sequence. In a DAG, each node represents a subtask, and the arrows indicate the direction of dependency between tasks. If an arrow points from subtask A to subtask B, it means that the completion of subtask A is a prerequisite for the start of subtask B. A DAG can be a linear structure or contain branching, parallel, or independent subtask structures. This representation helps to clearly show the execution paths and conditional dependencies of subtasks in complex tasks, thus supporting more flexible and efficient task scheduling and process management.

[0068] S402, based on the capability information of multiple candidate robots, assign at least one robot capable of performing the sub-task to each sub-task from multiple candidate robots, and obtain the robot scheduling strategy corresponding to the task sequence.

[0069] The system locally stores a robot information capability database, which is a dynamically updated heterogeneous robot capability digital twin database containing capability information of various candidate robots.

[0070] The construction of the robot's information capability database begins with static capability registration: whenever a robot (e.g., an Automated Guided Vehicle (AGV), robotic arm, or drone) joins the system, it must submit a structured capability configuration file (such as JSON or XML format) to the cloud. This file details the robot's basic type, physical parameters (load, size, speed), end effector type (gripper, suction cup, camera, etc.), and its external software skill API interfaces (e.g., / api / navigate_to_point for navigation, / api / scan_barcode for scanning). This information constitutes the robot's initial "capability profile" within the system.

[0071] For example, when an Automated Guided Vehicle (AGV) goes online, it registers its capability information with the system, including: (1) Physical parameters: Rated load capacity: 1000 kg; Maximum moving speed: 1.0 m / s. (2) Navigation method: Magnetic line navigation. (3) Software skill API interface: / api / follow_path: travels along a preset path to a designated station; / api / stop_at_station: stops precisely at a designated station.

[0072] Optionally, a local robot capability information database stores capability information of multiple candidate robots, and capability information of multiple candidate robots is retrieved from the database.

[0073] The step of determining the execution conditions required to execute each subtask is automatically completed when the user instruction is broken down into the smallest unit of subtasks. For example, in step S402, when the large language model decomposes the target task into the subtask of "scanning the shelf barcode", its semantic annotation has automatically generated the execution conditions: a robot with visual recognition capabilities and the ability to reach the shelf is required.

[0074] For each subtask, obtain the matching degree between the execution conditions of the subtask and the capability information of multiple candidate robots; determine the candidate robot with the highest matching degree as the robot to execute the subtask.

[0075] For example, the system uses a pre-defined weighted scoring algorithm that comprehensively considers various factors such as the robot's static ability to complete the task, its current position, and real-time battery level to calculate a matching score between each sub-task and all candidate robots. The robot with the highest score among the candidate robots is selected as the executor of that sub-task. Based on this allocation, the system further estimates the expected start and end times of each task, thus forming a complete, executable, and initial robot scheduling strategy.

[0076] For example, the execution conditions of each subtask and the capability information of each candidate robot are modeled as feature vectors. The similarity between the feature vectors of the execution conditions and the feature vectors of the capability information is calculated. A first score is obtained based on the first similarity. A second score is obtained by combining multiple dynamic factors (such as the robot's current position and real-time battery level). The first score and the second score are weighted and comprehensively scored. The weighted total score is used as the matching degree. The robot with the highest matching degree is selected for the subtask.

[0077] For example, suppose the subtask is "to perform visual quality inspection on parts boxes located in the east area of ​​the workshop". Its execution conditions can be extracted as a multi-dimensional feature vector. The meanings of each dimension of the feature vector are as follows: {task type: inspection, required skills: visual photography and image analysis, work area: east area of ​​the workshop, accuracy requirement: high}.

[0078] Among them, the capability information database stores the capability information of two candidate robots (robot CamBot_1 and robot CamBot_2), and the features are extracted from them: (1) The feature vector of the capability information of robot CamBot_1 is {type: fixed industrial camera, skills: high-definition photography, defect recognition, deployment location: east area of ​​workshop, nominal accuracy: 69.9%}; its real-time status is: {current working status: idle, network latency: low}. (2) Robot CamBot_2: The feature vector of the capability information is {type: mobile inspection robot, skills: navigation, photography, deployment location: west area of ​​workshop, nominal accuracy: 69.5%}; its real-time status is: {current working status: idle, current location: west area of ​​workshop (200 meters from the east area), real-time battery level: 80%}.

[0079] The first score is determined by calculating the cosine similarity: the similarity between the subtask feature vector and the feature vector of each robot's capability is calculated, assuming that CamBot_1 gets the first score of 95 points; assuming that CamBot_2 gets the first score of 70 points.

[0080] Calculate the second score: CamBot_1 has been deployed at the target location and does not need to move. The network condition is good, so the dynamic evaluation assumption score is 100 points; CamBot_2 needs to move 200 meters from its current location to the target location, and its battery is not full. Moving will take time and consume power, so the dynamic evaluation assumption score is 60 points.

[0081] Weighted summation: Assuming the first score has a weight of 60% and the second score has a weight of 40%, then: the total matching degree between CamBot_1 and the subtask = 95 * 60% + 100 * 40% = 97 points; the total matching degree between CamBot_2 and the subtask = 70 * 60% + 60 * 40% = 66 points.

[0082] Therefore, the matching score of robot CamBot_1 (97 points) is higher than that of CamBot_2 (66 points), and robot CamBot_1 is selected as the executor of this sub-task. Based on this, the system combines its workflow with time estimation (including the start time of the task, the duration of the execution process, and the end time of the task) to complete the precise scheduling of this sub-task.

[0083] In some embodiments, the system has a mechanism for dynamically updating robot capability information.

[0084] Optionally, for each robot, the robot's capability information is updated based on the execution results of its corresponding sub-tasks, involving the following two aspects: real-time status monitoring and historical performance learning.

[0085] First, each robot periodically reports its key operational status to the cloud via a pre-set heartbeat mechanism. The reported data includes at least: remaining battery power, real-time location based on fusion localization, current task status (e.g., idle, running, faulty), and the load status of the computing unit. This real-time data forms the dynamic basis for scheduling decisions.

[0086] Secondly, the system continuously optimizes its capability assessment model by analyzing historical task execution data of the robots. The system aggregates and analyzes task records for each robot, including success rate, average time, and performance in specific scenarios. For example, in ambient light conditions below 300 lux, the visual positioning success rate of a certain model of collaborative robotic arm drops from the nominal 69.2% to approximately 94.5%. These statistically validated performance characteristics are transformed into conditional capability indicators and dynamically updated in the robot's capability profile.

[0087] Through the above mechanism, the robot's capability information can evolve from static parameters into a continuously improving dynamic profile, thereby providing a more accurate and reliable matching basis for subsequent task scheduling.

[0088] S403 controls the robot corresponding to each subtask to execute the corresponding subtask according to the robot scheduling strategy.

[0089] The core of this step lies in the collaborative execution architecture between the cloud and the robot's edge. The cloud is not responsible for generating the low-level motion control sequences, but rather for translating scheduling strategies into high-level operational instructions and issuing them. The robot, or its connected edge computing unit, acts as the receiver and executor of these instructions, and is responsible for autonomously generating and executing fine-grained low-level control signals based on these high-level instructions.

[0090] Specifically, the cloud encapsulates macro-level strategies into a standardized task description language, such as AML (Automation Markup Language) fragments based on JSON format, and distributes them to designated robots. This description language includes task objectives and execution constraints. Task objectives define the final state to be achieved, such as "move the specified workpiece from position A to position B". Execution constraints limit the boundary conditions in achieving the objective, such as the maximum allowable gripping force of the robotic arm and the obstacle avoidance safety distance of the mobile platform.

[0091] After the task instruction is issued, the lightweight reinforcement learning controller deployed on the robot body immediately starts the real-time control loop. This loop consists of the following three key stages: (1) State perception: The controller collects environmental and robot body state information s_t in real time through integrated sensors.

[0092] (2) Strategy reasoning: Its embedded strategy network π(a_t|s_t) combines the current state s_t with the target and constraints issued by the cloud to calculate the underlying control command a_t at the current moment, such as the target torque of the joint motor or the speed difference of the drive wheel.

[0093] (3) Optimization-driven: The output of the policy network is optimized by an internal reward function r(s_t, a_t). This function is designed to directly encode the intent of cloud-based instructions, such as giving a positive reward for "approaching the task objective" and a negative reward for "deviating from the predetermined path" or "violating physical constraints". Through this mechanism, the local controller can autonomously and in real time generate control instructions without continuous cloud intervention, ensuring that the robot's actions converge towards the global objective efficiently and in compliance with regulations.

[0094] S404, if an abnormal working state of the first robot is detected, determine the first target subtask from the task sequence.

[0095] In some embodiments, the robot's working state may become abnormal during task execution. The abnormality may be caused by internal factors, such as hardware or software failure of the robot itself; or by external factors, such as unforeseen obstacles in the working environment, or the user issuing temporary instructions to modify, add or cancel the task.

[0096] For example, the first robot is equipped with several sensing sensors for continuously monitoring the robot's status, including but not limited to the following.

[0097] 1. Inertial Measurement Unit: Continuously collects the robot's three-axis acceleration and angular velocity data. When the data deviates from the stationary or uniform motion model for an extended period, or when continuous high-frequency vibrations occur in a specific direction (e.g., wheels jamming causing motors to spin and vibrate), it may indicate that the robot is tipping over, slipping, or that the drive system is malfunctioning.

[0098] 2. Motor Encoder and Temperature Sensor: The motor encoder provides real-time feedback on the actual speed and position of the wheel assembly or joint. A persistent and unavoidable error between the feedback value and the control command (e.g., command to move forward but actual displacement is zero) may indicate motor stall, mechanical jamming, or transmission system failure. Simultaneously, if the temperature sensor reading on the motor or drive controller consistently exceeds the safety threshold, it indicates that the equipment is overheating and a failure is imminent or has already occurred.

[0099] 3. Power Management Unit: Monitors the robot's battery voltage, current, and remaining power. If the voltage drops suddenly under load, or the current spikes abnormally (possibly accompanied by a short circuit), or the power is depleted abnormally and rapidly within the expected time, it indicates a fault in the power system, and the robot may shut down at any time.

[0100] 4. Onboard computing unit self-test: By monitoring heartbeat signals, CPU / memory usage, and key process status, it diagnoses whether the software system has crashed, whether communication has been interrupted, or whether the computing power is overloaded.

[0101] For example, the first robot's operating environment is typically equipped with a variety of external sensors to perceive the global environment and events, including but not limited to the following.

[0102] 1. Global Vision Monitoring System: Wide-angle or panoramic cameras deployed on warehouse or workshop ceilings or key passageways continuously collect video streams. Through image recognition algorithms, it can detect unforeseen obstacles in the environment (such as scattered goods, temporarily parked equipment), unauthorized personnel entering the work area, or congestion or collision risks that may be caused by other robots deviating from their predetermined paths.

[0103] 2. LiDAR or depth sensor array: Fixedly installed at key intersections or workstations to build high-precision dynamic environmental maps. When an object is detected occupying the robot's predetermined path for an extended period (such as a collapsed shelf), or when its scan data shows a significant and continuous difference from the preset static map, the path can be determined to be blocked.

[0104] 3. Task Management System Interface: Receives real-time command changes from upper-level management software or operators. For example, users may temporarily issue commands such as "cancel the current task," "insert an urgent priority task," or "modify the task target point" via a terminal. These commands directly alter the original task execution prerequisites or conditions, constituting a "planned anomaly" triggered by external input.

[0105] Based on the multimodal information collected by the internal and external sensors, it is determined whether the robot's working state is abnormal.

[0106] (1) Internal anomaly determination: When the readings of the above internal sensors continuously and significantly deviate from the numerical range corresponding to the normal operating conditions, and the on-board diagnostic system cannot recover on its own, it is determined that the working state is abnormal due to internal factors. For example, the motor temperature exceeds the red line and continues to rise, or the IMU detects that the robot has overturned.

[0107] (2) External anomaly determination: When the external sensor system detects an obstacle, or negates the environmental changes or instructions of the current task execution plan, even if the internal sensor readings of the robot are normal, it is determined that its working state has become abnormal at the task level. For example, if the global camera finds that the path ahead is completely blocked, it means that the current "navigation" task objective cannot be achieved.

[0108] If, during the execution of a sub-task by the first robot, the combined information from the aforementioned internal and external sensors indicates that the first robot "cannot complete the current task" or "continuing to execute the original task will lead to failure or danger," then an abnormal working state of the first robot is detected.

[0109] This application's embodiments decompose the target task into a sequence of atomic subtasks with logical dependencies, and construct a directed acyclic graph of task execution during the initial scheduling phase. Therefore, when an abnormal event occurs, the system can perform precise problem isolation and local processing at the subtask level. Specifically, the system does not require global rescheduling; it only needs to locate and process those subtasks that are directly or indirectly affected by the abnormal state of the first robot, i.e., the first target subtask.

[0110] Optionally, the first target subtask includes at least one of the following: a main subtask performed by the first robot, and an auxiliary subtask that has a dependency relationship with the main subtask performed by the first robot.

[0111] The main sub-tasks performed by the first robot include the sub-tasks that the first robot is currently performing, as well as the sub-tasks in the task sequence that are planned to be performed by the first sub-task but have not yet started.

[0112] Subtasks that depend on the subtasks performed by the first robot: These are downstream subtasks that use the execution result of the subtasks performed by the first robot as a prerequisite. For example, in a collaborative work chain of "movement → gripping → transporting → placement", if the first robot (responsible for movement and transporting) malfunctions during the "movement" phase, not only will its own "movement" and subsequent "transporting" tasks be unable to be executed, but all downstream subtasks that depend on it to provide the state or result of "moved to position" or "transported to position" (such as the "gripping" or "placement" operation of another robot) will also become the first target subtasks affected.

[0113] For example, in a warehouse replenishment and handling task, the system schedules two robots to work together, and the task sequence is as follows: T1 (AMR-001 picks up the goods from the warehouse door and moves them to the transfer point X); T2 (AMR-002 picks up the goods from the transfer point X and moves them to the target shelf Y) → depends on T1 to complete; T3 (AMR-001 returns to the charging station to charge); T4 (AMR-002 returns to the standby area after completing the handling).

[0114] The dependencies between subtasks are as follows: T2 can only begin after T1 is completed. T3 and T4 are independent subsequent tasks and do not depend on each other.

[0115] For example, AMR-001 is performing task T1 (transferring to transfer point X) when it stops due to a sudden battery failure. The first target subtask affected is determined as follows: (1) Subtasks directly performed by the first robot (AMR-001): T1 (current task, interrupted due to failure) and T3 (subsequent tasks to be performed by it, which cannot start due to robot failure); (2) Subtasks that are dependent on the tasks performed by the first robot: T2 (performed by AMR-002, but its execution is strictly dependent on the completion of T1. Since T1 is interrupted, T2 cannot start, thus becoming the first target subtask). Therefore, the set of first target subtasks is: {T1, T2, T3}.

[0116] Unaffected subtask: T4 (executed by AMR-002, it only depends on the completion of T2, and since T2 has not yet started, T4 is currently not directly affected by this anomaly).

[0117] S405, Update the robot scheduling strategy according to the first target sub-task to obtain the updated robot scheduling strategy.

[0118] When the system detects an abnormal working state of the first robot, it will initiate a dynamic rescheduling mechanism. The core of this mechanism is to reassign all subtasks that were originally assigned to the first robot in the initial robot scheduling strategy to other robots, and to determine whether subtasks that have dependencies on the subtasks corresponding to the first robot need to be rearranged.

[0119] Optionally, if an abnormal working state of the first robot is detected, the master-subtask executed by the first robot in the robot scheduling strategy is replaced by the second robot, and the working state of the second robot is normal.

[0120] A second robot is determined from a pool of candidate robots other than the first robot. The second robot is a robot that is not currently performing a subtask but is capable of performing the subtask corresponding to the first robot.

[0121] The second robot includes at least one of the following: a robot other than the robot scheduling strategy; a robot whose task execution order in the task sequence precedes the sub-task corresponding to the first robot; or a robot in the task sequence with a task to be executed, wherein there is no timing conflict between the task to be executed and the sub-task corresponding to the first robot.

[0122] For example, the task sequence includes subtasks A, B, C, and D, which are executed by robot 1, the first robot, robot 2, and robot 3, respectively. An abnormal event occurs during the execution of B by the first robot.

[0123] 1. Consider condition one (robots outside the scheduling strategy), such as calling a standby robot X that is idle and waiting. It is not assigned to this task sequence and can be put into use as an immediate resource to take over or assist in handling exceptions.

[0124] 2. Consider condition two (the robot with a earlier time sequence), such as robot 1 that has already completed subtask A. Since it is located before the first robot (performing task B) in the task sequence, it is most familiar with the context of task B (such as the workpiece state) and may be the most suitable for initial intervention or state restoration.

[0125] 3. Consider condition three (the existence of robots with no conflicting tasks to be executed), such as robots 2 and 3. Robots 2 and 3 are assigned subsequent tasks C and D, respectively. The time required for robot 2 to travel from its location for task C to its location for task B is 10 minutes. The time interval between the estimated start time of task C and the end time of task B must be within 5 minutes. This indicates a timing conflict between tasks B and C, insufficient to support robot 2 completing task B before task C. The time required for robot 3 to travel from its location for task D to its location for task B is 2 minutes. The time interval between the estimated start time of task D and the end time of task B is 30 minutes. This indicates no timing conflict between tasks B and D, sufficient to support robot 3 completing task B before task C.

[0126] In some embodiments, there are multiple robots that can replace the first robot. The system automatically evaluates the time required for each robot to perform its corresponding sub-task in place of the first robot, and determines the robot with the shortest time as the second robot.

[0127] The system continuously monitors the task execution status through multi-source perception. Its event stream includes internal events actively reported by the robot and external events captured by the environmental perception system.

[0128] When an abnormal event is triggered, the system immediately performs an impact assessment: quickly analyzes the subtasks in the current task sequence that are directly affected by the first robot, thereby forming a set of subtasks to be rescheduled.

[0129] The system performs local replanning for this set of subtasks, rather than regenerating the global scheduling scheme.

[0130] In some embodiments, after an abnormal event occurs to the first robot, in addition to replacing the robots executing all subtasks corresponding to the first robot, it is also necessary to consider whether other subtasks corresponding to the first robot will be affected, causing changes in the execution results of other subtasks. Therefore, based on the dependencies between subtasks, each subtask that has a dependency relationship with the first robot's subtask can be re-analyzed, and if necessary, the subtasks can be re-scheduled and planned to obtain an updated robot scheduling strategy.

[0131] Optionally, if the preset dynamic adjustment conditions are met, the execution order of subtasks that have a dependency relationship with the subtasks executed by the first robot in the robot scheduling strategy can be adjusted to obtain an updated robot scheduling strategy.

[0132] The preset dynamic adjustment conditions refer to the resource allocation conflicts or task timing conflicts that occur in the robot scheduling strategy due to the influence range of the first target sub-task.

[0133] The preset dynamic adjustment conditions include, but are not limited to: (1) Optimal execution subject change condition: The system calculates the score in real time based on the static capability tags in the robot capability digital twin library, the real-time reported location information and battery power data, through the preset weighted capability matching algorithm; if it is found that at least one other available robot has a calculated score for the currently affected first target sub-task that exceeds the score of the original execution robot or the currently temporarily assigned robot by more than the first value (e.g., 20%), it is determined that the optimal execution subject has changed and a reassignment is triggered. (2) Critical path time delay condition: The system estimates the completion time of each sub-task based on the standard working time library of each sub-task in the task sequence (directed acyclic graph), the real-time status of the robot and the path planning results; if after local replanning, the new estimated completion time of the affected task chain causes the earliest completion time of the global task to be delayed by more than the first duration threshold (e.g., 5 minutes) compared with the original plan or deadline, it is determined to be a critical path delay and the task order needs to be optimized and adjusted. (3) Resource conflict condition: The system integrates the reported positions, planned path coordinate sequences and timestamps of all robots, as well as global environmental map information, and runs a path conflict detection algorithm; if it is determined that the expected arrival time difference between the newly planned robot and other robots at the same coordinate point within the future preset time period is less than the second time period threshold (e.g., 3 seconds) and the spatial distance is less than the first preset distance (e.g., 1 meter), then it is determined that there is a collision risk, and the task time window must be adjusted or the path must be replanned. (4) Cluster load imbalance condition: The system calculates the average cluster load based on the task queue length reported by each robot and the global task table maintained by the central scheduler; if it is detected that the number of sub-tasks to be executed by any robot exceeds n times the average value (n is a real number, for example, n is 1.5), then it is determined that the load is unbalanced and triggers load transfer adjustment. (5) Cooperative constraint failure condition: The system calculates the theoretical cooperative error based on the cooperative parameters defined in the sub-task description, the robot's positioning accuracy data and network latency test results; if the error value is greater than the maximum cooperative tolerance allowed by the task after the cooperative task is reassigned, then the cooperative constraint is determined to be invalid, and the task allocation or execution order needs to be adjusted.

[0134] For example, when a robot suddenly malfunctions, the system will only include the subtasks that have not yet started execution, those that are being executed but have been forced to stop, and all subsequent subtasks that logically depend on the results of these tasks in the scope of rematching and sorting; while other subtasks in the task sequence that are not related to these tasks and their scheduling arrangements will remain unchanged.

[0135] After generating a new local scheduling scheme, the system will resolve resource conflicts. For example, it will check whether the preset path of the newly assigned robot will conflict with other sub-tasks being executed in the system in terms of space or time, and resolve the conflict by adjusting the task time window (e.g., adjusting the execution order of sub-tasks) or replanning the local path, thereby ensuring the consistency and feasibility of the updated global scheduling strategy.

[0136] It's important to note that during incremental optimization, the robot scheduling strategy for all identified dependent subtasks is not redesigned. The system makes more refined decisions: for some subtasks, although their execution depends on the results of preceding anomalous tasks, the currently assigned robot type, capabilities, and status can still effectively meet the task requirements. For such subtasks, the system may only need to adaptively adjust their scheduling parameters without changing the executing entity.

[0137] For example, adaptive adjustments include at least one of the following: (1) Time planning adjustment: Based on the delay of the preceding task, recalculate and update the estimated start and end times of the subtask. (2) Execution parameter adjustment: Based on the latest context information, fine-tune the execution parameters of the subtask. For example, if the preceding handling task has a slight deviation in the arrival position due to detour, the subsequent grasping task may need to update the coordinates of its target grasping point. (3) Collaboration interface adjustment: For tasks that require the collaboration of multiple robots, if one of the collaborating partners is replaced or the task sequence changes, the system needs to update the collaboration rules or communication protocols between the robots.

[0138] In a specific application scenario, suppose there is a linear task sequence: first, autonomous mobile robot AMR1 performs material handling; then, robotic arm A performs grasping and assembly; and finally, robotic arm B completes quality inspection. If autonomous mobile robot AMR1, which is performing the first task, experiences a minor malfunction en route, the system will activate an exception handling mechanism to replace it with another robot of the same model, AMR2, to continue the operation. However, this will cause the completion time of this sub-task to be delayed by ten minutes.

[0139] An impact analysis was then conducted, identifying that the two subsequent sub-tasks both depended on the materials provided by the initial handling task, and were therefore marked as affected items requiring adjustment. During the refined rescheduling phase, the system did not simply replace the executing robot for these two tasks. For the grasping and assembly task, the assessment confirmed that the originally designated robotic arm A was still available and in optimal condition. Therefore, the scheduling system kept its execution entity unchanged, only adjusting the timing, postponing the start time of this sub-task by ten minutes, and potentially fine-tuning the grasping target coordinates of robotic arm A based on the specific location of the material ultimately delivered by the alternative robot. Similarly, for the subsequent quality inspection task, given that it was only affected by the delay in the preceding steps and that the execution requirements did not fundamentally change, the system determined that robotic arm B was still the suitable executor, and therefore only its start time was synchronously postponed.

[0140] By making such refined judgments based on task dependencies and resource status, the system ensures the overall continuity of operational logic while significantly reducing system oscillations and coordination costs that may be caused by global rescheduling, thereby achieving more efficient and robust dynamic adaptability.

[0141] During incremental rescheduling, the policy updates of each affected subtask can be processed sequentially according to their original expected start times. In the dependency chain, subtasks with earlier start times have higher deterministic scheduling results, and their update results will directly affect the available resources and time window assessments of subsequent subtasks. Sequential processing helps to construct a layer-by-layer recursive and information-coherent replanning decision, avoiding decision conflicts and resource assessment distortions that may arise from reverse or parallel evaluations.

[0142] For example, when a preceding task encounters an anomaly and triggers the rescheduling of a series of subtasks with sequential dependencies (e.g., the original plan was for subtask 1 to start at 09:00, subtask 2 to start at 10:30, and subtask 3 to start at 13:00), the system will update the strategy sequentially according to the original expected start time of each subtask.

[0143] The system first processes subtask 1, which starts earliest, by evaluating it and reassigning the most suitable robot to it, and calculating a new estimated completion time (e.g., 09:45). Then, based on the adjusted results for subtask 1, subtask 2 is processed, ensuring that its execution does not conflict with occupied resources while meeting its own resource requirements, and that its start time is no earlier than 09:45. Finally, the system plans subtask 3 based on the updated time constraints of subtask 2.

[0144] This chronologically progressive replanning approach ensures that dependencies and resource constraints on the task chain are consistently and continuously passed down and satisfied during dynamic adjustments, thus systematically generating a feasible overall update scheduling scheme. Conversely, if this order is broken, for example, planning the latest-starting subtask 3 first, it may prematurely occupy a critical resource, causing the earlier-starting subtasks 1 or 2 to be unable to be effectively scheduled due to insufficient resources, ultimately leading to the failure of the entire replanning process.

[0145] In some embodiments, the task sequence includes a second subtask, which requires collaborative execution by at least two types of robots. The characteristic of such tasks is that the multiple participating robots must be synchronously scheduled and coordinated to ensure their actions are closely aligned in time, space, and logic, guaranteeing the complete and correct execution of the subtask. Compared to the control instructions for a typical subtask (here referring to a subtask executed by one type of robot), the control instructions for the second subtask not only include the individual task objectives to be achieved but also specify a series of collaborative constraints.

[0146] Optionally, for the second subtask, control instructions are sent to at least two types of robots performing the second subtask, the control instructions being used to instruct the at least two types of robots to perform the second subtask under the condition of satisfying cooperative constraints.

[0147] Cooperative constraints are used to constrain at least one of the following: the relative positions of at least two robots, the relative motion speeds of at least two robots, the joint movement paths of at least two robots, and the range of forces simultaneously output by at least two robots.

[0148] For example, in the second subtask of “cooperatively transporting large sheet metal,” the control instructions issued to the local controllers of the autonomous mobile robot and the collaborative robotic arm include at least the following information: “Task objective: transport the sheet metal smoothly from position A to position B; constraint: maximum transport speed 0.3 m / s; cooperation rule: the relative pose error between the robotic arm end effector and the autonomous mobile robot’s carrying platform must be kept within ±5 cm and ±2 degrees.”

[0149] Upon receiving the instruction, each robot's local controller (such as a reinforcement learning controller) simultaneously parses the policy. Its internal reward function or control logic is shaped by this cooperative rule, enabling it to not only achieve its own task when autonomously generating low-level control instructions, but also to calculate and adjust in real time to meet the relative constraints with its collaborating partners. For example, when planning its own movement, the controller of an autonomous mobile robot considers how to make the platform's movement smoother to reduce disturbances to the robotic arm; while the robotic arm's controller may actively adjust the gripping force based on force sensor feedback to compensate for minor offsets caused by the autonomous mobile robot's movement. Through this distributed but shared unified cooperative goal of autonomous control, multiple robots can achieve high-precision, robust real-time collaboration with low communication overhead, jointly completing complex second sub-tasks.

[0150] In summary, the method for scheduling robots to execute tasks provided in this application intelligently parses and constructs a sequence of multiple sub-tasks with logical order and dependencies from a comprehensive target task issued by the user, thereby modularizing and clarifying complex operations. Based on this, it can intelligently match the most suitable robot for each sub-task from a variety of robots according to the execution conditions required to complete each sub-task, thus generating an executable overall scheduling strategy. This effectively solves the problem of optimal allocation of tasks and resources in heterogeneous multi-robot systems, significantly improving the automation level and efficiency of job planning.

[0151] Corresponding to the method of scheduling robots to perform tasks in the above embodiments, Figure 5 A structural block diagram of a device for scheduling robots to perform tasks, provided in an embodiment of this application, is shown. For ease of explanation, only the parts related to the embodiments of this application are shown.

[0152] Reference Figure 5 The device 500 includes: a task acquisition module 510, configured to generate a task sequence of at least one subtask corresponding to the target task in response to a user instruction indicating a target task; a scheduling module 520, configured to allocate at least one robot capable of executing the subtask from multiple candidate robots based on the capability information of multiple candidate robots, thereby obtaining a robot scheduling strategy corresponding to the task sequence; the scheduling module 520 is further configured to control the robot corresponding to each subtask to execute the corresponding subtask according to the robot scheduling strategy; the scheduling module 520 is further configured to determine a first target subtask from the task sequence when an abnormal working state of a first robot is detected, the first target subtask including at least one of the following: a main subtask executed by the first robot, and an auxiliary subtask that has a dependency relationship with the subtask executed by the first robot; the scheduling module 520 is further configured to update the robot scheduling strategy according to the first target subtask, thereby obtaining an updated robot scheduling strategy.

[0153] It should be noted that the information interaction and execution process between the above-mentioned devices / modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0154] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0155] To implement the above embodiments, this application also proposes an electronic device. Figure 6 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application.

[0156] like Figure 6 As shown, the above-mentioned electronic device 600 includes: The system includes a memory 610 and at least one processor 620, and a bus 630 connecting the different components (including the memory 610 and the processor 620). The memory 610 stores a computer program, which implements the method of the embodiments of this application when the processor 620 executes the program.

[0157] Bus 630 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0158] Electronic device 600 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 600, including volatile and non-volatile media, removable and non-removable media.

[0159] Memory 610 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 640 and / or cache memory 650. Electronic device 600 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 660 may be used to read and write non-removable, non-volatile magnetic media (… Figure 6 Not shown; usually referred to as a "hard drive"). Although Figure 6 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 630 via one or more data media interfaces. Memory 610 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0160] A program / utility 680 having a set (at least one) of program modules 670 may be stored in, for example, memory 610. Such program modules 670 include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 670 typically perform the functions and / or methods described in the embodiments of this application.

[0161] Electronic device 600 can also communicate with one or more external devices 690 (e.g., keyboard, pointing device, display 691, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 696. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 693. As shown, network adapter 693 communicates with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0162] The processor 620 executes various functional applications and data processing by running programs stored in the memory 610.

[0163] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the method in the embodiment of this application, and will not be repeated here.

[0164] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the various method embodiments above.

[0165] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0166] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / electronic device, a recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some regions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0167] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0168] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0169] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

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

[0171] In the foregoing, specific details such as particular system architectures and techniques have been set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted to avoid unnecessary detail from obscuring the description of this application.

[0172] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0173] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0174] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0175] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0176] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0177] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for scheduling robots to perform tasks, characterized in that, The method includes: In response to a user instruction indicating a target task, a task sequence of at least one subtask corresponding to the target task is generated; Based on the capability information of multiple candidate robots, at least one robot capable of performing the sub-task is assigned to each sub-task from the multiple candidate robots to obtain the robot scheduling strategy corresponding to the task sequence; According to the robot scheduling strategy, control the robot corresponding to each subtask to execute the corresponding subtask; If an abnormal working state of a first robot is detected, a first target subtask is determined from the task sequence. The first target subtask includes at least one of the following: a main subtask performed by the first robot and an auxiliary subtask that has a dependency relationship with the main subtask performed by the first robot. The robot scheduling strategy is updated based on the first target sub-task to obtain the updated robot scheduling strategy.

2. The method according to claim 1, characterized in that, The step of updating the robot scheduling strategy according to the first target sub-task to obtain the updated robot scheduling strategy includes: The main sub-task executed by the first robot in the robot scheduling strategy is replaced by the second robot, and the second robot is working normally. Under the condition of meeting the preset dynamic adjustment conditions, the execution order of the auxiliary sub-tasks that have a dependency relationship with the main sub-tasks executed by the first robot in the robot scheduling strategy is adjusted to obtain the updated robot scheduling strategy. The preset dynamic adjustment conditions refer to the fact that the influence range of the first target sub-task causes resource allocation conflicts or task timing conflicts in the robot scheduling strategy.

3. The method according to claim 2, characterized in that, The step of replacing the master-subtask executed by the first robot in the robot scheduling strategy with the execution of the second robot includes: The second robot is determined from the multiple candidate robots other than the first robot. The second robot is a robot that is not currently executing a subtask and is capable of executing the main subtask corresponding to the first robot. The second robot includes at least one of the following: a robot other than the robot scheduling strategy; a robot whose task execution order in the task sequence is before the main subtask corresponding to the first robot; or a robot in the task sequence that has a task to be executed, and there is no timing conflict between the task to be executed and the main subtask corresponding to the first robot.

4. The method according to claim 1, characterized in that, The step of generating a task sequence of at least one subtask corresponding to the target task in response to a user instruction indicating the target task includes: The task sequence is generated based on the dependencies between each subtask and other subtasks, wherein the task sequence includes a first subtask, which is any subtask in the task sequence, and subtasks that have dependencies on the first subtask include subtasks that need to utilize the execution result of the first subtask.

5. The method according to any one of claims 1 to 4, characterized in that, The step of assigning at least one robot capable of performing the sub-task to each sub-task from among the multiple candidate robots based on their capability information, thereby obtaining the robot scheduling strategy corresponding to the task sequence, includes: Obtain the capability information of the various candidate robots; Determine the execution conditions that must be met to execute each subtask; For each subtask, the matching degree between the execution conditions of the subtask and the capability information of the various candidate robots is obtained; The candidate robot with the highest matching degree is selected as the robot to perform the sub-task.

6. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The capability information of each robot is updated based on the execution results of its corresponding sub-tasks.

7. The method according to any one of claims 1 to 4, characterized in that, The task sequence includes a second subtask, which requires at least two types of robots to perform collaboratively. The step of controlling the robot corresponding to each subtask to execute the corresponding subtask according to the robot scheduling strategy includes: For the second sub-task, control instructions are sent to at least two types of robots performing the second sub-task respectively. The control instructions are used to instruct the at least two types of robots to perform the second sub-task under the condition of satisfying cooperative constraints. The cooperative constraints are used to constrain at least one of the following: the relative position between the at least two types of robots, the relative motion speed between the at least two types of robots, the joint movement path between the at least two types of robots, and the range of force output by the at least two types of robots simultaneously.

8. A device for scheduling robots to perform tasks, characterized in that, The device includes: The task acquisition module is used to generate a task sequence of at least one subtask corresponding to the target task in response to a user instruction indicating a target task; The scheduling module is used to allocate at least one robot capable of performing the subtask from the multiple candidate robots based on the capability information of the multiple candidate robots, thereby obtaining the robot scheduling strategy corresponding to the task sequence; The scheduling module is also used to control the robot corresponding to each subtask to execute the corresponding subtask according to the robot scheduling strategy. The scheduling module is further configured to determine a first target subtask from the task sequence when an abnormal working state of a first robot is detected. The first target subtask includes at least one of the following: a main subtask executed by the first robot and an auxiliary subtask that has a dependency relationship with the main subtask executed by the first robot. The scheduling module is further configured to update the robot scheduling strategy according to the target sub-task, thereby obtaining an updated robot scheduling strategy.

9. An electronic device comprising a memory, one or more processors, and a computer program stored in the memory and executable on the one or more processors, characterized in that, When the one or more processors execute the computer program, the electronic device performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 7.

Images