Hierarchical driving adaptation method, device and storage medium for robot effector

Abstract

The application relates to the field of robot motion control, and provides a layered driving adaptation method and device of a robot executor and a storage medium. The method comprises the following steps: receiving a motion instruction; converting the motion instruction into a unified motion intermediate representation through a motion abstraction layer; querying an executor configuration file to obtain capability parameters and a protocol type of a target bottom-layer executor, and mapping the unified motion intermediate representation into target driving protocol data matched with the protocol type through an adapter mapping framework; delivering the target driving protocol data to the corresponding bottom-layer executor before a preset deadline through a driving adapter interface, and reading hardware feedback and standardizing the same into general state feedback; dynamically evaluating a current control quality index, and triggering an adapter mapping parameter reconfiguration process when the control quality index is lower than a preset threshold. The technical scheme of the application realizes decoupling of the motion instruction and the executor hardware, and improves the reusability of the control logic.

Description

Technical Field

[0001] This application relates to the field of robot motion control, and in particular to a hierarchical drive adaptation method, apparatus and storage medium for a robot actuator. Background Technology

[0002] With the rapid development of industrial automation, collaborative robots, mobile robots, and embodied intelligent systems, the types of actuators integrated into robot platforms are becoming increasingly diverse. Common actuators include servo motors, stepper motors, servo motors, linear motors, hydraulic actuators, pneumatic actuators, mobile chassis, and grippers. These actuators often employ different communication protocols and control interfaces, such as CANopen, EtherCAT, PWM, UART, Modbus, and analog signals, and their control quantities, ranges, feedback methods, and response delay characteristics vary significantly.

[0003] In existing technologies, the control of the aforementioned heterogeneous actuators typically employs solutions based on distributed middleware such as ROS / ROS2 and connecting various nodes via asynchronous messaging; solutions relying on traditional programmable logic controllers or dedicated motion control cards and focusing on low-level I / O or single-axis motion control; or solutions that directly write specific drivers for each actuator, resulting in tight coupling between the upper-level control logic and the specific hardware. Because these existing solutions use different protocols, control units, and feedback characteristics that are inconsistent across actuators, the upper-level control logic cannot be reused across actuators. Each time an actuator is replaced or added, the upper-level control code needs to be redeveloped or modified, severely impacting the scalability and development efficiency of the robot system. Summary of the Invention

[0004] This application provides a hierarchical drive adaptation method, device, and storage medium for robot actuators, which decouples motion commands from actuator hardware and improves the reusability of control logic.

[0005] On one hand, this application provides a hierarchical drive adaptation method for robot actuators. This method is applied to a hierarchical control system architecture that includes upper-level control logic or task planners, a motion abstraction layer, an adapter mapping framework, a drive adapter interface, and lower-level actuators. The method includes: Step S1: Receive the motion command MotionCommand generated by the upper-level control logic or task planner, which is independent of the actuator; Step S2: Through the motion abstraction layer, the motion instructions are converted into a unified motion intermediate representation, which is a standard motion description data structure that is independent of the actuator, verifiable, and compilable. Step S3: Query the actuator configuration file to obtain the capability parameters and protocol type of the target underlying actuator, and map the unified motion intermediate representation to target driver protocol data that matches the protocol type through the adapter mapping framework; Step S4: Through the driver adapter interface, send the target driver protocol data to the corresponding underlying actuator before the preset deadline, and read the hardware feedback and standardize it into a general status feedback. Step S5: During the execution of the hierarchical drive adaptation method for the robot actuator, the current control quality index is dynamically evaluated based on the deviation between the general state feedback and the unified motion intermediate representation. When the control quality index is lower than a preset threshold, the following adapter mapping parameter reconfiguration process is triggered: query the preset quality degradation compensation table in the actuator configuration file to obtain the compensation parameters corresponding to the current deviation type and magnitude; dynamically adjust at least one conversion rule in the adapter mapping framework according to the compensation parameters, the conversion rule including unit conversion factor, nonlinear compensation curve or frame format mapping relationship; apply the adjusted conversion rule to the mapping process of the target drive protocol data.

[0006] On the other hand, this application provides a hierarchical drive adapter device for a robot actuator. The device is applied to a hierarchical control system architecture that includes upper-level control logic or a task planner, a motion abstraction layer, an adapter mapping framework, a drive adapter interface, and lower-level actuators. The device includes: The instruction receiving module is used to receive motion instructions (MotionCommand) generated by the upper-layer control logic or task planner that are independent of the actuator. The generation module is used to convert the motion instructions into a unified motion intermediate representation through the motion abstraction layer. The unified motion intermediate representation is a standard motion description data structure that is independent of the actuator, verifiable, and compilable. The mapping module is used to query the executor configuration file, obtain the capability parameters and protocol type of the target underlying executor, and map the unified motion intermediate representation to target driver protocol data that matches the protocol type through the adapter mapping framework; The standardization module is used to send the target driver protocol data to the corresponding underlying actuator before a preset deadline through the driver adapter interface, and to read the hardware feedback and standardize it into a general status feedback. The adjustment module is used during the process of the device executing the hierarchical drive adaptation method for the robot actuator to dynamically evaluate the current control quality index based on the deviation between the general state feedback and the unified motion intermediate representation. When the control quality index is lower than a preset threshold, the following adapter mapping parameter reconfiguration process is triggered: querying the preset quality degradation compensation table in the actuator configuration file to obtain the compensation parameters corresponding to the current deviation type and magnitude; dynamically adjusting at least one conversion rule in the adapter mapping framework according to the compensation parameters, the conversion rule including unit conversion factor, nonlinear compensation curve or frame format mapping relationship; and applying the adjusted conversion rule to the mapping process of the target drive protocol data.

[0007] Thirdly, this application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the technical solution of the hierarchical drive adaptation method for robot actuators described above.

[0008] Fourthly, this application provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of the hierarchical drive adaptation method for robot actuators described above.

[0009] As can be seen from the technical solutions provided in this application, on the one hand, by receiving motion instructions generated by the upper-level control logic or task planner that are independent of the actuator, the motion instructions are converted into a unified intermediate motion representation, so that the upper-level control logic no longer depends on the physical characteristics and protocol details of a specific actuator, thereby achieving decoupling between motion instructions and actuator hardware; on the other hand, by querying the actuator configuration file to obtain the capability parameters and protocol type of the target actuator, and using the adapter mapping framework to map the standardized motion intent into target driving protocol data, the same set of upper-level control logic can automatically adapt to different types of actuators, significantly improving the reusability of motion control logic; thirdly, by issuing instructions before the preset deadline through the drive adapter interface and reading hardware feedback to standardize it into general status feedback, the real-time performance and traceability of instruction execution are guaranteed, while providing a unified execution status view for the upper-level control logic; fourthly, through this dynamic, closed-loop adaptive adjustment mechanism, the slow degradation of actuator performance or changes in environmental characteristics can be automatically compensated without interrupting operation, thereby maintaining high-precision control performance over a long time scale, significantly improving the reliability of the robot system and the flexibility of maintenance cycles. In summary, this application effectively solves the problem of the inability to reuse upper-level control logic due to differences in actuator protocols and characteristics in the prior art, and improves the scalability, real-time performance, engineering deployability, and maintenance cycle flexibility of the robot system. Attached Figure Description

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

[0011] Figure 1 This is a flowchart of the layered drive adaptation method for robot actuators provided in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the layered drive adapter device for the robot actuator provided in the embodiments of this application; Figure 3 This is a schematic diagram of the device provided in the embodiments of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] In this specification, adjectives such as "first" and "second" are used only to distinguish one element or action from another, without necessarily requiring or implying any actual such relationship or order. Where circumstances permit, reference to an element or component or step (etc.) should not be construed as being limited to only one of the elements, components, or steps, but may be one or more of the elements, components, or steps, etc.

[0014] For ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn to actual scale.

[0015] In existing technologies, the control of the aforementioned heterogeneous actuators typically employs solutions based on distributed middleware such as ROS / ROS2 and connecting various nodes via asynchronous messaging; solutions relying on traditional programmable logic controllers or dedicated motion control cards and focusing on low-level I / O or single-axis motion control; or solutions that directly write specific drivers for each actuator, resulting in tight coupling between the upper-level control logic and the specific hardware. Because these existing solutions use different protocols, control units, and feedback characteristics that are inconsistent across actuators, the upper-level control logic cannot be reused across actuators. Each time an actuator is replaced or added, the upper-level control code needs to be redeveloped or modified, severely impacting the scalability and development efficiency of the robot system.

