Split robot dynamic task flow engine system

Abstract

The application provides a split type robot dynamic task flow engine system. The system comprises a basic executor configured to generate a task instance according to an externally input task request; a set of operators comprising at least one operator, each of which is configured to, upon receiving an execution instruction from the basic executor, invoke hardware resources of a corresponding functional cabin to perform an action corresponding to the type of the operator; a task model configured to maintain identification, type, priority and state information of the task instance between the basic executor and the set of operators, and support persistent storage and recovery of the task instance; and a communication coordination module configured to provide a unified message transmission interface between a chassis, functional cabins and edge computing nodes of the split type robot, and realize transmission of instructions and state data between the basic executor and the set of operators. The application can realize cabin plug-and-play and dynamic adaptation, capability-based task scheduling, unified communication and state persistence, and guarantee task continuity.

Description

Technical Field

[0001] This application relates to the field of robotics technology, and in particular to a dynamic task flow engine system for a split-type robot. Background Technology

[0002] With the development of artificial intelligence and mobile robot technology, service robots are rapidly becoming widespread in scenarios such as cleaning, delivery, and medical assistance. For multi-tasking and multi-scenario applications, a modular architecture with separable functional modules is becoming the trend, requiring task scheduling and control to dynamically adapt to hardware combinations and achieve low-latency collaboration between heterogeneous components.

[0003] Most systems are still based on integrated models, with task flows strongly tied to fixed hardware, typically driven by static state machines or scripts. Changing the chassis or adding sensors / actuators requires modifying the drivers and upper-level logic. Cross-component communication relies heavily on their respective protocol stacks, lacking unified abstraction and capability declarations, and lacking runtime-oriented task models and persistence mechanisms.

[0004] Existing technologies still have the following problems: high hardware coupling, unable to be hot-swapped and capability self-discovery; scheduling lacks capability-based dynamic matching and conflict verification; communication and collaboration lack a unified interface and quality control; insufficient exception and degradation mechanisms, resulting in poor task continuity; high threshold for function expansion and reuse, and high development and maintenance costs. Summary of the Invention

[0005] In view of this, embodiments of this application provide a split-type robot dynamic task flow engine system to solve the problems of high hardware coupling, difficulty in adapting to the combination and replacement of functional compartments, lack of capability-based dynamic matching and scheduling in static task control, and lack of unified communication and task state persistence mechanism for heterogeneous components in the prior art.

[0006] This application provides a dynamic task flow engine system for a split-type robot, comprising: a basic actuator, used to generate task instances based on externally input task requests, perform creation, scheduling, pausing, cancellation, and status updates on the task instances, and distribute execution instructions to the operators; an operator set, containing at least one operator, each operator being used to invoke the hardware resources of the corresponding functional compartment to perform actions corresponding to the operator type when receiving execution instructions from the basic actuator; a task model, used to maintain the identifier, type, priority, and status information of task instances between the basic actuator and the operator set, and to support persistent storage and recovery of task instances; and a communication and coordination module, used to provide a unified message transmission interface between the chassis, functional compartments, and edge computing nodes of the split-type robot, realizing the transmission of instructions and status data between the basic actuator and the operator set.

[0007] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0008] The system comprises a basic actuator, which generates task instances based on externally input task requests, performs creation, scheduling, pausing, cancellation, and status updates on these instances, and distributes execution instructions to the operators. An operator set, containing at least one operator, is used to invoke the hardware resources of its corresponding functional compartment to execute actions corresponding to its type when receiving execution instructions from the basic actuator. A task model maintains the identifier, type, priority, and status information of task instances between the basic actuator and the operator set, and supports persistent storage and recovery of task instances. A communication and coordination module provides a unified message transmission interface between the chassis, functional compartments, and edge computing nodes of the split-type robot, enabling the transfer of instructions and status data between the basic actuator and the operator set. This application achieves plug-and-play and dynamic adaptation of the compartments, capability-based task scheduling, unified communication, and persistent status, ensuring task continuity. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of the structural composition of the split-type robot dynamic task flow engine system provided in the embodiments of this application. Detailed Implementation

[0011] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0012] With the development of artificial intelligence technology, service robots are being used more and more widely in various industries. Traditional service robots usually adopt an integrated design, with all functional components fixed on the same body, lacking flexibility and scalability. This design is difficult to adapt to different scenarios and task requirements, often requiring the configuration of multiple dedicated robots, resulting in wasted resources.

[0013] In existing technologies, service robot task execution systems are typically designed based on fixed hardware configurations, making them inflexible in adapting to the replacement and combination of different functional modules. When robot functions need to be changed, the control system often needs to be redesigned and developed, resulting in high development costs and low efficiency. Furthermore, existing systems lack effective management mechanisms for the collaborative work between the components of a modular robot, especially in scenarios involving heterogeneous component collaboration, making it difficult to guarantee task continuity and reliability.

[0014] Therefore, designing a task flow engine system that can adapt to split robot architecture, support dynamic task flow management, and possess high scalability and robustness has significant practical value and technical significance.

[0015] In view of the problems existing in the prior art, this application provides a task flow engine system for split-type robots, mainly applied to the task scheduling, execution and management of service robots with detachable functional compartments. This technology can be applied to intelligent service robots, logistics delivery robots, medical assistance robots and other fields, and is particularly suitable for scenarios that require multiple functional modules to work together. The core of this application is the implementation of a dynamic task flow engine, which can dynamically assemble and execute task processes according to different task requirements and hardware configurations.

[0016] The task flow engine system for the split-type robot in this application mainly includes the following components:

[0017] Basic Executor: As the core control center of the system, it is responsible for the overall scheduling and execution of the task flow. It implements basic functions such as task creation, execution, pause, cancellation, and update, and handles various events and state transitions during task execution.

[0018] Operator: A specific execution unit designed for different types of tasks and functional modules, such as delivery, sweeping, and returning to charging (GoBack). Each operator inherits from a base operator and implements the specific logic for a particular task.

[0019] Task Model: Defines the data structure and state management mechanism of a task, and maintains the task's queue, execution state, and lifecycle.

[0020] Communication and Collaboration Layer: Manages the communication and collaborative work between the various components of the split robot, including Mesh messaging protocol, MQTT messaging service, etc.

[0021] Service layer: Provides various auxiliary services, such as database services, cabin control services, and transmission services.

[0022] The specific structure and function of the split-type robot dynamic task flow engine system provided in this application embodiment will be described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 This is a schematic diagram of the structural composition of the split-type robot dynamic task flow engine system provided in the embodiments of this application, as shown below. Figure 1 As shown, the split-type robot dynamic task flow engine system may specifically include the following modules:

[0023] The basic executor 101 is used to generate task instances based on externally input task requests, perform creation, scheduling, pausing, cancellation and status updates on the task instances, and distribute execution instructions to the operator;

[0024] The set of manipulators 102 includes at least one manipulator. Each manipulator is used to call the hardware resources of the corresponding functional compartment to perform an action corresponding to the manipulator type when it receives the execution instruction from the basic actuator.

[0025] Task model 103 is used to maintain the identifier, type, priority and status information of task instances between the basic executor and the set of operators, and supports the persistent storage and recovery of task instances.

