Welding robot multi-task scheduling method, system, device and storage medium

Abstract

The present disclosure provides a welding robot multitask scheduling method, system, device and storage medium. In some embodiments of the present disclosure, an external input layer is used to receive a task request, and a task feature string is matched with a predefined execution graph to join a task queue; a behavior tree layer is used to perform priority preemption scheduling; a multitask scheduling layer includes a multitask scheduler, which is used to manage the scheduling, resource allocation and perception data failure fallback of multiple parallel task slots; an action graph definition layer defines all task execution paths in the form of a declarative directed graph, and the task execution paths include a retry branch, a loop branch and a failure branch; and an action module layer includes multiple independent action modules, each of which implements three interfaces of resource declaration, execution and cancellation. The present disclosure separates the task execution path from the imperative code, performs multitask slot parallel scheduling, and improves the task processing efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of robotics technology, and in particular to a method, system, device and storage medium for multi-task programming of a welding robot. Background Technology

[0002] Industrial welding robots have become core equipment in high-end equipment manufacturing fields such as automobile manufacturing, shipbuilding, and steel structure processing. A complete automated welding operation is not a single action, but involves the high degree of coordination among multiple heterogeneous subsystems such as robotic arms, external axes (such as guide rails), vision perception systems, and welding power sources. Its standard workflow typically includes a series of complex sequential or parallel processes such as reset, rail movement, global observation, weld planning, weld alignment, photography, weld recognition, process application, execution planning, welding execution, and torch cleaning. To manage this complex process efficiently and reliably, a task orchestration system with high flexibility, high concurrency, and strong robustness is crucial, as it directly determines the overall efficiency of the production line, resource utilization, and adaptability to complex working conditions.

[0003] Most existing welding robot task orchestration systems employ finite state machines (FSMs) based on imperative code or simple serial scripts for control. In this architecture, the entire welding process is decomposed into a series of predefined states, with the system transitioning to the next state based on the current state and triggering conditions. For different welding scenarios, such as short welds, long welds, or multi-segment welds, developers need to write different state transition logic or call different processing functions. This approach was common in early automation applications where task logic was relatively fixed and scenarios were simple. Its core idea is to hard-code all possible execution paths into the software and control the program's execution flow through conditional statements.

[0004] Currently, the task processing efficiency of welding robot task orchestration systems is relatively low. Summary of the Invention

[0005] This disclosure provides a multi-task orchestration method, system, device, and storage medium to at least solve the problem of low task processing efficiency in existing welding robot task orchestration systems.

[0006] The technical solution disclosed herein is as follows: This disclosure provides a welding robot multi-task orchestration system, including: The external input layer is used to receive task requests, match the task feature strings with the predefined execution graph, and add them to the task queue. The behavior tree layer is used for priority preemptive scheduling; The multi-task scheduling layer includes a multi-task orchestrator for managing the scheduling, resource allocation, and data failure rollback of multiple parallel task slots. The action graph definition layer is used to define all task execution paths in the form of a declarative directed graph, which includes retry branches, loop branches, and failure branches. The action module layer contains multiple independent action modules, each of which implements three interfaces: resource declaration, execution, and cancellation.

[0007] Optionally, the task orchestrator is used for: For task slots that have completed the current action group, collect the execution results, release the hardware resource tokens held by the task slots that have completed the current action group, and advance the nodes in the declarative directed graph according to the execution results. Check whether the perception data acquisition round recorded in the task slot waiting to be scheduled is consistent with the current world state data round. If the perception data acquisition round is consistent with the current world state data round, then the task slot waiting to be scheduled is rolled back to the entry node of the execution graph. The system attempts to atomically request all the necessary hardware resources for the waiting task slots in sequence, and initiates asynchronous concurrent execution upon successful request.

