Robot control method, device, robot, storage medium and program product

Abstract

The application discloses a robot control method and device, a robot, a storage medium and a program product, and belongs to the technical field of robots. The method comprises the following steps: in response to a first starting instruction, an executable file is run and a master process is generated; the master process differentially deploys resource data according to the data type of the resource data; the master process receives action arrangement data for a target execution unit, and generates an action control sequence based on the action arrangement data; the action control sequence is incrementally combined and written into a data field corresponding to the device model in a multi-model record file according to the device model of the target execution unit; in the case where an execution instruction for the action control sequence is received, the master process issues the action control sequence to a communication bridge sub-process; and a physical control frame is transmitted to the target execution unit based on the communication bridge sub-process to control the target execution unit to run, thereby improving the compatibility of multi-model heterogeneous execution units in a unified control scene.

Description

Technical Field

[0001] This application belongs to the field of robotics technology, and in particular relates to a robot control method, device, robot, storage medium, and program product. Background Technology

[0002] In recent years, heterogeneous robotic devices, exemplified by bionic dexterous hands, have undergone frequent iterations. Within the same product series, multiple mechanical structures (e.g., 6 to 25 degrees of freedom) and underlying communication protocols often exist. Related control schemes typically highly couple business logic with underlying bus access in the same process and often employ a multi-component discrete deployment model. This architecture makes cross-platform adaptation of control software difficult, easily leading to component version mismatches during field deployment, and making it difficult to guarantee stable concurrent control of multiple devices. Furthermore, in terms of motion data management, related technologies often use a whole-file overwrite mechanism for data storage; if motion data from multiple device models are recorded alternately within the same system, subsequent save operations will directly overwrite and delete the existing data from other models. The aforementioned system architecture and data storage mechanism make it difficult for related systems to adapt to industrial environments where heterogeneous devices coexist, reducing the efficiency of collaborative control of multiple devices. Summary of the Invention

[0003] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes a robot control method, device, robot, storage medium, and program product, which improves the compatibility of multiple heterogeneous execution units and the reuse rate of motion data.

[0004] In a first aspect, this application provides a robot control method. The robot includes at least one execution unit and is configured with an executable file. The executable file includes at least one type of resource data. The method includes: in response to a first start command, the executable file runs and generates a main control process; the main control process performs differentiated deployment of the resource data according to the data type of the resource data, so as to release the communication bridging dependency data in the resource data into a bridging executable file, and launches a communication bridging subprocess based on the bridging executable file; the main control process receives motion orchestration data for a target execution unit and generates a motion control sequence based on the motion orchestration data; according to the device model of the target execution unit, the incremental merging of the motion control sequence is written into the data field corresponding to the device model in a multi-model record file; upon receiving an execution command for the motion control sequence, the main control process converts the motion control sequence into a physical control frame and sends the physical control frame to the communication bridging subprocess; the communication bridging subprocess transmits the physical control frame to the target execution unit to control the operation of the target execution unit.

[0005] According to the robot control method of this application, a main control process is generated by running a single executable file, and communication bridge subprocesses are deployed and launched according to the different data types of resource data, simplifying the deployment dependencies of the control software. The main control process centrally converts the motion control sequence into physical control frames, and then transmits them physically through the communication bridge subprocesses, decoupling the upper-layer control logic from the lower-layer communication and shielding the differences in the underlying communication drivers. At the same time, according to the device model of the target execution unit, the incremental motion control sequence is merged and written into the corresponding data fields in the multi-model record file, avoiding data overwriting when recording across models and improving the compatibility of multi-model heterogeneous execution units in a unified control scenario.

[0006] According to one embodiment of this application, the main control process performs differentiated deployment of resource data based on the data type of the resource data, so as to release the communication bridging dependency data in the resource data into a bridging executable file, and launch a communication bridging subprocess based on the bridging executable file, including: when the resource data includes communication bridging dependency data, extracting and saving the communication bridging dependency data to a local path, and configuring executable permissions to generate a bridging executable file; the main control process starts the bridging executable file to launch the communication bridging subprocess.

[0007] According to one embodiment of this application, the main control process performs differentiated deployment of resource data based on the data type of the resource data, including: when the resource data includes configuration file data, loading the configuration file data into memory for the main control process to read initialization parameters; when the resource data includes default action library data and the target action library does not exist locally, unpacking the default action library data to generate the target action library locally; when the resource data includes front-end static resource data, mounting the front-end static resource data to the routing interface, and uniformly redirecting to the homepage file of the front-end static resource data when the route is not hit, so as to provide access services for the operation interface to the outside world through the main control process.

[0008] According to one embodiment of this application, based on the device model of the target execution unit, the incremental action control sequence is merged and written into the field corresponding to the device model in a multi-model record file, including: receiving a save instruction for the action control sequence; in response to the save instruction, obtaining the action control sequence and the target device model corresponding to the target execution unit; reading the multi-model record file corresponding to the action control sequence; the multi-model record file contains multiple parallel model data fields, each model data field corresponding to each execution unit; based on the target device model, the incremental action control sequence is merged and written into the target data field corresponding to the target device model in the multi-model record file, so as to keep the data in other model data fields in the multi-model record file unchanged.

[0009] According to one embodiment of this application, the communication bridging dependency data in the resource data is released into a bridging executable file, and a communication bridging subprocess is launched based on the bridging executable file, including: after the main control process is generated, detecting and obtaining the occupancy status of a preset local bridging port; if the local bridging port is occupied, refusing to launch the communication bridging subprocess and outputting a port conflict prompt; if the local bridging port is not occupied, releasing the communication bridging dependency data into a bridging executable file and launching the communication bridging subprocess.

[0010] According to one embodiment of this application, the main control process converts the action control sequence into physical control frames and sends the physical control frames to the communication bridge subprocess, including: in the main control process, obtaining the corresponding communication protocol configuration information and inter-frame interval time according to the device model of the target execution unit; the main control process extracts the logical control instructions in the action control sequence based on the communication protocol configuration information and assembles the logical control instructions into physical control frames; the main control process sends the physical control frames to the communication bridge subprocess through the inter-process communication channel based on the inter-frame interval time.

[0011] According to one embodiment of this application, transmitting physical control frames to a target execution unit based on a communication bridging subprocess to control the operation of the target execution unit includes: the communication bridging subprocess receiving the physical control frames; the communication bridging subprocess, based on a local communication interface, shielding the underlying driver differences of different communication hardware adapters, and sending the physical control frames to the corresponding target execution unit.

[0012] Secondly, this application provides a robot control device. The robot includes at least one execution unit and is configured with an executable file. The executable file includes at least one type of resource data. The device includes: a first processing module, configured to execute the executable file and generate a main control process in response to a first start command; a second processing module, configured to perform differentiated deployment of the resource data according to the data type of the resource data, so as to release the communication bridging dependency data in the resource data into a bridging executable file, and launch a communication bridging subprocess based on the bridging executable file; a third processing module, configured to receive motion orchestration data for a target execution unit and generate a motion control sequence based on the motion orchestration data; a fourth processing module, configured to incrementally merge the motion control sequence into the data field corresponding to the device model in a multi-model record file according to the device model of the target execution unit; a fifth processing module, configured to convert the motion control sequence into a physical control frame by the main control process upon receiving an execution command for the motion control sequence, and send the physical control frame to the communication bridging subprocess; and a sixth processing module, configured to transmit the physical control frame to the target execution unit based on the communication bridging subprocess to control the operation of the target execution unit.

[0013] According to the robot control device of this application, a main control process is generated by running a single executable file, and communication bridge subprocesses are deployed and launched according to the different data types of resource data, simplifying the deployment dependencies of the control software. The main control process centrally converts the motion control sequence into physical control frames, and then transmits them physically through the communication bridge subprocesses, decoupling the upper-layer control logic from the lower-layer communication and shielding the differences in the underlying communication drivers. At the same time, according to the device model of the target execution unit, the incremental motion control sequence is merged and written into the corresponding data fields in the multi-model record file, avoiding data overwriting when recording across models and improving the compatibility of multi-model heterogeneous execution units in a unified control scenario.

[0014] Thirdly, this application provides a robot, including: at least one execution unit; and a robot control device as described in the second aspect, the robot control device being electrically connected to the execution unit. Fourthly, this application provides a non-transitory computer-readable storage medium storing a computer program thereon, the computer program being executed by a processor to implement the robot control method as described in the first aspect above. Fifthly, this application provides a computer program product, including a computer program, the computer program being executed by a processor to implement the robot control method as described in the first aspect above.

[0015] The above-described one or more technical solutions in the embodiments of this application have at least one of the following technical effects: The main control process is generated by running a single executable file, and communication bridge subprocesses are deployed and launched differently according to the data type of resource data, which simplifies the deployment dependencies of the control software. The main control process centrally converts the action control sequence into physical control frames, and then transmits them physically through the communication bridge subprocesses, decoupling the upper-layer control logic from the lower-layer communication and shielding the differences in the underlying communication drivers. At the same time, according to the device model of the target execution unit, the incremental action control sequence is merged and written into the corresponding data fields in the multi-model record file, avoiding data overwriting when recording across models and improving the compatibility of multi-model heterogeneous execution units in a unified control scenario.

[0016] Furthermore, a three-layer decoupled system architecture consisting of a console, a local communication bridge, and a communication hardware adapter was constructed. A local port conflict detection mechanism ensured the unique running state of the bridge subprocess, effectively avoiding communication conflicts and system deadlocks caused by multiple processes competing for underlying bus resources. The local communication interface shielded the underlying driver differences of different hardware adapters, achieving complete decoupling between upper-layer business logic and underlying driver details. Differential ready-to-wait strategies for different operating systems improved the reliability of the bridge subprocess during the underlying interface initialization phase, thereby enhancing the operational reliability of the robot in complex operating environments and improving the compatibility of multiple heterogeneous execution units under unified control scenarios.

[0017] Furthermore, by organizing control frame arrays of multiple model variant keys in parallel, control frames for the same action on all models are aggregated into the same gesture file, thus solving the defects of full file overwriting and scattered storage by model, and realizing cross-model reuse of the gesture library. By adopting the incremental merging semantics of "reading disk - replacing only the model fields involved in this time - writing disk", it supports a progressive cross-model recording process of "recording on one model first, then supplementing recording on another model, and finally the two coexisting in the same file". This ensures that when supplementing recording on any model, the existing data of other models will not be discarded, thereby realizing the universality and reuse of action data among heterogeneous devices, effectively improving the cross-device reuse rate, and enhancing the system compatibility of multiple heterogeneous execution units in a unified control scenario.

[0018] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0019] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 This is one of the flowcharts illustrating the robot control method provided in the embodiments of this application; Figure 2 This is a second schematic flowchart of the robot control method provided in the embodiments of this application; Figure 3 This is the third flowchart illustrating the robot control method provided in the embodiments of this application; Figure 4 This is the fourth flowchart illustrating the robot control method provided in the embodiments of this application; Figure 5 This is the fifth flowchart illustrating the robot control method provided in the embodiments of this application; Figure 6 This is the sixth flowchart illustrating the robot control method provided in the embodiments of this application; Figure 7 This is the seventh flowchart illustrating the robot control method provided in the embodiments of this application; Figure 8 This is the eighth flowchart illustrating the robot control method provided in the embodiments of this application; Figure 9 This is a schematic diagram of the structure of the robot control device provided in the embodiments of this application; Figure 10 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0021] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0022] The robot control method, robot control device, robot, readable storage medium, and program product provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0023] The robot control method can be applied to the terminal, and can be executed by the hardware or software in the terminal.

[0024] The terminal includes, but is not limited to, portable communication devices such as mobile phones or tablets. It should also be understood that, in some embodiments, the terminal may not be a portable communication device, but rather a desktop computer.

[0025] This application provides a robot control method. The executing entity of the robot control method can be a robot or a functional module or functional entity in the robot that can implement the robot control method. The robot control method provided in this application is described below using a robot as the executing entity.

[0026] During the research and development process, the inventors discovered that bionic dexterous hands, as key components of humanoid robots, humanoid robot end effectors, and teleoperated teaching terminals, exhibit rapid model iteration and significant differences in mechanical structure. Within the same dexterous hand product series, multiple degrees of freedom configurations often coexist, along with different structural variations such as worm gear drives and ball joint drives. Each model typically has its own underlying fieldbus, frame command codes, frame lengths, byte definitions, and default values. This coexistence of multiple models places extremely high demands on the development, maintenance, and field deployment of the host computer control software. In practical industrial applications and robot teaching scenarios, customers and teaching engineers urgently require the ability to use a single host computer software to perform real-time joint teaching, batch gesture saving, and multi-gesture orchestration and playback for one or more actuators on any model, any hand (e.g., left or right hand), and any CAN interface. Simultaneously, they expect the deployment process to be free from strong dependence on pre-installed operating systems and underlying driver toolchains. However, control solutions in related technologies are typically developed independently for specific models, making it difficult to meet the aforementioned unified scheduling requirements across multiple models and platforms. Related technologies involve developing and pre-selecting control software for each device model, requiring users to pre-select the device model during software startup or in the interface. The software then issues joint commands according to a fixed frame format (such as specific command codes, frame lengths, and byte order) for that model. This approach necessitates the redevelopment and delivery of a separate installation package to the customer each time a new model is added or a variant of the device structure is changed. This results in low flexibility and accuracy in equipment scheduling in complex and changing field conditions or scenarios with frequent equipment changes. It also increases the risk of errors in low-level command parsing due to human error in selecting the wrong model, potentially adversely affecting the mechanical safety of the execution unit. Furthermore, gesture data is usually stored in separate directories for each model. Since each gesture only contains a binary frame specific to that model, the arrangement and playback of actions can only be effective between devices of the same model. This results in poor cross-model smooth migration and reuse capabilities of existing historical action libraries when hardware structure iterations or multi-model heterogeneous collaborative operations occur. Users usually need to spend a lot of time re-recording teaching actions. In addition, without a unified system-level timeline, the fine-grained timing collaborative control of heterogeneous devices with different response rhythms is often inadequate, which seriously affects the overall stability of multi-device concurrent operations.Through in-depth research, the inventors designed a machine control method. The method includes: acquiring an action control sequence of a target execution unit; the action control sequence includes multiple action control frames, each including logical control instructions representing action semantics; acquiring communication protocol configuration information and inter-frame interval time corresponding to the target execution unit; the communication protocol configuration information and inter-frame interval time are determined based on the device model of the target execution unit; based on the communication protocol configuration information, extracting the logical control instructions from the action control frames and assembling the logical control instructions into physical control frames; and based on the inter-frame interval time, sending the physical control frames to the target execution unit to drive the target execution unit to perform actions corresponding to the logical control instructions. According to the robot control method provided in this application, logical control instructions representing abstract action semantics are extracted and dynamically assembled into specific physical control frames in conjunction with communication protocol configuration information determined by the device model. Based on the introduced configuration-driven mechanism, the system can adapt to new device models without modifying the core business code, thereby reducing the system's expansion cost and enabling the reuse of the same set of action sequences across different execution unit models. Based on this, for the physical control frame distribution process, a scheduling method based on the inter-frame interval time determined by the target device model is introduced to match the instruction distribution frequency with the actual mechanical response speed of different structural execution units. Based on the above-mentioned dedicated timing scheduling, the system alleviates the control disconnection caused by inconsistent physical response speeds when multiple heterogeneous devices execute concurrently, thereby improving the overall coordination of multiple heterogeneous execution units under concurrent orchestration control. This application provides a robot. In some embodiments, the robot includes multiple execution units. In this embodiment, the execution unit is the physical component in the robot system that actually receives instructions and performs actions, such as various models of multi-degree-of-freedom bionic dexterous hands connected to the communication bus (e.g., dexterous hand devices with different configurations such as 6 degrees of freedom, 7 degrees of freedom, 10 degrees of freedom, and even 20 degrees of freedom and 25 degrees of freedom), specific models such as L10 type (including worm gear drive variant and ball joint drive variant), O7 type and O6 type, etc.; in addition, the execution unit can also be an independently controlled single finger component and drive joint on the above-mentioned dexterous hand device. The control scheme provided in this application is widely applicable to any robot application scenario involving "multiple heterogeneous devices sharing the same control system". Therefore, in a wider range of embodiments, the execution unit may also include, but is not limited to, multiple models of robotic arm end effectors, multiple models of bionic torsos, and multiple models of mobile chassis, as well as other heterogeneous physical components. In some embodiments, the execution unit corresponds one-to-one with the communication protocol, and at least two execution units correspond to different communication protocols. In actual execution, within the same robot (e.g., a bionic dexterous hand) product series, different degree-of-freedom configurations often coexist, as do different structural variations such as worm gear drives and ball joint drives.Due to differences in the underlying mechanical structure, each type of execution unit often has its own proprietary communication protocol, corresponding to different command codes, frame lengths, and specific physical frame definitions such as load offset bits. In some embodiments, the English abbreviations and their corresponding Chinese definitions in this application are shown in Table 1.

