A robot task orchestration method and system

Abstract

The embodiments of the present disclosure at least provide a robot task scheduling method and system. The method comprises: a control chip acquires a command token of a master control chip; the command token is generated by a currently activated node in a soft behavior tree of the master control chip; target hardware state information required for executing an atomic action is determined by querying a hardware access condition table according to an atomic action indicated by the command token; the atomic action is access checked according to the target hardware state information and currently maintained hardware state information; when the access check fails, the command token is intercepted, and a suspension signal is sent to the master control chip; the suspension signal is used to freeze the execution progress of the currently activated node in the soft behavior tree of the master control chip; and during the freezing, a self-healing operation is performed on the underlying hardware; after the self-healing operation is completed, a recovery signal is sent to the master control chip, and the recovery signal is used to indicate that the currently activated node continues to execute from the execution progress when it is frozen.

Description

Technical Field

[0001] This disclosure relates to the field of robotics technology, and in particular to a method and system for robot task orchestration. Background Technology

[0002] With the increasing application of advanced intelligent robots, such as quadruped robots, embodied intelligent terminals, and industrial autonomous mobile robots, in complex environments, their task orchestration software needs to be capable of handling both high-level business logic and low-level hardware protection logic. High-level business logic, which constitutes a soft task flow, is typically orchestrated by algorithm developers or users based on behavior trees, such as multi-stage task flows for user applications like "go to point A" or "perform inspection and photography." Low-level hardware protection logic represents hard safety boundaries, usually written by low-level control engineers to safeguard the robot's physical integrity, such as defense mechanisms for physical safety like "battery overheat protection," "motor stall self-healing," and "ultrasonic near-ground stop."

[0003] In existing robot software system architectures, the two types of logic mentioned above are typically mixed and written in the same control engine. This approach requires exhaustively defining the handling logic for every combination of business functions and hardware anomalies, leading to system bloat, difficulty in expansion, and a high risk of logical conflicts. Business layer developers need in-depth knowledge of the underlying hardware status, resulting in a high development threshold, high coupling between software and hardware, and a single change easily triggering a chain reaction of failures. Furthermore, when intermittent anomalies occur in the underlying hardware, the system can only report an error and restart the task, making it difficult to guarantee the success rate of tasks in industrial scenarios. Summary of the Invention

[0004] This disclosure provides at least one robot task orchestration method and system that decouples the mixed orchestration of business logic and security logic, and solves the problems of state explosion, hardware and software coupling, and tasks being easily reset due to underlying anomalies.

[0005] In a first aspect, a robot task orchestration method is provided, applied to a control chip, comprising: acquiring a command token from a main control chip; the command token being generated by a currently active node in the soft behavior tree of the main control chip; querying a hardware admission condition table according to the atomic action indicated by the command token to determine the target hardware state information required to execute the atomic action; performing admission verification on the atomic action according to the target hardware state information and the currently maintained hardware state information; intercepting the command token and sending a suspension signal to the main control chip when the admission verification fails; the suspension signal being used to freeze the execution progress of the currently active node in the soft behavior tree of the main control chip; and, during the freezing period, controlling the underlying hardware to perform a self-healing operation; and sending a recovery signal to the main control chip after the self-healing operation is completed, the recovery signal being used to instruct the currently active node to continue execution from the execution progress at the time of freezing.

[0006] In one embodiment, the control chip runs a hardware-functional state machine, which is used to maintain the hardware state information and perform the admission verification. The hardware-functional state machine communicates with the soft behavior tree using an asynchronous suspension and recovery protocol, which is independent of the state feedback mechanism natively defined by the soft behavior tree. When the admission verification fails, intercepting the command token and sending a suspension signal to the main control chip includes: when the admission verification fails, sending the suspension signal to the soft behavior tree through the hardware-functional state machine based on the asynchronous suspension and recovery protocol to freeze the current node context pointer and timeout timer of the soft behavior tree. After the self-healing operation is completed, sending a recovery signal to the main control chip includes: after the self-healing operation is completed, sending the recovery signal to the soft behavior tree through the hardware-functional state machine based on the asynchronous suspension and recovery protocol to restore the current node context pointer and timeout timer.

[0007] In one implementation, the control chip and the main control chip are independent physical chips; the control chip runs a real-time operating system, and the main control chip runs a non-real-time operating system; the hardware function state machine is deployed in the middleware layer of the control chip, and the software behavior tree is deployed in the business application layer of the main control chip; the middleware layer is located between the algorithm layer and the hardware driver layer of the control chip; the hardware function state machine is used to perform the admission verification and interception on the low-level control instructions after the algorithm layer generates the low-level control instructions according to the command token and before the low-level control instructions reach the hardware driver layer; the suspend signal and the resume signal are sent directly from the middleware layer of the control chip to the software behavior tree of the main control chip, without logical processing or decision intervention by the algorithm layer.

[0008] In one implementation, the hardware admission condition table is an M-row, N-column matrix table. The M rows correspond to M atomic actions that can be issued, and the N columns correspond to N hardware state components of the maintained hardware state information. The matrix elements of the hardware admission condition table take either a first matrix value or a second matrix value. The first matrix value indicates that the execution of the corresponding atomic action strongly depends on the corresponding hardware state component being normal, and the second matrix value indicates that the execution of the corresponding atomic action does not depend on the corresponding hardware state component. The step of querying the hardware admission condition table according to the atomic action indicated by the command token to determine the target hardware state information required for the execution of the atomic action includes: extracting the row with the same sequence number as the atomic action in the hardware admission condition table as a row vector; wherein, the hardware state component corresponding to the component taking the first matrix value in the row vector belongs to the target hardware state information.

[0009] In one implementation, the step of performing admission verification on the atomic action based on the target hardware state information and the currently maintained hardware state information includes: representing the currently maintained hardware state information as a hardware state vector, where both the hardware state vector and the row vector are N-dimensional vectors; for each component with the same index in the hardware state vector and the row vector, performing a logical OR operation between the component with that index in the hardware state vector and the inverse of the component with that index in the row vector to obtain the item result for that index; performing a logical AND operation on all N item results to obtain the admission verification result; when all item results are true, the admission verification passes; when any item result is false, the admission verification fails.

[0010] In one implementation, performing a logical OR operation on each component with the same index in the hardware state vector and the row vector includes: recording the component in the row vector corresponding to the target hardware state information as the component to be operated; for each component to be operated, performing a logical OR operation on the value of the component with the same index in the hardware state vector and the inverse value of the component to be operated to obtain the item result of that component; and performing a logical AND operation on the item results of all the components to be operated to obtain the admission verification result.

[0011] In one implementation, the atomic action is subjected to admission verification based on the target hardware state information and the currently maintained hardware state information, including: determining the value of the target hardware state component from the currently maintained hardware state information based on the target hardware state information; verifying whether the value of each target hardware state component is normal; if the value of all target hardware state components is normal, the admission verification passes; if the value of any target hardware state component is abnormal, the admission verification fails.

[0012] In one embodiment, the method further includes: continuously refreshing the hardware status information at a preset period; when any hardware status component of the hardware status information changes from normal to abnormal during the execution of the atomic action, and the hardware status component belongs to the target hardware status information on which the atomic action depends, cutting off the drive current sent to the underlying layer, and triggering the suspension signal carrying a physical error code to be sent to the main control chip.

[0013] In one implementation, the control of the underlying hardware to perform a self-healing operation includes: during the freeze period, the control chip acquires control of the underlying hardware; according to a locally fixed security protection strategy, it independently controls the underlying hardware to perform physical protection or self-healing operations, the execution of the self-healing operation not depending on the computing power of the main control chip; the self-healing operation includes controlling the robot to perform a low-power crouching heat dissipation posture, and / or performing reconstruction and reset of the internal physical bus network.

[0014] Secondly, embodiments of this disclosure also provide a robot task orchestration method applied to a main control chip, comprising: generating a command token based on a currently activated node of a soft behavior tree and sending the command token to a control chip; the command token indicating an atomic action to be executed; freezing the execution progress of the currently activated node in response to a suspension signal sent by the control chip when the admission verification of the atomic action fails; and unfreezing the execution progress in response to a recovery signal sent by the control chip, so that the currently activated node continues execution from the frozen execution progress.

[0015] In one implementation, the soft behavior tree is deployed in the business application layer of the main control chip; the soft behavior tree does not rely on the code of the control chip when modifying business functions; the main control chip runs a non-real-time operating system, and the control chip runs a real-time operating system; the main control chip and the control chip are independent physical chips; the suspend signal and the resume signal are transmitted directly between the main control chip and the control chip, without passing through the algorithm layer.

[0016] In one implementation, in response to a suspension signal sent by the control chip when the admission verification of the atomic action fails, freezing the execution progress of the currently activated node in the soft behavior tree includes: the main control chip responding to the suspension signal by controlling the currently activated node not to return the execution result to the parent node; locking the behavior pointer of the currently activated node and keeping the behavior pointer statically fixed; and pausing the timeout timer bound to the currently activated node.

[0017] In one implementation, in response to a recovery signal sent by the control chip, unfreezing the execution progress and enabling the currently activated node to continue execution from the point where the execution progress was frozen includes: in response to the recovery signal, unfreezing the behavior pointer and restoring the timeout timer; and resuming execution from the point where the currently activated node was frozen.

[0018] In one implementation, freezing the execution progress of the currently activated node includes: in response to the suspension signal, rewriting the frozen flag stored in the blackboard of the soft behavior tree to a frozen value; the conditional branch node of the soft behavior tree, in response to the frozen value of the frozen flag, jumping the execution flow from the main task branch to a preset virtual stub node; the virtual stub node executing a conditional branch loop on the soft behavior tree, so that the soft behavior tree resides at the virtual stub node, and the currently activated node does not return the execution result to the parent node; unfreezing the execution progress includes: the main control chip, in response to the recovery signal, resetting the frozen flag in the blackboard; the conditional branch node, in response to the reset frozen flag, controlling the soft behavior tree to exit the conditional branch loop and jump back to the main task branch, resuming execution from the execution progress when frozen; wherein, the rewriting and resetting of the frozen flag does not modify the node structure of the soft behavior tree.

[0019] In one implementation, generating a command token based on the currently activated node of a soft behavior tree includes: activating leaf nodes in a polling manner, determining the activated leaf nodes as the currently activated nodes; and generating an atomic command token for a multi-stage task flow from the currently activated nodes as the command token, wherein the multi-stage task flow includes at least one of going to a target point, activating a vision camera, performing grid-based inspection and photography, and returning to a charging pile.

[0020] In one implementation, the suspend signal carries a physical error code; the method further includes: the main control chip records the reason why the currently activated node is frozen according to the physical error code, and stops issuing new command tokens to the control chip until the recovery signal is received.

[0021] In one embodiment, the control chip runs a simplified behavior tree, which includes a shadow mirror node corresponding to the currently activated node; the shadow mirror node is used to align the execution state with the currently activated node; the suspend signal and the resume signal are transmitted by the control chip to the currently activated node through the shadow mirror node.

[0022] Thirdly, a robot task orchestration system is provided, including:

[0023] The main control chip is used to generate a command token based on a soft behavior tree and send the command token to the control chip; the command token indicates an atomic action to be executed; in response to a suspension signal sent by the control chip when the admission verification of the atomic action fails, the execution progress of the currently activated node in the soft behavior tree is frozen; and in response to a recovery signal sent by the control chip, the execution progress is unfrozen, allowing the currently activated node to continue execution from the frozen execution progress position. The control chip is configured to query a hardware admission condition table based on the atomic action indicated by the command token to determine the hardware state required to execute the atomic action; perform admission verification on the atomic action based on the determined required hardware state and the maintained hardware state vector; if the admission verification fails, intercept the command token to prevent the hardware from executing the atomic action and send a suspension signal to the main control chip; the suspension signal is used to freeze the execution progress of the currently activated node in the soft behavior tree of the main control chip; and during the freeze, control the underlying hardware to perform a self-healing operation; and after the self-healing operation is completed, send a recovery signal to the main control chip.