[0026] The communication and collaboration module 104 is used to provide a unified message transmission interface between the chassis, functional compartments and edge computing nodes of the split robot, so as to realize the transmission of instructions and status data between the basic actuators and the set of operators.

[0027] In some embodiments, the basic actuator includes:

[0028] The task parsing unit is used to extract the task type and priority from externally input task requests and generate task instances with unique identifiers.

[0029] The capability matching unit is used to dynamically determine the target operator and output the corresponding execution instructions based on the task type of the task instance and the hardware capability identifier declared by each operator in the operator set.

[0030] The status management unit is used to update the status fields in the task model during each stage of task instance creation, scheduling, suspension, cancellation, and completion, and to publish status change events to the communication and collaboration module.

[0031] Specifically, the basic actuator consists of a task parsing unit, a capability matching unit, and a state management unit. These three units work together sequentially to generate, match, and manage the entire lifecycle of task instances. This embodiment focuses on delivery tasks in a hospital setting, but the described techniques are also applicable to tasks such as cleaning and inspection.

[0032] First, the task parsing unit performs protocol unification and semantic mapping on task requests transferred from the communication and coordination module, standardizing fields from REST, MQTT, or local calls into internal task descriptions, including at least task type, priority, parameter payload, and source identifier. The task parsing unit generates task instance identifiers based on timestamps and random sequences, sets the initial state to pending scheduling, and writes the task type, priority, and parameter payload into the corresponding fields in the task model. If a necessary field is missing or the type is incompatible, a verification failure is returned, and the reason code is recorded.

[0033] Subsequently, the capability matching unit reads the hardware capability identifiers of each operator in the operator set and the online status of the bound functional compartments to establish a capability mapping relationship. For delivery tasks, the capability matching unit searches for candidate operators with delivery compartment capability identifiers based on the task type, and verifies the hardware resource occupancy and mutual exclusion constraints involved, such as the exclusive relationship between door control and pallet sensing. When multiple candidates exist, the capability matching unit selects the target operator according to the priority field in the task model and preset conflict resolution rules. After determining the target operator, the capability matching unit executes the instruction according to the unified instruction template encoding. The instruction at least includes the opcode, parameter payload, task instance identifier, and version number, and is submitted to the target channel of the communication and coordination module to trigger execution.

[0034] During execution, the state management unit maintains a set of state codes and state transition constraints. When the basic executor issues an execution command, the state management unit atomically updates the state fields in the task model, changing them from pending scheduling to running, and increments the version number. When an operator reports progress, pause, cancellation, or completion events, the state management unit performs a validity check based on the event type and the current state, generates a state change event containing the task instance identifier, previous state, next state, trigger reason code, and timestamp, sets an idempotent flag, and publishes it to the corresponding topic in the communication and coordination module, achieving traceability and deduplication of the state. If no heartbeat or result report is received from the target operator within a preset time window, the state management unit records the timeout reason code, sets the task instance to paused or failed, and writes back to the task model for the basic executor to retry or reassign later.

[0035] For ease of understanding, the following is a typical sequence of events for a delivery task. The nursing station initiates a delivery task through the host system, the request including the destination department and the compartment number. The task parsing unit generates a task instance identifier, sets the priority to medium, and places it in the database. The capability matching unit retrieves an operator with the capability identifier for delivery compartments and currently online from the operator set. After verifying that the operator does not occupy exclusive resources in the same compartment, it selects the target operator according to the rules and issues an execution command. The status management unit updates the status to "Running" and publishes a status change event. The target operator sequentially completes the retrieval, navigation, and delivery actions and reports a completion event. The status management unit verifies the transfer conditions, updates the status to "Completed," and publishes an event. If a compartment feedback anomaly occurs during delivery, the status management unit receives the anomaly event, updates the status to "Paused," and records the cause code. The basic actuator then triggers subsequent processes such as reassignment or manual intervention.

[0036] Through the above embodiments, the basic executor completes the standardized generation of task instances, the determination of target operators based on hardware capability identifiers, and the delivery of instruction encoding without changing the application layer logic. The state management unit performs consistency maintenance and event publishing for the task lifecycle, ensuring the orderly execution and controllability of tasks in the split architecture.

[0037] In some embodiments, the capability matching unit is specifically used for:

[0038] Establish a mapping relationship between the operator and the hardware capability identifier and synchronize the mounting and online status of the functional modules;

[0039] Candidate operators that meet the hardware capability identifiers are retrieved based on the task type, and the hardware resource usage and mutual exclusion constraints involved in the candidate operators are checked.

[0040] The target operator is determined according to the priority field in the task model and the preset conflict resolution rules.

[0041] The execution instruction, which includes the opcode, parameter load, and task instance identifier, is encoded according to the unified instruction template and submitted to the target channel of the communication and collaboration module.

[0042] Specifically, the capability matching unit is used to sequentially complete capability mapping maintenance, candidate operator retrieval and constraint verification, target determination based on task model priority, and unified instruction encoding and delivery after the basic actuator receives the task instance generated by the task parsing unit, forming a closed-loop control path from capability to instruction.

[0043] In terms of capability mapping maintenance, the capability matching unit models the capabilities of the operator set, establishing a mapping relationship between the hardware capability identifier declared by each operator and its accessible functional compartments. The hardware capability identifier is used to abstract the minimum hardware prerequisites for the operator to access the chassis and compartments, at least covering capability category, interface family, and version information. The capability matching unit subscribes to functional compartment mounting events and online heartbeats through the communication coordination module, synchronizing the availability status of each mapped entry in real time for subsequent candidate selection.

[0044] In terms of candidate retrieval and constraint verification, the capability matching unit retrieves a set of candidate operators that meet the target capability identifier in the capability mapping based on the task type, and performs occupancy and mutual exclusion verification from the resource dimension. Resource occupancy reflects the exclusive request of an operator for hardware resources such as door actuators, sensor channels, and chassis navigation control during the execution period; mutual exclusion constraints describe the logical restrictions that resources of the same type cannot be used in parallel at the same time. After retrieving the candidate set, the capability matching unit queries the current resource occupancy table and mutual exclusion rule set for each candidate operator, eliminating candidates that are unavailable due to conflicts with the instance executing the task, thus obtaining a feasible candidate set.

[0045] In terms of target determination, the capability matching unit reads the priority field from the task model and preset conflict resolution rules to sort and select feasible candidates. The priority field reflects the scheduling priority of task instances; the conflict resolution rules determine a unique target operator when candidate scores are the same, based on resource reuse, historical waiting time, or a specified preference strategy. After determining the target, the capability matching unit establishes a temporary resource binding between the task instance and the target operator and updates the resource occupancy table to lock necessary hardware resources.

[0046] Regarding instruction encoding and delivery, the capability matching unit executes instructions according to a unified instruction template. This template includes at least an opcode, parameter payload, and task instance identifier, and may also carry a version number and target device identifier. The execution instruction is delivered to the receiving topic corresponding to the target operator via the target channel of the communication coordination module, and the basic executor enters a waiting-for-report scheduling state accordingly.