[0027]

[0028] like Figure 1 As shown, the robot control method includes steps 110, 120, 130 and 140.

[0029] Step 110: Obtain the motion control sequence of the target execution unit. In this step, the target execution unit refers to the physical hardware carrier that is actually connected to the robot communication bus and is currently to be controlled. This could be, for example, various models of bionic dexterous hands with different degrees of freedom (such as L10, O7, or O6 models covering 6 to 25 degrees of freedom, and including structural variations such as worm gear drives or ball joint drives), or independently controlled single-finger components and drive joints. In some embodiments, the target execution unit can be uniquely addressed and locked at the system level by parsing the device model and communication identifier (e.g., Controller Area Network (CAN) identifier). For example, in a specific implementation scenario, CAN identifier 0x27 can be set to represent the right-hand device, and CAN identifier 0x28 can be set to represent the left-hand device. The motion control sequence refers to the continuous combination of actions to be performed by the target execution unit over a period of time. In terms of actual data structure, the motion control sequence is essentially a sequence of motion data composed of a set of gestures with frame numbers combined in a time sequence. In this context, a gesture refers to the fixed positional state of each joint of the target execution unit at a specific point in time (its actual movement is such as a bionic dexterous hand making a fist or gesturing the numbers 1 to 9 in a frozen position). At the data processing and storage level, a gesture is specifically represented as a set of multiple physical control frames (such as CAN data frames, RS485 communication frames, EtherCAT messages, or Modbus data frames, etc., representing underlying industrial communication messages) corresponding to a single static posture. These frames are uniformly stored as structured data formats such as JSON files, binary JSON (BSON), MessagePack, Protocol Buffers, or SQLite single-file databases. In some embodiments, the specific application scenarios of the motion control sequence may include, but are not limited to: robot dance and choreography, task pipelines in industrial manufacturing scenarios, and pre-recorded action macros.

[0030] In some embodiments, the motion control sequence includes multiple motion control frames. In this embodiment, the motion control frame is a data frame containing the gesture to be performed by the target execution unit. In some embodiments, the motion control frame includes a frame number for indicating the execution order of the motion control frames, and a data payload encapsulating the positional state of each joint of the target execution unit. During actual execution, multiple motion control frames are arranged sequentially according to a preset temporal order to jointly constitute the motion control sequence. In some embodiments, the motion control frame includes logical control instructions for characterizing the semantics of the motion. In this embodiment, the logical control instructions are essentially standardized motion identifiers encapsulated within the motion control frame for characterizing the motion features of each joint; for example, the logical control instructions may include control variables representing specific joint motions or global parameters, such as thumb, thumb_swing, global_speed, thumb_roll, thumb_yaw, thumb_root1, or thumb_tip. By coordinating multiple logical control instructions within a single motion control frame, the target execution unit is driven to form the expected overall pose state at the current frame time. By coordinating multiple logical control instructions within a single action control frame, the target execution unit is driven to form the expected overall pose state at the current frame time. In some embodiments, the logical control instructions can be independent of the underlying communication protocol and hardware physical structure of the target execution unit. Therefore, the same set of logical control instructions can serve as a universal baseline control item, enabling the same logical control instruction to drive different types of underlying hardware simultaneously while maintaining consistency in action semantics. This allows the control instructions to be efficiently reused across different types of heterogeneous target execution units, thereby achieving effective decoupling between upper-layer action orchestration services and lower-layer physical drivers. To achieve decoupling between upper-layer orchestration and lower-layer heterogeneous hardware, the aforementioned action control sequence and its internal action control frames can be defined and issued using a unified data structure. The system defines a unified gesture data structure (e.g., GestureData), which includes a gesture name identifier (name, type string) and motion control frame sequences (represented as independent []Frame arrays) corresponding to various underlying hardware models (e.g., O6, O7, L10_WormGear with worm gear structure variants, L10_BallJoint with ball joint structure variants, L20, L25, etc.). Based on this unified gesture data structure, control data from multiple heterogeneous devices can be centrally encapsulated. To support complex long-term multi-gesture concurrent tasks, the system encapsulates a global motion choreography data structure (e.g., the dance data structure DanceData).This data structure contains a global identifier name (name, type string) for the orchestration task, and binds different timing nodes (frameKey) to their corresponding unified gesture data structure through key-value pair mapping (e.g., defined as sequence: map[frameKey]GestureData), thus forming a complete motion control sequence. With this data structure design, the system can directly drive any type of execution unit present in the field, relying on a single configuration file. During actual execution, logical control instructions are extracted frame by frame as matching indices for physical mapping by the underlying execution engine. The system extracts logical control instructions from the motion control frame and performs address matching with the logical control identifier (LogicalControl) in the target execution unit's dedicated configuration dictionary (e.g., a byte mapping array). If a match is found, the logical control instructions are converted into underlying physical control values ​​recognizable by the target hardware according to the corresponding physical mapping rules, and written to the load offset bits to assemble and generate a physical control frame. By introducing logical control instructions independent of the underlying hardware and combining them with a dedicated configuration dictionary for mapping matching, the upper-layer semantic control quantities and the details of the lower-layer communication protocol (e.g., CAN protocol) are effectively configured and decoupled, reducing the dependence of motion data on specific physical models. Therefore, existing motion control sequences can be adapted and reused among heterogeneous devices with different structures and models. In addition, adopting standardized motion control sequences helps to simplify the process of upper-level multi-gesture orchestration and task scheduling, improves the compatibility of the control system and the flexibility of device collaborative scheduling, and thus enhances the overall coordination of multiple heterogeneous execution units under concurrent orchestration control.

[0031] Step 120: Obtain the communication protocol configuration information and inter-frame interval time corresponding to the target execution unit. In this step, the communication protocol configuration information refers to the mapping data table constructed for each type of device model compatible with the system. The communication protocol configuration information serves as a static mapping basis, used to specify the underlying physical protocol specifications of the corresponding hardware model, thereby providing rule support when the system performs addressing translation and physical control frame assembly. The inter-frame interval time refers to the delay waiting time between the actions sent by two adjacent physical control frames. The inter-frame interval time is independent of the static communication protocol configuration information and is a dynamic scheduling parameter. The system can flexibly adjust the inter-frame interval time during runtime according to the mechanical response speed of the specific hardware, thereby controlling the actual frequency of control frame sending by each concurrent thread. In some embodiments, the default value of the inter-frame interval time can be set to a value in the range of 200ms to 500ms, for example, preferably 300ms. In some embodiments, the system can load a differentiated default delay that matches the mechanical response characteristics of the corresponding hardware according to the device model of the target execution unit. For example, the inter-frame interval is set to 300ms for the L10 model device and 200ms for the O6 model device. In other embodiments, the inter-frame interval can be overwritten in real time during system operation in response to dynamic rate requirements in upper-layer action orchestration services. By flexibly scheduling the inter-frame interval as a dynamic parameter independent of static configuration, the system can effectively adapt to the physical differences in mechanical response speed of different hardware models, improving the operational stability during concurrent scheduling of multiple heterogeneous devices. In some embodiments, the communication protocol configuration information includes command codes, frame lengths, and a data mapping set consisting of at least one logical control identifier and a payload offset bit. In this embodiment, the command code refers to the instruction semantic identifier carried in the first byte of the physical control frame (e.g., a CAN data frame). Different command codes are used to indicate different underlying operation semantics (e.g., 0xC0 for multi-frame model lookup, or 0x64 for single-frame model lookup, etc.). The target execution unit matches the corresponding underlying parsing rules based on the command code, thereby completing the physical decoding and action driving of subsequent data payloads. Frame length is a fixed-length parameter representing the total number of bytes occupied by the underlying physical control frame. During the actual execution of the underlying assembly operation, the system needs to pre-allocate a byte array space of the corresponding length in memory based on the frame length. The data mapping set is used to define the addressing rules between the upper-layer business logic and the underlying physical space. Each mapping entry in the data mapping set contains a logical control identifier (LogicalControl) representing the specific action intent, and a corresponding payload offset bit. The payload offset bit is an index parameter used to indicate the assembly and parsing position within the physical control frame.The payload offset bit in the communication protocol configuration information defines the correspondence between the abstract logical control identifier (LogicalControl) and the specific byte position within the physical control frame. When assembling the physical control frame, the system uses this payload offset bit as coordinates to accurately fill the specific values ​​corresponding to the aforementioned logical control instructions into the byte space corresponding to the payload area of ​​the physical control frame. In some embodiments, the communication protocol configuration information can be persistently stored in the form of JSON (JavaScript Object Notation), XML, or other structured data text. This structured configuration method, independent of code compilation logic, allows for rapid compatibility and support for new device models without modifying or refactoring the core scheduler, simply by introducing or modifying a configuration file containing the communication protocol configuration information. In actual execution, the communication protocol configuration information can be fully loaded at startup and reside in system memory to build a global static mapping library; alternatively, it can be dynamically read and parsed through a lazy-load mechanism when the system first detects the target execution unit of the corresponding model connected to the bus. This disclosure does not strictly limit the specific loading timing of the configuration information.

[0032] In some embodiments, the communication protocol configuration information and inter-frame interval time are determined based on the device model of the target execution unit. In actual execution, taking loading at the start of the main control program as an example: the system can load all communication protocol configuration information (e.g., JSON or other structured text format model configuration file FingerConfig) containing various device models at once during program startup. The communication protocol configuration information is categorized by the device model of each target execution unit; for each device model, several frame configurations (FrameConfig) corresponding to different underlying control functions (e.g., position control, speed control, etc.) are described. Each frame configuration specifically includes a corresponding command code, frame length, default value field, and a data mapping set (mapping[]) consisting of logical control identifiers and load offset bits (i.e., byte index ByteIndex). In other embodiments, the communication configuration protocol information may also include a set of logical control item definitions. Each logical control item definition includes the control group category to which the logical control identifier belongs (e.g., basic motion group, swing control group, speed adjustment group, roll / yaw control group, root1 / tip control group, etc.) and default value parameters, thus providing a business-level classification basis and initial attribute configuration for the host computer's motion orchestration and interface rendering. Based on the clearly defined control group categories and default parameter specifications in the configuration information, standardized data support is provided for the visualization rendering of the upper-layer human-computer interaction interface and the rapid orchestration of motion sequences, which helps to reduce the development complexity of the front-end interaction system. In some embodiments, in order to improve the efficiency of global scheduling and avoid frequent bus queries, the system builds and maintains a device four-tuple cache (e.g., defined as deviceCache) in memory. This cache uses the communication interface as the key and maps it to a target feature tuple containing the device model, side, variant, and cache expiration time. Specifically, the time to live (TTL) of this cache can preferably be configured to 5 seconds. Within this lifecycle, the system can directly read device parameters from the cache without initiating a low-level bus query. When determining the communication protocol configuration information based on the acquired device parameters, the system pre-sets a mode priority table. This table is represented as an ordered sequence, such as [(L25, [LHG20, LHT20]), (L10, [L10, LHT10]), (L6, [L6, LHT06]), (O7, [O7, 07]), (O6, [O6, 06])].In the actual matching process, the system adopts the first hit principle for traversal matching. Once the model and variant reported by the underlying hardware fall into the sequence set of a certain level, the corresponding upper-level general logic model (such as L25, L10, etc.) is immediately returned, thereby quickly determining the communication protocol configuration information of this type of execution unit.

[0033] Step 130: Based on the communication protocol configuration information, extract the logical control instructions from the motion control frame and assemble the logical control instructions into a physical control frame. In this step, the logical control instructions are essentially standardized motion identifiers (e.g., "thumb_swing" for thumb swing, "index_bend" for index finger bending, etc.) encapsulated within the motion control frame to characterize the motion features of each joint. By coordinating multiple logical control instructions within a single motion control frame, the target execution unit is driven to form the expected overall pose state at the current frame time. The physical control frame essentially refers to the underlying communication message (e.g., CAN bus message or serial port byte stream) that the underlying hardware device (i.e., the target execution unit) can directly parse and execute. At the specific data structure and transmission level, it corresponds to the byte array actually sent to the CAN bus or other communication links, and the first byte of the byte array is usually the aforementioned command code. In other embodiments, the aforementioned mechanism of dynamically parsing and assembling physical control frames at runtime based on communication protocol configuration information (i.e., configuration-driven generation method) can be equivalently replaced by a dedicated encoding function automatically generated for each device model during compilation based on code generation technology, or by low-level execution logic that pre-describes the frame structure based on a domain-specific language (DSL) and compiles it. It should be understood that regardless of the conversion mechanism used, as long as the consistency of the issued interface can be maintained when accessing the target execution unit of a new model, and there is no need to modify the system's core orchestration, scheduling, and state storage code, it falls under the equivalent alternative protected by this disclosure.

[0034] Based on communication protocol configuration information containing low-level details such as command codes, frame lengths, byte mappings, and default values ​​for each device model, a three-segment mapping method of "logical control instructions—configuration information—physical control frames" is adopted. At runtime, the extracted logical control instructions are dynamically assembled into physical control frames executable by specific hardware. Therefore, the system does not need to hardcode dedicated protocol parsing and assembly logic for each device model in the core business code; when a new device model is connected or the underlying protocol is changed, only the corresponding configuration information needs to be expanded or updated to complete the adaptation, avoiding modification and recompilation of the core code, thereby reducing the system's expansion costs. Simultaneously, as a hardware-independent abstract action semantic, the same set of logical control instructions can be correctly converted into corresponding physical messages based on their respective configuration information when driving different models of underlying hardware, thus maintaining the consistency of action execution across multiple models of execution units. In some embodiments, step 130 includes: allocating a byte array based on the frame length and writing the command code into the first byte of the byte array; traversing each logical control identifier in the data mapping set and searching for the logical control instruction corresponding to the logical control identifier in the action control frame; if the action control frame includes a logical control instruction, writing the corresponding control value into the byte array at the position indicated by the corresponding load offset bit; if the action control frame does not include a logical control instruction, writing the preset control value in the communication protocol configuration information into the byte array at the position indicated by the corresponding load offset bit. In this embodiment, the first byte serves as the starting address bit of the storage space and is specifically used to store the command code indicating the operation type of the physical control frame. The control value refers to the specific numerical parameter dynamically issued by the upper-layer service for a specific action; the preset control value refers to the default parameter pre-set for each logical control item in the communication protocol configuration information, so as to fill in the missing parameters in the load when the action control frame lacks the corresponding logical control instruction. In actual execution, the system (such as the logic control and physical frame conversion module) will configure each frame of the target device, pre-allocate a byte array (frameData) of the corresponding size according to the frame length (Length) of the frame, and set the first byte to the corresponding command code (frame.CommandCode).

[0035] The program iterates through the byte mapping array configured for the frame, using the logical control identifier (LogicalControl) as the retrieval basis, and executes the control value lookup logic (e.g., calling the lookupLogicalValue function). In each control group carried by the currently received action control frame (i.e., this control request), it searches for the logical control instruction corresponding to the logical control identifier and extracts the current control value from the logical control instruction. If the action control frame includes a logical control instruction, the corresponding current control value is written into the byte array at the position indicated by the corresponding load offset bit. If the action control frame does not include a logical control instruction, the preset control value of the logical control item is extracted and replaced, and the preset control value is written into the byte array at the position indicated by the corresponding load offset bit.

[0036] It should be noted that, considering the first byte is usually already occupied by the command code, when actually calculating the memory index to write the aforementioned control value or preset control value, the actual byte writing position is usually at the memory coordinates corresponding to the payload offset bit extended by the corresponding length (e.g., ByteIndex + 1). By pre-allocating a byte array based on the frame length and writing it according to the payload offset bit, the format accuracy of the underlying message dynamic construction is improved. At the same time, parameter completion is performed using preset control values ​​during the assembly process, enabling the generation of a complete physical control frame even when the action control frame contains only part of the logical control instructions. This mechanism reduces the risk of underlying hardware parsing anomalies due to missing local data, thereby enhancing the consistency of device control and the fault tolerance of the system.