[0024] This embodiment utilizes a layered architecture with independent main control chip and control chip, separating business logic and security logic and allowing them to run on different chips. Each evolves independently; adding or deleting business functions or expanding security logic does not require exhaustive combinations and jumps within a single control engine, eliminating system bloat and the risk of cascading changes caused by hybrid orchestration at the architectural level. Furthermore, this embodiment uses the control chip to perform access verification on commands from the main control chip. Only commands that pass verification are allowed to be sent to the underlying hardware for execution; those that fail are blocked. The business layer only needs to issue commands without needing to understand any hardware physical state details, achieving isolation between business and hardware. Simultaneously, because the control chip operates independently, even if the main control chip experiences a freeze or lockup, the control chip can still independently complete command verification and interception, ensuring that the overall physical security of the machine is not affected by upper-layer software anomalies. In addition, this embodiment sends a suspend signal to the main control chip when verification fails. Upon response, the main control chip freezes the execution progress of the current node; after the control chip completes its underlying self-healing, it sends a recovery signal, and the main control chip unfreezes the node and continues execution from where it left off. The entire process does not require resetting the behavior tree or reinitializing the task, enabling the task to be suspended in place and seamlessly resumed in case of underlying exceptions. This avoids the task interruption caused by the traditional mechanism of starting over when an error occurs, and significantly improves the task continuity and execution efficiency in industrial scenarios.

[0025] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this disclosure.

[0026] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.

[0028] Figure 1 A flowchart of a robot task orchestration method provided in one embodiment of this disclosure; Figure 2 This is a schematic diagram of the robot system architecture provided in the embodiments of this disclosure; Figure 3 A flowchart of a robot task orchestration method provided in another embodiment of this disclosure; Figure 4 A schematic diagram of a robot task orchestration system 400 provided in an embodiment of this disclosure; Figure 5 This is a schematic diagram of the interaction corresponding to the robot task orchestration system described above; Figure 6 This is a schematic diagram of the physical and logical mapping of a dual-chip chip provided in an embodiment of this disclosure. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0030] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0031] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0032] Furthermore, the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein.

[0033] Research has revealed that in relevant robot task orchestration schemes, high-level business logic and low-level hardware protection logic are often mixed and written in the same control engine. This leads to problems such as state combinatorial explosion, high coupling between software and hardware, and frequent task resets due to occasional low-level anomalies when the system expands its functionality. To address these issues, this disclosure provides a robot task orchestration method. The core idea is to physically separate the main control chip running the business logic from the control chip running the security logic. The control chip independently performs access verification on each command token issued by the main control chip. If the verification passes, the command is allowed to be issued to the low-level hardware for execution; if the verification fails, the command is intercepted and hardware action is prohibited. Simultaneously, when verification fails, the control chip sends a suspend signal to the main control chip. Upon response, the main control chip freezes the execution progress of the current node and does not return any state. After the control chip completes its low-level self-healing, it sends a recovery signal, and the main control chip unfreezes the node and continues execution from the original progress.

[0034] The specific embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0035] like Figure 1 As shown, this disclosure provides a robot task orchestration method applied to a control chip, including: S101: Obtain the command token of the main control chip; the command token is generated by the currently activated node in the soft behavior tree of the main control chip.

[0036] In this embodiment, the main control chip runs a Soft Behavior Tree (SBT). This SBT is orchestrated by algorithm developers or users based on specific business scenarios, including multi-stage task flows such as "go to point A," "perform grid-based inspection and photography," and "return to the charging pile." During operation, the SBT polls its nodes according to a predetermined strategy. When a leaf node is activated, it generates a corresponding command token based on its bound business logic. This command token is an abstract description of an atomic action, such as "go to the target point," "activate the visual camera," "perform grid-based inspection and photography," or "return to the charging pile," representing an indivisible minimum business operation unit. After generating the command token, the main control chip sends it to the control chip via a cross-chip communication bus (such as PCIe or Ethernet). Correspondingly, the control chip obtains the command token through its communication interface as input for subsequent security verification.

[0037] The atomic actions or atomic command tokens described in this embodiment are relative to the business application layer where the soft behavior tree resides. At this business orchestration level, the atomic action represents a minimal business operation unit with complete semantics. For example, "go to the target point" is considered an indivisible atomic action at the business layer, and its internal path planning, gait generation, motor drive, and other low-level implementation details are transparent to the soft behavior tree. When the command token is issued to the control chip, the algorithm layer of the control chip further decomposes it into multiple low-level control primitives (such as forward, turn, etc.) for hardware execution. Therefore, the atomic action refers to the smallest orchestration unit oriented towards the business application layer.

[0038] S102: Based on the atomic action indicated by the command token, query the hardware admission condition table to determine the target hardware state information required to execute the atomic action.

[0039] In this embodiment, the control chip has a pre-built hardware admission condition table, which records the dependency relationship between each possible atomic action and various hardware states. Different atomic actions have different degrees of dependency on the underlying hardware. For example, "going to the target point" may depend on the battery voltage, motor temperature, and communication link status all being normal, while "performing grid-based inspection and photography" may only depend on the camera power supply being normal and is not sensitive to motor temperature.

[0040] Once the control chip obtains the command token, it can parse the atomic action identifier carried within it. Using this identifier as an index, it can query the hardware admission condition table to determine the target hardware state information upon which the execution of the atomic action depends. The target hardware state information is a security prerequisite for executing the action; only when all the dependent hardware states meet the normal conditions can the action be executed safely.

[0041] S103: Perform admission verification on the atomic action based on the target hardware status information and the currently maintained hardware status information.

[0042] In this embodiment, the control chip independently maintains a set of real-time updated hardware status information. This information reflects the actual physical condition of the robot at the current moment, such as whether the battery voltage is normal, whether the motor temperature exceeds the limit, and whether the communication link is unobstructed. The control chip continuously refreshes this hardware status information at a high frequency (e.g., 1kHz) to ensure that it remains synchronized with the actual physical state of the underlying hardware.

[0043] After determining the target hardware state information required for the current atomic action in step S102, the control chip compares and verifies the target hardware state information with the currently maintained hardware state information. For example, it checks whether all dependent hardware states are normal at the current moment. If all are normal, it means that the current physical state of the system fully meets the security boundary of the business action, and the access verification passes. If any dependent hardware state is abnormal, it means that there is a security risk in executing the action, and the access verification fails. This verification process is completed by the control chip, independent of the main control chip, without the business layer's involvement, thus achieving physical boundary isolation.

[0044] S104: When the admission verification fails, the command token is intercepted and a suspension signal is sent to the main control chip; the suspension signal is used to freeze the execution progress of the currently activated node in the soft behavior tree of the main control chip; and during the freeze, the underlying hardware is controlled to perform a self-healing operation.

[0045] In practice, when the access verification result of step S103 is unsuccessful, it indicates that the current hardware state of the robot does not meet the safety conditions for executing the atomic action. At this time, the control chip immediately performs an interception operation: cutting off the path of the command token to the underlying hardware driver layer, and prohibiting the conversion of the action instruction into actual motor current or actuator drive signal, thereby completely blocking the instruction before it reaches the hardware and preventing the robot from performing actions in an unsafe state.

[0046] Simultaneously, the control chip bypasses the intermediate algorithm layer and directly sends a suspension signal to the main control chip's soft behavior tree. This suspension signal notifies the main control chip that a security issue exists at the underlying level, requiring a halt to service execution. Upon receiving this suspension signal, the main control chip's soft behavior tree engine freezes the currently executing node, essentially freezing its execution progress. This includes maintaining the node's behavior pointer statically, preventing pointer shifting towards parent or child nodes, and pausing all service layer timeout timers bound to the node to prevent false timeouts at the software level while waiting for the underlying self-healing process. During this process, the soft behavior tree does not return traditional running, success, or failure states to any parent node; instead, it enters a special frozen suspension state, awaiting subsequent recovery instructions.

[0047] S105: After the self-healing operation is completed, a recovery signal is sent to the main control chip. The recovery signal is used to instruct the currently activated node to continue execution from the execution progress when it was frozen.

[0048] In this embodiment, after the control chip sends a suspend signal to the main control chip and the main control chip's behavior tree enters a frozen state, the control chip retains absolute control over the underlying hardware during this period. Based on its locally implemented security protection strategy, the control chip independently controls the underlying hardware to perform self-healing operations; this process does not require the main control chip's computing power.

[0049] For example, if the cause of the anomaly is motor overheating, the control chip can control the robot to perform a low-power squatting posture on the spot to dissipate heat; if the cause of the anomaly is an occasional drop of the communication link, the control chip can perform reconstruction and reset of the internal physical bus network.

[0050] The control chip continuously monitors the hardware status. Once the self-healing operation is complete and the hardware status returns to normal, the control chip sends a recovery signal to the main control chip's soft behavior tree. Upon receiving this recovery signal, the main control chip's soft behavior tree engine releases the frozen state of the current node: restoring the node's original behavior pointer so that it points back to the node's position when it was frozen, and simultaneously resuming the paused timeout timer. Afterward, the robot continues executing its tasks from its original physical position and task state when it was forcibly suspended, without needing to reinitialize or reset the behavior tree, achieving seamless task continuation.

[0051] In one embodiment, the software architecture and interaction protocol of the control chip and the main control chip are specifically configured as follows: the control chip runs a hard functional state machine (Hard FSM, HFSM), which is used to maintain the hardware state information and perform the above-mentioned admission verification, instruction interception, and suspension / resumption control; the hard functional state machine and the soft behavior tree communicate with each other using an asynchronous suspension and resumption protocol, which is independent of the state feedback mechanism (Running, Success, Failure) natively defined by the soft behavior tree.

[0052] This disclosure deploys two different software execution engines, a soft behavior tree and a hard function state machine, on the main control chip and control chip, respectively. Their design intent, operating environment, and responsibilities differ. The soft behavior tree runs at the business application layer of the main control chip and is a top-level task orchestration tool oriented towards user business scenarios. It is designed and configured by algorithm developers or users according to specific application requirements to organize the logical sequence, conditional branches, and loop execution relationships between a series of high-level business actions (such as going to point A, activating the visual camera, performing grid-based inspection and photography, returning to the charging pile, etc.). Each node in the soft behavior tree corresponds to an atomic action with a certain semantic meaning, and its orchestration logic focuses on business-level issues such as task completion status and the next step. This disclosure uses a non-real-time operating system (such as Linux Ubuntu) for the soft behavior tree. This is mainly because the main control chip needs to handle a large number of computationally intensive algorithmic tasks (such as visual perception, path planning, and large model inference), and its scheduling strategy and resource allocation prioritize task throughput and computational efficiency rather than a fixed response time. Furthermore, the hard-function state machine runs in the middleware layer (or software platform layer, or software platform and middleware layer) of the control chip, serving as a low-level monitoring and decision-making engine for the physical safety of the robot. The hard-function state machine does not participate in any high-level business logic orchestration or decision-making. Its core responsibilities include: continuously refreshing and maintaining the robot's hardware status information (such as battery voltage, motor temperature, communication link status, ultrasonic near-ground signal, etc.) at high-frequency cycles (e.g., 1kHz); performing the aforementioned access verification and interception operations on each command token issued by the main control chip; and independently controlling the underlying hardware to perform self-healing operations when hardware anomalies occur. The hard-function state machine operates in a real-time operating system environment because safety logic requires a defined response delay. When the hardware state deteriorates, the control chip must react and cut off the drive current within milliseconds; any unpredictable delay could lead to hardware damage or safety incidents.

