Task scheduling method, device and storage medium for multi-brand robots

Abstract

This application discloses a task scheduling method, device, and storage medium for multi-brand robots, relating to the field of data processing technology. The method includes: determining the target robot to execute the instruction to be assigned based on the robot's state and the instruction type of the instruction to be assigned; filling in the general instruction template corresponding to the instruction type based on the parsing result of the instruction to be assigned, and generating a general instruction corresponding to the instruction to be assigned; obtaining the instruction conversion rules associated with the target robot, and converting the general instruction into a proprietary instruction according to the instruction conversion rules; and issuing the proprietary instruction to the target robot, thereby controlling the operation of the target robot through the proprietary instruction. This application unifies the instructions into standardized general instructions, and then uses the instruction conversion rules to convert the general instructions into proprietary instructions for the target robot, thus solving the problem of instruction incompatibility between robots of different brands.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a task scheduling method, device, and storage medium for multi-brand robots. Background Art

[0002] The Automated Dispatching System (ADS) for multi-brand robots is a system designed to implement mixed dispatching of multi-modal robots. It provides an open, unified dispatching interface for mobile robots and precisely controls robots according to commands from the host system, enabling the mixed operation of multi-brand robots within the same scene map. In practice, robots from different brands often use different communication protocols, command formats, and control logic. This leads to command incompatibility when integrating multi-brand robots, making unified dispatching and control difficult.

[0003] Currently, a unified communication interface is typically developed for different robot types to ensure effective information exchange with multi-brand robot dispatch systems. However, because communication interfaces are often closely tied to the robot's hardware characteristics and software architecture, changes to the hardware or software may make the existing communication interface no longer meet communication requirements. Therefore, when robot hardware or software is updated, the unified communication interface may need to be adjusted accordingly, increasing system maintenance costs.

[0004] The above content is only used to assist in understanding the technical solution of this application and does not constitute an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a task scheduling method, device and storage medium for multi-brand robots, aiming to solve the technical problem of how to solve the incompatibility of instructions between robots of different brands.

[0006] To achieve the above objectives, this application proposes a task scheduling method for multi-brand robots, the method comprising:

[0007] Determining a target robot to execute the instruction to be assigned based on the robot status and the instruction type of the instruction to be assigned;

[0008] Filling in a general instruction template corresponding to the instruction type according to the parsing result of the instruction to be assigned, and generating a general instruction corresponding to the instruction to be assigned;

[0009] Obtaining an instruction conversion rule associated with the target robot, and converting the general instruction into a proprietary instruction according to the instruction conversion rule;

[0010] The proprietary instruction is sent to the target robot, thereby controlling the operation of the target robot through the proprietary instruction.

[0011] In one embodiment, before the step of obtaining the instruction conversion rule associated with the target robot and converting the general instruction into a proprietary instruction according to the instruction conversion rule, the step further includes:

[0012] Matching the general instruction and the brand identifier of the target robot in an instruction conversion rule library to determine whether the instruction conversion rule exists;

[0013] If it does not exist, the decision tree model is trained according to the feature data and target label of the instruction to be assigned to obtain a target decision tree model;

[0014] The branches and nodes of the decision tree in the target decision tree model are confirmed as the instruction conversion rules.

[0015] In one embodiment, the step of identifying the branches and nodes of the decision tree in the target decision tree model as the instruction conversion rules includes:

[0016] Starting from the root node of the decision tree, traversing the nodes along the branches of the decision tree;

[0017] The instruction conversion rule is obtained by combining the conditional judgment statements of the internal nodes and the output statements of the leaf nodes.

[0018] In one embodiment, the step of matching the general instruction and the brand identifier of the target robot in an instruction conversion rule library to determine whether the instruction conversion rule exists includes:

[0019] Parsing the general instruction according to the syntax analyzer to obtain the action type and parameter range;

[0020] Matching the action type with the brand identifier; if the match fails, decomposing the action type into actions to obtain atomic actions;

[0021] Determine whether the atomic action has a sub-conversion rule, and if so, combine the sub-conversion rules to obtain the instruction conversion rule;

[0022] If the sub-conversion rule does not exist, it is determined that the match fails.

[0023] In one embodiment, the step of obtaining the instruction conversion rule associated with the target robot and converting the general instruction into a proprietary instruction according to the instruction conversion rule includes:

[0024] replacing the execution action of the general instruction according to the instruction conversion rule, and performing parameter value conversion and / or unit conversion on the parameters of the general instruction;

[0025] The converted execution action and the parameters are reorganized according to the instruction conversion rule to obtain the target-specific instruction.

[0026] In one embodiment, the step of determining a target robot to execute the instruction to be assigned based on the robot state and the instruction type of the instruction to be assigned includes:

[0027] Determining the number of dispatchable robots according to the instruction type and the status of the robot;

[0028] If the number of dispatchable robots is less than or equal to a preset dispatchable number threshold, the dispatchable robot list is traversed to obtain the path distance from the current position of the dispatchable robot to the task starting point;