[0037] In some embodiments, traversing each logical control identifier in the data mapping set and searching for the logical control instruction corresponding to the logical control identifier in the action control frame further includes: if no corresponding logical control instruction is found in the action control frame for each logical control identifier in the data mapping set, performing the following operations: skipping the assembly of the corresponding physical control frame; skipping the issuance of the physical control frame. In actual execution, the above steps essentially implement a "full-frame empty skip" security protection mechanism. If no corresponding current control value is extracted for each logical control identifier in the data mapping set (i.e., the upper-layer service has not issued any logical control instructions involved in the current communication protocol configuration information), the system directly skips the construction and issuance process of the corresponding physical control frame. This mechanism reduces the risk of mistakenly issuing preset control values ​​as actual control intentions. This reduces the possibility of the underlying hardware performing unexpected mechanical actions and improves the safety and reliability of the target hardware device during controlled execution. In some embodiments, the speed control identifier in the logical control instruction is used to batch write the corresponding speed control values ​​into the speed mapping bit in the byte array. In this embodiment, the speed control identifier is used to characterize the device's motion rate adjustment attribute; the speed mapping bit is the physical storage location in the byte array used to write the rate parameter. In actual execution, for message configurations specifically used for rate adjustment (commonly known as "speed frames" in practical engineering), when the system (or conversion module) recognizes that the currently processed logical control identifier has a speed control attribute (e.g., the identifier's name ends with the suffix "_speed"), it will batch and uniformly write the extracted same speed control value into all speed mapping bits in the current byte array. By batch writing the corresponding speed control values, the repeated issuance of similar rate parameters by upper-layer services is reduced, the instruction logic of the software layer is simplified, and the assembly efficiency of the underlying message is improved, so as to conveniently realize the global speed adjustment of the target execution unit or the partial speed adjustment of some joints. In some embodiments, the method further includes: when the device attributes of the target execution unit include a variant identifier, generating a refined device identifier based on the base model and variant identifier of the target execution unit; and reading the corresponding communication protocol configuration information based on the refined device identifier.

[0038] In this embodiment, the variant identifier (corresponding to the structural variant of the target execution unit) is used to characterize the differences in the underlying transmission structure or hardware iteration version of the same basic model. Essentially, it refers to different mechanical implementations under the same basic model. The refined device identifier is used to accurately match the joint retrieval key value of the corresponding dedicated configuration dictionary. In actual execution, taking the variant mapping of a specific execution unit as an example, when the system (or conversion module) detects that the target execution unit belongs to a specific basic model (e.g., model L10) and its device attributes include a variant identifier, it combines the basic model of the target execution unit with the variant identifier by executing model feature extraction logic (e.g., calling the getModelKey mapping function), mapping it to a refined device identifier pointing to a specific underlying hardware structure (e.g., for model L10, when its variant identifier corresponds to a worm gear mechanical implementation, it is mapped to the refined device identifier L10_WormGear; when it corresponds to a ball joint mechanical implementation, it is mapped to the refined device identifier L10_BallJoint), and then loads the corresponding byte mapping rules accordingly. By introducing the aforementioned variant mapping mechanism, it is possible to achieve backward compatibility with heterogeneous hardware of the same system with different underlying mechanical structures without changing the unified calling of upper-layer services. This improves the accuracy of communication protocol configuration information calling and enhances the overall control framework's ability to expand hardware iteration and non-standard customization.

[0039] In some embodiments, the method further includes: jointly encapsulating the physical control frame with a communication interface identifier and a target identifier to generate a physical communication message. In this embodiment, the communication interface identifier is used to specify the addressing parameters of the target bus interface; the target identifier is used to indicate the bus address of the target execution unit receiving the message. In actual execution, for the physical control frame sequence assembled for each target execution unit, the system (logic control-physical frame conversion module) associates and encapsulates the corresponding bus interface information (interface), device bus ID (id), and assembled byte array (data) to generate a physical communication message in a unified format (e.g., the CanMessage{interface, id, data} data structure), which is then sent to the hardware by the subsequent local REST bridging architecture. By packaging the physical control frame into a physical communication message containing interface, identifier, and data, the data interaction format of the underlying communication interface is standardized, which helps to shield the transmission differences between different physical buses; it also realizes the precise routing binding of message data and physical interface, which helps to improve the transmission efficiency and reliability of physical control frames sent to the underlying communication bus.

[0040] In some embodiments, the method further includes: allocating a corresponding asynchronous execution thread to the target execution unit before extracting the logical control instructions from the action control frame; in the asynchronous execution thread, sequentially performing the step of "extracting the logical control instructions from the action control frame based on communication protocol configuration information and assembling the logical control instructions into a physical control frame" for each action control frame; in the asynchronous execution thread, sequentially performing the step of "sending the physical control frame to the target execution unit based on the inter-frame interval time to drive the target execution unit to execute the action corresponding to the logical control instructions" for each physical control frame. In this step, the asynchronous execution thread is an independent coroutine created for each variant subset. In other equivalent embodiments, the asynchronous execution thread can also be replaced by a thread pool, coroutine pool, or actor model.

[0041] The inter-frame interval time refers to the independent time threshold maintained for each model variant subset (e.g., a default of 300 milliseconds). The inter-frame intervals for different model variants within the same orchestration task are independent and do not block each other. In actual execution, the system creates an independent coroutine for the target execution unit and iterates through the action control frame sequence within the inner loop of this coroutine, sequentially issuing the assembled physical control frames according to the inter-frame interval time, thereby achieving asynchronous and independent execution of action commands. According to the robot control method provided in this application embodiment, by allocating corresponding asynchronous execution threads to the target execution unit, the protocol assembly and sequential issuance process of action commands is placed in an independent thread space, enabling various control tasks in multi-model mixed scenarios to operate in parallel. Each execution unit sequentially issues physical control frames based on its own dedicated inter-frame interval time, reducing mutual interference and blocking between different underlying devices during command scheduling. By sequentially traversing and processing the action control frames within their respective asynchronous threads, it is beneficial to maintain the continuity of the action sequence execution of a single device, alleviate the global waiting and system congestion caused by the lag in response of individual devices in the traditional synchronous scheduling mode, and thus improve the overall coordination of multiple heterogeneous execution units under concurrent orchestration control.

[0042] In some embodiments, when the target execution unit includes multiple target sub-execution units, step 130 includes: dividing the multiple target sub-execution units into multiple execution groups according to the device model corresponding to each target sub-execution unit; allocating corresponding independent concurrent execution threads to each execution group; and in each concurrent execution thread, based on the communication protocol configuration information of the corresponding execution group, performing the step of "extracting logical control instructions from the control frame based on the communication protocol configuration information and assembling the logical control instructions into a physical control frame" for each corresponding execution group. In this embodiment, each execution group proceeds asynchronously according to the corresponding inter-frame interval time. In actual execution, the multiple target sub-execution units in the target execution unit can be grouped by model: the system applies a feature extraction function (e.g., the getModelKey function) to the target device list for this execution and groups it into subsets of model variants such as L6, L10_WormGear, L10_BallJoint, O6, and O7 (i.e., execution groups). Among them, devices of the same model but with different physical interfaces or types are still classified into the same subset. It should be noted that in other embodiments, the aforementioned "grouping by model" strategy can also be flexibly replaced by grouping by individual device, by hand, or by specific "machine group". It should be understood that regardless of the grouping feature used, as long as the underlying execution scheduling maintains "frames" as the smallest temporal unit, each execution group maintains independent timing (i.e., the inter-frame intervals are independent), and can gracefully respond to interruptions at any frame boundary, it is an equivalent alternative of this disclosure. After grouping, in order to achieve concurrent execution of the control logic orchestration execution module by model, an independent coroutine is created for each model variant subset as a concurrent execution thread. Each coroutine runs concurrently under a common stop signal channel (stopChan). According to the robot control method provided in the embodiments of this application, when facing a complex mixed scenario containing multiple target sub-execution units, each sub-execution unit is divided into multiple execution groups according to the device model, and each execution group is assigned a corresponding independent concurrent execution thread. Based on the above-mentioned concurrent processing architecture by model grouping, it supports the execution of cross-model action sequences along the same time axis for multiple heterogeneous devices in a mixed environment. Meanwhile, each execution group, within its own concurrent thread, asynchronously assembles and schedules physical control frames according to its dedicated inter-frame interval, enabling the instruction distribution frequency to be finely adapted to the actual mechanical response speed differences of different underlying devices. Combined with the aforementioned scheduling strategy of model-based isolation and independent timing, this reduces mutual constraints and instruction congestion among devices with different structures operating synchronously, improving the overall coordination of multiple heterogeneous execution units under concurrent orchestration control.

[0043] In some embodiments, step 130 includes: during the asynchronous execution of each concurrent execution thread, each concurrent execution thread sequentially extracts the action control frames from the action control sequence according to the corresponding inter-frame interval time; each concurrent execution thread independently assembles the corresponding logical control instructions into physical control frames based on the communication protocol configuration information of the corresponding execution group. In order to realize the above-mentioned control logic of concurrent execution by model, during the asynchronous execution of the concurrent execution threads, the outer loop of each coroutine (i.e., concurrent execution thread) is repeatedly executed according to the repeat parameter in the action request; its inner loop sequentially traverses the pre-loaded and sorted ordered frame sequence (i.e., the aforementioned action control frame sequence), and independently sends the physical control frame (e.g., CAN frame sequence) corresponding to each frame to all target devices in the subset of model variants (i.e., the execution group to which it belongs). In some embodiments, before each concurrent execution thread extracts the action control frame, the method further includes: loading a set of unordered gestures corresponding to the received action execution request; extracting the frame number corresponding to each gesture in the unordered gesture set; and sorting the frame numbers according to a preset sequence rearrangement rule to convert the unordered gesture set into an action control sequence with execution timing. To implement the above loading and sorting logic, the system specifically loads the corresponding set of unordered gestures (which, at the data processing level, is typically represented in memory as a map[frameKey]) based on the action identifier (e.g., a specific dance name) in the action execution request. The system extracts the frame number (i.e., frameKey) corresponding to each gesture and rearranges the unordered gesture set strictly according to the lexicographical order of the frame numbers as a preset sequence rearrangement rule, thereby transforming it into an ordered frame sequence (i.e., the aforementioned action control sequence) for each concurrent execution thread to traverse sequentially in a loop. Regarding the delay parameter (i.e., inter-frame interval time), in some embodiments, each execution group (i.e., a subset of model variants) maintains an independent inter-frame interval in its respective concurrent execution thread (at the code implementation level, for example, represented by the variable intervalMs, with a default value of 300 milliseconds in its embodiments). The system (e.g., the aforementioned gesture orchestration execution module) exposes specific dynamic configuration interfaces (e.g., the SetModelInterval function) that support dynamic modification of the inter-frame interval of a specific execution group at runtime according to the specific refined device identifier (i.e., model variant key). Because each concurrent execution thread has underlying isolation, the inter-frame intervals of different types in the same action request (i.e., orchestration task) are completely independent of each other, and the modification of parameters and the issuance of actions do not block each other.

[0044] According to the robot control method provided in this application, each concurrent execution thread controls the action delivery rhythm according to its own dedicated inter-frame interval time, and independently translates the logical control instructions into corresponding physical control frames. Based on the above-mentioned asynchronous advancement and independent assembly processing method, the system finely adapts to the differences in mechanical response speed of different devices, reducing mutual waiting and blocking between threads. At the same time, combined with nested loop logic, the system can batch-deliver the generated physical messages to all devices in the same group, reducing the underlying scheduling overhead. As a result, multiple heterogeneous devices can operate independently and in parallel along the same time axis according to their respective rhythms, thereby improving the overall coordination of multiple heterogeneous execution units under concurrent orchestration control. In some embodiments, each concurrent execution thread extracts control frames from the action control sequence in sequence according to the corresponding inter-frame interval time, including: each concurrent execution thread listens for stop instructions and timer instructions in parallel; when a stop instruction is heard, the current concurrent execution thread is controlled to interrupt execution at the frame boundary; when no stop instruction is heard and the timer instruction indicates that the corresponding inter-frame interval time has been reached, the action control frame in the action control sequence is extracted.

[0045] In this embodiment, the monitored execution period includes the frame boundary of the action control frame and the waiting process based on the corresponding inter-frame interval. During actual execution, to implement the aforementioned "interruptible waiting" control logic, each concurrent execution thread simultaneously monitors the stop signal channel (corresponding to the stop instruction) and the timer channel (corresponding to the timing instruction) through a non-blocking concurrent multiplexing mechanism (manifested at the code level as a non-blocking select statement) during the aforementioned execution period. Each concurrent execution thread monitors the stop instruction and the timing instruction in parallel through non-blocking multiplexing during the frame boundary and inter-frame waiting periods. Based on the above concurrent monitoring processing, externally issued stop instructions can be responded to promptly and smoothly interrupted at the boundary of any action control frame. These processing steps effectively reduce the risk of the entire system's stop scheduling being blocked by excessively long inter-frame waits of individual devices, enabling the underlying multi-threaded systems to quickly release control resources without interfering with each other when faced with external stop requests, thereby improving the overall coordination of multiple heterogeneous execution units under concurrent orchestration control.

[0046] In some embodiments, the robot includes a human-machine interface device. After sending a physical control frame to the target execution unit, the method further includes: obtaining the final-state physical control frame in the physical control frame; parsing the target load bit in the final-state physical control frame into a target logical state value based on the load offset bit in the communication protocol configuration information; and updating the interaction state of the control component of the human-machine interface device based on the target logical state value. In this embodiment, the final-state physical control frame refers to a communication message used to characterize the expected pose of the target execution unit in the final state of the current action control sequence. The load offset bit refers to an index parameter used to indicate the internal assembly and parsing position of the physical control frame. The target load bit is the original load byte segment located and extracted in the physical control frame based on the load offset bit. The target logical state value is a state parameter used to characterize the expected pose of the target execution unit in the final state to the human-machine interface device. The expected pose of the target execution unit in the final state is determined based on the expected physical result deduced from the final-state physical control frame.

[0047] After sending the physical control frame to the underlying hardware, the system extracts the final-state physical control frame and reverse-parses it into the target logic state value based on the load offset bits. Based on this reverse parsing process, the system can update the interaction state of the human-machine interface device in a timely manner, combining the deduced expected physical results. These processing steps effectively reduce the risk of discrepancies between the user interface display and the actual physical pose of the underlying device after the action sequence is executed, enabling the front-end interface to intuitively and accurately map the final state of the underlying hardware's actions. Thus, the upper-level control end can accurately grasp the actual action completion status of each underlying device; in complex situations involving multiple concurrent tasks, this reliable state feedback avoids scheduling conflicts caused by asynchronous hardware and software states, thereby improving the overall coordination of multiple heterogeneous execution units under concurrent orchestration control.

[0048] In actual execution, the reverse resolution process for the target logical state value specifically includes: when the current action control sequence is issued to the last frame of the last round, the system (e.g., the orchestration execution module) uses a preset state resolution function (e.g., convertFramesToLogicalValues) to reverse-parse the final physical control frame into the target logical state value. The specific logic of the reverse resolution process is as follows: First, scan the starting byte of the final physical control frame to match the specific command code (e.g., FrameConfig.CommandCode) in the communication protocol configuration information; strictly based on the payload offset bit (e.g., a specific byte mapping index ByteIndex + 1), locate and extract the target payload bit (i.e., the original payload byte segment) in the final physical control frame; combine the group reverse lookup logic (e.g., findControlGroup) to reverse-query the control group to which the target execution unit corresponding to the original payload byte segment belongs; finally, assemble the above parsing results into a multi-dimensional mapping structure (e.g., map[group]map[control]int form) of the target logical state value. The assembled target logic state value is returned to the human-computer interaction device (such as the front end) along with the response message. This directly drives the corresponding control components (such as interface sliders) to precisely reset to the interaction indication position corresponding to the "expected pose" in the final state, thereby completing the final update of the interaction state. The underlying scheduling logic for the above gesture orchestration execution can be implemented through the following pseudocode.

