Graphical and modular task arrangement system and method for intelligent robot

Abstract

The invention discloses an intelligent robot-oriented graphical and modular task arrangement system and method, and provides a comprehensive software framework integrating graphical task arrangement, modular packaging, low-code development and visual debugging functions. According to the core technical scheme, a clear layered system architecture covers user interaction, task execution, a core framework and bottom layer driving; a set of standardized module packaging mechanism is used for separating the appearance, interaction control and core operation logic of the module and defining a unified life cycle management model; and an efficient data exchange mechanism taking the data blackboard as the center. Compared with the prior art, the method has the advantages that the threshold for non-professional technicians to use robots is remarkably reduced, and meanwhile, the efficiency for professional research and development personnel to develop, deploy and maintain new function modules is greatly improved, so that the expandability, maintainability and market competitiveness of the whole robot system are enhanced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of robots, and in particular to a graphical modular task arrangement system and method for intelligent robots. BACKGROUND

[0002] With the development of artificial intelligence and automation technology, intelligent robots are increasingly widely used in manufacturing, logistics, medical treatment, services and other fields. However, the development and deployment process of robot application still faces severe challenges, which limits its wider and more efficient popularization. The existing technology mainly has the following pain points:

[0003] 1. High threshold of traditional development mode: The construction of robot behavior logic highly depends on professional code writing. This mode has a steep learning curve and a high threshold for on-site debugging engineers or front-line technical personnel who lack deep programming background. This makes it difficult for them to directly participate in the rapid assembly of robot tasks, on-site logic adjustment, and intuitive understanding of complex robot behavior.

[0004] 2. Complex and non-intuitive debugging process: The code-level debugging process is often complex and lacks visual support, making it difficult for non-professional users to quickly understand the real-time execution status and internal logic of robot tasks. This seriously limits the ability to diagnose, respond quickly and efficiently handle unexpected situations on site.

[0005] 3. Low efficiency of professional development and deployment: For professional robot development engineers, it is time-consuming and laborious to write, test and deploy new functional modules from scratch. In the case of varied robot application scenarios, frequent task logic adjustments or a large number of repetitive operations, the maintenance cost of traditional code is high, and the iteration efficiency is low, which is prone to errors.

[0006] Lack of a unified standardized development framework: The existing robot development tool chain generally lacks a unified standardized framework that supports rapid development of new functional modules and integration into a visual interface. This makes it difficult for development engineers to achieve rapid development and deployment when providing customized robot capabilities for new scenarios, thereby affecting the delivery cycle and market competitiveness of the entire robot solution.

[0007] Therefore, a better way is needed to solve the above problems in the industry. SUMMARY

[0008] Therefore, the present application proposes a graphical modular task arrangement system and method for intelligent robots, which standardizes the encapsulation of complex robot capabilities through a low-code framework and presents them to users in a visual manner, thereby realizing the rapid construction, efficient execution and convenient maintenance of task flow. The technical solution of the present application is as follows:

[0009] In one aspect, the application discloses a graphical modular task arrangement system for intelligent robots, comprising the following hierarchical architecture:

[0010] A user layer configured to receive graphical task assembly instructions of a debugging user and task orders of a manufacturing execution system;

[0011] A software layer comprising a task center and a graphical renderer, the task center being configured to parse task orders and match instruction scheme groups; the graphical renderer being configured to provide a module toolbox, a splicing palette and a running control interface;

[0012] An execution layer comprising a graphical module parsing executor and an instruction scheme group, the graphical module parsing executor being configured to parse instruction schemes and generate module instance sequences; the instruction scheme group being configured to store a plurality of task instruction schemes configured by a user;

[0013] A framework layer comprising a low-code framework system, a module library and a data blackboard, the low-code framework system being configured to manage module extension and information provision; the module library being configured to store standardized module definitions; the data blackboard being configured to realize runtime data sharing;

[0014] A driving layer configured to encapsulate the underlying functions of a database, a robot action library, a communication interface, sensor data, a warehouse position management and an operation library.

[0015] Specifically, the graphical renderer realizes graphical assembly of robot tasks through drag, connection and parameter configuration operations, and integrates debugging control functions.

[0016] Specifically, the data blackboard comprises:

[0017] A data read-write API interface configured to support decoupled data access between components;

[0018] A data serialization / deserialization mechanism configured to realize standardized conversion of structured data;

[0019] A data storage module configured to persistently save system parameters and runtime states.

[0020] Specifically, the module library stores modules including appearance settings, control settings and running period management rules.

[0021] Specifically, the running period management of the module comprises the following states executed in sequence:

[0022] Reading appearance settings, reading control settings, initializing content, waiting for content, executing content, state branching and leaving content.

[0023] Specifically, the graphic module parser comprises:

[0024] The parser is configured to perform data parsing of the instruction scheme, module metadata retrieval, parameter writing to the data blackboard, and logic assembly.

[0025] The executor is configured to schedule the instantiation module sequence according to preselected rules and feed back the running state to the application layer in real time.

[0026] Specifically, the low-code framework system supports encapsulating the driving layer functions as visual modules and realizing rapid deployment through the module library.

[0027] Another aspect of the present application discloses a method of a graphical modular task arrangement system for intelligent robots, comprising the following steps:

[0028] S1, receiving the module dragging, connection and parameter configuration operations of the user through the graphic renderer, and generating an instruction scheme;

[0029] S2, the task center parses the task order and matches the corresponding scheme from the instruction scheme group;

[0030] S3, the graphic module parser loads the module library definition, parses the instruction scheme and instantiates the module logic sequence;

[0031] S4, the executor schedules the module instances according to the preselected rules and reads and writes the runtime data through the data blackboard;

[0032] S5, feeding back the task execution state to the application layer interface in real time.

[0033] Specifically, the module instantiation process comprises:

[0034] The appearance setting and the control setting are extracted from the module library; the parameter data is generated according to the user configuration and written into the data blackboard; the logic assembly is completed based on the module connection relationship to form an executable sequence.

[0035] Specifically, the execution stage supports the debugging function, which comprises:

[0036] The breakpoint pause, single-step execution and variable real-time monitoring are triggered through the running control interface; the flow is dynamically adjusted according to the state branch feedback of the executor.

[0037] The advantages of the present application are as follows:

[0038] 1. Revolutionarily reduce the use threshold: through the intuitive graphical interface and the "building block" type task arrangement mode, the on-site engineers without professional programming background can also quickly understand, construct and adjust the complex robot task logic, and the creation right of the robot application is decentralized from a few experts to a wider user.

[0039] 2. Significantly improve development and deployment efficiency: Standardized module packaging paradigm and life cycle management enable professional developers to quickly develop, test and release new functional modules. The high reusability of modules avoids repeated "wheel building", greatly shortening the development cycle and time to market of new applications.

[0040] 3. Enhance system maintainability and debugging capability: Clear module life cycle state management, combined with visual debugging tools (breakpoints, single-step execution, variable monitoring), enables the system to quickly and accurately locate the source of the problem when problems occur. Modular design also makes it easy to repair or replace individual functional modules without affecting other parts of the system, greatly improving the overall robustness and maintainability of the system. BRIEF DESCRIPTION OF DRAWINGS

[0041] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiment or prior art description. Obviously, the drawings in the following description are only one embodiment of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0042] Figure 1 The overall system execution flow architecture diagram in the embodiment of the present application;

[0043] Figure 2 The internal component and data flow diagram of the low-code framework system in the embodiment of the present application;

[0044] Figure 3 The module packaging and life cycle management mechanism diagram in the embodiment of the present application. DETAILED DESCRIPTION

[0045] The technical solutions of the present application will be described in detail below with reference to the embodiments of the present application and the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, not all embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of the present application.

[0046] Unless otherwise defined, all technical and scientific terms used in the present application have the same meaning as understood by those skilled in the art to which the present application belongs; the terms used in the specific embodiments are only for the purpose of describing the specific embodiments, not intended to limit the present application; the terms "include" and "have" in the specification and claims of the present application and the above description of drawings are intended to cover non-exclusive inclusion.

[0047] In the description of the specific embodiments of the present application, the technical terms "first", "second", and the like are only used to distinguish different objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order or primary and secondary relationship of the indicated technical features. In the description of the embodiments of the present application, the meaning of "a plurality of" is more than two, unless otherwise explicitly and specifically limited.

[0048] In the present application, the phrase "embodiments" means that the specific features, structures or properties described in conjunction with the embodiments can be included in at least one embodiment of the present application. The appearance of this phrase at various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment to other embodiments. It is explicitly and implicitly understood by those skilled in the art that the described embodiments of the present application can be combined with other embodiments.

[0049] In the description of the embodiments of the present application, the term "and / or" is only a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the three cases of A alone, A and B together, and B alone. In addition, the character " / " in the present application generally represents an "or" relationship between the associated objects before and after it.

[0050] It should be noted that, for ease of description, in the following embodiments, all the same technical features are marked with the same symbol.