[0029] The dispatchable robot with the smallest path distance is determined as the target robot.

[0030] In one embodiment, after the step of determining the number of dispatchable robots according to the instruction type and the status of the robot, the method further includes:

[0031] If the number of dispatchable robots is greater than the preset dispatchable number threshold, a comprehensive score of the task allocation plan is obtained based on the congestion coefficient of the shipping port, the path distance, and the priority level;

[0032] Obtain a target task allocation plan corresponding to the highest comprehensive score, and determine the target robot according to the target task allocation plan.

[0033] In one embodiment, the step of determining the number of dispatchable robots according to the instruction type and the status of the robot includes:

[0034] Determining, according to the instruction type, a first robot that can execute the instruction to be assigned;

[0035] Obtaining, according to the identifier of the first robot, a current power level of the first robot and a remaining power level after task execution;

[0036] The first robots whose current power is less than a preset power threshold, or whose remaining power is less than the sum of the mission energy consumption and the energy consumption of returning to the charging station are filtered to obtain the dispatchable robots and the number of the dispatchable robots.

[0037] In addition, to achieve the above-mentioned purpose, the present application also proposes a task scheduling device for a multi-brand robot, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the computer program is configured to implement the steps of the task scheduling method for a multi-brand robot as described above.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium. A computer program is stored on the storage medium, and when the computer program is executed by the processor, the steps of the task scheduling method for multi-brand robots as described above are implemented.

[0039] This application proposes a task scheduling method for multi-brand robots. By comprehensively considering the instruction type and robot status, it can ensure that the task can be assigned to the robot most suitable for execution. According to the instruction type, the corresponding general instruction template is called, and the parameters are filled in according to the requirements of the specific instruction, so that the generated instruction can accurately reflect the specific requirements of the task to be executed. According to the brand identification of the target robot, the general instruction mapping rules corresponding to the brand robot are obtained. The obtained mapping rules are used to convert the general instructions into proprietary instructions for the target robot, solving the problem of instruction incompatibility between robots of different brands. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0042] Figure 1 A flowchart illustrating a first embodiment of a method for scheduling tasks for a multi-brand robot according to the present application;

[0043] Figure 2 A flowchart illustrating a second embodiment of the task scheduling method for multi-brand robots of this application is provided;

[0044] Figure 3 A flowchart illustrating a third embodiment of the method for scheduling tasks for a multi-brand robot according to the present application;

[0045] Figure 4 Another flowchart diagram provided for Example 3 of the task scheduling method for multi-brand robots of this application;

[0046] Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the task scheduling method for multi-brand robots in the embodiment of the present application.

[0047] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0048] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0049] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0050] The main solution of the embodiment of the present application is: according to the instruction type of the instruction to be assigned and the status of the robot, the task to be assigned corresponding to the instruction to be assigned is assigned, and the target robot to execute the task to be assigned is determined; according to the instruction type, the corresponding general instruction template is called, and parameters are filled in the general instruction template to generate a general instruction; according to the brand identification of the target robot, the instruction conversion rule corresponding to the general instruction is obtained, and the general instruction is converted into a target-specific instruction according to the mapping rule; the target instruction is sent to the corresponding target robot.

[0051] In this embodiment, for ease of description, the following description is made with the task scheduling of multi-brand robots as the execution subject.

[0052] The Automated Dispatching System (ADS) is a system for implementing mixed scheduling of multi-modal robots. It provides an open, unified scheduling interface for mobile robots, enabling command-level control of robots based on the policies of the upper-level system, and enabling the mixed operation of robots from multiple brands within the same scene map. In practice, robots from different brands often use different communication protocols, command formats, and control logic. This leads to command incompatibility when integrating robots from multiple brands, making unified scheduling and control difficult.

[0053] Currently, a unified communication interface is typically developed for different robot types to ensure effective information exchange with multi-brand robot dispatch systems. However, because communication interfaces are often closely tied to the robot's hardware characteristics and software architecture, changes to the hardware or software may make the existing communication interface no longer meet communication requirements. Therefore, when robot hardware or software is updated, the unified communication interface may need to be adjusted accordingly, increasing system maintenance costs.

[0054] This application provides a solution that ensures that tasks are assigned to the most suitable robot for execution by comprehensively considering the instruction type and robot status. The corresponding general instruction template is called according to the instruction type, and parameters are filled in according to the requirements of the specific instruction, so that the generated instruction can accurately reflect the specific requirements of the task to be executed. The general instruction mapping rules corresponding to the brand of robot are obtained based on the brand logo of the target robot. The obtained mapping rules are used to convert the general instructions into proprietary instructions of the target robot, solving the problem of instruction incompatibility between robots of different brands.

[0055] It should be noted that the execution subject of this embodiment can be a computing service device with network communication and program execution capabilities, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device or device capable of implementing the above functions. The following uses a task scheduling device for multi-brand robots as an example to illustrate this embodiment and the following embodiments.

