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 robot comprises a plurality of execution units and a plurality of servo motors for driving the execution units respectively, and the method comprises the following steps: in response to a first control instruction containing a target servo motor identifier, a preset control interface is called to generate a control message set corresponding to the target servo motor identifier; the control message set comprises a plurality of control messages, each control message is obtained by encapsulating the target servo motor identifier according to a communication protocol matched with the communication type of each servo motor; a target servo motor corresponding to the target servo motor identifier in the servo motors acquires a control message matched with the communication type of the target servo motor from the control message set; and the target servo motor drives the corresponding execution unit to operate based on the matched control message, so that the flexibility and adaptability of the hardware configuration of the whole robot are improved.

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] Robot execution units are typically connected to a host controller via a bus. In actual production, different manufacturers' heterogeneous servo motors are often mixed and matched on the same robot or even the same bus. Related technologies use differentiated drive adaptation for each motor model or rely on static mapping tables for instruction distribution to achieve collaborative operation of heterogeneous motors; however, these technologies struggle to effectively decouple the upper-level control logic from the lower-level communication protocol, resulting in low code reusability, high adaptation testing costs, and limiting the mass production and maintainability of the robot's control software. Furthermore, the distribution method relying on manually maintained static mapping tables is prone to sending incompatible messages due to configuration deviations, causing the motors to fail to execute and reducing the overall reliability of the robot. 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 flexibility and adaptability of the robot's overall hardware configuration.

[0004] In a first aspect, this application provides a robot control method, the robot comprising multiple execution units and multiple servo motors for driving each of the execution units, the method comprising: In response to a first control command containing a target servo motor identifier, a preset control interface is invoked to generate a set of control messages corresponding to the target servo motor identifier; the set of control messages includes multiple control messages, each of which is obtained by encapsulating the target servo motor identifier according to a communication protocol that matches the communication model of each servo motor; The target servo motor that corresponds to the target servo motor identifier in the servo motor is obtained from the control message set, and the control message that matches the communication model corresponding to the target servo motor is obtained. The target servo motor drives the corresponding execution unit to run based on the matched control message.

[0005] According to the robot control method of this application, a preset control interface is constructed within the same robot body control software stack by uniformly abstracting the underlying heterogeneous servo motors. When responding to control commands, by calling this preset control interface, a set of control messages containing multiple communication protocols can be generated. The target servo motor can then autonomously match and extract control messages matching its communication model from this set. Through this mechanism, the upper-level command distribution logic in the robot is decoupled from the specific communication format of the underlying motors, effectively shielding the differences in communication protocols between heterogeneous motors. This allows for hybrid driving of heterogeneous motors without significant modifications to the upper-level control code, thereby improving the flexibility of the robot's overall hardware configuration and the system's adaptability, and reducing subsequent development and maintenance costs.

[0006] According to one embodiment of this application, the preset control interface defines a set of general control operations for the servo motor, and the preset control interface includes a unified aggregation layer and multiple implementation layers respectively set for different communication protocols; the step of calling the preset control interface to generate a set of control messages corresponding to the target servo motor identifier includes: The unified aggregation layer determines the corresponding target control operation in the general control operation set according to the first control instruction, and calls the control operation corresponding to the target control operation in each implementation layer; wherein, the general control operation set is constructed based on the common control functions of each execution unit; Each of the invoked implementation layers encapsulates the target servo motor identifier based on its corresponding communication protocol, and generates and returns the corresponding control message and parameter-level error. The unified aggregation layer acquires the control messages returned by each of the implementation layers and discards the parameter-level errors returned by each of the implementation layers; The unified aggregation layer merges the acquired control messages to obtain the control message set.

[0007] According to one embodiment of this application, the plurality of implementation layers includes a first implementation layer and a second implementation layer; wherein, The control message generated by the first implementation layer is a first control message encapsulated according to the first communication protocol. The frame identifier of the first control message includes the target servo motor identifier, the master station identifier, and the command type. The control message generated by the second implementation layer is a second control message encapsulated according to the second communication protocol. The frame identifier of the second control message includes the target servo motor identifier, and the data field of the second control message contains a command word.

[0008] According to one embodiment of this application, the method further includes: The servo motor filters out control messages from the control message set that do not match the servo motor.

[0009] According to one embodiment of this application, the servo motor filters control messages in the control message set that do not match the servo motor, including: If it is determined that the control instruction identifier of the mismatched control message is not within the target definition domain, the servo motor discards the mismatched control message; If a protocol-level error response frame is generated based on the mismatched control message, and the frame identifier of the protocol-level error response frame does not match the target feedback frame identifier, the unified aggregation layer discards the protocol-level error response frame.

[0010] According to one embodiment of this application, when the plurality of execution units include a multi-finger execution unit, and the control instruction is directed to the multi-finger execution unit, the step of calling a preset control interface to generate a set of control messages includes: The first control instruction is parsed to obtain the target byte data corresponding to the multi-finger hand execution unit; Based on the communication protocol corresponding to the category of the multi-finger execution unit, the target byte data is encapsulated into a multi-finger control message, and the multi-finger control message is incorporated into the control message set.

[0011] According to one embodiment of this application, the step of encapsulating the target byte data into a multi-finger control message based on the communication protocol corresponding to the category of the multi-finger execution unit includes: When the type of the multi-finger execution unit is the first multi-finger execution unit, the corresponding target byte data and the first frame command word are encapsulated to generate a single frame control message; When the type of the multi-finger execution unit is the second multi-finger execution unit, the corresponding target byte data is split into a first data segment and a second data segment, and the first data segment is encapsulated with the first frame command word to generate a first frame control message, and the second data segment is encapsulated with the continuation frame command word to generate a continuation frame control message. The single-frame control message, the first-frame control message, and the subsequent-frame control message all share the same frame identifier.

[0012] According to one embodiment of this application, before the step of generating a set of control messages corresponding to the target servo motor identifier by calling a preset control interface in response to a first control command containing a target servo motor identifier, the method further includes: During the initialization phase, the first communication protocol probe is executed; If the first detection response is not obtained, the process reverts and executes the second communication protocol detection to obtain the device type and assembly position of the servo motor and the execution unit.

[0013] Secondly, this application provides a robot control device, the robot including multiple execution units and multiple servo motors for driving each of the execution units, the device comprising: The first processing module is configured to respond to a first control command containing a target servo motor identifier by calling a preset control interface to generate a set of control messages corresponding to the target servo motor identifier; the set of control messages includes multiple control messages, each of which is obtained by encapsulating the target servo motor identifier according to a communication protocol that matches the communication model of each servo motor. The second processing module is used to obtain, from the control message set, a control message matching the communication model corresponding to the target servo motor from the target servo motor that corresponds to the target servo motor identifier. The third processing module is used to drive the corresponding execution unit to run based on the matched control message of the target servo motor.

[0014] According to the robot control device of this application, a preset control interface is constructed within the same robot body control software stack by uniformly abstracting the underlying heterogeneous servo motors. When responding to control commands, by calling this preset control interface, a set of control messages containing multiple communication protocols can be generated. The target servo motor can then autonomously match and extract control messages matching its communication model from this set. Through this mechanism, the upper-level command distribution logic in the robot is decoupled from the specific communication format of the underlying motors, effectively shielding the differences in communication protocols between heterogeneous motors. Hybrid driving of heterogeneous motors can be achieved without significant modifications to the upper-level control code, thereby improving the flexibility of the robot's overall hardware configuration and the system's adaptability, and reducing subsequent development and maintenance costs.

[0015] Thirdly, this application provides a robot, comprising: Multiple execution units; Multiple servo motors; each servo motor is connected to a corresponding execution unit for driving each execution unit; As described in the second aspect above, the robot control device is electrically connected to the servo motor and the execution unit, respectively.

[0016] Fourthly, this application provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the robot control method as described in the first aspect above.

[0017] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the robot control method as described in the first aspect above.

[0018] The above-described one or more technical solutions in the embodiments of this application have at least one of the following technical effects: Within the same robot control software stack, a pre-defined control interface is constructed by uniformly abstracting the underlying heterogeneous servo motors. When responding to control commands, this pre-defined control interface is invoked to generate a set of control messages containing multiple communication protocols. The target servo motor can then autonomously match and extract control messages matching its communication model from this set. Through this mechanism, the upper-level command distribution logic in the robot is decoupled from the specific communication format of the underlying motors, effectively shielding the differences in communication protocols between heterogeneous motors. This allows for hybrid driving of heterogeneous motors without significant modifications to the upper-level control code, thereby improving the flexibility of the robot's overall hardware configuration and the system's adaptability, while reducing subsequent development and maintenance costs.

[0019] Furthermore, by sending control messages of multiple protocols in parallel, mismatched messages are naturally filtered by the underlying hardware filter and firmware layer. Simultaneously, based on the general property that request and response identifier values ​​do not overlap, occasional abnormal feedback frames are automatically filtered, thereby reducing the system's dependence on specific manufacturer-specific response values. Furthermore, based on the aforementioned underlying passive failure mechanism, this solution constructs a hybrid drive mechanism for heterogeneous motors, combining simultaneous sending and silent ignoring, effectively reducing system cascading failures caused by model configuration mismatches. Based on this mechanism, the upper-layer system reduces its perception dependence on specific motor models, thus enabling the mixed installation of heterogeneous motors on the same control bus, thereby improving the flexibility and adaptability of the robot's overall hardware configuration.

[0020] Furthermore, the normalized target floating-point pressure is mapped to discrete byte data through linear mapping, and dynamic encapsulation is implemented based on the upper limit of the bus single-frame payload: the first multi-finger hand with data within the limit adopts a single-frame layout; the second multi-finger hand with data exceeding the limit is decomposed into a first frame and subsequent frames that share the same frame identifier and are distinguished only by the first byte command word. This scheme solves the limitation of the physical length of the bus single frame with low protocol overhead; at the same time, by allowing multi-finger hands with different physical configurations to share the identifier and command word template, they can share the same control interface at the upper layer, which reduces the complexity of the multi-finger hand control module, improves the flexibility of the robot's overall hardware configuration and the system's adaptability, and effectively reduces subsequent development and maintenance costs.

[0021] 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

[0022] 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 a schematic diagram of the structure of the robot control device provided in the embodiments of this application; Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0023] 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.

[0024] 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.

[0025] 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.

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

[0027] 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.

[0028] It should be understood that a terminal may include one or more other physical user interface devices such as a physical keyboard, mouse, and joystick.

[0029] The robot control method provided in this application embodiment can be executed by a robot or a functional module or entity in a robot that can implement the robot control method. The robot control method provided in this application embodiment is described below using a robot as the execution subject.

[0030] During the research and development process, the inventors discovered that the robot's body typically comprises multiple execution units (such as robotic arms or multi-fingered dexterous hands). Each execution unit is driven by a corresponding servo motor, which is usually connected to a host controller via a bus (such as CAN or RS-485 protocols). In actual production, it is common to mix heterogeneous servo motors from different manufacturers or series on the same robot or even the same bus. While these heterogeneous motors share consistent high-level control semantics, their underlying communication protocols (such as frame formats and data field layouts) differ significantly, resulting in low code reusability and difficulty in sharing a unified control interface between heterogeneous devices.

[0031] To adapt to these heterogeneous motors, related technologies typically directly call the proprietary driver libraries provided by each manufacturer, or distribute instructions based on message middleware. However, these methods struggle to effectively decouple the upper-layer control logic from the lower-layer communication protocol. The upper-layer business code needs to explicitly distinguish the interfaces and parameters of various motors, resulting in significant modifications to the control branches when integrating new motor models. This increases the cost of code adaptation and testing, and severely limits the flexibility of hardware replacement during mass production.