[0051] With the development of artificial intelligence and automation technology, intelligent robots are increasingly widely used in manufacturing, logistics, medical care, services and other fields. However, the development and deployment process of robot application still faces severe challenges, which limit its wider and more efficient popularization. The existing technology mainly has the following pain points:

[0052] 1. High threshold of traditional development mode: The construction of robot behavior logic highly depends on professional code writing. This mode has a steep learning curve and a high threshold for on-site debugging engineers or front-line technical personnel who lack deep programming background. This makes it difficult for them to directly participate in the rapid assembly of robot tasks, on-site logic adjustment, and intuitive understanding of complex robot behavior.

[0053] 2. Complex and non-intuitive debugging process: The code-level debugging process is often complex and lacks visual support, making it difficult for non-professional users to quickly understand the real-time execution status and internal logic of robot tasks. This seriously limits the ability to diagnose, respond quickly and efficiently handle unexpected situations on site.

[0054] 3. Low efficiency of professional development and deployment: For professional robot R&D engineers, it is time-consuming and laborious to write, test and deploy new functional modules from scratch. In the case of varied robot application scenarios, frequent adjustment of task logic or a large number of repetitive operations, the maintenance cost of traditional code is high, and the iteration efficiency is low, which is prone to introduce errors.

[0055] Lack of unified standardized development framework: The existing robot development tool chain generally lacks a unified standardized framework that supports rapid development of new functional modules and integration into a visual interface. This makes it difficult for R&D engineers to achieve rapid development and deployment when providing customized robot capabilities for new scenarios, thereby affecting the delivery cycle and market competitiveness of the entire robot solution.

[0056] Therefore, there is an urgent need in the industry for a better way to solve the above problems.

[0057] In view of this, the present application provides a graphical modular task arrangement system and method for intelligent robots, which standardizes the encapsulation of complex robot capabilities through a low-code framework and presents them to users in a visual manner, thereby achieving rapid construction, efficient execution and convenient maintenance of task processes.

[0058] Embodiments

[0059] In one aspect, the present application discloses a graphical modular task arrangement system for intelligent robots, comprising the following layered architecture:

[0060] The user layer is configured to receive graphical task assembly instructions of a debugging user and task orders of a manufacturing execution system;

[0061] Specifically, the user layer represents an external entity or user role that interacts directly with the execution system, wherein:

[0062] Debugging (user role): The user assembles robot functions through the graphical interface displayed by the graphical renderer, and debugs and writes tasks for robot functions using breakpoints and other running control functions according to real-time running status and running data; finally, the configured functions are put into the software center.

[0063] MES (Manufacturing Execution System): As an external system, it sends "task orders" to the task center to start the automation process.

[0064] The software layer includes a task center and a graphical renderer, the task center is configured to parse task orders and match instruction scheme groups, and the graphical renderer is configured to provide a module toolbox, a splicing palette and a running control interface.

[0065] Specifically, the software layer is the application interface and high-level logic processing part, responsible for user interaction and task management, wherein:

[0066] Task Center: Receives "task order" from MES to match the corresponding "configuration task" bound to the debugging user. It is responsible for receiving automation tasks and parsing into specific action groups to ultimately call the corresponding instruction scheme.

[0067] Running Status Display: Receives "status updates" from the graphical module parsing executor, and shows the user the execution progress and status of the robot task in real time.

[0068] Graphical Renderer: Receives the current visualization module group of the low-code framework system, provides module toolbox, module splicing board, module running control, etc. Functional interface, responsible for presenting graphical modules and task flows on the user interface, and receiving start, stop, power-off execution, etc. Control commands from the debugging user; to assist in the development and debugging of the graphical interface, and ultimately form a specific instruction scheme.

[0069] Execution layer, including graphical module parsing executor and instruction scheme group, graphical module parsing executor, configured to parse instruction schemes and generate module instance sequences; instruction scheme group, configured to store multiple task instruction schemes configured by the user;

[0070] Specifically, the execution layer is the core running engine of the system, responsible for parsing and actually executing robot tasks, including:

[0071] Graphical module parsing executor: This is the core of the execution layer, which receives specific instruction schemes; it is responsible for parsing the logic of graphical modules, loading module libraries, instantiating module logic, and ultimately scheduling execution; and feeding back "status updates" during execution to the running status display. This function is provided by the low-code framework system.

[0072] Instruction scheme: represents a specific task instruction scheme, which is completed by the user in real-time debugging in the "graphical renderer".

[0073] Instruction scheme group: as a collection of instruction schemes, it stores multiple task instruction schemes that can be selected or executed. The task center issues "select task" instructions to it to select the scheme to be executed. The selected "instruction scheme" is sent to the graphical module parsing executor for execution.