[0016] To address the aforementioned problems in existing technologies, this application proposes a hierarchical driver adaptation method for robot actuators, applicable to a hierarchical control system architecture comprising an upper-level control logic or task planner, a Motion Abstraction Layer (MAL), an Adapter Mapping Framework (AMF), a Driver Adapter Interface, and a lower-level actuator. Here, in this application, the Motion Abstraction Layer refers to a functional layer located between the upper-level control logic or task planner and the adapter mapping framework. This layer receives motion commands independent of the actuator, performs unit normalization, amplitude limiting, and trajectory interpolation on these commands, and finally outputs a unified intermediate motion representation. A flowchart of the hierarchical driver adaptation method for robot actuators proposed in this application is attached. Figure 1 As shown, it mainly includes steps S1 to S5, which are detailed below: Step S1: Receive motion instructions generated by the upper-level control logic or task planner that are independent of the actuator.

[0017] In robot control systems, upper-level control logic or task planners, such as AI strategies, Python SDKs, manual configurations, etc., typically generate a high-level semantic motion instruction, such as "move to position 0.1 meters, speed 0.05 meters / second". However, different actuators interpret "position" and "speed" differently: some actuators use millimeters as the unit of length, while others use radians as the unit of angle; some actuators expect to receive pulse counts, while others expect to receive analog voltage values. Furthermore, instructions issued by upper-level control logic or task planners may contain missing fields, values ​​outside the reasonable range, or format errors. If directly sent to the actuators, these can lead to anything from abnormal motion to serious hardware damage.

[0018] To address the aforementioned issues, this application employs the following technical solution: receiving motion commands generated by upper-layer control logic or a task planner, independent of the actuator. These motion commands are structured data objects independent of specific actuator hardware, containing key fields including at least: motion mode (e.g., position mode, velocity mode, torque mode, etc.), target value (target_value), trajectory point sequence (trajectory_points), constraints (e.g., maximum speed, maximum acceleration, etc.), timing requirements (e.g., expected execution time, deadline, etc.), and priority. These commands can be implemented using various serialization formats such as JSON, YAML, Protocol Buffers, FlatBuffers, or binary structures, but their core characteristic is that field types, version numbers, and verification rules are explicitly defined, ensuring their serializability, verifiability, versionability, and auditability.

[0019] In one embodiment of this application, step S1 may further include integrity verification and field unit normalization of the motion command. The specific implementation of integrity verification of the motion command is as follows: The system first checks whether the motion command contains all required fields, such as motion mode, target value, and timing requirements; then it checks whether the values ​​of each field are within a preset reasonable range, for example, the position value should not exceed the physical boundary of the robot's workspace, and the speed value should not exceed the maximum speed allowed by the actuator; finally, it checks whether the units of the fields conform to preset normalization standards, for example, all length units should be meters (m), all angle units should be radians (rad), and all time units should be seconds (s). If the check fails, the system will not execute blindly, but will generate a clarification request with a rejection reason and suspend the execution of subsequent steps, waiting for correction or confirmation from the upper-level control logic or task planner. This mechanism avoids unexplainable automatic control behavior and ensures the system's security and predictability.

[0020] The specific implementation of unit normalization for motion commands is as follows: The system maintains a global unit mapping table, which defines conversion factors between various common units (e.g., millimeters, centimeters, inches, degrees, revolutions per minute, etc.) and the International System of Units (SI). When the first motion command is received, the system iterates through all numerical fields in the command, looks up the corresponding conversion factor based on the field's type label (e.g., "length", "angle", "speed", etc.), and multiplies the field value by the factor to convert it to a standard value in SI. For example, if the position value sent by the upper-level control logic or task planner is 100 millimeters, it is normalized to 0.1 meters; if the speed is 60 degrees / second, it is normalized to... π / 3 radians / second. The normalized instructions are stored in a new data structure for use in subsequent steps.

[0021] In practical applications, basic integrity checks and unit normalization alone are insufficient to guarantee the safe operation of robots. For example, the target position of instructions issued by the upper-level control logic or task planner may be located near a singular configuration in the robot's workspace, or the target path may collide with surrounding obstacles. Therefore, this application introduces a safety constraint check mechanism in step S1 above, specifically including the following steps S1.1 and S1.2: Step S1.1: Based on the safety constraints in the actuator configuration file, perform collision detection or singular configuration checks on the target value of the motion command.

[0022] The actuator profile in the above embodiments is a structured data object that records information such as the actuator type, communication protocol, physical limits, calibration parameters, response characteristics, and safety constraints. Safety constraints can include soft and hard limits on robot joint angles, the maximum workspace boundary of the end effector, prohibited areas (e.g., virtual walls), or combinations of joint angles in singular configurations. The system uses these safety constraints to perform collision detection or singular configuration checks on the target value of the first motion command. Collision detection can be performed through spatial interference checks using a bounding box hierarchy or placeholder mesh, while singular configuration checks can be performed by calculating the condition number of the Jacobian matrix to determine if the target is close to a singularity.

[0023] Step S1.2: If a conflict is detected, a downgrade plan or clarification request is generated, and the execution of subsequent steps is suspended.

[0024] If a conflict is detected during collision detection or singular configuration checking of the target value of the motion command, the system will not execute it directly. Instead, it will generate a degradation solution (e.g., adjusting the target position to the nearest feasible point within the safe area) or a clarification request (e.g., reporting the cause of the conflict to the upper-level control logic or task planner and requesting new instructions), and suspend the execution of subsequent steps. This measure advances safety protection to the instruction reception stage, effectively avoiding physical risks caused by planning errors in the upper-level control logic or task planner.

[0025] In modern embodied intelligent systems (e.g., intelligent robots), upper-level control logic or task planners increasingly rely on artificial intelligence (AI) strategies, such as large language models, vision-language-action models, or reinforcement learning strategies. The outputs of these AI models are probabilistic and context-dependent, potentially generating instructions that do not conform to the robot's physical capabilities or violate safety constraints. To prevent such erroneous instructions from entering the execution chain, this application establishes a safety gating mechanism before step S1, specifically including the following steps S'1.1 and S'1.2: Step S'1.1: When the source of the motion instruction is an AI strategy or natural language parsing result, perform pattern verification and capability check on the motion instruction before executing step S1.

[0026] Pattern verification refers to checking whether the structure of an instruction conforms to a predefined pattern template, such as whether the instruction contains necessary fields, whether the field types are correct, and whether the enumerated values ​​are within the allowed range. Capability checking refers to comparing the target value of an instruction with the physical limits (e.g., maximum speed, maximum load, maximum travel, etc.) recorded in the executor configuration file to determine whether the instruction is within the current executor's capability range.

[0027] Step S'1.2: If the verification fails, the motion command is marked as a candidate intent and returned to the upper-level control logic or task planner for confirmation or correction.

[0028] If a motion command fails pattern verification and capability checks, the system will not consider it an executable command. Instead, it will mark it as a candidate intent and return it to the upper-level control logic or task planner for confirmation or correction. This mechanism is equivalent to inserting a verification layer between the AI ​​output and actual execution, effectively filtering out unreasonable or dangerous commands, ensuring system security, and providing clear feedback signals for the iterative improvement of AI strategies.

[0029] Step S2: Through the motion abstraction layer, the motion instructions generated by the upper-level control logic or task planner that are independent of the actuator are converted into a unified motion intermediate representation. This unified motion intermediate representation is a standard motion description data structure that is independent of the actuator, verifiable, and compileable.

[0030] In existing robot control systems, motion commands generated by upper-level control logic or task planners are typically directly transmitted to specific actuator drive layers. However, different actuators interpret the same motion command significantly differently: for example, a stepper motor driver might expect to receive pulse count and pulse frequency, while a servo driver might expect to receive speed commands in millimeters per second or torque commands in Newton-meters. Furthermore, different actuators have varying capabilities in processing motion trajectories: some actuators have built-in trajectory interpolation capabilities, allowing smooth movement from one point to the next; while others can only receive discrete points and cannot autonomously generate intermediate trajectories. More critically, the target values ​​in the commands issued by the upper-level control logic or task planner may exceed the actuator's physical limits (e.g., maximum speed, maximum acceleration, maximum torque, etc.). If these are issued directly without constraints, it can easily lead to actuator overload, loss of synchronization, or even damage.