[0032] To address the challenges of mixed-model compatibility, some related technologies mandate the use of the same model motor for the entire machine or a single arm. This approach simplifies control code at the expense of hardware compatibility, but the system hardware is easily tied to a single vendor, resulting in a lack of supply chain flexibility. Furthermore, some technologies rely on manually maintained static mapping tables for control distribution. While this method superficially supports mixed-model installations, the accuracy of command issuance depends entirely on manually preset table entries. In scenarios with multiple motors, the system's initial startup phase, relying solely on conventional passive scanning, struggles to accurately identify the equipment type and installation location automatically. If the system misidentifies or the static mapping table configuration is incorrect, the upper-level controller will send completely incompatible protocol messages to the target motor, causing the motor to fail to correctly parse and execute actions. This can trigger cascading failures in the control system, reducing the overall reliability of the machine.

[0033] To address the problem of strong coupling between upper-level motion control code and lower-level heterogeneous hardware within a single robot, which makes it difficult to integrate servo motors using different communication protocols on the same control bus, and the inherent risk of system cascading failures due to model mismatches in traditional lookup table-based active distribution mechanisms, the inventors, after in-depth research, designed a robot control method. The robot includes multiple execution units and multiple servo motors driving each execution unit. The method includes: responding to a first control command containing a target servo motor identifier, calling a preset control interface to generate a set of control messages corresponding to the target servo motor identifier; the control message set includes multiple control messages, each encapsulated according to a communication protocol matching the communication model of each servo motor; the target servo motor corresponding to the target servo motor identifier retrieves the control message matching its communication model from the control message set; and the target servo motor drives the corresponding execution unit based on the matched control message.

[0034] According to the robot control method provided in this application, a preset control interface is constructed within the same robot body control software stack by uniformly abstracting the underlying heterogeneous servo motors. When responding to control commands, by calling this preset control interface, a set of control messages containing multiple communication protocols can be generated. The target servo motor can then autonomously match and extract control messages matching its communication model from this set. Through this mechanism, the upper-level command distribution logic in the robot is decoupled from the specific communication format of the underlying motors, effectively shielding the differences in communication protocols between heterogeneous motors. Hybrid driving of heterogeneous motors can be achieved without significant modifications to the upper-level control code, thereby improving the flexibility of the robot's overall hardware configuration and the system's adaptability, and reducing subsequent development and maintenance costs.

[0035] In some embodiments, the robot includes multiple actuators and multiple servo motors.

[0036] In some embodiments, the device category of the execution unit may include robotic arms, dexterous hands, electric grippers, painting ends, mobile chassis, or multi-axis gimbals, etc.

[0037] In this embodiment, the robotic arm may include, but is not limited to, a six-degree-of-freedom robotic arm, a seven-degree-of-freedom robotic arm, or a dual-arm collaborative robotic arm.

[0038] Dexterity can include, but is not limited to: three-finger dexterity, five-finger dexterity, six-finger dexterity, or ten-finger dexterity.

[0039] Among them, the six-fingered hand (L6) and the ten-fingered hand (L10) are multi-finger dexterous hands that respectively contain six and ten independently controllable finger execution units.

[0040] In a typical hardware architecture, a robot body usually consists of two seven-DOF robotic arms and two multi-fingered dexterous hands. These actuators are typically symmetrically mounted on the left and right sides of the robot body (e.g., configured as the left arm, right arm, left hand, and right hand, respectively). Due to the different torque requirements and physical size constraints of each joint, heterogeneous servo motors are usually mixed and matched at different joint positions on the same robot, or even on the same bus. Each servo motor is connected to the robot's host controller via a bus.

[0041] In some embodiments, the bus may include Controller Area Network (CAN) protocol, RS-485 protocol, or EtherCAT protocol, etc.

[0042] In addition, there are alternative implementation methods to the aforementioned CAN bus-based implementation method: the CAN bus interface module of the present invention can be carried by a native SocketCAN driver, a USB-CAN adapter, a virtual CAN (vcan) based on a transmission control protocol tunnel, or even an Ethernet-based CAN over Ethernet; as long as its message structure exposed to the upper layer can be mapped by the CANMessage data structure of the present invention, it is considered an equivalent replacement.

[0043] At the global motion planning level of the upper-level controller, the aforementioned heterogeneous servo motors exhibit a high degree of consistency in their high-level control semantics (e.g., uniformly accepting instructions such as enable, disable, speed setting, single joint angle setting, batch joint angle setting, proportional-integral-derivative (PID) parameter tuning, and error clearing). However, significant differences exist in the underlying communication protocols when receiving instructions. The proportional-integral-derivative (PID) controller is a three-term linear controller that responds to errors using proportional, integral, and derivative terms.

[0044] In some embodiments, the differences in the underlying communication protocols described above may include: differences in frame identifier bit width, differences in frame identifier encoding methods, differences in data field layout, and differences in parameter open granularity.

[0045] In this embodiment, the difference in frame identifier bit width is reflected in the following: some servo motor models use a standard frame with an 11-bit width, while other servo motor models use an extended frame with a 29-bit width. The standard frame and the extended frame are two frame formats in the CAN protocol with frame ID lengths of 11 bits and 29 bits, respectively.

[0046] The difference in frame identifier encoding methods is reflected in the following: some servo motors' underlying protocols directly use the motor identifier as the complete frame identifier, while other heterogeneous servo motors use a combined encoding method (e.g., synthesizing the frame identifier into three segments: "motor identifier, master identifier, and command type"). The master identifier is a logical number used to uniquely identify the host controller on the CAN bus; the command type (commType) is a command category identifier encoded in the high segment of the 29-bit frame ID of the extended frame motor. The differences in data field layout are as follows: some servo motors use a combination structure of command word and corresponding parameters in their data messages, while other servo motors use a configuration structure of register address and corresponding register write value. The command word (Command Byte) is the operation identifier encoded in the first byte of the data field of a standard frame motor.

[0047] The aforementioned extended frame motors and standard frame motors are two types of servo motor series distinguished by CAN frame format. In this specification, they are respectively implemented by the extended frame motor implementation layer (such as RsArmEncoder) and the standard frame motor implementation layer (such as LensArmEncoder).

[0048] The difference in parameter openness granularity is reflected in the fact that different manufacturers' series of servo motors have different constraints on the read and write permissions and levels of underlying control parameters such as proportional-integral-derivative (PID).

[0049] In some embodiments, to achieve unified hybrid drive for the aforementioned heterogeneous servo motors, the robot's body control software stack can refer to... Figure 2 It is equipped with a corresponding control architecture.

[0050] Figure 2 The overall control block diagram for the hybrid heterogeneous motor robot includes: the upper-level motion planning / task scheduling module calls the unified aggregation module through the unified arm motor control interface; the unified aggregation module internally holds two instances in parallel: the extended frame motor implementation layer and the standard frame motor implementation layer; the CAN messages generated by the two types of implementation layers are sent in parallel to the left arm, right arm, left hand, and right hand execution units through the CAN bus interface module; the multi-finger hand control module performs floating-point pressure normalization and multi-frame stitching in parallel at the same level.

[0051] Among them, the Unified Arm Encoder Interface (ArmEncoder) is a unified abstract interface defined in this invention for heterogeneous servo motors.

[0052] refer to Figure 2 The control method of this application embodiment can be executed collaboratively by an encoder module, a unified aggregation module, an arm detection module, a multi-fingered hand module arranged in the robot body control software stack, and a bus interface module (such as a CAN interface module) arranged in the hardware transmission layer.

[0053] Continue to refer to Figure 2 The top-level motion planning or task scheduling module only holds variables of the preset control interface (i.e., the ArmEncoder interface), and sends instructions downwards by calling the interface variables.

[0054] In the above collaborative control architecture, the code inclusion and calling relationship between the encoder module and the unified aggregation module is as follows: the encoder module includes a unified interface layer and multiple implementation layers; the unified aggregation module internally holds instances of the above multiple implementation layers.

[0055] Based on the above inclusion relationship, the abstract control levels in this application can be implemented in the following code examples: In some embodiments, the preset control interface in this application may be a unified interface layer in the encoder module (e.g., the ArmEncoder interface defined in the code).

[0056] In this embodiment, the unified interface layer defines a set of general control operations for servo motors, which is used to provide a unified calling specification to the upper layer.

[0057] refer to Figure 2 The general control operation set of the ArmEncoder interface can include: EnableMotor, DisableMotor, SetSpeed / SetSpeeds, SetAcceleration / SetAccelerations, SetAngle / SetAngles, SetProportional / Integral / Filtering Parameters (SetMotor{Loc / Speed}Kp / Ki / FiltGain), SetMotorZero, CleanError, and CheckMotor.

[0058] The general control operation set is built on the common control functions of each execution unit, so that the upper-level motion control code only needs to call this unified interface layer, without having to be aware of the differences in the underlying motor model and communication protocol.

[0059] In some embodiments, the multiple implementation layers in this application are used to perform instruction translation and protocol encapsulation logic for different underlying characteristics of heterogeneous servo motors.

[0060] In this embodiment, the multiple implementation layers are a set of driver functions within the encoder module responsible for parsing specific communication protocols and constructing messages. These multiple implementation layers can be configured based on the differences in the underlying drive characteristics of each heterogeneous servo motor.

[0061] The following explanation uses differences in communication protocols as an example. In actual implementation, refer to... Figure 2The implementation layers can include an extended frame motor implementation layer (e.g., RsArmEncoder) and a standard frame motor implementation layer (e.g., LensArmEncoder). Both serve as low-level driver code written for the 29-bit extended frame protocol and the 11-bit standard frame protocol, respectively, responsible for parsing and encapsulating the communication protocol. For example... Figure 2 As shown, the extended frame motor implementation layer corresponds to a 29-bit extended frame, whose frame identifier can include the master station identifier (such as 0x00FD) and a specific command type (commType); the standard frame motor implementation layer corresponds to an 11-bit standard frame, whose frame identifier can directly use the motor identifier (motorID), and includes a specific command word in the data field.

[0062] It is understandable that the differences in the underlying driver characteristics mentioned above may include, in addition to the different communication protocol categories, differences in frame identifier bit width (such as 11-bit standard frame and 29-bit extended frame) under the same communication protocol, differences in data field layout (such as command word structure and register structure), and differences in specific instruction sets of different motor manufacturers. This application does not limit the specific basis for the division of multiple implementation layers.

[0063] In some embodiments, the unified aggregation layer in this application may be the aforementioned unified aggregation module (e.g., defined as UnifiedArmEncoder).

[0064] In this embodiment, the unified aggregation module, acting as a scheduling layer, uses its internally held implementation layer instances (such as the extended frame motor implementation layer instance and the standard frame motor implementation layer instance) to achieve unified distribution and overall management of different underlying drivers. Figure 2 As shown in the intermediate layer logic, for each call to the upper layer, the unified aggregation module calls the underlying implementations in parallel at the code level (such as rsMsgs, _ := rs.M() and lensMsgs, _ := lens.M()), and after discarding the error parameters returned by the lower layer, merges the obtained messages (such as return append(rsMsgs,lensMsgs), nil), and finally returns to the lower layer.

[0065] In addition, refer to Figure 2 The collaborative control architecture also includes a multi-finger control module (e.g., L6HandEncoder for six-finger hands or L10HandEncoder for ten-finger hands). This module is responsible for performing floating-point pressure normalization operations for multi-finger hands in parallel at the same level (e.g., using byte(round(p × 255)) logic), as well as single-frame or 6+4 double-frame message splicing and transmission operations.