[0008] Optionally, the declarative directed graph includes: action nodes and transition edges; The action node represents a group of actions that are executed in parallel; The transformation edge includes: a starting node, a result code matching pattern, a target node, and a priority; After the action group is executed, the name and result code of each action are concatenated into a key-value string according to preset rules, and matched with the result code matching pattern of the transformation edge. The transformation edge with the highest total score is selected for node jump.

[0009] Optionally, the action module layer is used for: Declare the target hardware resources required for this execution based on the current state, or declare that the execution should be skipped; After the multitasking orchestrator acquires the target hardware resources, it starts and receives the static running parameters configured in the diagram. It is invoked when the behavior tree is preempted or the task is canceled, and is used to release the hardware state held by the module.

[0010] Optionally, the world state object is an immutable frozen data class, which includes: a data cycle counter and guide rail position information; Once the action that caused the perception data to fail has been completed, the multitasking orchestrator creates a new world state object and increments the data round counter. The perception data rounds recorded in the task slots are compared with the data rounds of the current world state to determine whether the data is invalid.

[0011] Optionally, the behavior tree layer uses a memoryless selector as the root node, and in each scheduling cycle, it re-evaluates the highest priority child node. When an alarm or pause is triggered, the behavior tree layer preempts the multi-task scheduling node, triggers the cancellation of all currently executing asynchronous tasks, and calls the interrupt cleanup interface of each action module.

[0012] Optionally, it also includes: a scope data blackboard and a module contract system; The scope data blackboard is used to isolate data when multiple task slots are executed concurrently; each task slot holds an independent scope data blackboard, which automatically isolates its own data by prefixing it with the task identifier, and provides a global sharing layer for sharing world state, alarm state and pause state across task slots; The contract system is used to centrally declare contracts for all action modules; each module contract includes: running parameter declaration, data read / write declaration, resource requirement declaration, result code declaration, and feature annotation; wherein, the feature annotation is used to mark module features in the module contract, and the multi-task orchestrator executes scheduling logic by querying module features.

[0013] This disclosure also provides a method for multi-task orchestration of a welding robot, including: The task request is received through an external input layer, and the task feature string is matched with a predefined execution graph before being added to the task queue. Priority preemption scheduling is performed through a behavior tree layer; The multi-task scheduling layer manages the scheduling, resource allocation, and data failure rollback of multiple parallel task slots at a fixed frequency. The task execution path is defined in a declarative directed graph through the action graph definition layer. The task execution path includes: retry branch, loop branch and failure branch. The action module layer executes specific actions and interacts with the task scheduling layer for resource declaration, execution, and interruption cleanup.

[0014] This disclosure also provides an electronic device, including: processor; Memory used to store processor-executable instructions; The processor is configured to execute instructions to implement the steps in the above method.

[0015] This disclosure also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0016] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects: In some embodiments of this disclosure, an external input layer is used to receive task requests, match task feature strings with a predefined execution graph, and add them to a task queue; a behavior tree layer is used for priority preemptive scheduling; a multi-task scheduling layer includes a multi-task orchestrator for managing the scheduling, resource allocation, and data failure fallback of multiple parallel task slots; an action graph definition layer defines all task execution paths in the form of a declarative directed graph, including retry branches, loop branches, and failure branches; and an action module layer contains multiple independent action modules, each implementing three interfaces: resource declaration, execution, and cancellation. This disclosure improves task processing efficiency by separating task execution paths from imperative code, defining all task execution paths in the form of a declarative directed graph, and performing parallel scheduling of multiple task slots.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0019] Figure 1 A flowchart illustrating a multi-task orchestration system for a welding robot, provided as an exemplary embodiment of this disclosure; Figure 2 A schematic diagram of a multi-task orchestration method for a welding robot provided as an exemplary embodiment of this disclosure; Figure 3 A schematic diagram of the structure of a welding robot multi-task orchestration device provided for an exemplary embodiment of this disclosure; Figure 4 A schematic diagram of the structure of an electronic device provided for an exemplary embodiment of this disclosure. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0021] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure.