[0053] In step S104, when the admission verification fails, the hardware state machine sends a suspension signal to the soft behavior tree based on the asynchronous suspension and recovery protocol. Upon receiving the signal, the soft behavior tree freezes its current node context pointer and timeout timer. Optionally, the suspension signal may carry a specific physical error code to notify the main control chip of the cause of the abnormality. After the self-healing operation is completed, the hardware state machine may send a recovery signal to the soft behavior tree based on the asynchronous suspension and recovery protocol. The soft behavior tree responds and restores its current node context pointer and timeout timer.

[0054] This asynchronous suspension and recovery protocol is independent of the state feedback mechanism natively defined by the soft behavior tree. Essentially, it's an event-driven interrupt signaling mechanism actively initiated by the control chip, unlike the synchronous blocking mode of traditional main control chips periodically polling hardware. In the traditional mode, the main control chip needs to actively query whether the hardware is ready in each tick cycle. Anomalies occurring during the query interval cannot be captured in time, and when the main control chip is running a non-real-time operating system, high load tasks may lead to polling delays or even missed detections. However, in the asynchronous suspension and recovery protocol of this embodiment, the control chip, upon failure of the admission verification, does not wait for any query request from the main control chip and actively pushes a suspension interrupt signal to the soft behavior tree; after self-healing, it also actively pushes a recovery signal. The entire communication process is triggered only once each during anomaly occurrence and recovery; the communication link remains silent during normal operation. This mechanism completely liberates the main control chip from the burden of periodically polling the hardware, while reducing the anomaly response delay from milliseconds of traditional polling to microseconds of hardware interrupt triggering, providing ample time for underlying self-healing.

[0055] In one implementation, to ensure the independence and reliability of security logic at the physical level, the embodiments of this disclosure impose the following specific constraints on the hardware selection and software deployment of the control chip and the main control chip: the control chip and the main control chip are independent physical chips; the control chip runs a real-time operating system, and the main control chip runs a non-real-time operating system; the hardware state machine is deployed in the middleware layer of the control chip, and the software behavior tree is deployed in the business application layer of the main control chip; the middleware layer is located between the algorithm layer and the hardware driver layer of the control chip; the hardware state machine is used to perform the admission verification and interception on the low-level control instructions after the algorithm layer generates the low-level control instructions according to the command token and before the low-level control instructions reach the hardware driver layer; the suspend signal and the resume signal are sent directly from the middleware layer of the control chip to the software behavior tree of the main control chip, without logical processing or decision intervention by the algorithm layer.

[0056] In this implementation, the main control chip can be a computing chip such as the S100 that supports non-real-time operating systems (e.g., Linux / Ubuntu), on which the algorithm layer and business application layer are deployed to run computationally intensive tasks such as high-load perception large-scale models. The control chip can be a control chip such as the RK3588 that supports real-time operating systems, on which the software platform, middleware layer, and hardware driver layer are deployed, specifically responsible for monitoring the underlying hardware status and executing security logic. As mentioned earlier, the hardware-functional state machine is deployed in the middleware layer of the control chip (the third layer of the system architecture), which is located between the algorithm layer and the hardware driver layer of the control chip. After the command token issued by the main control chip is processed by the algorithm layer of the control chip to generate specific underlying control instructions, before the underlying control instructions reach the hardware driver layer, the hardware-functional state machine intervenes and performs the admission verification and interception operations of steps S101 to S103 mentioned above on the underlying control instructions. In addition, as mentioned earlier, the soft behavior tree is deployed in the business application layer of the main control chip (the fifth layer of the system architecture). Suspension and resumption signals are sent directly from the middleware layer of the control chip to the soft behavior tree of the main control chip's application layer, without any logical processing or decision-making intervention by the control chip's algorithm layer. In this approach, even if the main control chip experiences occasional pauses or process lock-ups due to high-load tasks, the control chip can still independently complete command verification and instruction interception within milliseconds, safeguarding the overall system's security. Furthermore, security logic and business logic are completely isolated at both the physical chip and software levels; an anomaly in one will not affect the normal operation of the other.

[0057] For example, such as Figure 2 As shown, the robot system architecture of this embodiment includes, from top to bottom, a business application layer, an algorithm layer, a middleware layer (i.e., a software platform layer), a hardware driver layer, and a physical hardware layer.

[0058] Some modules of the business application layer and algorithm layer are deployed on the main control chip (i.e., the brain, such as high-computing chips like the S100). The main control chip runs a non-real-time operating system (such as Linux Ubuntu) to handle computationally intensive tasks such as large-scale perception models and path planning, as well as the orchestration of business logic for user scenarios. Another part of the algorithm layer (such as motion control) is deployed on the control chip (i.e., the cerebellum, such as real-time control chips like the RK3588). The control chip runs a real-time operating system specifically responsible for monitoring the underlying hardware status, executing security logic, and real-time motion control.

[0059] The business application layer is deployed on the main control chip and includes a task manager, a soft behavior tree (SBT), and a cloud / human-machine interface (HMI). The task manager is responsible for task scheduling and lifecycle management, such as starting, pausing, resuming, and terminating multi-stage task flows. The soft behavior tree, as the top-level task orchestration engine, is designed and configured by algorithm developers or users according to specific business scenarios to organize multi-stage task flows such as "going to the target point," "activating the vision camera," "performing grid-based inspection and photography," and "returning to the charging station." The cloud / HMI provides human-machine interaction and remote control capabilities, enabling users to issue task commands to the robot or monitor task execution status through a cloud platform or local HMI.

[0060] The algorithm layer includes a perception module (such as high-dimensional detection and segmentation), a SLAM mapping module (such as visual / LiDAR SLAM), a planning and decision module, and a motion control module. Among them, the perception module, SLAM mapping module, and planning and decision module are deployed on the main control chip and rely on NPU / GPU for accelerated computing; the motion control module is deployed on the control chip and runs on a real-time operating system to ensure deterministic motion control commands and low-latency response.

[0061] The software platform and middleware layer, hardware driver layer, and physical hardware layer are deployed on the control chip. The software platform and middleware layer includes the Robot Operating System 2 (ROS2) / Data Distribution Service (DDS) communication data backbone, the Hard Functional State Machine (HFSM), the hardware access verification matrix, and the Software Development Kit (SDK) / Application Programming Interface (API) interface. The ROS2 / DDS communication data backbone, acting as the communication infrastructure for heterogeneous collaboration between the main control chip and the control chip, as well as between various modules, is responsible for data interaction and message passing. The Hard Functional State Machine continuously refreshes and maintains the hardware state vector S at a high-frequency cycle (e.g., 1kHz), where each bit corresponds to the real-time value (normal / abnormal) of a hardware state component. The hardware access verification matrix is ​​a pre-defined M×N matrix table that records the dependencies between each atomic action and the hardware state component. The SDK / API interface provides standardized application programming interfaces for upper-layer algorithms or business modules to call the underlying hardware capabilities. The middleware layer is positioned between the algorithm layer and the hardware driver layer, enabling the hardware function state machine to perform admission verification and interception operations on the underlying control instructions after the motion control module generates the underlying control instructions based on the command token and before the underlying control instructions reach the hardware driver layer.

[0062] The hardware driver layer includes standardized hardware interfaces such as standardized topic output, sensor driver nodes, and chassis communication nodes. These interfaces are used to shield the specific implementation details of the underlying hardware from the upper layers, allowing upper-layer software to access different hardware devices through a unified interface.

[0063] The physical hardware layer 500 comprises two parts: physical hardware entities and computing infrastructure. Physical hardware entities include sensors and actuators such as monocular / dual-lens cameras, LiDAR / IMU, and motor / joint modules; computing infrastructure includes the main control chip (brain, ARM / NPU), control chip (cerebellum, real-time core), and security MCU, providing computing power support for upper-layer algorithms and applications.

[0064] In this embodiment, the suspend and resume signals are sent directly from the middleware layer of the control chip to the soft behavior tree of the main control chip's business application layer, without passing through the algorithm layer (including the perception, mapping, and planning modules on the main control chip side and the motion control module on the control chip side) for any logical processing or decision-making intervention. In other words, the algorithm layer is bypassed at the logic level. The operating state of the algorithm layer (whether busy, lagging, or crashing) will not interfere with the execution of the security logic or the transmission of the suspend / resume signals. In this way, even if the main control chip experiences occasional lag or process lock-up due to running high-load tasks, the control chip can still independently complete command verification and instruction interception at millisecond intervals, safeguarding the overall system security. Simultaneously, the security logic and business logic are completely decoupled at both the physical chip and software levels; an anomaly in one will not affect the normal operation of the other.

[0065] In one implementation, to efficiently store, query, and update the dependencies between atomic actions and hardware states in engineering, this disclosure embodiment designs the specific data structure and query method of the hardware admission condition table as follows: The hardware admission condition table adopts an M-row, N-column matrix table. The M rows correspond to M atomic actions that can be issued (e.g., walking forward, turning in place, raising the left front leg, turning on the camera to take a picture, etc.), and each row uniquely corresponds to one atomic action. The N columns correspond to the N hardware state components of the maintained hardware state information (e.g., battery voltage state, motor temperature state, communication link state, ultrasonic near-ground signal state, etc.), and each column uniquely corresponds to one hardware state component. The matrix elements of the hardware admission condition table take a first matrix value (e.g., binary logic value 1) or a second matrix value (e.g., binary logic value 0). The first matrix value indicates that the execution of the corresponding atomic action strongly depends on the corresponding hardware state component being normal, and the second matrix value indicates that the execution of the corresponding atomic action does not depend on the corresponding hardware state component. Step S102 involves querying the hardware admission condition table based on the atomic action indicated by the command token to determine the target hardware state information required to execute the atomic action. This includes extracting rows with the same sequence number as the atomic action from the hardware admission condition table as row vectors. The hardware state components corresponding to the components that take the first matrix value in the row vectors belong to the target hardware state information.

[0066] To facilitate understanding, a concrete example is provided. Assume a robot control chip maintains five hardware state components: s1 battery voltage, s2 left front leg motor temperature, s3 right front leg motor temperature, s4 communication link status, and s5 ultrasonic near-ground signal. The control chip's pre-set hardware access condition table contains three atomic actions: A1 walk forward, A2 turn in place, and A3 raise the left front leg to take a picture. One possible form of this matrix table is as follows (each row corresponds to one atomic action, and each column corresponds to one hardware state component): The row vector corresponding to A1 walking forward is [1, 1, 1, 1, 0], which means that performing this action depends on the battery voltage being normal, the temperature of the left front leg motor being normal, the temperature of the right front leg motor being normal, and the communication link being normal, but does not depend on ultrasonic near-ground signals. The row vector corresponding to the A2 stationary turn is [1, 0, 0, 1, 1], which means that performing this action depends on the battery voltage being normal, the communication link being normal, and the ultrasonic near-ground signal being normal, but does not depend on the temperature of the motors of the left and right front legs; The row vector corresponding to A3 raising its left front leg to take a picture is [1, 1, 0, 1, 1], indicating that the execution of this action depends on the normal battery voltage, normal temperature of the left front leg motor, normal communication link, and normal ultrasonic near-ground signal, but does not depend on the temperature of the right front leg motor.