[0056] Based on this, the embodiment of the present application provides a task scheduling method for multi-brand robots, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the task scheduling method for multi-brand robots of this application.

[0057] In this embodiment, the task scheduling method for multi-brand robots includes steps S10 to S40:

[0058] Step S10: determining a target robot to execute the instruction to be assigned based on the robot state and the instruction type of the instruction to be assigned.

[0059] It's understandable that different types of robots can execute different types of instructions depending on their design purpose and functional characteristics. For example, pallet-type AGVs (Automated Guided Vehicles) are primarily used to transport palletized goods, while lurking AGVs are suitable for shuttle transport under shelf shelves.

[0060] In this embodiment, after receiving a task request from a higher-level management system (such as an enterprise resource planning system or warehouse management system), the multi-brand robot scheduling system determines the target robot capable of executing the task based on the corresponding instruction type and the robot's status. Instruction types include movement instructions, such as forward, backward, turn, and move to a specified coordinate location; and operation instructions, such as grabbing and dropping objects. Robot states can include idle (the robot is not currently performing any task and is ready to accept new instructions); busy (the robot is currently performing a task and cannot immediately respond to new instructions); fault (the robot is malfunctioning, causing some or all functions to malfunction); and charging (the robot is charging and may only be able to execute specific charging-related or urgent instructions).

[0061] In this embodiment, a message queue (such as RabbitMQ or Kafka) is used to store and manage pending instructions. A detection mechanism is used to detect whether there are new, unassigned tasks in the task queue. When a pending task is detected, it is extracted from the task queue and formatted to ensure that it meets the expected format requirements. If the task format is incorrect, error handling is performed, such as logging or discarding the task. After verification, decoding and structured parsing are performed. The parsed task content may include information such as the task type (such as handling, assembly, inspection, and stacking), the task starting point (such as shipping port A and shipping port B), the target location (such as shipping port A and production line B), and the weight and dimensions of the goods. After parsing is complete, the obtained task type is matched with the preset instruction type to select robots capable of executing the pending instruction. When determining the target robot, a list of robots capable of executing the instruction type is first determined based on the pre-established matching relationship between instruction type and robot type. Next, a search is performed to find robots currently capable of executing the instruction (such as the idle state). Traverse all robots that meet the instruction type requirements and exclude robots that are in unexecutable states such as busy, faulty, or charging based on the real-time robot status information.

[0062] Optionally, detection trigger conditions can be configured based on the real-time requirements of the assigned task and system performance. For tasks with high real-time requirements, an event-triggered mechanism can be used, triggering notifications immediately when new messages arrive in the queue. For batch processing tasks, the queue can be polled periodically to pull a batch of messages to the local server for processing.

[0063] In this embodiment, when a target robot that meets the instruction type is not obtained, first, multiple aspects such as the task description, robot status, and matching rules are checked to determine the reason for the matching failure.

[0064] For example, you can first check the task description to ensure that the task type, requirements, priority and other information are accurate, so as to confirm whether the matching failure is caused by missing or incorrect information. Check the status of all available robots, including whether they are idle, power, location, load capacity, etc., to confirm whether any robots are unable to perform the task due to maintenance, failure or other reasons. Evaluate whether the matching conditions are up-to-date and accurately reflect the capabilities of the robots and the requirements of the task. Secondly, determine the adjustment plan based on the reason for the matching failure and re-match the matching task. The adjustment plan can be to adjust the requirements of the task to match the available robots, for example, reducing the load, changing the handling path or adjusting the task priority; or request a human operator or technician to intervene and manually select the target robot.

[0065] In this embodiment, if multiple target robots meet the requirements, further selection can be performed based on pre-set target robot selection rules. The target robot can be determined based on the robot's location, with robots closer to the command execution location being prioritized for the task. Alternatively, the target robot can be determined based on its remaining battery life, with robots with higher battery levels being prioritized.

[0066] Step S20: filling in a general instruction template corresponding to the instruction type according to the parsing result of the instruction to be assigned, and generating a general instruction corresponding to the instruction to be assigned.

[0067] In this embodiment, a corresponding general instruction template is determined from a preset general instruction template library based on the instruction type. The template contains the basic structure and format of the instruction, as well as placeholders for parameters that need to be filled in, such as the cargo weight parameter. The corresponding general instruction template is retrieved using the instruction type identifier or name. After the call is completed, the parameter values are extracted from the instruction request and filled in to obtain the general instruction.

[0068] Step S30: Acquire the instruction conversion rule associated with the target robot, and convert the general instruction into a proprietary instruction according to the instruction conversion rule.

[0069] Step S40: Send the proprietary instruction to the target robot, thereby controlling the operation of the target robot through the proprietary instruction.

[0070] In this embodiment, a pre-set mapping rule library is searched for the corresponding mapping rules based on the brand and model of the target robot. After obtaining the mapping rules, the generic instructions are parsed and converted into target-specific instructions. The target-specific instructions are then sent to the target robot via the communication system. The target robot executes the instructions and provides feedback on the results. Based on the feedback, task completion status is recorded and the robot status is updated.

