A robot dispatch management method and system based on cloud platform

Abstract

The present invention belongs to the field of intelligent manufacturing and provides a robot dispatch management method and system based on a cloud platform, including the cloud platform establishing a communication connection with all robots and parsing the task parameters and resource information in the lease; the cloud platform establishes a robot management subsystem corresponding to the lease one by one according to the lease, and establishes a logical communication channel between each robot in the first robot set; the robot management subsystem determines the service dependency relationship between the first robot set based on the processing task information in the lease, and constructs a corresponding service dependency graph; the robot management subsystem generates a communication path topology within the first robot set based on the service dependency graph, which is used to guide collaborative communication between robots; each robot in the first robot set receives and executes the task command issued by the robot management subsystem in turn according to the communication path topology.

Description

Technical Field

[0001] The present invention belongs to the field of intelligent manufacturing, and specifically relates to a robot dispatch management method and system based on a cloud platform. Background Art

[0002] With the continuous improvement of manufacturing automation, industrial robots have been widely used in areas such as assembly, handling, welding, and testing. To improve equipment efficiency and reduce operation and maintenance costs, more and more companies are adopting the Robotics as a Service (Robot-as-a-Service) model, where a platform centrally dispatches and manages robot resources distributed across multiple tenants, enabling on-demand dispatch and remote control.

[0003] In existing robot management systems, the platform primarily handles lease management, task dispatching, status collection, and some scheduling functions, while robots access the platform through edge gateways to participate in task execution. However, due to the diversity of tenant tasks, the heterogeneity of robot resources, the complexity of service dependencies during task execution, and the need for real-time collaboration, existing technologies still have shortcomings in the following areas:

[0004] Existing platforms often generate robot execution plans based on static configuration or rule-driven approaches. These platforms are unable to parse service logic and derive collaborative structures in real time based on complex task parameters submitted by tenants, making them incapable of adapting to dynamic task structures involving multiple stages, cross-services, and multiple robots. Existing systems mostly utilize pre-defined robot communication channels, making it difficult to automatically generate or adjust communication topologies based on the service dependencies of actual tasks. This results in redundant or missing communication link configurations, impacting system efficiency and data transmission reliability. Robot management systems are typically pre-configured using templates, with fixed functional modules and communication interfaces. These systems lack modular assembly and on-demand configuration capabilities, resulting in wasted platform resources, weak adaptability, and difficulty supporting the flexible scheduling requirements of multi-tenant environments. Task scheduling and communication management are often separated into separate systems, failing to establish a unified control flow model for task instruction issuance, communication link establishment, and robot status feedback, driven by service dependencies. This creates a disconnect between scheduling, execution, and feedback. Summary of the Invention

[0005] In order to solve the problems in the prior art, the present invention provides a robot dispatch management method based on a cloud platform, comprising the following steps:

[0006] The cloud platform establishes communication connections with all robots;

[0007] The cloud platform receives a robot lease from a tenant and parses the task parameters and resource information in the lease;

[0008] The cloud platform establishes a robot management subsystem corresponding to the lease in a one-to-one manner according to the lease;

[0009] The robot management subsystem establishes a logical communication channel with each robot in the first robot set according to the first robot set specified in the lease;

[0010] The robot management subsystem determines the service dependency relationship between the first robot set based on the processing task information in the lease, and constructs a corresponding service dependency graph;

[0011] The robot management subsystem generates a communication path topology within the first robot set based on the service dependency graph, for guiding collaborative communication between robots;

[0012] Each robot in the first robot set receives and executes the task command issued by the robot management subsystem in sequence according to the communication path topology.

[0013] Furthermore, establishing a robot management subsystem corresponding to each lease specifically includes:

[0014] The cloud platform models the task parameters in the lease as a graph structure, where each node represents a functional requirement or resource entity, and the edge represents a call relationship or constraint logic. After the graph structure is input into the task configuration engine, the cloud platform uses a trained graph matching model or graph embedding comparison algorithm to select the function template that best matches the task structure semantics in the lease from the preset robot management subsystem template library;

[0015] The cloud platform calls the corresponding basic function modules in the platform service component pool according to the module list marked in the selected template, and splices them in a predetermined logical order to generate a complete operating structure;

[0016] The cloud platform uses a communication channel compiler to generate a robot management subsystem based on the task structure diagram and the robot set;

[0017] The robot management subsystem establishes a binding relationship with the lease ID during deployment and is included in the unified lifecycle management process before and after task execution. The activation status, operation stage, resource occupancy, abnormal status and execution completion status of the robot management subsystem are written into the lease management database in real time. When the lease expires or the task is terminated, the robot management subsystem stops task distribution, releases the corresponding logical communication channel and service interface, and reclaims module resources.

[0018] Furthermore, the construction of the service dependency graph specifically includes the following steps:

[0019] The robot management subsystem performs semantic analysis on the processing task information, extracts the task elements, and converts them into a unified task description data structure;

[0020] The robot management subsystem establishes a correspondence between the mission phase and the first set of robots specified in the lease, and constructs a robot-phase mapping table, while marking the service call and trigger relationship;

[0021] The robot management subsystem infers timing dependencies, service nesting dependencies, and data transfer dependencies based on task phase timing and service call requirements, and converts the above dependencies into directed edges with attribute labels;

[0022] The robot management subsystem combines dependency edges and nodes to construct a directed service dependency graph, in which nodes represent robot task stages or service module call units, and edges represent service dependency paths between tasks.

[0023] Furthermore, the generation of the communication path topology specifically includes:

[0024] The robot management subsystem extracts a directed edge set from the service dependency graph, maps the dependency relationship represented by each edge into a communication requirement, and uniformly converts it into a communication requirement list;

[0025] The robot management subsystem constructs a communication path topology graph according to the communication requirements, wherein the nodes represent robots in the first robot set, the edges represent communication channels and their attributes, and the communication path topology is represented as a directed weighted attribute graph for execution by the edge controller, the task scheduler, or the robot communication agent;

[0026] The robot management subsystem optimizes the communication path topology, including merging redundant paths, introducing backup paths, setting priority forwarding rules, bandwidth restrictions, channel isolation, and dynamic adjustment of edge weights;

[0027] The robot management subsystem sends the communication path topology in the form of a structured configuration file or microservice API to each robot communication module, edge node scheduler and cloud platform monitoring module. After the communication path is activated, it guides the robot to perform task synchronization, status feedback, service call and exception reporting. The communication link status supports periodic monitoring. If a communication anomaly is detected, the topology reconstruction or channel migration mechanism is automatically triggered.

[0028] Furthermore, the process of the robots in the first robot set executing the task command according to the communication path topology includes the following steps:

[0029] The robot management subsystem generates task commands in stages and distributes them to robots based on the service dependency graph and communication path topology. It generates a task instruction queue bound to each robot instance, binds each task instruction to a trigger condition, and sends the instruction to the corresponding robot communication module through a logical communication channel. The instruction is queued on the robot side and waits for execution.

[0030] After receiving a command, each robot determines whether it meets the execution conditions, including confirmation of the completion of the predecessor task, the completeness of the service return data, and verification of the resource status and topological edge attributes of the robot management subsystem. Only instructions that meet all the execution conditions will be pushed into the control module execution stack.

[0031] The robots complete action control, state synchronization, service interface calls, and result feedback according to task instructions, and transmit execution status or data packets to subsequent nodes according to the communication path topology. When the collaborative control strategy is enabled, the robots continuously exchange state information to ensure consistent collaborative actions.