[0049] Sort dance.sequence into frames[] by frameKey in lexicographical order. Grouping targets into groups using getModelKey(target): map[modelKey] -> []target Start a goroutine for each (modelKey, targetGroup): for round in 1..repeat: for frame in frames: Non-blocking check stopChan: If a signal is received, exit at the frame boundary. data = frame.gesture.GetFrames(modelKey) Send data to all targets in the targetGroup select { case<- stopChan: Exit case <- time.After(interval[modelKey]): Continue to the next frame. } Wait for all goroutines to exit Final logical values ​​= convertFramesToLogicalValues(last frame, typical modelKey) return final state logical value The following is based on Figure 2 Taking this as an example, we will explain in detail the specific execution process of the gesture orchestration engine. Figure 2 This demonstrates the execution process, including starting independent coroutines by model group, repeating the outer loop by frame sequence, sending out inner frames by frame, waiting between frames by model, listening for the stop signal at each frame boundary using a non-blocking select function, and deconstructing the final state logic value. The specific implementation steps are as follows: Sequence sorting and group scheduling are performed. Upon receiving an orchestration execution request (e.g., a POST / api / hand / exec mode=dance (name, repeat, targets) request initiated by the front end), the system, on the one hand, strictly sorts the current action control sequence (i.e., dance.sequence[]) according to the lexicographical order of frameKey; on the other hand, based on device model characteristics (e.g., using the getModelKey(target) function), the target execution unit list is divided into multiple independent execution groups (e.g., ...). Figure 2The system is divided into subsets of model variants such as L10_WormGear, L10_BallJoint, and O7. Concurrent execution threads are started. The system allocates and starts corresponding independent concurrent execution threads (such as goroutines) for each partitioned execution group. Each concurrent execution thread shares the same global stop signal channel (i.e., stopChan in the diagram) in memory for receiving external Stop requests (broadcasts). Nested loops are executed, and physical control frames are sent. Within each concurrent execution thread, the system executes double-layered nested control logic: the outer loop advances according to the set number of iterations (e.g., for round in 1..repeat); the inner loop advances frame by frame along the sorted frame sequence (e.g., for frame in frames). In each iteration of the inner layer, the system calls the frame extraction logic corresponding to the model (e.g., executing frame.GetFrames(L10_WormGear), frame.GetFrames(L10_BallJoint), or frame.GetFrames(O7) respectively), and independently sends the assembled physical control frame to each underlying target execution unit under the execution group through the underlying communication interface (e.g., triggering a POST / api / can request). Non-blocking listening at the execution frame boundary and independent inter-frame interval control are implemented. At the frame boundary after the current physical control frame has been sent, each concurrent execution thread uses a non-blocking multiplexing mechanism (e.g., a select syntax block) to simultaneously execute two listeners: one is listening to stopChan, and the other is listening to the timer bound to the execution group (e.g., ...). Figure 2In L10_WormGear, the case <- After (250ms): next; in L10_BallJoint, the case <- After (300ms): next; and in O7, the case <- After (400ms): next. If an external stop signal is captured during this waiting interval (i.e., the case <- stopChan: break is executed), the thread immediately jumps out safely at the current frame boundary and is interrupted (i.e., graceful interruption). If the timer times out normally, it continues to advance to the next frame according to the predetermined independent timing. The system performs multi-threaded rendezvous and final state logic value inversion. After all frames of all concurrent execution threads have been sent or interrupts have been responded to, the system executes thread rendezvous (e.g., three coroutines join). Subsequently, the system extracts the last sent physical control frame and reverse-parses it into the target logic state value (which is represented in data structure as a multi-dimensional mapping structure that returns the final state logic value map[group]map[control]int) using a preset inversion function (e.g., convertFramesToLogicalValues()). The assembled target logic state value is returned to the front end with the execution response, which is used to directly drive the control components of the human-computer interaction device to accurately reset (i.e., trigger the front end slider reset in the diagram).

[0050] Step 140: Based on the inter-frame interval, the physical control frame is sent to the target execution unit to drive the target execution unit to execute the action corresponding to the logic control instruction. In this step, the inter-frame interval refers to the inter-frame waiting time parameter independently set for a specific execution group to ensure compatibility with heterogeneous underlying hardware (such as the difference in response speed between worm gear variants and ball joint variants). Using the frame as the smallest timing unit means abandoning the traditional continuous sending mode of large instruction packets and treating a single physical control frame as an indivisible atomic operation of underlying scheduling and interruption. In actual execution, the independent concurrent execution threads corresponding to each execution group sleep and wait for the control flow according to this "inter-frame interval," thereby forming a precise timing interval between the continuous physical control frames sent to the target execution unit. Specifically, after each concurrent execution thread sends the current single physical control frame to the target execution unit, the thread immediately enters a controlled non-blocking waiting state. During this waiting interval, the thread synchronously listens for external stop signals. If an interrupt command is captured, the thread immediately terminates its action safely at the current frame boundary (i.e., a graceful interrupt is achieved). If the timer reaches the inter-frame interval normally, the thread continues to advance and sends the next physical control frame. This mechanism effectively avoids driver overshoot damage caused by excessively rapid command issuance and ensures that the control system is not blocked by the long-interval execution at the lower level.

[0051] In some embodiments, before step 110, the method further includes: clearing the historical message cache of the communication interface corresponding to each execution unit, and issuing a first query instruction via each communication interface; if a valid multi-frame message returned in response to the first query instruction is received, parsing the device parameters of each execution unit from the valid multi-frame message; if no valid multi-frame message returned in response to the first query instruction is received, issuing a second query instruction via each communication interface; if a single-frame message returned in response to the second query instruction is received, parsing the device parameters of each execution unit based on the target byte bits of the single-frame message; and determining the communication protocol configuration information and inter-frame interval time corresponding to each execution unit based on the device model in the device parameters. In this embodiment, the first query instruction refers to a query instruction used to trigger the target execution unit to return a complete device model string. Since the device attribute information carried by this model string is relatively rich, the underlying hardware needs to split the complete model string into a multi-frame sequence for segmented return after receiving the first query instruction. The second query instruction refers to a query instruction used to trigger the target execution unit to return a fixed-length message in single-frame form. In the single-frame message corresponding to this instruction, multiple preset specific byte positions (i.e., target byte bits) directly map and encode the corresponding core device parameters (e.g., specific byte bits represent the device model, structural variant, and handheld device type, respectively). In some embodiments, the device parameters of each execution unit parsed from each valid multi-frame message or each single-frame message include at least: device model, structural variant, and handheld device type. During actual execution, the system binds the parsed device parameters (i.e., the device parameter triplet containing device model, structural variant, and handheld device type) to the corresponding communication interface that receives the device parameters to construct a target feature tuple (e.g., a quadruple containing communication interface, device model, handheld device type, and structural variant) for global scheduling and precise instruction delivery. During actual execution, the first query instruction and the second query instruction constitute a primary-backup redundant compatibility polling architecture in the device identification mechanism. Based on the first query command and its corresponding multi-frame sequence response, the system can obtain complete device characteristics with high scalability, and therefore configures it as the priority delivery sequence. Based on the second query command and its corresponding single-frame fixed-byte response, the system can obtain low-level parsing guarantee with high backward compatibility, and therefore configures it as the fallback sequence when the aforementioned priority delivery sequence fails. This master-slave combination mechanism built based on the physical response characteristics of the command (multi-frame long messages and single-frame short messages) enables the system to reliably and accurately complete device identification and automatic access even when the heterogeneous hardware firmware version is too low (does not support long messages) or the field communication bus response times out.

[0052] According to the robot control method provided in this application, the interference of bus-residual data on the current device identification process is reduced by pre-clearing the historical message cache. Simultaneously, the system introduces a primary / backup disaster recovery strategy that prioritizes multi-frame messages and degrades and rolls back specific byte messages in a single frame, enhancing the backward compatibility and robustness of device querying in scenarios with multiple firmware versions and naming conventions. This design enables the system to automatically parse the accurate device model even in complex operating conditions such as limited underlying hardware firmware versions or response timeouts. This not only reduces the tedious steps of manual selection and configuration by users and effectively reduces the risk of misselection, but also provides a reliable underlying hardware benchmark for subsequent multi-task concurrent scheduling, thereby improving the overall coordination of multiple heterogeneous execution units under concurrent orchestration control. The pseudocode for the above device identification process is shown below.

[0053] Recognition device (iFace): DELETE / api / messages / iface# Clear cache for canId in [0x27, 0x28]: Send 0xC0 query frame to canId Collect response frames and assemble them into a modelString according to their frame numbers. If assembly is successful: (model, side, variant) = Priority Matching(modelString) return (iface, model, side, variant) # Revert to 0x64 Single Frame Query for canId in [0x27, 0x28]: Send a 0x64 query frame to canId data = Waiting for 8-byte response model = dictionary[data[1]] variant = dictionary[data[2]] side = dictionary[data[4]] return (iface, model, side, variant) No device returned In actual implementation, the device identification process of the above system specifically includes the following sub-steps: (a) Message Cache Purge: For each available communication interface (e.g., CAN interface), the system first actively clears the historical message cache corresponding to that interface (e.g., by issuing a DELETE command to / api / messages / ). <iface>(a) Request), to avoid interference from old messages left over from previous tasks on the current model identification. (b) Multi-frame sequence assembly query: The system attempts to set the hardware identifiers (such as CAN ID 0x27 for the right-hand device and 0x28 for the left-hand device) in sequence on the communication interface, and issues the first query command with command code 0xC0. The target execution unit (device side) returns with a multi-frame sequence response. The first byte of each response frame is 0xC0, the second byte is the frame sequence number, and the following bytes are the payload fragment of the model string. The system sorts and assembles the received response frames according to the frame sequence number, thereby parsing out the complete model string. (c) Single-frame query rollback: When the system does not receive a valid multi-frame message in response to the first query command (e.g., the firmware version of the target device does not support the first query command, a response timeout occurs, or partial packet loss causes the multi-frame sequence assembly to fail), the system automatically rolls back to the single-frame query logic and issues the second query command with command code 0x64. The single-frame response corresponding to this instruction is fixed at 8 bytes, where specific byte positions directly correspond to device parameter encoding (for example, the target byte position of data[1] is the model encoding, the target byte position of data[2] is the structure variant encoding, and the target byte position of data[4] is the hand type encoding). The system directly extracts the device parameter tuple containing the device model, structure variant, and hand type by reading directly according to the fixed byte position.

[0054] It is understood that in other embodiments, there are multiple equivalent alternatives to the aforementioned device identification mechanism.

[0055] The aforementioned query commands (such as command codes 0xC0 and 0x64) can be replaced with other self-describing query commands defined by the manufacturer; the process of matching device parameters based on the model string can be replaced with an equivalent matching method based on regular expressions, tries, or hash tables; the multi-frame message response mechanism can be replaced with a single long frame plus Cyclic Redundancy Check (CRC) implementation; the aforementioned primary / backup degradation fallback strategy can also be replaced with "prioritizing the issuance of the second query command" or a concurrent scheme that issues both query commands in parallel and takes the first valid response. It should be noted that regardless of the query and matching combination method used, as long as it can ultimately identify and construct a target feature tuple covering the communication interface, device model, structural variant, and hand type of the target execution unit, it is considered to fall within the scope of equivalent substitution protected by this disclosure. In some embodiments, parsing device parameters of each execution unit from valid multi-frame messages includes: obtaining the frame sequence number contained in the valid multi-frame messages; assembling the valid multi-frame messages into a device feature string based on the frame sequence number; and parsing the device feature string based on a target pattern matching rule to obtain the device parameters of the execution unit corresponding to the device feature string. In this embodiment, the target pattern matching rule refers to a string parsing rule used to identify and extract target device parameters (such as device model) from the device feature string.

[0056] In some embodiments, to avoid misjudgment of attributes due to local character overlap during long string parsing, the target pattern matching rule can adopt ordered pattern matching logic. In this embodiment, the ordered pattern matching logic assigns a strict matching priority sequence to each feature substring based on the structural characteristics of the feature substrings corresponding to each device model, and enables the system to compare the device feature strings sequentially according to the matching priority sequence. In actual execution, the system performs ordered pattern matching on the device feature strings based on the core principle of "specific substrings take precedence over general substrings". This principle is based on the partial order relationship of proper substring inclusion between feature substrings, that is, the specific substring containing richer information (such as "LHT06") must be strictly ranked before the included general substring (such as "06") for verification; once the first match is found in the order, the system determines and returns the main device model. Subsequently, the system uses a preset symbol (such as a hyphen) as a separator to scan the remaining fields to extract auxiliary attributes such as hand type (such as the "R / L" segment) and structural variants (such as the "06 / 07" segment), thereby unambiguously and completely parsing the device parameters. The aforementioned matching priority sequence is essentially a three-layer decision model determined by strong constraints to prevent misjudgment due to partial order of proper substrings, weak heuristics for optimizing the descending order of feature substring lengths, and underlying device naming conventions. It also supports offline automated derivation. Specifically, the system constructs a directed graph based on the partial order relationship of substrings. If two model features are substrings of each other, resulting in a cycle, an error message indicating ambiguity is displayed. If there is no cycle, topological sorting is performed to generate a basic linear sequence that satisfies the strong constraints, and the sequence is expanded using weak heuristic rules. Through this mechanism, when a new heterogeneous device model is added, only the feature mapping needs to be appended and the graph topological sorting re-executed to automatically output the latest priority sequence to prevent collisions, eliminating the risk of manual reordering and intrusive modifications to the core code. Finally, the successfully parsed target feature tuple (i.e., the device quad tuple containing the communication interface, model, hand type, and variants) will be written to a device list cache configured with a preset time-to-live (TTL, e.g., 5 seconds). Within the lifetime validity period, the system directly intercepts repeated query commands for the same device and returns a cache hit. Only after the cache expires is a new underlying physical query allowed, thus achieving an efficient balance between real-time status and bus communication load. By introducing this cache lifecycle management mechanism, the system effectively avoids underlying physical bus congestion caused by high-frequency front-end status updates, significantly improving the communication scheduling efficiency of heterogeneous hardware networks. It should be noted that the target feature tuples generated by the aforementioned device identification process, including communication interface, device model, type, and structural variants, are maintained only as a dynamic runtime context within the system. In some specific application scenarios, to cope with hot-plug events of the underlying hardware, the system supports manually issuing reload commands for a single physical device or a specific communication interface through a host control terminal or human-machine interface (such as a console interface).When a reload command is received, the system will proactively invalidate the aforementioned device list cache and re-trigger the aforementioned underlying identification and parsing process for that device, thereby ensuring real-time synchronization between the upper-layer scheduling state and the underlying physical hardware.

[0057] In some embodiments, based on frame sequence numbers, valid multi-frame messages are assembled into a device feature string, including: accumulating and truncating received valid multi-frame messages according to a preset receive window mechanism to obtain a candidate message set; performing frame sequence number continuity determination and termination frame identification on the candidate message set to ensure the temporal integrity and boundary closure of the accumulated messages; if the continuity determination and termination frame identification are passed, concatenating the payload of the candidate message set according to the frame sequence number to generate a candidate feature string; performing structural verification on the candidate feature string, and if the verification passes, determining the candidate feature string as a device feature string. In actual execution, the system ensures the reliability of multi-frame assembly through the joint determination of four mechanisms: receive window, frame sequence number continuity, termination frame boundary, and structural verification; if any step fails, the currently accumulated data is discarded, and the system reverts to the single-frame query logic of the second query instruction (0x64). Specifically, after the system issues the first query command, it starts the receiving window and closes it to prevent blocking or waiting when the preset total duration (e.g., 200ms) or continuous silent timeout (e.g., 50ms) is reached. Subsequently, the accumulated response frames within the window are deduplicated and sorted by frame number (second byte), verifying whether they meet the timing continuity requirement of starting at 0 and strictly incrementing by 1. Under this premise, the system identifies the last frame based on one of three conditions: the presence of a pre-defined termination sentinel (e.g., 0x00) in the payload, a short frame boundary (payload length less than the previous frame), or silent inference, thus closing the physical boundary. After boundary closure, the system extracts the payloads of each frame, concatenates them into a candidate string, and performs multi-dimensional structural verification: verifying whether it consists entirely of printable ASCII characters, whether the total length meets the standard (e.g., ≥8), whether it is divided into at least 3 segments by hyphens, and whether it successfully hits the aforementioned matching priority sequence. Only when all four conditions are met can the final valid device feature string be output. It is understandable that the above-mentioned assembly integrity verification mechanism has multiple equivalent alternatives. For example, a fixed window can be replaced by an adaptive dynamically extended window, strict incremental judgment can be replaced by disordered reassembly and full-rank verification based on a sequence number bitmap, tail termination frame identification can be replaced by direct identification based on the end-of-message (EOM) marker in the frame header, and structural verification based on character and segmentation patterns can be replaced by cyclic redundancy check (CRC) or vendor-specific communication signatures and other digital-level integrity verification mechanisms. It should be noted that, without departing from the core semantics of this disclosure (i.e., the four mechanisms of time domain window control, frame continuity guarantee, boundary identification, and validity verification combined), regardless of the specific equivalent judgment or verification method used to achieve the complete assembly of multi-frame messages, as long as it can ultimately effectively obtain a device feature string with integrity and parsing legitimacy, it is considered an equivalent alternative falling within the protection scope of this disclosure.