[0074] Framework layer, including low-code framework system, module library and data blackboard, low-code framework system, configured to manage module extension and information provision; module library, configured to store standardized module definitions; data blackboard, configured to realize runtime data sharing;

[0075] Specifically, the framework layer is the basic infrastructure and core components, providing support for upper-layer applications and execution, including:

[0076] Module: represents an executable unit encapsulated by a module. After compilation, the module is stored in the module library as an independent component and can be extended and called by the low-code framework system. The module abstractly encapsulates the underlying functions, which are logically assembled and instantiated by the parser, and finally executed by the executor.

[0077] Module library: as a centralized repository of all reusable modules, the module library stores module definitions, interface specifications, and metadata, supports the parser to dynamically retrieve module information, and meets different execution demand scenarios. At the same time, it provides module styles and help information to the application layer, supports graphical display and interaction of modules.

[0078] Low-code framework system: as the core management component of the framework layer, it is responsible for module extension management and unified provision of module information, supports the parser to perform module analysis, logical assembly, and instance scheme generation. At the same time, it provides module graphical data for the software layer, supports the visual display of modules in the user interface, and promotes the efficient operation of the low-code development process.

[0079] Driver layer, configured to encapsulate the underlying functions of database, robot action library, communication interface, sensor data, warehouse management, and operation library.

[0080] Specifically, the driver layer represents the abstraction of the robot's underlying hardware and software interface, and its specific functions can be "encapsulated" by modules, including:

[0081] Database, robot action library, communication, sensor data, warehouse management, operation library: these components represent various underlying driver functions such as robot control, data management, communication, perception, and algorithms. Through the standard graphical "encapsulation" provided by the low-code framework, their capabilities can be quickly encapsulated into visual and executable modules, so that the upper-layer application does not need to directly interact with complex underlying interfaces, but only needs to call the corresponding modules.

[0082] In an implementable embodiment, as shown in Figure 1 The system adopts a clear layered architecture design, ensuring clear responsibilities and high decoupling of each part, thereby improving the stability and scalability of the system. The architecture is divided into five layers from top to bottom:

[0083] User layer: the direct user of the system, including field engineers who perform task scheduling and debugging, and interfaces that issue automation tasks through external systems (such as MES).

[0084] Software layer: responsible for user interaction and high-level task management. Its core component, the graphical renderer, provides a visual "canvas" where users can build task flows by dragging and dropping modules. The task center is responsible for receiving and analyzing task orders from external systems such as MES.

[0085] Execution layer: the core running engine of the system. Its core component, the graphic module parsing executor, receives the "instruction scheme" generated by the software layer, and is responsible for parsing task logic, instantiating modules, and scheduling execution.

[0086] Framework layer: provides modular core support for the entire system. Its core is the low-code framework system, which manages all reusable module libraries and provides a data blackboard as a data exchange center within the system. This layer is the cornerstone of low-code development and efficient execution.

[0087] Driver layer: the final abstraction of the robot's underlying hardware and software interface. It includes robot action library, sensor data interface, communication protocol, database, etc. The framework layer "wraps" these complex underlying functions into standardized graphic modules that can be directly called on the upper layer through standardized packaging rules.

[0088] This layered architecture realizes a clear mapping from user intent to underlying execution. Users perform high-level logic arrangement in the software layer without worrying about the complex implementation details of the execution layer, framework layer, and driver layer, thus achieving effective separation of development, execution, and underlying driving.

[0089] In an implementable embodiment, the graphic renderer realizes the graphical assembly of robot tasks through drag-and-drop, connection, and parameter configuration operations, and integrates debugging control functions.

[0090] In an implementable embodiment, the data blackboard includes:

[0091] Data read-write API interface configured to support decoupled data access between components;

[0092] Data serialization / deserialization mechanism configured to realize standardized conversion of structured data;

[0093] Data storage module configured to persistently save system parameters and runtime state.

[0094] In an implementable embodiment, the module library stores modules including appearance settings, control settings, and running period management rules.

[0095] In an implementable embodiment, the running period management of the module includes the following states executed in sequence: reading appearance settings, reading control settings, initializing content, waiting for content, executing content, state branching, and leaving content.

[0096] In an implementable embodiment, the graphic module parsing executor includes:

[0097] Parser configured to perform data parsing of the instruction scheme, module metadata retrieval, parameter writing to the data blackboard, and logic assembly;

[0098] Executor: configured to schedule instantiation module sequence according to pre-selected rules, and feedback running state to application layer in real time.