[0032] After completing the task instructions, the robot uploads status information and records the execution log. If an error occurs, the robot will perform rollback, retry, backup robot relay or interruption of the task according to the exception handling logic in the task instructions. The robot management subsystem dynamically updates the service dependency graph and communication path topology based on task feedback, and performs structural reconstruction and task adjustment.

[0033] Another aspect of the present invention provides a cloud-based robot dispatch management system, comprising the following modules:

[0034] Communication module, used to establish communication connection between the cloud platform and all robots;

[0035] A lease receiving and parsing module, configured to receive a robot lease from a tenant and parse the task parameters and resource information in the lease;

[0036] A subsystem construction module, configured to establish a robot management subsystem corresponding to the lease according to the lease;

[0037] a communication channel building module, configured to establish a logical communication channel with each robot in the first robot set according to the first robot set specified in the lease;

[0038] a service dependency graph building module, configured to determine the service dependency relationship between the first set of robots based on the processing task information in the lease, and to build a corresponding service dependency graph;

[0039] a communication topology generation module, configured to generate a communication path topology within the first set of robots based on the service dependency graph, for guiding collaborative communication between the robots;

[0040] The task execution control module is used to enable each robot in the first robot set to sequentially receive and execute the task command issued by the robot management subsystem according to the communication path topology.

[0041] Furthermore, the subsystem building blocks specifically include:

[0042] Graph modeling unit, used to model and abstract the task parameters in the lease into a graph structure, where each node represents a functional requirement or resource entity, and the edge represents a call relationship or constraint logic;

[0043] The template matching unit is used to input the graph structure into the task configuration engine and select the function template that best matches the task structure semantics in the lease from the preset subsystem template library through the graph matching model or graph embedding comparison algorithm;

[0044] The module splicing unit is used to call the corresponding basic function modules in the platform service component pool according to the module list marked in the selected template, and splice them in a predetermined logical order to generate a complete operating structure;

[0045] A communication compilation unit, configured to generate a robot management subsystem according to a task structure diagram and a robot set using a communication channel compiler;

[0046] The lifecycle management unit is used to establish a binding relationship with the lease ID during deployment, write the subsystem's activation status, operating stage, resource occupancy, abnormal status, and execution completion status into the lease management database, and release resources when the lease expires.

[0047] Furthermore, the service dependency mapping module specifically includes:

[0048] Semantic parsing unit, used to perform semantic parsing on processing task information, extract task elements, and convert them into a unified task description data structure;

[0049] a phase mapping unit, configured to establish a mapping relationship between the task phase and the first set of robots, and construct a robot-task phase mapping table;

[0050] The dependency reasoning unit is used to infer timing dependencies, service nesting dependencies, and data transfer dependencies based on task timing and service calls, and convert them into directed edges with attribute labels;

[0051] The graph generation unit is used to combine dependency edges and nodes to construct a directed service dependency graph, in which the nodes represent task stages or service module call units, and the edges represent service dependency paths.

[0052] Furthermore, the communication topology generation module specifically includes:

[0053] A communication requirement generation unit is used to extract a directed edge set from the service dependency graph, map the dependency relationship into communication requirements, and convert it into a communication requirement list;

[0054] A topology construction unit is used to construct a communication path topology graph according to communication requirements, where nodes represent robots, edges represent communication channels and their attributes, and are represented in the form of a directed weighted attribute graph;

[0055] Topology optimization unit, used to merge redundant paths, introduce backup paths, set forwarding rules, bandwidth restrictions, channel isolation, and edge weight adjustment for communication path topology;

[0056] The topology deployment unit is used to send the communication path topology to the robot communication module, edge scheduler and cloud platform monitoring module in the form of a structured configuration file or microservice API, and supports the communication link status monitoring and reconstruction mechanism.

[0057] Furthermore, the task execution control module specifically includes:

[0058] The task issuing unit is used to divide the task commands into stages and distribute them to robots according to the service dependency graph and communication path topology, generate a task instruction queue with binding trigger conditions, and send it through the logical communication channel;

[0059] The condition judgment unit is used to check whether the conditions of predecessor task completion, service data availability, system resource status and topological edge attributes are met after the robot receives the task command;

[0060] The task execution unit is used to complete action control, state synchronization, service call and data feedback according to instructions, and transmit execution information according to the communication path topology to support state exchange in collaborative control scenarios;

[0061] The feedback processing unit is used to upload status, record logs, and when a task is abnormal, perform rollback, retry, relay or interrupt the task according to the processing logic in the task instruction, and trigger dynamic adjustment of the service dependency graph and communication path topology.

[0062] Compared with the existing technology, the cloud platform-based robot dispatch management method and system proposed in the present invention has the following beneficial effects:

[0063] The present invention uses graph neural modeling to perform graph structure abstraction on the lease task parameters, combines the graph matching algorithm to automatically select functional templates from the template library, and forms a robot management subsystem with command control, communication scheduling, service binding and other functions based on the component pool. This makes the generation of the subsystem adaptive and sensitive to task scenarios, effectively solving the problems of subsystem structural rigidity and poor reusability in existing systems.

[0064] The present invention automatically derives communication requirements based on the task service dependency graph, constructs a directed weighted attribute graph as the communication path topology, and performs redundancy optimization, channel isolation, and dynamic bandwidth adjustment according to the task phase, service call, and data transmission strategy. This makes the communication structure more in line with the actual needs of the task, improves the communication stability and efficiency of multi-robot collaborative execution, and avoids resource waste and path failure.

[0065] The present invention binds the service dependency graph with the communication topology, issues task instructions to each robot instance through a logical channel, and implements task trigger judgment, service call coordination, and exception handling loops based on a state feedback mechanism, forming a scheduling-execution-feedback closed-loop control link with service dependency as the core, enhancing the system's perception and response capabilities to execution deviations, service anomalies, and robot failures.

[0066] The robot management subsystem in the present invention supports dynamic module loading, automatic compilation of logical communication channels, and on-demand binding of service interfaces. It also automatically releases resources after the task is completed or the lease is terminated, forming a complete lifecycle management process. This effectively improves the utilization efficiency of cloud platform resources and the controllability of the task system, and adapts to the service-oriented robot dispatch business needs.

[0067] In summary, the present invention provides a robot dispatch management solution with flexible structure, intelligent drive, adaptive communication, and a highly closed loop, which can significantly improve the scheduling intelligence level and system operation stability of the cloud platform in complex multi-tenant robot application scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0069] Figure 1 is a flow chart of the method of the present invention;

[0070] Figure 2 It is a system block diagram of the present invention. DETAILED DESCRIPTION

[0071] Below, the invention is preferably described with reference to the accompanying drawings and specific embodiments.

[0072] This embodiment solves the above problem through the following steps:

[0073] In one embodiment, reference Figure 1 The present invention provides a cloud-based robot dispatch management method, which is oriented towards a multi-tenant shared environment and implements robot state perception, task allocation, and communication management through the cloud platform. Specifically, the method includes the following steps:

[0074] Step S10: The cloud platform establishes communication connections with all robots.

[0075] Among them, the cloud platform refers to a centralized management system deployed on a remote server or data center with functions such as task management, data processing, communication coordination, and dispatch decision-making.