[0031] To address the aforementioned issues, this application introduces a unified motion intermediate representation (MIR) as its core innovation. This unified motion intermediate representation is an actuator-independent, verifiable, and compilable standard motion description data structure, inspired by the concept of intermediate representation (IR) in computer compiler principles. Just as high-level programming languages ​​are converted into IR by a compiler front-end, and then the IR is compiled into machine code for different target platforms by a back-end, this application converts motion instructions generated by upper-level control logic or task planners into a unified motion intermediate representation through a motion abstraction layer. Then, an adapter mapping framework "compiles" this intermediate representation into low-level control instructions for different protocol executors.

[0032] Specifically, step S2 converts the normalized motion instructions into a unified intermediate motion representation through a motion abstraction layer. This unified intermediate motion representation is a standard motion description data structure independent of specific actuator hardware. Its core fields include: position (3D spatial coordinates or joint angle vector), velocity, acceleration, jerk, torque, wrench (including force and torque), and time (including timestamp and duration). These fields all use the International System of Units (SI) to ensure consistency between different actuators. More importantly, this unified intermediate motion representation has three key characteristics: actuator independence, verifiability, and compilability, which are explained in detail below: 1) Actuator independence: The intermediate representation does not contain any information related to a specific actuator protocol, unit or physical characteristics. Any upper-level control logic or task planner, such as AI strategies, Python scripts, manual configurations, etc., can generate this intermediate representation without knowing the underlying hardware details.

[0033] 2) Verifiability: The intermediate representation has strict structured definitions and verification rules, which can perform integrity checks, security constraint checks and physical feasibility verifications before compilation, ensuring that only legal and safe motion semantics can enter the subsequent compilation stage.

[0034] 3) Compilability: The intermediate representation, like the IR in the program, can be optimized and transformed by the downstream adapter mapping framework (which is equivalent to the compiler backend) for different target executors to generate efficient low-level instructions.

[0035] As an embodiment of this application, unit normalization, amplitude limiting, and trajectory interpolation are performed on the unified motion intermediate representation to generate a standardized motion intent, which can be achieved through the following steps S2.1 to S2.3: Step S2.1: Based on the unit mapping table in the actuator configuration file, convert the units of each field in the unified motion intermediate representation to the International System of Units (SI).

[0036] Although step S1 has already performed preliminary unit normalization for the motion commands, the unit normalization in step S2 is a deeper level of standardization for the unified motion intermediate representation. Specifically, based on the unit mapping table in the actuator configuration file, the units of each field in the unified motion intermediate representation are converted to SI units. This unit mapping table not only includes conversion factors between common units and SI units but also actuator-specific unit conversion rules. For example, some actuators use "encoder count" as the position unit, in which case the unit mapping table defines a conversion relationship such as "1 encoder count = π / 5000 rad"; similarly, some hydraulic actuators use "valve spool displacement percentage" as the flow control unit, and the unit mapping table converts it to "liters per minute". Through this step, all numerical fields are unified to SI units, providing unambiguous input for subsequent limiting and interpolation.

[0037] Step S2.2: Clamp each field according to the physical limit values ​​in the executor configuration file.

[0038] Even after unit normalization, the target values ​​in the unified motion intermediate representation may still exceed the physical capabilities of the actuator. For example, the upper-level control logic or task planner might require the actuator to move at a speed of 10 m / s, but the actuator's maximum permissible speed is only 2 m / s; or it might require an output torque of 100 N·m, but the actuator's rated torque is only 30 N·m. Without limitations, these over-limit commands will lead to actuator overheating, mechanical damage, or loss of control. Therefore, this application introduces a limiting mechanism in the motion abstraction layer, that is, clamping each field according to the physical limit values ​​in the actuator configuration file. The actuator configuration file records the physical limits of each actuator, including: maximum position (soft limit and hard limit), maximum speed, maximum acceleration, maximum jerk, maximum torque / force, maximum current, maximum temperature, etc. The limiting operation uses these limit values ​​as upper and lower boundaries to clamp the values ​​of the corresponding fields in the unified motion intermediate representation: if the target value is greater than the upper limit, the upper limit value is used; if the target value is less than the lower limit, the lower limit value is used; if the target value is within the range, it remains unchanged. The clamped values ​​are then written back to the corresponding fields in the unified motion intermediate representation.

[0039] It is worth noting that simple linear clamping is not ideal in some cases because different actuators have different response characteristics. For example, some actuators have large dead zones or frictional nonlinearities in the low-speed region, resulting in a lag between the actual output and the command; the acceleration curves of some actuators rise exponentially rather than nonlinearly. To address this issue, this application further proposes an improved clamping method: when clamping the unified motion intermediate representation, the target value is nonlinearly mapped or lag compensated according to the response characteristic curve in the actuator configuration file to eliminate the difference in response delay between different actuators. Specifically, the actuator configuration file stores one or more response characteristic curves, which can be obtained through offline calibration (e.g., applying a series of known commands to the actuator, recording the actual output, and then fitting the input-output relationship curve). During the clamping process, the system first looks up the response characteristic curve based on the target value (e.g., target speed) in the unified motion intermediate representation to obtain the corresponding pre-compensation value. For example, if the response characteristic curve indicates that the actual output is only 40% when the input command is 50%, the system will divide the target value by 0.8 (i.e., 1 / 0.8 = 1.25 times) as the pre-compensation value. The system then clamps the pre-compensation value to ensure it does not exceed physical limits. Finally, the clamped value is written into the unified motion intermediate representation as the final amplitude limiting result. This mechanism effectively eliminates the response delay differences caused by factors such as mechanical friction, electromagnetic hysteresis, and hydraulic damping among different actuators, enabling the same set of motion commands to produce nearly consistent actual motion effects on different actuators.

[0040] Step S2.3: Use linear interpolation or spline interpolation algorithms to generate intermediate pose sequences between adjacent trajectory points, and write the intermediate pose sequences into the timestamp field of the unified motion intermediate representation.

[0041] In many application scenarios, instructions issued by upper-level control logic or task planners only specify the start and end points (or a series of discrete path points), without providing intermediate trajectories. If discrete points are directly sent to the actuator, the actuator may perform step movements between each point, resulting in uneven motion, shocks, vibrations, and even triggering the actuator's protection mechanism. To address this issue, this application performs trajectory interpolation operations in the motion abstraction layer. Specifically, linear interpolation or spline interpolation algorithms are used to generate intermediate pose sequences between adjacent trajectory points, and these sequences are written into the timestamp field of a unified motion intermediate representation. Linear interpolation is suitable for scenarios where trajectory smoothness requirements are not high; it distributes intermediate points evenly along a straight line between two adjacent points, with each intermediate point corresponding to a timestamp. Spline interpolation (e.g., cubic splines, B-splines, etc.) is suitable for scenarios where trajectory smoothness requirements are high; it generates intermediate points by fitting a continuously differentiable curve, thereby ensuring the continuity of velocity and acceleration during motion and avoiding shocks. The generated intermediate pose sequence is written into the timestamp field of the unified motion intermediate representation. Each pose point is accompanied by a timestamp, indicating that the actuator should have reached that pose at that time. In this way, the subsequent drive adaptation layer can issue commands one by one according to the timestamp order to achieve smooth continuous motion.

[0042] Step S3: Query the actuator configuration file to obtain the capability parameters and protocol type of the target underlying actuator, and map the unified motion intermediate representation to the target driver protocol data that matches the protocol type through the adapter mapping framework.

[0043] After processing in step S2, the system has obtained a unified intermediate motion representation. This unified intermediate motion representation uses the International System of Units (SI), has been limited and interpolated, and theoretically can be executed by any actuator. However, in the real world, different actuators use drastically different communication protocols and control interfaces. For example, servo drives typically use the CANopen protocol to read and write target position, speed, and torque through an object dictionary; stepper motor drivers often use a pulse / direction interface to control motion through the frequency and number of pulse width modulation (PWM) signals; hydraulic actuators may use analog voltage (0~10V) or current (4~20mA) to control valve opening; and intelligent grippers may send ASCII commands through Modbus RTU or UART serial ports. Furthermore, even when using the same protocol (e.g., CANopen), actuators from different manufacturers differ in object dictionary indexes, data types, and unit conversion relationships. Therefore, the key challenge in realizing actuator-independent motion control is how to automatically and accurately convert the unified motion intermediate representation into protocol data that can be understood by a specific actuator.