[0066] It should be noted that when executing control methods, the aforementioned modules or layers can generate bus message objects (such as CAN message objects) instead of directly sending them. The actual sending of these messages is uniformly handled by the bus interface module (such as the CAN Interface Module) located in the hardware transmission layer, thereby achieving decoupling between the control layer and the transmission layer. (Reference) Figure 2 The bus interface module can be carried by SocketCAN, USB-CAN, or vcan, and will send the merged control messages to the robot's various communication branches (e.g., CAN0 port for the 7 joints of the left arm, CAN1 port for the 7 joints of the right arm, CAN2 port for the left hand, and CAN3 port for the right hand). For control messages broadcast to the bus, non-matching motors will be naturally filtered by the underlying CAN controller or motor firmware because the frame ID and command word of the message fall outside their own defined domain (i.e., implementing a broadcast and silent ignore mechanism).

[0067] Broadcast Dispatch is a method of distributing messages to both extended frames and standard frames simultaneously for each upper-layer control call.

[0068] The Silently Ignore mechanism is an error handling method that prevents parameter-level errors returned by non-matched motors from being propagated to the upper layer.

[0069] Those skilled in the art should understand that the “layer” used in this document to describe the hierarchical relationship of the system is the same technical concept expressed in different dimensions as the “module,” “class,” or “interface” in the specific code structure of software engineering.

[0070] The architectural relationships in this application can be understood as follows: a macro-level business "module" (such as the encoder module mentioned above) can be logically divided into "layers" at different levels of abstraction (such as the unified interface layer responsible for defining contracts, and the implementation layer responsible for encapsulating specific protocols); and each of these "layers" can be concretely implemented as corresponding code structures in actual object-oriented programming (OOP). For example, the unified interface layer corresponds to the "interface" definition, and the implementation layer corresponds to the specific entity "class" object. Therefore, the use of the above terms is intended to clearly illustrate the control logic and data flow relationships in this application, and does not constitute a limitation on the specific code implementation form of this application. The key constants in this application are shown in Table 1.

[0071]

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

[0073] Step 110: In response to the first control command containing the target servo motor identifier, call the preset control interface to generate a set of control messages corresponding to the target servo motor identifier; In this step, the control message set includes multiple control messages, each of which is obtained by encapsulating the target servo motor identifier according to a communication protocol that matches the communication model of each servo motor.

[0074] The first control command is a global control request in the robot and its related systems, used to instruct a specific actuator or joint to perform a desired action (or state configuration). (Reference) Figure 2 The first control command can be uniformly issued by the motion planning module (e.g., responsible for spatial trajectory planning and kinematic calculation) or the task scheduling module (e.g., responsible for the execution sequence of the overall business logic) located on the upper layer of the control software stack.

[0075] The target servo motor identifier is used to uniquely identify and locate the motor to be controlled, and can be represented as motorID in the code parameters.

[0076] In some embodiments, the preset control interface defines a set of general control operations for servo motors, and the preset control interface includes a unified aggregation layer and multiple implementation layers respectively set for different communication protocols.

[0077] In this embodiment, the general control operation set is constructed based on the common control functions of each execution unit.

[0078] In actual implementation, refer to Figure 2 The default control interface can be the unified arm motor control interface (hereinafter referred to as the ArmEncoder interface) defined in the unified interface layer. The general control operation set (i.e., method set) of this interface is grouped by functional domain as follows: Enable and disable classes: including EnableMotor(motorID) int) and DisableMotor(motorID) (int). The parameter motorID is carried as a pointer. When the value is a null pointer (nil), it means that all joint motors on this side (left or right) are enabled or disabled in batches. When the value is not null, it means that the specified motor is enabled or disabled.

[0079] Speed ​​and acceleration classes include SetSpeed(motorID, speed), SetSpeeds(speeds []float32), SetAcceleration(motorID, acc), and SetAccelerations(accs []float32), which respectively carry out the setting of speed / acceleration for a single motor and the setting of speed / acceleration for the entire arm in batches.

[0080] Angle classes include SetAngle(motorID, angle), SetAngleWithIndex(index, angle), and SetAngles(angles []float32). Among them, SetAngleWithIndex is issued by joint index (instead of motor ID), which makes it easier for the upper layer to arrange data in joint order rather than manufacturer ID order.

[0081] PID and filtering classes include position loop proportional gain SetMotorLocKp, speed loop proportional gain SetMotorSpeedKp, speed loop integral gain SetMotorSpeedKi, and speed filtering gain SetMotorSpeedFiltGain.

[0082] Maintenance functions include SetMotorZero (zeroing out), CleanError (error clearing), and CheckMotor (motor existence check / handshake).

[0083] Each method of the ArmEncoder interface uniformly returns a tuple of ([]CANMessage, error). Here, []CANMessage is the list of CAN messages to be sent, and error is a parameter-level error (e.g., motor ID out of bounds).

[0084] Based on this design, motor drives from different manufacturers at the lower level can achieve unified access to the upper-level controller by implementing the same interface.

[0085] It is understood that, in addition to the Go language interface form used above, the implementation of the unified interface layer in this application can also be replaced by other polymorphic implementations such as function tables, C-style virtual function tables (vtables), or dynamic library plug-ins; the interface method set can also be added or deleted according to the deployment scenario, but as long as the minimum subset of methods "enable / disable / speed / acceleration / angle / PID / zeroing / clearing" is retained and "list of CAN messages to be sent + parameter-level errors" is used as the unified return form, it is considered an equivalent substitution of the present invention.

[0086] According to the robot control method provided in this application, a unified servo motor control interface abstraction scheme is constructed, anchoring control semantics at the functional semantic layer rather than the underlying communication protocol layer. This control interface defines a general set of control operations for servo motors, covering various control semantics such as motion control, state configuration, parameter adjustment, and operation and maintenance, all anchored to the same set of method signatures. Furthermore, its method set uniformly returns a binary tuple containing a list of control messages to be sent and parameter-level errors. Based on this design, the upper-layer motion planning module and task scheduling module can be programmed to send control commands through this interface, greatly reducing the upper-layer code's dependence on the underlying motor model. When the lower layer connects to newly added heterogeneous motor types or motor drives from different manufacturers, providing the corresponding implementation of this interface is sufficient to connect to the upper-layer controller without significantly modifying the existing upper-layer control code. This method effectively shields the differences in underlying protocols, improving the flexibility and adaptability of the robot's overall hardware configuration.

[0087] In some embodiments, the plurality of implementation layers include a first implementation layer and a second implementation layer; The control message generated by the first implementation layer is a first control message encapsulated according to the first communication protocol; The control message generated by the second implementation layer is a second control message encapsulated according to the second communication protocol.

[0088] In this embodiment, the frame identifier of the first control message includes the target servo motor identifier, the master station identifier, and the command type.

[0089] The frame identifier of the second control message includes the target servo motor identifier, and the data field of the second control message contains the command word.

[0090] The first implementation layer is used to perform instruction translation and message encapsulation operations on the servo motor using the first communication protocol. The first implementation layer can be obtained by instantiating the code structure or class object corresponding to the underlying layer of the first communication protocol in the control software stack.

[0091] The second implementation layer is used to perform instruction translation and message encapsulation operations on servo motors using the second communication protocol. The second implementation layer can be obtained by instantiating the code structure or class object corresponding to the underlying layer of the first communication protocol in the control software stack.

[0092] It should be noted that the unified aggregation layer of this application may also include three or more implementation layers simultaneously. In practical applications, the number of implementation layers corresponds to the number of underlying communication protocols compatible with the system. As the types of mixed-type motors increase, this application does not limit the specific number of implementation layers.

[0093] In some embodiments, the first communication protocol can be the 29-bit Extended Frame Controller Area Network (CAN) protocol, and the second communication protocol can be the 11-bit Standard Frame CAN protocol. In other embodiments, the first or second communication protocol described above can also be a low-level communication protocol based on other industrial bus standards such as RS-485 or EtherCAT, which is not limited herein.

[0094] In this embodiment, Controller Area Network (CAN) is a serial fieldbus protocol widely used in industrial fields and robot joint buses.

[0095] refer to Figure 3 The following section uses the 29-bit extended CAN frame as the first communication protocol as an example to explain the message encapsulation process of the first implementation layer (e.g., the extended frame motor implementation layer RsArmEncoder).

[0096] In the specific implementation of the extended frame motor and the three-segment extended frame ID encoding method, for any control message, the first implementation layer synthesizes the extended frame ID according to the following formula: ID = motorIDPart | masterIDPart | commTypePart = (motorID&0xFF) | (uint32(0x00FD)<<8) | ((commType&0x1F)<<24) refer to Figure 3 The aforementioned 29-bit frame identifier is strictly divided into three independent data segments from low to high.

[0097] The target servo motor identifier field (motorID) occupies the lower 8 bits (bits 0 to 7) and is used to carry the target motor ID. For example, the motor IDs for the seven joints of the left arm can be configured as 61–67. Figure 3 In the example, the ID of joint 1 in the left arm is 0x3D, which corresponds to 61 in decimal. The seven joints in the right arm can be configured as 51–57.

[0098] The master ID field occupies 16 bits (bits 8 to 23) starting from bit 8 and is used to carry a fixed identifier for the host controller. For example, this field can be fixed as 0x00FD.

[0099] The command type field (commType) occupies 5 bits (bits 24 to 28) starting from bit 24 and is used to carry the major categories of high-level control commands. For example... Figure 3As shown, typical values ​​can include: 0x00 (existence check / handshake), 0x03 (enable), 0x04 (disable / clear), 0x06 (zero), 0x12 (parameter register write), and 0x16 (save all parameters). The data from these three segments are combined into a single 29-bit extended frame ID through a bitwise OR operation. This three-segment bitwise OR synthesis ensures that the frame ID itself can be accurately matched by the CAN hardware filter, while simultaneously reserving all 8 bytes of data in each frame for the underlying register number and write value, thereby improving bus utilization.