[0058] The following is based on Figure 3 Taking this example, the specific structure and execution steps of the automatic device identification process provided in this embodiment will be described in detail. First stage: Starting point traversal and environment initialization. The process starts by traversing each communication interface (iface) returned by the GET / api / setup / available interface. For each obtained communication interface, the system first executes step S1.1, calling DELETE / api / messages / <iface>The interface clears the corresponding historical message cache to prevent dirty data from interfering with subsequent judgments. Second stage: Multi-frame query and splicing attempt. After clearing the cache, the process proceeds to step S1.2, where the system sends a 0xC0 query frame via the bus. In practice, the system attempts to send instructions to the specified CANID (e.g., querying the right-hand device at ID 0x27 and the left-hand device at ID 0x28). The system collects the multi-frame response messages returned by the bus. These multi-frame messages have a fixed data format: the first byte of each frame is fixed as 0xC0, the second byte represents the frame sequence number, and the remaining bytes are the actual payload fragments. The system sorts and assembles the collected payload fragments according to the frame sequence number to generate a complete model string (e.g., LHT06-01-058-RB-1, LHG20-… or L10-07-… as shown in the example). Third stage: Branch 1 (Yes): Multi-frame splicing successful, string parsing is executed. If assembly is successful, the process proceeds along the "Yes" branch to step S1.4, where priority pattern matching is performed. Specifically, the system follows the principle of "prioritizing specific substrings" for ordered matching: Model L25 prioritizes matching the feature substrings [LHG20, LHT20]; Model L10 prioritizes matching the feature substrings [L10, LHT10]; Model L6 prioritizes matching the feature substrings [L6, LHT06]; Model O7 prioritizes matching the feature substrings [O7, 07]; Model O6 matches the feature substring [O6, 06]. In the above priority sequence, once the first match is found, the main model is immediately returned. Next, the system traces the remaining fields of the string using hyphens (-) as delimiters: for example, by identifying the R / L segment to extract the side parameter; assuming a match with Model L10, if segment 06 is identified, it is determined to be a ball-joint variant; if segment 07 is identified, it is determined to be a worm-gear variant. Branch 2 (No): Multi-frame assembly failure triggers single-frame rollback. If assembly failure occurs, the process rolls back to step S1.3 along the "No" branch, and the system issues a 0x64 single-frame query instruction for degradation protection. The single-frame query adopts an 8-byte fixed byte bit direct reading mechanism. The system directly extracts specific byte bits from the single-frame payload: reads the target byte bit of data[1] to obtain the model code (e.g., 0x0A = L10, 0x07 = O7); reads the target byte bit of data[2] to obtain the variant code (e.g., 0x07 = worm gear, 0x06 = ball joint); reads the target byte bit of data[4] to obtain the hand code (e.g., 0x4C = left hand L, 0x52 = right hand R). Fourth stage: data binding, caching and output.Regardless of whether multi-frame pattern matching or single-frame direct readback is used, after successfully extracting the parameters of each dimension, both branches converge down to step S1.5. In step S1.5, the system binds the current communication interface, device model, hand type, and variant into the device quadruple cache. This cache is configured with a 5-second time-to-live (TTL = 5s) and is actively invalidated when the system performs operations such as saving, deleting, or reloading. The system converts the acquired valid data into a DeviceInfo list for output, which is then retrieved and scheduled by the host system via the GET / api / hand / devices interface. It should be noted that the parameters in the embodiments of the present invention (including device list lifetime of 5 seconds, default inter-frame interval of 300 milliseconds, bridging ready wait time of 10 seconds on Windows platform, bridging ready wait time of 3 seconds on Linux platform, CAN identifiers 0x27 and 0x28, command codes 0xC0 and 0x64, model string examples LHT06-01-058-RB-1, LHT10-…, LHG20-… and LHT20-… etc.) are all typical values ​​for implementation reference and do not constitute a limitation on the scope of protection of the present invention; in specific deployment, they can be uniformly calibrated according to the target hardware and network environment.

[0059] This application also provides a robot control method. The execution subject of this robot control method can be a robot or a functional module or entity within a robot capable of implementing the robot control method. The robot control method provided in this application is illustrated below using a robot as the execution subject as an example. During the research and development process, the inventors discovered that bionic dexterous hands, as key components of humanoid robot end effectors and remote teaching terminals, experience frequent model iterations and significant differences in mechanical structure. Multiple degrees of freedom (e.g., 6 to 20 degrees of freedom) configurations and structural variations often coexist within the same product series, and each model typically has differentiated underlying communication protocol definitions (e.g., independent CAN frame command codes, frame length, and byte definitions). The coexistence of these multiple heterogeneous devices presents significant engineering challenges in upper-level software development, concurrent collaborative control, and field deployment. Related solutions typically involve the upper-level process directly calling the underlying communication interface (e.g., SocketCAN) or being driven by the device manufacturer. In this architecture, upper-level business logic such as motion orchestration and execution is highly coupled with lower-level bus access within the same process. This strong coupling leads to differences in operating system type, kernel version, and hardware drivers, which directly translates into differences in the underlying dependencies of the host computer software, increasing the difficulty of cross-platform software adaptation. Related solutions generally adopt a multi-component discrete deployment model. On-site, it is often necessary to independently install the underlying communication toolchain, language runtime environment, front-end static resources, and various configuration files, relying on manual intervention to complete version alignment and path configuration between components. This deployment mechanism results in numerous on-site dependencies, and the combination of different component versions can easily lead to mismatches, causing the on-site operating environment to deviate from the standard development state, increasing the cost of system delivery and subsequent maintenance. Regarding motion data management in scenarios where multiple models coexist, related technologies often use a single file to carry all data for a single model or a single gesture; when the system performs a save operation, it directly overwrites the existing file with the same name. If motion data from multiple models of devices are recorded alternately within the same system, subsequent save operations will directly overwrite and delete the saved data of other models, making it difficult for the system to adapt to industrial sites with multiple heterogeneous models of devices coexisting, reducing the efficiency of collaborative control of multiple devices.

[0060] After in-depth research, the inventors designed a robot control method, which includes: responding to a first start command, an executable file runs and generates a main control process; the main control process performs differentiated deployment of resource data according to the data type of the resource data, so as to release the communication bridging dependency data in the resource data into a bridging executable file, and launches a communication bridging subprocess based on the bridging executable file; the main control process receives motion orchestration data for the target execution unit, and generates motion control sequences based on the motion orchestration data; according to the device model of the target execution unit, the incremental merging of the motion control sequence is written into the data field corresponding to the device model in the multi-model record file; upon receiving an execution command for the motion control sequence, the main control process sends the motion control sequence to the communication bridging subprocess; and the communication bridging subprocess transmits physical control frames to the target execution unit to control the operation of the target execution unit. According to the robot control method provided in this application, a main control process is generated by running a single executable file, and communication bridge subprocesses are deployed and launched according to the different data types of resource data, simplifying the deployment dependencies of the control software. The main control process centrally converts the action control sequence into physical control frames, and then transmits them physically through the communication bridge subprocesses, decoupling the upper-layer control logic from the lower-layer communication and shielding the differences in the underlying communication drivers. At the same time, according to the device model of the target execution unit, the incremental action control sequence is merged and written into the corresponding data fields in the multi-model record file, avoiding data overwriting when recording across models and improving the compatibility of multi-model heterogeneous execution units in a unified control scenario.

[0061] In some embodiments, the robot includes at least one execution unit. In this embodiment, the robot is configured with an executable file. In some embodiments, the executable file is a single binary file generated by code compilation embedding instructions (such as the / / go:embed instruction in Go), enabling zero-dependency deployment. In this embodiment, Single-Binary Zero-Dependency Deployment refers to a deployment method that completes the distribution and startup of the entire service using only a single executable file, without relying on external runtime and external configuration. The customer site only needs to distribute and execute this single host computer executable file to start the entire service, including the underlying bridging subprocess, web interface, REST interface, and default gesture library, without relying on external operating system language runtime environment and external configuration files. The local REST bridging (CAN Bridge) refers to the bridging service deployed on the same host, shielding the console process from the differences between the underlying SocketCAN or USB-CAN adapters through a local HTTP / JSON interface. " / / go:embed" refers to the compile-time resource embedding directive provided by Go language version 1.16 and above, which can embed files or directories into the final executable file. In other embodiments, the executable file can also be an external compressed archive with a self-extracting archive file, an executable SquashFS file, an AppImage file, or a Microsoft Software Installation Package (MSIX) file. Furthermore, to mitigate the underlying differences between different operating systems, the executable file can also use build tags to isolate platform-specific environment dependencies (such as the superuser privilege check required for operating SocketCAN on Linux platforms) into the main program. In some embodiments, the executable file includes at least one type of resource data. In this embodiment, at least one type of resource data includes communication bridging dependency data (i.e., the underlying CAN bridging executable file). In other embodiments, at least one type of resource data may include, in addition to communication bridging dependency data, front-end static resources, default gesture library, model configuration data, and shortcut key configuration data; the above resource data is embedded as a read-only file system in the executable file, and different deployment strategies are executed according to the physical form of different data and business requirements during program execution.For communication bridging dependency data, namely the underlying CAN bridging executable file, it is specifically adapted and embedded according to the target platform during the build phase. Target platforms include, but are not limited to, Linux amd64, Linux arm64, Windows amd64, Windows arm64, macOS amd64, and macOS arm64. During program execution, this resource data is granted executable permissions and written to disk for execution every time the system starts, thereby ensuring that the binary version of the launched bridging process always matches the main console program, thus converging the dependency differences of the underlying driver in the local environment. As an equivalent implementation replacement for the embedded method, the communication bridging dependency data can also be configured to be managed independently of the executable file, that is, converted into dynamic acquisition logic that triggers network download and performs hash verification during program runtime, or adopted as a binary form distributed in the same package as the executable file in the same directory. In other embodiments, regarding the platform coverage and adaptation scope of the embedded bridging binary file, in addition to the four platforms of Linux amd64, Linux arm64, Windows amd64, and Windows arm64, the embedded bridging binary and platform difference file can be extended to target platforms such as macOS amd64 and macOS arm64 in the same mode, all of which are equivalent implementations of the present invention. For front-end static resources, their data content essentially encapsulates static HTML, CSS, and JavaScript code files, as well as internationalized (i18n) strings for cross-language display. In the service construction phase, this part of the data resource is mounted in memory and exposed to the HTTP routing system to provide access services, thereby realizing the front-end routing mechanism of a single-page application (SPA). This mechanism constitutes a console operation entry point for unified management of multiple heterogeneous devices at the overall architecture level. For the default gesture library, it serves as a ready-to-use initial action configuration dictionary within the system architecture. At the deployment level, the program actively detects the existence of corresponding file paths in the system's working directory upon startup, only executing the disk deployment action if the path is determined to be missing. This nested pre-verification processing logic effectively protects the user's recorded historical gesture data at the physical write level, preventing it from being overwritten and corrupted by default data during software version upgrades. For model configuration data and shortcut key configuration data, these two types of resources are compiled into a pure byte slice physical form within the executable file. During actual invocation, they are configured to completely bypass disk I / O, employing a pure memory deployment strategy that reads and loads directly from memory to drive the real-time conversion of upper-layer logic control values ​​to lower-layer physical communication frames and support shortcut key responses on the console interface.This non-disk loading mechanism cuts off external intervention at the source of data flow, significantly reducing the system risk of core configuration files being maliciously tampered with in the runtime environment. The following example illustrates this. Figure 5 Taking this as an example, the overall system architecture and the interaction process of each module of the present invention will be described in detail. Figure 5 The architecture is clearly illustrated from top to bottom, showing the hierarchical relationship between the Web frontend (i.e., the human-computer interaction interface), the console process (i.e., the main control process, Dashboard Backend), the local REST bridging process (i.e., the communication bridging subprocess, CAN Bridge), and the SocketCAN / USB-CAN adapter and dexterous hand hardware (i.e., the target execution unit), as well as the data flow between the core modules within the console process. At the top of the architecture is the Web frontend (i.e., the human-computer interaction interface, Dashboard UI), which primarily provides users with a visual control and interaction entry point. Internally, it includes a device list display component, a joint control slider interaction component, a gesture library management component, a dance choreography component, a shortcut key mapping management component, and an internationalization (i18n) multilingual switching component. Located in the middle control layer is the console process (i.e., the main control process, Dashboard Backend, generated by running a single binary executable file). This main control process uses the Gin HTTP framework to mount a unified RESTful API route set, namely / api / hand / The routing interfaces prefixed with ` / config` specifically cover interfaces for model configuration retrieval, device identification triggering, gesture data CRUD operations and reloading, action orchestration execution and termination, inter-frame interval configuration, and shortcut mapping. Within the main control process, four core functional modules—device identification, gesture storage, logic control-physical frame conversion, and gesture orchestration execution—work collaboratively, supported by underlying data from the model configuration data (i.e., the `FingerConfig` configuration file) located in memory. The model configuration data specifically includes command codes, frame lengths, byte mapping arrays, and default values ​​for each hardware model and variant, supporting subsequent real-time protocol mapping and assembly. The device identification module is configured to, upon receiving a device identification command, first send a cache clearing request to the bridging subprocess, then issue a multi-frame query with command code 0xC0 or automatically fall back to a single-frame query with command code 0x64. Based on a pattern priority matching rule that prioritizes specific substrings over general substrings, it parses the device quadruple (containing interface name, device model, hand type, and structural variant), and finally stores it in a device list cache with a preset lifespan. The gesture storage module is configured to define a multi-model record file (i.e., a gesture JSON file) containing multiple model variants with parallel first-level keys. Upon receiving an action save command, it executes incremental merging and saving logic that only partially replaces the target device model field, keeping other model data fields unchanged. The logic control-physical frame conversion module loads the aforementioned model configuration data. During runtime, it dynamically assembles the logic control commands input from the upper layer into physical control frames according to the load offset bits, and executes a full-frame empty skip mechanism and a speed frame batch filling mechanism during traversal. The gesture orchestration and execution module is configured to divide the target execution unit into multiple execution groups according to the device model, and allocate independent concurrent execution threads (goroutines) to each execution group. Each thread asynchronously advances the action delivery according to the independent inter-frame interval time corresponding to the device model. At frame boundaries and waiting points, a non-blocking select mechanism is used to listen for the stop command channel (i.e., stopChan) to achieve graceful interruption. After execution, the final physical control frame is reverse-parsed into logical state values ​​and backfilled into the front-end interactive slider. A local REST bridging process (i.e., the communication bridging subprocess CAN Bridge) is deployed in the robot.The bridging child process is bound to the main control process in a parent-child relationship and deployed on the same host. It communicates with the main control process across processes through local HTTP / JSON interfaces (including POST / api / can for sending control frames and GET / api / messages / :iface for reading message caches), thereby shielding the main control process from hardware bus details and completely converging the underlying driver differences within the child process. Below the bridging child process is the hardware abstraction layer, which contains the native SocketCAN interface driver for the Linux operating system and the USB-CAN adapter driver for the Windows operating system, used to convert the requests transmitted from the front end into physical bus signals. The lowest level of the architecture is the dexterous hand hardware (i.e., the target execution unit), which receives control frames and executes action responses via a physical CAN bus with preset identifiers (such as 0x27 for the right hand and 0x28 for the left hand). The dexterous hand hardware device models cover at least the following heterogeneous robot execution units: 6-DOF standard type (O6), 6-DOF L type (L6), 7-DOF type (O7), 10-DOF worm gear variant (L10 Worm Gear), 10-DOF ball joint variant (L10 BallJoint), 20-DOF type (L20), and 25-DOF type (L25).