[0044] In existing technologies, there are generally three approaches to solving this problem: First, hard-coding a separate protocol conversion function for each executor at the driver layer. This approach leads to code redundancy, maintenance difficulties, and requires source code modification for each new executor. Second, utilizing the hardware interface layer of the Robot Operating System (ROS) (e.g., ros_control) to write a separate hardware resource manager for each executor. However, ROS's asynchronous message architecture struggles to guarantee end-to-end real-time performance and determinism, and it is not compatible with non-ROS systems. Third, using a hardware gateway for protocol conversion. However, gateways are costly, inflexible, and introduce additional points of failure. None of these solutions fundamentally achieves automation and configurability for protocol adaptation.

[0045] To address the aforementioned issues, this application introduces an Actuator Profile and an Adapter Mapping Framework. The main technical solutions include: querying the Actuator Profile to obtain the target Actuator's capability parameters and protocol type; and using the Adapter Mapping Framework to map the Unified Motion Intermediate Representation (UMI) to target driver protocol data matching the protocol type. Firstly, the technical solutions of this application's embodiments have several advantages. Firstly, the Actuator's protocol information and conversion rules are centrally stored in the configuration file. When adding or replacing an Actuator, only the configuration file needs to be added or modified, without modifying any core code, greatly improving the system's scalability and maintenance efficiency. Secondly, the Adapter Mapping Framework acts as a "translator," with the UMI as its input and various protocol messages as its output. There is no direct code dependency between them, allowing the UMI to seamlessly migrate between different protocols. Thirdly, by explicitly defining unit conversion relationships and frame formats in the configuration file, conversion errors prone to occur in hard coding are avoided. Mechanisms such as adding checksums ensure the integrity of transmitted data.

[0046] In this embodiment, the actuator configuration file is a structured data object that centrally stores all the technical parameters of each actuator. Its core fields include: actuator type (e.g., servo motor, stepper motor, hydraulic cylinder, gripper, etc.), communication protocol (e.g., CANopen, EtherCAT, PWM, UART, Modbus, analog, etc.), physical limits (e.g., maximum position, maximum speed, maximum torque, etc.), calibration parameters (e.g., zero offset, scale coefficient, etc.), response characteristics (e.g., response curve, dead zone, hysteresis time, etc.), and safety constraints (e.g., soft limit, hard limit, emergency stop configuration, etc.). This configuration file can be stored in JSON, YAML, Protocol Buffers, or database tables and supports versioning to ensure compatibility between different versions.

[0047] It should be noted that the adapter mapping framework in the above embodiments is a scalable software architecture. Its core idea is to extract the "motion intent → protocol data" conversion logic from hard-coded code and transform it into a pluggable conversion module driven by a configuration file. This framework maintains a protocol converter registry, where each protocol type corresponds to a dedicated protocol converter. When the system needs to map the unified motion intermediate representation to the driver protocol data of a specific actuator, the adapter mapping framework automatically selects the appropriate protocol converter based on the protocol type identifier in the actuator configuration file and passes the unified motion intermediate representation and the configuration file as input to the converter. Specifically, mapping the unified motion intermediate representation to the target driver protocol data matching the protocol type can be achieved through steps S3a to S3c via the adapter mapping framework, as detailed below.

[0048] Step S3a: Call the corresponding protocol converter according to the protocol type identifier in the executor configuration file.

[0049] First, the system reads the protocol type field from the actuator configuration file, such as "CANopen", "EtherCAT_COE", "PWM_DIR", and "MODBUS_RTU". Then, the system searches the protocol converter registry for a converter instance that matches the protocol type identifier. The protocol converter registry is a collection of key-value pairs, where the key is the protocol type string and the value is a pointer or reference to a converter object. Each protocol converter implements a unified interface, which includes at least one conversion method. Its inputs are the unified motion intermediate representation and the actuator configuration file, and its output is the target driver protocol data. This design allows for the addition of a new protocol type simply by developing a new protocol converter and registering it in the registry, without modifying existing code, thus adhering to the open / closed principle.

[0050] Step S3b: The protocol converter converts the data fields in the unified motion intermediate representation into register values ​​or pulse sequences that can be recognized by the underlying hardware, according to the frame format and unit conversion relationship of the protocol type.

[0051] After the protocol converter is invoked, it begins executing the actual conversion logic. The conversion process involves two aspects: frame format conversion and unit conversion. Frame format conversion refers to reassembling the structured fields (e.g., position, velocity, acceleration, etc.) in the Unified Motion Intermediate Representation (UMI) according to the message format of the target protocol. For example, for the CANopen protocol, the converter needs to convert the target position (floating-point number, in meters) in the UMI into an integer value (in micrometers or encoder counts) at the corresponding index (e.g., 0x607A) in the CANopen object dictionary, and construct a Controller Area Network (CAN) message. For the PWM direction interface, the converter needs to convert the target velocity and acceleration in the UMI into pulse frequency and direction level, and calculate the required number of pulses. The unit conversion relationships also come from the actuator configuration file, such as "1 mm = 1000 encoder counts" or "1 rpm = 2000 pulses / second". Through this step, the UMI is accurately translated into low-level signals that the actuator hardware can directly understand and execute.

[0052] Step S3c: Encapsulate the register value or pulse sequence into a message structure that conforms to the protocol type, and attach a checksum.

[0053] After conversion, the protocol converter encapsulates the generated register values ​​or pulse sequences according to the message structure of the target protocol. For example, for the CANopen protocol, it needs to fill in the CAN message ID, data length, and data bytes, and calculate and append a Cyclic Redundancy Check (CRC) code to the end of the message; for the Modbus RTU protocol, it needs to construct the function code, data area, and CRC-16 checksum; for the UART ASCII protocol, it needs to format the data into a string with a specific prefix and suffix, and append a parity bit. The encapsulated message is the target driver protocol data, which is the final instruction that can be directly sent to the actuator through the physical layer (e.g., CAN transceiver, RS485 chip, etc.). The addition of the checksum ensures the integrity of data transmission and prevents malfunctions caused by communication interference.

[0054] In actual deployments, the version of the executor configuration file may be incompatible with the version adapter of the current runtime environment. For example, the older version of the configuration file may lack some new fields, or the data types of the fields may have changed. To address this issue, this application introduces a version adaptation mechanism in step S3. Specifically, if the version number of the executor configuration file is incompatible with the version adapter of the current runtime environment, the version adapter is invoked to convert the executor configuration file into a format readable by the current version before performing subsequent mapping operations. The version adapter is a module specifically designed to handle data structure version migration. It maintains a series of version conversion rules (e.g., field mapping from v1.0 to v2.0, default value filling, type conversion, etc.). When version incompatibility is detected, the system automatically loads the corresponding version adapter, converts the old version of the configuration file into a format readable by the current version in real time, and then performs protocol conversion. This mechanism ensures that historical sessions, historical tasks, and historical policies can still be read and executed normally in the new runtime, greatly enhancing the backward compatibility and long-term maintainability of the system.

[0055] Step S4: Send the target driver protocol data to the corresponding underlying actuator through the driver adapter interface before the preset deadline, and read the hardware feedback and standardize it into a general status feedback.

[0056] After processing in step S3, the system has obtained the target drive protocol data for a specific actuator, which is the final message conforming to the actuator communication protocol. However, simply generating the message is insufficient; it also needs to be reliably sent to the actuator under strict time constraints and the actuator's status feedback needs to be obtained in real time to form a complete control closed loop. In real-time robot control systems, the timeliness of commands is crucial: if the command issuance delay exceeds the actuator's response window, it may lead to asynchronous motion, trajectory deviation, or even safety accidents. Furthermore, the feedback formats and contents of different actuators vary greatly; some return encoder positions, some return Hall sensor counts, and some return analog voltage values. Without standardization, the upper-level control logic or task planner will not be able to uniformly interpret the actual state of the actuator. In view of this, this application uses a driver adapter interface to send the target drive protocol data to the corresponding underlying actuator before a preset deadline and reads the hardware feedback, standardizing it into a general status feedback. Through the driver adapter interface, this application achieves standardization and real-time processing of instruction issuance and status feedback. Specifically, the unified interface design allows upper-level control logic or task planners to communicate with any executor as if calling a local function, without needing to concern themselves with the details of the underlying protocol; the deadline check mechanism ensures the timeliness of instruction execution and avoids the risk of timeout; and the standardization of general status feedback provides upper-level control logic or task planners with a unified and comparable view of the execution status, laying the foundation for subsequent closed-loop control, safety monitoring, and data auditing.