[0100] Continue to refer to Figure 3 In the case of command type segment commType = 0x12 (i.e., parameter register write), the data field of the control message has a specific spatial layout. Specifically, the first two bytes of the data field (i.e., data[0] and data[1])... Figure 3 The corresponding values ​​are reg.lo and reg.hi, which are used as the low and high bytes respectively to carry the corresponding target register numbers; starting from the 2nd byte (i.e., data[2] to data[5], Figure 3 The corresponding values ​​for f32[0] to f32[3] are the specific register values ​​to be written. For floating-point parameters, this field is encoded according to the IEEE 754 single-precision little-endian standard. In this embodiment, typical control register number mappings include: 0x7005 (mode switching), 0x7029 (zero-bit start), 0x7016 (angle setting), 0x7024 (speed setting), and 0x7025 (acceleration setting), etc. The typical register mappings are shown in Table 2 below.

[0101]

[0102] To ensure that the robot joint zero-position parameters are permanently stored on the disk, the first implementation layer sends out a sequence of three control messages in strict timing order when performing a zeroing operation on each motor. The first frame is used to write the zero-position start bit, i.e., constructing a parameter register write message and writing the value 1 into register 0x7029; the second frame is used to save everything, i.e., constructing a save command message and configuring the commType field to a value of 0x16; the third frame is used to execute the zeroing action, i.e., constructing a zeroing trigger message and configuring the commType field to a value of 0x06.

[0103] According to the robot control method provided in this application, a three-segment frame identifier encoding mechanism is adopted for servo motors. This mechanism uses bitwise OR operations to compress and synthesize the target motor identifier, master station identifier, and command type into the same frame identifier, so that the frame identifier itself can be accurately matched by the underlying hardware to achieve message splitting. Furthermore, this scheme improves bus utilization by releasing data fields and using them entirely to carry register numbers and write values, meeting the communication needs of servo motors from different manufacturers mixed on the same set of control buses, thereby improving the flexibility and adaptability of the robot's overall hardware configuration.

[0104] It is understood that the extended frame ID encoding in this application can also be implemented in the following alternative ways: for example, the master station identifier 0x00FD can be replaced with other manufacturer-defined values; for example, the bit width of the command type field can be adjusted between 4 and 7 bits; for example, the bit order of the low byte motor ID and the high byte command type can also be interchanged; if the core method of "synthesizing the three segments of motor ID + master station identifier + command type in the extended frame ID by bit operation" is retained, it can be regarded as an equivalent replacement.

[0105] refer to Figure 4 The following section uses the 11-bit standard CAN frame as the second communication protocol as an example to explain the specific message encapsulation process of the second implementation layer (e.g., the standard frame motor implementation layer LensArmEncoder).

[0106] In the standard frame motor implementation and command word register-based control method, the second implementation layer implements the same preset control interface (i.e., the ArmEncoder interface) as described above. Completely different from the extended frame ID synthesis method used in the first implementation layer, this second implementation layer directly uses the target servo motor identifier as the standard frame ID.

[0107] For any control message, its 11-bit standard frame ID is set to ID = uint32(motorID). For example, ... Figure 4 As shown, the IDs for the left and right hands can be 0x28 and 0x27 respectively, and the ID range for a specific Lens arm motor can be from 0x33 to 0x43.

[0108] In some embodiments, standard frame ID synthesis can be implemented based on the following pseudocode: ID = uint32(motorID) data[0] = commandByte data[1..] = payload (float32 little-endian or constant parameter).

[0109] Furthermore, this second implementation layer employs a command-word plus register-based data field layout. For example... Figure 4 As shown, the first byte of the data field of the control message (i.e., data[0]) is used to carry a specific command word (cmd), and from the first byte onwards (i.e., data[1] and subsequent bytes), it is used to carry the corresponding constant or floating-point parameters (e.g., IEEE 754 single-precision little-endian floating-point parameters). Typical command word mappings are shown in Table 3 below. The Profile Position Mode is a working mode for servo motors that plans motion trajectories according to target positions.

[0110]

[0111] For floating-point parameters, they are encoded in single-precision little-endian (float32 LE). In this embodiment, a typical command word mapping may include: 0x07 indicating mode switching (e.g., switching to PROFILE POSITION mode, corresponding to parameter data[1] = 0x05), 0x2A indicating enable or disable (corresponding to parameter data[1] 0x01 or 0x00 respectively), 0x0A indicating setting position (SetAngle), 0x1F indicating setting speed (SetSpeed), 0x20 indicating setting acceleration (SetAcceleration), 0x21 indicating setting deceleration (SetDeceleration), 0x87 indicating zeroing (SetMotorZero), 0xFE indicating clearing errors (CleanError), and 0x01 indicating version or existence query, etc. In a practical example, to issue an enable command to a motor with ID 0x28, the message format could be: ID = 0x28, data = [0x2A, 0x01, 0, 0, 0, 0, 0, 0].

[0112] Furthermore, for proportional-integral-derivative (PID) control operations that are not open to the standard frame motor hardware (such as setting the position loop proportional gain SetMotorLocKp, speed loop proportional gain SetMotorSpeedKp, speed loop integral gain SetMotorSpeedKi, and speed filtering gain SetMotorSpeedFiltGain), this second implementation layer adopts an interface-null implementation compatible design. When the upper layer calls the above-mentioned closed operations, the second implementation layer directly returns an empty message list and an empty error (i.e., return []CANMessage{}, nil). This approach reduces the CAN traffic generated on the bus while maintaining the same ArmEncoder interface signature shared with the extended frame implementation layer. This null implementation strategy naturally supports the branchless heterogeneous merging execution logic of the unified aggregation layer and forms the natural filtering basis for the "broadcast-silent ignore" mechanism in the subsequent control architecture.

[0113] According to the robot control method provided in this application, a command word plus register-based control message encapsulation mechanism is adopted for servo motors. This mechanism uses lightweight mapping to directly use the target motor identifier as the standard frame identifier and utilizes the first byte of the data field to carry the command word, covering various control semantics. Furthermore, this scheme reduces conditional branches and invalid bus traffic at the aggregation level by using null implementations for specific non-open operations, allowing heterogeneous servo motors to be mixed on the same set of control buses, thereby improving the flexibility and adaptability of the robot's overall hardware configuration.

[0114] It is understood that the aforementioned standard frame command words also have the following alternative implementations: for example, each command word in the command word to operation mapping table (such as 0x07 / 0x2A / 0x0A / 0x1F / 0x20 / 0x21 / 0x87 / 0xFE) can be replaced with an equivalent command word provided by the manufacturer in a later version; a mode code, channel number or other pre-fields can also be added after the command word; however, as long as the message template of "first byte command word + subsequent byte parameters" is retained and an empty message list and an empty error are returned to the non-open interface, it can be regarded as an equivalent replacement.

[0115] It should be noted that the aforementioned "PID interface empty implementation" strategy is applicable only if the upper layer adjusts the PID parameters as a "one-time configuration + long-term use," rather than high-frequency closed-loop parameter tuning. Without opening the PID to the standard frame motor, the empty implementation will not generate any traffic to the bus, nor will it cause any errors. If the upper layer needs to perform PID parameter tuning on the standard frame motor (e.g., through a manufacturer-specific tool), it should be done via an out-of-band channel, decoupled from the unified interface of this invention.

[0116] In some embodiments, step 110 includes: The unified aggregation layer determines the corresponding target control operation from the general control operation set according to the first control instruction, and calls the control operation corresponding to the target control operation in each implementation layer. Each invoked implementation layer encapsulates the target servo motor identifier based on its corresponding communication protocol, and generates and returns the corresponding control message and parameter-level error. The unified aggregation layer obtains the control messages returned by each implementation layer and discards the parameter-level errors returned by each implementation layer; The unified aggregation layer merges the acquired control messages to obtain a set of control messages.

[0117] In this embodiment, the general control operation set is constructed based on the common control functions of each execution unit, which has been described in detail above and will not be repeated here.

[0118] In actual implementation, refer to Figure 5 The unified aggregation layer (e.g., the unified aggregation module UnifiedArmEncoder defined in the specific code) simultaneously holds an instance of both the aforementioned extended frame motor implementation layer and the aforementioned standard frame motor implementation layer. In the code embodiment, the unified aggregation module implements any control method in the preset control interface (such as the ArmEncoder interface) according to the following unified pattern: rsMessages, _ := u.rsEncoder. <method>(args...) lensMessages, _ := u.lensEncoder. <method>(args...) return append(rsMessages, lensMessages...), nil Combination Figure 5 The control logic shown unifies the aggregation layer's control calls to the upper layer (e.g., Figure 5 The top-level call to `u.SetAngles([]float32{θ1...θ7})` specifically performs the following three atomic operations: First, it synchronously calls two types of implementations. The unified aggregation layer simultaneously calls methods with the same name as the target control operation within both the extended frame motor implementation layer (i.e., u.rsEncoder in the code above) and the standard frame motor implementation layer (i.e., u.lensEncoder in the code above). <method>Therefore, the two implementations generate their respective control messages (i.e., rsMessages and lensMessages in the code) and corresponding parameter-level errors in parallel.

[0119] Secondly, two types of errors are explicitly discarded. For parameter-level errors returned by the two calls, the unified aggregation layer explicitly discards them at the code level. This silent handling at the software code level prevents low-level parameter-level errors such as "mismatched motor ID" from propagating upwards.

[0120] Third, the message lists are concatenated in parallel. The unified aggregation layer merges the valid control messages returned by the two types of implementations to generate the final set of control messages. Specifically, the unified aggregation layer executes the append(rsMessages,lensMessages...) logic in the third line of the code above, returning the merged and concatenated message set along with a unified null error (i.e., nil) to the upper layer, so that the upper layer caller does not need to be aware of the model differences of the underlying hybrid motors.

[0121] Through the unified software control mode described above, each upper-level control call simultaneously generates two types of control messages: extended frames and standard frames, which enter the CAN bus (and the frame IDs and command word spaces of these two types of messages do not overlap). See brief reference... Figure 5 At the bottom hardware physical layer logic, when the control message set enters the bus, only the target motor that matches the parameters of this call will receive the instruction and generate actual action based on its own defined domain; while the other unmatched motors are naturally filtered by the underlying CAN controller hardware filter or the motor firmware layer, thus realizing the broadcast and silent ignore mechanism at the software and hardware coordination level.

[0122] It is understandable that the aforementioned unified aggregation module simultaneously holds both extended frame and standard frame motor instances and distributes them in parallel for each call. The number of instances held can be generalized to N (N≥2) to accommodate third or fourth motor manufacturers; the distribution strategy can also be replaced with more granular variations such as "distributing by joint list", "pre-distributing by motor ID range", or "distributing by the maximum likelihood of the previous response statistics"; however, as long as the core mechanism of "silently swallowing all errors returned by non-matching instances" is retained, it is considered an equivalent replacement.

[0123] Step 120: For the target servo motor that corresponds to the target servo motor identifier in the servo motor, obtain the control message that matches the communication model corresponding to the target servo motor from the control message set; In actual execution, when the set of control messages enters the CAN bus via broadcast, the target servo motor continuously listens for bus messages through the underlying hardware filter (such as the CAN controller hardware filter). Once it detects a control message whose frame identifier contains its own target servo motor identifier and whose command format falls within its own defined domain, the target servo motor will determine it as a matching control message and extract it.

[0124] Subsequently, the target servo motor parses the acquired control message based on its corresponding communication model and protocol, and generates actual actions accordingly (such as rotating the corresponding robotic arm joint). If the target servo motor uses the extended frame protocol, it will perform operations based on the command type segment (commType) in the frame identifier and the register number and register value in the data field; if it uses the standard frame protocol, it will perform operations based on the command word in the first byte of the data field and subsequent parameters.

[0125] The resulting overall control semantics are as follows: each upper-level control call generates two types of messages, extended frames and standard frames, which enter the CAN bus. Only the target motor that matches the parameters of this call will obtain the message and generate actual action; other non-matching motors are filtered by the CAN controller hardware filter or the motor firmware layer because the frame ID and command word are outside their own defined domain. Even if a non-matching motor occasionally generates a protocol-level error response frame, it will not be consumed by the upper-level response decoder because its response frame ID does not coincide with the upper-level expected feedback frame ID.

[0126] In some embodiments, the method further includes: The servo motor filter control message set contains control messages that do not match the servo motor.

[0127] In this embodiment, filtering (i.e., "natural filtering" mentioned above) refers to a passive failure mechanism that does not rely on active table lookups or active judgments by upper-layer software. This process is undertaken by the CAN controller hardware and the motor firmware, and can be divided into a four-level filtering mechanism.

[0128] In some embodiments, the filtering mechanism may specifically include: identifier extension (IDE) bit filtering, ID segment filtering, firmware layer command word filtering, and driver layer empty message filtering.

[0129] In actual implementation, the above filtering mechanism is specifically implemented as follows: (1) IDE bit filtering: The CAN 2.0B protocol distinguishes between standard frames (IDE=0) and extended frames (IDE=1) by the IDE bit in the frame header. Motor manufacturers configure their CAN controllers (typically general-purpose CAN controllers such as MCP2515 / bxCAN / FlexCAN, etc.) hardware receive filters to only receive messages in their own frame format—the extended frame motor hardware filter only allows extended frames with IDE=1, discarding standard frames with IDE=0 before they are pushed into the controller's receive FIFO stack; standard frames are mirrored by the motor. This is the most comprehensive filter, ensuring that the message sets received by the two types of motors during broadcast transmission are completely mutually exclusive at the frame format level.

[0130] (2) ID segment filtering: The CAN controller matches the ID field according to the Acceptance Mask and Acceptance Code. Extended frame motors only receive extended frames whose ID is equal to their own motor ID (left arm 0x3D..0x43, right arm 0x33..0x39, etc.); standard frame motors only receive standard frames whose ID is equal to their own motor ID.

[0131] (3) Firmware layer command word filtering: After the message passes through the first two levels of filtering and enters the motor firmware, the firmware decodes the command type field commType (extended frame) or the first byte of the data field, the command word data[0] (standard frame). If the value is not within its own instruction set (commType ∈ {0x00, 0x03, 0x04, 0x06, 0x12, 0x16} etc. / data[0] ∈ {0x01, 0x07, 0x0A, 0x1F, 0x20, 0x21, 0x2A, 0x87, 0xFE} etc.), then the message is discarded according to the manufacturer's agreement, or an error response frame different from the normal response is returned. The specific error response byte is determined according to the manufacturer's agreement. This invention does not bind specific values, but only relies on the property-level condition that "unknown command words will trigger non-execution".

[0132] (4) Driver layer empty message filtering: For semantic layer differences such as "standard frame motor does not open PID and filter interface", this invention returns []CANMessage{}, nil in the driver implementation layer (LensArmEncoder), and no CAN frame will be generated on the corresponding bus.

[0133] In summary, if any one of the four levels of "hardware IDE → hardware ID segment → firmware command word → driver layer empty message" is active, the mismatched motor will not produce any actual action. In some embodiments, the servo motor filtering control message set includes control messages that do not match the servo motor, including: If the control command identifier of a mismatched control message is determined to be outside the target definition domain, the servo motor discards the mismatched control message. When a protocol-level error response frame is generated based on a mismatched control message, and the frame identifier of the protocol-level error response frame does not match the target feedback frame identifier, the unified aggregation layer discards the protocol-level error response frame.

[0134] In this embodiment, the target definition domain refers to the range of legal instruction sets supported and effectively parsed by the underlying firmware of the servo motor. For example, for a motor using the extended frame protocol, its target definition domain includes a preset set of legal command type fields (commType); for a motor using the standard frame protocol, its target definition domain includes a preset set of legal first byte command words (data[0]). When the control instruction identifier is not within the target definition domain, it indicates that the instruction is an unknown instruction for the motor.

[0135] The target feedback frame identifier refers to the characteristic identifier of a normal response frame that the upper-layer control system (such as the upper-layer response decoder) explicitly registers and expects to receive during the startup phase. It may include a frame ID of a specific pattern (such as containing a specific master station identifier segment) or a specific set of valid response command words.

[0136] In actual implementation, the above filtering mechanism combines downlink and uplink processes, as follows: First, regarding the downlink, refer to Figure 5 The filtering logic on the right side states that when the frame ID or command word of the control message received by the non-matched motor is not within its own defined domain, the control message will be filtered and discarded by the CAN hardware filter or the firmware layer.

[0137] Secondly, regarding the scenario where a non-matched motor generates a protocol-level error response frame, the unified aggregation layer uses a precise matching mechanism in the uplink to prevent the error frame from being mistakenly consumed. This is implemented in two levels: (1) Registration-based subscription of the upper layer (i.e., unified aggregation layer) response decoder: The response decoder explicitly registers the frame ID pattern to be consumed during the system startup phase. For extended frame motors: the response frame ID is in the form of (motorID&0xFF) |(0x00FD<<8) | ((respCommType&0x1F)<<24), where respCommType only takes several response classes corresponding to the request of this master station (typically "parameter readback response" or "existence ACK", etc., the specific value set is agreed upon by the manufacturer's protocol). The decoder accepts the request based on the condition that "master station identifier segment = 0x00FD and respCommType ∈ registered response set". For standard frame motors: the response frame ID is equal to the motor ID itself and data[0] is the response command word. The decoder accepts the request based on the condition that "frame ID ∈ the set of motor IDs it cares about and data[0] ∈ the set of registered response command words". The set of registered response command words does not overlap with the set of request command words under the manufacturer's protocol. The decoder does not consume any unregistered frame IDs or command word patterns, meaning it neither enters the callback chain nor updates any upper-level state.

[0138] (2) Three reasons why the ID of the non-matched motor error response frame must fall outside the subscription window: ① The command type or command word of the error frame must be different from the normal response - the error response commType returned by the extended frame motor firmware when encountering an unknown commType is not in the subscribed normal response commType set; the error response data[0] returned by the standard frame motor firmware when encountering an unknown data[0] is also not in the subscription set; ② The source motor ID of the error frame is still itself and does not impersonate other motors; ③ The frame format IDE bit is inconsistent with the decoder expectation - the two types of response decoders only subscribe to their own frame formats, and cross-frame format interference cannot be established. The uplink has two levels of rejection: the master station CAN controller receiving filter and the application layer decoder. Together, they make it impossible for the error response frame of the non-matched motor to reach any upper-layer semantic state.

[0139] According to the robot control method provided in this application, by sending control messages of multiple protocols in parallel, mismatched messages are naturally filtered by the underlying hardware filter and firmware layer. Simultaneously, based on the general property that request and response class identifier values ​​do not overlap, occasional abnormal feedback frames are automatically filtered, thereby reducing the system's dependence on specific manufacturer-specific response values. Furthermore, based on the aforementioned underlying passive failure mechanism, this solution constructs a hybrid drive mechanism for heterogeneous motors, combining simultaneous sending and silent ignoring, effectively reducing system cascading failures caused by model configuration mismatches. Based on this mechanism, the upper-layer system reduces its perception dependence on specific motor models, thus enabling the mixed installation of heterogeneous motors on the same control bus, thereby improving the flexibility and adaptability of the robot's overall hardware configuration.

[0140] It should be noted that the security of the aforementioned "broadcast + silent ignore" mechanism comes from two sources: First, the 29-bit ID space of the extended frame (including the master station identifier segment) and the 11-bit ID space of the standard frame fall within non-overlapping ID spaces at the CAN controller hardware filter level; second, when the firmware of both the extended frame motor and the standard frame motor receives a non-matching command word or register number, they both return an error frame according to the protocol. The frame ID of this error frame does not coincide with the expected feedback frame ID of the upper layer and therefore will not be consumed by the upper layer response decoder. During deployment, it should be verified that the ID allocation of other devices on the target CAN bus does not conflict with the above two types of ID spaces.

[0141] In some embodiments, where multiple execution units include multi-finger execution units and control instructions are directed to the multi-finger execution units, a preset control interface is invoked to generate a set of control messages, including: The first control instruction is parsed to obtain the target byte data corresponding to the multi-finger hand execution unit; Based on the communication protocol corresponding to the type of multi-finger execution unit, the target byte data is encapsulated into a multi-finger control message, and the multi-finger control message is incorporated into the control message set.

[0142] In this embodiment, target byte data refers to discrete byte values ​​used to characterize the expected gripping pressure of each finger in a multi-finger hand.

[0143] In actual execution, due to the differences in physical configuration of different types of multi-fingered hands, their corresponding control messages require different CAN message framing and splicing operations: For example, if the multi-finger execution unit is a six-finger hand (L6), then the L6HandEncoder controller is called to frame and encapsulate the target byte data of the six fingers according to the six-finger protocol requirements; If it is a ten-finger hand (L10), the system calls the L10HandEncoder controller to frame and encapsulate the target byte data of the ten fingers according to the ten-finger protocol requirements.

[0144] In some embodiments, the first control instruction is parsed to obtain target byte data corresponding to the multi-finger hand execution unit, including: The first control instruction is parsed to obtain the target floating-point pressure corresponding to the multi-finger execution unit; The target floating-point pressure is mapped to a fixed point to obtain the corresponding target byte data.

[0145] In this embodiment, fixed-point mapping is a linear mapping method that approximates continuous floating-point quantities as integers with finite bit width.

[0146] In actual execution, different multi-finger execution units (such as six-finger and ten-finger) can be based on a common floating-point pressure to byte normalization mapping logic.

[0147] In some embodiments, for each finger's normalized target floating-point pressure, the system maps it to corresponding target byte data according to the following logic: target = byte(round(pressure × 255)) Here, `target` represents the target byte data obtained through mapping, and `pressure` represents the normalized target floating-point pressure obtained, where `pressure` ∈ [0, 1]. The above mapping process is a linear lossy fixed-point processing with a fixed-point resolution of 1 / 255; in actual grasping tasks, this resolution is comparable to the granularity of human hand tactile perception.

[0148] It should be noted that the above-described normalized pressure resolution method also has the following alternative implementation methods: This invention uses byte(round(pressure × 255)) to approximate continuous pressure with an 8-bit fixed-point resolution. It can be expanded to 16-bit fixed-point (uint16(round(pressure × 65535))) and the continuous frame data field can be expanded accordingly; as long as the function of "linear fixed-point mapping of continuous pressure to finite-width integers" is retained, it is considered an equivalent replacement.

[0149] In some embodiments, based on the communication protocol corresponding to the type of multi-finger execution unit, the target byte data is encapsulated into a multi-finger control message, including: When the type of multi-finger execution unit is the first multi-finger execution unit, the corresponding target byte data and the first frame command word are encapsulated to generate a single frame control message; When the multi-finger execution unit is classified as a second multi-finger execution unit, the corresponding target byte data is split into a first data segment and a second data segment. The first data segment is encapsulated with the first frame command word to generate a first frame control message, and the second data segment is encapsulated with the continuation frame command word to generate a continuation frame control message.

[0150] In this embodiment, the single-frame control message, the first-frame control message, and the subsequent frame control messages share the same frame identifier.

[0151] The first multi-finger execution unit refers to a multi-finger device whose target byte data length does not exceed the upper limit of the effective payload length of a single frame of the control bus (such as the 8-byte upper limit of the CAN bus), such as a six-finger hand (L6) with 6 fingers.

[0152] The second multi-finger execution unit refers to a multi-finger hand device whose target byte data length exceeds the upper limit of the single frame payload of the control bus, such as a ten-finger hand with 10 fingers (L10).

[0153] The first and second data segments refer to the two data payloads obtained by splitting the total target byte data into two parts according to preset rules to meet the single frame length limit, due to the total target byte data being too long. For example, for a ten-fingered hand, the data of the first six fingers constitutes the first data segment, and the data of the last four fingers constitutes the second data segment.

[0154] In actual execution, the specific message encapsulation layout and framing logic for the two different types of multi-finger execution units mentioned above are as follows: First, for the first multi-finger execution unit (e.g., a six-finger hand), a single-frame layout is adopted: combined with Figure 6 The six-finger standard frame identifier (frame ID) is 0x28 (left hand) and 0x27 (right hand) for the left and right sides respectively; the data field layout of its control message is: data[0] = 0x01 (attitude first frame command word), data[1..6] respectively carry the pressure byte values ​​of the six fingers (i.e. Figure 6 (f0 to f5 in the data), this single-frame control message occupies a total of 7 bytes of data fields, which does not exceed the CAN single-frame limit.

[0155] Secondly, for the second multi-finger hand execution unit (e.g., a ten-finger hand), refer to Figure 6 The target pose of the ten-finger hand (i.e., the target pose vector of the ten fingers target[0..9]) consists of 10 fingers and 10 bytes, which exceeds the upper limit of 8 bytes of effective payload in a single CAN frame. Therefore, it is automatically split into two frames for transmission. Place the first 6 fingers ( Figure 6 The target byte data (f0..f5) is used as the first data segment, and together with the first frame command word, it is encapsulated to generate the first frame control message. Figure 6 f0..f5, a total of 7 bytes, that is: Frame 1 (first frame): data[0] = 0x01, data[1..6] = the byte value of finger 0..5.

[0156] Place the last four fingers ( Figure 6 The target byte data (f6..f9) is used as the second data segment, and together with the continuation frame command word, it is encapsulated to generate a continuation frame control message. Figure 6 f6..f9, a total of 5 bytes, that is: Frame 2 (continued): data[0] = 0x04, data[1..4] = the byte value of finger 6..9.

[0157] The first frame control message and the subsequent frame control message strictly share the same pair of frame identifiers (0x28 on the left and 0x27 on the right). The first frame and the subsequent frame are distinguished by the first byte of the data field command word (0x01 and 0x04).

[0158] In addition, for the speed control command of the ten fingers, the double-frame splitting logic uses the same pair of frame identifiers, with speed command words 0x05 and 0x06 as the first frame command word and the subsequent frame command word, respectively, which carry the normalized speed of the first data segment (fingers 0–4, i.e. f0..f4) and the second data segment (fingers 5–9, i.e. f5..f9).

[0159] It should be noted that the above-mentioned multi-finger framing strategy also has the following alternative implementation methods: For example, the current framing strategy for ten fingers is distributed in six plus four (command word 0x01 / 0x04), which can be replaced by other framing methods such as five plus five, seven plus three, eight plus two; for example, the shared frame ID can also be replaced by two adjacent standard frame IDs; however, as long as the two core points of "the same pair of frame IDs distinguishes the first frame from the subsequent frame by the first byte command word" and "floating-point pressure linearization" are retained, it can be regarded as an equivalent replacement.

[0160] According to the robot control method provided in this application, the normalized target floating-point pressure is mapped to discrete byte data through linear mapping, and dynamic encapsulation is implemented based on the upper limit of the effective payload of a single bus frame: the first multi-finger hand with data within the limit adopts a single-frame layout; the second multi-finger hand with data exceeding the limit is decomposed into a first frame and subsequent frames that share the same frame identifier and are distinguished only by the first byte command word. This scheme solves the limitation of the physical length of a single bus frame with low protocol overhead; at the same time, by allowing multi-finger hands with different physical configurations to share the identifier and command word template, they can share the same control interface at the upper layer, which reduces the complexity of the multi-finger hand control module, improves the flexibility of the robot's overall hardware configuration and the system's adaptability, and effectively reduces subsequent development and maintenance costs.

[0161] Step 130: The target servo motor drives the corresponding execution unit to run based on the matched control message.

[0162] In this step, the target servo motor refers to a specific servo motor whose physical hardware identifier or underlying firmware configuration on the robot's CAN control bus completely matches the identifier (such as the motorID parsed from the frame ID) contained in the currently issued control message. In a heterogeneous environment with multi-vendor assembly, the target servo motor is the designated execution subject for the current specific control command.

[0163] In actual execution, after successfully parsing the control message that matches its communication protocol and identifier, the target servo motor drives the connected execution unit to produce actual physical movements based on the specific control parameters carried in the message's data field. The execution unit may include a seven-degree-of-freedom joint of a robotic arm, or a multi-fingered dexterous hand execution unit such as a six-fingered hand or a ten-fingered hand.

[0164] The physical actions performed by the target servo motor correspond to the high-level control semantics issued by the upper controller, which may include: enabling, disabling, speed setting, acceleration setting, single joint angle setting, batch setting of joint angles, proportional-integral-derivative (PID) parameter tuning of position loop and speed loop, zeroing, and error clearing.

[0165] According to the robot control method provided in this application, through the matching and execution mechanism of the target servo motor, only the target servo motor matching the identifier will parse the message and accurately drive the corresponding execution unit (such as a robotic arm joint or a multi-finger dexterous hand) to produce actual physical movements each time a control message is sent. Thus, this application achieves precise physical driving for multi-vendor mixed-assembly execution units while significantly reducing the dependence of the upper-level motion control code on the underlying heterogeneous motor model perception, thereby realizing efficient collaboration and unified control of the entire robot body.

[0166] In some embodiments, prior to step 110, the method further includes: During the initialization phase, the first communication protocol probe is executed; If the first detection response is not received, the process reverts and executes the second communication protocol detection to obtain the device type and assembly location of the servo motor and actuator.

[0167] In this embodiment, the first communication protocol detection refers to the system prioritizing the issuance of detection messages in a specific format during the startup phase to detect and mark the corresponding motor equipment.

[0168] Secondary communication protocol probing refers to the process by which the system sends out a different format of probe message (such as a handshake probe frame of 11-bit standard frame) to conduct a secondary probe when no response is obtained in the first round of probe.

[0169] It should be noted that the communication protocols corresponding to the first and second communication protocol probes are respectively matched with the first and second communication protocols used to generate control messages.

[0170] Furthermore, the probe messages used in the first communication protocol probe have a longer frame identifier bit width than the probe messages used in the second communication protocol probe, and the former has more significant format characteristics (such as containing a specific master station identifier segment).

[0171] In actual implementation, refer to Figure 7 The automatic identification state machine logic during startup, as shown, includes the following specific execution process for automatic identification of arm type and left / right sides during startup: The arm-type detection module (hereinafter, taking UnifiedArmChecker as an example) performs device identification on each CAN bus during system startup. The overall identification process is uniformly scheduled in a higher-level detection entry point (hereinafter, taking DetectCANConfigs as an example), and specifically includes the following hierarchical detection and inference steps: First, extended frame priority detection is performed: the extended frame motor detector (RsArmChecker.DetectArmSide is used as an example below) is called on all CAN interfaces to be identified. If any interface receives a complete or partial extended frame response, the interface is marked as an extended frame motor type and its left / right side is further determined. This detection process is carried out in five steps within a preset time window (e.g., 200ms, which can be adjusted according to the deployment scenario): (1) Construction of probe message: According to the three-segment extended frame ID encoding method, construct an "existence query" message (commType = 0x00) for the 14 motor IDs in the left arm candidate ID set {61, 62, 63, 64, 65, 66, 67} and the right arm candidate ID set {51, 52, 53, 54, 55, 56, 57}. All data fields are 0, and the data length code DLC = 0 or 1.

[0172] (2) Synchronous message delivery: Following the principle of "broadcast + silent ignore", the above 14 frames are delivered to the CAN interface to be detected at once, without presetting the specific side position of the interface, which is determined by the response. Among them, the side position is a logical bit identifier used to distinguish the left and right in a dual-arm robot, with typical values ​​of Left=0 and Right=1.

[0173] (3) Response statistics: Open a 200ms receiving window. During the statistical period, the extended frame response received will still be recorded according to the main station's convention (main station identifier segment 0x00FD). Decode the motorID field and classify it: if it falls within the left arm set {61..67}, it will be included in the left arm response set S_L; if it falls within the right arm set {51..57}, it will be included in the right arm response set S_R; other illegal IDs will be regarded as bus noise and discarded.

[0174] (4) Classification and determination: Based on the size of the set, four categories are determined according to |S_L|, |S_R| and the threshold K (K=1 in the example, and the typical value can be adjusted according to the deployment scenario): ① Complete extended frame response (|S_L|=7 and |S_R|=0 or mirror case): Mark the extended frame motor type, and determine the side position according to the non-zero set; ② Partial extended frame response (1≤|S_L|<7 and|S_R|=0 or mirror case): still mark the extended frame motor type, the side position is determined by the non-zero set, and the missing joint is handed over to the upper layer log alarm; ③ No extended frame response (|S_L|=|S_R|=0): Returns ErrNoMotorResponsesDetected, and enters standard frame backtracking detection or left-right pairing inference, which will be explained in detail later.

[0175] ④ Left and right aliasing (|S_L|>0 and |S_R|>0): This should not happen in theory. It is considered a hardware configuration error and a recognition failure is reported, prompting manual intervention.

[0176] (5) Accept "partial response" instead of demanding "complete response": Allows for successful recognition even in boundary situations such as individual joint failure, initial start-up delay, and gradual activation of the CAN controller receive filter.

[0177] In some embodiments, if no first probe response is received, a fallback and execution of a second communication protocol probe are performed, including: If none of the interfaces to be identified return a valid response to the first communication protocol probe, the second communication protocol probe will be triggered and executed uniformly on all interfaces to be identified.

[0178] The protocol's fallback mechanism will be explained in detail below.

[0179] In some embodiments, the execution unit may include an arm execution unit and a hand execution unit (such as a multi-finger hand), and the servo motor corresponding to the execution unit may be connected via multiple control bus interfaces of the whole machine. The system reverts to and executes a second communication protocol detection to obtain the device type and assembly position of the servo motor and the execution unit, and further includes at least one of the following detection and reasoning steps: In the case where the first interface on one side returns a valid response and the second interface on the other side does not return a response, based on the physical constraint of the two arms being paired, the assembly position of the second interface is inferred to be the opposite side of the first interface, and the second interface is bound by default using a unified aggregation module. Based on the control bus interface of the whole machine, global device quotas are set. If there is only one unidentified interface, it is converged and inferred to be the only unassigned device type and side position. If the number of unidentified interfaces is greater than the first number, identification failure information is directly output. A probing two-frame message is sent to the interface assigned as the hand execution unit. If a valid response to both frames is received within a preset time window, the device type of the corresponding interface is determined to be the third multi-finger hand execution unit. If a valid response to the first frame is received, the device type of the corresponding interface is determined to be the fourth multi-finger hand execution unit. If no valid response is received, a fallback binding is performed according to the preset default multi-finger hand model, and a second verification is performed during runtime.

[0180] In this embodiment, the first interface and the second interface are respectively physically reserved as control bus interfaces for connecting the left and right candidate arm execution units.

[0181] The first quantity can be set to 1; An exploratory two-frame message may include an attitude first frame (such as containing a first frame command word) and an attitude continuation frame (such as containing a continuation frame command word).

[0182] The third multi-finger execution unit refers to a complex multi-finger device that supports and responds to multi-frame gesture commands (e.g., a ten-finger L10 with firmware that supports parsing continuous frames).

[0183] The fourth multi-finger execution unit refers to a basic multi-finger device that only supports and responds to single-frame gesture commands (such as a six-finger L6 that performs firmware to perform natural filtering of consecutive frames).

[0184] The global equipment quota refers to the upper limit of the types and quantities of equipment set based on the actual hardware assembly of the robot (for example, it is agreed that the whole machine includes "two arms and two hands").

[0185] According to the robot control method provided in this application, for device identification during the startup phase, a multi-level automatic identification mechanism is adopted, including extended frame priority detection, standard frame backtracking detection, left-right pairing reasoning, and whole-machine device uniqueness reasoning. First, single-sided device identification is completed on each of the underlying control buses. Then, a higher-level detection entry performs total allocation and remaining uniqueness reasoning based on global quotas. This two-layer collaborative architecture enables the robot to autonomously complete accurate mapping between ports and devices even in complex assembly scenarios with disordered physical wiring or unknown motor models. Furthermore, this solution effectively reduces the risk of system control failures caused by model and port mismatches during operation, reducing on-site deployment and manual troubleshooting costs while improving the flexibility and adaptability of the robot's overall hardware configuration.

[0186] The following describes the specific execution process of the aforementioned standard frame backtracking detection, left-right pairing inference, and subsequent device uniqueness and model identification.

[0187] Standard frame back-off detection: The system will only call the standard frame motor detector to issue standard frame commands (using LensArmChecker.DetectArmSide as an example below) to all interfaces when none of the CAN interfaces to be identified have obtained any valid response during the extended frame detection phase (i.e., return an error such as "no motor response", for example, ErrNoMotorResponsesDetected).

[0188] Left-right pairing reasoning: This reasoning mechanism is triggered in the precise binary boundary case where "only one of the two candidate arm CAN interfaces responds, and the other remains completely silent." It performs deterministic completion based on the physical constraint that "both arms are paired left and right," and is elaborated in five points: (1) Triggering condition: The results of the two candidate arm interfaces IF_A and IF_B have been obtained through the aforementioned extended frame priority detection and the standard frame back-off detection when necessary: ​​IF_A has been identified as the left or right side; IF_B has no response under both extended frame and standard frame detection.

[0189] (2) Physical constraints: Based on the fact that a dual-arm humanoid or collaborative robot has exactly one left arm and one right arm, that is, the side set of interface A and interface B is always equal to the binary set {left, right} (for example, the binary set {IF_A.Side, IF_B.Side}={Left, Right} always holds true), there will be no situation where both interfaces are both left or both are both right.

[0190] (3) Reasoning action: If interface A is identified as the left side (IF_A.Side=Left), then directly infer that interface B is the right side (IF_B.Side=Right), and vice versa.

[0191] For interface B (IF_B), the "Motor Series Type" (extended frame or standard frame) should be completed using the following two methods: ① Default path – UnifiedArmEncoder placeholder binding (main path). Considering that this invention explicitly allows heterogeneous motors to be mixed on the CAN bus, the motor series of IF_B is actually undeterminable when there is no response; during startup, the unified aggregation module UnifiedArmEncoder is used as a placeholder (simultaneously holding two implementations and issuing them in parallel according to the "broadcast + silent ignore" mechanism, which can correctly drive both types of motor series), even if it is found to be a different motor series during operation, there is no need to restart the identification. This is consistent with the aforementioned mechanism of "constructing UnifiedArmEncoder when heterogeneous or unknown model".

[0192] ② Optional Optimization – Conservative Type Inheritance. If the deployer explicitly declares "force both arms to be the same model" in the configuration file (typically for finished models from a single supplier), this option can be enabled to allow IF_B to directly inherit the motor series type already identified by IF_A, saving the overhead of dual parallel connection of UnifiedArmEncoder; this is not the default behavior.

[0193] (4) Runtime backflow verification: The above inference is a placeholder inference during startup, not a permanent binding. When any CAN frame is received on IF_B during operation, it is verified according to "the frame format (IDE bit) is consistent with the inference type and the motor identifier motorID falls into the corresponding side bit (left 61..67 / right 51..57)". If they are inconsistent, an alarm is triggered and manual intervention is required to prevent cascading failures caused by misinference.

[0194] (5) Determine the boundary and fallback: This reasoning mechanism only takes effect in the precise binary case of "one side responds and the other side is silent"; if neither interface responds, it will proceed to the subsequent whole device uniqueness reasoning or directly report the identification failure; if both interfaces respond, they will independently complete the identification according to the aforementioned extended frame priority detection or standard frame fallback detection description, without the need for pairing.

[0195] According to the robot control method provided in the embodiments of this application, based on the above differences, the detection message with more significant features is sent first, which can effectively reduce the device misidentification rate in heterogeneous environments; only when no response is received will it fall back to the second communication protocol detection, thereby improving the accuracy and stability of automatic mapping between ports and devices.

[0196] The following explains the uniqueness reasoning of the whole machine and the automatic identification of multi-finger hand models.

[0197] Uniqueness reasoning for the whole device: The higher-level detection entry performs a total allocation for the four CAN interfaces according to the total quota of "two arms + two hands". When at most one interface remains unidentified, it is inferred as the unique unassigned category and position according to the principle of "unique remaining device".

[0198] Automatic identification of multi-fingered hand types: After completing the aforementioned two-way arm identification, the remaining two interfaces have been allocated as "left hand" or "right hand" according to the total quota. The system performs the following four sub-steps for each interface assigned as a hand to automatically distinguish between a six-fingered hand (L6) and a ten-fingered hand (L10): (a) Tentative two-frame transmission: L10 style two-frame handshake - first frame (ID = 0x28 or 0x27, data[0] = 0x01, data[1..6] = 0xFF × 6) + subsequent frame (same ID, data[0] = 0x04, data[1..4] = 0xFF × 4), open a 100ms receiving window (can be adjusted according to deployment scenario); (b) Relay Frame Response Feature Comparison: The comparison and judgment rely solely on the objective condition that "L6 and L10 are necessarily distinguishable in their response behavior to the relay frame command word 0x04": The L10 firmware recognizes both the 0x01 first frame and the 0x04 relay frame as valid attitude commands and generates ACK responses respectively. Therefore, if the upper layer observes ACK responses to both 0x01 and 0x04 simultaneously within the receiving window, it is determined to be L10.

[0199] Conversely, the L6 firmware recognizes the first frame 0x01 as a valid attitude command and ACKs it, but does not respond to subsequent frames 0x04 because the command word is not in the L6 instruction set, or returns an error response that is different from the normal ACK. Therefore, if the upper layer only observes the ACK response to 0x01 and does not observe the ACK response to 0x04, it is determined to be L6; it should be noted that the specific ACK response byte is determined according to the manufacturer's agreement, and this invention does not bind the specific response byte value.

[0200] (c) Silent fallback: If no ACK response is observed for 0x01 and 0x04 in the window, "User configuration rollback" is triggered: the multi-finger hand implementation layer of the interface is bound according to the default configuration in the deployment file (e.g., hand_type_default, L6 in the example), and an alarm is sent to the upper-level log "Hand recognition not confirmed, bound according to the default model, please verify finger action during runtime". Here, finger action is a tuple consisting of finger number and normalized pressure {FingerID, Pressure ∈ [0, 1]}.

[0201] (d) Runtime backflow verification: Similar to the left and right pairing reasoning mentioned above, after the first valid response frame of the interface is received during the runtime, the model is verified again according to the frame layout; if the model is inconsistent with the determination during the startup period, an alarm is triggered and manual intervention is required.

[0202] It should be noted that the aforementioned "automatic identification during startup" method can be completed through inference based on the "uniqueness of remaining devices" in the boundary case where at most one interface is unresponsive. When more than one interface is unresponsive, the arm-type detection module should return an identification failure and prompt manual intervention from the upper layer to prevent erroneous inferences in highly uncertain scenarios. The boundary threshold (at most one unresponsive) is a typical value in the embodiment and can be adjusted according to the deployment scenario.

[0203] According to the robot control method provided in this application, for the automatic identification of multi-finger hand models, this application reuses the differences in response behavior of existing command words as judgment features, without relying on additional dedicated handshake instructions or firmware modifications, thus improving the compatibility of different hardware access. Simultaneously, this solution adopts a passive observation of continuous frame responses instead of active discrimination based on specific firmware versions, effectively avoiding the comparison risks caused by inconsistent manufacturer version definitions and enhancing the robustness of the identification logic. Furthermore, this mechanism uses a configurable fallback strategy instead of hard error reporting in case of abnormal no response, preventing the system from being blocked due to temporary communication jitter during startup, and performs backflow verification in conjunction with the first successful response during runtime, further improving the accuracy and stability of model identification while ensuring smooth system startup.

[0204] The end-to-end overall process for implementing the robot control method of this application is described below: This application, based on the robot control methods provided in any of the foregoing embodiments, collectively constitutes the end-to-end hybrid drive and adaptation process of the present invention, including: [During system startup phase] │ ① Call the high-level detection entry DetectCANConfigs to perform automatic identification on all CAN interfaces; ▼ [Received arm / hand CAN allocation results] │ ② Construct the corresponding ArmEncoder interface instance based on the identified device type or user preset configuration; (Specifically, when heterogeneous motors are detected or the motor model is unknown, an instance of the UnifiedArmEncoder module is automatically constructed.) ▼ [Start of control loop] │ ③ The upper layer calls the ArmEncoder interface methods (SetAngles, etc.) to initiate a control request; │ ④ The unified aggregation module generates both extended frames and standard frames simultaneously. │ ⑤ The finger control module performs floating-point pressure normalization processing and CAN message frame splicing in parallel; ▼ [CAN Bus Interface Module] │ ⑥ The various messages generated in parallel above are uniformly and sent to each CAN bus in parallel; ▼ [The target servo motors in each execution unit are driven by matched control messages, while unmatched motors are naturally filtered based on hardware filters or firmware layer logic.] This application constructs a heterogeneous hardware integrated adaptation architecture that encompasses "Unified Arm Encoder Interface", "Broadcast-and-Silently-Ignore", and "Automatic Arm-Type and Side Detection during startup". This architecture relates to the control of humanoid robots, dual-arm cooperative robots, and multi-fingered dexterous hands, as well as the field of servo motor drive technology based on the Controller Area Network (CAN) bus. It also relates to methods for floating-point pressure normalization and CAN message multi-frame segmentation for six-fingered hands (L6) and ten-fingered hands (L10). Specifically, it involves a method for unified abstraction and hybrid drive of heterogeneous servo motor actuators using different CAN frame formats (including 11-bit standard frames and 29-bit extended frames), different command systems (including command word / register write hybrid systems), and different manufacturers' series within the same robot control software stack.

[0205] The technical problem this solution aims to solve is: how to allow servo motors and multi-finger actuators from different manufacturers, using different CAN frame formats (11-bit standard frame / 29-bit extended frame), different command systems (command word / register write), and different parameter open granularities (open PID / closed PID) to be mixed on the same CAN bus in a single robot body, while significantly reducing the dependence on upper-level motion control code perception, and to achieve automatic identification of arm type and left and right sides during the system startup phase, while reducing the risk of cascading failures caused by model-port mismatch from a mechanistic perspective.

[0206] Based on the above scheme, the overall mechanism is executed in two stages, namely the startup phase and the control phase, in series, achieving the following technical effects: First, in the startup phase, all port-device mappings can be established through a single identification, eliminating the need for complex model branch judgments in the control phase; Second, each instruction issued in the control phase adopts passive matching of "broadcast + natural filtering" rather than active matching of "table lookup + active distribution", thus avoiding the risk of cascading failure due to model table mismatch from a mechanistic perspective; Third, multi-finger hand control and arm motor control run in parallel under the same interface, achieving a high degree of consistency of the upper-level calling interface.

[0207] It should be noted that the above-mentioned automatic identification algorithm also has the following alternative implementation methods: The arm type detection module of the present invention currently adopts a two-level priority of extended frame priority and standard frame backoff, which can be extended to traverse any number of registered motor detectors according to the priority queue; the left and right pairing reasoning can also be replaced by template matching based on the joint response ID pattern or inference based on the timing of the first joint response; the whole device uniqueness reasoning can also be replaced by statistical inference based on multiple scan voting; but as long as the two functions of "probing step by step according to priority + convergence of the uniqueness of the remaining devices" are retained, it can be regarded as an equivalent replacement.

[0208] In one specific embodiment of this application, the unified interface layer, the extended frame motor implementation layer, the standard frame motor implementation layer, the unified aggregation module, the arm type detection module, and the multi-finger hand control module can be implemented based on Go language and uniformly encapsulated under the encoder module of the robot body control software stack; The CAN bus interface module can be based on a cross-platform CAN driver, with the control layer and transport layer interfacing via the CANMessage data structure. The upper-layer kinematics module and task planning module each hold only one ArmEncoder interface type variable. During startup, the actual implementation selects one of three implementation types (extended frame implementation, standard frame implementation, and unified aggregation implementation) based on the device type and the automatic identification results from the left and right sides.

[0209] The parameters of the specific implementation can be adjusted according to the deployment environment: when expanding the third type of motor, only one ArmEncoder interface needs to be added and an aggregation member needs to be added in the unified aggregation module; when expanding the number of fingers in a multi-finger hand, only the command word and continuation frame layout need to be added according to the frame splitting principle of the aforementioned multi-finger hand pressure normalization and multi-frame splicing method; no changes are required to the upper-level code.

[0210] It should be noted that the extended frame master station identifier 0x00FD, the left arm motor ID set {61, 62, 63, 64, 65, 66, 67}, the right arm motor ID set {51, 52, 53, 54, 55, 56, 57}, and the multi-finger left and right frame IDs {0x28, 0x27} provided in this embodiment are typical values ​​of the embodiment and do not constitute a limitation on the scope of protection of this invention; in specific deployment, they can be uniformly calibrated according to the robot model, motor manufacturer agreement, and CAN bus planning.

[0211] The robot control method in this application is applicable to any mixed-assembly scenario of servo motors that are consistent in high-level semantics but differ in low-level CAN protocol, and is not limited to dual-arm humanoid robots. In scenarios such as the lower limb servo chain of bipedal humanoid robots, the multi-joint hybrid supply chain configuration of collaborative robotic arms, and the hybrid access of mobile operation robot chassis and robotic arms, the embodiments provided in steps 110 to 130 can be reused. Only more implementation layer instances beyond the extended frames need to be added to the unified aggregation module as needed.

[0212] The specific implementation of the robot control method in this application is presented using Go language as an example. Its deployment form does not constitute a limitation on the present invention. In scenarios that require lower memory usage or embedded deployment, the encoder module can be rewritten in C or Rust.

[0213] 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.

[0214] This application also provides a robot control device.

[0215] like Figure 8 As shown, the robot control device includes: a first processing module 810, a second processing module 820, and a third processing module 830.

[0216] The first processing module 810 is used to respond to a first control command containing a target servo motor identifier by calling a preset control interface to generate a set of control messages corresponding to the target servo motor identifier; the set of control messages includes multiple control messages, each of which is obtained by encapsulating the target servo motor identifier according to a communication protocol that matches the communication model of each servo motor. The second processing module 820 is used to obtain the control message matching the communication model corresponding to the target servo motor from the control message set for the target servo motor that corresponds to the target servo motor identifier. The third processing module 830 is used to drive the corresponding execution unit to run based on the matched control message of the target servo motor.

[0217] According to the robot control device provided in this application embodiment, a preset control interface is constructed within the same robot body control software stack by uniformly abstracting the underlying heterogeneous servo motors. When responding to control commands, by calling this preset control interface, a set of control messages containing multiple communication protocols can be generated, allowing the target servo motor to autonomously match and extract control messages matching its communication model from this set. Through this mechanism, the upper-level command distribution logic in the robot is decoupled from the specific communication format of the underlying motors, effectively shielding the differences in communication protocols between heterogeneous motors. Hybrid driving of heterogeneous motors can be achieved without significant modifications to the upper-level control code, thereby improving the flexibility of the robot's overall hardware configuration and the system's adaptability, and reducing subsequent development and maintenance costs.

[0218] In some embodiments, the preset control interface defines a general set of control operations for servo motors, and the preset control interface includes a unified aggregation layer and multiple implementation layers respectively set for different communication protocols; the first processing module 810 can also be used for: The unified aggregation layer determines the corresponding target control operation from the general control operation set according to the first control instruction, and calls the control operation corresponding to the target control operation in each implementation layer; wherein, the general control operation set is constructed based on the common control functions of each execution unit; Each invoked implementation layer encapsulates the target servo motor identifier based on its corresponding communication protocol, and generates and returns the corresponding control message and parameter-level error. The unified aggregation layer obtains the control messages returned by each implementation layer and discards the parameter-level errors returned by each implementation layer; The unified aggregation layer merges the acquired control messages to obtain a set of control messages.

[0219] In some embodiments, the robot control method further includes a fourth processing module for: The servo motor filter control message set contains control messages that do not match the servo motor.

[0220] In some embodiments, the fourth processing module can also be used for: If the control command identifier of a mismatched control message is determined to be outside the target definition domain, the servo motor discards the mismatched control message. When a protocol-level error response frame is generated based on a mismatched control message, and the frame identifier of the protocol-level error response frame does not match the target feedback frame identifier, the unified aggregation layer discards the protocol-level error response frame.

[0221] In some embodiments, where the plurality of execution units include multi-finger execution units and the control instructions are directed to the multi-finger execution units, the first processing module 810 may further be used to: The first control instruction is parsed to obtain the target byte data corresponding to the multi-finger hand execution unit; Based on the communication protocol corresponding to the type of multi-finger execution unit, the target byte data is encapsulated into a multi-finger control message, and the multi-finger control message is incorporated into the control message set.

[0222] In some embodiments, the first processing module 810 may also be used for: Based on the communication protocol corresponding to the type of multi-finger execution unit, the target byte data is encapsulated into a multi-finger control message, including: When the type of multi-finger execution unit is the first multi-finger execution unit, the corresponding target byte data and the first frame command word are encapsulated to generate a single frame control message; When the type of multi-finger execution unit is the second multi-finger execution unit, the corresponding target byte data is split into a first data segment and a second data segment, and the first data segment is encapsulated with the first frame command word to generate a first frame control message, and the second data segment is encapsulated with the continuation frame command word to generate a continuation frame control message. The single-frame control message, the first-frame control message, and the subsequent frame control messages all share the same frame identifier.

[0223] In some embodiments, the robot control method further includes a fifth processing module, configured to: During the initialization phase, the first communication protocol probe is executed; If the first detection response is not received, the process reverts and executes the second communication protocol detection to obtain the device type and assembly location of the servo motor and actuator.

[0224] 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 implementation.

[0225] The robot control device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0226] The robot control device provided in this application embodiment can achieve... Figures 1 to 7 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0227] In some embodiments, such as Figure 9 As shown, this application embodiment also provides an electronic device 900, including a processor 901, a memory 902, and a computer program stored in the memory 902 and executable on the processor 901. When the program is executed by the processor 901, it implements the various processes of the above-described robot control method embodiment and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0228] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0229] This application also provides a non-transitory computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described robot control method embodiments and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0230] 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.