[0062] like Figure 4 As shown, the robot control method includes steps 410, 420, 430, 440, 450, and 460. Step 410: In response to the first start command, the executable file runs and a main control process is generated; In this step, the first startup command can be a system call triggered by a user double-clicking the executable file icon in the operating system's visual interactive interface at the customer's site; or a program execution command entered by a technician through a local command-line terminal. In other embodiments, the first startup command can also be obtained based on automated triggering mechanisms that do not require manual intervention, such as the operating system's startup configuration script (e.g., a systemd service script or Windows Task Scheduler), execution signals issued by remote automated deployment tools, or fault recovery wake-up events of system daemons. After being allocated system resources and started by the operating system, the main control process (i.e., the console background process) acts as the control and management hub of the entire system. First, it mounts a unified network routing interface (such as a REST API routing set built on the Gin framework) in memory to receive various operation commands from the front-end human-machine interface. Simultaneously, the main control process is responsible for unpacking and deploying various built-in static and dynamic resource data according to preset differentiated strategies, and starting the underlying communication bridge subprocesses. Based on this, the main control process acts as the command forwarding hub, responsible for parsing and assembling the received action control commands, and accurately routing and forwarding them to the communication bridge subprocesses to ultimately drive the underlying target hardware. The executable file is a single host computer software program distributed externally in a single binary form, enabling zero-dependency deployment. At the customer's site, only this single executable file needs to be distributed and executed to start the entire console service, including the communication bridge subprocesses, the human-machine interface, and the back-end interface, without relying on external operating system language runtime environments or discrete configuration files. In some embodiments, the executable file is generated by statically embedding resource data during the compilation phase; during the software building phase, all underlying communication bridging dependency data, configuration files, and front-end static resources required for operation are uniformly packaged and solidified into a single binary executable file. Through the static embedding mechanism described above during the compilation phase, the host computer software of this application is distributed externally as a single executable file, for example, its file extension can be empty or .exe. In practical applications, the customer only needs to deploy and execute this executable file, and the main control process will automatically launch the entire console service, including the communication bridging subprocess, Web interface, REST interface, and default gesture library, after responding to the first startup command. This avoids dependence on external operating system language runtime or discrete configuration files, significantly simplifying the deployment process of the control software.

[0063] Step 420: The main control process performs differentiated deployment of resource data based on its data type to release communication bridging dependency data from the resource data into a bridging executable file, and launches a communication bridging subprocess based on the bridging executable file. In this step, the resource data can include, but is not limited to, various types of data with different purposes, such as communication bridging dependency data, configuration file data, default action library data, and front-end static resource data. Communication bridging dependency data (i.e., canBridgeBinary) is a low-level executable image used for communication translation and protocol bridging between the main control process and the underlying hardware bus driver. It is used to shield the upper-level main control process from hardware bus details and locally converge the logical differences in driver access between different operating systems. In some embodiments, the communication bridging dependency data is embedded specifically for each platform according to the build tag (e.g., supporting multiple target platforms such as Linux amd64, Linux arm64, Windows amd64, and Windows arm64). The aforementioned resource data is statically packaged and solidified into the executable file of the main control process during the software compilation and build phase through compile-time resource embedding instructions, forming a memory byte slice or a read-only file system.

[0064] In actual execution, in order to package and solidify the above-mentioned resource data into the program during the software compilation stage, the console main program statically embeds various resource data into the main binary program during compilation using the following / / go:embed instruction set: / / go:embed web / var webFS embed.FS / / go:embed config / finger_config.json var fingerConfigBytes []byte / / go:embed config / shortcuts.jsonvar shortcutsBytes []byte / / go:embed gestures var gesturesFS embed.FS / / go:embed can-bridge- <os> - <arch>var canBridgeBinary []byte. In some embodiments, the resource data statically embedded within the executable file via compile-time resource embedding instructions includes front-end static resource data, configuration file data, default action library data, and communication bridging dependency data. In this embodiment, each resource data specifically includes, in terms of physical form and application purpose: front-end static resource data (i.e., webFS), including static HTML / CSS / JavaScript files and internationalization (i18n) strings, is embedded in a read-only file system and is used to expose a visual console operation interface to the outside world through HTTP routing; default action library data (i.e., gesturesFS, i.e., default gesture library), which contains a preset action configuration dictionary and initial gesture definition file for heterogeneous devices, is embedded in a read-only file system and is used to provide initial gesture data without additional configuration when the system is initially running or the local path is missing. Configuration file data (i.e., fingerConfigBytes and shortcutsBytes), including model configuration and shortcut key configuration, is embedded as a plain byte slice to drive physical communication frame mapping and console shortcut key responses. Communication bridge dependency data (i.e., canBridgeBinary) is embedded as a binary data slice, used by the main control process to release disk access, configure executable permissions, and start the corresponding communication bridge child process during system startup. It should be noted that the native HTML / CSS / JavaScript frontend in the above frontend implementation process can be replaced with equivalent implementations of modern frameworks such as React, Vue, Svelte, or Solid; the internationalization module can be replaced with the corresponding internationalization library (such as vue-i18n or react-intl). According to the robot control method provided in this application embodiment, by integrating multiple resource data into a single executable file and implementing differentiated deployment, the system deployment process is simplified. For different categories of built-in resources, on-demand expansion, memory loading, and routing fallback strategies are adopted respectively. This ensures system upgrade consistency and interface access stability while effectively preventing the overwriting of existing user data, achieving a balance between convenient deployment and data protection. Furthermore, it enables the universality and reuse of action data across heterogeneous devices, effectively improving cross-device reusability and enhancing system compatibility across multiple heterogeneous execution units in a unified control scenario. In some embodiments, the method further includes: the main control process mounting platform-related functions corresponding to the operating system platform through construction tag files; during the startup phase, the main control process calls platform-related functions to perform communication dependency prerequisite checks for the current operating system. In actual execution, the communication dependency prerequisite checks performed by the main control process for the current operating system are specifically achieved through the build tag file isolation mechanism during the compilation phase.The main control program code is built using Go tags, routing cross-platform processing logic to independent scripts (such as platform_linux.go for Linux systems and platform_other.go for other systems). Each script exposes platform-specific functions with a unified signature (such as the checkPlatformPrerequisites() environment prerequisite check function). In this way, specific environment prerequisite checks, such as the superuser (root) privilege verification required when operating the SocketCAN bus on Linux platforms, are fully internalized into the main program's pre-boot process, enabling the main control process to autonomously complete cross-platform adaptation without relying on external environment configuration scripts.

[0065] In some embodiments, the main control process can also be configured to adopt a differentiated deployment strategy based on the data type of the resource data during program execution, so as to accurately deploy various types of resource data to the corresponding memory space or local path, thereby protecting the user's existing gesture data from being overwritten by the upgrade.

[0066] In some embodiments, step 420 includes: if the resource data includes communication bridging dependency data, extracting and saving the communication bridging dependency data to a local path, and configuring executable permissions to generate a bridging executable file; the main control process starts the bridging executable file to launch the communication bridging subprocess. In actual execution, each time the system starts, the main control process writes the embedded underlying CAN bridging binary data to disk and releases it to a local path using a file write function (such as os.WriteFile(". / can-bridge", data, O755)), and simultaneously configures O755 permissions to generate the bridging executable file; subsequently, the main control process executes the written bridging executable file to launch the communication bridging subprocess, ensuring that the binary files of the console (i.e., the main process) and the communication bridging subprocess always match. By rewriting and executing the binary files each time the system starts, the version of the underlying bridging binary program always matches the console main program, effectively reducing the risk of communication translation problems caused by inconsistencies between old and new versions or missing files.

[0067] In some embodiments, resource data is deployed in a differentiated manner according to the data type of the resource data, including: when the resource data includes configuration file data, loading the configuration file data into memory for the main control process to read initialization parameters; when the resource data includes default action library data and the target action library does not exist locally, unpacking the default action library data to generate the target action library locally; when the resource data includes front-end static resource data, mounting the front-end static resource data to the routing interface, and uniformly redirecting to the homepage file of the front-end static resource data when the route is not hit, so as to provide access services for the operation interface to the outside world through the main control process. In actual execution, the main control process adopts the following differentiated deployment strategies based on the data types of different resource data and business security requirements: For configuration file data (i.e., model configuration data and shortcut key configuration data), the main control process calls configuration parsing functions (such as LoadFingerConfigFromBytes) to directly load the above configuration data from memory for reading initialization parameters. The entire process does not perform any write-to-disk operations. The above memory-loaded configuration strategy effectively reduces the risk of configuration files being tampered with externally. For default action library data (i.e., default gesture library), the main control process adopts an "on-demand extraction" protective strategy. At startup, it actively probes whether the preset local target action library working directory (such as . / config / gestures / ) exists. Only if the working directory does not exist will it unpack and extract the default action library data and write it to the local disk to generate the target action library, thereby effectively avoiding the overwriting of user-recorded historical gesture data due to program restarts or version upgrades. Here, on-demand extraction refers to the strategy of writing embedded resources to disk only when the target path does not exist, and retaining existing user data when it does exist. For front-end static resource data, the main control process retrieves static resource files through subfile system extraction functions (such as fs.Sub(embedFS, "web")) and mounts them to expose the underlying web routing framework (such as the Gin routing framework). In practice, the main control process not only provides direct access to static files through named route interfaces (such as / styles.css, / js / :filename, etc.), but also mounts unified no-route fallback handling logic (such as the NoRoute handler in the Gin framework). When the user's requested route does not match the specific static file, it uniformly redirects the user back to the front-end homepage file (i.e., index.html), thus perfectly supporting the front-end routing mechanism of Single Page Applications (SPAs), and providing access services to the user through a visual interface via the main control process.In actual execution, the master control process employs specific differentiated deployment strategies based on the data types of different resources and business security requirements. See below for reference. Figure 8 This is a single binary startup timing diagram based on / / go:embed, specifically illustrating the time sequence of startup steps such as embedded resource unpacking, port conflict detection, underlying CAN bridge binary disk writing and child process launch, platform readiness waiting, web route mounting, and on-demand expansion of the default gesture library. Combined with... Figure 8 It can be seen that the core strategy of this process is: "Expand the default gesture library as needed + Always override the bridging binary + Load configuration in memory + Front-end resource sub-file system". In actual execution, the main control process integrates multiple external dependencies during compilation. Figure 8 The "embedded resources ( / / go:embed)" shown on the left specifically include: "web / • Front-end HTML / CSS / JS / i18n" (i.e., front-end static resource data); "config / finger_config.json • model configuration" and "config / shortcuts.json • default shortcut keys" (i.e., configuration file data); "gestures / • default gesture library" (i.e., default action library data); and "can-bridge-" compiled in conjunction with "platform_{linux,other}.go • platform difference buildtag". <os> - <arch>• Low-level CAN bridge binary (i.e., communication bridge-dependent data). For example... Figure 8 As shown, the main control process executes step "① Parse command line / Detect port occupancy". In this step, the system calls "net.Listen local bridge port" to detect port occupancy, and its processing logic is "if occupied -> refuse to start". For configuration file data, the main control process executes step "② Load configuration in memory" as indicated by the arrow. In this step, the main control process calls the configuration parsing function (such as "LoadFingerConfigFromBytes") to directly load the above configuration data from memory for reading initialization parameters, and stipulates that the entire process "does not write to disk". This pure memory loading strategy effectively reduces the risk of configuration files being tampered with externally. For default action library data, the main control process executes step "③ Expand default gesture library on demand" as indicated by the arrow. In this step, the main control process adopts a protective strategy of "expand on demand". It actively detects whether the preset local target action library working directory exists when starting up. If it is determined that "the directory exists -> skip", if it is determined that "otherwise -> unpack (protect user data)". This effectively avoids the overwriting of the user's recorded historical gesture data due to program restart or version upgrade, thereby generating the target action library locally. For communication bridging dependent data, the main control process executes step "④ Bridging binary data to disk" and step "⑤ Launching the bridging child process + platform waiting" sequentially according to the arrow. In step ④, each time the main control process starts, it writes the embedded underlying CAN bridging binary data to disk and releases it to the local path through a file write function (specifically, "os.WriteFile(". / can-bridge", O755)"), and simultaneously configures O755 with executable permissions. The purpose is to achieve "version consistency with each overwrite", thereby effectively reducing the risk of communication translation failures caused by inconsistencies between old and new versions or missing files. In step ⑤, the main control process executes the file to disk to launch the communication bridging child process and waits for the platform according to system parameters (i.e., "Linux 3 s • Windows 10 s"). At the same time, it "registers SIGINT / SIGTERM / SIGHUP" signals to take over the lifecycle of the child process. For front-end static resource data, the main control process executes step "⑥ Front-end resource mounting + NoRoute fallback" as indicated by the arrow. In this step, the main control process retrieves the static resource file through the sub-file system extraction function and mounts it to expose it to the underlying Web routing framework. The specific routing chain is shown in the attached diagram as "fs.Sub(webFS) -> Gin NoRoute -> index.html (SPA)". That is, when the main control process does not hit the specific static file, it uniformly redirects it back to the front-end homepage file (i.e., index.html) as a fallback, thus perfectly supporting the front-end routing mechanism of Single Page Application (SPA) and providing access services to the external user interface through the main control process.The main control process executes step "⑦ Enter the main loop" along the downward arrow; at this stage, the system "opens / api / hand / ". The interface allows "Web frontend access" and officially "starts service". It should be noted that in some other embodiments, / / go:embed in the above single binary deployment process can be replaced with an external compressed package plus self-extracting archive, executable SquashFS, AppImage, or Microsoft Software Installer Package (MSIX); the embedded bridging binary can be replaced with runtime download and hash verification, or distributed in the same directory as the console main program in the same package binary form, and this application does not limit this.