[0057] In this embodiment, the driver adapter interface is a unified abstract interface that provides a standardized operating contract for each type of actuator. This interface defines at least the following methods: initialization (init, used to open the communication port and configure parameters), sending commands (send_command, used to send target driver protocol data), reading status (read_state, used to read hardware feedback), setting parameters (set_param, used to dynamically adjust actuator parameters), and emergency stop (emergency_stop, used to quickly cut off power). Each specific actuator driver implements this interface, allowing upper-layer control logic or task planners to interact with any actuator through a unified application programming interface, without needing to concern themselves with the underlying communication details.

[0058] The specific execution process of step S4 is as follows: First, the system obtains the target driver protocol data generated in step S3 and determines the corresponding driver adapter instance. Then, the system checks the relationship between the current time and the preset deadline. The preset deadline is the timing requirement extracted from the motion command received in step S1, or calculated based on the timestamp during trajectory interpolation in step S2. If the current time is sufficient to complete the command issuance and execution, the send_command method of the driver adapter is called to send the target driver protocol data to the actuator through the physical layer (e.g., CAN bus, Ethernet, serial port, GPIO). If it is detected that the current time is less than the minimum required execution time (including communication transmission time, actuator response time, and status feedback time), the system determines that the task cannot be completed on time. At this time, execution is refused and a deadline violation is marked, while a replanning request is returned to the upper-layer control logic or task planner. This mechanism ensures that the system will not force execution when it knows that it cannot be completed on time, avoiding motion loss of control or task failure due to timeout.

[0059] After the command is issued, the system immediately or periodically calls the `read_state` method of the drive adapter to read the hardware feedback from the actuator. The form of the hardware feedback varies depending on the actuator: for CANopen servo drives, the feedback may be the actual position and actual speed from the object dictionary; for stepper motors, the feedback may be encoder counts or Hall sensor status; for hydraulic actuators, the feedback may be analog voltage values ​​from pressure and displacement sensors. The drive adapter interface internally converts this raw feedback data into a unified structured format, namely UniversalState. UniversalState is a standardized data structure whose key fields include: actual position, actual speed, actual torque / force, actual current, temperature, and fault code. All fields use the International System of Units (SI), ensuring that upper-level control logic or task planners can uniformly interpret the state of any actuator.

[0060] In actual operation, actuators may experience various abnormal situations, such as hardware failures (e.g., motor overload, encoder damage), communication interruptions (e.g., bus disconnection, severe packet loss), or safety constraint conflicts (e.g., exceeding soft limits, collision detection triggering). If these abnormalities are not handled promptly, they may lead to equipment damage or personal injury. Therefore, this application introduces an abnormality handling mechanism based on step S4. Specifically, when any actuator is detected to have a hardware failure, communication interruption, or safety constraint conflict, an adapter emergency stop sequence is immediately triggered. The emergency stop sequence includes three key actions: First, broadcasting an emergency stop command to all online actuators. This command is sent via the `emergency_stop` method of the drive adapter and is typically a high-priority stop command (e.g., a CANopen NMT stop node command or an immediate zeroing of the PWM signal). Second, recording the last general status feedback before the emergency stop, including key data such as position, speed, and torque, as well as the timestamp of the anomaly. This data will be saved in the audit log for post-event analysis and troubleshooting. Third, reporting the cause of the emergency stop to the upper-level control logic or task planner, including the anomaly type, the time of occurrence, and a list of affected actuators, so that the upper-level control logic or task planner can take further countermeasures, such as switching control modes, notifying the operator, or initiating a backup plan.

[0061] To ensure the rationality of emergency stop decisions, this application further establishes a hierarchical judgment mechanism. Specifically, before triggering the adapter emergency stop sequence, the system further includes: judging the anomaly type hierarchically according to safety constraints, hard constraints, soft constraints, and preference order. If the current anomaly cannot be resolved by degradation or replacement actuator, the emergency stop sequence is executed. Here, safety constraints refer to inviolable mandatory rules (e.g., prohibiting exceeding hard limits), hard constraints refer to the physical limits of the actuator (e.g., maximum current), soft constraints refer to recommended operating ranges (e.g., suggested speed range), and preference order refers to user-defined priorities (e.g., prioritizing the use of the main actuator, with alternative actuators as degradation options). The system evaluates anomalies hierarchically according to this priority order: first, it checks whether safety constraints are violated; if so, it immediately initiates an emergency stop; second, it checks whether hard constraints are exceeded; if so, it attempts to degrade (e.g., reduce speed or torque) or switch to a replacement actuator; if degradation or switching fails, an emergency stop is executed. This hierarchical processing strategy maintains the continuous operation of the system as much as possible while ensuring safety, avoiding unnecessary downtime.

[0062] Step S5: During the execution of the hierarchical drive adaptation method for the robot actuator, the current control quality index is dynamically evaluated based on the deviation between the general state feedback and the unified motion intermediate representation. When the control quality index is lower than a preset threshold, the following adapter mapping parameter reconfiguration process is triggered: query the preset quality degradation compensation table in the actuator configuration file to obtain the compensation parameters corresponding to the current deviation type and magnitude; dynamically adjust at least one conversion rule in the adapter mapping framework according to the compensation parameters, wherein the conversion rule includes a unit conversion factor, a nonlinear compensation curve, or a frame format mapping relationship; apply the adjusted conversion rule to the subsequent mapping process of the target drive protocol data.

[0063] To further enhance the system's control robustness and adaptability under long-term operation or environmental changes, during the implementation of the hierarchical drive adaptation method for the robot actuators, the system continuously monitors the deviation between the unified intermediate motion representation and the general state feedback obtained through standardization in step S4. This deviation reflects the difference between the actual execution effect and the desired motion intention, such as position tracking error, velocity following error, or torque output deviation. Based on this deviation, the system dynamically evaluates the current control quality index. The control quality index is a comprehensive quantitative value used to measure the performance of the current control loop. Its calculation can comprehensively consider multiple dimensions such as the root mean square value of the tracking error, maximum overshoot, steady-state error, and response delay. When the control quality index is lower than a preset threshold, for example, when the root mean square value of the position tracking error continuously exceeds 20% of the allowable range, the system automatically triggers the adapter mapping parameter reconfiguration process.

[0064] The reconfiguration process first queries the pre-defined quality degradation compensation table in the actuator configuration file. This table is a pre-calibrated data structure generated based on experimental data from aging, wear, or environmental changes of the actuator under different operating conditions. It records the compensation parameters corresponding to different deviation types (e.g., low-speed crawling due to increased friction, high-frequency oscillations due to elastic deformation, stick-slip due to poor lubrication, etc.) and deviation amplitudes. The compensation parameters corresponding to the deviation amplitude are a set of numerical values ​​or function coefficients used to guide how to correct the current mapping rules to offset the effects of performance degradation. For example, for low-speed tracking errors caused by increased friction, the compensation parameter might be an increased dead zone compensation coefficient or a corrected nonlinear friction model parameter; for high-frequency oscillations caused by elastic deformation, the compensation parameter might be a reduced acceleration limit or an increased damping coefficient.

[0065] Next, the system dynamically adjusts at least one conversion rule in the adapter mapping framework based on the acquired compensation parameters. In this embodiment, the conversion rule is the specific algorithm or mapping relationship used by the adapter mapping framework when performing protocol conversion, including but not limited to unit conversion factors, nonlinear compensation curves, and frame format mapping relationships, which will be described one by one below.

[0066] 1) Unit conversion factor: For example, converting position values ​​(meters) in the International System of Units (SI) into a scaling factor for the encoder count inside the actuator. This factor can be dynamically corrected when the transmission ratio changes due to wear of the actuator.