[0047] For example, in some sample scenarios, taking the parallel operation of hospital delivery and cleaning as an example, the host system issues delivery tasks and cleaning tasks successively. The task parsing unit generates two task instances and writes them into the task model, setting their priorities to medium and low, respectively.

[0048] The capability matching unit first processes the delivery task, searches the capability mapping for operators with delivery cabin control capability identifiers that are online, verifies that the door actuator and pallet sensor resources are not occupied, and determines a feasible candidate set; selects the target operator based on the priority field and conflict resolution rules, establishes temporary resource binding, and encodes the execution command carrying the operation code, destination parameters and task instance identifier, and issues it through the target channel.

[0049] Subsequently, the cleaning task is processed. The capability matching unit searches for an operator with a cleaning capability identifier, but finds that it has a mutual exclusion constraint with the delivery task in terms of chassis navigation control. Moreover, the resource occupancy table shows that the chassis control has been temporarily bound by the delivery task. Therefore, the candidate is marked as currently unavailable, and another candidate operator with area cleaning capability and support for yielding strategy is selected as the target, and the corresponding instruction is issued.

[0050] After the two instructions are issued, the delivery task and the cleaning task begin execution at their respective target operators. The capability matching unit maintains resource occupancy until the target operator reports the stage result or completion result. If the delivery task is completed ahead of schedule, the capability matching unit releases its resource binding and triggers an immediate re-evaluation of the cleaning task candidate set, allowing switching to a more efficient cleaning operator to continue execution without changing the task instance identifier.

[0051] Through the above embodiments, the capability matching unit completes the entire process from capability mapping, candidate screening and constraint verification to target determination and unified instruction delivery while maintaining consistency between task type and hardware capability identifier. This enables task instances to obtain execution capacity that matches their capability requirements in a multi-cabinet, multi-operator environment, and keeps resource binding and release synchronized with the task model state.

[0052] In some embodiments, the state management unit is specifically used for:

[0053] Establish a set of state codes and state transition constraints for task instances;

[0054] Upon receiving a stage event generated by the basic executor, the legality of the proposed change state is checked according to the state transition constraints, and the state field and version number in the task model are updated atomically.

[0055] Generate a state change event that includes the task instance identifier, previous state, next state, trigger reason code, and timestamp;

[0056] Set an idempotent flag for state change events and publish them to the target channel of the communication collaboration module according to the preset topic route.

[0057] Specifically, the state management unit is deployed within the basic executor to execute a consistent state control process for task instances during creation, scheduling, suspension, cancellation, and completion. This unit maintains a set of state codes and state transition constraints. Using stage events as trigger inputs, it performs atomic updates to the state fields and version numbers in the task model, while generating state change events with idempotent flags and publishing them to the target channel via the communication and coordination module.

[0058] To facilitate unified management, the status management unit pre-sets a set of status codes, including at least pending scheduling, running, paused, canceled, canceled, completed, and failed. Corresponding state transition constraints are established to limit the allowed paths from previous state to subsequent state, such as pending scheduling → running, running → paused, running → completed, running → failed, paused → running, running → canceled → canceled, etc. The sources of stage events include scheduling events from the basic actuator, external control commands, and operator-reported events, all transmitted through the communication and coordination module and carrying task instance identifiers and trigger reason codes.

[0059] Upon receiving a stage event, the state management unit first reads the current state and version number of the task instance from the task model and performs a legality check based on state transition constraints. If the check passes, two operations are completed within a single transaction boundary: first, the subsequent state is written atomically and the version number is incremented; second, a state change event is generated. If an inconsistency in version number or an unauthorized change path is found, a check failure is returned and a rejection reason code is recorded, without rewriting the task model. To prevent duplicate processing, the state management unit calculates an idempotency identifier for each state change event. The idempotency identifier is obtained by combining the task instance identifier, version number, and subsequent state, and is used for downstream deduplication. The event content includes at least the task instance identifier, previous state, subsequent state, trigger reason code, and timestamp, and is mapped to the target channel of the communication and coordination module according to a preset topic route, for subscription by the operator, host system, and monitoring nodes.

[0060] For example, in a hospital delivery scenario, after the nursing station submits a task, the state management unit receives the scheduling event from the basic actuator and completes the atomic update from pending scheduling to running, generating and publishing a state change event with an idempotent flag. During execution, if the target actuator reports a loading sensor anomaly, the state management unit, based on the constraint that it is currently running and allows running to pause, completes the atomic update from running to pause and publishes the event. After manual reset, the basic actuator issues a recovery event, and the state management unit completes the update according to the pause to running constraint. When the task ends, the target actuator reports a completion event, and the state management unit writes running to completed into the task model and publishes the final state event. If a version number inconsistency is detected at any stage, the change is rejected and the basic actuator is required to retry, thus avoiding state inconsistencies caused by concurrent writes.

[0061] Through the above embodiments, the state management unit, based on a pre-set set of state codes and state transition constraints, completes three core operations around stage events: legality verification, atomic update, and event publication. It also uses idempotent identifiers to ensure that events can be reliably deduplicated in the target channel of the communication and collaboration module, ensuring that the state fields in the task model are consistent with the external subscribers' perception of the task lifecycle.

[0062] In some embodiments, the set of operators includes one or more of the following:

[0063] The navigation manipulator is used to control the robot chassis to follow the path and stop at the station when it receives execution instructions from the basic actuator;

[0064] The operation operator is used to call the hardware resources associated with the functional compartment to execute operation actions corresponding to the task type. The operation actions include at least one of delivery or cleaning.

[0065] The return-to-charge operator is used to control the robot to dock with the charging device when it receives a return-to-warehouse or charging command.

[0066] Interactive actuators are used to drive human-computer interaction components to execute prompts and confirm instructions;

[0067] The exception handling operator is used to perform task interruption control and task recovery when an exception event is received.

[0068] Specifically, the operator set consists of a navigation operator, a job operator, a recharge operator, an interaction operator, and an exception handling operator. Each operator interfaces with the basic executor using a unified instruction input and status output standard: the basic executor issues execution instructions to the target channel through a communication coordination module; the instructions include an opcode, parameter payload, and task instance identifier; the operator completes resource binding before execution, reports progress events in stages during execution, and returns a completion or failure event and releases resource binding upon completion. The task model records the binding relationship and status fields between operators and task instances, and the status management unit uses this information for status transitions and event publishing.

[0069] To facilitate understanding, the relevant terms are explained first. Operation codes indicate the type of action the operator needs to perform, such as navigation execution, station docking, door opening / closing, docking back to the depot, and interactive prompts. Parameter payloads carry the parameters required for the action, such as path point sets, station identifiers, docking parameters, interactive template identifiers, and timeout thresholds. Resource bindings record the exclusive hardware relationships during the execution period, such as chassis navigation control, door actuators, and pallet sensor channels. The target channel is the message routing identifier in the communication coordination module corresponding to the topic subscribed to by the operator.