[0099] In an implementable embodiment, the low-code framework system supports encapsulating the driving layer functions as visual modules, and realizes rapid deployment through the module library.

[0100] Another aspect of the application discloses a method of a graphical modular task arrangement system for intelligent robots, comprising the following steps:

[0101] S1, receiving the module dragging, connection and parameter configuration operations of the user through the graphical renderer, and generating an instruction scheme;

[0102] S2, the task center parses the task order, and matches the corresponding scheme from the instruction scheme group;

[0103] S3, the graphical module parses the executor to load the module library definition, parses the instruction scheme and instantiates the module logic sequence;

[0104] S4, the executor schedules the module instance according to the pre-set rules, and reads and writes the runtime data through the data blackboard;

[0105] S5, real-time feedback of the task execution state to the application layer interface.

[0106] In an implementable embodiment, the module instantiation process includes:

[0107] Extract appearance settings and control settings from the module library; generate parameter data according to user configuration and write into the data blackboard; complete logical assembly based on module connection relationship, and form an executable sequence.

[0108] In an implementable embodiment, the execution stage supports debugging functions including:

[0109] Trigger breakpoint pause, single-step execution and variable real-time monitoring through the running control interface; dynamically adjust the process according to the state branch feedback by the executor.

[0110] As shown in Figure 2 The low-code framework is the technical core of the application, and its internal working mechanism ensures seamless conversion from graphical design to actual execution:

[0111] Parser: When the user finishes task orchestration and clicks "Run", the parser first intervenes. It reads the instruction scheme data generated by the graphical interface, decomposes it into "module data" (which modules need to be called) and "parameter data" (specific values configured by the user for these modules). Then it obtains the complete definition of the corresponding module from the module library, writes the parameter data to the data blackboard, and finally generates an "instance scheme" containing specific module instances and execution order through the "logical assembly" process.

[0112] Module Library: This is a centralized module repository that stores all standardized functional modules. Each module not only contains its core running logic, but also pre-defines its appearance on the graphical interface (style, connection points) and interactive controls (input box, drop-down menu, etc.), as well as its complete life cycle management rules.

[0113] Data Blackboard: This is a global data exchange center that achieves complete decoupling of components within the system. The parser writes user-configured parameters to the blackboard, and the executor reads the required data from the blackboard when running modules, and writes the module output back to the blackboard for subsequent module use. This mechanism avoids direct dependencies between components, greatly enhancing the flexibility and maintainability of the system.

[0114] Instance Plan: A specific task sequence generated by the parser to be executed. It is not a general module definition, but a module collection instantiated according to user-specific requirements, containing all the context information required for running.

[0115] Executor: As the "heart" of the system, the executor obtains the task flow to be executed from the instance scheme and schedules and runs each module instance according to the pre-set rules (such as linear sequential execution, state machine jump, etc.). During execution, it frequently interacts with the data blackboard to obtain and update data, and real-time feedback of each module's running state (success, failure, running, etc.) to the upper application interface for user monitoring and debugging.

[0116] In addition, Figure 2 This paper details how the low-code framework works, including the parser, data blackboard, instance scheme, module library, executor and application layer. It focuses on the internal operation mechanism and data flow of the framework, as follows:

[0117] 1. Parser: Realize the parsing of instruction scheme and instantiate module to form executable sequence.

[0118] Data Parsing: This is the starting point of processing user graphical input (such as dragging, connecting modules). It is responsible for receiving and parsing "instruction scheme data that needs to be executed", splitting the data into parameter data and module data.

[0119] Module Data: After "Data Parsing" is completed, the parser identifies the module type selected by the user and retrieves the metadata of the corresponding module (i.e. module function definition, interface specification, etc.) from the module library.

[0120] Parameter Data: Extract the specific parameter values set by the user for the module from "user-selected data" to form "parameter data". These parameter data are then sent and stored to the data blackboard component through the "write parameter" operation.

[0121] Logic Assembly: According to "module data" and user-defined connection relationship, the parser performs "logic assembly". This process integrates scattered module definitions into a module instantiation executable logic sequence according to the scheme execution method.

[0122] 2、Module Library: A centralized repository of all reusable modules, the module library stores module function implementation, interface metadata and lifecycle management definition. Each module in the module library contains complete appearance settings, control settings and running cycle management rules, supporting standardized encapsulation and reuse of modules. The module library supports dynamic retrieval of module definitions by the parser for user graphical design and process logic assembly. At the same time, the module library provides module styles and module help information to the application layer, supporting the visual display and interaction of modules in the interface.