[0067] 2) Nonlinear compensation curves: These are used to correct the inherent nonlinear response characteristics of the actuator, such as dead zones, saturation zones, or hysteresis curves. These curves are typically stored in lookup tables or piecewise polynomials, and adjustments mean modifying key points or polynomial coefficients on the curve.

[0068] 3) Frame format mapping: This defines how each field in the unified motion intermediate representation is mapped to a specific location, data type, and value range in the target protocol message. For example, in the CANopen protocol, the target location field is mapped to the index and sub-index of object dictionary 0x607A. Adjusting this mapping can change the way the message is assembled.

[0069] Finally, the system applies the adjusted conversion rules to the mapping process of the target-driven protocol data. That is, when the system executes step S3 again, it will use the updated conversion rules to generate the target-driven protocol data. Through this dynamic, closed-loop adaptive adjustment mechanism, the technical solution of this application can automatically compensate for the slow degradation of actuator performance or changes in environmental characteristics without interrupting operation, thereby maintaining high-precision control performance over long time scales and significantly improving the reliability of the robot system and the flexibility of maintenance cycles.

[0070] In many practical applications, robotic systems comprise multiple actuators, such as a six-axis robotic arm, a gripper, and a mobile chassis. These actuators need to work collaboratively to perform complex tasks, such as grasping and handling. However, each actuator operates independently, with its own clock and communication channel, lacking a unified coordination mechanism. This can lead to disordered action timing, resource contention, or inconsistent states. For example, the robotic arm may have moved to the gripping position, but the gripper is not yet in place, resulting in a failed grasp; or two actuators may simultaneously access the same shared resource (e.g., a power bus), causing overload.

[0071] To address these issues, this application introduces a Multi-Actuator Coordinator (MAC). Specifically, in multi-actuator collaborative scenarios, the MAC maintains the independent state and shared context of each actuator; based on timestamps, resource locks, and synchronization groups, it binds the actions and feedback of multiple actuators into a single traceable process. The MAC is a central coordination module that maintains a global state table recording the current state (e.g., idle, in motion, fault), resource occupancy (e.g., shared bus, power supply, workspace), and task progress of each actuator. When multiple actuators need to collaboratively execute a complex task, the coordinator associates the independent actions and feedback of each actuator based on timestamps (i.e., the planned execution time of each action), resource locks (ensuring mutually exclusive resources are not accessed simultaneously), and synchronization groups (defining which actuators need to start or end actions at the same time), forming a complete task execution record. For example, in a "grab and place" task, the coordinator ensures that the gripper only performs the closing action after the robotic arm reaches the gripping position, and that the moving chassis remains stationary during placement. The above solution maintains the independent state and shared context of each executor through a multi-executor coordinator, and binds multiple actions and feedbacks into the same traceable process using timestamps, resource locks and synchronization groups. This achieves unified management and full-process auditing of multi-executor collaborative operations, and solves the coordination and traceability problems in multi-executor scenarios.

[0072] To further improve the accuracy of multi-actuator coordination, this application also introduces a clock synchronization and delay compensation mechanism. Specifically, binding the actions and feedback of multiple actuators into a single traceable process based on timestamps can be achieved by: obtaining the local clock offset and communication delay of each actuator through a multi-actuator coordinator, and applying corresponding delay compensation to the action command of each actuator to synchronize the actual start time of all actuators' actions. In a real system, each actuator's controller has its own local clock, and these clocks drift and offset; at the same time, the communication delays of different actuators are also different (for example, the delay of the CAN bus is usually less than that of Wi-Fi). The multi-actuator coordinator measures the clock offset and round-trip delay of each actuator by periodically exchanging clock synchronization messages (such as the IEEE 1588 PTP protocol or a simple NTP-like protocol). Then, when sending action commands, the coordinator applies a compensation delay to each command based on the measurement results, so that all actuators appear to receive the command simultaneously in local time, thereby achieving synchronous start-up in actual physical time. This mechanism is particularly important for multi-axis linkages that require precise timing (e.g., dual robotic arm collaboration).

[0073] In industrial and enterprise-level robot deployments, simply achieving motion control and drive adaptation is insufficient. The system needs robust auditing and traceability capabilities to accurately reconstruct the complete context of each control action in the event of an accident, performance degradation, or compliance check. Traditional data logging methods typically employ linear logs, with each record stored independently, lacking interrelationships and tamper-proof protection. Once a log file is partially tampered with, it is difficult to detect in a timely manner, and post-event verification is inefficient. To address these issues, this application introduces a structured auditing mechanism, specifically including the following steps S51a and S51b: Step S51a: During execution, a structured hash calculation is performed on the general state feedback at fixed intervals or when an event is triggered.

[0074] The fixed period here (e.g., every 10ms) can be an integer multiple of the control loop, and the event trigger can be each instruction completion, each exception occurrence, or each state transition. Structured hash computation refers to converting all fields of the universal state feedback (e.g., position, velocity, torque, current, temperature, fault code, etc.) into a byte stream according to predefined serialization rules (e.g., JSON specification sorting, Protocol Buffers encoding, etc.), and then using a cryptographic hash algorithm to calculate a fixed-length hash value. This hash value uniquely represents the executor state at that moment; any small modification to the original data will cause a drastic change in the hash value, thus achieving integrity protection of the state data.

[0075] Step S51b: Store the hash value obtained from the structured hash calculation along with the timestamp into the audit log.

[0076] After calculating the hash value, the system needs to persist it for subsequent auditing. Specifically, the hash value calculated by the structured hash is stored in the audit log along with a timestamp. The timestamp records the moment the state was captured, forming an indivisible audit entry together with the hash value. However, simple linear storage still faces the risk of being tampered with in batches. To further enhance anti-tampering capabilities, this application uses a Merkle tree structure to organize audit entries. Specifically, storing the hash value calculated by the structured hash along with the timestamp in the audit log can be done by associating the hash value of the current general state feedback with the hash value of the corresponding motion command, and packaging it together with the version number of the executor configuration file into an audit entry. The audit entries are organized using a Merkle tree structure to support efficient post-verification and local tamper detection. The specific implementation is as follows: Each audit entry contains not only the hash value of the general state feedback, but also the hash value of the motion command that triggered the state, and the version number of the executor configuration file used at that time. These three are concatenated and hashed again to form the root hash of the audit entry. Multiple consecutive audit entries are arranged chronologically. The hash values ​​of every two adjacent entries are paired and then hashed again to form the node of the next level; this process continues until a binary Merkle tree is formed. The root node of the tree represents an integrity summary of all audit data within the entire time period. When it is necessary to verify whether a segment of audit data has been tampered with, it is only necessary to recalculate the Merkle path of that segment of data and compare it with the stored root hash to quickly locate the tampered leaf node. This structure reduces the verification time complexity from O(n) to O(logn), and any local tampering will be exposed by changes in the root hash.

[0077] Through structured hash calculation and Merkle tree organization, the above embodiments of this application achieve integrity protection and efficient verification of the robot execution process. Any tampering with historical state data will result in a mismatch in the Merkle tree root hash, thus being quickly detected. Simultaneously, the Merkle tree structure eliminates the need for verification operations to traverse all data, significantly improving audit efficiency and meeting the stringent data security and compliance requirements of enterprise-level deployments.

[0078] In actual operation, actuators inevitably experience various failures, such as motor overheating, encoder loss, communication timeouts, and hydraulic leaks. Traditional fault handling methods typically involve directly shutting down the machine and waiting for manual intervention, which leads to prolonged production interruptions, especially in unattended or remote operation scenarios where manual intervention is extremely costly. Furthermore, simple shutdowns may leave the robot in an unsafe position or posture, increasing the difficulty of subsequent recovery. To address this issue, this application introduces an automatic fault recovery mechanism. Specifically, after step S4, if the general status feedback contains a fault code, a recovery path is automatically selected and executed based on the predefined fault recovery mapping table in the actuator configuration file. Here, the fault code is a numerical code reported by the actuator through the general status feedback, with each code corresponding to a specific fault type. The actuator configuration file contains a predefined fault recovery mapping table, which specifies one or more recovery paths for each fault code. The recovery path is a series of ordered actions designed to safely return the system from a faulty state to a controllable, stable state.