[0076] Robots refer to multiple industrial robot entities that collaborate with the cloud platform to perform tasks. The robots are equipped with the action modules, control modules and communication modules required to perform tenant tasks, and can access the network via wired or wireless means.

[0077] The communication connection refers to a two-way data exchange path established between the cloud platform and each robot through a network protocol, which is used to transmit task instructions, status information, execution feedback and control parameters. The communication connection supports but is not limited to TCP / IP protocol, MQTT protocol, WebSocket protocol, HTTP / HTTPS protocol or other industrial automation communication protocols, and can achieve physical layer connection through the public network, private LAN, 5G network, Wi-Fi or Ethernet.

[0078] The communication connection can be logically managed through a unified access control module, supporting the allocation of a unique identity, authentication credentials and communication channel to each connected robot.

[0079] This enables real-time monitoring of robot access status, data security protection, and dynamic allocation of communication resources, providing basic support for the issuance of subsequent dispatch instructions and coordination of task execution.

[0080] In step S20 , the cloud platform receives a robot lease from a tenant and parses the task parameters and resource information in the lease.

[0081] Among them, a robot lease refers to a structured job instruction document or digital contract submitted by a tenant to the cloud platform to request an industrial robot to complete a specified task within a specific time period. The lease includes task parameters, time windows, resource call permissions, service level requirements and execution constraints, and is suitable for the dispatch management of periodic, continuous or multi-stage robot operation tasks.

[0082] The cloud platform processes the lease through a lease parsing module, extracts task-related information and stores it in a lease management database to support the subsequent configuration of the robot management subsystem, the establishment of communication channels and the generation of task scheduling logic.

[0083] The task parameters include but are not limited to:

[0084] Task type, such as "periodic inspection", "batch handling", and "continuous operation of welding line";

[0085] Operational objectives, such as "Complete the continuous handling and stacking of 2,000 sets of parts";

[0086] Start and end time, for example, "The task starts at 08:00 on May 1, 2025, and ends at 18:00 on May 14, 2025";

[0087] The pace of work, for example, "8 hours a day, 100 round trips per hour";

[0088] Task scheduling rules, such as "Robot A will work in the morning, and Robot B will take over in the afternoon. The self-check module must be triggered between operations."

[0089] The resource information includes but is not limited to:

[0090] Specify a collection of robots, for example, "rent three six-axis robotic arms with ±0.02mm repeatability";

[0091] Service module dependencies, such as "need to call the platform visual recognition API and dynamic trajectory optimization module";

[0092] Communication requirements, such as "the robot status must be uploaded at a frequency of at least 1 Hz during operation, and abnormal status will trigger the emergency channel";

[0093] Task area binding, for example, "the operation is limited to workshop 3 and between lines F and J";

[0094] For example, a robot lease submitted by tenant A contains the following long-term task information:

[0095] Task type: "Robot arm continuous assembly";

[0096] Mission period: "June 10, 2025 to June 30, 2025";

[0097] Working hours: "09:00 to 21:00 every day, for 21 days";

[0098] Required robots: "2 six-axis industrial robots of model XXXXX";

[0099] Ancillary services: "Requires reliance on cloud-based visual recognition subsystem and welding path planning module";

[0100] Communication requirements: "A stable logical communication channel must be established to ensure that job logs and status information are aggregated to tenant terminals every day, and pushed to the cloud platform management end in real time when a fault alarm occurs."

[0101] Through the above analysis process, the cloud platform can generate a task-specific robot management subsystem for the tenant based on the task parameters and resource dependencies of the long-term task lease, and provide a basis for building the communication topology and service dependency structure in subsequent steps.

[0102] In step S30, the cloud platform establishes a robot management subsystem corresponding to the lease according to the lease.

[0103] Among them, the robot management subsystem refers to an operating unit dynamically created for each lease task in the cloud platform, which has independent communication control, scheduling logic and service deployment functions. This subsystem has task logic encapsulation, resource control boundaries and status tracking capabilities, and is used to support the division of labor execution, service calls and information flow closure of lease tasks among multiple robots.

[0104] Furthermore, the robot management subsystem is established using a task scenario driven generation mechanism, specifically including the following steps:

[0105] Step S31: Task requirement graph analysis and subsystem template selection

[0106] The cloud platform models the task parameters in the lease through graph neural modeling, that is, abstracting task parameters such as task type, time window, required robot type, expected operation path, service module call sequence and other information into a graph structure, where each node represents a functional requirement or resource entity, and the edge represents a call relationship or constraint logic. After the graph structure is input into the task configuration engine, the cloud platform selects the functional template that best matches the task structure semantics in the lease from the preset subsystem template library through a trained graph matching model or graph embedding comparison algorithm.

[0107] The subsystem template defines execution logic such as task instruction format (such as sequential control, conditional jump), communication interface layout (such as multi-robot message bus, point-to-point connection), service combination strategy (such as the series and parallel order of service modules) and scheduling mode (such as fixed priority, load balancing, time slice scheduling).

[0108] This step uses graph neural network modeling to model the task parameters in the lease. The core idea is to convert structured and semi-structured task descriptions into a learnable graph representation. This graph structure not only captures the physical elements of the task (such as robot type and service module), but also represents the dependencies, order, and parallel relationships between them. The task structure is then embedded using a graph neural network (GNN). Combined with a graph matching mechanism, the most suitable subsystem template is automatically matched, achieving task-driven subsystem generation.

[0109] The mechanism is based on the following two core principles:

[0110] Map lease task parameters to a graph ,in Represents the task function node (such as task type, robot, service module, etc.), Represents the calling relationship, resource dependency, or execution constraints (such as timing, spatial order, and control logic) between functional nodes;

[0111] Embed the task graph into a structural representation in a multidimensional vector space through a trained graph neural network (such as GCN, GAT) , and the standard function template diagram embedded in the template library Perform similarity comparison (such as cosine similarity, Euclidean distance, or subgraph kernel function) and select the template with the most similar structural semantics as the subsystem design blueprint for the current lease task.

[0112] In a specific implementation, the task parameters included in the lease submitted by the tenant include but are not limited to:

[0113] Task type (such as assembly, inspection, welding, handling, etc.);

[0114] Time windows (execution cycles, shift schedules, etc.);

[0115] The type and quantity of robots required (e.g., AGV, collaborative arm, six-axis arm, etc.);

[0116] Job path or sequence;

[0117] Service module call requirements (such as visual recognition, trajectory planning, collision detection, etc.).

[0118] The platform first performs structured extraction of the above parameters and marks each functional element and its relationship.

[0119] Based on the extraction results, build the task graph structure ,

[0120] node Contains task stages, robot resources, and external services;

[0121] side It represents the dependency path between task stages and the calling relationship between robots and service modules. The attributes of the edge can include execution timing (sequential relationship), communication direction, priority, etc.

[0122] The platform designs several standard task structures based on historical lease data and typical industry task processes (such as assembly, welding, testing, transportation, etc.). Each task structure is modeled as a task graph.

[0123] Different task graphs that semantically belong to the same task type are labeled as “positive sample pairs”.

[0124] Graph pairs with different task types or large differences in structural dependencies are regarded as “negative sample pairs”.

[0125] The GCN (Graph Convolutional Network) network in the existing technology is used, and the graph contrast loss function is adopted for supervised training to obtain a pre-trained graph neural network.