[0068] In some embodiments, step 420 includes: after the main control process is generated, detecting and obtaining the occupancy status of a preset local bridging port; if the local bridging port is occupied, refusing to launch the communication bridging child process and outputting a port conflict warning; if the local bridging port is not occupied, releasing the communication bridging dependency data into a bridging executable file and launching the communication bridging child process. In actual execution, the communication bridging child process (i.e., the local REST bridging process) and the main control process (i.e., the console process) are deployed together on the same physical host in a parent-child relationship. To ensure the exclusivity of underlying bus resources and the stability of inter-process communication, the main control process performs strict bridge process uniqueness detection and platform readiness waiting mechanisms. During the startup phase, the main control process actively detects whether the preset local bridging port is occupied through a network listening function (specifically, net.Listen). If the detection result indicates that the port is already occupied, the main control process will directly refuse to start the child process and output a port conflict warning. This uniqueness detection mechanism can absolutely guarantee that only one active bridge child process exists on the current host system, thereby effectively avoiding communication conflicts or device deadlocks caused by multiple processes simultaneously competing for the same underlying CAN bus resources. If the detection result indicates that the local bridge port is not occupied, the main control process will release the pre-statically embedded communication bridge dependency binary data to disk as an executable file and officially start the communication bridge child process (specifically, the can-bridge child process). After successfully starting the child process, the main control process will not immediately send out business data, but will execute a targeted ready-to-wait strategy based on the different characteristics of the current operating system platform; for example, in some specific embodiments, the main control process will suspend and wait for 10 seconds on the Windows platform, while it will suspend and wait for 3 seconds on the Linux platform. By employing the aforementioned ready-to-wait mechanism tailored to platform characteristics, it is ensured that the communication bridging subprocess has completed the initialization and readiness of hardware interface mapping and network listening at the operating system level before receiving subsequent action control commands. According to the robot control method provided in this application, a three-layer decoupled system architecture consisting of a console, a local communication bridge, and a communication hardware adapter is constructed. A local port conflict detection mechanism ensures the unique running state of the bridging subprocess, effectively avoiding communication conflicts and system deadlocks caused by multiple processes competing for underlying bus resources. The local communication interface shields the underlying driver differences of different hardware adapters, achieving complete decoupling between upper-layer business logic and underlying driver details. Differentiated ready-to-wait strategies for different operating systems improve the reliability of the bridging subprocess during the underlying interface initialization phase, thereby enhancing the operational reliability of the robot in complex operating environments and improving the compatibility of multiple heterogeneous execution units in a unified control scenario.In some embodiments, after launching the communication bridge child process, the method further includes: the main control process registering a listening mechanism for system signals with the operating system; and, in the event that the main control process triggers an exit procedure, the main control process sending a termination signal to the communication bridge child process based on a semaphore-based propagation mechanism to perform safe exit management on the communication bridge child process. In actual execution, to achieve semaphore-based propagation and orphan process protection, the main control process, after successfully launching the communication bridge child process, will proactively register a listening and handling mechanism for critical interrupt signals (specifically, system signals such as SIGINT, SIGTERM, and SIGHUP) with the operating system. When the main control process triggers its exit procedure due to user-forced termination, system restart, or abnormal conditions, it actively sends a corresponding termination signal (such as a SIGTERM signal) to the resident communication bridge child process through the signal transmission mechanism between parent and child processes. This notifies the communication bridge child process to safely release the underlying bus and perform a safe exit. Simultaneously, to improve the reliability of process exit, the main control process also calls forced termination logic (such as a Kill operation) before exiting, ensuring the effective destruction of the communication bridge child process. According to the robot control method provided in this application, the main control process, through a registered system signal listening mechanism, uses signal linkage propagation to notify the bridge child process to safely release resources when the exit procedure is triggered. This, coupled with fallback forced destruction logic, effectively avoids the generation of orphan processes, thereby improving the safety and reliability of the multi-process system during exit or abnormal interruption. Step 430: The main control process receives motion orchestration data for the target execution unit and generates a motion control sequence based on the motion orchestration data. In this step, the target execution unit refers to the hardware execution carrier connected to the robot communication bus and currently under control, including but not limited to various models of bionic dexterous hands with different degrees of freedom configurations, as well as independently controlled single-finger components and drive joints. Motion orchestration data refers to motion control request data sent by the front-end human-machine interface or the upper-level control terminal, which includes the target device's device identifier, gesture name sequence, frame interval time, and playback control parameters, etc. The motion control sequence refers to the continuous combination of actions to be performed by the target execution unit within a certain period of time. In terms of actual data composition, the motion control sequence is essentially a sequence of motion data composed of a set of gestures with frame numbers combined in time. Among them, a gesture refers to the fixed position state of each joint of the target execution unit at a specific point in time (its actual motion performance is, for example, the frozen action of the bionic dexterous hand when it is "clenching a fist" or making "numbers 1 to 9").At the data processing and storage level, gestures are specifically represented as a set of multiple physical control frames (such as CAN data frames, RS485 communication frames, EtherCAT messages, or Modbus data frames, etc., underlying industrial communication messages) corresponding to a single static posture, and are uniformly stored as structured data formats such as JSON format files, binary JSON (BSON), MessagePack, Protocol Buffers, or SQLite single-file databases. In some embodiments, step 430 includes: the master control process receiving an orchestration request for the target execution unit, containing a sequence of gesture names and inter-frame intervals, via a preset orchestration execution routing interface; the master control process reading the corresponding multi-model record file based on the device model of the target execution unit; the master control process retrieving the logical control instructions corresponding to each gesture name from the multi-model record file in the order of the gesture name sequence, and assembling them to generate an action control sequence consisting of multiple action control frames. In actual execution, the master control process receives JSON format orchestration request messages sent from the front end through the mounted REST API orchestration execution routing interface (specifically the / api / hand / exec interface). The message encapsulates specific parameters such as the target device's identification information (e.g., device model O6, L6, or L10_WormGear and hand type right or left), gesture name slices (e.g., ["fist", "open", "victory"]), inter-frame interval time (interval_ms), and loop count (loop_count). Upon receiving this request, the master control process first verifies the communication status of the target execution unit, then reads the gesture JSON record file (gestures.json) stored in the working directory. The master control process iterates through the gesture name slices, matching the joint angles and control semantic values ​​corresponding to each gesture name under the target device model field in gestures.json. These logical control values ​​are then assembled sequentially along the timeline into an action control sequence composed of ordered action control frames (i.e., frame data containing logical control instructions). This sequence serves as the data basis for subsequent communication protocol mapping and asynchronous physical frame distribution.

[0069] Step 440: Based on the device model of the target execution unit, incrementally merge and write the motion control sequence into the data field corresponding to the device model in the multi-model record file. In this step, incremental merging and writing refers to an incremental update mechanism that, when persistently saving gesture or motion data for a specific device model, only partially updates or replaces the data node corresponding to the target device model, while keeping the data nodes corresponding to other device models in the multi-model record file completely unaffected. The multi-model record file refers to a data record file (specifically, a gesture definition file in JSON format) that is preset in the local working directory and centrally saves motion data of multiple heterogeneous device models and structural variations in the same physical file. In some embodiments, step 440 includes: receiving a save instruction for the motion control sequence; in response to the save instruction, obtaining the motion control sequence and the target device model corresponding to the target execution unit; reading the multi-model record file corresponding to the motion control sequence; and incrementally merging and writing the motion control sequence into the target data field corresponding to the target device model in the multi-model record file based on the target device model, so as to keep the data in the data fields of other models in the multi-model record file unchanged. In this embodiment, the multi-model record file contains multiple parallel model data fields, each corresponding to a different execution unit. The instruction to save the action control sequence is a network communication message (specifically, an HTTP POST save request based on a RESTful architecture) or an internal system call signal, triggered by the user after recording or editing the action on the front-end visual interface. This message requests the persistence of the action data in current memory to disk. The data packet of this instruction carries the action control logic value to be saved, the target action name, and the selected target hardware range. The target device model is a unique identifier representing the specific physical hardware and its mechanical structure variants applicable to the current action control sequence. It is used to accurately locate and address the target primary key node to be written incremental data in the multi-model record file. The multi-model record file stores control sequence data with the same action name on different hardware models and variants in a single persistent file, with each model data field maintaining strict independence in both physical structure and logical read / write operations. In actual execution, the gesture storage module executing the above logic is deployed within the main control process (i.e., the console process). To achieve the independence and coexistence of multi-model action data, refer to... Figure 6 This is a diagram illustrating a unified JSON storage format for gestures with multiple parallel fields. For example... Figure 6 As shown, the main control process defines a single gesture file (i.e., a multi-model log file) as a unified storage structure in the following JSON format. This structure specifically shows the parallel field structure of the seven model variant keys: O6, L6, O7, L10_WormGear, L10_BallJoint, L20, and L25, as well as the organization of the CAN frame arrays corresponding to each model key: "{ "name": "<gesture name>", "O6":["<base64 frame 1> The master control process uses a parallel field structure of "model key - CAN frame array" to aggregate and save CAN frame data (i.e., action control sequences) of the same action on different models into the same file; for example, the two structural variants under the L10 model, L10_WormGear and L10_BallJoint, are saved in parallel with independent fields and do not overwrite each other. In other embodiments, the storage format of the multi-model record file is not limited to JSON, and can also be equivalently replaced by structured storage carriers such as binary JSON (BSON), MessagePack, Protocol Buffers, or SQLite single-file database. In specific implementations, the parallel fields for multiple models can be equivalently replaced by an embedded dictionary structure that maps device models to control frames (specifically, model_key -> frames); the underlying data of the action control sequence can also be equivalently replaced by a Base64 string with a hexadecimal string or raw binary data. As long as the above storage format can maintain the two core semantics of "multiple model data coexisting in the same object" and "supporting local incremental merging and saving", it should be considered an equivalent alternative within the scope of protection of this application. In some embodiments, based on the target device model, the incremental merging of the action control sequence is written into the target data field corresponding to the target device model in the multi-model record file, including: obtaining an action save request containing the target device model and the action data to be saved; reading the multi-model record file corresponding to the action save request, and creating an initial data object in memory if the multi-model record file does not exist; writing the action data into the target data field corresponding to the target device model in the multi-model record file, while keeping other model data fields in the record file unchanged; and persisting the updated multi-model record file to disk. In actual execution, refer to Figure 7 This is an incremental merge and save timing diagram, specifically illustrating the timing relationship of steps such as the arrival of the save request, reading the disk file with the same name, replacing only the model field involved in the current request, keeping the remaining fields unchanged, and the linkage between disk writing and memory cache. It also shows the field accumulation process of the same gesture file in three cross-model supplementary recording processes. For example... Figure 7 As shown, the gesture storage module in the main control process receives a save request (e.g., SaveGestureRequest) containing the current target device model and variant identifiers (targets), the logical control values ​​(values) involved in this edit, and an optional multi-frame sequence (sequence). Before writing to disk, the gesture storage module first reads the gesture definition file with the same name from the disk and deserializes it into an in-memory data object (e.g., a GestureData object); if the file does not exist on the disk, an empty GestureData object is created in memory. Subsequently, the gesture storage module calls the data update interface (e.g., SetFrames(modelKey, frames)), only writing the target device model field involved in this save request to the corresponding data node, while keeping the original disk values ​​of other unrelated device model fields in the file completely unchanged. Finally, the merged data result is persistently written back through a disk write operation. For dance choreography files containing multi-frame motion sequences, refer to... Figure 7 The data is uniformly described and stored as a sequence object containing action names and frame number mappings (specific structure such as { name, sequence: { "1": GestureData, "2": GestureData, ...}}). Each frame key in the sequence is attached to a GestureData object containing multiple model fields. When saving the dance file, the main control process executes the above-mentioned merging and saving logic frame by frame, that is, the model fields within each frame that have not been modified or involved in this request are also retained as is, thereby realizing the incremental merging and saving of multi-frame composite dance files frame by frame. It should be noted that in some other embodiments, for the incremental merging and saving operation of action data, the above-mentioned merging logic of "reading, partially replacing the target model field and persisting it to disk" can also be equivalently replaced by a version number-based Compare-And-Swap (CAS) concurrent safety mechanism, or a differential patch file merging method. As long as the above mechanism can ensure that other data fields corresponding to non-target device models in the multi-model record file are not overwritten or lost during the update process, it should be considered an equivalent alternative within the scope of protection of this application. In some embodiments, the method further includes: performing character filtering and cleaning on the action name string in the action save request before reading or creating the multi-model record file; and synchronously refreshing the action data cache in memory after persisting the updated multi-model record file to disk. In actual execution, in order to ensure disk writing security and prevent unauthorized path traversal, the gesture storage module performs filename sanitization after receiving the gesture name or dance name string input by the user. By filtering illegal characters from the input name string, characters containing / , \, :, etc. are removed. Nine preset system-reserved characters, including 、, ?, ", <, >, and |, are uniformly replaced with safe characters, effectively avoiding the risks of malicious cross-directory traversal and unauthorized disk writing. For the synchronous refresh of motion data cache, the main control process implements a synchronous linkage mechanism between the cache and the persistent layer. After a successful disk write operation, the gesture storage module immediately refreshes the gesture data cache and dance data cache residing in memory. Therefore, when the system subsequently responds to read-only query requests for relevant motion data, it can directly and accurately retrieve the data from the memory cache without triggering disk I / O again. The disk reading operation significantly improves the response efficiency and concurrent processing performance of the console system. According to the robot control method provided in this application, by organizing control frame arrays of multiple model variant keys in parallel, control frames for the same action on all models are aggregated into a single gesture file, thus solving the defects of full file overwriting and scattered storage by model, and realizing cross-model reuse of the gesture library. By adopting the incremental merging semantics of "reading disk—replacing only the model field involved in this instance—writing disk," a progressive cross-model recording process of "recording on one model first, then supplementing recording on another model, and finally both coexisting in the same file" is supported. This ensures that existing data of other models is not discarded when supplementing recording on any model, thereby improving the system compatibility of multi-model heterogeneous execution units in a unified control scenario, and the cross-device reuse rate of action data. Furthermore, those skilled in the art should understand that the method of this embodiment is not limited to the control of dexterous hands, but is applicable to any engineering scenario where "multiple heterogeneous devices share the same host computer control software," including but not limited to multi-model dexterous hands, multi-model robotic arm end effectors, multi-model bionic torsos, and multiple... Model mobile chassis. The mechanism of converting logical control instructions into physical control frames based on model configuration in the aforementioned embodiments (i.e., embodying the semantics of "model configuration-driven physical frame generation"), and the mechanism of aggregating control frames based on multiple model variant keys and saving them through local field replacement (i.e., embodying the semantics of "incremental merging and storage of parallel fields of multiple models"), are essentially decoupling of the underlying heterogeneous communication protocols and unifying the data structures of multiple models. Therefore, the above two core processing logics do not depend on the specific mechanical structure of the dexterous hand and can be directly reused for various extended scenarios such as robotic arms and bionic torsos mentioned above, thereby achieving unified storage and concurrent orchestration control across device forms. Step 450: Upon receiving an execution instruction for the action control sequence, the main control process converts the action control sequence into a physical control frame and sends the physical control frame to the communication bridge subprocess; in this step, the execution instruction for the action control sequence is usually triggered by the user through the front-end visual operation interface (e.g., clicking a specific action playback control) or generated through preset shortcut key mapping, used to request the system to drive the underlying hardware to execute the corresponding physical action.In actual execution, the main control process includes a logic control-physical frame conversion module. This module generates physical CAN frames for each model based on a model configuration that describes the command codes, frame lengths, byte mappings, and default values ​​for each model. Specifically, the program loads the model configuration in JSON format, which describes several frame configurations at the model level. When assembling frame by frame according to the target device, a byte array frameData of length frame.Length is allocated, and the first byte is set to frame.CommandCode. The byte mapping array of the frame is traversed, and the current value is found according to the logic control identifier. If no value is set, the default value is taken, and the result is written to frameData[ByteIndex + 1]. The conversion module packages the physical frame sequence of each target device into a CanMessage{interface, id, data} triple, and combines it with an independent inter-frame interval maintained by a subset of each model variant. This is then sent to the hardware by the communication bridge subprocess via HTTP / JSON (using POST / api / can to send CAN frames). In some embodiments, a unified HTTP / JSON interface mechanism is established between the master process and the communication bridge subprocess for inter-process communication. In this embodiment, the communication between the two is primarily conducted via HTTP / JSON. Specific interface configurations include, but are not limited to: sending CAN frames via POST requests (e.g., / api / can), reading the message cache via GET requests (e.g., / api / messages / :iface), clearing the message cache via DELETE requests (e.g., / api / messages / :iface), and querying available interfaces via GET requests (e.g., / api / setup / available). Through this interface mechanism, the underlying communication differences between different hardware adapters (e.g., SocketCAN and USB-CAN adapters) are encapsulated and isolated within the communication bridge subprocess, allowing the master process to remain unaware of the specific details of the CAN bus.

[0070] In other embodiments, the HTTP / JSON communication method in the REST bridging described above can be replaced with gRPC, WebSocket, shared memory, Unix domain sockets, or Windows named pipes; JSON encoding can be replaced with MessagePack-RPC or Concise Binary Object Representation (CBOR), as long as the console process (i.e., the main process) and the bridging process (i.e., the communication bridging child process) are decoupled using local inter-process communication methods. In some embodiments, in order to provide a unified Web console service to the outside world, the main control process exposes a preset prefix (e.g., / api / hand / ) under the underlying routing framework (specifically, the Gin routing framework). A unified set of REST interfaces.

[0071] In this embodiment, the REST interface set includes at least: interfaces for returning model configuration (such as GET / api / hand / config), interfaces for triggering device identification mechanisms (such as GET / api / hand / devices), a group of interfaces for CRUD operations on gesture data (such as GET / api / hand / gestures, POST / api / hand / gestures / save, DELETE / api / hand / gestures / :name and POST / api / hand / gestures / reload corresponding to read, save, delete and reload), interfaces for real-time joint control and speed control (such as POST / api / hand / joint / logical and POST / api / hand / speed), interfaces for execution, orchestration and stop control of action sequences (such as POST / api / hand / exec distinguished by the three states of the mode field), interfaces for global and model-specific inter-frame interval configuration (such as GET and POST / api / hand / interval), and interfaces for shortcut key mapping management (such as GET, POST and DELETE / api / hand / shortcuts). In other embodiments, the specific implementation architecture of the shortcut key module is not limited to centralized management by the main control process combined with the backend interface. It can also be equivalently replaced by using an operating system-level global hotkey library (e.g., calling the underlying system hook mechanism) to capture and respond to global shortcut keys, or by a pure frontend implementation based on browser page keydown event listening. As long as the above implementation can maintain the association mapping and trigger response semantics between the action control sequence and the preset shortcut keys, they should all be considered equivalent alternatives within the scope of protection of this application.

[0072] In some embodiments, the main control process is also configured with a cache invalidation consistency mechanism. During actual execution, the system caches data such as the device list for a preset lifespan (e.g., 5 seconds). When the system receives and performs data change operations such as save, delete, and reload, it will actively trigger and invalidate the relevant cache, thereby ensuring that the view state of the front-end interface and the data of the back-end persistent layer remain highly consistent, thus achieving data state synchronization. In some embodiments, step 450 includes: in the main control process, obtaining the corresponding communication protocol configuration information and inter-frame interval time according to the device model of the target execution unit; the main control process extracts the logical control instructions from the action control sequence based on the communication protocol configuration information and assembles the logical control instructions into physical control frames; the main control process sends the physical control frames to the communication bridge subprocess through the inter-process communication channel based on the inter-frame interval time. In this embodiment, the communication protocol configuration information refers to the model configuration (FingerConfig) used to describe the underlying communication format of the target execution unit. In some embodiments, the communication protocol configuration information includes command code, frame length, and a data mapping set consisting of at least one logical control identifier and a payload offset bit. In this embodiment, the definitions of communication protocol configuration information and inter-frame interval time have been explained in detail above and will not be repeated here.