[0067] When the main control chip issues the command token for atomic action A1 (moving forward), the control chip parses its sequence number as 1 and extracts the first row vector [1, 1, 1, 1, 0] from the matrix table. The component with the first matrix value (i.e., 1) in this row vector corresponds to columns 1, 2, 3, and 4. Therefore, the target hardware status information for moving forward is determined to be: normal battery voltage, normal left front leg motor temperature, normal right front leg motor temperature, and normal communication link. The ultrasonic near-ground signal in column 5 takes the second matrix value (i.e., 0), which is not part of the target hardware status information. Even if the ultrasonic wave is triggered, it will not affect the access judgment of the moving forward action. When the main control chip issues the command token for atomic action A2 (turning in place), it extracts the second row vector [1, 0, 0, 1, 1]. The target hardware status information is: normal battery voltage, normal communication link, and normal ultrasonic near-ground signal. Whether the left and right front leg motor temperatures are normal does not affect the access verification of the turning in place action. And so on. This matrix-based hardware admission condition table can fully reveal all hardware dependencies for any atomic action with a single row read. Its well-organized storage structure and short query paths perfectly meet the data access efficiency and deterministic computation requirements of real-time control chips. Furthermore, the static pre-configuration of the matrix table allows hardware dependencies to be maintained and updated uniformly during the compilation phase as the product iterates, avoiding the uncertainty and overhead associated with runtime dynamic configuration.

[0068] In one implementation, to provide an efficient and deterministic admission verification method, this disclosure further provides a verification process based on Boolean algebra operations, building upon the aforementioned matrix table structure: The currently maintained hardware state information is represented as a hardware state vector, where both the hardware state vector and the row vector are N-dimensional vectors; for each component with the same index in the hardware state vector and the row vector, a logical OR operation is performed between the component with that index in the hardware state vector and the inverse of the component with that index in the row vector to obtain the item result for that index; a logical AND operation is performed on all N item results to obtain the admission verification result; when all item results are true, the admission verification passes; when any item result is false, the admission verification fails.

[0069] For example, to facilitate understanding of the above verification process, the hardware state information currently maintained by the control chip can be abstracted into an N-dimensional hardware state vector. Each element in this vector corresponds to the real-time value of a hardware state component, and each element is encoded in binary, for example, 1 represents the corresponding hardware state as normal and 0 represents as abnormal. Meanwhile, the row vector extracted from the hardware admission condition table in the aforementioned steps is regarded as an N-dimensional dependency vector of the same dimension, and its elements are also encoded in binary, for example, 1 represents that performing the atomic action depends on the hardware state component and 0 represents that it does not depend on it.

[0070] Based on the above vector representation, let the hardware state vector be... The dependency vector (i.e., the aforementioned row vector) is ,in , Admission verification function The mathematical expression is: ; in, Represents logical OR, Indicates logical NOT. This indicates a logical AND operation on the results of all N dimensions. The physical meaning of this expression is: for each dimension, the hardware must be in a normal state (…). Or the hardware is not dependent on the current action. The validation passes when this condition is met in all dimensions. If any dimension simultaneously satisfies the hardware state anomaly (i.e., true); And the hardware is dependent on ( If ), then the verification fails. (i.e., false). This verification method can be completed by reading a matrix row and performing parallel Boolean operations on an N-dimensional vector in one operation. It is fast, deterministic, and suitable for high-frequency execution on real-time control chips.

[0071] In one implementation, the aforementioned admission verification can be implemented either by a full computation method that traverses all hardware state dimensions, or by a simplified computation method that only verifies the hardware state components that the current atomic action actually depends on. The specific method can be flexibly selected according to the actual application scenario.

[0072] For example, if a full-scale computation method is used, the hardware state information currently maintained by the control chip can be represented as an N-dimensional hardware state vector, the same as the total number of hardware state dimensions. Simultaneously, the row vectors corresponding to the current atomic action, extracted from the aforementioned hardware admission condition table, are used as dependency vectors of the same dimension. During verification, for each component with the same index in the hardware state vector and the row vector (i.e., traversing all hardware state components from dimension 1 to dimension N), a logical OR operation is performed between the actual value of that indexed component in the hardware state vector and the inverse value of that indexed component in the row vector to obtain the item result for that dimension. Then, a logical AND operation is performed on the item results for all N dimensions to obtain the final admission verification result. When all N item results are true, the admission verification passes; when any dimension item result is false, the admission verification fails. Although this full-scale computation method requires traversing all hardware state dimensions, its computational logic is regular, suitable for accelerated processing using vectorized parallel instructions, and has the advantages of simple implementation and no need for additional filtering and judgment in scenarios where the total number of hardware state dimensions is small or the processor has strong vector computation capabilities.

[0073] To facilitate understanding, we will use a robot with four hardware state dimensions (N=4) for maintenance: battery voltage, motor temperature, communication link, and ultrasonic near-ground signal. Assume the main control chip issues an atomic action command token for "walk forward." The control chip extracts the dependency row vector corresponding to this action from the hardware admission condition table as [1, 1, 1, 0], indicating that executing "walk forward" depends on normal battery voltage, normal motor temperature, and normal communication link, but not on the ultrasonic near-ground signal. At this time, the real-time hardware state vector maintained by the control chip is [1, 0, 1, 1], indicating normal battery voltage, abnormal motor temperature, normal communication link, and normal ultrasonic near-ground signal. Using the full-scale calculation method, calculations are performed one by one from dimension 1 to dimension 4: dimension 1 is 1 or (not 1) = 1 or 0 = 1, dimension 2 is 0 or (not 1) = 0 or 0 = 0, dimension 3 is 1 or (not 1) = 1 or 0 = 1, and dimension 4 is 1 or (not 0) = 1 or 1 = 1. The results for the four dimensions are 1, 0, 1, and 1 respectively. After performing a logical AND operation, the result is 0, which fails the validation because the second dimension simultaneously satisfies both "abnormal motor temperature" and "walking action depends on normal motor temperature".

[0074] If a simplified calculation method is adopted, the above verification process can be performed only on the hardware state components that the current atomic action actually depends on, instead of traversing all N hardware state dimensions. In specific implementation, the components in the row vector corresponding to the target hardware state information are recorded as components to be calculated; for each component to be calculated, the value of the component with the same index in the hardware state vector as the component to be calculated is logically ORed with the inverse value of the component to be calculated to obtain the term result of that component; the term results of all the components to be calculated are logically ANDed to obtain the admission verification result.

[0075] Here, in the row vector of the hardware admission condition table, components with a value of 0 indicate that the current atomic action does not depend on that hardware state component. These components will not affect the final verification result regardless of the actual hardware state. Therefore, in actual calculation, only the components in the row vector corresponding to the target hardware state information (i.e., components with a value of 1, indicating dependence) can be marked as components to be calculated. For these components to be calculated, the actual value of the component with the same index in the hardware state vector is logically ORed with the inverse value of the component to be calculated to obtain the item result of that component. Finally, the item results of all components to be calculated are logically ANDed to obtain the final admission verification result. This simplified calculation method is mathematically equivalent to the aforementioned full verification method that traverses all N dimensions, but it effectively reduces the amount of computation by eliminating the participation of dependent items in the calculation. In practical application scenarios where the hardware state vector dimension is large and most atomic actions only depend on a few hardware state components, this optimization method can significantly improve verification efficiency and reduce the consumption of computing resources of the control chip.

[0076] Continuing with the previous example: The robot has a 4-dimensional hardware state. The current "walk forward" action depends on the row vector [1, 1, 1, 0], where dimensions 1, 2, and 3 are the dependent components to be calculated, and dimension 4 (ultrasonic near-ground signal) is skipped because it is independent. The control chip's current hardware state vector is [1, 0, 1, 1]. The simplified calculation method only performs calculations on the components to be calculated: dimension 1 is calculated as 1 or (not 1) = 1, dimension 2 is calculated as 0 or (not 1) = 0, and dimension 3 is calculated as 1 or (not 1) = 1. The results of the three components to be calculated are 1, 0, and 1 respectively. After performing a logical AND operation, the result is 0, and the verification fails. This result is completely consistent with the aforementioned full calculation method, the difference being that the simplified calculation method does not require any calculation of the 4th dimension. This simplified calculation method is mathematically equivalent to the aforementioned full verification method that traverses all N dimensions, but it reduces the amount of computation by eliminating the independent components involved in the calculation. In real-world applications where the hardware state vector dimension is large and most atomic actions depend on only a few hardware state components, this optimization method can significantly improve verification efficiency and reduce the computational resource consumption of the control chip.

[0077] In one implementation, the admission verification in step S103 can also be implemented using a condition-based step-by-step check. The core idea of ​​this approach includes: determining the values ​​of target hardware state components from the currently maintained hardware state information based on the target hardware state information; verifying whether the values ​​of each target hardware state component are normal; if all the values ​​of the target hardware state components are normal, the admission verification passes; if any of the target hardware state components has an abnormal value, the admission verification fails.

[0078] For example, in step S103, after querying the hardware access condition table based on the command token and determining the target hardware state information required to execute the current atomic action, the control chip uses the target hardware state information as an index to extract the current actual value of each target hardware state component from its own real-time maintained hardware state information. For example, if the target hardware state information indicates that the atomic action depends on two components, battery voltage and motor temperature, then the current values ​​of these two components are extracted from the current hardware state information, such as the battery voltage being normal and the motor temperature being abnormal. Subsequently, the value of each extracted target hardware state component is verified one by one to check whether they are all normal. If the values ​​of all target hardware state components are normal, the access verification passes, and the control chip sends the command token to the underlying hardware for execution; if any target hardware state component has an abnormal value, the access verification fails, the control chip intercepts the command token, and triggers a suspension process. Taking the same scenario as described above as an example, suppose the "walk forward" action depends on three hardware components: battery voltage, motor temperature, and communication link. Currently, the actual states of these three components are normal, abnormal, and normal, respectively. After checking each component, if the motor temperature is found to be abnormal, the verification fails, and the action is blocked. Conversely, if all three components are currently normal, the verification passes, and the command is allowed to execute. The advantage of this verification method is its clear logic and straightforward judgment conditions. It eliminates the need for bitwise operations or Boolean algebra transformations, helping to lower the understanding threshold for developers and facilitating the rapid identification of the specific reasons for verification failure during debugging and maintenance.

[0079] To maintain continuous monitoring of hardware security even after an atomic action has passed access verification and been issued for execution, this disclosure also provides a dynamic monitoring and real-time response mechanism during execution. Steps S101 to S105 primarily describe the access verification and interception process that the command token undergoes before execution. However, in actual operation, the hardware state is not static and may suddenly deteriorate during command execution. Therefore, one embodiment of this disclosure extends security monitoring from static verification before execution to dynamic protection during execution, achieving full lifecycle security. In one embodiment, the method further includes: continuously refreshing the hardware state information at a preset period; when any hardware state component of the hardware state information changes from normal to abnormal during the execution of the atomic action, and the hardware state component belongs to the target hardware state information upon which the atomic action depends, cutting off the drive current to the underlying layer and triggering the suspension signal carrying a physical error code to be sent to the main control chip.

[0080] For example, the control chip continuously refreshes its internally maintained hardware status information at a preset cycle (e.g., 1 kHz, or once every millisecond) to ensure that this information is always synchronized with the actual physical state of the underlying hardware. After the atomic action passes the access verification and the command token has been issued to the underlying hardware to begin execution, the control chip does not stop monitoring but continues to refresh at a high frequency, comparing the refreshed hardware status information with the target hardware status information on which the currently executing atomic action depends in real time. When any hardware status component in the hardware status information is detected to change from normal (e.g., binary value 1) to abnormal (e.g., binary value 0), and the abnormal component happens to belong to the target hardware status information on which the currently executing atomic action depends, the control chip immediately takes safety measures. These include: firstly, immediately cutting off the drive current to the underlying hardware (such as motor drivers, actuators, etc.), causing the robot's execution components to stop operating urgently. This rapid power-off operation at the physical level can stop the robot from continuing to perform actions that may cause damage within milliseconds, preventing irreversible physical damage to the hardware due to continuous operation in an abnormal state, or preventing the robot from posing a safety threat to the surrounding environment and personnel in an out-of-control state. Secondly, a suspension signal is triggered, which carries a specific physical error code (such as indicating that the right front leg motor is overheating, CAN bus communication timeout, battery voltage drop, etc.) to identify the specific type and source of the abnormality. Then, according to the aforementioned asynchronous suspension and recovery protocol, the suspension signal is sent to the soft behavior tree of the main control chip, triggering the node freezing process of the main control chip: freezing the execution progress of the current node, pausing the timeout timer, and waiting for the control chip to complete the self-healing operation.

