A robotic arm task execution method based on low-code configuration

Abstract

The present invention discloses a robotic arm task execution method based on low-code configuration, including defining a status module, which includes the position, pose, kinematic attributes, path constraints, peripheral operations, and exception handling of the robotic arm; creating a low-code task configuration file in YAML or JSON format to represent the hierarchical relationship between different levels of entries; constructing a task tree structure including task arrays or lists, subtasks, status modules and their attributes; defining data structures and node types to convert the text-form task configuration into a data structure that can be processed by a program; parsing the task tree structure configuration in YAML format or JSON format and reading it into a data structure that meets the tree topology structure; executing the task tree data structure, traversing each node, and cooperating with the robotic arm drive to implement task execution operations according to the status module and attributes defined by each node. The present invention simplifies the programming process of robotic arm tasks and improves the flexibility and reliability of task execution.

Description

Technical Field

[0001] The present invention relates to the technical field of mechanical automation control, and specifically to a method for executing robotic arm tasks based on low-code configuration. Background Art

[0002] With the development of industrial automation and intelligent manufacturing, robotic arms have been widely used in multiple fields such as production manufacturing, logistics and warehousing, and medical and health. Traditional methods for executing robotic arm tasks usually rely on professional programmers to write control codes using complex programming languages. This approach not only has a long development cycle and high costs, but also requires a high level of technical expertise from operators, which limits the popularization and application of robotic arms.

[0003] Traditional robotic arm task execution solutions mainly rely on professional programmers to write control codes using complex programming languages. The advantage of this approach is that it can achieve highly customized task execution logic to meet complex and changing industrial requirements. However, its disadvantages are also very obvious: long development cycle, high costs, high technical requirements for operators, which limits the popularization and application of robotic arms. In addition, traditional programming methods are difficult to adapt to rapidly changing production environments and difficult to achieve rapid iteration and updates.

[0004] Existing technical solutions, such as robotic arm task execution methods based on graphical programming, reduce the programming difficulty by providing a visual programming interface, enabling non-professional personnel to perform simple task configurations. However, such solutions often have functional limitations, are difficult to meet the needs of complex tasks, and may be affected in terms of performance and stability when dealing with large-scale and high-concurrency scenarios.

[0005] This technical solution aims to address the deficiencies of the existing technology by introducing a method for executing robotic arm tasks based on low-code configuration. First, the low-code configuration file makes task configuration more intuitive and simple, reduces the requirements for programming skills, and improves the efficiency of task configuration. Second, by organizing tasks into a tree structure, this solution can better manage complex task logic, support hierarchical and modular design of tasks, and improve the maintainability and scalability of tasks. Finally, this solution controls the action sequence of the robotic arm by parsing the configuration file, making task execution more flexible and dynamic, capable of quickly adapting to changes in the production environment, and improving production efficiency and flexibility. Summary of the Invention

[0006] A method for executing robotic arm tasks based on low-code configuration includes the following steps:

[0007] S1. Define a status module, where the status module includes the position, pose, kinematic attributes, path planning constraint conditions of the TCP at the end of the robotic arm, and a status sequence of peripheral operations and exception logic processing that depend on the position and pose before and after.

[0008] S2. Create a low-code task configuration file, which is stored in YAML format or JSON format and is used to represent the hierarchical relationship between entries at different levels.

[0009] S3. Build a task tree structure, which includes a task array or list, subtasks, a status module and its attributes, and uses the tree structure to organize the task configuration.

[0010] S4. Define the data structure and node type, parse and store the tree task configuration sequence of the low-code organization, and convert the text-form task configuration into a data structure that can be processed by the program.

[0011] S5. Parse the low-code task configuration file, read the task tree structure configuration in YAML format or JSON format into the data structure, and the data structure also satisfies the tree topology structure, which is convenient for traversing each node of the task sequence during software execution.

[0012] S6. Execute the task tree data structure, traverse each node in the task tree data structure, and cooperate with the robotic arm drive to implement the task execution operation of the robotic arm according to the status module and attributes defined by each node.

[0013] Preferably, the status module specifically includes: speed and acceleration, joint coordinate system path and Cartesian coordinate system path, pre-execution peripheral operations, post-execution peripheral operations, post-execution time interval, and a status sequence for exception logic processing.

[0014] The speed and acceleration are used to define the speed and acceleration of the robotic arm moving to this position or pose.

[0015] The joint coordinate system path and Cartesian coordinate system path are used to plan the movement path of the robotic arm.