[0071] In a feasible implementation, step S30 may include the following steps:

[0072] replacing the execution action of the general instruction according to the instruction conversion rule, and performing parameter value conversion and / or unit conversion on the parameters of the general instruction;

[0073] The converted execution action and the parameters are reorganized according to the instruction conversion rule to obtain the target-specific instruction.

[0074] In this embodiment, based on the execution action of the general instruction, the name, description, and parameters of the action type are compared in the proprietary instruction set of the target robot to screen out related or similar action types. The screened action types are compared in detail, including their key parameters such as motion trajectory, speed, acceleration, and positioning accuracy. If the general instruction action type cannot be directly implemented by a single action type in the proprietary instruction set, it is implemented by combining multiple action types. The action types in the general instructions are analyzed to determine their required functions and characteristics. The proprietary instruction set is searched for action types that partially match or are related to the general instruction action type. Based on the matching results, it is determined which proprietary instruction action types can be combined to implement the functions of the general instruction. The execution order of these proprietary instruction action types is determined to ensure that they can work together as expected. Based on the determined order and parameter settings, the combined proprietary instruction is generated.

[0075] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 2 Before step S30, the task scheduling method for multi-brand robots further includes steps A10 to A30:

[0076] Step A10: Match the general instruction and the brand identifier of the target robot in a rule library to determine whether the instruction conversion rule exists.

[0077] In this embodiment, the brand identifier of the target robot is accurately matched in the preset rule library to find out whether there is a corresponding instruction conversion rule. The rule library is accurately matched according to the action type, and on the basis of the action type matching, it is further filtered according to the brand identifier.

[0078] In one possible approach, if exact matching fails to find a fully matching conversion rule, a fuzzy match is attempted using a similarity algorithm. The parameter structure of the general instruction and the parameter structure of the candidate conversion rules are each represented as a vector. Each dimension of the vector can represent a parameter or feature, such as the number, type, or relationship of parameters. The cosine similarity formula is used to calculate the similarity between the two vectors. Among all candidate conversion rules, the conversion rule with the highest cosine similarity to the general instruction parameter structure is selected as the match.

[0079] In a feasible implementation manner, step A10 may further include the following steps:

[0080] Parsing the general instruction according to the syntax analyzer to obtain the action type and parameter range;

[0081] Matching the action type with the brand identifier; if the match fails, decomposing the action type into actions to obtain atomic actions;

[0082] Determine whether the atomic action has a sub-conversion rule, and if so, combine the sub-conversion rules to obtain the instruction conversion rule;

[0083] If the sub-conversion rule does not exist, it is determined that the match fails.

[0084] In this implementation, a syntax analyzer parses common instructions and generates a corresponding abstract syntax tree (ABST). The ABST clearly displays the grammatical structure of the instruction, including the relationships and hierarchy between its components. Based on the ABST, semantic information about the instruction is further extracted, including the action type (e.g., move, grab, place), parameter ranges (e.g., position coordinates, speed), and possible objects or tools involved. Key fields extracted are standardized, including unified data formats, unit conversions, and necessary numerical range adjustments. First, a precise match is performed against a pre-set rule library based on the target robot's brand identifier. If a match fails, the composite action is decomposed into atomic actions, which are the smallest indivisible units of operation. For example, the "pick_and_place" action is decomposed into two atomic actions: "move" and "grasp." After decomposition, each atomic action is matched. The rule library is searched separately to find the corresponding conversion rules for each atomic action. Based on the relationships between the atomic actions, the conversion rules are combined to determine how to combine them. Possible combinations include sequential execution, parallel execution, and conditional selection.

[0085] Step A20: If it does not exist, the decision tree model is trained according to the feature data and target label of the instruction to be assigned to obtain a target decision tree model.

[0086] In this embodiment, when the matching fails, indicating a lack of conversion rules for a specific brand, conversion rules are generated based on a supervised learning algorithm, such as a decision tree, random forest, gradient boosting tree, or neural network.

[0087] Optionally, conversion rules are generated based on the decision tree. Feature data is extracted from the existing instruction data set. Feature data is the input information used to train the decision tree model, which can help the model distinguish different categories of instructions or data. Feature data includes: instruction type, instruction content, instruction format, and brand name or identifier, etc. The target label is the output result that the decision tree model needs to predict or classify. The target label may include: the converted instruction and the conversion category representing the converted instruction type or format, etc. The decision tree model is trained using the preprocessed feature data and target labels. During the training process, the decision tree algorithm attempts to find the best splitting points and splitting features to divide the input data into different categories or intervals, and predict the target label for each category.

[0088] Step A30: confirming the branches and nodes of the decision tree in the target decision tree model as the instruction conversion rules.