[0070] Upon receiving the execution command containing the navigation execution opcode and path point set, the navigation operator first requests chassis navigation control from the resource occupancy table and completes resource binding. It then parses the path point set in the parameter load, generates a driving segment plan based on the path point sequence and constraints, and sends speed and attitude control quantities through the chassis motion control interface. During navigation, it continuously collects mileage, positioning, and obstacle avoidance sensor feedback, reporting stage progress events to the basic actuator according to a preset sampling period. If the parameter load includes a station stop command, the navigation operator performs deceleration, attitude adjustment, and stopping actions as it approaches the target station, and reports a stopping completion event when the stopping judgment conditions are met. If an anomaly occurs, such as path unreachable, positioning distortion, or obstacle avoidance triggering, the navigation operator generates a failure event containing an exception code and a timestamp and unbinds the resource.

[0071] After receiving the execution instruction, the job operator branches out the processing according to the job type in the parameter load.

[0072] During the delivery operation, the operator binds the delivery compartment capability identifier to the associated resources and sequentially performs the actions of unlocking the door, opening the door, and confirming the status of the compartment. After confirming the loading of the goods, the operator closes the door and reports the stage event according to the compartment number and safety conditions in the load parameters. After arriving at the destination station, the operator performs the actions of opening the door, confirming the retrieval of the goods, and closing the door, and records the detection signal and timestamp at each action node.

[0073] During cleaning operations, the operator binds the cleaning actuator to the relevant sensor channels, starts the cleaning actuator according to the area cleaning parameters in the parameter load, coordinates with the path planning of the navigation operator according to the area boundary and yielding strategy, and periodically reports the coverage progress and consumable status; when the actuator is detected to be overloaded or the sensor is abnormal, an abnormal event is generated and the operator enters a waiting instruction state.

[0074] After both types of tasks are completed, the task operator unbinds the corresponding resources and returns a completion event; if a cancellation instruction is received from the basic executor midway, the task operator performs a safe shutdown and resource release before returning a cancellation completion event.

[0075] The recharge operator handles return-to-warehouse or charging docking actions. Upon receiving a docking command, the recharge operator requests chassis navigation control and completes resource binding. Based on the docking pose and method in the docking parameters, it generates an entry path and drives the chassis motion control interface to complete the entry. Once in position, it initiates a docking handshake through the charging device's communication interface, receives docking status and charging preparation signals, and then sends a charging start command and reports a charging start event. During recharge, the recharge operator periodically reads the charging device's status feedback and reports stage events. When the basic actuator issues a stop charging or interrupt command, the recharge operator executes the stop charging and disengagement process and releases resource binding.

[0076] After receiving the instruction, the interactive operator drives the display, voice, or indicator light components to output prompts based on the interactive template identifier, and collects user input according to the input type and timeout threshold in the parameter load. The interactive operator verifies the validity of the received input, and encapsulates the confirmation, cancellation, or no response results as interactive result events and reports them to the basic executor. When the template requires repeated confirmation, the interactive operator executes multiple rounds of prompts and data collection in the template sequence and outputs the final result.

[0077] When the exception handling operator receives an exception event instruction, it first queries the current state and resource binding of the task instance in the task model, submits a task interruption request to the basic executor, and waits for the state management unit to complete the state transition. Then, it selects either a recovery strategy or a rollback strategy based on the exception code. The recovery strategy generates a recovery execution instruction and submits it to the basic executor in short-term recoverable exception scenarios; the instruction may include parameters for the number of retries and the retry interval. The rollback strategy generates a rollback instruction in scenarios where the current action needs to be withdrawn, such as returning to the previous pathpoint after a docking failure or a door closing action when the operation is not confirmed. During the execution of the recovery or rollback process, the exception handling operator reports events in stages. After completion, it releases the resources temporarily occupied by it and reports a processing completion event.

[0078] For example, in some sample scenarios within a hospital environment, the host system sequentially issues delivery and return-to-charge tasks. The basic actuator generates task instances for both requests and distributes them in sequence. After gaining control of the chassis navigation, the navigation operator completes path following and docking at the target department station; the interaction operator prompts the nurse to confirm opening the hatch based on the interaction template, and after receiving confirmation input, the operation operator completes hatch door opening, item retrieval confirmation, and hatch door closing; after the task completion event is published, the basic actuator distributes docking instructions to the return-to-charge operator, which completes docking and starts charging. If station congestion occurs during delivery, causing docking failure, the exception handling operator generates a backtracking instruction according to the backtracking strategy to return to the previous path point and submits a recovery request to the basic actuator to retry docking; if the retry still fails, the exception handling operator reports a processing completion event with a failure code, which the basic actuator uses for subsequent scheduling.

[0079] Through the above embodiments, the operator set completes actions such as path execution, cabin operation, return to the depot for charging, human-machine interaction and anomaly handling under unified instructions and status specifications, and forms a closed-loop control with the basic actuator, task model and communication collaboration module through resource binding and event reporting.

[0080] In some embodiments, each operator is configured to, upon receiving an execution instruction from a basic actuator, invoke the hardware resources of the corresponding functional module to perform an action corresponding to the operator type, including:

[0081] The navigation manipulator is used to parse the opcode and parameter load in the execution command, call the chassis motion control interface to generate speed and attitude control quantities, and perform path following and station docking according to the path point set associated with the task instance identifier.

[0082] The operation controller is used to call the actuator interface and detection interface bound to the functional compartment according to the operation parameters in the execution command to perform the delivery or cleaning action;

[0083] The recharge operator is used to call the chassis motion control interface and the charging device communication interface according to the docking parameters in the execution command to complete the docking and charging control.

[0084] The interactive operator is used to drive the human-computer interaction components to output prompts and collect confirmation input based on the interactive template identifier in the execution instruction;

[0085] The exception handling operator is used to trigger task interruption control and generate a recovery or rollback instruction associated with the task instance identifier when an exception event instruction is received, and submit it to the basic executor.

[0086] Specifically, the operator set works in conjunction with the basic executor using a unified instruction input and status output standard: the basic executor sends execution instructions to the target channel via the communication coordination module; each execution instruction includes at least an opcode, parameter payload, and task instance identifier; the operator completes resource binding before responding to the execution instruction, reports events in stages during execution, and returns a completion or failure event and releases resource binding upon completion. The task model records the binding relationship between the task instance and the target operator, as well as the current state, and the state management unit uses this information to perform state transitions and event publishing.

[0087] Upon receiving an execution command containing a navigation execution operation code and a path point set, the navigation operator first requests chassis navigation control from the resource occupancy table and completes resource binding; it parses the path point set, speed limit threshold, and stop station identifier in the parameter load to generate a driving segment plan; it periodically sends speed and attitude control quantities through the chassis motion control interface and collects positioning and obstacle avoidance feedback for closed-loop control; when reaching a path point with a stop identifier, it performs deceleration, attitude adjustment, and stop station determination, and reports a stop completion event after the determination is successful; if an anomaly occurs such as path unreachable, positioning distortion, or continuous obstacle avoidance triggering, it generates a failure event with an exception code and unbinds the resource.