[0016] The pre-execution peripheral operations are used to perform peripheral operations before starting to execute this path point. The peripheral operations include but are not limited to digital input / output operations, trigger type operations, and custom I / O type operations. The peripheral operations also define the number of attempts after the operation fails, the delay time before and after the operation, the status value of the digital input / output, and the specific attributes of the I / O type operation.

[0017] The post-execution peripheral operations are used to perform peripheral operations after this path point is executed. The peripheral operations also include digital input / output operations, trigger type operations, and custom I / O type operations. The peripheral operations also define the number of attempts after the operation fails, the delay time before and after the operation, the status value of the digital input / output, and the specific attributes of the I / O type operation.

[0018] The post-execution time interval uses the time interval after the execution of this path and defines the waiting time after the execution of this path point;

[0019] The state sequence of the exception logic processing is the state sequence for the exception logic processing after the failure of the execution of this state. It jumps to other state modules through goto for recovery operations. The goto jump defines the maximum number of attempts to execute after the exception occurs.

[0020] Preferably, the low-code task configuration file in S2 is stored in YAML format or JSON format. The YAML format stores represent the hierarchical relationship between entries at different levels through indentation; the JSON format stores represent the hierarchical relationship between entries at different levels by being enclosed in "{}"; the YAML format storage and JSON format storage support vector data types and map data types; the vector data type is array-type data; the map data type is hash data with unique keywords.

[0021] Preferably, the task tree structure in S3 is defined by the low-code task configuration file. The task tree structure consists of a parent node corresponding to multiple child nodes. The child nodes are sequentially combined in the form of an array or a list. The sequential combination is: parent node > child node array or list > child node attribute array or list.

[0022] Preferably, the task tree configuration in S3 specifically includes:

[0023] The task tree configuration defines three basic node structures: the top-level parent node, the middle-level node, and the bottom-level node;

[0024] The top-level parent node is "arm task", which is the root node of the task tree;

[0025] The middle-level node is an array or list of "tasks" child nodes, which are a series of task nodes, and each task node is represented by "name";

[0026] The bottom-level node is an array or list of "poses". Each "poses" node corresponds to a "name" node and contains a series of "pose" nodes; each child node "pose" in the "poses" array or list represents a state module; various attributes and peripheral operations that depend on each other before and after in the state module are defined in the form of child nodes;

[0027] The task tree configuration defines two types of node types, "necessary" and "optional". Among them, the necessary nodes must exist and set corresponding information, while the optional nodes can be omitted according to actual needs and default to preset values.

[0028] Preferably, the S4 data structure specifically includes: vector data type and conventional data type:

[0029] For the vector data type, the data is enclosed in square brackets "[]", and the data is separated by commas ",";

[0030] The conventional data type is a Byte of data, and the data type includes decimal / hexadecimal data or string data.

[0031] Preferably, the S4 node types specifically include task nodes and status nodes:

[0032] The task nodes belong to the array or list "tasks", and the start of a new task is marked by the child node of the keyword "name". At the same time, the task nodes contain an array or list of status nodes "poses" as child nodes, and the child nodes "name" and "poses" are sibling nodes;

[0033] The status nodes define the TCP end position and pose of each path point in the execution path of the robotic arm, as well as its attributes and operations that need to interact with the periphery; the status nodes include the necessary "pose" nodes, peripheral operation nodes, and other optional nodes.

[0034] Preferably, the peripheral operation nodes are of the type before starting to execute the status node to which they belong, and of the type after finishing executing the status node to which they belong. The node structures, attributes, and definitions of the child nodes of the two types are exactly the same, except for the time points when they are executed; three standard subclasses are defined in the child nodes of the two types: bool switch type, trigger type, and IO type.

[0035] Preferably, the S5 parses the low-code task configuration file to construct the tree structure of the task by parsing the configuration file in YAML format or JSON format. Each task node can contain one or more subtask nodes. The task tree is converted into a data structure. Each task node has a unique identifier, status, and subtask list. The complete parsing structure is constructed through recursive processing to guide the robotic arm to execute tasks in a predefined order, supporting dynamic adjustment of the task execution order or conditional skipping of certain tasks, thereby improving the clarity, maintainability, and scalability of task management.