[0089] In this embodiment, after training is complete, transformation rules are extracted from the target decision tree model. These transformation rules are a series of conditional statements, each corresponding to a split point in the decision tree. Starting from the root node, the rules are sequentially judged based on the input data's feature values and traversed down the tree until a leaf node is reached. The output value corresponding to the leaf node is the result of the transformation.

[0090] In a feasible implementation, step A30 may include the following steps:

[0091] Starting from the root node of the decision tree, traversing the nodes along the branches of the decision tree;

[0092] The instruction conversion rule is obtained by combining the conditional judgment statements of the internal nodes and the output statements of the leaf nodes.

[0093] In this embodiment, the splitting feature and splitting threshold of the current internal node are obtained from the target decision tree model. The splitting feature is usually a field or attribute in the input data, which is used to compare with the feature value. Using the splitting feature and splitting threshold, a conditional judgment statement is constructed. For each leaf node of the decision tree, the output value or category label is obtained from the decision tree model. The output value can be a specific numerical value, string or other data type, used to represent the classification result. Using the output value or category label, an output statement is constructed. The conditional judgment statements of all internal nodes and the output statements of the leaf nodes are combined to form a complete set of conversion rules. Each rule consists of a series of conditional judgment statements and an output statement, which represents the complete path from the root node to a leaf node. Rules with similar conditions and outputs are merged to obtain instruction conversion rules.

[0094] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the above embodiment 1 can be referred to the above introduction and will not be described in detail later. Figure 3 , step S30 may include steps S31 to S33:

[0095] Step S31, determining the number of dispatchable robots according to the instruction type and the status of the robot;

[0096] In this embodiment, the number of dispatchable robots can be the number of idle robots or the sum of the number of idle robots and the number of robots about to become idle. The number of robots about to become idle can be predicted based on the remaining time of the current task. The robot's current task information, including task start time and estimated task completion time, is obtained. A prediction model is constructed using methods such as time series analysis and machine learning. The task start time and estimated task completion time are input into the prediction model to obtain the estimated idle time of the robots, thereby determining the number of robots about to become idle.

[0097] Optionally, pre-setting a filtering condition to further filter the robots determined according to the instruction type and the robot status includes the following steps:

[0098] Determining, according to the instruction type, a first robot that can execute the instruction to be assigned;

[0099] Obtaining, according to the identifier of the first robot, a current power level of the first robot and a remaining power level after task execution;

[0100] The first robots whose current power is less than a preset power threshold, or whose remaining power is less than the sum of the mission energy consumption and the energy consumption of returning to the charging station are filtered to obtain the dispatchable robots and the number of the dispatchable robots.

[0101] In the above steps, after determining the first robot that meets the instruction type conditions, the first robot's current status information, including power level, load, and location, is obtained based on its identifier. The preset power threshold is appropriately set based on the first robot's battery capacity, task characteristics, and system requirements. For each first robot, a check is performed to see whether its current power level is less than the preset power threshold, or whether the remaining power level meets the energy consumption required to perform the current task, including energy consumption during task execution, energy consumption during the return trip, and energy consumption upon returning to the charging station. This ensures that the robot will not be interrupted during task execution due to insufficient power. First robots that meet any of the above conditions are removed from the list of dispatchable robots to obtain a final dispatchable list, and the number of robots in the dispatchable robot list is counted. By filtering out first robots that do not meet the conditions, the search space for task assignment is reduced, enabling the identification of suitable target robots for task execution to be accelerated. Furthermore, this ensures that the target robot will not malfunction due to insufficient power or overload while performing the task, preventing damage to the target robot due to overload or frequent low-power operation.

[0102] Step S32: If the number of dispatchable robots is less than or equal to a preset dispatchable number threshold, traverse the dispatchable robot list to obtain the path distance from the current position of the dispatchable robot to the task starting point;

[0103] Step S33: Determine the dispatchable robot with the smallest path distance as the target robot.

[0104] In this embodiment, the task instruction type (e.g., handling, picking, or transport) is analyzed. Based on the task instruction type, the required robot type (e.g., picking robot, traction robot, roller robot, etc.) is determined. Robots that meet the instruction type requirements are screened to obtain a list of dispatchable robots capable of executing the task. The target robot selection rule is determined based on the number of dispatchable robots in the list. When the number of dispatchable robots is less than or equal to a preset dispatchable threshold, the dispatchable robot list is traversed. The dispatchable robot list includes at least the identifiers and current position coordinates of all dispatchable robots. For each robot, a path planning algorithm is used to obtain the path distance from its current position to the task starting point. The robot with the smallest path distance is selected as the target robot. Based on the task starting position coordinates obtained from the parsed results of the task to be assigned, the current position coordinates of the robot currently traversed are obtained. A path planning algorithm (e.g., A algorithm, Dijkstra algorithm, A+ heuristic method, etc.) is invoked, using the robot's current position as the starting point and the task starting point as the end point, to calculate the path distance. The calculated path distance is stored in a pre-created path distance dictionary, with the robot identifier as the key and the path distance as the value. Initialize the minimum path distance to infinity and initialize the target robot identifier. Traverse the path distance dictionary. If the current path distance is less than the minimum path distance, update the minimum path distance to the current traversed path distance.