[0123] Module: Contains the appearance settings, control settings, running logic and lifecycle management rules of the module, supporting the whole process from graphical configuration to running execution of the module.

[0124] Provide module styles and controls to support graphical display of the application layer interface.

[0125] Provide module help information to assist users in understanding module functions and configuration methods.

[0126] Parser: Retrieve module definitions from the module library through the "get corresponding module" operation to complete module instantiation and logic assembly

[0127] 3、Data Blackboard: A centralized data storage and exchange mechanism for realizing data sharing and decoupling between components in the system, supporting different components to access and exchange runtime data in a unified way.

[0128] Data Read / Write: Unified API interface is provided to support runtime read / write operations on data in the blackboard. System parameters and runtime data are accessed through this interface, eliminating the need for direct coupling between components and reducing system complexity. The parser writes parameter data here, and the executor reads data from here to obtain the required runtime data.

[0129] Data Serialization / Deserialization: Standardized conversion of data formats is implemented to support the conversion of complex data structures into a transmissible and storable data format, and the restoration of the original data structure when read, ensuring reliable data transmission and long-term storage between different components.

[0130] Data Storage: Provides physical storage capabilities for persistently saving system parameters, global variables, and runtime state information. Through cooperation with the data serialization / deserialization mechanism, consistency and integrity of data during storage and recovery are ensured.

[0131] 4. Instance Scheme: Stores the instantiated module sequences completed by the "logical assembly" after the parser parses. These "module sequences" are derived from the general module definitions in the module library based on the specific process and configuration created by the user on the graphical interface. They are provided as "scheme data" to the executor, waiting for its scheduling and execution.

[0132] 5. Executor: The core running engine of the low-code framework system, responsible for scheduling and executing module instances according to the user-defined logical order and rules.

[0133] Executor Selection: The type of executor is determined before the execution phase begins. The low-code platform supports multiple executor schemes suitable for different module execution needs, such as using linear executors for sequential process execution, state machine executors for handling state jump logic, and behavior tree executors for implementing behavior pattern-based execution processes.

[0134] Running according to the executor rules: The executor runs according to the selected "executor" running rules during the running phase, executing module instances according to the preset logic. During the running process, the executor supports debugging functions, including start / stop control, breakpoint execution, etc., and real-time feedback of the current running state, execution information, and key data in the running process to the "running state feedback". The executor obtains "scheme data" from the instance scheme and performs necessary parameter and global state read / write through the data blackboard, ensuring data consistency and real-time performance during execution.

[0135] Running state feedback: During the execution of the executor, the current running state will be fed back in real time. The executor makes execution decisions based on this state, such as continuing execution in the success state, suspending the process in the pause state, and triggering exception handling in the error state. At the same time, the executor sends real-time running data to the application layer interface for the interface to display the current running information and data state.

[0136] 6. Application layer: As a graphical user interface for users to interact with the low-code framework.

[0137] Module style: Obtain and display the graphical style and controls of available modules from specific modules.

[0138] Module help information: Obtain and display detailed help documents for modules from modules.

[0139] Running state display: Real-time receive "real-time feedback" from the executor, and show the user the execution progress and results of the robot task.

[0140] Running control: Users can use this interface to perform "start / stop" debugging operations on the executor to control the execution of the robot task.

[0141] In summary, Figure 2 The close cooperation of each component within the low-code framework is meticulously described. The parser is responsible for converting user intent into executable module instances and interacting with the module library and data blackboard. The instance scheme carries the logic flow to be executed. The executor, as the core engine, schedules and executes these instances, manages data through the data blackboard, and provides real-time feedback of the running state to the application layer, realizing a closed loop from low-code development to efficient execution. This fine layering and clear division of responsibilities is the key to the efficiency and scalability of the low-code framework.

[0142] As Figure 3 shown, another major innovation of the present application is the standardized paradigm design of "modules" themselves, ensuring the high consistency and reusability of all functional units. In combination with the Figure 3 , the encapsulation of each module follows the following rules:

[0143] Appearance and control separation: completely separate the "skin" (appearance settings) and "interactive interface" (control settings) of the module from its "soul" (running logic). Developers can independently define the display style of a module on the interface (such as color, icon, connection slot position) and the user input controls it needs to receive (such as text box, number input, drop-down selection, etc.), without needing to handle any UI-related code in the running logic. This modular design philosophy is the key to improving maintainability and reusability.