[0036] Preferably, the S6 execution task tree data structure traverses each node in the task tree data structure, and according to the status and attributes of each node, calls the corresponding robotic arm driver program to execute operations; uses a recursive algorithm to process each task node and its subtask nodes to ensure that all subtasks are executed in a predefined order; the execution task tree data structure supports dynamic adjustment of the task execution order and real-time update of the task status, allowing dynamic modification of task parameters or status during execution to adapt to changes in the environment or task requirements.

[0037] The present invention defines the tasks of the robotic arm through the YAML format or JSON format of the low-code configuration file. These files are easy to write and understand, reducing the requirements for programming skills and enabling non-professionals to perform task configuration. This solves the problem of high technical requirements for operators in the traditional programming method and improves the efficiency of task configuration.

[0038] The present invention organizes tasks into a tree structure, and each task node can contain subtasks, forming a hierarchical task structure. This structured method makes task management clearer, supports hierarchical and modular design of tasks, and improves the maintainability and scalability of tasks. In addition, through the definition of the task tree structure and configuration, automated control and intelligent decision-making can be achieved, improving work efficiency and accuracy.

[0039] The present invention controls the action sequence of the robotic arm by parsing the configuration file, making task execution more flexible and dynamic. The control system can execute each subtask in sequence according to the task tree structure and configuration in the task configuration file until the entire task is completed. This dynamic task execution method can quickly adapt to changes in the production environment and improve production efficiency and flexibility.

[0040] The present invention introduces an exception handling mechanism during task execution. When an abnormal situation occurs during task execution, the system can automatically identify and take corresponding handling measures, such as pausing the task, retrying the task, or skipping the abnormal task. This exception handling mechanism improves the stability and reliability of the system and reduces production interruptions and losses caused by abnormal situations.

[0041] The present invention makes the structure and content of the task configuration file more standardized and unified through the data format and node type of the task configuration file. By defining the data format and node type, a task configuration file that meets the requirements of the task tree structure can be constructed, enabling the control system to correctly parse and execute these tasks. This standardized data format and node type definition improve the accuracy and consistency of task configuration and reduce system failures and production delays caused by configuration errors.

[0042] The above description is only an overview of the technical solution of this application. In order to be able to understand the technical means of this application more clearly, so as to be implemented in accordance with the content of the specification, and in order to make the above and other purposes, features and advantages of this application more obvious and understandable, the following will be described in detail with reference to the preferred embodiments of this application and the accompanying drawings.

[0043] From the following detailed description of the specific embodiments of this application in conjunction with the accompanying drawings, those skilled in the art will become more clear about the above and other purposes, advantages and features of this application. Brief Description of the Drawings

[0044] In order to more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings. In all the drawings, similar elements or parts are generally denoted by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to actual scale.

[0045] Figure 1 Flowchart of robotic arm task execution for low-code configuration;

[0046] Figure 2 Flowchart of robotic arm task parsing for low-code configuration;

[0047] Figure 3 Flowchart of robotic arm implementation for low-code configuration;

[0048] Figure 4 Task tree structure diagram. Specific Embodiments

[0049] To make the objectives, technical solutions and advantages of the embodiments of this application more clear, the following will clearly and completely describe the technical solutions in the embodiments of this application in conjunction with the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are some, but not all, of the embodiments of this application. In the following description, specific details such as specific configurations and components are provided only to assist in a comprehensive understanding of the embodiments of this application. Therefore, those skilled in the art should understand that various changes and modifications can be made to the embodiments described here without departing from the scope and spirit of this application. In addition, descriptions of known functions and structures are omitted for clarity and conciseness.

[0050] It should be understood that the "one embodiment" or "this embodiment" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, the "one embodiment" or "this embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner.

[0051] In addition, the present application may repeat reference numerals and / or letters in different examples. Such repetition is for the purpose of simplicity and clarity and does not in itself indicate the relationship between the various embodiments and / or arrangements discussed.

[0052] The term "and / or" in this article is merely a description of the associated relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, B exists alone, and A and B exist simultaneously. The term " / and" in this article describes another associated object relationship, indicating that there can be two relationships. For example, A / and B can represent: A exists alone, and A and B exist alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are an "or" relationship.

[0053] The term "at least one" in this article is merely a description of the associated relationship of the associated objects, indicating that there can be three relationships. For example, at least one of A and B can represent: A exists alone, A and B exist simultaneously, and B exists alone.

[0054] It should also be noted that in this article, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprising", "including" or any other variant thereof are intended to cover non-exclusive inclusion.

[0055] Embodiment 1

[0056] This embodiment mainly specifically describes a robotic arm task execution method based on low-code configuration;