[0081] For ease of understanding, let's continue with the example of a quadruped robot performing a "walking forward" action. Assume this action relies on three hardware components: battery voltage, motor temperature, and communication link, all of which are normal. During the robot's forward movement, the control chip continuously monitors the hardware status at a frequency of 1kHz. At a certain moment, after refreshing the hardware status, the control chip detects that the temperature component of the right front leg motor has changed from normal to abnormal, and this temperature component happens to correspond to the target hardware status information upon which the "walking forward" action depends. At this point, the control chip immediately cuts off the drive current to the quadruped robot's joint motors, allowing the robot to stop smoothly instead of continuing to walk due to the abnormal command, which could burn out the motors. Simultaneously, the control chip triggers a suspension signal carrying a "right front leg motor overheating" error code and sends it to the main control chip's soft behavior tree. This causes the main control chip to freeze the current "walking forward" node and pause the timeout timer bound to that node. The control chip then independently controls the robot to perform self-healing operations such as squatting to dissipate heat. Once the motor temperature returns to normal, the control chip sends a recovery signal, and the robot stands up and continues walking forward. Throughout this process, the system does not need to restart the behavior tree or replan the task path. This implementation method ensures that safety protection extends beyond the access control stage before command issuance to the entire continuous process of command execution. Even if anomalies occur during execution, they can be captured and handled promptly, effectively guaranteeing the robot's operational safety in dynamic and uncertain environments.

[0082] In one implementation, the control of the underlying hardware to perform a self-healing operation includes: during the freeze period, the control chip acquires control of the underlying hardware; according to a locally fixed security protection strategy, it independently controls the underlying hardware to perform physical protection or self-healing operations, the execution of the self-healing operation not depending on the computing power of the main control chip; the self-healing operation includes controlling the robot to perform a low-power crouching heat dissipation posture, and / or performing reconstruction and reset of the internal physical bus network.

[0083] In practical implementation, after the control chip sends a suspend signal to the main control chip and the main control chip's soft behavior tree enters a frozen state (i.e., the current node behavior pointer is locked and the timeout timer is paused), the control chip automatically acquires full control over the underlying hardware during this period. This means that the drive instructions for the underlying hardware (such as motor drivers, sensors, cooling fans, bus interfaces, etc.) are issued entirely independently by the control chip during this period. The main control chip does not participate in any underlying control decisions, and its computing power is idle or continues to run other non-real-time services (such as perception large model inference). The control chip drives the self-healing process of the underlying hardware according to a locally embedded security protection strategy. This security protection strategy is pre-programmed or embedded in the control chip's storage medium (e.g., firmware or read-only memory), independent of the main control chip's business layer code, and does not rely on any algorithm or decision input provided by the main control chip. The entire self-healing operation is executed without relying on the computing power of the main control chip. Even if the main control chip experiences lag, deadlock, or even complete shutdown due to high load tasks, the control chip can still independently and reliably complete the self-healing control, thereby achieving absolute physical isolation between security logic and business logic.

[0084] For example, the control chip can trigger corresponding self-healing operations for different anomaly types. When the anomaly is motor overheating (e.g., the joint motor temperature rises above the safety threshold due to prolonged heavy-load walking in a quadruped robot), the control chip, according to its local safety policy, controls the robot to execute a low-power squatting posture for heat dissipation. For instance, the control chip sends drive commands corresponding to the squatting action to each joint motor, causing the robot to switch from a walking posture to a low-power squatting posture, while simultaneously activating the forced cooling fan on the robot body to accelerate air convection and reduce the joint motor temperature. Throughout the entire heat dissipation process, the main control chip's business layer does not need to sense temperature changes, nor does it need to intervene in any fan control or posture adjustment logic; the entire process is completed independently in a closed loop by the control chip. When the anomaly is an occasional communication drop or link interruption in the internal physical bus network (such as CAN bus, EtherCAT bus, etc.), the control chip performs reconstruction and reset operations of the internal physical bus network according to its local safety policy: specifically, the control chip sends reset commands to each node of the bus in sequence, re-enumerates the bus devices, rebuilds the communication link, and re-establishes the data transmission and reception channel after confirming that the link has stabilized. This process also does not require the intervention of the main control chip.

[0085] Throughout the entire freeze and self-healing process, the soft behavior tree nodes of the main control chip remain frozen. Node behavior pointers are statically fixed, and timeout timers are paused. They neither actively poll for underlying anomalies nor participate in any decision-making until the control chip completes self-healing and sends a recovery signal before thawing and continuing. This operational mode, where the control chip fully takes over the underlying layer and the main control chip is completely isolated during the freeze period, ensures both the efficiency and reliability of the self-healing process and achieves complete decoupling of physical and business boundaries at the architectural level.

[0086] Based on the control chip-side robot task orchestration method provided in the above-described embodiments, firstly, the control chip independently performs access verification on each command token issued by the main control chip. Only if the verification passes is the command allowed to be issued to the underlying hardware for execution; otherwise, it is immediately blocked. This mechanism completely shields the underlying hardware physical state from the business layer, allowing the business layer to issue commands without needing to understand hardware details, thus lowering the development threshold. Simultaneously, because the control chip operates independently, even if the main control chip experiences a glitch or lockup, the control chip can still independently complete the verification and blocking, safeguarding the overall physical security. Furthermore, through the independent main control chip and control chip layered architecture, business logic and security logic run independently on different chips. Adding or deleting business functions does not affect the security logic code, and expanding security functions does not affect the orchestration logic of the business layer. Both evolve independently, completely eliminating the system bloat and expansion difficulties caused by exhaustive combination jumps under hybrid orchestration. Furthermore, when the verification fails, the control chip sends a suspension signal to the main control chip, and sends a recovery signal after self-healing is completed. This allows the main control chip's soft behavior tree to be frozen in place during the abnormal period and seamlessly resumed after recovery without resetting the behavior tree or re-initializing it. This achieves in-situ suspension and seamless recovery of tasks, greatly improving task continuity in industrial scenarios.

[0087] In some embodiments, the soft behavior tree can store shared blackboard variables among nodes via a blackboard, the blackboard variables including a frozen flag. The main control chip can, in response to a suspend signal, rewrite the frozen flag in the blackboard to a frozen value. The conditional branch nodes of the soft behavior tree, based on the frozen value of the frozen flag, jump the execution flow from the main task branch to a preset virtual stub node. The virtual stub node executes a conditional branch loop on the soft behavior tree, causing the soft behavior tree to reside at the virtual stub node, and the currently activated node does not return an execution result to its parent node. Furthermore, the main control chip can, in response to a restore signal, reset the frozen flag in the blackboard. The conditional branch node, based on the reset frozen flag, controls the soft behavior tree to exit the conditional branch loop and jump back to the main task branch, resuming execution from the point where it was frozen. The rewriting and resetting of the frozen flag does not modify the node structure of the soft behavior tree.

[0088] In some embodiments, a field-programmable gate array (FPGA) can be configured on the instruction path between the control chip and the underlying hardware. The FPGA can preset the hardware admission condition table and collect the hardware status information. When the admission verification fails, the command token is intercepted. Alternatively, this can be done by forging a hardware status data packet: the FPGA intercepts the underlying control instruction corresponding to the command token at the hardware level to prevent the underlying control instruction from reaching the underlying hardware; a forged hardware status data packet is sent back to the control chip, indicating that the atomic action has been executed normally, so that the soft behavior tree maintains that the behavior pointer of the currently activated node does not enter an abnormal branch; when the admission verification passes, the FPGA transparently transmits the underlying control instruction corresponding to the command token to the underlying hardware.

[0089] Optionally, during the hardware-level interception of the underlying control commands, the field-programmable gate array independently drives the underlying hardware to perform preset physical protection actions; the message format of the forged hardware status data packet is consistent with the message format of the status data packet normally reported by the underlying hardware; when the hardware status information is restored and the admission verification passes, the field-programmable gate array stops sending back the forged hardware status data packet and restores the transparent transmission of the underlying control commands.

[0090] In other embodiments, the atomic action is subjected to admission verification based on the target hardware state information and the currently maintained hardware state information. Alternatively, a calculated risk cost value can be used instead of the aforementioned Boolean-type admission verification result. Specifically, a continuous risk cost value can be calculated based on the target hardware state information and the currently maintained hardware state information to replace the Boolean-type admission verification result. The continuous risk cost value represents the degree of hardware risk in executing the atomic action. When the continuous risk cost value does not exceed a preset cost threshold, the admission verification is deemed to have passed; when the continuous risk cost value exceeds the preset cost threshold, the admission verification is deemed to have failed.

[0091] For example, the values ​​of each hardware state component in the currently maintained hardware state information can be normalized to the range of [0, 1], and then a weighted sum or weighted average can be performed according to the target hardware state components on which the atomic action depends to obtain the continuous risk cost value.

[0092] Optionally, after the command token is intercepted because the continuous risk cost exceeds the preset cost threshold, the control chip can generate an alternative atomic action that bypasses the high-risk hardware state component based on hierarchical task network planning; and issue the alternative command token corresponding to the alternative atomic action for execution to replace the passive freeze triggered by the suspend signal.

[0093] like Figure 3 As shown, another embodiment of this disclosure provides a robot task orchestration method applied to a main control chip, including: S301: Generate a command token based on the currently activated node of the soft behavior tree and send the command token to the control chip; the command token indicates the atomic action to be executed.

[0094] Here, a soft behavior tree runs on the main control chip. This soft behavior tree is orchestrated by algorithm developers or users based on specific business scenarios, using top-level logic to organize a series of multi-stage task flows for user applications. During execution, the soft behavior tree traverses each node according to its preset polling strategy. When a leaf node is activated (i.e., the node gains execution rights), the node generates a corresponding command token based on its bound business logic. This command token is an abstract description of an atomic action, representing the smallest business operation unit. The command token carries at least type information to identify the specific atomic action, so that the receiver can recognize the business intent corresponding to the token. After generating the command token, the main control chip sends it to the control chip via the cross-chip communication bus between the main control chip and the control chip (e.g., physical links such as PCIe, Ethernet, serial bus, etc., and their upper-layer communication protocols). The control chip then performs subsequent security verification and execution control on the command token.

[0095] S302: In response to the suspension signal sent by the control chip when the admission verification of the atomic action fails, the execution progress of the currently activated node is frozen.

[0096] In practice, after the main control chip sends the command token to the control chip, the control chip performs an admission check on the atomic action indicated by the token. This check verifies whether the current hardware physical state of the device meets the conditions for safely executing the action. If the admission check fails, it indicates that some hardware state of the device is abnormal (e.g., motor overheating, battery low voltage, communication interruption, etc.), and the safety prerequisite for executing the atomic action is not met. Therefore, the command token is intercepted and will not be sent to the underlying hardware. Simultaneously, the control chip sends a suspend signal to the main control chip via the cross-chip communication bus to notify the main control chip of a hardware security issue requiring a pause in service execution. Upon receiving this suspend signal, the main control chip's soft behavior tree engine immediately performs a context freeze operation on the currently executing node, freezing the execution progress of the currently active node. Specifically, freezing execution progress includes, but is not limited to: locking the behavior pointer of the current node, keeping it pointing to the current node without shifting (neither returning to the parent node nor jumping to child or sibling nodes); and pausing all business layer timeout timers bound to this node to prevent false timeouts at the software level while waiting for underlying self-healing. During this process, the currently active node does not return any state from the traditional behavior tree to its parent node. For example, it does not return Running (because the node is not still running normally), Success (because the task has not completed successfully), or Failure (because the task has not completely failed but is waiting for recovery), but instead enters a special frozen suspension intermediate state. Throughout the entire freeze, the node retains its entire execution context unchanged, including the currently completed portion of progress, intermediate variables, timer states, etc., preserving complete state information for subsequent in-place recovery.