[0144] Standardized life cycle management: To ensure the predictable and easy-to-manage behavior of all modules, the invention defines a unified "module running cycle". Any module must go through a series of standardized state stages from being loaded to the end of execution, including: reading appearance settings, reading control settings, initializing content, waiting for content, executing content, state branching (success, pause, error), leaving content. When developing new modules, R&D engineers only need to fill in the specific business logic in the corresponding life cycle function, and the framework will automatically manage the state transition. This greatly simplifies the development process and provides a foundation for implementing reliable debugging functions such as breakpoints and single-step execution.

[0145] In addition, Figure 3 The core development and running process of modules in the low-code framework is described in detail, especially how it encapsulates the appearance, controls and running logic of the module, and the life cycle state management of the module during execution, as follows:

[0146] 1. Module appearance settings: Define the visual characteristics of the module on the graphical interface, i.e. the "skin" of the module. These settings are referenced by "reading appearance settings" in the module running cycle management when the module is loaded or created. Mainly including control layout, connection slot configuration, color setting, inline style configuration, help document association, etc., supporting flexible presentation and classification of modules in the interface.

[0147] 2. Module control settings: Define the input and output control types for the module to interact with the user, i.e. the "interactive interface" of the module. These settings are referenced by "reading control settings" in the module running cycle management when the module is loaded or created. Mainly including string controls, number controls, slot controls, drop-down box controls, selection box controls, global variable controls, etc.; provides a variety of preset UI control types for developers to choose from according to module functionality, such as parameter input, data reference, logic branching, etc. For example, "slot control" may be used to receive input from a sub-process, and "drop-down box control" may be used to provide predefined options.

[0148] 3. Module running cycle management: The core management part of the runtime life cycle in the framework. It defines each phase of the module from loading to the end of execution and its state transition. Development engineers need to encapsulate and develop corresponding functional modules according to the corresponding life cycle.

[0149] Read appearance settings: The module life cycle begins by loading its visual properties defined in the module appearance settings.

[0150] Read control settings: Then load the interactive controls defined in the module control settings.

[0151] Initialization: After the module finishes configuring its appearance and controls, it enters the initialization phase, where it allocates necessary resources, loads parameters, or prepares internal states.

[0152] Waiting: The module may enter a waiting state, such as waiting for an external event trigger, dependent data readiness, or waiting for the completion of another module's execution.

[0153] Execution: This is the phase where the module's core business logic runs. The module performs its specific functions here.

[0154] State Branching: After the "Execution" phase, the module enters different states based on the execution results:

[0155] Success: The module's task is successfully completed.

[0156] Pause: The module's execution is temporarily interrupted, waiting for subsequent recovery or termination instructions.

[0157] Error: Problems occur during the module's execution, which may require exception handling or retries.

[0158] Leaving: The final state of the module, indicating that it performs operations such as resource release before the end of its execution cycle.

[0159] Among them, the encapsulation rules and characteristics are as follows;

[0160] 1. Clear separation of responsibilities and encapsulation:

[0161] Appearance and function separation: The low-code framework completely separates the "appearance" (such as color, layout, connection points) and "controls" (such as input boxes, drop-down menus) of the module from its core "running logic". This means that developers can independently define the interface and function implementation of the module when designing the module, without interfering with each other. This encapsulation greatly improves the maintainability and reusability of the module.

[0162] Centralized life cycle management: The entire running life cycle of the module (from configuration reading to execution end, including various state transitions) is uniformly coordinated by "module running cycle management". This ensures the predictability and consistency of the module's behavior.

[0163] 2. Foundation of low-code development:

[0164] Rich interaction methods: By predefining a variety of control types (strings, numbers, slots, drop-down boxes, etc.), appearance settings, the framework allows users to choose different control implementations to interact with users according to different functional requirements.

[0165] Modular combination: The modules have clear connection slot definitions (up and down connection slots, output slots), so that the modules can be easily "assembled" like building blocks, quickly building complex automation processes, greatly improving the speed of logical assembly.

[0166] 3. Runtime state management: The framework defines clear life cycle states (initialization, waiting, execution, success, pause, error, leave) for each module. This allows the system to accurately track the runtime state of each module, facilitating debugging, fault diagnosis, and process control (such as task pausing, resuming, or error handling).

[0167] 4. Standardization of module encapsulation: The framework provides a standardized encapsulation paradigm for module development and integration through its clearly defined "module appearance settings", "module control settings", and "module running cycle management". The development of any new module must follow these preset interfaces and life cycle management rules, greatly simplifying module development, integration, and interoperability, ensuring the unity and robustness of the entire system ecosystem.

[0168] Through the above encapsulation rules and features, the framework achieves high abstraction and standardization of modules, providing users with an intuitive, efficient, and controllable robot application development and running environment.