[0022] It should be noted that the user information involved in this disclosure includes, but is not limited to, user device information and user personal information; the collection, storage, use, processing, transmission, provision and disclosure of user information in this disclosure all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0023] To address the aforementioned technical issues, in some embodiments of this disclosure, an external input layer is used to receive task requests, match task feature strings with a predefined execution graph, and add them to a task queue; a behavior tree layer is used for priority preemptive scheduling; a multi-task scheduling layer includes a multi-task orchestrator for managing the scheduling, resource allocation, and data failure rollback of multiple parallel task slots; an action graph definition layer defines all task execution paths in the form of a declarative directed graph, including retry branches, loop branches, and failure branches; and an action module layer contains multiple independent action modules, each implementing three interfaces: resource declaration, execution, and cancellation. This disclosure improves task processing efficiency by separating task execution paths from imperative code, defining all task execution paths in the form of a declarative directed graph, and performing parallel scheduling of multiple task slots.

[0024] The technical solutions provided by the embodiments of this disclosure are described in detail below with reference to the accompanying drawings.

[0025] Figure 1 This is a flowchart illustrating a welding robot multi-task orchestration system 10, provided as an exemplary embodiment of this disclosure. Figure 1 As shown, the multi-task orchestration system 10 includes: an external input layer 11, a behavior tree layer 12, a multi-task scheduling layer 13, an action graph definition layer 14, and an action module layer 15.

[0026] The external input layer 11 is used to receive task requests, match the task feature string with the predefined execution graph, and add it to the task queue. Behavior tree layer 12 is used for priority preemptive scheduling; The multi-task scheduling layer 13 includes a multi-task orchestrator for managing the scheduling, resource allocation, and data failure rollback of multiple parallel task slots. Action graph definition layer 14 is used to define all task execution paths in the form of a declarative directed graph. The task execution paths include: retry branches, loop branches, and failure branches. Action module layer 15 contains multiple independent action modules, each implementing three interfaces: resource declaration, execution, and cancellation. It should be noted that this disclosure does not limit the number of action modules and can be adjusted according to actual needs. For example, the number of action modules could be 11.

[0027] In some embodiments of this disclosure, the declarative directed graph includes: action nodes and transformation edges; an action node represents a set of actions executed in parallel and is declared as an immutable frozen data structure. For example, a weld bead perception node includes four parallel actions: weld bead planning, weld bead alignment, photography, and weld seam recognition; a transformation edge includes four fields: starting node, result code matching mode, target node, and priority; wherein, after the action group is executed, the name and result code of each action are concatenated into a key-value string according to a preset rule, for example, weld bead planning: successful, weld seam recognition: successful, photography: successful; as the matching input for the transformation edge. It is then matched with the result code matching mode of the transformation edge, and the transformation edge with the highest total score is selected for node jump; for example, the transformation edge supports exact matching (+2 points), single wildcard (+1 point), and global wildcard (0 points), and the edge with the highest total score is selected for jump. If there is no match, jump to the failure termination node.

[0028] It's important to note that the graph structure of a declarative directed graph is entirely defined by the configuration file. Adding a new scenario requires only one additional configuration, with zero changes to the orchestration engine.

[0029] In the above embodiments, the system performs a static check on each graph once at startup. The check rules include: the entry node exists, all edges referencing nodes are valid, each non-terminal node has a globally wildcard bottom edge, and it includes both successful and failed termination nodes. The check is not repeated during runtime, ensuring zero runtime overhead.

[0030] In some embodiments of this disclosure, the task orchestrator collects execution results for task slots that have completed the current action group, releases the hardware resource tokens held by the task slots that have completed the current action group, and advances the nodes in the declarative directed graph according to the execution results; checks whether the perception data acquisition rounds recorded by the task slots waiting to be scheduled are consistent with the current world state data rounds. If the perception data acquisition rounds are consistent with the current world state data rounds, the task slots waiting to be scheduled are rolled back to the entry node of the execution graph; and attempts to atomically request all the required hardware resources for the task slots waiting to be scheduled in sequence. After successful request, asynchronous concurrent execution is started.