[0105] Please refer to Figure 4 In a feasible implementation manner, step S31 may further include steps S34 to S35:

[0106] Step S34: If the number of dispatchable robots is greater than a preset dispatchable number threshold, a comprehensive score of the task allocation plan is obtained according to the congestion coefficient of the shipping port, the path distance, and the priority level.

[0107] Step S35 , obtaining the target task allocation plan corresponding to the highest comprehensive score, and determining the target robot according to the target task allocation plan.

[0108] In this implementation, a comprehensive scoring model is defined, encompassing dimensions such as the outlet congestion coefficient, path distance, and priority. Each dimension can be assigned a different weight to reflect its importance in actual task allocation. The list of dispatchable robots is traversed, and each robot and task combination is combined. A comprehensive score is calculated based on the comprehensive scoring model. The comprehensive score = outlet congestion coefficient score * congestion weight + path distance score * distance weight + priority score * priority weight. The outlet congestion coefficient score is calculated based on the congestion coefficient of the outlet where the task's endpoint is located; a higher congestion coefficient indicates a lower score. The path distance score is calculated based on the path distance from the robot's current location to the task's starting point. A longer path distance indicates a lower score. The priority score is calculated based on the robot's priority level; a higher priority level indicates a higher score. A higher comprehensive score indicates a more optimal solution. From all calculated comprehensive scores, the task allocation solution with the highest score is selected as the optimal solution. The target robot corresponding to the optimal solution is determined based on the optimal solution. By comprehensively considering multiple dimensions, the task load can be more effectively balanced across robots, preventing some robots from being overloaded while others remain idle.

[0109] Based on the first embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the first embodiment can be referred to the above introduction and will not be repeated hereafter. On this basis, before step S10, the task scheduling method of the multi-brand robot further includes the following steps:

[0110] Determine the executable actions of each type of robot according to the preset robot capability map, and create the corresponding general instruction template according to the executable actions;

[0111] It should be noted that the instruction template is a standardized instruction framework that provides a standardized instruction format for controlling the robot to perform specific actions.

[0112] In this embodiment, the preset robot capability map contains functional descriptions, operating ranges, physical limitations, and specific actions that different types of robots can perform. All possible action types are identified from the map, including: move, which navigates to a target location along a specified path or node, supporting adjustable parameters such as speed and acceleration; pause, which temporarily stops the current task; fork lift, suitable for forklift-type AGVs, which controls the height of the forks to complete loading and unloading operations; pallet grab / release, used by handling robots to grab or release pallets or cargo; and rotate, which adjusts the direction of a carrier, such as rotating a shelf or adjusting the position of cargo. Based on the standards defined by the VDA5050 protocol, the basic format of a common instruction template is determined, including an action type identifier, a list of required parameters, and possible additional information (such as execution conditions and priority). A corresponding common instruction template is created for each action type. By adhering to the VDA5050 protocol standard, automated guided vehicles (AGVs) and mobile robots from different manufacturers can communicate using a unified instruction format. This improves system interoperability and enables vehicles of different brands to work together under the same control system.

[0113] Optionally, after the general instruction template is completed, use a simulation environment to verify it. Ensure that the template correctly expresses the robot's intended motion. Based on the test results and feedback, make necessary adjustments and optimizations to the template, such as modifying parameter definitions, adjusting the template structure, or adding additional information fields.

[0114] A mapping rule and an association relationship are established between the general instruction template and the brand-specific instruction, and the mapping rule is used to convert the general instruction into the brand-specific instruction.

[0115] It should be noted that brand-specific instructions are the instruction formats used by robots of a specific brand, and contain parameters, command structures, and grammatical rules unique to that brand.

[0116] In this embodiment, one or more corresponding brand-specific commands are defined for each command type in the universal command template. A mapping table or database is established to store the mapping relationship between universal command templates and brand-specific commands. The mapping table can be a database or configuration file, containing information about task types, command types, and the corresponding robot types. The mapping rules are implemented in the robot control system or middleware. When a universal command is received, it can be automatically converted into the corresponding brand-specific command and sent to the target robot.

[0117] For example, a general instruction template includes a "MOVE" instruction for controlling robot movement. This instruction contains two parameters: "direction" and "distance." The mapping rule for a certain brand of robot is as follows: map the "MOVE" instruction to the "MOVE_CMD" instruction for that brand of robot. Map the "direction" parameter to "direction_param" and define its value range. Map the "distance" parameter to "distance_param" and define its data type and unit (for example, a floating point number in meters).