[0088] The operation controller branches according to the operation type in the parameter load. During delivery operations, it binds the relevant resources of the delivery compartment, and sequentially executes door unlocking, door opening, slot occupancy detection, and loading confirmation, recording detection signals and timestamps, and reporting stage events; upon arrival at the destination station, it executes door opening, item retrieval confirmation, and door closing, and reports a completion event. During cleaning operations, it binds the cleaning actuator and relevant sensor channels, starts cleaning according to the area cleaning parameters, and coordinates with the path planning of the navigation controller, periodically reporting coverage progress and consumable status; when an overload of the actuator or sensor malfunction is detected, it reports an abnormal event and enters a waiting command state. When the operation ends or is canceled, it performs a safety shutdown and releases the bound resources.

[0089] Upon receiving the return-to-warehouse or charging docking operation code, the return-to-charge operator requests chassis navigation control and completes resource binding; it generates an entry path based on the target pose and docking method in the docking parameters and drives the chassis into position; it initiates a handshake through the charging device communication interface, and after receiving the docking status and charging ready signals, it issues a charging start command and reports the start-of-charging event; during charging, it periodically reads the docking status and electrical quantities and reports stage events; when it receives a stop-charging or interrupt command, it executes the stop-charging and disconnection process and releases resource binding.

[0090] After receiving an execution command containing an interaction template identifier, the interactive actuator drives human-computer interaction components such as displays, voice prompts, or indicator lights to output prompt information; it collects user input according to the input type and timeout threshold in the parameter load, verifies the legality of the input, and generates confirmation, cancellation, or no response after timeout as an interaction event to report to the basic actuator; when the template requires multiple rounds of confirmation, it outputs prompts and collects inputs in the order of the template, and finally outputs a summary result event.

[0091] Upon receiving an exception event instruction, the exception handling operator reads the current state and resource binding information of the task instance in the task model, submits a task interruption request to the basic executor, and waits for the state management unit to complete the state transition. Based on the exception code, it selects a recovery or rollback strategy: the recovery strategy is used for short-term recoverable scenarios, generating a recovery execution instruction containing the number of retries and the retry interval, and submitting it to the basic executor; the rollback strategy is used for scenarios requiring the current action to be revoked, generating a rollback instruction such as returning to the previous path point or executing door closure, and submitting it to the basic executor. During the recovery or rollback process, events are reported in stages, and upon completion, the temporarily occupied resources are released, and a processing completion event is reported.

[0092] For example, taking a hospital floor delivery task as an example, the upper-level system issues delivery execution instructions and task instance identifiers. The navigation operator acquires chassis navigation control and completes path following and docking at the target department; the interactive operator prompts the nurse to confirm opening the hatch according to the interactive template and collects confirmation input; the operation operator completes hatch door opening, item retrieval confirmation, and hatch door closing and reports the completion event; the basic actuator advances the task model state according to the event and issues state change events; if docking fails, the exception handling operator triggers a rollback to the previous path point and submits a recovery request for a second docking; after the task is completed, the basic actuator can issue docking instructions to the recharging operator to execute the charging process.

[0093] In the above process, all stage events are accompanied by task instance identifiers and published through the target channel of the communication and collaboration module. The state management unit atomically updates the state fields and version numbers in the task model to ensure orderly execution under multi-operator collaboration.

[0094] In some embodiments, the task model specifically includes:

[0095] The Identifier and Metadata Unit is used to assign a unique task instance identifier to a task instance and store the task type, priority field, and parameter payload as metadata.

[0096] Queues and dependency units are used to maintain task queues and parent-child task relationships, record task execution order and dependency constraints, and provide a schedulable entry retrieval interface to the basic executor.

[0097] The state storage unit is used to save the state field and version number of the task instance, and record the trigger reason code and timestamp related to the state change;

[0098] The resource binding unit is used to record the binding relationship between task instances and target operators, functional modules and hardware capability identifiers, so that the basic actuators can perform capability matching and conflict verification.

[0099] The serialization and persistence unit is used to serialize task instances and their status fields and write them to external storage, and provides a deserialization recovery interface when the system restarts.

[0100] Specifically, the task model consists of identification and metadata units, queue and dependency units, state storage units, resource binding units, and serialization and persistence units, which are used to provide a unified task data plane and consistency control plane between the basic executor and operator set, supporting the creation, scheduling and recovery of task instances.

[0101] The Identifier and Metadata Unit is used to assign a task instance identifier (such as a UUID) to each task instance after task parsing and to create an index, storing the task type, priority field, and parameter payload related to the task. The parameter payload is used to carry structured parameters related to execution, including target site identifier, path point set identifier, job type identifier, and timeout threshold, etc. The unit performs integrity checks on required fields, and requests that fail the check are not entered into the subsequent queue.

[0102] The queue and dependency unit is used to maintain the association between schedulable entries and parent-child tasks. A schedulable entry refers to a task instance or subtask instance that meets the preconditions and is not blocked by resource conflicts. This unit records the execution order and dependency constraints, supporting parallel or serial control of multiple subtasks by the parent task; when the dependency is satisfied, it provides a schedulable entry retrieval interface to the basic executor, and marks the entry as occupied after it is taken to avoid duplicate scheduling.

[0103] The state storage unit is used to store the state fields and version number of the task instance, and record the trigger reason code and timestamp related to state changes. The state fields are represented by a pre-defined set of codes, and the version number is used for concurrency control. After the legality check is passed, the basic executor or state management unit atomically writes the subsequent state and increments the version number, while retaining the previous state and trigger reason code in the task model for traceability.

[0104] The resource binding unit records the binding relationships between task instances and target operators, functional modules, and hardware capability identifiers. Binding relationships distinguish between exclusive and shareable resources, and support mutually exclusive sets to describe constraints that prevent similar resources from being used concurrently at the same time. The basic executor writes a temporary binding after the capability matching unit selects the target operator, and releases the binding upon completion or cancellation. When a resource conflict is detected, the resource binding unit returns the conflict information to the queue and dependent units to block the entry from entering the scheduling process.

[0105] The serialization and persistence unit is used to serialize the identifier, metadata, dependencies, status fields and resource binding relationships of task instances and write them to external storage. When the system restarts, the task queue and index are rebuilt through the deserialization recovery interface, the latest state is restored according to the version number, and the running instances are reset to a retryable or paused state according to the preset recovery strategy to ensure that the basic executor can continue to perform capability matching and command issuance.

[0106] For example, in a scenario where hospital delivery and cleaning occur concurrently, the nursing station and the operations and maintenance department submit delivery and cleaning tasks respectively. The identification and metadata unit generates task instance identifiers for both and writes them into the priority field and parameter payload; the delivery task, as the parent task, simultaneously generates two sub-tasks: pickup and delivery. The queue and dependency unit sets delivery to a serial relationship that depends on pickup completion.

[0107] After the capability matching is completed, the resource binding unit writes a temporary binding between the delivery task and the delivery cabin and chassis navigation control; the cleaning task requests the cleaning execution mechanism and is marked as waiting because it is mutually exclusive with the chassis navigation control.

[0108] The state storage unit updates the delivery task from pending scheduling to running and then to completion as the stage event progresses, and records the trigger reason code and timestamp; after the delivery is completed and the binding is released, the queue and dependency unit immediately convert the cleaning task into a schedulable item and enters the scheduling process.

[0109] If the device loses power during execution, the serialization and persistence unit will rebuild the two task instances and their dependencies and binding snapshots when the system recovers. Based on the version number, the incomplete entries will be restored to paused and submitted to the basic executor for continued scheduling.

