Robot management method and system based on double registration mechanisms

Abstract

The invention discloses a robot management method and system based on a dual registration mechanism, and the method comprises the following steps: obtaining a task instruction which comprises a production order and the like; performing demand processing on the task instruction to generate service demand data; robot matching is carried out on the service demand data according to a dual-registration mechanism, and a demand list is generated; sending the demand list to a corresponding robot; the robot receives and executes the matched service demand data; the system comprises an API layer, a unified planning layer, a dual-registration service docking layer, a distributed execution layer and a robot. The API layer is used for acquiring a task instruction; the unified planning layer is used for receiving a task instruction and carrying out demand processing to generate service demand data; the dual-registration service docking layer is used for performing robot matching on the service demand data according to a dual-registration mechanism to generate a demand list; the distributed execution layer is used for acquiring and sending the demand list to the corresponding robot; and the robot receives and executes the matched service demand data.

Description

Technical Field

[0001] This invention relates to the field of robot management methods and systems, and specifically to a robot management method and system based on a dual registration mechanism. Background Technology

[0002] In traditional and most current smart manufacturing scenarios, robot swarm scheduling systems or scheduling software, scheduling strategies, and scheduling mechanisms are characterized by isolated components. Specifically, mobile robot scheduling systems (WMS / WCS), robot control systems (RCS), human management platforms (MES), and drone inspection systems are usually provided by different vendors, each with its own independent control logic, communication protocols, and databases. They interact with each other through limited, predefined interfaces, resulting in extremely poor collaboration capabilities and a significant island effect.

[0003] Management mechanisms based on the assumption of homogeneous capabilities—that is, assuming all devices have the same capabilities—for example, robot scheduling management assumes all vehicles have the same load capacity, speed, and battery type; robot path planning assumes all robots and robotic arms have the same working range and technical parameters. This severely limits the upper limit of system optimization and the full utilization of resources.

[0004] Centralized control, a central scheduling system or software platform, requires knowledge of all operational details (such as the exact status, location, and task progress of each device) and the planning of action instructions accurate to the second. This leads to significant risks, such as the central scheduler crashing and the entire production coming to a standstill.

[0005] The system lacks scalability; adding new equipment or new jobs requires rewriting or extensively modifying the code on the centralized management platform.

[0006] It has weak anti-disturbance capability. When dynamic events such as equipment failure, emergency order insertion, and material delay occur, the central system will recalculate and re-dispatch the order, resulting in slow response speed and heavy calculation burden.

[0007] The disconnect between humans and systems means that people are often excluded from automated systems or interact only through simple terminals (such as barcode scanners or tablets). The system cannot dynamically and intelligently allocate tasks to the most suitable people or machines, and cannot achieve the optimal configuration of "human-machine collaboration". Summary of the Invention

[0008] The technical problem this invention aims to solve is that in traditional systems, upon receiving task instructions, the system needs to assign tasks according to pre-set rules and fixed, matched robots. Such systems have poor scalability and flexibility, and cannot dynamically manage robots and equipment. For example, the online or offline status of equipment can lead to system instability, even loss of some functions. Furthermore, they cannot adapt to the integration of new equipment or robots or the disconnection of old equipment, requiring reprogramming and adaptation. This invention provides a robot management method based on a dual-registration mechanism, and also provides a robot management system based on a dual-registration mechanism, enabling intelligent robot scheduling to adapt to future production needs of multiple varieties, small batches, and high dynamism, thereby overcoming the shortcomings of existing technologies.

[0009] To solve the above-mentioned technical problems, the present invention provides the following technical solutions:

[0010] Firstly, a robot management method based on a dual registration mechanism includes the following steps:

[0011] Obtain task instructions, which include production orders, etc.

[0012] The task instructions are processed to generate service requirement data;

[0013] The service request data is matched with robots based on the dual registration mechanism to generate a request list;

[0014] Send the list of requirements to the corresponding robot;