[0126] The graph to be matched Input the pre-trained graph neural network to generate the global structure embedding vector of the graph This vector can comprehensively express the semantic features of the task structure, node type distribution and edge relationship. Multiple subsystem function templates are pre-established in the platform. , and store its embedding vector The optimal matching template is selected using a similarity calculation function (such as cosine similarity). This implementation enables unified modeling and automatic matching for tasks with complex structures, multiple service dependencies, and heterogeneous robot types, eliminating the need for manual configuration or static template selection, thereby improving platform adaptability. Automatic template retrieval through graph matching, combined with a modular splicing mechanism, enables highly automated subsystem construction, improving scheduling flexibility and component reuse in multi-tenant environments.

[0127] Step S32: Subsystem modular instance generation

[0128] After matching the adapted functional template, the cloud platform calls the corresponding basic functional modules in the platform service component pool according to the module list marked in the template, and splices them in a predetermined logical order to generate a complete operating structure.

[0129] These modules include but are not limited to:

[0130] Task instruction orchestration module: responsible for parsing tenant tasks and converting them into control instruction sequences that can be recognized by the robot;

[0131] Communication control and traffic control module: responsible for managing communication frequency, data transmission strategy and channel bandwidth usage;

[0132] Service interface adaptation and binding module: used to connect various AI or functional services provided by the platform, such as visual recognition API, path optimization services, etc.

[0133] Status monitoring and feedback collection module: used to collect the status of each robot and task execution status in real time and feedback to the cloud or tenant terminal;

[0134] Robot resource scheduling module: assign tasks and perform parallel collaborative control of multiple robots based on task progress and resource availability.

[0135] The above modules all exist in the form of containers, microservices or lightweight pluggable components, allowing the system to dynamically load, combine and recycle on demand, forming a highly elastic and adaptable subsystem execution structure.

[0136] Step S33: Communication logic compilation and distribution

[0137] Since different leases involve different numbers and types of robots, and parameters such as communication requirements, communication security levels, and data feedback frequency vary greatly, the cloud platform uses a communication channel compiler to generate a dedicated communication topology structure based on the task structure diagram and the robot collection.

[0138] In the communication topology, the connection method, data transmission direction, transmission timing and transmission content between different robot nodes are all defined by the configuration logic. For example: for high-precision collaborative action tasks, a periodic synchronization and message confirmation mechanism is adopted; for low-latency alarm tasks, an event-driven and broadcast mechanism is adopted; for image data, a compressed upload and asynchronous processing strategy is adopted.

[0139] The generated communication strategy file will be sent to the edge node in the form of a configuration file or microservice image, so that the edge computing unit can deploy and activate the local communication network based on it, and realize real-time data connection between robots and between robots and cloud platforms.

[0140] Step S34: State synchronization and lifecycle management

[0141] To ensure orderly resource use and controllable task execution, the robot management subsystem establishes a strong binding relationship with the lease ID during deployment. Each subsystem is included in the unified lifecycle management process of the cloud platform before and after task execution.

[0142] The subsystem's activation status, operating stage, resource occupancy, abnormal status, and execution completion status will be written to the lease management database in real time. When the lease expires or the task is terminated, the subsystem automatically stops all task distribution behaviors, releases the corresponding logical communication channel and service interface, reclaims module resources, and avoids resource occupation and retention.

[0143] In addition, during operation, the subsystem will continuously feedback task status, robot operation logs, exception information and performance evaluation results to the tenant terminal, providing tenants with complete traceability and operation transparency, while providing data support for subsequent dispatch optimization model training.

[0144] For example, a tenant submits a two-week lease for a robotic welding task, requiring the use of robots A, B, and C, as well as visual recognition and trajectory planning services. The cloud platform automatically builds the following subsystems through the above steps:

[0145] Extract the task map of "welding tasks + multi-robot collaboration + vision / path service dependency";

[0146] Match the welding subsystem template and automatically assemble the required control modules;

[0147] Compile the communication path: A→B→Visual→Path→C;

[0148] Deploy to edge nodes and enter the activation state;

[0149] After the lease expires, the system reclaims the channel and service and releases scheduling resources.

[0150] In this step, through task graph modeling and template matching, the generation of the robot management subsystem no longer relies on fixed patterns, but has the ability to adaptively build on demand, which can cover a variety of industrial task types; the subsystem structure is constructed by modular splicing, which has high scalability and reusability, and is suitable for complex and changeable task scenarios; the introduction of a communication channel compilation mechanism allows the communication topology to be dynamically adjusted according to tasks and network conditions, improving communication efficiency and system robustness; the full process binding, state traceability and automatic release of the subsystem life cycle are achieved, enhancing the system's resource management capabilities and controllability; it has good horizontal adaptability, can support multi-tenant concurrent deployment, heterogeneous robot access and multi-platform service collaboration, and is an important basic support solution for the "Robot as a Service (RaaS)" model.

[0151] Step S40: The robot management subsystem establishes a logical communication channel with each robot in the first robot set according to the first robot set specified in the lease.

[0152] The first robot set refers to one or more robot entities explicitly designated by the tenant in the lease to participate in task execution. The robots have remote scheduling, network communication, and task response capabilities, and may include heterogeneous robots of the same or different models. The first robot set can be spatially distributed in the same operating area or deployed across multiple physical spaces. The logical communication channel refers to the information transmission path between robots that is dynamically configured and virtually generated by the robot management subsystem under the control of the unified communication rules of the cloud platform, based on task execution needs and tenant agreed policies. This channel is not a direct correspondence to a physical link, but a logical data interaction mechanism built on the network protocol, supporting multiple communication types and transmission methods, including but not limited to:

[0153] Point-to-point communication, used to synchronize status or control information directly between robots;

[0154] Publish-subscribe communication, used for master-slave or broadcast task data transmission;

[0155] Multicast / groupcast communication, used for group synchronization behavior under collaborative tasks;

[0156] Asynchronous task signal channel, used for event notifications such as fault reporting, task switching, or emergency interruption.

[0157] Specifically, the robot management subsystem performs the following operations to establish a logical communication channel:

[0158] Identity authentication and mapping initialization: assign a unique logical address and session identifier to each robot in the first robot set, establish its routing mapping table in the communication domain, and ensure that the robot identity is unique and isolated within the scope of this lease task; channel configuration generation: according to the execution mode of the task in the lease, the collaboration logic between robots and the service dependency structure, select the matching communication template from the communication strategy library, and automatically generate the corresponding channel configuration parameters, including communication source / destination pairs, data format specifications, transmission frequency, synchronization mechanism, security protocol, etc.; topology structure injection and protocol matching: inject the channel configuration into the communication topology management module, and according to the type of deployed network (such as Wi-Fi, 5G, industrial Ethernet) matches the corresponding communication protocol stack and performs protocol adaptation and modulation strategy settings for the transmission content. For example, compressed transmission is used for image data, and retransmission and confirmation mechanisms are enabled for key control commands. Channel activation and connection test: After completing channel configuration, the subsystem sends an initialization instruction to the first robot set, starts the communication module of each node and performs a connection test. If the test passes, the logical communication channel is officially enabled. Dynamic adjustment and fault-tolerant mechanism: During task execution, the communication module supports dynamic adjustment of frequency and transmission strategy according to the robot status, channel load and task progress, and automatically starts the backup channel or delayed retransmission mechanism in the event of node failure or link abnormality to ensure communication continuity and robustness.