[0031] The multitasking orchestrator executes a scheduling loop at a fixed frequency (10Hz) and manages up to N parallel task slots (N is configurable, ranging from 1 to 3). Its core workflow consists of three steps: "harvesting", "failure checking", and "scheduling".

[0032] During the harvest phase, the orchestrator processes task slots that have completed the current action group. It collects execution feedback for each action (including action name and result code) and releases all hardware resource tokens currently held by the task slot. It checks if the current execution round contains the side effect of "invalidating perception data," and if so, increments the "world state data round" counter by 1. Finally, it uses the result code key-value string to query the declarative directed graph, locates and advances to the next node; if the new node is a termination node, it marks the task slot as "complete" and notifies the final result.

[0033] During the failure check phase, the orchestrator ensures that the execution of task slots awaiting scheduling is based on the latest environmental perception. The system checks whether the "perception data acquisition round" recorded by the task slot is consistent with the current "world state data round". If they are inconsistent, it means that the environmental data has changed, and the orchestrator will roll back the task slot to the entry node of the execution graph, clear its recorded perception data round, and force it to re-execute the observation process using the latest perception data.

[0034] During the scheduling phase, the orchestrator allocates resources to task slots that are waiting for scheduling and have passed the failure check (sorted by enqueue time to ensure fairness). The system calls the resource declaration interface of each action module to obtain the list of resources required for this operation. If all actions declare "skip execution," the graph node is directly advanced without consuming hardware resources. Next, it checks whether there are other running task slots that depend on the current perception data to prevent conflicts, and then attempts to atomically request all the required hardware resources. If the request fails, the current round of scheduling is skipped; if the request succeeds, the action group of this node is started to execute asynchronously and concurrently.

[0035] In addition, the system supports gradual migration. When the maximum number of concurrent tasks is configured to 1, the scheduling layer automatically degenerates to single-task pass-through mode.

[0036] In some embodiments of this disclosure, the action module layer declares the target hardware resources required for this execution based on the current state, or declares to skip execution; it is started after the multi-task orchestrator obtains the target hardware resources and receives the static running parameters configured in the graph; it is invoked when the behavior tree preempts or the task is canceled, and is used to release the hardware state held by the module.

[0037] In some embodiments of this disclosure, the action module layer strictly separates the declaration and execution of resource requirements through three interfaces. First, in the resource declaration phase (phase one), the module performs synchronous and read-only operations (taking less than 1 millisecond), determining the target hardware resources required for this execution based on the current blackboard data and world state, and supports dynamic runtime decisions. For example, if the track-shifting module detects that it is already at the target position, it can declare to skip this execution. Second, in the actual execution phase (phase two), it starts only after the multi-task orchestrator successfully acquires all the resources declared in phase one. This phase is asynchronous and can run for a long time, while receiving static running parameters of the graph configuration (such as the execution mode of the reset module). Finally, in the interrupt cleanup phase (phase three), if behavior tree preemption or task cancellation occurs, this interface will be called to release the hardware state held by the module.

[0038] To facilitate the above process, the resource manager is responsible for maintaining three types of exclusive hardware resource tokens: the robotic arm, the computing unit, and the guide rail. The system uses an all-or-none approach for atomic allocation to prevent deadlocks and ensures that each type of resource token can only be held by one task module at any given time, thereby effectively guaranteeing the hardware security of multi-tasking.

[0039] In some embodiments of this disclosure, the world state object is an immutable frozen data class, which includes a data round counter and guide rail position information. After the action that causes the sensing data to fail is completed, the multi-task orchestrator creates a new world state object and increments the data round counter. The sensing data round recorded in the task slot is compared with the current world state's data round to determine if the data is invalid. Specifically, the data round counter is used to manage the failure relationships of the sensing data; for example, when the robot guide rail moves, previously collected weld seam sensing data (images, point clouds, recognition results) is considered invalid.