[0118] In this embodiment, when the robot hardware or software is updated, the mapping rules are dynamically adjusted to adapt to the new hardware or software features. This ensures that it can continue to adapt to robots of different brands and models. When it is detected that the hardware and software status of the robot has been updated, the robot's update log is obtained and analyzed to understand the specific content of the update, including new features, bug fixes, performance improvements, etc. For hardware updates, new hardware components, interface changes, etc. are identified in order to adjust the mapping rules. Based on the updated content obtained from the analysis, the mapping rule library is updated, including mapping rules from general instructions to proprietary instructions, parameter conversion rules, etc. For new hardware components or software functions, new mapping rules are set to ensure that the new functions can be correctly identified and utilized. By dynamically adjusting the mapping rules, there is no need to make large-scale modifications or rewrites to the communication interface, thereby reducing the maintenance cost of the system and ensuring the stability and reliability of the system.

[0119] Based on the first embodiment of the present application, in the fifth embodiment of the present application, the same or similar content as the above-mentioned embodiment 1 can be referred to the above introduction and will not be repeated hereafter. On this basis, after step S40, the task scheduling method of the multi-brand robot may further include: when a fault is detected in the target robot, obtaining the fault type of the faulty robot. According to the fault type, a corresponding fault resolution instruction is obtained from the instruction library, and the fault resolution instruction is sent to the faulty robot.

[0120] In this embodiment, the operating status of the target robot is detected to obtain sensor data, motor status, actuator position, etc. When an abnormal or unexpected status is detected, a fault is considered to exist and the fault type is identified. The fault type can be predefined, such as "fork stuck", "motor failure", "sensor failure", etc.

[0121] A pre-set instruction library contains instructions for resolving different fault types. When a fault type is identified and the corresponding error code is triggered, the robot retrieves the corresponding fault resolution instruction from the instruction library and sends it to the faulty robot. This fault resolution mechanism automatically identifies and resolves robot faults, improving the robot's task execution efficiency.

[0122] For example, if the target robot's battery level drops below a critical value while performing a task, the ERROR_LOW_BATTERY error code is triggered. The command library is searched to find a fault resolution command matching ERROR_LOW_BATTERY. Upon receiving the command, the faulty robot aborts the current task and navigates to a charging station for recharging.

[0123] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the task scheduling method of the multi-brand robot of the present application. More forms of simple transformations based on this technical concept are all within the scope of protection of the present application.

[0124] The present application provides a task scheduling device for a multi-brand robot, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the task scheduling method for the multi-brand robot in the above-mentioned embodiment one.

[0125] Reference below Figure 4 , which shows a schematic diagram of the structure of a task scheduling device suitable for implementing a multi-brand robot in an embodiment of the present application. The task scheduling device for a multi-brand robot in an embodiment of the present application may include, but is not limited to, mobile terminals such as laptop computers, personal digital assistants (PDAs), tablet computers (PADs), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The task scheduling device for multi-brand robots shown is merely an example and should not limit the functions and scope of use of the embodiments of the present application.

[0126] like Figure 4As shown, the task scheduling device for a multi-brand robot may include a processing device 1001 (e.g., a central processing unit, graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in a read-only memory (ROM) 1002 or programs loaded from a storage device 1003 into a random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the task scheduling device for a multi-brand robot. Processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007, including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008, including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003, including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication devices 1009 can allow the task scheduling device for multi-brand robots to communicate with other devices wirelessly or wired to exchange data. While the figure shows a task scheduling device for multi-brand robots with various systems, it should be understood that implementation or presence of all the illustrated systems is not required. More or fewer systems may alternatively be implemented or present.

[0127] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are performed.

[0128] The multi-brand robot task scheduling device provided in this application utilizes the multi-brand robot task scheduling method described in the aforementioned embodiment to address the technical issue of resolving command incompatibility between robots of different brands. Compared to the prior art, the multi-brand robot task scheduling device provided in this application achieves the same beneficial effects as the multi-brand robot task scheduling method described in the aforementioned embodiment. Other technical features of the multi-brand robot task scheduling device are the same as those disclosed in the aforementioned embodiment and are not further elaborated upon here.

[0129] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0130] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0131] The present application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, and the computer-readable program instructions are used to execute the task scheduling method for multi-brand robots in the above-mentioned embodiment.

[0132] The computer-readable storage medium provided herein may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0133] The computer-readable storage medium may be included in the task scheduling device of the multi-brand robot; or it may exist independently without being assembled into the task scheduling device of the multi-brand robot.

[0134] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the task scheduling device of the multi-brand robot, the task scheduling device of the multi-brand robot: determines the target robot that executes the instruction to be assigned according to the state of the robot and the instruction type of the instruction to be assigned; fills in the general instruction template corresponding to the instruction type according to the parsing result of the instruction to be assigned, and generates a general instruction corresponding to the instruction to be assigned; obtains the instruction conversion rule associated with the target robot, and converts the general instruction into a proprietary instruction according to the instruction conversion rule; sends the proprietary instruction to the target robot, thereby controlling the operation of the target robot through the proprietary instruction.

[0135] Computer program code for performing the operations of the present application may be written in one or more programming languages, or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0136] The flow charts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the specified function or operation, or can be implemented by a combination of dedicated hardware and computer instructions.