[0159] In addition, the logical communication channel can be connected to the data center of the cloud platform, supporting real-time monitoring of communication status, logging and bandwidth statistics, and providing support for system scheduling, debugging and tenant visualization.

[0160] Step S50: The robot management subsystem determines the service dependency relationship between the first robot sets according to the processing task information in the lease, and constructs a corresponding service dependency graph.

[0161] Among them, processing task information refers to the industrial operation tasks defined by the tenant in the lease and required to be completed by multiple robots in collaboration, including task flow description, process sequence, task decomposition structure, robot function constraints, service call requirements and data flow requirements.

[0162] Furthermore, the robot management subsystem adopts a service dependency modeling method based on the combination of task semantic analysis and collaborative topology reasoning to construct a corresponding service dependency graph, which specifically includes the following steps:

[0163] Step S51: Task semantic structure analysis

[0164] The robot management subsystem first performs semantic analysis on the processing task information and extracts the task elements that can be modeled, including:

[0165] Task stage list: process steps divided in logical order, such as task stage = {blank grabbing, positioning detection, rough machining, finishing, transporting and warehousing};

[0166] Robot function mapping: The robot capabilities required for each stage, such as "blank grasping" requires AGV, "rough processing" requires a six-axis robot arm;

[0167] Service module call requirements: specify the external services that need to be called in the stage, such as "positioning detection" needs to call "visual recognition service";

[0168] Data transfer requirements: The state / image / recognition result output from one stage serves as the basis for the input of the next stage;

[0169] Coordination timing requirements: such as "Phase A and Phase B can be executed in parallel" or "Phase B must wait for Phase A to complete."

[0170] This process can be completed through natural language structure annotation + task template matching + label extraction model, and converted into a unified task description data structure.

[0171] Step S52: Robot-task phase mapping relationship construction

[0172] Based on the task phase structure obtained in step S51, the system performs functional matching between the task phase and the first robot set specified in the lease, and establishes the following correspondence:

[0173] “Blank Grasping” → AGV Robot R1;

[0174] "Positioning Detection" → Collaborative Robot Arm R2 + Calling Visual Recognition Service V;

[0175] "Rough machining" → six-axis industrial robot R3;

[0176] "Finishing" → Six-axis industrial robot R4;

[0177] “Transporting and warehousing” → AGV robot R5.

[0178] Based on this, the system constructs a "robot-stage" mapping table and marks the service dependency requirements. For example, "visual service V" needs to be called by robot R2 and triggered during the "positioning detection" process.

[0179] Step S53: Dependency Relationship Reasoning and Dependency Edge Generation

[0180] Based on the mapping table and process timing requirements, the subsystem automatically infers the following dependencies:

[0181] Timing dependency:

[0182] R1 (grasping) → R2 (inspection), indicating that the blank must be transported to the inspection area before inspection can be carried out;

[0183] R2 → R3, the qualified test result is used as the starting condition for rough machining;

[0184] R3 → R4, finishing is performed only after roughing is completed;

[0185] R4 → R5, the finished product is delivered to the warehouse by the handling robot;

[0186] Service dependencies:

[0187] R2 needs to bind and call the visual recognition service V, forming a nested dependency of R2→V;

[0188] R3 and R4 call the path optimization module P at the same time (if there is a risk of path conflict), forming a competitive shared dependency;

[0189] Data delivery dependencies:

[0190] The image result output by R2 is used as the input of R3 process;

[0191] The processing completion status output by R3 is used as the signal for starting R4.

[0192] All dependencies are converted into directed edges with the following properties:

[0193] Dependency type (timing / service / data);

[0194] Calling mode (blocking / non-blocking);

[0195] Execution conditions (previous task success / success + timeout);

[0196] Edge weight (indicating priority or communication strength).

[0197] Step S54: Service dependency graph construction

[0198] The system eventually constructs the above structured information into a service dependency graph, which is as follows:

[0199] Node set N = {R1, R2, V, R3, P, R4, R5};

[0200] Edge set E = { (R1→R2),

[0201] (R2→V),

[0202] (V→R2),

[0203] (R2→R3),

[0204] (R3→P),

[0205] (R4→P),

[0206] (P→R3),

[0207] (R3→R4),

[0208] (R4→R5)}

[0209] The graph is a directed graph structure and can have the following advanced features:

[0210] Support graph traversal sorting to generate task execution order;

[0211] Can be used for graph partitioning scheduling strategy (dividing tasks into parallel subgraphs);

[0212] Can be used for fault recovery: if a node fails, its predecessor node can be traced back to determine whether it can be skipped or replaced;

[0213] It can be directly used for subsequent communication path generation and task control flow injection.

[0214] Specifically and demonstratively:

[0215] Assume that tenant A submits the following task lease:

[0216] Processing task: continuous assembly task, cycle time is two weeks;

[0217] Robot collection: R1 (AGV), R2 (collaborative arm), R3 / R4 (six-axis arm), R5 (AGV);

[0218] Service modules: visual recognition (V), trajectory planning (P);

[0219] Task phase: grabbing → testing → processing → handling;

[0220] Requirements: The task will be carried out in two shifts every day, and status confirmation and feedback will be required between each stage;

[0221] Process constraints: Processing is required after inspection, and a copy of the inspection image must be retained and sent to the tenant terminal;

[0222] The system builds a service dependency graph (SDG) through the above steps, forming a task scheduling framework. This dependency graph is then used to:

[0223] Automatically generate communication topology diagram;

[0224] Control the robot to execute the flow;

[0225] Trigger service module;

[0226] Respond to tenant-side visual monitoring and data feedback.

[0227] In this step, by structurally expressing task process information as a graph structure, the service and control dependencies between robots are made formal, reconfigurable, and verifiable. A multi-dimensional reasoning mechanism of task-robot-service-data is adopted to solve the problem that the existing scheduling system has weak modeling capabilities for complex collaborative behaviors. The service dependency graph is used for scheduling, communication routing, and task tracking, and is a core intermediate expression structure that is cross-module and multi-layered. The graph model supports parallel computing, distributed deployment, elastic scheduling, and abnormal reconstruction, and has engineering feasibility and scalability.

[0228] Step S60: The robot management subsystem generates a communication path topology within the first robot set based on the service dependency graph, so as to guide collaborative communication between robots.

[0229] Among them, the communication path topology refers to a directed communication graph structure generated by the robot management subsystem based on the task execution dependency and oriented towards the internal part of the robot cluster. This topology is used to define the communication links, message exchange methods, transmission timing, synchronization requirements and priority order that should be established between robots during task execution, so as to achieve reliable connection of task flow, collaborative control, state feedback and logical closed loop of service call links.

[0230] This path topology is not limited to the physical network topology, but is built on the basis of the service dependency graph, mapping the communication behavior patterns and collaboration strategies of the robots.

[0231] The process of generating the communication path topology includes the following steps:

[0232] Step S61: Service dependency graph structure analysis

[0233] The robot management subsystem first extracts a set of directed edges from the service dependency graph obtained in step S50, where each edge represents a dependency relationship (data, service, control, resource), and maps it to "communication needs".

[0234] For example, if the service dependency graph contains the edge R1 → R2, which means that the grasping task completed by robot R1 is a prerequisite for the detection task of R2, then a data transmission channel needs to be established from R1 to R2 to transmit the completion signal or object status.