[0231] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described robot control method.

[0232] 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.

[0233] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described robot control method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0234] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0235] 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 apparatuses 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. Additionally, features described with reference to certain examples may be combined in other examples.

[0236] 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.

[0237] 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 can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

[0238] In the description of this specification, the references to "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.

[0239] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations 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.< / method> < / method> < / method>

Claims

1. A robot control method, characterized in that, The robot includes multiple execution units and multiple servo motors for driving each of the execution units. The method includes: In response to a first control command containing a target servo motor identifier, a preset control interface is invoked to generate a set of control messages corresponding to the target servo motor identifier; the set of control messages includes multiple control messages, each of which is obtained by encapsulating the target servo motor identifier according to a communication protocol that matches the communication model of each servo motor; The target servo motor that corresponds to the target servo motor identifier in the servo motor is obtained from the control message set, and the control message that matches the communication model corresponding to the target servo motor is obtained. The target servo motor drives the corresponding execution unit to run based on the matched control message.

2. The robot control method according to claim 1, characterized in that, The preset control interface defines a set of general control operations for the servo motor, and the preset control interface includes a unified aggregation layer and multiple implementation layers set for different communication protocols. The step of calling the preset control interface to generate a set of control messages corresponding to the target servo motor identifier includes: The unified aggregation layer determines the corresponding target control operation in the general control operation set according to the first control instruction, and calls the control operation corresponding to the target control operation in each implementation layer; wherein, the general control operation set is constructed based on the common control functions of each execution unit; Each of the invoked implementation layers encapsulates the target servo motor identifier based on its corresponding communication protocol, and generates and returns the corresponding control message and parameter-level error. The unified aggregation layer acquires the control messages returned by each of the implementation layers and discards the parameter-level errors returned by each of the implementation layers; The unified aggregation layer merges the acquired control messages to obtain the control message set.