[0137] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0138] The computer-readable storage medium provided in this application stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned multi-brand robot task scheduling method. This computer-readable storage medium can address the technical issue of resolving instruction incompatibility between robots of different brands. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are similar to those of the multi-brand robot task scheduling method provided in the aforementioned embodiments, and are not further elaborated here.

[0139] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the task scheduling method for multi-brand robots as described above.

[0140] The computer program product provided in this application can solve the technical problem of how to resolve command incompatibility between robots of different brands. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the multi-brand robot task scheduling method provided in the above embodiment, and will not be elaborated here.

[0141] The above description is only part of the embodiments of the present application and does not limit the patent scope of the present application. All equivalent structural transformations made by using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A task scheduling method for multi-brand robots, characterized in that: The task scheduling method for multi-brand robots includes: Determining a target robot to execute the instruction to be assigned based on the robot status and the instruction type of the instruction to be assigned; Filling in a general instruction template corresponding to the instruction type according to the parsing result of the instruction to be assigned, and generating a general instruction corresponding to the instruction to be assigned; Matching the general instruction and the brand identifier of the target robot in an instruction conversion rule library includes: parsing the general instruction according to a syntax analyzer to obtain an abstract syntax tree, and extracting semantic information according to the abstract syntax tree to obtain an action type and a parameter range; matching the action type with the brand identifier to obtain an instruction conversion rule; if the match fails, decomposing the action type to obtain an atomic action; and combining sub-conversion rules corresponding to the atomic action to obtain the instruction conversion rule; Converting the general instruction into a proprietary instruction according to the instruction conversion rule includes: Replacing the execution action of the general instruction according to the instruction conversion rule, and performing parameter value conversion and / or unit conversion on the parameters of the general instruction; recombining the converted execution action and the parameters according to the instruction conversion rule to obtain the proprietary instruction; The proprietary instruction is sent to the target robot, thereby controlling the operation of the target robot through the proprietary instruction.

2. The task scheduling method for multi-brand robots according to claim 1, characterized in that: After the step of matching the universal instruction and the brand identifier of the target robot in the instruction conversion rule library, the method further includes: Determining whether the instruction conversion rule exists; If it does not exist, the decision tree model is trained according to the feature data and target label of the instruction to be assigned to obtain a target decision tree model; The branches and nodes of the decision tree in the target decision tree model are confirmed as the instruction conversion rules.

3. The task scheduling method for multi-brand robots according to claim 2, characterized in that: The step of confirming the branches and nodes of the decision tree in the target decision tree model as the instruction conversion rules includes: Starting from the root node of the decision tree, traversing the nodes along the branches of the decision tree; The instruction conversion rule is obtained by combining the conditional judgment statements of the internal nodes and the output statements of the leaf nodes.

4. The task scheduling method for multi-brand robots according to claim 1, characterized in that: The step of combining the sub-conversion rules corresponding to the atomic actions to obtain the instruction conversion rule includes: Determine whether the atomic action has a sub-conversion rule, and if so, combine the sub-conversion rules to obtain the instruction conversion rule; If the sub-conversion rule does not exist, it is determined that the match fails.

5. The task scheduling method for multi-brand robots according to claim 1, characterized in that: The step of determining a target robot to execute the instruction to be assigned based on the robot state and the instruction type of the instruction to be assigned comprises: Determining the number of dispatchable robots according to the instruction type and the status of the robot; If the number of dispatchable robots is less than or equal to a preset dispatchable number threshold, the dispatchable robot list is traversed to obtain the path distance from the current position of the dispatchable robot to the task starting point; The dispatchable robot with the smallest path distance is determined as the target robot.

6. The task scheduling method for multi-brand robots according to claim 5, characterized in that: After the step of determining the number of dispatchable robots according to the instruction type and the status of the robot, the method further includes: If the number of dispatchable robots is greater than the preset dispatchable number threshold, a comprehensive score of the task allocation plan is obtained based on the congestion coefficient of the shipping port, the path distance, and the priority level; Obtain a target task allocation plan corresponding to the highest comprehensive score, and determine the target robot according to the target task allocation plan.

7. The task scheduling method for multi-brand robots according to claim 5, characterized in that: The step of determining the number of dispatchable robots according to the instruction type and the status of the robot comprises: Determining, according to the instruction type, a first robot that can execute the instruction to be assigned; Obtaining, according to the identifier of the first robot, a current power level of the first robot and a remaining power level after task execution; The first robots whose current power is less than a preset power threshold, or whose remaining power is less than the sum of the mission energy consumption and the energy consumption of returning to the charging station are filtered to obtain the dispatchable robots and the number of the dispatchable robots.

8. A task scheduling device for multi-brand robots, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the task scheduling method for multi-brand robots according to any one of claims 1 to 7.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the task scheduling method for multi-brand robots according to any one of claims 1 to 7 are implemented.

Images