[0235] The subsystem converts all such dependency edges into a unified list of communication requirements, each of which includes:

[0236] Communication source node (sender robot);

[0237] Communication target node (receiving robot or service module);

[0238] Communication content (task completion mark, image data, control signal, etc.);

[0239] Communication timing requirements (real-time / delay acceptable / periodic);

[0240] Transmission mode (unicast, broadcast, multicast);

[0241] Communication reliability requirements (whether ACK confirmation is required, whether retries are allowed);

[0242] Priority label (high, medium, low);

[0243] Encryption flag (whether end-to-end encryption is enabled).

[0244] Step S62: Communication channel allocation and topology construction

[0245] The system constructs a communication path topology diagram based on the analyzed communication requirements, which is expressed as:

[0246] Node Set , represents the robots in the first robot set;

[0247] Edge Set , represents the communication channel and its attributes;

[0248] Each edge is accompanied by a communication strategy attribute attr, including:

[0249] Data format;

[0250] Transport protocols (e.g., MQTT, DDS, TCP, UDP);

[0251] Encryption / compression configuration;

[0252] Communication frequency (e.g. 5Hz status push, 0.2Hz image upload);

[0253] Abnormal recovery strategy (alternative path, number of retries, etc.).

[0254] The communication path topology can be represented as a directed weighted attribute graph for direct reading and execution by edge controllers, schedulers, or robot communication agents.

[0255] Step S63: Topology optimization and redundancy configuration

[0256] To improve system robustness and fault tolerance, the subsystem optimizes the initial topology, including:

[0257] Merging redundant paths (e.g., multiple robots sending repeated messages to the same destination);

[0258] Introduce backup paths and set priority forwarding rules;

[0259] Set bandwidth limits or channel isolation for core communication nodes;

[0260] Introduce a dynamic edge weight adjustment mechanism (adjust communication intensity according to task stage or network load).

[0261] The topology optimization is completed by the dynamic communication planning module, which can integrate graph optimization algorithms (such as minimum spanning tree, multi-source path optimization, and communication load balancing) for adjustment.

[0262] Step S64: Communication path topology deployment and activation

[0263] The generated and optimized communication path topology will be delivered in the form of a structured configuration file (such as JSON) or a microservice API to:

[0264] Communication modules of each robot;

[0265] Edge node task scheduler;

[0266] Cloud platform monitoring module.

[0267] Once the communication path is activated, the robots will perform collaborative communication according to the link relationship defined by the topology diagram, including task synchronization, status feedback, service call and exception reporting.

[0268] The system can regularly monitor the status of communication links. If it detects high packet loss rate, abnormal delay, node inactivity, etc., it will automatically trigger the topology reconstruction logic or channel migration mechanism.

[0269] For example, based on the welding task service dependency graph in the previous step, the robot set is set:

[0270] R1 (AGV, grasping);

[0271] R2 (collaboration arm, detection);

[0272] R3 (six-axis, rough machining);

[0273] R4 (six-axis, finishing);

[0274] R5 (AGV, handling);

[0275] Service modules V (visual recognition), P (trajectory planning).

[0276] After analysis, the following communication path topology needs to be established:

[0277] R1 → R2: state synchronization, unicast, event-driven;

[0278] R2 → V: Image upload, request service call, point-to-point;

[0279] V → R2: The recognition result is sent, including the error code, with high reliability;

[0280] R2 → R3: Push the qualified test mark and confirm the message;

[0281] R3 → P, R4 → P: service shared path with access queue;

[0282] P → R3 / R4: Return trajectory data with timestamp;

[0283] R4 → R5: Task completion instruction, transfer parameters are issued.

[0284] In this step, communication requirements are automatically derived based on the service dependency graph, and the system can dynamically generate the most appropriate topology according to the task. The communication path is expressed in the form of a graph, achieving high consistency between the behavior orchestration and logical closed loop among multiple robots. The communication graph can be optimized and reconstructed based on task progress and network load, and has system flexibility. This topology diagram not only guides communication but also provides a structural foundation for scheduling, exception management, and data feedback.

[0285] Step S70: Each robot in the first robot set receives and executes the task command issued by the robot management subsystem in sequence according to the communication path topology.

[0286] This step includes the following sub-operations:

[0287] Step S71: Task Command Issuance and Node Distribution The robot management subsystem generates task commands in stages and distributes them to robots based on the service dependency graph and communication path topology, specifically including:

[0288] Generate a task instruction queue bound to each robot instance;

[0289] Each task instruction is bound to a trigger condition (e.g., "receive completion signal from the leading robot");

[0290] The instruction format uses structured commands (such as JSON / XML), which include operation type, target parameters, service call information, and error handling logic; the instruction is sent to the corresponding robot communication module through the logical communication channel and queued on the robot side for execution.

[0291] The commands received locally by each robot correspond to its task topology position, ensuring contextual consistency in command transmission.

[0292] Step S72: Task triggering and condition checking mechanism

[0293] After receiving a command, each robot does not execute it immediately. Instead, it uses the following mechanism to determine whether the execution conditions are met:

[0294] Predecessor task completion confirmation: Confirm the successful execution of the previous robot task through the communication channel;

[0295] Completeness of service return data: If visual recognition or path planning is required, you need to wait for the results of the called service;

[0296] System resource status: such as whether the robotic arm is idle and whether the sensor is responding normally;

[0297] Verification of topological edge attributes: such as whether the specified time point has been reached and whether the synchronization signal has been received.

[0298] Only instructions that meet all execution conditions will be pushed into the control module execution stack.

[0299] Step S73: Task execution and collaborative control

[0300] The robot enters the actual execution phase and completes the following actions according to the task instructions:

[0301] Start motion control (such as grasping, handling, processing, etc.);

[0302] Synchronously obtain or output status information (such as "task started", "task completed");

[0303] Start service module interfaces (such as image acquisition, path tracking, and force control feedback);

[0304] Send execution status, data packets, and feedback results to subsequent robots or service modules defined by the communication path in real time.

[0305] If the system uses a collaborative control strategy (such as master-slave collaboration or multi-robot relay), the robots must continuously exchange states during execution to ensure coordination and consistency. For example:

[0306] R1 moves the goods to the destination → notifies R2 → R2 conducts inspection;

[0307] R2 completes inspection → notifies R3 → R3 performs processing.

[0308] Communications in such processes are automatically established and scheduled according to the communication path topology.

[0309] Step S74: Task feedback and exception handling

[0310] During the execution of the task, each time the robot completes an instruction, it needs to provide feedback as follows:

[0311] The status is uploaded to the robot management subsystem (cloud platform) and downstream robots;

[0312] Write execution logs to local and cloud data recording modules;

[0313] If an error occurs (e.g., execution failure, mechanical failure, data loss), one of the following strategies will be executed based on the exception handling logic in the task instructions:

[0314] Notify the predecessor node to roll back or resend;

[0315] Request the service module to recalculate;

[0316] Start the backup robot to perform task relay;

[0317] Send an alarm message to the tenant terminal and interrupt the task.

[0318] The robot management subsystem dynamically updates the service dependency graph and communication path topology based on feedback information, and performs structural reconstruction and task adjustment when necessary.

[0319] For example:

[0320] Continuing with the previous example:

[0321] R1 (AGV) completes the blank grabbing → sends a "transportation completed" signal to R2;

[0322] R2 (collaborative arm) starts the detection task based on the received signal + visual recognition results;