[0073] Step 460: Transmit physical control frames to the target execution unit based on the communication bridge subprocess to control the operation of the target execution unit. In this step, based on the aforementioned three-layer architecture of "main control process - communication bridge subprocess - communication hardware adapter", the communication bridge subprocess, as the local bridging layer, is responsible for receiving physical control frames sent by the main control process in HTTP / JSON format, and calling the matching underlying communication hardware adapter (such as SocketCAN or USB-CAN adapter) to transmit the physical control frames to the target execution unit. By setting up the communication bridge subprocess, all differences in underlying communication drivers are completely converged within the communication bridge subprocess. This mechanism allows the upper-layer main control process to issue actions without being aware of the specific CAN details at the lower layer, thereby achieving decoupling between the upper-layer business logic and the lower-layer hardware driver.

[0074] In some embodiments, step 460 includes: a communication bridging subprocess receiving a physical control frame; the communication bridging subprocess, based on a local communication interface, shields the underlying driver differences between different communication hardware adapters and sends the physical control frame to the corresponding target execution unit. In this embodiment, the local communication interface refers to the HTTP / JSON communication boundary deployed on the same host. The underlying driver differences mainly refer to the differences in calling methods between different operating system platforms and underlying communication controllers (e.g., the SocketCAN interface on the Linux platform and the independent USB-CAN adapter driver on the Windows platform). In actual execution, the communication bridging subprocess listens to the aforementioned local communication interface and receives the physical control frame (i.e., the physical CAN frame) carried by the request initiated by the main control process (e.g., a POST / api / can request). After receiving the frame, the communication bridging subprocess automatically selects and calls the matching communication hardware adapter interface based on the current host's operating environment within the program. Subsequently, the communication bridging subprocess accurately transmits the physical control frame to the corresponding bus port based on the pre-agreed controller area network identifier of the target hardware (e.g., 0x27 for the right-hand device and 0x28 for the left-hand device in this embodiment), thereby completing the physical action delivery to the target execution unit. By converging the differences in the underlying hardware within itself through the communication bridging subprocess, the main control process is unaware of the details of the underlying controller area network.

[0075] In one specific embodiment, the method is applied to a unified console product form for multiple dexterous hand models. The console's front-end uses native HTML / CSS / JavaScript to maintain a lightweight design, while the back-end (i.e., the background program that generates the main control process) uses Go and incorporates gin-gonic / gin as the HTTP routing framework, BurntSushi / toml as the configuration parsing library, and jessevdk / go-flags as the command-line argument parsing library. The target execution unit models supported in this embodiment include at least: 6-DOF O6 and L6; 7-DOF O7; 10-DOF L10 (including worm gear and ball joint structural variants); 20-DOF L20; and 25-DOF L25. In this embodiment, the controller LAN identifier used for low-level communication is conventionally set as follows: 0x27 for right-handed devices and 0x28 for left-handed devices. The typical workflow of the embodiment is as follows: After the console program starts, the main control process automatically launches the embedded CAN bridge subprocess (i.e., the communication bridge subprocess); the user clicks "Refresh Device" in the web interface to trigger a GET / api / hand / devices request. The device identification module in the main control process performs identification on each available local communication interface and returns a list of device quadruplets containing the interface, model, hand type, and structural variant; after the user selects the target device, they can slide the logic control slider in the joint control interface to generate action semantics (logic.thumb, swing.index_swing, etc. logic control instructions). Based on the preloaded model configuration information, the main control process converts the logic control instructions into physical CAN frames (i.e., physical control frames) corresponding to each model and transmits them via HTTP / JSON. Inter-process communication is used to send signals in real time to the communication bridge subprocess, which then transmits them to the underlying hardware for execution. When the user clicks "Save Gesture," the gesture storage module in the main control process performs incremental merging and saving (i.e., before writing to disk, it reads the disk's corresponding record file, writes only the action control sequence to the data field corresponding to the currently involved model, and keeps the fields of other models unchanged). When the user switches to the "Dance" tab to choreograph a multi-frame sequence and clicks "Execute," the gesture choreography execution module in the main control process groups and concurrently sends signals according to the model of the target device. The main control process maintains an independent inter-frame interval for each model to execute the choreography task (i.e., sends the assembled physical control frames to the subprocess in sequence), and after the task is completed, it reverse-parses the final state logic value and fills it back into the front slider. The entire service is distributed externally in a single binary form (i.e., a single executable file) and achieves zero-dependency deployment. It should be noted that the robot control method of this application is not limited to a specific programming language and framework; Go language and gin-gonic / gin framework are typical choices for ease of implementation.In scenarios requiring lower latency or smaller memory footprint, the core module can be rewritten in C, C++, or Rust. The robot control method provided in this application can be executed by a robot control device. This application uses the example of a robot control device executing the robot control method to illustrate the robot control device provided in this application. This application also provides a robot control device. It should be noted that the robot provided in the foregoing embodiments may also include the robot control device provided in any of the embodiments of this application. The robot control device is electrically connected to multiple execution units in the robot.

[0076] like Figure 9 As shown, the robot control device includes: a first processing module 910, a second processing module 920, a third processing module 930, a fourth processing module 940, a fifth processing module 950, and a sixth processing module 960.

[0077] The first processing module 910 is used to respond to the first startup command, run the executable file, and generate a main control process; the second processing module 920 is used for the main control process to perform differentiated deployment of resource data according to the data type of the resource data, so as to release the communication bridging dependency data in the resource data into a bridging executable file, and start a communication bridging subprocess based on the bridging executable file; the third processing module 930 is used for the main control process to receive action orchestration data for the target execution unit and generate an action control sequence based on the action orchestration data; the fourth processing module 940 is used to merge the incremental action control sequence into the data field corresponding to the device model in the multi-model record file according to the device model of the target execution unit; the fifth processing module 950 is used for the main control process to convert the action control sequence into a physical control frame when an execution command for the action control sequence is received, and send the physical control frame to the communication bridging subprocess; the sixth processing module 960 is used to transmit the physical control frame to the target execution unit based on the communication bridging subprocess to control the operation of the target execution unit.

[0078] According to the robot control device provided in this application embodiment, a main control process is generated by running a single executable file, and communication bridge subprocesses are deployed and launched according to the different data types of resource data, simplifying the deployment dependency of the control software. The main control process centrally converts the action control sequence into physical control frames, and then transmits them physically through the communication bridge subprocesses, decoupling the upper-layer control logic from the lower-layer communication and shielding the differences in the underlying communication drivers. At the same time, according to the device model of the target execution unit, the incremental action control sequence is merged and written into the corresponding data fields in the multi-model record file, avoiding data overwriting when recording across models, thereby effectively improving the system compatibility of multi-model heterogeneous execution units in a unified control scenario, as well as the cross-device reuse rate of action data.

[0079] In some embodiments, the second processing module 920 may also be used to: extract and save the communication bridging dependency data to a local path when the resource data includes communication bridging dependency data, and configure executable permissions to generate a bridging executable file. The main control process then starts the bridging executable file to launch the communication bridging subprocess.

[0080] In some embodiments, the second processing module 920 can also be used to: load the configuration file data into memory when the resource data includes configuration file data, so that the main control process can read the initialization parameters; unpack the default action library data when the resource data includes default action library data and the target action library does not exist locally, so as to generate the target action library locally; and mount the front-end static resource data to the routing interface when the resource data includes front-end static resource data, and uniformly redirect to the homepage file of the front-end static resource data when the route is not hit, so as to provide access services for the operation interface to the outside world through the main control process.

[0081] In some embodiments, the fourth processing module 940 may also be used to: receive a save instruction for the action control sequence; in response to the save instruction, obtain the action control sequence and the target device model corresponding to the target execution unit; read a multi-model record file corresponding to the action control sequence; the multi-model record file contains multiple parallel model data fields, each model data field corresponding to each execution unit; based on the target device model, merge the action control sequence increment into the target data field corresponding to the target device model in the multi-model record file, so as to keep the data in other model data fields in the multi-model record file unchanged.

[0082] In some embodiments, the second processing module 920 can also be used to: after the main control process is generated, detect and obtain the occupancy status of a preset local bridging port; if the local bridging port is occupied, refuse to start the communication bridging subprocess and output a port conflict prompt; if the local bridging port is not occupied, release the communication bridging dependency data into a bridging executable file and start the communication bridging subprocess.

[0083] In some embodiments, the sixth processing module 960 can also be used to: in the main control process, obtain the corresponding communication protocol configuration information and inter-frame interval time according to the device model of the target execution unit; the main control process extracts the logical control instructions in the action control sequence based on the communication protocol configuration information, and assembles the logical control instructions into physical control frames; the main control process sends the physical control frames to the communication bridge subprocess through the inter-process communication channel based on the inter-frame interval time.

[0084] In some embodiments, the sixth processing module 960 can also be used to: receive physical control frames by a communication bridging subprocess; the communication bridging subprocess, based on the local communication interface, shields the underlying driver differences of different communication hardware adapters and sends the physical control frames to the corresponding target execution unit.

[0085] The robot control device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the specific devices. The robot control device in this application embodiment can be a device with an operating system. The operating system can be Android, iOS, or other possible operating systems, this application embodiment does not specifically limit the specific devices. The robot control device provided in this application embodiment can achieve… Figures 1 to 8 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0086] In some embodiments, such as Figure 10 As shown, this application embodiment also provides an electronic device 1000, including a processor 1001, a memory 1002, and a computer program stored in the memory 1002 and executable on the processor 1001. When the program is executed by the processor 1001, it implements the various processes of the robot control method embodiment described above and achieves the same technical effect. To avoid repetition, it will not be described again here. It should be noted that the electronic device in this application embodiment includes the mobile electronic device and non-mobile electronic device described above. This application embodiment also provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by the processor, it implements the various processes of the robot control method embodiment described above and achieves the same technical effect. To avoid repetition, it will not be described again here. The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes a computer-readable storage medium, such as a computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. This application embodiment also provides a computer program product, including a computer program. When the computer program is executed by the processor, it implements the robot control method described above. The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. This application also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-described robot control method embodiments, achieving the same technical effects. To avoid repetition, it will not be described again here. It should be understood that the chip mentioned in this application embodiment can also be called a system-on-a-chip (SoC), system-on-a-chip (SoC), chip system, or system-on-a-chip (SoC), etc. It should be noted that in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatus in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. In addition, features described with reference to certain examples may be combined in other examples.

[0087] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application. The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art, under the guidance of this application, can make many other forms without departing from the spirit and scope of protection of the claims, all of which fall within the protection scope of this application. In the description of this specification, references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.< / arch> < / os> < / arch> < / os> < / iface> < / iface>

Claims

1. A robot control method, characterized in that, The robot includes at least one execution unit, and the robot is configured with an executable file; the executable file includes at least one type of resource data; the method includes: In response to the first startup command, the executable file runs and generates a main control process; The main control process performs differentiated deployment of the resource data according to the data type of the resource data, so as to release the communication bridging dependency data in the resource data into a bridging executable file, and start the communication bridging subprocess based on the bridging executable file; The master control process receives action orchestration data for the target execution unit and generates an action control sequence based on the action orchestration data; Based on the device model of the target execution unit, the incremental motion control sequence is merged and written into the data field corresponding to the device model in the multi-model record file; Upon receiving an execution instruction for the action control sequence, the main control process converts the action control sequence into a physical control frame and sends the physical control frame to the communication bridge subprocess. The physical control frame is transmitted to the target execution unit based on the communication bridge subprocess to control the operation of the target execution unit; The main control process performs differentiated deployment of the resource data based on the data type, including: If the resource data includes configuration file data, the configuration file data is loaded into memory so that the main control process can read the initialization parameters; If the resource data includes default action library data and the target action library does not exist locally, the default action library data is unpacked to generate the target action library locally. When the resource data includes front-end static resource data, the front-end static resource data is mounted to the routing interface, and when the route is not hit, it is uniformly redirected to the homepage file of the front-end static resource data, so as to provide access services for the operation interface to the outside world through the main control process.

2. The robot control method according to claim 1, characterized in that, The main control process performs differentiated deployment of the resource data according to the data type of the resource data, so as to release the communication bridging dependency data in the resource data into a bridging executable file, and launch a communication bridging subprocess based on the bridging executable file, including: If the resource data includes communication bridging dependency data, the communication bridging dependency data is extracted and saved to a local path, and executable permissions are configured to generate the bridging executable file; The main control process starts the bridging executable file to launch the communication bridging subprocess.

3. The robot control method according to claim 1 or 2, characterized in that, The step of merging the incremental motion control sequence into the field corresponding to the device model in the multi-model record file according to the device model of the target execution unit includes: Receive a command to save the action control sequence; In response to the save command, the action control sequence and the target device model corresponding to the target execution unit are obtained; Read the multi-model record file corresponding to the action control sequence; the multi-model record file contains multiple parallel model data fields, each of which corresponds to a specific execution unit; Based on the target device model, the incremental motion control sequence is merged and written into the target data field corresponding to the target device model in the multi-model record file, so as to keep the data in other model data fields in the multi-model record file unchanged.

4. The robot control method according to claim 1 or 2, characterized in that, The step of releasing the communication bridging dependency data in the resource data into a bridging executable file, and launching a communication bridging subprocess based on the bridging executable file, includes: After the main control process is generated, the occupancy status of the preset local bridging port is detected and obtained; If the local bridging port is already in use, refuse to start the communication bridging subprocess and output a port conflict warning; If the local bridging port is not occupied, the communication bridging dependency data is released as the bridging executable file, and the communication bridging subprocess is started.

5. The robot control method according to claim 1 or 2, characterized in that, The step of the main control process converting the action control sequence into a physical control frame and sending the physical control frame to the communication bridge subprocess includes: In the main control process, the corresponding communication protocol configuration information and inter-frame interval time are obtained according to the device model of the target execution unit; Based on the communication protocol configuration information, the main control process extracts the logical control instructions from the action control sequence and assembles the logical control instructions into physical control frames. Based on the inter-frame interval, the master control process sends the physical control frame to the communication bridge subprocess through the inter-process communication channel.

6. The robot control method according to claim 1 or 2, characterized in that, The step of transmitting the physical control frame to the target execution unit based on the communication bridge subprocess to control the operation of the target execution unit includes: The physical control frame is received by the communication bridge subprocess; The communication bridging subprocess, based on the local communication interface, shields the underlying driver differences of different communication hardware adapters and sends the physical control frame to the corresponding target execution unit.

7. A robot control device, characterized in that, The robot includes at least one execution unit, and the robot is configured with an executable file; the executable file includes at least one type of resource data; the device includes: The first processing module is configured to respond to the first startup command, wherein the executable file runs and generates a main control process; The second processing module is used by the main control process to perform differentiated deployment of the resource data according to the data type of the resource data, so as to release the communication bridging dependency data in the resource data into a bridging executable file, and start a communication bridging subprocess based on the bridging executable file; it is also used to load the configuration file data into memory when the resource data includes configuration file data, so that the main control process can read the initialization parameters; when the resource data includes default action library data and the target action library does not exist locally, it unpacks the default action library data to generate the target action library locally; when the resource data includes front-end static resource data, it mounts the front-end static resource data to the routing interface, and when the route is not hit, it uniformly redirects to the homepage file of the front-end static resource data, so as to provide access services for the operation interface through the main control process; The third processing module is used for the main control process to receive action orchestration data for the target execution unit and generate an action control sequence based on the action orchestration data; The fourth processing module is used to merge the incremental action control sequence into the data field corresponding to the device model in the multi-model record file according to the device model of the target execution unit. The fifth processing module is used to, upon receiving an execution instruction for the action control sequence, have the main control process convert the action control sequence into a physical control frame and send the physical control frame to the communication bridge subprocess. The sixth processing module is used to transmit the physical control frame to the target execution unit based on the communication bridge subprocess, so as to control the operation of the target execution unit.

8. A robot, characterized in that, include: At least one execution unit; The robot control device as described in claim 7 is electrically connected to the execution unit.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the robot control method as described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the robot control method as described in any one of claims 1-6.

Images