[0040] Once the orbit shift module completes its execution and declares the side effect of "disable sensing data," the multitasking orchestrator creates a new world state object at the new location during the harvest phase and increments the data round counter. In the subsequent scheduling loop, the system checks whether the sensing acquisition rounds recorded by each task slot are consistent with the current world state's data rounds; if a discrepancy is found, the data is deemed invalid, and the waiting task slot is rolled back to the entry node of the execution graph, forcing it to re-execute the observation process.

[0041] To prevent concurrent conflicts, the system also includes a scheduling protection mechanism. If a task slot is about to execute an action with the side effect of "disabling perceived data," while another task slot is in the perceived dependency phase marked by the "observation dependency" feature in the module contract, the orchestrator will delay the scheduling to prevent the ongoing observation from being invalidated midway. This "observation dependency" attribute is marked in the module contract through module features, and the orchestrator retrieves it through a feature query interface. There is no need to hardcode the module name in the scheduling logic, allowing new modules to be automatically detected by the scheduling logic simply by declaring the features in the contract.

[0042] In some embodiments of this disclosure, the behavior tree layer uses a memoryless selector as the root node, and re-evaluates the highest priority child node in each scheduling cycle. When an alarm or pause is triggered, the behavior tree layer preempts the multi-task scheduling node, triggers the cancellation of all currently executing asynchronous tasks, and calls the interrupt cleanup interface of each action module.

[0043] Specifically, in some embodiments of this disclosure, the behavior tree layer employs a memoryless selector as the root node to ensure high system responsiveness. This selector contains four child nodes and re-evaluates each scheduling cycle (within 100ms) starting from the highest priority child node, rather than remembering or skipping branches already in the "running" state. This mechanism ensures that alarms and pause signals can be captured and activated immediately.

[0044] The node priority structure of the behavior tree is as follows: Alarm branch (highest priority): Uses a memoryless sequence structure, detects the alarm status through read-only, O(1), and side-effect-free condition nodes. If the condition is met, the alarm handling action (such as robotic arm safety reset) is executed immediately. Pause branch (secondary priority): Also uses a memoryless sequence to detect the pause status. If triggered, it enters a pause waiting action, continuously returning to the running state until a recovery command is received. Multi-task scheduling node: Responsible for handling normal business logic execution. Idle processing node: Executes when there are no tasks.

[0045] When an alarm or pause signal is triggered, the high-priority selector branch preempts the multi-task scheduling node, immediately canceling all currently executing asynchronous tasks and calling the interrupt cleanup interface of each action module to release resources. During the system recovery phase, the orchestrator uses execution breakpoint records containing interrupted nodes, lists of completed actions, and lists of interrupted actions for rescheduling, supporting three recovery strategies: direct continuation, rescheduling from checkpoints, and node retry.

[0046] In some embodiments of this disclosure, the welding robot multi-task orchestration system 10 further includes: a scope data blackboard and a module contract system. The scope data blackboard is used for data isolation when multiple task slots execute concurrently; each task slot holds an independent scope data blackboard, automatically isolating its own data by prefixing it with a task identifier, and providing a global sharing layer for sharing world state, alarm state, and pause state across task slots; the contract system is used to centrally declare contracts for all action modules; each module contract includes: a running parameter declaration, a data read / write declaration, a resource requirement declaration, a result code declaration, and a feature annotation; wherein, the feature annotation is used to annotate module features in the module contract, and the multi-task orchestrator executes scheduling logic by querying module features.