[0015] The robot receives the matched service request data and executes it.

[0016] The above-mentioned robot management method based on a dual registration mechanism includes the following steps in the demand processing:

[0017] The task instruction is decomposed into multiple sub-tasks. The received task instruction is parsed to become an instruction form that the management system can understand, recognize, and execute. For example, MES sends a production task instruction to process part xx@yytime (this instruction is for illustrative purposes only).

[0018] After constraining, optimizing, and resolving conflicts among the multiple subtasks, the service requirement data is generated. Each subtask is optimized based on factors such as operation type, production process, cycle time requirement, current production line status, and work logic, for example, by prioritizing and adjusting the cycle time. Simultaneously, based on the existing equipment, agents, and production line status, potentially conflicting subtasks are adjusted; this step is called conflict resolution. For example, if two subtasks may conflict with current resources, the priority of one subtask may be readjusted, but this adjustment will not affect the integrity and cycle time requirement of the overall task. After this step, each subtask has been initially configured with clear production parameters, cycle time agreements, resource calls, and other related parameter attributes, and then published.

[0019] The robot management method based on the dual registration mechanism described above, wherein the method for generating the service requirement data by the subtask is as follows:

[0020] Extract key or feature attributes from the subtasks and form semantic expression data, usually in the form of natural language descriptions, to generate robot-recognizable and readable objects. For example, use natural language processing (NLP) technology to extract key fields and feature fields from unstructured text.

[0021] The semantic expression data is structured to generate feature requirements that can fully represent the original sub-tasks, and the feature requirement data is integrated into the service requirement data; for example, key attributes and feature attributes are mapped to JSON fields, and structured generation is performed in the form of tables, or mapped to database table structures. JSON / tables can be parsed by algorithms. For example, attribute types can include input, output, and constraint conditions.

[0022] Input attributes may include, for example, material type, material quantity, tool requirements, preferred tools, safety requirements, etc.

[0023] Output attributes may include, for example, delivery status, target location, etc.

[0024] Constraints may include, for example, cycle time, maximum load, priority, etc.

[0025] Each of the above attributes has a value or a corresponding type.

[0026] The above-mentioned robot management method based on a dual registration mechanism includes the following method for matching robots to the service demand data according to the dual registration mechanism:

[0027] Obtain service demand information recorded in the service demand registration center. The service demand registration center is responsible for registering the service demand information converted from subtasks to indicate service demand.

[0028] The robot capability attribute information recorded in the Agent Registration Center is obtained. The Agent Registration Center is used to register the capability attribute information of the Agent to indicate the capabilities or types of tasks and actions that the robot or Agent has, forming a list of services that can be provided. The information recorded in the Agent Capability Registration Center mainly includes: capability tag registration (including constraint tags), status collection and registration, and prediction / inference engine (capability prediction).

[0029] Specifically, the Agent's capabilities are abstracted using a capability abstraction engine, transforming them into standardized service descriptions that clearly define "what services can be provided." These abstracted capability descriptions are then mapped to a domain ontology, semantic tags are added to support cross-system semantic alignment, and the semantically encoded service descriptions are stored in the Agent registry center. This supports efficient querying and matching. The Agent registry center typically employs a hybrid architecture of "graph database + relational database": the graph database stores semantic relationships (such as service type inheritance and attribute associations) and supports semantic reasoning queries; the relational database stores structured attributes (such as service IDs, performance metrics, and constraint values) and supports fast filtering.

[0030] Based on the service demand information and the robot capability attribute information, the service demand data is matched with the corresponding robot.

[0031] Secondly, a robot management system based on a dual registration mechanism includes an API layer, a unified planning layer, a dual registration service interface layer, a distributed execution layer, and a robot.

[0032] The API layer is used to obtain task instructions;

[0033] The unified planning layer is used to receive the task instructions and process the requirements to generate service requirement data.