[0110] The above embodiments demonstrate that the task model, through unified data and control abstraction, enables the basic executor to stably and traceably manage the task lifecycle and resource consumption in a split architecture.

[0111] In some embodiments, the communication coordination module specifically includes:

[0112] The communication interface unit is used to provide a unified message transmission interface to the basic actuator, the set of manipulators, the chassis, the functional compartment and the edge computing node, and to shield the differences in the underlying link.

[0113] The channel management unit is used to maintain local area communication channels and wide area communication channels, route messages by topic, and manage target channels.

[0114] The message encoding and parsing unit is used to encode and parse instruction and status data according to a unified message format;

[0115] The transmission control unit is used to configure the quality of service level field and retransmission, sequence number and idempotency identification processing strategies for different messages;

[0116] The authentication and access control unit is used to authenticate message publishing and subscription based on device identifiers or roles and to issue topic access permissions.

[0117] The event distribution and subscription management unit is used to distribute the execution instructions generated by the basic executor and the state change events generated by the task model to the target operator or related nodes, and to receive the status messages reported by each node.

[0118] The equipment status synchronization unit is used to receive the online and heartbeat status of the functional compartments and chassis and submit it to the basic actuators and task model.

[0119] Specifically, the communication and collaboration module is deployed on the communication plane of the split-type robot to carry out instruction and status exchanges between the basic actuators, manipulator set, chassis, functional compartments, and edge computing nodes. This module uses a unified message format as the data carrier and a publish / subscribe mechanism as the routing method, and sets up local communication channels and wide-area communication channels. Both types of channels are controlled by a unified strategy under the channel management unit.

[0120] The communication interface unit exposes a unified message transmission interface to various functional entities. This interface employs both request / response and publish / subscribe interaction paradigms, defining a minimum set of message fields, including task instance identifier, opcode, parameter payload, timestamp, version number, and idempotency identifier. The interface abstracts and shields different underlying links; when the chassis connects via wired Ethernet while the functional modules connect wirelessly, the interface layer maintains consistent calling semantics with the upper layer.

[0121] The channel management unit maintains local and wide-area communication channels. Local communication channels are used for low-latency message exchange between the chassis and functional modules, while wide-area communication channels are used for reliable message transmission with edge computing nodes. The channel management unit routes messages according to topics, which consist of device, task, and event domains, exemplified as device domain / task instance identifier / event type. When a basic actuator distributes execution instructions to a target operator, the channel management unit determines the target channel based on the topic mapping and completes the delivery; when a task model publishes a state change event, the channel management unit replicates and routes the event to monitoring and visualization nodes subscribed to that topic.

[0122] The message encoding and parsing unit performs bidirectional processing according to a unified message format. On the encoding side, the parameter payload is structured and encapsulated based on the instruction template bound to the opcode, along with a task instance identifier and version number. On the parsing side, field validation and version consistency checks are performed on arriving messages; if any required fields are missing or the version has been rolled back, the message is rejected and a reason code is returned. This unit uses fixed-point or compact representations for numerical values ​​to reduce frame length and uses monotonic clock values ​​for timestamps to facilitate sequence comparison.

[0123] The transmission control unit configures Quality of Service (QoS) level fields for different messages and implements reliability strategies. Higher QoS levels are set for execution instructions and state change events, enabling acknowledgment, retransmission, and sequence number links; lower QoS levels are used for high-frequency telemetry to reduce bandwidth pressure. Idempotency flags are used for deduplication at the receiving end, sequence numbers are used for out-of-order reordering, and retransmission windows are used to limit the retransmission cycle. When continuous packet loss or round-trip delay exceeding the threshold is detected, the transmission control unit switches to a backup channel or initiates backoff and retry without changing the upper-layer topic.

[0124] The authentication and access control unit verifies publish and subscribe requests. Based on device identifiers or roles, this unit loads access policies and distributes topic-level publish and subscribe permissions to the interface side for execution. Basic executors are only authorized to publish execution instructions and read status events; operators are only authorized to subscribe to their own topics and publish phase events; edge computing nodes are authorized to subscribe to status events and device heartbeats. Permission changes take effect atomically; unauthorized requests are rejected and logged in the audit log.

[0125] The event distribution and subscription management unit is responsible for organizing the lifecycle of instructions and events. Execution instructions generated by the basic executor are distributed according to the topic of the target operator, and state change events generated by the task model are simultaneously distributed to the basic executor, the target operator, and the upper-level monitoring node. When an operator reports a stage event or an abnormal event, this unit forwards the event to the basic executor and drives the state management unit for subsequent processing. To prevent event loss due to short-term offline status of subscribers, this unit configures a short-term retention policy on the wide-area communication channel side, allowing offline subscribers to retrieve unread events in sequence after recovery.

[0126] The device status synchronization unit receives the online and heartbeat status of the functional modules and chassis and submits it to the basic actuators and task models. The heartbeat message contains the device identifier, online status, and most recent error code. When the heartbeat times out or the status is offline, the device status synchronization unit publishes a device offline event to the basic actuators and triggers an immediate reassessment by the capability matching unit. When the device comes back online, the device status synchronization unit publishes an online event, and the channel management unit restores the normal routing for the corresponding topic accordingly.

[0127] In the collaborative process of delivery and recharging in a hospital setting, the basic actuator receives task requests from the upper-level system through a wide-area communication channel. After verification by the message encoding and parsing unit, it generates execution instructions and distributes them to the navigation and operation operators through a local communication channel. During execution, status change events are distributed simultaneously on both types of channels at a high quality of service level. The authentication and access control unit ensures that only authorized nodes can subscribe. When a functional module is briefly offline, the device status synchronization unit publishes an offline event and triggers a backoff strategy. After the module is restored to online status, the event distribution and subscription management unit reissues unread events in sequence to ensure that the task model status is consistent with the perception of external subscribers.

[0128] Through the above embodiments, under the constraints of unified message format and topic routing, the communication collaboration module provides an abstractable interface layer, a controllable transmission layer, and an auditable permission layer for the split architecture, realizing low-latency instruction delivery and high-reliability status distribution under heterogeneous links, completing deduplication, out-of-order reordering, and offline compensation controls, and supporting stable collaboration of basic actuators and operator sets and consistent maintenance of task models.

[0129] In some embodiments, the system further includes a resource conflict detection module, which is used to detect hardware resource occupancy conflicts of the operator set on the functional cabin before the task instance enters execution, and to adjust the scheduling order or split low-priority tasks when a conflict is detected.

[0130] Specifically, the resource conflict detection module is deployed on the scheduling path of the basic executor. It checks the resource requests of the operator set and the resource occupancy of the functional modules before a task instance enters execution. Upon detecting a conflict, it returns executable rearrangement suggestions to the queue and dependent units or splits the subtask to release the pressure on exclusive resources. This module uses the resource binding units and queue and dependent units in the task model as data sources, and the target operator and its hardware capability identifier output by the capability matching unit as constraint input. Through a joint comparison of the resource occupancy table, the set of mutual exclusion constraints, and the expected occupancy period, it generates conflict determination results and resolution schemes.