[0047] Specifically, when multiple task slots execute concurrently, the scope data blackboard held by each task slot will transparently isolate its own data with a task identifier as a prefix, and the action module code does not need any modification. For example, when the module write key "weld perception / completion status" for task A (task ID: t001), it is actually stored as "task / t001 / weld perception / completion status", with the task prefix automatically added. Globally shared keys (such as world status, alarm status, pause status) are automatically recognized and not prefixed, and all task slots can jointly read shared data such as guide rail position, data cycle, current alarm, and pause request.

[0048] The system centrally declares complete contracts for 11 action modules. Each module contract includes: a runtime parameter declaration (static configuration keys and allowed values ​​accepted by the module, specified in the graph configuration and passed to the execution interface at runtime), a data read declaration (a list of data keys read from the blackboard at runtime), a data write declaration (a list of data keys written to the blackboard at runtime), a resource requirement declaration (the types of required hardware resources, such as robotic arms, computing units, and guide rails), a result code declaration (all possible execution result codes, used for graph verification and documentation), and feature annotations (a set of module features, such as "observation dependencies," used for the perception data round mechanism). The system comprises 11 action modules: reset, track movement, global observation, photography, weld seam recognition, weld bead planning, weld bead alignment, execution planning, process application, welding execution, and torch cleaning.

[0049] During graph loading, the graph validator, in conjunction with module contracts, performs static validation of the key names and value ranges of all actions' execution parameters in the graph, exposing configuration errors before execution. Furthermore, the system employs a task-graph matching mechanism: when a task is submitted, it carries a characteristic key-value string (e.g., "weld type: short weld, process type: MIG"). The system performs key-value subset matching using an ordered rule set, routing the task to the best-matching execution graph, supporting zero-code extensions for new scenarios.

[0050] This embodiment utilizes multi-task slot parallel scheduling to allow visual perception and robotic arm movement to overlap and execute across different tasks. When the maximum concurrent task count is 2, perception waiting time can be completely masked. Adding a welding scenario only requires adding a configuration file, without modifying the orchestration engine, behavior tree layer, or action module, achieving zero-code expansion of the execution path. Simultaneously, the data round-robin mechanism can automatically detect perception data failures caused by guide rail movement and trigger task rollback, eliminating the need for manual checking logic. When a pause or alarm occurs, saving the execution breakpoint allows for resumption from the interrupted node, avoiding the overhead of repeated execution. The resource manager employs an atomic all-or-nothing allocation strategy, ensuring zero hardware resource conflicts at the architectural level. The core orchestration engine does not rely on the robot communication framework and supports independent unit testing. Furthermore, when the maximum concurrent task count is set to 1, the system can degenerate into a single-task serial mode, supporting gradual migration with manageable risks.

[0051] Figure 2 This is a schematic diagram illustrating a multi-task orchestration method for a welding robot, provided as an exemplary embodiment of this disclosure. (See diagram below.) Figure 2 As shown, the method includes: S201: Receive task requests through the external input layer, match the task feature string with the predefined execution graph, and add it to the task queue; S202: Priority preemption scheduling is performed through the behavior tree layer; S203: Manages the scheduling, resource allocation, and data failure rollback of multiple parallel task slots at a fixed frequency through a multi-task scheduling layer; S204: Define task execution paths using a declarative directed graph through the action graph definition layer. Task execution paths include: retry branches, loop branches, and failure branches. S205: Executes specific actions through the action module layer and interacts with the multi-task scheduling layer for resource declaration, execution, and interrupt cleanup.

[0052] In this embodiment, the subject executing the above method is a terminal device or a server.

[0053] The terminal device includes, but is not limited to, mobile stations (MS), mobile terminals, mobile phones, handsets, and portable equipment. This terminal device can communicate with one or more core networks via a radio access network (RAN). For example, the terminal device can be a mobile phone (or "cellular" phone), a computer with wireless communication capabilities, a computer with wireless transceiver capabilities, a virtual reality (VR) terminal device, an AR terminal device, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical care, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in a smart city, a wireless terminal in a smart home, etc. The operating systems installed on the terminal device include, but are not limited to, iOS, Android, Windows, Linux, and Mac OS. In different networks, terminals may be called by different names, such as: user equipment, mobile station, user unit, station, cellular phone, personal digital assistant, wireless modem, wireless communication device, handheld device, laptop, cordless phone, wireless local loop station, television, etc. For ease of description, this embodiment will simply refer to it as terminal device.