[0034] The dual-registration service interface layer is used to perform robot matching on the service request data according to the dual-registration mechanism and generate a request list.

[0035] The distributed execution layer is used to obtain the demand list and send it to the corresponding robot.

[0036] The robot receives the matched service request data and executes it;

[0037] The robot receives the service request data through the communication layer, enabling communication between the system and physical heterogeneous robots or devices, including heterogeneous communication protocols, communication delay compensation, multi-protocol functions, etc.

[0038] From the overall system architecture above, this system interfaces with the factory's MES / ERP platforms to achieve data interaction and enable the issuance of factory production tasks. It also communicates with heterogeneous robots, equipment, and other intelligent agents to issue and assign tasks to relevant robots and equipment.

[0039] In the aforementioned robot management system based on a dual registration mechanism, after the unified planning layer receives the task instruction, it needs to parse and decompose the task instruction. Specifically, after decomposing the task instruction into multiple sub-tasks, it performs constraints, task resource optimization, and conflict resolution on the multiple sub-tasks to generate the service requirement data.

[0040] After receiving the task instruction, the unified planning layer immediately starts the task parsing module. The task parsing module needs to break down the task represented by the instruction, including the parsing and breakdown of the operation actions or links contained in the task, and the parsing and breakdown of the time rhythm. After parsing and breakdown, it is divided into several sub-tasks and supplemented with constraints.

[0041] The robot management system based on the dual registration mechanism described above, wherein the specific process of generating the service requirement data by the subtask is as follows: extracting key attributes or feature attributes from the subtask and forming semantic expression data; performing structured processing on the semantic expression data to generate feature requirement data; and integrating the feature requirement data into the service requirement data.

[0042] The aforementioned robot management system based on a dual registration mechanism includes a dual registration service interface layer that connects to a service demand registration center to obtain service demand information and to an Agent registration center to obtain robot capability attribute information. Based on the service demand information and the robot capability attribute information, the system matches the service demand data with the corresponding robots to generate a demand list, thereby enabling the interface between intelligent agent devices and demand services, or the claiming of service demands.

[0043] From the perspective of system processes and data flow, this system is not much different from traditional robot scheduling or management systems. However, fundamentally, the task parsing and distribution mechanism within the system architecture differs significantly from traditional methods. The main difference lies in converting production tasks into demand services and finding or matching suitable service agents to undertake these services; the internal logic and philosophy have been transformed. Based on this philosophy, many problems that are difficult to solve in traditional systems are easily resolved here, or even cease to be problems at all.

[0044] Thirdly, a chip comprising: a processor for retrieving and running a computer program from a memory, causing a device having the chip mounted to perform: the method as described in any of the first aspects.

[0045] Fourthly, a computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when executed by a processor, the computer program implements the steps of the method described in any one of the first aspects.

[0046] The technical solution provided by the robot management method and system based on the dual registration mechanism of the present invention has the following technical effects:

[0047] It allows intelligent devices such as robots to dynamically go online and offline without affecting the overall system scheduling; the task order distribution response speed is faster, and the overall system efficiency is higher; it enables dynamic management of heterogeneous robots and related equipment in manufacturing scenarios, from task parsing, task planning to task assignment and task execution; the system architecture can realize flexible and dynamic operations such as device access, device disconnection, and task distribution without significantly adjusting the underlying resources or even rewriting the system's software code, adapting to the highly flexible needs of manufacturing production lines. Attached Figure Description

[0048] Figure 1 This is a flowchart of a robot management method based on a dual registration mechanism according to the present invention;

[0049] Figure 2 This is a flowchart of a robot management method based on a dual registration mechanism according to the present invention, which performs robot matching based on the dual registration mechanism for service demand data;

[0050] Figure 3 This is a schematic diagram of the structure of a robot management system based on a dual registration mechanism according to the present invention.

[0051] The reference numerals in the attached figures are as follows:

[0052] API layer 100, unified planning layer 200, dual registration service integration layer 300, distributed execution layer 400, robot 500, communication layer 600. Detailed Implementation

[0053] In order to make the technical means, inventive features, objectives and effects of the invention easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to specific illustrations. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0054] Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0055] It should be noted that the structures, proportions, sizes, etc., illustrated in the accompanying drawings of this specification are only used to complement the content disclosed in the specification for those skilled in the art to understand and read, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0056] Furthermore, the terms such as "upper," "lower," "left," "right," "middle," and "one" used in this specification are merely for clarity of description and are not intended to limit the scope of the invention. Any changes or adjustments to their relative relationships, without substantially altering the technical content, should also be considered within the scope of the invention.

[0057] like Figure 1-2 As shown, in a first aspect, a first embodiment, a robot management method based on a dual registration mechanism includes the following steps:

[0058] Obtain task instructions, which include production orders, etc.

[0059] Process task instructions to generate service requirement data;

[0060] Based on the dual registration mechanism, the service demand data is matched with 500 robots to generate a demand list;

[0061] Send the list of requirements to the corresponding robot 500;

[0062] Robot 500 receives and executes the matched service request data.

[0063] The demand processing includes the following steps:

[0064] The task instruction is decomposed into multiple sub-tasks. The received task instruction is parsed and transformed into an instruction form that the management system can understand, recognize, and execute. For example, MES sends a production task instruction to process part xx@yytime (this instruction is for illustrative purposes only).

[0065] After constraining, optimizing, and resolving conflicts among multiple subtasks, service requirement data is generated. Each subtask is then optimized based on factors such as operation type, production process, cycle time requirements, current production line status, and operational logic, including priority ranking and cycle time adjustment. Simultaneously, based on existing equipment, agents, and production line status, potentially conflicting subtasks are adjusted; this step is called conflict resolution. For example, if two subtasks may conflict with current resources, the priority of one subtask may be readjusted, but this adjustment will not affect the integrity and cycle time requirements of the overall task. After this step, each subtask has been initially configured with clear production parameters, cycle time agreements, resource calls, and other related parameter attributes, and then published.

[0066] The method for generating service requirement data for subtasks is as follows:

[0067] Extract key or feature attributes from subtasks and form semantic representation data, usually in the form of natural language descriptions, to generate objects that the robot can recognize and read. For example, use natural language processing (NLP) technology to extract key fields and feature fields from unstructured text.

[0068] Structural processing is performed on semantic expression data to generate feature requirements that can fully represent the original sub-tasks, and the feature requirement data is integrated into service requirement data; for example, key attributes and feature attributes are mapped to JSON fields, and structured generation is performed in the form of tables, or mapped to database table structures. JSON / tables can be parsed by algorithms. For example, attribute types can include input, output, and constraint conditions.

[0069] Input attributes may include, for example, material type, material quantity, tool requirements, preferred tools, safety requirements, etc.

[0070] Output attributes may include, for example, delivery status, target location, etc.

[0071] Constraints may include, for example, cycle time, maximum load, priority, etc.

[0072] Each of the above attributes has a value or a corresponding type.

[0073] like Figure 2 As shown, the method for matching service demand data with bots based on the dual registration mechanism is as follows:

[0074] Obtain service requirement information recorded in the service requirement registry. The role of the service requirement registry is to register the service requirement information transformed from subtasks to indicate service requirements.

[0075] The Agent Registry obtains the robot 500's capability attribute information recorded in the Agent Registry. The Agent Registry registers the Agent's capability attribute information to indicate the capabilities or types of tasks and actions that the robot 500 or Agent can perform, forming a list of services that can be provided. The information recorded in the Agent Capability Registry mainly includes: capability tag registration (including constraint tags), status collection and registration, and prediction / inference engine (capability prediction).