[0131] To standardize the verification granularity, the resource conflict detection module abstracts the operator's resource requests into resource request descriptions, which at least include resource granularity identifiers, exclusive or shared attributes, expected start and end points of occupation, and yielding policies. It also abstracts the current system state into a resource occupation table and a set of mutual exclusion constraints. The former records the task instance identifiers and version numbers bound to each resource, while the latter provides the restrictions preventing parallel occupation of similar resources within the same time period. The module first infers candidate start times based on schedulable entries provided by queues and dependent units, then performs time interval overlap detection on the resource request descriptions and resource occupation tables, and verifies the parallel availability of similar resources in the set of mutual exclusion constraints.

[0132] Upon detecting a conflict, the resource conflict detection module executes resolution strategies according to a preset order. It prioritizes rearrangement based on the priority field, shifting lower-priority entries to the back or giving way to higher-priority entries. If rearrangement is insufficient to resolve the conflict, it performs time window fine-tuning, shifting candidate start times to idle windows without altering task instance identifiers and dependencies. If resolution still fails, it structurally splits low-priority task instances, dividing the coverage or action sequence into multiple sub-task instances, binding each to a shorter occupancy window to reduce the continuity of exclusive resource occupancy, and writing parent-child relationships into queues and dependency units. If none of the above strategies are feasible, the module marks the entry with a blocking reason code and returns to a waiting state, awaiting immediate re-evaluation triggered by a channel event after resource release or device online. All rearrangement and splitting results are atomically written back to the task model, the resource binding unit synchronously generates or updates temporary bindings, and the state management unit publishes scheduling adjustment events accordingly.

[0133] For example, in some sample scenarios, such as a hospital setting, the system simultaneously handles delivery tasks and area cleaning tasks. The capability matching unit determines the delivery module and cleaning module for each task, respectively. Both request chassis navigation control and overlap with the same corridor segment during certain time periods. The resource conflict detection module determines a conflict after verifying the resource occupancy table and mutual exclusion constraint set. Based on the rule that the delivery task has higher priority, the module first moves the cleaning task to the back, which still conflicts with the delivery task in the section from the warehouse exit to the elevator entrance. Accordingly, the module performs a structured decomposition of the cleaning task, dividing it into front-area cleaning sub-tasks and back-area cleaning sub-tasks according to the area boundaries. The front-area sub-task is bound to a yielding strategy that executes only during idle corridor windows, while the back-area sub-task dependency is set to be triggered by the delivery completion event. The module writes the rearrangement and decomposition results back to the task model and updates the resource bindings. The basic executor then distributes instructions to the corresponding operators accordingly. After the delivery task is completed and chassis navigation control is released, the queue and dependency unit immediately converts the back-area cleaning sub-task into a schedulable item for execution.

[0134] Through the above embodiments, the resource conflict detection module completes the pre-verification and strategic resolution of exclusive and mutually exclusive resources before the task instance is executed, realizing priority-based rearrangement, time window-based fine-tuning, and structured splitting of low-priority tasks, thereby reducing the simultaneous and long-term occupation of exclusive resources, supporting the basic executor to stably promote multi-task parallelism, ensuring the orderly use of resources and the traceability of scheduling decisions.

[0135] In some embodiments, the system further includes a cabin control service module, which is used to abstract the underlying communication protocols of each functional cabin and provide a unified remote procedure call interface to the set of operators.

[0136] Specifically, the cabin control service module is deployed on the control plane between the communication coordination module and the functional cabins. It provides a unified remote procedure call interface to the set of operators, shielding the differences in the underlying communication protocols used by the functional cabins. The cabin control service module performs capability modeling on the instruction sets and status feedback of various functional cabins, forming a mapping relationship between high-level operational semantics and low-level message templates. It also synchronizes capability identifiers, firmware versions, and online status to the resource binding unit and device status synchronization unit in the task model for reference by the basic actuators and capability matching units.

[0137] In terms of protocol abstraction, the cabin control service module is configured with multiple protocol adapters to interface with links such as CAN, Ethernet fieldbus, serial bus, and local GPIO. The protocol adapters are responsible for message encoding / decoding, address mapping, and timeout control of the physical links, exposing only a unified set of call semantics and error codes. To adapt to the differences in instructions from different manufacturers, the cabin control service module defines opcodes, parameter fields, verification fields, and expected response formats using instruction description templates, and supports version tags to differentiate field layouts across different firmware versions.

[0138] Regarding capability registration and discovery, when the cabin control service module detects a functional cabin mounting or online event, it executes a handshake process and reads the device identifier, firmware version, and capability list, registering the parsed hardware capability identifier to the capability directory. When firmware is upgraded or capabilities change, the cabin control service module updates the capability directory incrementally and publishes capability update events to the basic actuators. Capability directory changes are also written back to the task model, enabling the capability matching unit to use the latest capability information in subsequent scheduling.

[0139] Regarding invocation and concurrency control, after obtaining exclusive resources granted by the resource binding unit, the operator initiates a remote procedure call to the cabin control service module. The cabin control service module verifies the validity of the parameter load based on the instruction description template, generates the underlying message, and distributes it through the target protocol adapter, while simultaneously recording the invocation context (task instance identifier, version number, retry count, and idempotency flag). To ensure consistency, the cabin control service module implements a serialized queuing and timeout retry strategy for concurrent calls to the same resource; when consecutive timeouts occur or error codes trigger thresholds, a cabin exception event is generated and submitted to the basic actuator and state management unit to execute a pause or rollback process.

[0140] In terms of status feedback and telemetry, the cabin control service module, in addition to synchronously returning responses to single calls, also subscribes to status reports and heartbeat information from functional cabins, and converts key states into structured events to be published as topics to the communication and coordination module. For motion-based equipment such as cleaning actuators and delivery doors, the cabin control service module provides event callbacks for action completion, action interruption, and safety interlock triggering; for sensor-based resources, it provides alarm event callbacks for threshold exceeding and self-test failure. All of the above events carry task instance identifiers and idempotency identifiers for the status management unit to perform deduplication and state transitions.

[0141] For example, taking a hospital delivery scenario, after the operator obtains exclusive binding with the resources related to the delivery compartment, it initiates an open-compartment call to the compartment control service module. The compartment control service module selects the appropriate instruction template based on the current firmware version, verifies the slot number and safety preconditions (such as attitude and door magnetic signals), sends an open-compartment message via the CAN adapter, and waits for a response. Upon receiving a response, it publishes an action completion event and returns the call result. If no valid response is received within the timeout period, it retransmits the message a limited number of times according to the retry strategy. If it still fails, it publishes a compartment exception event and suggests reassigning the basic actuator or inserting an exception handling operator. After delivery is completed, the operator calls the close-compartment interface. The compartment control service module synchronously reads the closure confirmation signal from the sensor input channel, generates a stage event, and submits it to the status management unit to update it to completion.