[0054] In this embodiment, the implementation form of the server is not limited. For example, the server can be a conventional server, a cloud server, a cloud host, a virtual center, or other server devices. The server mainly consists of a processor, hard disk, memory, system bus, and other common computer architecture types.

[0055] It should be noted that the embodiments disclosed herein do not demonstrate or describe the above methods. The specific execution steps of the above methods can be found in the descriptions of the foregoing embodiments, and will not be repeated here.

[0056] Figure 3 This is a schematic diagram of the structure of a welding robot multi-task orchestration device 30 provided for an exemplary embodiment of this disclosure. Figure 3 As shown, the welding robot multi-task orchestration device 30 includes: a matching module 31, a scheduling module 32, a management module 33, an execution module 34, and an interaction module 35.

[0057] Among them, the matching module 31 is used to receive task requests through the external input layer, match the task feature string with the predefined execution graph, and add it to the task queue; Scheduling module 32 is used for priority preemptive scheduling through the behavior tree layer; Management module 33 is used to manage the scheduling, resource allocation and data failure rollback of multiple parallel task slots at a fixed frequency through the multi-task scheduling layer; Execution module 34 is used to define task execution paths in a declarative directed graph through the action graph definition layer. The task execution paths include: retry branches, loop branches, and failure branches. Interaction module 35 is used to execute specific actions through the action module layer and interact with the multi-task scheduling layer for resource declaration, execution, and interruption cleanup.

[0058] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0059] Figure 4 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of the present disclosure. For example... Figure 4 As shown, the electronic device includes a memory 41 and a processor 42. Additionally, the electronic device also includes a power supply component 43 and a communication component 44.

[0060] Memory 41 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device.

[0061] The memory 41 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0062] Communication component 44 is used for data transmission with other devices.

[0063] The processor 42 executes computer instructions stored in the memory 41 to: receive task requests through an external input layer, match task feature strings with a predefined execution graph, and add them to a task queue; perform priority preemptive scheduling through a behavior tree layer; manage the scheduling, resource allocation, and data failure rollback of multiple parallel task slots at a fixed frequency through a multi-task scheduling layer; define task execution paths through a declarative directed graph through an action graph definition layer, whereby the task execution paths include retry branches, loop branches, and failure branches; execute specific actions through an action module layer, and interact with the multi-task scheduling layer for resource declaration, execution, and interrupt cleanup.

[0064] Accordingly, embodiments of this disclosure also provide a computer-readable storage medium storing a computer program. When the computer-readable storage medium stores a computer program, and the computer program is executed by one or more processors, it causes one or more processors to perform... Figure 2 Each step in the method embodiment.

[0065] Accordingly, embodiments of this disclosure also provide a computer program product, which includes a computer program / instructions that are executed by a processor. Figure 2 Each step in the method embodiment.

[0066] The above Figure 4 The communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA) technology, Ultra-Wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0067] The above Figure 4 The power supply component provides power to the various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which it resides.

[0068] The aforementioned electronic devices also include a display screen and audio components.

[0069] The display includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can sense not only the boundaries of touch or swipe actions, but also the duration and pressure associated with the touch or swipe operation.