[0076] Specifically, the Agent's capabilities are abstracted using a capability abstraction engine, transforming them into standardized service descriptions that clearly define "what services can be provided." These abstracted capability descriptions are then mapped to the domain ontology, semantic tags are added to support cross-system semantic alignment, and the semantically encoded service descriptions are stored in the Agent registry center. This supports efficient querying and matching. The Agent registry center typically employs a hybrid architecture of "graph database + relational database": the graph database stores semantic relationships (such as service type inheritance and attribute associations) and supports semantic reasoning queries; the relational database stores structured attributes (such as service IDs, performance metrics, and constraint values) and supports fast filtering.

[0077] Based on the service demand information and the capability attribute information of Robot500, the service demand data is matched with the corresponding Robot500.

[0078] The capabilities of an agent may change with its state (such as failure, low battery, or recovery after maintenance). Registration information is updated through a heartbeat mechanism or event triggering. Event triggering update: When an agent fails, it actively sends a "capability unavailable" event. The system marks its service as "offline" and notifies the requester to re-match. After successful registration in two registry centers, the remaining task is to match service requirements with capability information to complete the corresponding task order dispatch.

[0079] After the service requirement is generated, the system needs to match intelligent agent services that meet the constraints in the Agent registry center. The process includes four steps: "semantic retrieval → constraint filtering → multi-objective optimization → matching verification".

[0080] Semantic retrieval; service type matching based on ontology; there are two main matching methods used: ontology subclass reasoning: matching the type of the requested service with the type of the registered service through ontology inheritance relationship; or, using graph database language to retrieve semantically matched services.

[0081] Constraint filtering: Based on the input / output constraints of the demand service and the service constraints of the registered agent, services that do not meet the conditions are filtered out. For example, services that violate the "must be met" condition are excluded; and filtering methods are sorted by priority.

[0082] Multi-objective optimization: For services that violate the "must be met" condition, calculate the comprehensive score based on multiple objectives to generate the optimal candidate list. For example, a machine learning model can be used to train a regression model based on historical data to predict the "comprehensive score" of the service (e.g., 0-1 points, the higher the better).

[0083] Matching and Validation: After matching a candidate service, the feasibility of the service is verified by combining the agent's real-time status (such as current location and battery level), and an executable service instance is generated. The latest status of the agent can be queried using real-time status queries, or the service execution window can be calculated and matched using dynamic constraint solving.

[0084] Matching is not the end point. Feedback is needed to optimize the requirement description, agent capabilities, and matching strategy, forming a closed loop of "matching → execution → feedback → optimization".

[0085] like Figure 3 As shown, in a second aspect, a second embodiment, a robot management system based on a dual registration mechanism, comprising an API layer 100, a unified planning layer 200, a dual registration service interface layer 300, a distributed execution layer 400, and a robot 500.

[0086] API layer 100 is used to obtain task instructions;

[0087] The unified planning layer 200 is used to receive task instructions and process requirements to generate service requirement data;

[0088] The dual-registration service interface layer 300 is used to perform robot matching on service request data according to the dual-registration mechanism and generate a request list.

[0089] The distributed execution layer 400 is used to obtain and send the demand list to the corresponding robot 500;

[0090] Robot 500 receives and executes the matched service request data.

[0091] Robot 500 receives service request data through communication layer 600, enabling communication between the system and robot 500 or the device, including heterogeneous communication protocols, communication delay compensation, multi-protocol functions, etc.

[0092] From the overall system architecture above, this system interfaces with the factory's MES / ERP platforms to achieve data interaction and enable the issuance of factory production tasks. It also communicates with heterogeneous robots, equipment, and other intelligent agents to issue and assign tasks to relevant robots and equipment.

[0093] Among them, after receiving the task instruction, the unified planning layer 200 needs to parse and decompose the task instruction. Specifically, after decomposing the task instruction into multiple sub-tasks, constraints are applied to the multiple sub-tasks, task resources are optimized, and conflicts are resolved, and then service requirement data is generated.