[0057] Furthermore, as Figure 3 shown, a robotic arm task execution method based on low-code configuration includes the following steps:

[0058] S1. Define a status module, where the status module includes the position, pose, kinematic attributes, path planning constraint conditions of the TCP at the end of the robotic arm, and the status sequence of the peripheral operations and exception logic processing that depend on the position and pose before and after.

[0059] S2. Create a low-code task configuration file, which is stored in YAML format or JSON format and is used to represent the hierarchical relationship between entries at different levels;

[0060] S3. Build a task tree structure, which includes a task array or list, subtasks, a status module and its attributes, and uses the tree structure to organize the task configuration;

[0061] S4. Define the data structure and node type, parse and store the tree task configuration sequence of the low-code organization, and convert the text-form task configuration into a data structure that can be processed by the program;

[0062] S5. Parse the low-code task configuration file, read the task tree structure configuration in YAML format or JSON format into the data structure, and the data structure also satisfies the tree topology structure, which is convenient for traversing each node of the task sequence during software execution;

[0063] S6. Execute the task tree data structure, traverse each node in the task tree data structure, and cooperate with the manipulator drive to implement the task execution operation of the manipulator according to the status module and attributes defined by each node.

[0064] Furthermore, the status module specifically includes: speed and acceleration, joint coordinate system path and Cartesian coordinate system path, pre-execution peripheral operations, post-execution peripheral operations, post-execution time interval, and the status sequence of exception logic processing;

[0065] Speed and acceleration are used to define the speed and acceleration of the manipulator moving to this position or pose;

[0066] The joint coordinate system path and the Cartesian coordinate system path are used to plan the movement path of the manipulator;

[0067] The pre-execution peripheral operation is used to start the peripheral operation before executing this path point. The peripheral operation includes but is not limited to digital input / output operations, trigger type operations, and custom IO type operations. The peripheral operation also defines the number of attempts after the failure of executing this operation, the delay time before and after executing this operation, the status value of the digital input / output, and the specific attributes of the IO type operation;

[0068] The post-execution peripheral operation is used to perform the peripheral operation after this path point is executed. The peripheral operation also includes digital input / output operations, trigger type operations, and custom IO type operations. The peripheral operation also defines the number of attempts after the failure of executing this operation, the delay time before and after executing this operation, the status value of the digital input / output, and the specific attributes of the IO type operation;

[0069] The post-execution time interval is used to define the time interval after this path is executed, which defines the waiting time after executing this path point;

[0070] The state sequence for exception logic handling is the state sequence used to execute exception logic handling after the failure of this state. It jumps to other state modules through goto for recovery operations, and the goto jump defines the maximum number of attempts to execute after an exception occurs.

[0071] Furthermore, the low-code task configuration file in S2 is stored in YAML format or JSON format. The YAML format stores represent the hierarchical relationship between entries at different levels through indentation; the JSON format stores represent the hierarchical relationship between entries at different levels by enclosing with "{}"; the YAML format storage and JSON format storage support vector data type and map data type; the vector data type is array-type data; the map data type is hash data with unique keywords.

[0072] Furthermore, as Figure 4 shown, the task tree structure in S3 is defined by the low-code task configuration file. The task tree structure consists of a parent node corresponding to multiple child nodes, and the child nodes are sequentially combined in the form of an array or a list. The sequential combination is: parent node > child node array or list > child node attribute array or list;

[0073] Figure 4 The tasks shown in are the task array or list, which has one or more subtasks below it. Each subtask contains an array or list of poses, and each pose is the "state module". Each pose state module also contains an array or list of its properties. Similarly, each property can also contain multiple child nodes in the form of an array or a list, and so on to form a tree structure with a parent node containing multiple child nodes in the form of an array or a list. The advantage of using a one-to-many tree structure is that it can achieve infinite expansion of the containment relationship according to the characteristics of the child nodes, ensuring the adaptability of the mechanism to future expansion scenarios.

[0074] Furthermore, the task tree configuration in S3 specifically includes the following content:

[0075] The task tree configuration in S3 defines three basic node structures: the top parent node, the middle layer node, and the bottom layer node;

[0076] The top parent node is "arm task", which is the root node of the task tree;

[0077] The middle layer node is the "tasks" child node array or list, which is a series of task nodes, and each task node is represented by "name";