[0323] R2 sends the image to the visual module V → After receiving the recognition result, it sends a "qualified" signal to R3;

[0324] R3 performs rough machining → the result is notified to R4 for finishing;

[0325] After R4 is completed, notify R5 to move the goods into the warehouse;

[0326] In the above process:

[0327] All control processes and communication behaviors are constrained by the communication path topology;

[0328] Each robot only receives commands corresponding to its role in the service dependency graph;

[0329] All actions are equipped with a precursor state judgment and feedback mechanism to form a closed-loop control.

[0330] See also Figure 2 In another embodiment, the present invention further provides a cloud platform-based robot dispatch management system, comprising:

[0331] Communication module, used to establish communication connection between the cloud platform and all robots;

[0332] A lease receiving and parsing module, configured to receive a robot lease from a tenant and parse the task parameters and resource information in the lease;

[0333] A subsystem construction module, configured to establish a robot management subsystem corresponding to the lease according to the lease;

[0334] a communication channel building module, configured to establish a logical communication channel with each robot in the first robot set according to the first robot set specified in the lease;

[0335] a service dependency graph building module, configured to determine the service dependency relationship between the first set of robots based on the processing task information in the lease, and to build a corresponding service dependency graph;

[0336] a communication topology generation module, configured to generate a communication path topology within the first set of robots based on the service dependency graph, for guiding collaborative communication between the robots;

[0337] The task execution control module is used to enable each robot in the first robot set to sequentially receive and execute the task command issued by the robot management subsystem according to the communication path topology.

[0338] In a further implementation, the subsystem building module specifically includes:

[0339] Graph modeling unit, used to model and abstract the task parameters in the lease into a graph structure, where each node represents a functional requirement or resource entity, and the edge represents a call relationship or constraint logic;

[0340] The template matching unit is used to input the graph structure into the task configuration engine and select the function template that best matches the task structure semantics in the lease from the preset subsystem template library through the graph matching model or graph embedding comparison algorithm;

[0341] The module splicing unit is used to call the corresponding basic function modules in the platform service component pool according to the module list marked in the selected template, and splice them in a predetermined logical order to generate a complete operating structure;

[0342] A communication compilation unit, configured to generate a robot management subsystem according to a task structure diagram and a robot set using a communication channel compiler;

[0343] The lifecycle management unit is used to establish a binding relationship with the lease ID during deployment, write the subsystem's activation status, operating stage, resource occupancy, abnormal status, and execution completion status into the lease management database, and release resources when the lease expires.

[0344] In a further implementation, the service dependency mapping module specifically includes:

[0345] Semantic parsing unit, used to perform semantic parsing on processing task information, extract task elements, and convert them into a unified task description data structure;

[0346] a phase mapping unit, configured to establish a mapping relationship between the task phase and the first set of robots, and construct a robot-task phase mapping table;

[0347] The dependency reasoning unit is used to infer timing dependencies, service nesting dependencies, and data transfer dependencies based on task timing and service calls, and convert them into directed edges with attribute labels;

[0348] The graph generation unit is used to combine dependency edges and nodes to construct a directed service dependency graph, in which the nodes represent task stages or service module call units, and the edges represent service dependency paths.

[0349] In a further implementation, the communication topology generation module specifically includes:

[0350] A communication requirement generation unit is used to extract a directed edge set from the service dependency graph, map the dependency relationship into communication requirements, and convert it into a communication requirement list;

[0351] A topology construction unit is used to construct a communication path topology graph according to communication requirements, where nodes represent robots, edges represent communication channels and their attributes, and are represented in the form of a directed weighted attribute graph;

[0352] Topology optimization unit, used to merge redundant paths, introduce backup paths, set forwarding rules, bandwidth restrictions, channel isolation, and edge weight adjustment for communication path topology;

[0353] The topology deployment unit is used to send the communication path topology to the robot communication module, edge scheduler and cloud platform monitoring module in the form of a structured configuration file or microservice API, and supports the communication link status monitoring and reconstruction mechanism.

[0354] In a further implementation, the task execution control module specifically includes:

[0355] The task issuing unit is used to divide the task commands into stages and distribute them to robots according to the service dependency graph and communication path topology, generate a task instruction queue with binding trigger conditions, and send it through the logical communication channel;

[0356] The condition judgment unit is used to check whether the conditions of predecessor task completion, service data availability, system resource status and topological edge attributes are met after the robot receives the task command;

[0357] The task execution unit is used to complete action control, state synchronization, service call and data feedback according to instructions, and transmit execution information according to the communication path topology to support state exchange in collaborative control scenarios;

[0358] The feedback processing unit is used to upload status, record logs, and when a task is abnormal, perform rollback, retry, relay or interrupt the task according to the processing logic in the task instruction, and trigger dynamic adjustment of the service dependency graph and communication path topology.

[0359] It should be noted that the explanation of the aforementioned cloud platform-based robot dispatch management method embodiment is also applicable to the device of the embodiment of the present application and will not be repeated here.

[0360] Those skilled in the art will appreciate that the various units and algorithm steps described in the embodiments disclosed herein can be implemented using a combination of electronic hardware, computer software, and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0361] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0362] In the several embodiments provided in this application, if any function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of this application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory; hereinafter referred to as: ROM), random access memory (Random Access Memory; hereinafter referred to as: RAM), magnetic disk or optical disk, and other media that can store program code.

[0363] The above is only a specific embodiment of the present application. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in this application, which should be included in the scope of protection of this application. For some module structures that are not particularly clear in the present invention, the content recorded in the prior art shall prevail. The prior art mentioned in the above background technology section and the specific embodiment section of the present invention can be regarded as part of the present invention and is used to understand the meaning of some technical features or parameters.

Claims

1. A robot dispatch management method based on a cloud platform, characterized in that: The method comprises the following steps: The cloud platform establishes communication connections with all robots; The cloud platform receives a robot lease from a tenant and parses the task parameters and resource information in the lease; The cloud platform establishes a robot management subsystem corresponding to the lease in a one-to-one manner according to the lease; The robot management subsystem establishes a logical communication channel with each robot in the first robot set according to the first robot set specified in the lease; The robot management subsystem determines the service dependency relationship between the first robot set based on the processing task information in the lease, and constructs a corresponding service dependency graph; The robot management subsystem generates a communication path topology within the first robot set based on the service dependency graph, for guiding collaborative communication between robots; Each robot in the first robot set receives and executes the task command issued by the robot management subsystem in sequence according to the communication path topology; The establishment of a robot management subsystem corresponding to the lease specifically includes: The cloud platform models the task parameters in the lease as a graph structure, where each node represents a functional requirement or resource entity, and the edge represents a call relationship or constraint logic. After the graph structure is input into the task configuration engine, the cloud platform uses the trained graph matching model or graph embedding comparison algorithm to select the function template that best matches the task structure semantics in the contract from the preset robot management subsystem template library; The cloud platform calls the corresponding basic function modules in the platform service component pool according to the module list marked in the selected template, and splices them in a predetermined logical order to generate a complete operating structure; The cloud platform uses a communication channel compiler to generate a robot management subsystem based on the task structure diagram and the robot set; The robot management subsystem establishes a binding relationship with the lease ID during deployment and is included in the unified lifecycle management process before and after task execution. The activation status, operation stage, resource occupancy, abnormal status and execution completion status of the robot management subsystem are written into the lease management database in real time. When the lease expires or the task is terminated, the robot management subsystem stops task distribution, releases the corresponding logical communication channel and service interface, and reclaims module resources.