[0094] After receiving the task instruction, the unified planning layer 200 immediately starts the task parsing module. The task parsing module needs to break down the task represented by the instruction, including the parsing and breakdown of the operation actions or links contained in the task, and the parsing and breakdown of the time rhythm. After parsing and breakdown, it is divided into several sub-tasks and supplemented with constraints.

[0095] The specific process of generating service requirement data from subtasks is as follows: extract key attributes or feature attributes from subtasks and form semantic expression data; perform structured processing on the semantic expression data to generate feature requirement data; and integrate the feature requirement data into service requirement data.

[0096] Among them, the dual-registration service docking layer 300 connects with the service demand registration center to obtain service demand information and connects with the Agent registration center to obtain robot 500 capability attribute information. Based on the service demand information and robot 500 capability attribute information, it matches the service demand data with the corresponding robot 500, generates a demand list, and realizes the docking of intelligent agent devices with demand services or the claiming of service demands.

[0097] From the perspective of system processes and data flow, this system is not much different from traditional robot scheduling or management systems. However, fundamentally, the task parsing and distribution mechanism within the system architecture differs significantly from traditional methods. The main difference lies in converting production tasks into demand services and finding or matching suitable service agents to undertake these services; the internal logic and philosophy have been transformed. Based on this philosophy, many problems that are difficult to solve in traditional systems are easily resolved here, or even cease to be problems at all.

[0098] In a third aspect, a third embodiment, a chip includes: a processor for calling and running a computer program from a memory, causing a device on which the chip is mounted to perform: any of the methods in the first aspect.

[0099] Fourth aspect, fourth embodiment, a computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the steps of any of the methods in the first aspect.

[0100] For example, memory may include random access memory, flash memory, read-only memory, programmable read-only memory, non-volatile memory, or registers, etc.

[0101] The processor can be a central processing unit (CPU) or a graphics processing unit (GPU). The memory can store executable instructions.

[0102] The processor can execute instructions stored in memory to implement the various processes described in this paper.

[0103] It is understood that the memory in this embodiment can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0104] The non-volatile memory can be ROM (Read-Only Memory), PROM (Programmable ROM), EPROM (Erasable PROM), EEPROM (Electrically Erasable EPROM), or flash memory.

[0105] Volatile memory can be RAM (Random Access Memory), which is used as an external cache;

[0106] By way of example, but not limitation, many forms of RAM are available, such as SRAM (Static RAM), DRAM (Dynamic RAM), SDRAM (Synchronous DRAM), DDR SDRAM (Double Data Rate SDRAM), ESDRAM (Enhanced SDRAM), SLDRAM (Synchlink DRAM), and DRRAM (Direct Rambus RAM). The memories described herein are intended to include, but are not limited to, these and any other suitable types of memory.

[0107] In some implementations, the memory stores elements such as upgrade packages, executable units, or data structures, or subsets thereof, or extended sets thereof: operating systems and applications;

[0108] The operating system, which includes various system programs such as the framework layer, core library layer, and driver layer, is used to implement various basic business functions and handle hardware-based tasks.

[0109] Applications, encompassing various applications, are used to implement various application services. Programs implementing the methods of the embodiments of this invention can be included within these applications.

[0110] Those skilled in the art will understand 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 software and electronic hardware.

[0111] Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution.

[0112] Those skilled in the art can implement the described functions in different ways for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0113] In the embodiments of this application, the disclosed systems, apparatus and methods can be implemented in other ways;

[0114] For example, the division of units or modules is only a logical functional division, and there may be other division methods in actual implementation;

[0115] For example, multiple units, modules, or components can be combined or integrated into another system;

[0116] In addition, each functional unit or module in the embodiments of this application can be integrated into a processing unit or module, or it can exist as a separate physical entity, etc.

[0117] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0118] If the function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a machine-readable storage medium.

[0119] Therefore, the technical solution of this application can be embodied in the form of a software product, which can be stored in a machine-readable storage medium and may include several instructions to cause an electronic device to execute all or part of the process of the technical solution described in the embodiments of this application.