[0079] The specific content of the recovery path depends on the fault type and system configuration. For example, for a motor overheating fault, the recovery path might be "deceleration and stop": first, reduce the actuator speed to zero at a preset deceleration, then shut off the driver's power output, and record the stopping position. For an encoder loss fault, the recovery path might be "reverse motion": the actuator moves backward a short distance at low speed to attempt to recapture the encoder signal; if this fails, it switches to a backup encoder or enters a safe stop. For a gripper jamming fault, the recovery path might be "switch to a backup actuator": activate another backup gripper and reassign the current task to the backup gripper. Each recovery path consists of multiple sequentially executed atomic actions, such as "set target speed → start motion → monitor status → reach target → shut off power." During the execution of the recovery path, the system continuously records general status feedback, including position, speed, torque, temperature, etc., for post-fault analysis of the fault cause and the effectiveness of the recovery process.

[0080] By using a predefined fault recovery mapping table and automatic recovery path execution, the technical solution in the above example achieves automated and intelligent fault handling, restoring the system to a safe state or allowing it to continue executing tasks without immediate human intervention. This not only reduces downtime and manual maintenance costs but also improves the system's autonomous operation and maintenance capabilities and reliability, making it particularly suitable for unattended production lines and remote operation scenarios.

[0081] From the above Figure 1The example of the layered drive adaptation method for robot actuators demonstrates several key advantages. First, by receiving motion commands generated by the upper-level control logic or task planner that are independent of the actuator, the motion commands are converted into a unified intermediate motion representation. This eliminates the dependence of the upper-level control logic on the physical characteristics and protocol details of specific actuators, thus decoupling the motion commands from the actuator hardware. Second, by querying the actuator configuration file to obtain the target actuator's capability parameters and protocol type, and using an adapter mapping framework to map standardized motion intentions to target drive protocol data, the same set of upper-level control logic can automatically adapt to different types of actuators, significantly improving the reusability of motion control logic. Third, by issuing commands before a preset deadline through the drive adapter interface and reading hardware feedback to standardize it into general status feedback, the real-time performance and traceability of command execution are ensured, while providing a unified execution status view for the upper-level control logic. Fourth, through this dynamic, closed-loop adaptive adjustment mechanism, the slow degradation of actuator performance or changes in environmental characteristics can be automatically compensated for without interrupting operation, thereby maintaining high-precision control performance over long timescales and significantly improving the reliability of the robot system and the flexibility of maintenance cycles. In summary, this application effectively solves the problem of the inability to reuse upper-level control logic due to differences in actuator protocols and characteristics in the prior art, and improves the scalability, real-time performance, engineering deployability, and maintenance cycle flexibility of the robot system.

[0082] Please see the appendix Figure 2 This application provides a hierarchical drive adapter for a robot actuator. The adapter includes an instruction receiving module 201, a generation module 202, a mapping module 203, a standardization module 204, and an adjustment module 205, as detailed below: The instruction receiving module 201 is used to receive motion instructions (MotionCommand) generated by the upper layer that are independent of the actuator. The generation module 202 is used to convert motion instructions into a unified motion intermediate representation through the motion abstraction layer. The unified motion intermediate representation is a standard motion description data structure that is independent of the actuator, verifiable, and compilable. The mapping module 203 is used to query the actuator configuration file, obtain the capability parameters and protocol type of the target underlying actuator, and map the unified motion intermediate representation to the target driving protocol data that matches the protocol type through the adapter mapping framework; The standardization module 204 is used to send the target driver protocol data to the corresponding underlying actuator before a preset deadline through the driver adapter interface, and to read the hardware feedback and standardize it into a general status feedback. The adjustment module 205 is used to dynamically evaluate the current control quality index based on the deviation between the general state feedback and the unified motion intermediate representation during the process of the device executing the hierarchical drive adaptation method of the robot actuator. When the control quality index is lower than the preset threshold, the following adapter mapping parameter reconfiguration process is triggered: query the preset quality degradation compensation table in the actuator configuration file to obtain the compensation parameters corresponding to the current deviation type and magnitude; dynamically adjust at least one conversion rule in the adapter mapping framework according to the compensation parameters, wherein the conversion rule includes a unit conversion factor, a nonlinear compensation curve or a frame format mapping relationship; and apply the adjusted conversion rule to the mapping process of the target drive protocol data.

[0083] From the above Figure 2 As illustrated by the example of the layered drive adaptation device for the robot actuator, on the one hand, by receiving motion commands generated by the upper-level control logic or task planner that are independent of the actuator, the device converts these motion commands into a unified intermediate motion representation. This allows the upper-level control logic to no longer depend on the physical characteristics and protocol details of a specific actuator, thus decoupling the motion commands from the actuator hardware. On the other hand, by querying the actuator configuration file to obtain the target actuator's capability parameters and protocol type, and using an adapter mapping framework to map standardized motion intentions to target drive protocol data, the same set of upper-level control logic can automatically adapt to different types of actuators, significantly improving the reusability of the motion control logic. Thirdly, by issuing commands before a preset deadline through the drive adapter interface and reading hardware feedback to standardize it into general status feedback, the device ensures the real-time performance and traceability of command execution, while providing a unified execution status view for the upper-level control logic. Fourthly, through this dynamic, closed-loop adaptive adjustment mechanism, the device can automatically compensate for the slow degradation of actuator performance or changes in environmental characteristics without interrupting operation, thereby maintaining high-precision control performance over a long time scale and significantly improving the reliability of the robot system and the flexibility of the maintenance cycle. In summary, this application effectively solves the problem of the inability to reuse upper-level control logic due to differences in actuator protocols and characteristics in the prior art, and improves the scalability, real-time performance, engineering deployability, and maintenance cycle flexibility of the robot system.

[0084] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 3 in this embodiment mainly includes: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program for a hierarchical driver adaptation method for a robot actuator. When the processor 30 executes the computer program 32, it implements the steps in the above-described embodiment of the hierarchical driver adaptation method for a robot actuator, for example... Figure 1Steps S1 to S5 are shown. Alternatively, when processor 30 executes computer program 32, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 2 The functions of the instruction receiving module 201, generation module 202, mapping module 203, standardization module 204, and adjustment module 205 are shown.

[0085] For example, the computer program 32 of the hierarchical drive adaptation method for robot actuators mainly includes: receiving motion instructions generated by upper-level control logic or task planners that are independent of the actuator; converting the motion instructions generated by upper-level control logic or task planners into a unified motion intermediate representation through a motion abstraction layer, wherein the unified motion intermediate representation is a standard motion description data structure that is independent of the actuator, verifiable, and compilable; querying the actuator configuration file to obtain the capability parameters and protocol type of the target underlying actuator, and mapping the unified motion intermediate representation to target drive protocol data that matches the protocol type through an adapter mapping framework; and sending the target drive protocol data to the corresponding actuator before a preset deadline through the drive adapter interface. The underlying actuator reads hardware feedback and standardizes it into general state feedback. During the hierarchical drive adaptation method of the robot actuator, the current control quality index is dynamically evaluated based on the deviation between the general state feedback and the unified motion intermediate representation. When the control quality index is lower than a preset threshold, the following adapter mapping parameter reconfiguration process is triggered: a quality degradation compensation table preset in the actuator configuration file is queried to obtain compensation parameters corresponding to the current deviation type and magnitude; according to the compensation parameters, at least one conversion rule in the adapter mapping framework is dynamically adjusted, wherein the conversion rule includes a unit conversion factor, a nonlinear compensation curve, or a frame format mapping relationship; the adjusted conversion rule is applied to the subsequent mapping process of the target drive protocol data. The computer program 32 can be divided into one or more modules / units, which are stored in memory 31 and executed by processor 30 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 32 in the electronic device 3.For example, computer program 32 can be divided into the functions of instruction receiving module 201, generation module 202, mapping module 203, standardization module 204, and adjustment module 205 (a module in the virtual device). The specific functions of each module are as follows: Instruction receiving module 201 is used to receive motion commands (MotionCommand) generated by the upper layer and independent of the actuator; generation module 202 is used to convert motion commands into a unified motion intermediate representation through a motion abstraction layer, wherein the unified motion intermediate representation is a standard motion description data structure that is independent of the actuator, verifiable, and compilable; mapping module 203 is used to query the actuator configuration file, obtain the capability parameters and protocol type of the target underlying actuator, and map the unified motion intermediate representation to target driver protocol data that matches the protocol type through an adapter mapping framework; standardization module 204 is used to... Through the driver adapter interface, the target drive protocol data is sent to the corresponding underlying actuator before a preset deadline, and the hardware feedback is read and standardized into a general state feedback. The adjustment module 205 is used to dynamically evaluate the current control quality index based on the deviation between the general state feedback and the unified motion intermediate representation during the process of the device executing the hierarchical drive adaptation method of the robot actuator. When the control quality index is lower than a preset threshold, the following adapter mapping parameter reconfiguration process is triggered: query the preset quality degradation compensation table in the actuator configuration file to obtain the compensation parameters corresponding to the current deviation type and magnitude; dynamically adjust at least one conversion rule in the adapter mapping framework according to the compensation parameters, wherein the conversion rule includes a unit conversion factor, a nonlinear compensation curve or a frame format mapping relationship; and apply the adjusted conversion rule to the mapping process of the target drive protocol data.