[0078] The underlying nodes are an array or list of "poses", each "poses" node corresponds to a "name" node, and contains a series of "pose" nodes; each child node "pose" in the "poses" array or list represents a state module; various attributes and peripheral operations that depend on each other before and after in the state module are defined in the form of child nodes;

[0079] The task tree configuration defines two types of nodes: "necessary" and "optional". Among them, the necessary nodes must exist and set the corresponding information, while the optional nodes can be omitted according to actual needs and default to preset values.

[0080] Furthermore, the S4 data structure specifically includes: vector data type and conventional data type:

[0081] The vector data type encloses the data with square brackets "[]", and the data is separated by commas ",";

[0082] The conventional data type is a Byte of data, and the data type includes decimal / hexadecimal data or string data.

[0083] Furthermore, the S4 node types specifically include task nodes and state nodes:

[0084] Task nodes belong to the array or list "tasks", start a new task with the child node of the keyword "name", and at the same time the task node contains an array or list "poses" of state nodes as child nodes, and the child nodes "name" and "poses" are sibling child nodes;

[0085] The state node defines the TCP end position and pose of each path point in the robotic arm execution path, as well as its attributes and operations that need to interact with the periphery; the state node includes the necessary "pose" node, peripheral operation node and other optional nodes.

[0086] Furthermore, the peripheral operation nodes are of the type before starting to execute the state node to which they belong, and of the type after finishing executing the state node to which they belong. The node structures, attributes, and definitions of child nodes of the two types are exactly the same, and the difference lies in the time points when they are executed; three standard subclasses are defined in the child nodes of the two types: bool switch type, trigger type, and IO type.

[0087] Furthermore, S5 parses the low-code task configuration file to build a tree structure of tasks by parsing a configuration file in YAML format or JSON format. Each task node can contain one or more subtask nodes. The task tree is converted into a data structure. Each task node has a unique identifier, a status, and a list of subtasks. A complete parsing structure is built through recursive processing to guide the robotic arm to execute tasks in a predefined order, supporting dynamic adjustment of the task execution order or conditional skipping of certain tasks, thereby improving the clarity, maintainability, and scalability of task management.

[0088] Furthermore, S6 executes the task tree data structure by traversing each node in the task tree data structure, and according to the status and attributes of each node, calls the corresponding robotic arm driver to perform operations; uses a recursive algorithm to process each task node and its subtask nodes to ensure that all subtasks are executed in a predefined order; the execution of the task tree data structure supports dynamic adjustment of the task execution order and real-time update of the task status, allowing dynamic modification of task parameters or status during execution to adapt to changes in the environment or task requirements.

[0089] This embodiment realizes the automatic execution of robotic arm tasks through steps such as defining a status module, creating a task configuration file in YAML format or JSON format, building a task tree structure, defining a data structure and node types, parsing the configuration file, and executing the task tree data structure. This solution solves the problems of complex programming and poor flexibility of traditional robotic arms, improves the simplicity and maintainability of task configuration through an intuitive configuration file and a hierarchical task management method, and at the same time supports dynamic adjustment of the task execution order and parameters, enhancing the adaptability and flexibility of the system. In addition, through the definition of the status module and peripheral operations, the system can better handle abnormal situations and interactions with external devices, improving the overall stability and reliability.

[0090] Embodiment 2

[0091] This embodiment is based on Embodiment 1 and mainly describes the status nodes of the node types in S4:

[0092] The status node defines the TCP end position and pose of each path point in the robotic arm execution path, as well as its attributes and operations that need to interact with the periphery; the status node includes a necessary "pose" node, a peripheral operation node, and other optional nodes. The specific status nodes are shown in the following table:

[0093]

[0094] The necessary pose node defines the TCP terminal position and pose;

[0095] The optional variable is a variable node used to modify the TCP terminal position and pose;

[0096] The optional joints constraint is a joint constraint used to set constraints on one or more joints during path planning;

[0097] The optional goto try max is the maximum number of attempts, used to define the maximum number of retries after a goto - form operation fails;

[0098] The necessary name is the state name, used to uniquely identify the state node;

[0099] The optional frame id is the coordinate system name, used to define the coordinate system of the state node for TCP coordinate transformation;

[0100] The optional velocity scale is the velocity ratio, used to define the velocity of TCP movement;

[0101] The optional acceleration scale is the acceleration ratio, used to define the acceleration of TCP movement;

[0102] The optional is cartesian is the path - planning mode selection, used to specify whether to use the Cartesian coordinate system or the joint coordinate system for path planning;

[0103] The optional delay to next is the delay time, used to define the time interval after the state execution is completed;