3. The robot control method according to claim 2, characterized in that, The plurality of implementation layers includes a first implementation layer and a second implementation layer; wherein... The control message generated by the first implementation layer is a first control message encapsulated according to the first communication protocol. The frame identifier of the first control message includes the target servo motor identifier, the master station identifier, and the command type. The control message generated by the second implementation layer is a second control message encapsulated according to the second communication protocol. The frame identifier of the second control message includes the target servo motor identifier, and the data field of the second control message contains a command word.

4. The robot control method according to any one of claims 1-3, characterized in that, The method further includes: The servo motor filters out control messages from the control message set that do not match the servo motor.

5. The robot control method according to claim 4, characterized in that, The servo motor filters control messages in the control message set that do not match the servo motor, including: If it is determined that the control instruction identifier of the mismatched control message is not within the target definition domain, the servo motor discards the mismatched control message; If a protocol-level error response frame is generated based on the mismatched control message, and the frame identifier of the protocol-level error response frame does not match the target feedback frame identifier, the unified aggregation layer discards the protocol-level error response frame.

6. The robot control method according to any one of claims 1-3, characterized in that, When the plurality of execution units includes a multi-finger execution unit, and the control command is directed to the multi-finger execution unit, the step of calling the preset control interface to generate a set of control messages includes: The first control instruction is parsed to obtain the target byte data corresponding to the multi-finger hand execution unit; Based on the communication protocol corresponding to the category of the multi-finger execution unit, the target byte data is encapsulated into a multi-finger control message, and the multi-finger control message is incorporated into the control message set.