[0086] Electronic device 3 may include, but is not limited to, processor 30 and memory 31. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0087] The processor 30 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0088] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 31 can include both internal and external storage units of the electronic device 3. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or will be output.

[0089] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed. That is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above-described device can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0090] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

[0092] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0094] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0095] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can also be implemented by a computer program instructing related hardware. The computer program for the layered drive adaptation method of the robot actuator can be stored in a storage medium. When the computer program is executed by a processor, it can implement the steps of the above method embodiments, namely, receiving motion instructions that are independent of the actuator generated by the upper-level control logic or task planner; converting the motion instructions that are independent of the actuator generated by the upper-level control logic or task planner into a unified motion intermediate representation through a motion abstraction layer. This unified motion intermediate representation is a standard motion description data structure that is independent of the actuator, verifiable, and compileable; querying the actuator configuration file to obtain the capability parameters and protocol type of the target underlying actuator, and mapping the unified motion intermediate representation to a protocol type that matches the protocol type through an adapter mapping framework. The target drive protocol data is sent to the corresponding underlying actuator before a preset deadline via the drive adapter interface, and the hardware feedback is read and standardized into a general state feedback. During the hierarchical drive adaptation method of the robot actuator, the current control quality index is dynamically evaluated based on the deviation between the general state feedback and the unified motion intermediate representation. When the control quality index is lower than a preset threshold, the following adapter mapping parameter reconfiguration process is triggered: The preset quality degradation compensation table in the actuator configuration file is queried to obtain the compensation parameters corresponding to the current deviation type and magnitude. Based on the compensation parameters, at least one conversion rule in the adapter mapping framework is dynamically adjusted, where the conversion rule includes a unit conversion factor, a nonlinear compensation curve, or a frame format mapping relationship. The adjusted conversion rule is applied to the subsequent mapping process of the target drive protocol data. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or some intermediate form. Storage media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the contents of storage media can be appropriately added to or removed according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, storage media may not include electrical carrier signals and telecommunication signals.

[0096] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application. The specific embodiments described above further illustrate the purpose, technical solutions, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the protection scope of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A hierarchical drive adaptation method for a robot actuator, characterized in that, The method is applied to a hierarchical control system architecture that includes upper-level control logic or task planners, motion abstraction layers, adapter mapping frameworks, drive adapter interfaces, and lower-level actuators. The method includes: Step S1: Receive the motion command MotionCommand generated by the upper-level control logic or task planner, which is independent of the actuator; Step S2: Through the motion abstraction layer, the motion instructions are converted into a unified motion intermediate representation, which is a standard motion description data structure that is independent of the actuator, verifiable, and compilable. Step S3: Query the actuator configuration file to obtain the capability parameters and protocol type of the target underlying actuator, and map the unified motion intermediate representation to target driver protocol data that matches the protocol type through the adapter mapping framework; Step S4: Through the driver adapter interface, send the target driver protocol data to the corresponding underlying actuator before the preset deadline, and read the hardware feedback and standardize it into a general status feedback. Step S5: During the execution of the hierarchical drive adaptation method for the robot actuator, the current control quality index is dynamically evaluated based on the deviation between the general state feedback and the unified motion intermediate representation. When the control quality index is lower than a preset threshold, the following adapter mapping parameter reconfiguration process is triggered: query the preset quality degradation compensation table in the actuator configuration file to obtain the compensation parameters corresponding to the current deviation type and magnitude; dynamically adjust at least one conversion rule in the adapter mapping framework according to the compensation parameters, the conversion rule including unit conversion factor, nonlinear compensation curve or frame format mapping relationship; apply the adjusted conversion rule to the mapping process of the target drive protocol data. The step of receiving the motion command MotionCommand generated by the upper-layer control logic or task planner and independent of the executor also includes: performing integrity verification and field unit normalization on the motion command; The process of converting the motion command into a unified intermediate motion representation through the motion abstraction layer further includes: performing unit normalization, amplitude limiting, and trajectory interpolation on the unified intermediate motion representation to generate a standardized motion intent; when limiting the amplitude of the unified intermediate motion representation, performing nonlinear mapping or hysteresis compensation on the target value according to the response characteristic curve in the actuator configuration file to eliminate the response delay differences between different actuators.

2. The hierarchical drive adaptation method for robot actuators according to claim 1, characterized in that, The method further includes: In multi-actuator collaboration scenarios, a multi-actuator coordinator maintains the independent state and shared context of each actuator. Based on timestamps, resource locks, and synchronization groups, the actions and feedback of multiple executors are bound into the same traceable process.

3. The hierarchical drive adaptation method for robot actuators according to claim 2, characterized in that, The process of binding the actions and feedback of multiple executors into a single traceable process based on timestamps, resource locks, and synchronization groups includes: The local clock offset and communication delay of each actuator are obtained by the multi-actuator coordinator, and corresponding delay compensation is applied to the action command of each actuator to synchronize the actual start time of all actuators.

4. The hierarchical drive adaptation method for robot actuators according to claim 1, characterized in that, The method further includes: During execution, a structured hash calculation is performed on the general state feedback at fixed intervals or when an event is triggered. The hash value obtained from the structured hash calculation is stored in the audit log along with the timestamp.

5. The hierarchical drive adaptation method for robot actuators according to claim 4, characterized in that, The step of storing the hash value obtained from the structured hash calculation along with the timestamp into the audit log includes: Associate the hash value of the current general status feedback with the hash value of the corresponding motion command; The version number of the executor configuration file is packaged together into an audit entry, which is organized in a Merkle tree structure to support efficient post-verification and local tamper detection.

6. A layered drive adapter for a robot actuator, characterized in that, The device is applied to a hierarchical control system architecture comprising upper-level control logic or task planner, motion abstraction layer, adapter mapping framework, drive adapter interface, and lower-level actuator, to implement the hierarchical drive adaptation method for robot actuators as described in any one of claims 1 to 5. The device includes: The instruction receiving module is used to receive motion instructions (MotionCommand) generated by the upper-level control logic or task planner that are independent of the actuator. The generation module is used to convert the motion instructions into a unified motion intermediate representation through the motion abstraction layer. The unified motion intermediate representation is a standard motion description data structure that is independent of the actuator, verifiable, and compilable. The mapping module is used to query the executor configuration file, obtain the capability parameters and protocol type of the target underlying executor, and map the unified motion intermediate representation to target driver protocol data that matches the protocol type through the adapter mapping framework; The standardization module is used to send the target driver protocol data to the corresponding underlying actuator before a preset deadline through the driver adapter interface, and to read the hardware feedback and standardize it into a general status feedback. The adjustment module is used during the process of the device executing the hierarchical drive adaptation method for the robot actuator to dynamically evaluate the current control quality index based on the deviation between the general state feedback and the unified motion intermediate representation. When the control quality index is lower than a preset threshold, the following adapter mapping parameter reconfiguration process is triggered: querying the preset quality degradation compensation table in the actuator configuration file to obtain the compensation parameters corresponding to the current deviation type and magnitude; dynamically adjusting at least one conversion rule in the adapter mapping framework according to the compensation parameters, the conversion rule including unit conversion factor, nonlinear compensation curve or frame format mapping relationship; and applying the adjusted conversion rule to the mapping process of the target drive protocol data.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the hierarchical driver adaptation method for the robot actuator as described in any one of claims 1 to 5.

8. A storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the hierarchical drive adaptation method for the robot actuator as described in any one of claims 1 to 5.

Images