[0104] The optional alignment request is a hand - eye positioning request, used for hand - eye calibration when a positioning camera is installed;

[0105] The optional peripheral operation nodes include: preceding services (pre - peripheral operations) and following services (post - peripheral operations);

[0106] The optional preceding services (pre - peripheral operations) are used to define the peripheral operations that need to be executed before starting to execute this state node;

[0107] The optional following services (post - peripheral operations) are used to define the peripheral operations that need to be executed after starting to execute this state node;

[0108] The optional exception is a state sequence for exception logic handling, used to define the state nodes of the recovery actions that need to be executed after an error occurs during the execution of this state node.

[0109] The state node of this embodiment is a core component of task execution, which is used to define the position, pose, and their related attributes and peripheral operations of each path point in the robotic arm's execution path, ensuring that the robotic arm can execute tasks on the correct path at an appropriate speed and acceleration, and interact effectively with external devices. It also provides the ability to handle abnormal situations for better operation.

[0110] Embodiment 3

[0111] This embodiment is based on Embodiment 1. As Figure 2 shown, it mainly introduces the detailed process steps of parsing the low-code task configuration file in S5:

[0112] S5.1 Obtain the task name and read the name of the task from the task configuration file;

[0113] S5.2 Determine whether there is a pose sub-node by checking whether there is a pose sub-node in the task configuration file;

[0114] S5.3 Obtain the name of the pose node. Determine whether the last pose has been traversed. If so, the operation is completed; if not, parse the pose node and parse it successively according to the 6-dimensional position and pose, the predefined position and pose group, and the goto name;

[0115] S5.4 Extract the 6-dimensional position and pose. Determine whether there is a variable. If so, extract the variable keyword and operator and determine whether there is an exception; if not, directly determine whether there is an exception;

[0116] S5.5 If there is an exception, return to S5.2 to perform the operation again; if not, determine whether there are constraint conditions;

[0117] S5.6 If there are constraint conditions, extract the constraint conditions as the basis for subsequent processing; if not, determine whether there are other attributes;

[0118] S5.7 If there are other attributes, extract the other attributes as the basis for subsequent processing; if not, determine whether there are peripheral operations;

[0119] S5.8 If there are peripheral operations, obtain the service name; if not, return to S5.1 to perform the operation again;

[0120] S5.9 After obtaining the service name, determine whether it is of the bool switch quantity type. If so, extract the bool switch quantity attribute as the basis for subsequent processing; if not, determine whether there is an IO type;

[0121] S5.10 If there is an IO type, extract the bool switch quantity attribute as the basis for subsequent processing; if there is no IO type, determine whether there is a Trigger type. If so, extract the bool switch quantity attribute; Trigger type;

[0122] S5.11 Determine whether there is a Trigger type. The Trigger attribute is the trigger condition. If so, extract the Trigger attribute as the basis for subsequent processing; otherwise, determine whether the last one has been traversed;

[0123] S5.12 If the last node has been traversed, return to S5.1 to perform the operation again; otherwise, return to step S5.9 to obtain the service name again for judgment;

[0124] S5.13 Parse the predefined position pose group of the pose node, extract the predefined position pose group, and return to S5.5 to perform the operations in sequence;

[0125] S5.14 Parse the goto name of the pose node, extract the goto name, and return to S5.3 to perform the operations in sequence;

[0126] S5.15 Repeat the above process until the last node is traversed to end the operation.

[0127] In S5 of this embodiment, the parsing process realizes the efficient parsing of the task tree structure by automatically reading and processing each node in the task configuration file. By obtaining the task name, then checking and parsing the pose child nodes, extracting the position, pose information and related attributes, processing the peripheral operations and services, and supporting exception handling and dynamic adjustment. This process improves the flexibility and scalability of the robotic arm task configuration and ensures the accuracy and reliability of task execution.

[0128] Embodiment 4

[0129] This embodiment is based on Embodiment 1, as Figure 1 shown, mainly introduce the detailed process steps of executing the low-code task configuration file in S6:

[0130] S6.1 After the system starts, check whether there is a new task task to execute. If not, wait for the arrival of a new task;

[0131] S6.2 When a new task arrives, the system obtains the task task;

[0132] S6.3 Determine whether there is a pose node. If so, obtain the pose node; otherwise, end the operation;

[0133] S6.4 Obtain the pose node and determine whether there is a preceding service. If so, perform the pre-delay operation of the preceding service. If not, perform operations in sequence according to the 6D position and orientation, predefined position and orientation group, and goto name;