[0097] S303: In response to the recovery signal sent by the control chip, the execution progress is unfrozen, allowing the currently activated node to continue execution from where it was when it was frozen.

[0098] In this embodiment, after the control chip sends a suspend signal and the behavior tree node of the main control chip enters a frozen state, the control chip independently controls the underlying hardware to perform self-healing operations during this period (e.g., controlling the robot to perform a low-power crouching posture for heat dissipation, or performing reconstruction and reset of the internal physical bus network, etc.). The control chip continuously monitors the hardware status, and after the self-healing operation is completed and the hardware status returns to normal, the control chip sends a recovery signal to the main control chip through the cross-chip communication bus. After receiving the recovery signal, the soft behavior tree engine of the main control chip releases the frozen state of the currently activated node, that is, unfreezes the previously frozen execution progress. Specifically, the unfreezing operation includes: restoring the node's original behavior pointer, so that the pointer points back to the node position when it was frozen; restoring the previously paused timeout timer, so that it resumes counting from the paused time; and restoring all context information required by the node during execution. After unfreezing is completed, the current node continues execution from the execution progress when it was frozen, as if the anomaly had never occurred. It does not need to traverse the entire behavior tree again from the root node, nor does it need to re-execute the already completed parts of the work. Therefore, the robot is able to continue executing business from the physical location and task state that was forcibly suspended after an occasional hardware failure and self-healing, achieving seamless task continuation and greatly improving the continuity and success rate of task execution.

[0099] In one implementation, the soft behavior tree is deployed in the business application layer of the main control chip; the soft behavior tree does not rely on the code of the control chip when modifying business functions; the main control chip runs a non-real-time operating system, and the control chip runs a real-time operating system; the main control chip and the control chip are independent physical chips; the suspend signal and the resume signal are transmitted directly between the main control chip and the control chip, without passing through the algorithm layer.

[0100] In practical implementation, the soft behavior tree is deployed at the business application layer of the main control chip (i.e., the fifth layer of the system architecture). This layer is the top layer facing user business scenarios and is responsible for organizing and managing the execution logic of multi-stage task flows. Since the soft behavior tree carries pure business logic, its code does not require any modification or recompilation of the control chip's code when modifying or extending business functions (e.g., adding a new task node to perform infrared temperature measurement at point C). The security logic (hard-function state machine, hardware admission condition table, self-healing strategy, etc.) run by the control chip and the business logic of the main control chip are maintained and version-managed separately by independent code libraries. Business engineers and security engineers can develop and iterate in parallel without interfering with each other. The main control chip runs a non-real-time operating system (e.g., Linux Ubuntu). This type of operating system prioritizes task throughput and computational efficiency and is suitable for running computationally intensive tasks such as high-load perception large models and path planning algorithms. The control chip runs a real-time operating system. This type of operating system prioritizes deterministic response latency and can ensure that the security logic responds with deterministic latency of microseconds to milliseconds when hardware anomalies occur. Both are implemented using independent physical chips (e.g., the main control chip is the S100, and the control chip is the RK3588), each with its own independent processor core, memory resources, and peripheral interfaces. If one chip experiences a freeze, deadlock, or even complete crash due to extreme conditions, the other chip remains unaffected and can continue operating independently. Suspension and recovery signals are transmitted directly between the main control chip and the control chip, without passing through any algorithm layer modules (e.g., visual perception module, path planning module, SLAM positioning module, etc.) in the communication path. This means that the operating status of the algorithm layer (whether busy, frozen, or crashed) will not interfere with the transmission and processing of suspension / recovery signals. The core value of this architecture design is that even if the main control chip experiences occasional freezes or process locks due to running high-load tasks, the control chip can still independently complete command verification and instruction interception in milliseconds. Suspension and recovery signals can still reliably reach the soft behavior tree engine through the main control chip's communication interface, safeguarding the overall system's security.

[0101] In one implementation, in response to a suspension signal sent by the control chip when the admission verification of the atomic action fails, freezing the execution progress of the currently activated node in the soft behavior tree includes: the main control chip responding to the suspension signal by controlling the currently activated node not to return the execution result to the parent node; locking the behavior pointer of the currently activated node and keeping the behavior pointer statically fixed; and pausing the timeout timer bound to the currently activated node.

[0102] In practical implementation, when the main control chip receives the suspend signal sent by the control chip, the soft behavior tree engine performs the following three operations to achieve complete freezing of the current node. The first operation is: controlling the currently activated node not to return any execution result to its parent node. In traditional behavior trees, after execution, a node must return one of three states to its parent node: Running, Success, or Failure, so that the parent node can decide on the next action. However, in the frozen state of this implementation, the node does not return any of the above states, such as not returning Running (otherwise the parent node will think the node is still running normally and continue to wait, unable to enter the freezing process), not returning Success (otherwise the parent node will mistakenly think the task is completed and switch to the next node), and not returning Failure (otherwise the parent node will trigger the error handling process, resetting or interrupting the current task). The node enters a special state of silent freezing, and the parent node cannot perceive any state changes of the child node, thus freezing the entire behavior tree at the current node. The second operation is: locking the behavior pointer of the currently activated node and keeping the pointer statically fixed. The behavior pointer is an internal index used by the behavior tree engine to record which node is currently being executed. Locking this pointer means that the engine will not move the pointer to the parent node, child node, or sibling node, and the pointer position will remain unchanged even if the engine continues to perform Tick operations (periodic or polling-triggered). The third operation is to pause all business layer timeout timers bound to the currently active node. In actual business scenarios, many nodes have timeout limits (e.g., an error is reported if navigation times out by 5 minutes). If the timer continues to count down during the freeze period, it is very likely to trigger a false timeout before the underlying self-healing is completed, causing the system to incorrectly determine that the task has failed. Pausing the timer ensures that the freeze duration is not affected by business timeout limits, and the business layer will not be incorrectly interrupted due to timeout, regardless of whether the underlying self-healing takes several seconds or tens of seconds.

[0103] In one implementation, in response to a recovery signal sent by the control chip, unfreezing the execution progress and enabling the currently activated node to continue execution from the point where the execution progress was frozen includes: in response to the recovery signal, unfreezing the behavior pointer and restoring the timeout timer; and resuming execution from the point where the currently activated node was frozen.

[0104] Here, when the main control chip receives the recovery signal from the control chip, the soft behavior tree engine performs an unfreezing operation. Unfreezing is the reverse process of the aforementioned freezing operation. First, the previously locked behavior pointer is unfrozen, restoring it to point to the currently active node, allowing the engine's Tick operation to function normally on that node. Simultaneously, the previously paused timeout timer is resumed, allowing it to continue counting down from the remaining time at the pause point, rather than restarting from zero. This ensures that the business layer's constraint on the total task execution time remains consistent before and after freezing, preventing unreasonable additional time grace due to underlying self-healing. After completing these operations, the currently active node resumes execution from where it was frozen. Resuming execution from where it was frozen means that the node does not restart from the beginning, but continues execution from the step already completed at the time of suspension. For example, suppose a "navigate to point B" node is frozen due to motor overheating at 80% completion; after unfreezing, the node will continue the remaining 20% ​​of the navigation task from 80% completion, rather than restarting from 0%. This continuation execution mechanism enables the robot to seamlessly recover on the spot after hardware malfunctions and self-healing, without the need to reinitialize or reset the behavior tree, thus achieving maximum task continuity.

[0105] In another implementation, the soft behavior tree can store a freeze flag on a blackboard, and the main control chip can control the execution flow redirection of the soft behavior tree by rewriting the freeze flag, so as to realize the freezing and unfreezing of the currently activated node.

[0106] In this method, the main control chip freezes the execution progress of the currently activated node, which may include: in response to the suspension signal, rewriting the frozen flag stored in the blackboard of the soft behavior tree to a frozen value; the conditional branch node of the soft behavior tree, in response to the frozen value of the frozen flag, jumps the execution flow from the main task branch to a preset virtual stub node; the virtual stub node performs a conditional branch loop on the soft behavior tree, so that the soft behavior tree resides at the virtual stub node, and the currently activated node does not return the execution result to the parent node; The main control chip unfreezes the execution progress, which may include: the main control chip resetting the frozen flag in the blackboard in response to the recovery signal; the conditional branch node controlling the soft behavior tree to exit the conditional branch loop and jump back to the main task branch in response to the reset frozen flag, and continuing execution from the point where the execution progress was frozen; wherein, the rewriting and resetting of the frozen flag does not modify the node structure of the soft behavior tree.

[0107] In one implementation, generating a command token based on the currently activated node of a soft behavior tree includes: activating leaf nodes in a polling manner, determining the activated leaf nodes as the currently activated nodes; and generating an atomic command token for a multi-stage task flow from the currently activated nodes as the command token, wherein the multi-stage task flow includes at least one of going to a target point, activating a vision camera, performing grid-based inspection and photography, and returning to a charging pile.

[0108] Here, during execution, the soft behavior tree's engine performs periodic tick operations on the entire tree structure at a preset frequency or event-triggered method. Each tick traverses and performs conditional checks according to the control flow defined by the behavior tree (including sequential nodes, selection nodes, parallel nodes, conditional nodes, etc.), ultimately determining the leaf node that should be activated. A leaf node is the node in the behavior tree that actually executes a specific business action and does not contain any child nodes. When a leaf node is selected by the engine's tick process and gains execution rights, it is determined as the currently activated node. This node generates an atomic command token based on its internally bound business logic. The atomic command token refers to the action corresponding to the token being considered the smallest indivisible execution unit at the business orchestration level. For example, "go to the target point" is a complete navigation action, "activate the vision camera" is a device control action, "perform grid-based inspection and photography" is a sequential perception and recording action, and "return to the charging pile" is a return navigation action, etc. Soft behavior trees enable flexible orchestration of complex robotic business scenarios by combining these atomic action nodes into multi-stage task flows according to logic such as sequence, condition, and loop. Typical components of these multi-stage task flows may include, but are not limited to, complete user-facing business processes such as heading to a target point, activating the vision camera, performing grid-based inspection and photography, and returning to the charging station. Each atomic action node generates a command token upon activation, carrying unique identification information about the action type. The control chip uses this token to query the corresponding hardware dependencies and perform admission checks.

[0109] In one implementation, the suspend signal carries a physical error code; the method further includes: the main control chip records the reason why the currently activated node is frozen according to the physical error code, and stops issuing new command tokens to the control chip until the recovery signal is received.

[0110] Here, the suspend signal sent by the control chip carries a specific physical error code. This error code identifies the specific abnormality type and source that triggered the suspend. For example, error code 0x01 indicates that the battery voltage is below the safety threshold, error code 0x02 indicates that the left front leg motor is overheating, and error code 0x03 indicates that the CAN bus communication timed out. After receiving the suspend signal, the main control chip's soft behavior tree engine freezes the current node and records the reason for freezing the current node based on the physical error code carried in the suspend signal. For example, the error code is written to the system log or the behavior tree context for subsequent diagnosis and analysis. In addition, from receiving the suspend signal to receiving the recovery signal, the main control chip stops issuing any new command tokens to the control chip. The necessity of this behavior is that while the underlying hardware is in an abnormal state and has not yet recovered, even if the main control chip continues to issue command tokens for other atomic actions, these tokens will inevitably be intercepted and rejected during the control chip's access verification phase. Rather than repeatedly issuing rejected invalid instructions and occupying cross-chip communication resources, it is better to pause issuing and wait for the recovery signal before continuing. This mechanism not only reduces unnecessary communication overhead but also avoids a large number of invalid sending and rejection round trips on the main control chip side, making the system's operation during abnormal periods simpler and more controllable. After the control chip completes self-healing and sends a recovery signal, the main control chip resumes the normal process of sending command tokens to the control chip.