2. The cloud platform-based robot dispatch management method according to claim 1, characterized in that: The construction of the service dependency graph specifically includes the following steps: The robot management subsystem performs semantic analysis on the processing task information, extracts the task elements, and converts them into a unified task description data structure; The robot management subsystem establishes a correspondence between the mission phase and the first set of robots specified in the lease, and constructs a robot-phase mapping table, while marking the service call and trigger relationship; The robot management subsystem infers timing dependencies, service nesting dependencies, and data transfer dependencies based on task phase timing and service call requirements, and converts the above dependencies into directed edges with attribute labels; The robot management subsystem combines dependency edges and nodes to construct a directed service dependency graph, in which nodes represent robot task stages or service module call units, and edges represent service dependency paths between tasks.

3. The cloud platform-based robot dispatch management method according to claim 1, characterized in that: The generation of the communication path topology specifically includes: The robot management subsystem extracts a directed edge set from the service dependency graph, maps the dependency relationship represented by each edge into a communication requirement, and uniformly converts it into a communication requirement list; The robot management subsystem constructs a communication path topology graph according to the communication requirements, wherein the nodes represent robots in the first robot set, the edges represent communication channels and their attributes, and the communication path topology is represented as a directed weighted attribute graph for execution by the edge controller, the task scheduler, or the robot communication agent; The robot management subsystem optimizes the communication path topology, including merging redundant paths, introducing backup paths, setting priority forwarding rules, bandwidth restrictions, channel isolation, and dynamic adjustment of edge weights; The robot management subsystem sends the communication path topology to each robot communication module, edge node scheduler and cloud platform monitoring module in the form of structured configuration files or microservice APIs. After the communication path is activated, it guides the robot to perform task synchronization, status feedback, service call and exception reporting. The communication link status supports periodic monitoring. If a communication anomaly is detected, it automatically triggers the topology reconstruction or channel migration mechanism.

4. The cloud platform-based robot dispatch management method according to claim 1, characterized in that: The process of the robots in the first robot set executing the task command according to the communication path topology comprises the following steps: The robot management subsystem generates task commands in stages and distributes them to robots based on the service dependency graph and communication path topology. It generates a task instruction queue bound to each robot instance, binds each task instruction to a trigger condition, and sends the instruction to the corresponding robot communication module through a logical communication channel. The instruction is queued on the robot side and waits for execution. After receiving a command, each robot determines whether it meets the execution conditions, including confirmation of the completion of the predecessor task, the completeness of the service return data, and verification of the resource status and topological edge attributes of the robot management subsystem. Only instructions that meet all the execution conditions will be pushed into the control module execution stack. The robots complete action control, state synchronization, service interface calls, and result feedback according to task instructions, and transmit execution status or data packets to subsequent nodes according to the communication path topology. When the collaborative control strategy is enabled, the robots continuously exchange state information to ensure consistent collaborative actions. After completing the task instructions, the robot uploads status information and records the execution log. If an error occurs, the robot will perform rollback, retry, backup robot relay or interruption of the task according to the exception handling logic in the task instructions. The robot management subsystem dynamically updates the service dependency graph and communication path topology based on task feedback, and performs structural reconstruction and task adjustment.

5. A robot dispatch management system based on a cloud platform, characterized in that: The system includes the following modules: Communication module, used to establish communication connection between the cloud platform and all robots; A lease receiving and parsing module, configured to receive a robot lease from a tenant and parse the task parameters and resource information in the lease; A subsystem construction module, configured to establish a robot management subsystem corresponding to the lease according to the lease; a communication channel building module, configured to establish a logical communication channel with each robot in the first robot set according to the first robot set specified in the lease; a service dependency graph building module, configured to determine the service dependency relationship between the first set of robots based on the processing task information in the lease, and to build a corresponding service dependency graph; a communication topology generation module, configured to generate a communication path topology within the first set of robots based on the service dependency graph, for guiding collaborative communication between the robots; a task execution control module, configured to enable each robot in the first robot set to sequentially receive and execute task commands issued by the robot management subsystem according to the communication path topology; The subsystem building blocks specifically include: Graph modeling unit, used to model and abstract the task parameters in the lease into a graph structure, where each node represents a functional requirement or resource entity, and the edge represents a call relationship or constraint logic; The template matching unit is used to input the graph structure into the task configuration engine and select the function template that best matches the task structure semantics from the preset subsystem template library through the graph matching model or graph embedding comparison algorithm; The module splicing unit is used to call the corresponding basic function modules in the platform service component pool according to the module list marked in the selected template, and splice them in a predetermined logical order to generate a complete operating structure; A communication compilation unit, configured to generate a robot management subsystem according to a task structure diagram and a robot set using a communication channel compiler; The lifecycle management unit is used to establish a binding relationship with the lease ID during deployment, write the subsystem's activation status, operating stage, resource occupancy, abnormal status, and execution completion status into the lease management database, and release resources when the lease expires.

6. The cloud platform-based robot dispatch management system according to claim 5, characterized in that: The service-dependent mapping module specifically includes: Semantic parsing unit, used to perform semantic parsing on processing task information, extract task elements, and convert them into a unified task description data structure; a phase mapping unit, configured to establish a mapping relationship between the task phase and the first set of robots, and construct a robot-task phase mapping table; The dependency reasoning unit is used to infer timing dependencies, service nesting dependencies, and data transfer dependencies based on task timing and service calls, and convert them into directed edges with attribute labels; The graph generation unit is used to combine dependency edges and nodes to construct a directed service dependency graph, in which the nodes represent task stages or service module call units, and the edges represent service dependency paths.

7. The cloud platform-based robot dispatch management system according to claim 5, characterized in that: The communication topology generation module specifically includes: A communication requirement generation unit is used to extract a directed edge set from the service dependency graph, map the dependency relationship into communication requirements, and convert it into a communication requirement list; A topology construction unit is used to construct a communication path topology graph according to communication requirements, where nodes represent robots, edges represent communication channels and their attributes, and are represented in the form of a directed weighted attribute graph; Topology optimization unit, used to merge redundant paths, introduce backup paths, set forwarding rules, bandwidth restrictions, channel isolation, and edge weight adjustment for communication path topology; The topology deployment unit is used to send the communication path topology to the robot communication module, edge scheduler and cloud platform monitoring module in the form of a structured configuration file or microservice API, and supports the communication link status monitoring and reconstruction mechanism.

8. The cloud platform-based robot dispatch management system according to claim 5, characterized in that: The task execution control module specifically includes: The task issuing unit is used to divide the task commands into stages and distribute them to robots according to the service dependency graph and communication path topology, generate a task instruction queue with binding trigger conditions, and send it through the logical communication channel; The condition judgment unit is used to check whether the conditions of predecessor task completion, service data availability, system resource status and topological edge attributes are met after the robot receives the task command; The task execution unit is used to complete action control, state synchronization, service call and data feedback according to instructions, and transmit execution information according to the communication path topology to support state exchange in collaborative control scenarios; The feedback processing unit is used to upload status, record logs, and when a task is abnormal, perform rollback, retry, relay or interrupt the task according to the processing logic in the task instruction, and trigger dynamic adjustment of the service dependency graph and communication path topology.

Images