[0134] After the pre-delay operation of the preceding service is completed in S6.5, the system checks the bool switch quantity, IO, and Trigger attributes, passes them to perform the post-delay operation of the preceding service, and determines whether it is successfully completed;

[0135] In S6.6, if the post-delay operation is not successfully completed, determine whether there is an abnormal pose. If there is an abnormal pose, return to S6.4. If not, complete the operation process; if the post-delay operation is successfully completed, perform operations in sequence according to the 6D position and orientation, predefined position and orientation group, and goto name;

[0136] In S6.7, extract the 6D position and orientation, determine whether there is a variable modifier. If there is a variable modifier, modify the position and orientation, pass it to the constraint condition for superposition, and perform the IK inverse solution algorithm operation; if there is no variable modifier, directly pass it to the constraint condition for superposition, and perform the IK inverse solution algorithm operation;

[0137] In S6.8, extract the predefined position and orientation group and perform the IK inverse solution algorithm operation;

[0138] In S6.9, extract the goto node and determine whether the goto node is found. If so, return to S6.7 to perform operations in sequence; if not, return to S6.3 to perform operations in sequence;

[0139] In S6.10, determine whether the IK inverse solution algorithm operation is successful. If so, determine whether there is a followingservice; if not, determine whether there is an abnormal pose. If there is an abnormal pose, return to S6.4. If not, complete the operation process;

[0140] In S6.11, if there is a following service, perform the pre-delay operation of the preceding service. The system checks the bool switch quantity, IO, and Trigger attributes, passes them to perform the post-delay operation of the preceding service, and determines whether it is successfully completed; if there is no following service, end the operation process;

[0141] In S6.12, if it is successfully completed, end the operation process; if not, otherwise determine whether there is an abnormal pose. If there is an abnormal pose, return to S6.4. If not, complete the operation process.

[0142] This embodiment introduces that the execution process in S6 realizes the efficient execution of robotic arm tasks by automatically processing each node in the task configuration file. This process ensures that the system can accurately execute the actions and services defined by each task node, supports exception handling and dynamic adjustment, and improves the flexibility, reliability, and accuracy of robotic arm task execution.

[0143] The above are only the preferred embodiments of the present invention, and they do not limit the protection scope of the present invention. For those skilled in the art, various changes and modifications can be made to the present invention; within the spirit and principle of the present invention, any changes, modifications, substitutions, integrations, and parameter changes made to these embodiments by means of conventional substitutions or capable of achieving the same functions without departing from the principle and spirit of the present invention fall within the protection scope of the present invention.

Claims

1. A method for executing a robotic arm task based on low-code configuration, characterized in that: The following steps are involved: S1. Define a state module, which includes the position, posture, kinematic properties, path planning constraints, and state sequences of peripheral operations and abnormal logic processing of the position and posture of the robot terminal TCP; S2. Create a low-code task configuration file, where the configuration file is stored in YAML format or JSON format to represent the hierarchical relationship between items at different levels; S3, constructing a task tree structure, wherein the structure includes a task array or list, subtasks, a state module and its attributes, and uses a tree structure to organize task configuration; S4. Define data structure and node type, parse and store tree-shaped task configuration sequences organized by low code, and convert text-based task configurations into data structures that can be processed by programs; S5. Parse the low-code task configuration file and read the task tree structure configuration in YAML format or JSON format into the data structure; the data structure also satisfies the tree topology structure, which is convenient for traversing each node of the task sequence when the software is executed; S6, executing the task tree data structure, traversing each node in the task tree data structure, and cooperating with the robot arm driver to implement the task execution operation of the robot arm according to the state module and attributes defined by each node; The state module specifically includes: velocity and acceleration, joint coordinate system path and Cartesian coordinate system path, peripheral operation before execution, peripheral operation after execution, time interval after execution, and state sequence of abnormal logic processing; The speed and acceleration are used to define the speed and acceleration of the robot arm moving to the position or posture; The joint coordinate system path and the Cartesian coordinate system path are used to plan the movement path of the robotic arm; The pre-execution peripheral operation is used to start the peripheral operation before executing the path point. The peripheral operation includes but is not limited to switch operation, trigger type operation and custom IO type operation. The peripheral operation also defines the number of attempts after the operation fails, the delay time before and after the operation is executed, the state value of the switch and the specific attributes of the IO type operation; The post-execution peripheral operation is a peripheral operation after the execution of the path point is completed. The peripheral operation also includes switch operation, trigger type operation and custom IO type operation. The peripheral operation also defines the number of attempts after the operation fails, the delay time before and after the operation is executed, the state value of the switch and the specific attributes of the IO type operation; The post-execution time interval uses the time interval after the path is executed, and defines the waiting time after the path point is executed; The state sequence of the abnormal logic processing is a state sequence for executing the abnormal logic processing after the state fails, and jumps to other state modules for recovery operation through goto, and the goto jump defines the maximum number of execution attempts after the exception occurs; The task tree structure is defined by a low-code task configuration file. The task tree structure consists of a parent node corresponding to multiple child nodes. The child nodes are sequentially combined in the form of an array or list. The sequential combination is: parent node>child node array or list>child node attribute array or list The S4 node type specifically includes task nodes and state nodes: the task node belongs to the array or list "tasks", and the child node with the keyword "name" is the start of a new task. At the same time, the task node contains the array or list "poses" of the state node as a child node, and the child node "name" and "poses" are peer child nodes; The state node defines the TCP end position and posture of each path point in the robot arm execution path, as well as its attributes and operations that need to interact with the periphery; the state node includes necessary "pose" nodes, peripheral operation nodes and other optional nodes.