[0111] In one embodiment, the control chip runs a simplified behavior tree, which includes a shadow mirror node corresponding to the currently activated node; the shadow mirror node is used to align the execution state with the currently activated node; the suspend signal and the resume signal are transmitted by the control chip to the currently activated node through the shadow mirror node.

[0112] In this implementation, the control chip operates a simplified behavior tree (Slave BT), which contains shadow mirror nodes corresponding to the currently active nodes in the main control chip's soft behavior tree. The shadow mirror nodes correspond one-to-one with the main control chip's business execution nodes in terms of ID and structure, but their internal pointers are directly linked to the physical hardware state directly connected to the control chip, rather than executing business logic. The shadow mirror nodes are used to align the execution state with the corresponding currently active node in the main control chip. When the main control chip's behavior tree tick activates a business node, it synchronously sends a tick signal to the corresponding shadow mirror node of the control chip via the cross-chip bus. The shadow mirror node performs an evaluation locally: if the hardware state is safe, it maintains the Running state; if the hardware state is abnormal, it triggers a suspension process. Suspension and resumption signals are transmitted by the control chip to the corresponding currently active node in the main control chip through this shadow mirror node. In other words, the shadow mirror node acts as a proxy for the main control chip node on the control chip side, undertaking the dual roles of hardware state awareness and relaying suspension / resumption commands. This solution unifies the software development paradigm for dual-chip solutions, with both ends using behavior tree models. This eliminates the alignment overhead of data structure conversion between behavior trees and state machines in traditional solutions, making it more engineering-friendly for development teams with high native support for behavior trees. Engineers do not need to maintain two different programming models and debugging toolchains for behavior trees and state machines at the same time.

[0113] The robot task orchestration method on the main control chip side provided in this disclosure firstly allows the main control chip to generate and issue command tokens based on the soft behavior tree. Whether atomic actions can be executed is independently verified by the control chip, eliminating the need for the business layer to be aware of any underlying hardware physical state details. This significantly reduces the learning cost and error probability for business developers, allowing them to focus on the orchestration and optimization of the business logic itself. Secondly, upon receiving a suspension signal, the main control chip only freezes the execution context of the current node: locking the behavior pointer, pausing the timeout timer, and not returning any state, without executing any underlying exception handling logic. Upon recovery, it simply unfreezes and resumes in place. This passive response mode of the business layer completely decouples business logic from security logic at the code level. There are no conditional branches or exception handling code related to hardware protection in the business code, significantly improving code clarity, maintainability, and testability. Furthermore, from the perspective of the main control chip, throughout the entire process of a low-level hardware exception from occurrence to recovery, the behavior tree neither needs to revert to the root node for re-execution nor loses completed progress. This mechanism gives the business layer a high degree of immunity to occasional disturbances at the lower level, enabling the robot to maintain a high level of task execution continuity and success rate when facing frequent transient anomalies in industrial scenarios.

[0114] like Figure 4As shown in the illustration, this disclosure also provides a robot task orchestration system 400, comprising: The main control chip 41 is used to generate a command token based on the soft behavior tree and send the command token to the control chip; the command token indicates the atomic action to be executed; in response to the control chip sending a suspension signal when the admission verification of the atomic action fails, the execution progress of the currently activated node in the soft behavior tree is frozen; and in response to the recovery signal sent by the control chip, the execution progress is unfrozen, so that the currently activated node continues to execute from the execution progress when it was frozen.

[0115] The control chip 42 is configured to query the hardware admission condition table according to the atomic action indicated by the command token to determine the hardware state required to execute the atomic action; perform admission verification on the atomic action according to the determined required hardware state and the maintained hardware state vector; if the admission verification fails, intercept the command token to prevent the hardware from executing the atomic action, and send a suspension signal to the main control chip; the suspension signal is used to freeze the execution progress of the currently activated node in the soft behavior tree of the main control chip; and during the freeze, control the underlying hardware to perform a self-healing operation; and after the self-healing operation is completed, send a recovery signal to the main control chip.

[0116] like Figure 5 The diagram shown is an interaction diagram corresponding to the robot task orchestration system described above. Its interaction flow includes: S51: The main control chip sends a command token to the control chip.

[0117] S52: The control chip queries the hardware admission condition table and the maintained hardware state vector to perform admission verification on the atomic actions indicated by the command token.

[0118] S53: When the verification fails, the control chip initiates a suspend signal and controls the underlying hardware to perform a self-healing operation.

[0119] S54: The main control chip responds to the suspend signal and freezes the execution progress of the currently activated node.

[0120] S55: After the self-healing operation is completed, the control chip sends a recovery signal to the main control chip.

[0121] S56: The main control chip responds to the recovery signal sent by the control chip and unfreezes the execution progress.

[0122] S57: When the access verification is successful, the control chip sends the command token to the underlying hardware driver layer for execution.

[0123] like Figure 6The diagram shown illustrates the physical and logical mapping of the dual-chip architecture provided in this embodiment. This architecture employs a dual-chip deployment method, separating the main control chip at the brain end and the control chip at the cerebellum end, with the two interacting via a cross-chip communication bus.

[0124] The main control chip, also known as the brain (high-computing-power business unit), runs a non-real-time operating system (such as Ubuntu + ROS2), on which a Soft Behavior Tree (SBT) and a TokenGenerator are deployed. The SBT, as the top-level business orchestration engine, polls and activates leaf nodes according to a preset strategy. The activated nodes generate corresponding command tokens based on their bound business logic and send them asynchronously to the cerebellum via the cross-chip communication bus.

[0125] The control chip, also known as the cerebellum (security control terminal), runs a real-time operating system. On top of this, a Hard Functional State Machine (HFSM), a hardware admission condition table (hardware admission check matrix), and a chassis execution layer / hardware abstraction layer (HAL) are deployed. The HFSM maintains and continuously refreshes the hardware state vector S at a high frequency (e.g., 1kHz). Each bit in this vector corresponds to the real-time value (normal / abnormal) of a hardware state component. The hardware admission check matrix is ​​a pre-defined M×N matrix table, where each row corresponds to an atomic action, each column corresponds to a hardware state component, and the matrix elements indicate whether the execution of the corresponding action strongly depends on the corresponding hardware state being normal.

[0126] Under normal operation, nodes in the brain-side soft behavior tree continuously submit action requests to the task token generator, which then generates command tokens and issues them to the cerebellum-side. Simultaneously, the cerebellum-side's hardware state machine continuously refreshes the current hardware state vector S to the hardware access verification matrix at a high-frequency cycle (e.g., 1kHz). When the brain-side issues a command token to the cerebellum-side, the cerebellum-side uses the hardware access verification matrix to perform access verification on the command token: if the verification passes, the cerebellum-side initiates the physical execution flow, converting the command token into a low-level driver instruction and issuing it to the chassis execution layer; if the verification fails, the cerebellum-side intercepts the instruction and triggers a suspension process, sending a suspension signal to the brain-side. After the cerebellum-side completes its low-level self-healing, it sends a recovery signal to the brain-side, allowing the brain-side behavior tree to resume execution from its previous progress. This process constitutes an event-driven closed loop of instruction issuance, matrix interception and suspension, asynchronous self-healing, and in-situ recovery.

[0127] To more intuitively understand the complete workflow of the above method in a real robot system, the following example illustrates the task of a quadruped robot performing "taking pictures and inspecting the coupling at point B" in a chemical plant.

[0128] During the normal task distribution phase: The soft behavior tree running on the main control chip (e.g., S100) polls the leaf node NavToGoal(Point_B) and generates a command token. And send it to the control chip (e.g., RK3588). At this time, the state vector maintained by the control chip's hardware-function state machine is (These represent that the current battery voltage, motor temperature, and bus communication are all normal). The control chip calculates this through access verification. Once the verification is successful, the control chip sends the command token to the underlying hardware driver layer, and the quadruped robot walks forward with a normal gait.

[0129] Physical Anomaly and Hardware / Software Interception Phase: During the journey, due to the uneven ground of the chemical plant, the robot's right front leg motor was subjected to an overload torque output for an extended period. The control chip's hardware state machine detected that the motor's physical temperature rise exceeded the safety threshold, and the hardware state vector was instantly updated. (Right now This indicates that the normal motor temperature state has failed, and the leg joint is overheating. In the middleware layer of the control chip, the row vector for navigation actions in the hardware admission condition table specifies that it is strongly dependent on motor temperature (i.e., ...). The control chip immediately re-executes the admission verification: The verification result was a failure. The control chip instantly and forcibly intercepted the navigation command, cutting off the drive current to the joint motor, causing the chassis to come to a smooth stop.

[0130] Asynchronous Freezing and In-situ Self-Healing Phase: The control chip bypasses the algorithm layer and asynchronously sends a suspension signal to the main control chip's soft behavior tree, carrying the physical error code "Motor_Overheat". The main control chip's soft behavior tree engine responds to this signal, immediately freezing the current NavToGoal node, stopping the behavior tree pointer on that node, and instantly pausing the preset 5-minute navigation timeout timer. During this period, the control chip's hard-function state machine independently controls the quadruped robot to perform a low-power crouching posture and activates a forced fan for cooling. The main control chip's business layer does not need to run any temperature management code, achieving absolute isolation at physical boundaries.

[0131] Seamless in-situ recovery phase: After 30 seconds, the control chip detected that the temperature of the right front leg motor had dropped below the safety threshold and updated the state vector s2=1. The control chip asynchronously sent a recovery signal to the main control chip. The main control chip's soft behavior tree engine responded and instantly unfroze, and the navigation timer resumed timing. The quadruped robot stood up in place, continued walking towards point B, and ultimately successfully completed the photo-taking task. No behavior tree reset or task reinitialization occurred throughout the entire process.

[0132] This disclosure also provides a robot task orchestration device, which can be deployed on a control chip, including: The acquisition module is used to acquire the command token of the main control chip; the command token is generated by the currently activated node in the soft behavior tree of the main control chip; The determination module is used to query the hardware admission condition table based on the atomic action indicated by the command token, and determine the target hardware status information required to execute the atomic action. The verification module is used to perform admission verification on the atomic action based on the target hardware status information and the currently maintained hardware status information. The interception module is used to intercept the command token and send a suspension signal to the main control chip when the admission verification fails; the suspension signal is used to freeze the execution progress of the currently activated node in the soft behavior tree of the main control chip; and, during the freeze, control the underlying hardware to perform a self-healing operation. The recovery module is used to send a recovery signal to the main control chip after the self-healing operation is completed. The recovery signal is used to instruct the currently activated node to continue execution from the execution progress when it was frozen.

[0133] Another embodiment of this disclosure also provides a robot task orchestration device, which can be deployed on a main control chip, including: A generation module is used to generate a command token based on the currently activated node of the soft behavior tree and send the command token to the control chip; the command token indicates the atomic action to be executed. The freeze module is used to freeze the execution progress of the currently activated node in response to a suspension signal sent by the control chip when the admission verification of the atomic action fails. The unfreeze module is used to unfreeze the execution progress in response to the recovery signal sent by the control chip, so that the currently activated node can continue execution from the execution progress when it was frozen.

[0134] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the robot task orchestration method as described in any of the above embodiments.