[0120] The aforementioned storage media may include various media capable of storing program code, such as ROM, RAM, removable disk, hard disk, magnetic disk, or optical disk.

[0121] In summary, the robot management method and system based on a dual registration mechanism of the present invention allows robots and other intelligent devices to dynamically operate online and offline without affecting the overall system scheduling; the task order distribution response speed is faster, and the overall system efficiency is higher; it enables dynamic management of heterogeneous robots and related equipment in manufacturing scenarios, from task parsing and planning to task assignment and execution; the system architecture enables flexible and dynamic operations such as device access, device disconnection, and task distribution without significant adjustments to underlying resources or even extensive modifications to the system's software code, adapting to the highly flexible needs of manufacturing production lines.

[0122] The specific embodiments of the invention have been described above. It should be understood that the invention is not limited to the specific embodiments described above, and the devices and structures not described in detail should be understood to be implemented in a manner common to the art; those skilled in the art can make various modifications or alterations within the scope of the claims, and make several simple deductions, variations or substitutions, which do not affect the substantive content of the invention.

Claims

1. A robot management method based on a dual registration mechanism, characterized in that, Includes the following steps: Get task instructions; The task instructions are processed to generate service requirement data; The service request data is matched with robots based on the dual registration mechanism to generate a request list; Send the list of requirements to the corresponding robot; The robot receives the matched service request data and executes it.

2. The robot management method based on a dual registration mechanism according to claim 1, characterized in that, The demand processing includes the following steps: The task instruction is decomposed into multiple sub-tasks; After constraining, optimizing, and resolving conflicts among the multiple subtasks, the service requirement data is generated.

3. The robot management method based on a dual registration mechanism according to claim 1, characterized in that, The method for generating the service requirement data in the subtask is as follows: Extract key attributes or feature attributes from the subtasks and form semantic representation data; The semantic expression data is structured to generate feature requirement data; The aforementioned feature requirement data is integrated into the aforementioned service requirement data.

4. The robot management method based on a dual registration mechanism according to claim 1, characterized in that, The method for matching the service demand data with robots based on the dual registration mechanism is as follows: Obtain service request information recorded in the service request registry; Obtain robot capability attribute information recorded in the Agent registry center; Based on the service demand information and the robot capability attribute information, the service demand data is matched with the corresponding robot.

5. A robot management system based on a dual registration mechanism, characterized in that, It includes an API layer, a unified planning layer, a dual-registration service integration layer, a distributed execution layer, and a robot; The API layer is used to obtain task instructions; The unified planning layer is used to receive the task instructions and process the requirements to generate service requirement data. The dual-registration service interface layer is used to perform robot matching on the service request data according to the dual-registration mechanism and generate a request list. The distributed execution layer is used to obtain the demand list and send it to the corresponding robot. The robot receives the matched service request data and executes it.

6. A robot management system based on a dual registration mechanism according to claim 5, characterized in that, The unified planning layer is used to decompose the task instruction into multiple sub-tasks, and then constrain, optimize, and resolve conflicts among the multiple sub-tasks to generate the service requirement data.

7. A robot management system based on a dual registration mechanism according to claim 6, characterized in that, The specific process of generating the service requirement data in the subtask is as follows: extract key attributes or feature attributes from the subtask and form semantic expression data; perform structured processing on the semantic expression data to generate feature requirement data; integrate the feature requirement data into the service requirement data.

8. A robot management system based on a dual registration mechanism according to claim 5, characterized in that, The dual-registration service interface layer connects to the service demand registration center to obtain service demand information and connects to the Agent registration center to obtain robot capability attribute information. Based on the service demand information and the robot capability attribute information, the layer matches the service demand data with the corresponding robots to generate a demand list.

9. A chip, characterized in that, Includes: a processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform: the method as described in any one of claims 1-4.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1-4.

Images