7. The robot control method according to claim 6, characterized in that, The communication protocol based on the category of the multi-finger execution unit encapsulates the target byte data into a multi-finger control message, including: When the type of the multi-finger execution unit is the first multi-finger execution unit, the corresponding target byte data and the first frame command word are encapsulated to generate a single frame control message; When the type of the multi-finger execution unit is the second multi-finger execution unit, the corresponding target byte data is split into a first data segment and a second data segment, and the first data segment is encapsulated with the first frame command word to generate a first frame control message, and the second data segment is encapsulated with the continuation frame command word to generate a continuation frame control message. The single-frame control message, the first-frame control message, and the subsequent-frame control message all share the same frame identifier.

8. The robot control method according to any one of claims 1-3, characterized in that, Before invoking a preset control interface to generate a set of control messages corresponding to the target servo motor identifier in response to a first control command containing the target servo motor identifier, the method further includes: During the initialization phase, the first communication protocol probe is executed; If the first detection response is not obtained, the process reverts and executes the second communication protocol detection to obtain the device type and assembly position of the servo motor and the execution unit.

9. A robot control device, characterized in that, The robot includes multiple execution units and multiple servo motors for driving each of the execution units. The device includes: The first processing module is configured to respond to a first control command containing a target servo motor identifier by calling a preset control interface to generate a set of control messages corresponding to the target servo motor identifier; the set of control messages includes multiple control messages, each of which is obtained by encapsulating the target servo motor identifier according to a communication protocol that matches the communication model of each servo motor. The second processing module is used to obtain, from the control message set, a control message matching the communication model corresponding to the target servo motor from the target servo motor that corresponds to the target servo motor identifier. The third processing module is used to drive the corresponding execution unit to run based on the matched control message of the target servo motor.

10. A robot, characterized in that, include: Multiple execution units; Multiple servo motors; each servo motor is connected to a corresponding execution unit for driving each execution unit; The robot control device as described in claim 9 is electrically connected to the servo motor and the execution unit, respectively.

11. 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-8.

12. 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-8.

Images