[0135] Computer-readable storage media can be any usable medium accessible to a computer or a data storage device such as a server or data center that integrates one or more usable media. Usable media can be magnetic media, such as hard disks, floppy disks, and magnetic tapes; optical media, such as DVD-ROM, DVD-RAM, DVD-RW, DVD+RW, CD-ROM, CD-R, CD-RW, MO (magneto-optical) storage media; and semiconductor storage media, such as flash memory, EEPROM, Dynamic Random Access Memory (DRAM), and Static Random Access Memory (SRAM).

[0136] The computer program can be written in various computer programming languages, including but not limited to C, C++, Python, and custom messages and services under the ROS framework. When the computer program is executed by the processor, it implements the various steps of the robot task orchestration method in the embodiments of this disclosure.

[0137] This disclosure also provides a computer program product, which stores a computer program. When the computer program is run by a processor, it executes the steps of the robot task orchestration method provided in any of the above embodiments of this disclosure. For details, please refer to the above method embodiments, which will not be repeated here.

[0138] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium, which can be a volatile or non-volatile computer-readable storage medium. In another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0139] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices and apparatuses described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0140] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0141] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0142] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0143] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure; and these modifications, changes, 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 disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A robot task orchestration method, characterized in that, Applications in control chips, including: Obtain the command token from the main control chip; the command token is generated by the currently active node in the soft behavior tree of the main control chip; Based on the atomic action indicated by the command token, query the hardware admission condition table to determine the target hardware state information required to execute the atomic action; Based on the target hardware status information and the currently maintained hardware status information, the atomic action is subject to admission verification. When the admission verification fails, the command token is intercepted and a suspension signal is sent to the main control chip; the suspension signal is used to freeze the execution progress of the currently activated node in the soft behavior tree of the main control chip; and during the freeze, the underlying hardware is controlled to perform a self-healing operation. After the self-healing operation is completed, a recovery signal is sent to the main control chip. The recovery signal is used to instruct the currently activated node to continue execution from the execution progress when it was frozen. The control chip and the main control chip are independent physical chips; the control chip runs a real-time operating system, while the main control chip runs a non-real-time operating system. The control chip runs a hardware state machine, which is used to maintain hardware state information and perform the admission verification. The hardware state machine communicates with the soft behavior tree using an asynchronous suspension and resumption protocol, which is independent of the state feedback mechanism natively defined by the soft behavior tree. The hardware state machine is deployed in the middleware layer of the control chip, and the middleware layer is located between the algorithm layer and the hardware driver layer of the control chip; the software behavior tree is deployed in the business application layer of the main control chip; the software behavior tree does not depend on the code of the control chip when modifying business functions; The hardware state machine is used to perform the admission verification and interception on the underlying control instructions after the algorithm layer generates the underlying control instructions based on the command token and before the underlying control instructions reach the hardware driver layer. The suspend signal and the resume signal are sent directly from the middleware layer of the control chip to the soft behavior tree of the main control chip, without going through the algorithm layer for logical processing or decision intervention.

2. The method according to claim 1, characterized in that, When the access verification fails, the command token is intercepted and a suspend signal is sent to the main control chip, including: When the admission verification fails, the hardware function state machine sends the suspension signal to the soft behavior tree based on the asynchronous suspension and recovery protocol to freeze the current node context pointer and timeout timer of the soft behavior tree. The step of sending a recovery signal to the main control chip after the self-healing operation is completed includes: After the self-healing operation is completed, the hardware function state machine sends the recovery signal to the soft behavior tree based on the asynchronous suspension and recovery protocol to restore the current node context pointer and timeout timer.

3. The method according to claim 1, characterized in that, The hardware admission condition table is an M-row, N-column matrix table. The M rows correspond to the M atomic actions that can be issued, and the N columns correspond to the N hardware state components of the maintained hardware state information. The matrix elements of the hardware admission condition table take either a first matrix value or a second matrix value. The first matrix value indicates that the execution of the corresponding atomic action strongly depends on the corresponding hardware state component being normal, and the second matrix value indicates that the execution of the corresponding atomic action does not depend on the corresponding hardware state component. The step of querying the hardware admission criteria table based on the atomic action indicated by the command token to determine the target hardware state information required to execute the atomic action includes: Extract the row with the same sequence number as the atomic action from the hardware admission condition table and use it as a row vector; wherein, the hardware state component corresponding to the component that takes the value of the first matrix in the row vector belongs to the target hardware state information.

4. The method according to claim 3, characterized in that, The step of performing admission verification on the atomic action based on the target hardware status information and the currently maintained hardware status information includes: The currently maintained hardware state information is represented as a hardware state vector, and both the hardware state vector and the row vector are N-dimensional vectors. For each component with the same index in the hardware state vector and the row vector, perform a logical OR operation between the component with that index in the hardware state vector and the inverse value of the component with that index in the row vector to obtain the item result with that index. Perform a logical AND operation on the results of all N items with the specified numbers to obtain the admission verification result; The admission check passes when all of the above items are true; the admission check fails when any of the above items are false.

5. The method according to claim 4, characterized in that, For each component with the same index in the hardware state vector and the row vector, a logical OR operation is performed, including: The component in the row vector that corresponds to the target hardware state information is recorded as the component to be processed; For each component to be computed, the value of the component with the same index as the component to be computed in the hardware state vector is logically ORed with the inverse value of the component to be computed to obtain the result of that component. Perform a logical AND operation on the results of all the components to be calculated to obtain the admission verification result.

6. The method according to claim 1, characterized in that, The method further includes: The hardware status information is continuously refreshed at a preset period. When any hardware state component of the hardware state information changes from normal to abnormal during the execution of the atomic action, and the hardware state component belongs to the target hardware state information on which the atomic action depends, the drive current sent to the underlying layer is cut off, and the suspend signal carrying the physical error code is triggered to be sent to the main control chip.

7. The method according to claim 1, characterized in that, The control underlying hardware performs a self-healing operation, including: During the freeze, the control chip gains control of the underlying hardware; according to the locally fixed security protection strategy, it independently controls the underlying hardware to perform physical protection or self-healing operations, and the execution of the self-healing operation does not depend on the computing power of the main control chip. The self-healing operation includes controlling the robot to perform a low-power crouching heat dissipation posture and / or performing reconstruction and reset of the internal physical bus network.

8. The method according to claim 1, characterized in that, The control chip runs a simplified behavior tree, which includes a shadow mirror node corresponding to the currently activated node; the shadow mirror node is used to align the execution state with the currently activated node. The suspend signal and the resume signal are transmitted by the control chip to the currently activated node through the shadow mirror node.

9. A robot task orchestration method, characterized in that, Applied to main control chips, including: The currently active node generates a command token based on the soft behavior tree and sends the command token to the control chip; the command token indicates the atomic action to be executed. In response to the suspension signal sent by the control chip when the admission verification of the atomic action fails, the execution progress of the currently activated node is frozen. In response to the recovery signal sent by the control chip, the execution progress is unfrozen, allowing the currently activated node to continue execution from where it was when it was frozen. The control chip and the main control chip are independent physical chips; the control chip runs a real-time operating system, while the main control chip runs a non-real-time operating system. The control chip runs a hardware state machine, which is used to maintain hardware state information and perform the admission verification. The hardware state machine communicates with the soft behavior tree using an asynchronous suspension and resumption protocol, which is independent of the state feedback mechanism natively defined by the soft behavior tree. The hardware state machine is deployed in the middleware layer of the control chip, and the middleware layer is located between the algorithm layer and the hardware driver layer of the control chip; the software behavior tree is deployed in the business application layer of the main control chip; the software behavior tree does not depend on the code of the control chip when modifying business functions; The suspend signal and the resume signal are sent directly from the middleware layer of the control chip to the soft behavior tree of the main control chip, without going through the algorithm layer for logical processing or decision intervention.

10. The method according to claim 9, characterized in that, In response to a suspension signal sent by the control chip when the admission check for the atomic action fails, the execution progress of the currently activated node in the soft behavior tree is frozen, including: In response to the suspend signal, the main control chip controls the currently activated node not to return the execution result to the parent node. Lock the behavior pointer of the currently activated node and keep the behavior pointer statically fixed; Pause the timeout timer bound to the currently active node.

11. The method according to claim 10, characterized in that, In response to the recovery signal sent by the control chip, the execution progress is unfrozen, allowing the currently activated node to continue execution from where it was when it was frozen, including: In response to the recovery signal, the behavior pointer is unfrozen and the timeout timer is resumed; Execution resumes from where the currently activated node was frozen.

12. The method according to claim 9, characterized in that, Freezing the execution progress of the currently activated node includes: In response to the suspension signal, the frozen flag stored in the blackboard of the soft behavior tree is rewritten to a frozen value; in response to the frozen value of the frozen flag, the conditional branch node of the soft behavior tree jumps the execution flow from the main task branch to a preset virtual stub node; the virtual stub node executes a conditional branch loop on the soft behavior tree so that the soft behavior tree resides at the virtual stub node, and the currently activated node does not return the execution result to the parent node; The unfreezing of the execution progress includes: In response to the recovery signal, the main control chip resets the frozen flag in the blackboard; in response to the reset frozen flag, the conditional branch node controls the soft behavior tree to exit the conditional branch loop and jump back to the main task branch to resume execution from the point where the execution progress was frozen. The rewriting and resetting of the frozen flag does not modify the node structure of the soft behavior tree.

13. The method according to claim 9, characterized in that, The currently active node generates a command token based on the soft behavior tree, including: Leaf nodes are activated in a round-robin manner, and the activated leaf nodes are determined as the currently activated nodes; An atomic command token is generated by the currently activated node for a multi-stage task flow, which includes at least one of the following: going to the target point, activating the vision camera, performing grid-based inspection and photography, and returning to the charging pile.

14. The method according to claim 9, characterized in that, The suspension signal carries a physical error code; the method further includes: The main control chip records the reason why the currently activated node is frozen according to the physical error code, and stops issuing new command tokens to the control chip until it receives the recovery signal.

15. A robot task orchestration system, characterized in that, include: The main control chip is used to generate command tokens based on a soft behavior tree and send the command tokens to the control chip. The command token indicates the atomic action to be performed; In response to the suspension signal sent by the control chip when the admission verification of the atomic action fails, the execution progress of the currently activated node in the soft behavior tree is frozen. In addition, in response to the recovery signal sent by the control chip, the execution progress is unfrozen, allowing the currently activated node to continue execution from where it was when it was frozen; The control chip is configured to query a hardware admission condition table based on the atomic action indicated by the command token to determine the hardware state required to execute the atomic action; perform admission verification on the atomic action based on the determined required hardware state and the maintained hardware state vector; if the admission verification fails, intercept the command token to prevent the hardware from executing the atomic action and send a suspension signal to the main control chip; the suspension signal is used to freeze the execution progress of the currently activated node in the soft behavior tree of the main control chip; and, during the freeze, control the underlying hardware to perform a self-healing operation; and after the self-healing operation is completed, send a recovery signal to the main control chip. The control chip and the main control chip are independent physical chips; the control chip runs a real-time operating system, while the main control chip runs a non-real-time operating system. The control chip runs a hardware state machine, which is used to maintain hardware state information and perform the admission verification. The hardware state machine communicates with the soft behavior tree using an asynchronous suspension and resumption protocol, which is independent of the state feedback mechanism natively defined by the soft behavior tree. The hardware-functional state machine is deployed in the middleware layer of the control chip, and the middleware layer is located between the algorithm layer and the hardware driver layer of the control chip. The soft behavior tree is deployed in the business application layer of the main control chip; the soft behavior tree does not depend on the code of the control chip when modifying business functions. The hardware state machine is used to perform the admission verification and interception on the underlying control instructions after the algorithm layer generates the underlying control instructions based on the command token and before the underlying control instructions reach the hardware driver layer. The suspend signal and the resume signal are sent directly from the middleware layer of the control chip to the soft behavior tree of the main control chip, without going through the algorithm layer for logical processing or decision intervention.

Images