2. According to a method for executing a robotic arm task based on low-code configuration according to claim 1, it is characterized in that: The low-code task configuration file in S2 is stored in YAML format or JSON format. The YAML format storage uses indentation to indicate the hierarchical relationship between entries of different levels; the JSON format storage uses "{}" to enclose the hierarchical relationship between entries of different levels; the YAML format storage and JSON format storage support vector data type and map data type; the vector data type is array data; the map data type is hash data with unique keywords.

3. According to a method for executing a robotic arm task based on low-code configuration according to claim 1, it is characterized in that: The task tree configuration in S3 specifically includes: The task tree configuration defines three basic node structures: top parent node, middle node and bottom node; The top parent node is "armtask" which is the root node of the task tree; The middle layer node is an array or list of "tasks" child nodes, which is a series of task nodes, and each task node is represented by "name"; The bottom layer node is a "poses" array or list, each "poses" node corresponds to a "name" node and contains a series of "pose" nodes; each child node "pose" in the "poses" array or list represents a state module; various attributes and peripheral operations of the state module are defined in the form of child nodes; The task tree configuration defines two node types: "necessary" and "optional", where necessary nodes must exist and have corresponding information set, while optional nodes can be omitted based on actual needs and default values ​​are used.

4. According to a method for executing a robotic arm task based on low-code configuration according to claim 1, it is characterized in that: The S4 data structure specifically includes: vector data type and regular data type: The vector data type uses square brackets "[]" to enclose the data, and commas "," are used to separate the data. The conventional data type is Byte data, and the data type includes decimal / hexadecimal data or character string data.

5. According to a method for executing a robotic arm task based on low-code configuration according to claim 1, it is characterized in that: The peripheral operation node is a type before starting to execute the state node to which it belongs, and a type after completing the execution of the state node to which it belongs. The node structure, attributes, and sub-node definitions of the two types are exactly the same, and the difference lies in the time point when they are executed; three standard subclasses are defined in the two types of sub-nodes: bool switch type, trigger type, and IO type.

6. According to a method for executing a robotic arm task based on low-code configuration according to claim 1, it is characterized in that: The S5 parses the low-code task configuration file by parsing the configuration file in YAML format or JSON format to build a tree structure of the task. Each task node can contain one or more sub-task nodes, converting the task tree into a data structure. Each task node has a unique identifier, status, and sub-task list. The complete parsing structure is constructed through recursive processing to guide the robotic arm to perform tasks in a predefined order. It supports dynamic adjustment of the task execution order or conditional skipping of certain tasks, thereby improving the clarity, maintainability, and scalability of task management.

7. According to a method for executing a robotic arm task based on low-code configuration according to claim 1, it is characterized in that: The S6 execution task tree data structure traverses each node in the task tree data structure, and calls the corresponding robotic arm driver to perform operations according to the status and attributes of each node; uses a recursive algorithm to process each task node and its subtask nodes to ensure that all subtasks are executed in a predefined order; the execution task tree data structure supports dynamic adjustment of task execution order and real-time update of task status, allowing dynamic modification of task parameters or status during execution to adapt to environmental changes or changes in task requirements.

Images