[0070] An audio component may be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals may be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0071] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0072] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0073] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0074] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0075] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0076] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0077] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0078] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0079] The above are merely specific embodiments of this disclosure, enabling those skilled in the art to understand or implement this disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A multi-task orchestration system for welding robots, characterized in that, include: The external input layer is used to receive task requests, match the task feature strings with the predefined execution graph, and add them to the task queue. The behavior tree layer is used for priority preemptive scheduling; The multi-task scheduling layer includes a multi-task orchestrator for managing the scheduling, resource allocation, and data failure rollback of multiple parallel task slots. The action graph definition layer is used to define all task execution paths in the form of a declarative directed graph, which includes retry branches, loop branches, and failure branches. The action module layer contains multiple independent action modules, each of which implements three interfaces: resource declaration, execution, and cancellation.

2. The system according to claim 1, characterized in that, The task orchestrator is used for: For task slots that have completed the current action group, collect the execution results, release the hardware resource tokens held by the task slots that have completed the current action group, and advance the nodes in the declarative directed graph according to the execution results. Check whether the perception data acquisition round recorded in the task slot waiting to be scheduled is consistent with the current world state data round. If the perception data acquisition round is consistent with the current world state data round, then the task slot waiting to be scheduled is rolled back to the entry node of the execution graph. The system attempts to atomically request all the necessary hardware resources for the waiting task slots in sequence, and initiates asynchronous concurrent execution upon successful request.

3. The system according to claim 1, characterized in that, The declarative directed graph includes: action nodes and transition edges; The action node represents a group of actions that are executed in parallel; The transformation edge includes: a starting node, a result code matching pattern, a target node, and a priority; After the action group is executed, the name and result code of each action are concatenated into a key-value string according to preset rules, and matched with the result code matching pattern of the transformation edge. The transformation edge with the highest total score is selected for node jump.

4. The system according to claim 1, characterized in that, The action module layer is used for: Declare the target hardware resources required for this execution based on the current state, or declare that the execution should be skipped; After the multitasking orchestrator acquires the target hardware resources, it starts and receives the static running parameters configured in the diagram. It is invoked when the behavior tree is preempted or the task is canceled, and is used to release the hardware state held by the module.

5. The system according to claim 1, characterized in that, The world state object is an immutable frozen data class, which includes: a data cycle counter and guide rail position information; Once the action that caused the perception data to fail has been completed, the multitasking orchestrator creates a new world state object and increments the data round counter. The perception data rounds recorded in the task slots are compared with the data rounds of the current world state to determine whether the data is invalid.

6. The system according to claim 1, characterized in that, The behavior tree layer uses a memoryless selector as the root node, and in each scheduling cycle, it re-evaluates the highest priority child node. When an alarm or pause is triggered, the behavior tree layer preempts the multi-task scheduling node, triggers the cancellation of all currently executing asynchronous tasks, and calls the interrupt cleanup interface of each action module.

7. The system according to claim 1, characterized in that, Also includes: Scope data blackboard and module contract system; The scope data blackboard is used for data isolation when multiple task slots are executed concurrently; Each task slot holds an independent scoped data blackboard, automatically isolating its own data by prefixing it with the task identifier, and providing a global sharing layer for sharing world state, alarm state, and pause state across task slots; The contract system is used to centrally declare contracts for all action modules; each module contract includes: running parameter declaration, data read / write declaration, resource requirement declaration, result code declaration, and feature annotation; wherein, the feature annotation is used to mark module features in the module contract, and the multi-task orchestrator executes scheduling logic by querying module features.

8. A multi-task scheduling method for a welding robot, characterized in that, include: The task request is received through an external input layer, and the task feature string is matched with a predefined execution graph before being added to the task queue. Priority preemption scheduling is performed through a behavior tree layer; The multi-task scheduling layer manages the scheduling, resource allocation, and data failure rollback of multiple parallel task slots at a fixed frequency. The task execution path is defined in a declarative directed graph through the action graph definition layer. The task execution path includes: retry branch, loop branch and failure branch. The action module layer executes specific actions and interacts with the task scheduling layer for resource declaration, execution, and interruption cleanup.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to execute instructions to implement the steps in the method as described in claim 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in claim 8.

Images