[0169] The advantages of the present application are as follows:

[0170] 1. Revolutionarily lower the threshold: Through the intuitive graphical interface and "building block" task arrangement method, even field engineers without professional programming background can quickly understand, build and adjust complex robot task logic, decentralizing the creation of robot applications from a few experts to a wider range of users.

[0171] 2. Significantly improve development and deployment efficiency: Standardized module encapsulation paradigm and life cycle management allow professional developers to quickly develop, test and release new functional modules. The high reusability of modules avoids repeated "wheel building", greatly shortening the development cycle and time to market of new applications.

[0172] 3. Enhance the maintainability and debugging ability of the system: Clear module life cycle state management, combined with visual debugging tools (breakpoints, single-step execution, variable monitoring), allows the system to quickly and accurately locate the source of the problem when problems occur. Modular design also makes it easy to repair or replace individual functional modules without affecting other parts of the system, greatly improving the overall robustness and maintainability of the system.

Claims

1. A graphical modular task orchestration system for intelligent robots, characterized in that, Includes the following layered architecture: The user layer is configured to receive graphical task assembly instructions from debugging users and task orders from the manufacturing execution system; The software layer includes a task center and a graphics renderer. The task center is configured to parse task orders and match instruction scheme groups. The graphics renderer is configured to provide a module toolbox, a splicing canvas, and a runtime control interface. The execution layer includes a graphics module parsing executor and an instruction scheme group. The graphics module parsing executor is configured to parse instruction schemes and generate a sequence of module instances. The instruction scheme group is configured to store multiple task instruction schemes configured by the user. The framework layer includes a low-code framework system, a module library, and a data blackboard. The low-code framework system is configured to manage module extensions and information provision; the module library is configured to store standardized module definitions; and the data blackboard is configured to enable runtime data sharing. The driver layer is configured to encapsulate the underlying functions of the database, robot motion library, communication interface, sensor data, storage location management, and computing library.

2. The graphical modular task orchestration system for intelligent robots according to claim 1, characterized in that, The graphics renderer enables the graphical assembly of robot tasks through drag-and-drop, connection, and parameter configuration operations, and integrates debugging and control functions.

3. The graphical modular task orchestration system for intelligent robots according to claim 1, characterized in that, The data blackboard includes: The data read / write API interface is configured to support decoupled data access between components; The data serialization / deserialization mechanism is configured to achieve standardized transformation of structured data; The data storage module is configured to persistently save system parameters and runtime state.

4. A graphical modular task orchestration system for intelligent robots according to claim 1, characterized in that, The module library stores modules including appearance settings, control settings, and runtime management rules.

5. A graphical modular task orchestration system for intelligent robots according to claim 4, characterized in that, The module's runtime management includes the following states executed sequentially: Read appearance settings, read control settings, initialization content, waiting content, execution content, status branch, and exit content.

6. A graphical modular task orchestration system for intelligent robots according to claim 1, characterized in that, The graphics module parsing executor includes: The parser is configured to perform data parsing of the instruction scheme, module metadata retrieval, parameter writing to the data blackboard, and logic assembly. The executor is configured to schedule the sequence of instantiated modules according to pre-selected rules and provide real-time feedback on the running status to the application layer.

7. A graphical modular task orchestration system for intelligent robots according to claim 1, characterized in that, The low-code framework system supports encapsulating driver layer functions as visual modules and enabling rapid deployment through a module library.

8. A method for a graphical modular task orchestration system for intelligent robots as described in any one of claims 1 to 7, characterized in that, Includes the following steps: S1. Receive user module drag-and-drop, connection and parameter configuration operations through the graphics renderer, and generate instruction schemes; S2. The task center parses the task order and matches the corresponding solution from the instruction solution group; S3. The graphics module parser executor loads the module library definition, parses the instruction scheme, and instantiates the module logic sequence; S4. The actuator schedules module instances according to preset rules and reads and writes runtime data through the data blackboard. S5 provides real-time feedback on task execution status to the application layer interface.

9. The method for a graphical modular task orchestration system for intelligent robots according to claim 8, characterized in that, The module instantiation process includes: Extract appearance and control settings from the module library; generate parameter data based on user configuration and write it to the data blackboard; complete logical assembly based on module connection relationships to form an executable sequence.

10. The method for a graphical modular task orchestration system for intelligent robots according to claim 8, characterized in that, Debugging features supported during the execution phase include: The process can be dynamically adjusted based on the status branches fed back by the executor by triggering breakpoints to pause, single-step execution, and real-time variable monitoring through the operation control interface.

Images