[0142] Through the above embodiments, the cabin control service module achieves unified abstraction of heterogeneous functional cabins through protocol adaptation, capability registration, unified invocation, and concurrent control. It outputs stable and consistent remote procedure call interfaces to the operator set, significantly reducing the upper layer's perception of the differences in the underlying protocols. At the same time, it works with the task model and communication collaboration module to complete the standardized release and idempotent control of state events, improving the controllability of cabin actions and the system's expansion and maintenance efficiency in a split architecture.

[0143] Through the technical solutions of the above embodiments of this application, the technical solutions of this application have at least the following effects:

[0144] High flexibility and scalability: Through modular design and dynamic task flow assembly, the system can adapt to the combination and replacement of different functional modules without the need to redevelop the core control system, which greatly reduces development costs and improves development efficiency.

[0145] Strong fault tolerance and adaptability: The system has an intelligent anomaly handling mechanism that can automatically detect and handle various abnormal situations during task execution, such as communication interruption and hardware failure, and take corresponding recovery strategies according to the anomaly type, thereby improving the reliability of task execution.

[0146] Optimized resource utilization efficiency: The modular design allows the robot chassis to be combined with different functional compartments, avoiding the waste of resources of single-function robots, greatly improving equipment utilization and reducing operating costs.

[0147] Enhanced multi-task collaboration capability: The system can effectively manage and coordinate the collaboration between the components of the split robot, ensuring the continuity and consistency of complex tasks, and is particularly suitable for scenarios that require multiple functional modules to work together.

[0148] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A split-type robot dynamic task flow engine system, characterized in that, include: The basic executor is used to generate task instances based on externally input task requests, perform creation, scheduling, pausing, cancellation and status updates on the task instances, and distribute execution instructions to the operator; An operator set includes at least one operator, each of which is used to invoke the hardware resources of the corresponding functional compartment to perform an action corresponding to the operator type when receiving the execution instruction from the basic actuator; The task model is used to maintain the identifier, type, priority, and status information of the task instance between the basic executor and the set of operators, and supports the persistent storage and recovery of the task instance. The communication and coordination module is used to provide a unified message transmission interface between the chassis, functional compartments and edge computing nodes of the split robot, so as to realize the transmission of instructions and status data between the basic actuator and the set of manipulators; The basic actuator includes: The task parsing unit is used to extract the task type and priority from externally input task requests and generate task instances with unique identifiers. The capability matching unit is used to dynamically determine the target operator and output the corresponding execution instructions based on the task type of the task instance and the hardware capability identifier declared by each operator in the operator set. The status management unit is used to update the status fields in the task model during each stage of task instance creation, scheduling, suspension, cancellation and completion, and to publish status change events to the communication and collaboration module. The capability matching unit is specifically used for: Establish a mapping relationship between the operator and the hardware capability identifier and synchronize the mounting and online status of the functional modules; Candidate operators that meet the hardware capability identifier are retrieved according to the task type, and the hardware resource usage and mutual exclusion constraints involved in the candidate operators are checked. The target operator is determined according to the priority field in the task model and the preset conflict resolution rules. The execution instruction, which includes the opcode, parameter payload, and task instance identifier, is encoded according to the unified instruction template and submitted to the target channel of the communication and collaboration module. The status management unit is specifically used for: Establish a set of state codes and state transition constraints for task instances; Upon receiving a stage event generated by the basic executor, the legality of the proposed change state is checked according to the state transition constraints, and the state field and version number in the task model are updated atomically. Generate a state change event that includes the task instance identifier, previous state, next state, trigger reason code, and timestamp; Set an idempotent flag for the state change event and publish it to the target channel of the communication collaboration module according to the preset topic route.

2. The system according to claim 1, characterized in that, The set of operators includes one or more of the following: The navigation manipulator is used to control the robot chassis to follow the path and stop at the station when it receives execution instructions from the basic actuator; The operation operator is used to call hardware resources associated with the functional compartment to execute operation actions corresponding to the task type, the operation actions including at least one of delivery or cleaning; The return-to-charge operator is used to control the robot to dock with the charging device when it receives a return-to-warehouse or charging command. Interactive actuators are used to drive human-computer interaction components to execute prompts and confirm instructions; The exception handling operator is used to perform task interruption control and task recovery when an exception event is received.

3. The system according to claim 2, characterized in that, Each of the aforementioned operators is used, upon receiving the execution instruction from the basic actuator, to invoke the hardware resources of the corresponding functional module to execute an action corresponding to the operator type, including: The navigation manipulator is used to parse the opcode and parameter load in the execution command, call the chassis motion control interface to generate speed and attitude control quantities, and perform path following and station docking according to the path point set associated with the task instance identifier. The operation controller is used to call the actuator interface and detection interface bound to the functional compartment according to the operation parameters in the execution command to perform the delivery or cleaning action; The recharge operator is used to call the chassis motion control interface and the charging device communication interface according to the docking parameters in the execution command to complete the docking and charging control. The interactive operator is used to drive the human-computer interaction components to output prompts and collect confirmation input based on the interactive template identifier in the execution instruction; The exception handling operator is used to trigger task interruption control and generate a recovery or rollback instruction associated with the task instance identifier when an exception event instruction is received, and submit it to the basic executor.

4. The system according to claim 1, characterized in that, The task model specifically includes: The Identifier and Metadata Unit is used to assign a unique task instance identifier to a task instance and store the task type, priority field, and parameter payload as metadata. Queues and dependency units are used to maintain task queues and parent-child task relationships, record task execution order and dependency constraints, and provide a schedulable entry retrieval interface to the basic executor. The state storage unit is used to save the state field and version number of the task instance, and record the trigger reason code and timestamp related to the state change; The resource binding unit is used to record the binding relationship between task instances and target operators, functional modules and hardware capability identifiers, so that the basic actuators can perform capability matching and conflict verification. The serialization and persistence unit is used to serialize task instances and their status fields and write them to external storage, and provides a deserialization recovery interface when the system restarts.

5. The system according to claim 1, characterized in that, The communication coordination module specifically includes: The communication interface unit is used to provide a unified message transmission interface to the basic actuator, the set of manipulators, the chassis, the functional compartment and the edge computing node, and to shield the differences in the underlying link. The channel management unit is used to maintain local area communication channels and wide area communication channels, route messages by topic, and manage target channels. The message encoding and parsing unit is used to encode and parse instruction and status data according to a unified message format; The transmission control unit is used to configure the quality of service level field and retransmission, sequence number and idempotency identification processing strategies for different messages; The authentication and access control unit is used to authenticate message publishing and subscription based on device identifiers or roles and to issue topic access permissions. The event distribution and subscription management unit is used to distribute the execution instructions generated by the basic executor and the state change events generated by the task model to the target operator or related nodes, and to receive the status messages reported by each node. The equipment status synchronization unit is used to receive the online and heartbeat status of the functional compartments and chassis and submit it to the basic actuators and task model.

6. The system according to claim 1, characterized in that, The system also includes a resource conflict detection module, which is used to detect conflicts in the hardware resource usage of the functional cabin by the operator set before the task instance enters execution, and to adjust the scheduling order or split low-priority tasks when a conflict is detected.

7. The system as described in claim 1, characterized in that, The system also includes a cabin control service module, which is used to abstract the underlying communication protocols of each functional cabin and provide a unified remote procedure call interface to the set of operators.

Images