A Model-Defined Robot Control System Configuration Generation Method and System

Abstract

This invention provides a model-defined robot control system configuration generation method and system, including: extracting the robot's kinematic and dynamic parameters from a 3D model file to generate a unified robot description format file; reading a hardware interface plugin library to obtain communication protocol templates and parameter configuration items corresponding to various hardware models, and establishing a mapping table between joints and hardware models; parsing the control strategy configuration file to extract the control mode, PID initial parameters, and motion safety conditions for each joint; automatically generating a control system configuration file through a configuration generation engine based on the description format file, the joint-hardware model mapping relationship, and the control strategy; loading the control system configuration file into the robot controller, and communicating with the actual hardware through the hardware interface plugin to achieve real-time control of the robot. This invention can achieve automated configuration from 3D design to control system, improving development efficiency and system consistency.

Description

Technical Field

[0001] This invention relates to the field of robot control technology, specifically to a model-defined robot control system configuration generation method and system, aiming to achieve automated configuration generation from a 3D design model to a ROS2-control system. Background Technology

[0002] With the rapid development of robotics technology, the complexity of robot control system development is increasing daily. In the traditional robot control system development process, the mechanical design phase and the control software design phase are often separated. Mechanical engineers use CAD software (such as SolidWorks, Fusion 360, etc.) to design the robot body and export a 3D model; control engineers then manually write URDF (Uniform Robot Description Format) files and ROS2-control configuration files based on the exported model information.

[0003] The existing technology has the following shortcomings: First, manually writing control system configuration files is inefficient, especially for complex multi-joint robots. Configuring parameters for dozens of joints requires a lot of repetitive work and is prone to human errors such as inconsistent joint names or missing transmission parameters, leading to abnormal control system operation. Second, URDF files mainly contain geometric and kinematic information, while ROS2-control configuration requires control strategy information such as hardware interface parameters, controller PID gain, and safety limits. The two types of information have different dimensions, making automatic conversion difficult. Third, when the mechanical design changes, the control configuration needs to be modified synchronously, but the lack of an effective synchronization mechanism leads to a disconnect between design and control.

[0004] Existing tools such as xacro macros can achieve parametric description to some extent, but they still require manual macro definition writing and cannot automatically extract parameters from 3D models. MoveIt! Configuration Assistant can generate controller configuration files, but it is mainly for motion planning scenarios and is based on the ROS1 ros_control framework, with limited support for ROS2-control. Summary of the Invention

[0005] To address the technical problems of existing robot control system configuration relying on manual programming, which is inefficient and prone to errors, the present invention aims to provide a model-defined robot control system configuration generation method and system, which can realize automated configuration from 3D design to control system, improving development efficiency and system consistency.

[0006] The present invention achieves the above objectives through the following technical solutions: A model-defined robot control system configuration generation method includes: Extract the robot's kinematic and dynamic parameters from the 3D model file to generate a unified robot description format file containing link geometry information, joint types, and transmission relationships; Read the hardware interface plugin library, obtain the communication protocol templates and parameter configuration items corresponding to various hardware models, and establish a mapping table between joints and hardware models; Parse the preset control strategy configuration file to extract the control mode, PID initial parameters, and motion safety conditions for each joint; Based on the unified robot description format file, the mapping relationship between joints and hardware models, and the control strategy, the ROS2-control system configuration file is automatically generated through the configuration generation engine. The control system configuration file is loaded into the robot controller, and the robot communicates with the actual hardware through a hardware interface plug-in to achieve real-time control of the robot.

[0007] According to the model-defined robot control system configuration generation method provided by the present invention, kinematic parameters and dynamic parameters are extracted from a 3D model file, including: The CAD software plugin automatically identifies the joint constraint type in the assembly and extracts the joint axis position, axis direction, range of motion, as well as the link mass, center of mass position, and inertia tensor parameters. The CAD software plugin is compatible with assembly files in SolidWorks or Fusion 360 format. It generates a unified robot description format file from the extracted parameters. The unified robot description format file is in URDF or SDF format, and the hardware model identifier and control mode identifier are embedded in the unified robot description format file through custom tags.

[0008] According to the model-defined robot control system configuration generation method provided by the present invention, hardware model identifiers and control mode identifiers are embedded in a unified robot description format file through custom tags, including: In the unified robot description format file, each joint corresponds to <joint>In the tag, add a custom attribute field hardware_model to identify the hardware model associated with the joint; add a custom attribute field control_mode to identify the control mode of the joint, which includes position control, speed control or torque control. exist <transmission>In the tag, through<hardware_interface> The sub-tag embeds a hardware communication interface type identifier, including a CANopen protocol identifier, an EtherCAT protocol identifier, or a serial communication identifier, as well as the corresponding communication parameters, including CAN ID, baud rate, and encoder resolution; exist <link> The tag embeds the dynamic parameter identifiers of the link through custom attribute fields, including mass, center of mass coordinates center_of_mass, and matrix elements of the inertia tensor ixx, iyy, izz, ixy, ixz, and iyz.

[0009] According to the model-defined robot control system configuration generation method provided by the present invention, each plugin in the hardware interface plugin library inherits from the hardware_interface::SystemInterface base class of the ROS2-control control system, and encapsulates the communication details with the specified hardware model. The communication details include the data frame format and timing of CANopen protocol, EtherCAT protocol or serial communication. Each plugin provides a unified command interface and status feedback interface to the upper layer. The command interface includes a position command interface, a speed command interface, and a torque command interface. The status feedback interface includes a position feedback interface, a speed feedback interface, a torque feedback interface, and a status flag interface. The command interface and status feedback interface adopt a unified data structure definition, which includes a timestamp field, a data validity flag field, and a data value field.

[0010] According to the model-defined robot control system configuration generation method provided by the present invention, the method reads a hardware interface plugin library to obtain communication protocol templates and parameter configuration items corresponding to various hardware models, including: The plugin management module scans the hardware interface plugin library directory and loads the metadata description file of each plugin. The metadata description file records the list of hardware models supported by the plugin, the communication protocol type, the configurable parameters and their value ranges. The communication protocol types include CANopen protocol, EtherCAT protocol and serial communication protocol. The configurable parameters include CAN ID, baud rate, encoder resolution, number of motor pole pairs and transmission ratio. A hardware model list table is generated based on the metadata description file. Each entry in the hardware model list table contains a hardware model identifier, the corresponding plug-in name, a communication protocol template, and a parameter configuration item template. The mapping relationship between joints and hardware models is established in the following way: Based on the transmission ratio, maximum torque requirement, and motion speed requirement of each joint, the system automatically matches the appropriate hardware model from the hardware model list and generates an initial mapping relationship table. It provides a graphical configuration interface that allows users to manually adjust the initial mapping table, including modifying the hardware model of a single joint, adjusting the CAN ID allocation of multiple joints under the same hardware model, and setting the bus topology. The final confirmed mapping table is stored in YAML format and referenced in the joint tags of the unified robot description format file through the hardware_model attribute.

[0011] According to a model-defined robot control system configuration generation method provided by the present invention, the ROS2-control control system configuration file includes the following configuration parts: The hardware interface configuration section specifies the hardware plug-ins and communication parameters associated with each joint, including: The hardware plugin type field points to the specific plugin name in the hardware interface plugin library; The communication parameter fields include CAN ID, baud rate, encoder resolution, number of motor pole pairs and transmission ratio. Each parameter field is associated with the hardware_model attribute of the corresponding joint in the unified robot description format file. The command interface and status feedback interface fields are as follows: the command interface includes the position command interface, the speed command interface, and the torque command interface; the status feedback interface includes the position feedback interface, the speed feedback interface, the torque feedback interface, and the status flag interface. The controller configuration section is used to define the controller type, the list of associated joints, and the PID parameters, specifically including: The controller type field is automatically selected by the template engine of the configuration generation engine based on the robot type; The Joint List field is used to reference the joint names in the Unified Robot Description Format file and corresponds one-to-one with the communication parameters in the Hardware Interface Configuration section. The PID parameter fields include proportional gain P, integral gain I, derivative gain D, as well as feedforward gain and filter parameters. The initial values ​​of the PID parameters are extracted from the control strategy configuration file and automatically optimized based on the simulation results during the simulation verification step. The safety configuration section defines position soft limits, speed limits, and following error thresholds, specifically including: The position soft limit field includes the minimum position threshold and the maximum position threshold. The position threshold is generated based on the joint range of motion in the unified robot description format file and the position_limit parameter in the control strategy configuration file. The speed limit field includes the maximum speed threshold and the maximum acceleration threshold. The speed / acceleration thresholds are generated based on the velocity_limit and acceleration_limit parameters in the control policy configuration file. The following error threshold field is used in trajectory tracking control to determine the deviation between the command and the actual state. When the deviation exceeds the threshold, a safety protection action is triggered. Additional safety condition fields include at least one of the following: motor current threshold and communication timeout threshold. The motor current threshold is set according to the current_limit parameter in the control strategy configuration file, and the communication timeout threshold is used to detect whether the communication link between the hardware interface plug-in and the driver is normal.

[0012] According to the model-defined robot control system configuration generation method provided by the present invention, the motion safety conditions include at least one of the following: joint position soft limit, joint velocity limit, joint acceleration limit, motor current threshold, and communication timeout threshold.

[0013] The robot control system configuration generation method based on model definition provided by the present invention further includes a simulation verification step: After generating the ROS2-control system configuration file, the configuration file is loaded into the simulation environment, which can be either the Gazebo simulation environment or the Ignition simulation environment. At the same time, the virtual robot model corresponding to the unified robot description format file is loaded. The link geometry information, joint type, transmission ratio and range of motion of the virtual robot model are consistent with those of the unified robot description format file. The mass and inertia tensor parameters of each link are extracted from the unified robot description format file to initialize the dynamic characteristics of the virtual robot. A virtual hardware communication link is established through the hardware interface configuration section of the configuration file. Each controller defined in the controller configuration section is activated, and test motion sequences are executed on the virtual robot model. These test motion sequences include at least: single-joint position step response test, multi-joint coordinated trajectory tracking test, and emergency stop and safety limit trigger test. During the test, the joint position, velocity, and torque status data of the virtual robot model, as well as the command data output by the controller, are collected in real time to verify the correctness of the following control logic: In position control mode, is the tracking error between the actual joint position and the commanded position within the allowable range? In speed control mode, does the actual speed of the joint converge to the commanded speed? In torque control mode, does the joint output torque match the command torque? Does the safety protection mechanism trigger correctly when the joint position exceeds the soft limit, the speed exceeds the speed limit, or the motor current exceeds the current threshold?

[0014] According to a model-defined robot control system configuration generation method provided by the present invention, the following performance indicators are calculated based on the collected state data and command data: Root mean square error (RMSE) of position tracking; Speed ​​response overshoot and settling time; Maximum following error in trajectory tracking; The trigger response time of the security protection mechanism; The performance indicators are compared with the preset qualified thresholds. If any indicator exceeds the qualified threshold, an anomaly diagnosis report is generated. The anomaly diagnosis report marks the joint number where the anomaly occurred, the anomaly type, and the corresponding configuration parameter item. When any performance metric exceeds the acceptable threshold, the automatic PID parameter optimization process is initiated, including: Determine the joint number and corresponding PID parameter item that need to be adjusted based on the abnormal diagnosis report; The particle swarm optimization algorithm or Bayesian optimization algorithm is adopted, with the minimization of the root mean square error of position tracking as the objective function. The initial PID parameters in the control strategy configuration file are used as the search starting point, and iterative optimization is performed in the parameter search space. The parameter search space is jointly defined by the value range of PID parameters and safety constraints. After generating candidate PID parameter sets in each iteration, the test motion sequence is executed in the simulation environment to evaluate the performance indicators of the candidate parameter sets until the objective function converges or the maximum number of iterations is reached. Write the optimized PID parameters into the PID parameter field of the corresponding joint in the control strategy configuration file, and update the PID parameters in the controller configuration section of the ROS2-control system configuration file. Substitute the optimized PID parameters into the simulation environment and execute the complete test motion sequence again. After confirming that all performance indicators are within the acceptable threshold range, output the final ROS2-control system configuration file. The configuration file contains the optimized PID parameters and includes a performance indicator report that has passed the simulation verification.

[0015] A model-defined robot control system configuration generation system, comprising: The model parsing module is used to extract robot kinematic and dynamic parameters from 3D model files and generate a unified robot description format file containing link geometry information, joint types and transmission relationships; The hardware mapping module is used to read the hardware interface plug-in library, obtain the communication protocol templates and parameter configuration items corresponding to various hardware models, and establish the mapping relationship between joints and hardware models. The strategy configuration module is used to parse the preset control strategy configuration file and extract the control mode, PID initial parameters and motion safety conditions of each joint. The configuration generation engine is used to automatically generate ROS2-control system configuration files based on a unified robot description format file, the mapping relationship between joints and hardware models, and the control strategy. The controller loading module is used to load the control system configuration file into the robot controller and communicate with the actual hardware through the hardware interface plug-in to achieve real-time control of the robot.

[0016] Therefore, compared with the prior art, the robot control system configuration generation method and system based on model definition proposed in this invention have the following beneficial effects: 1. This invention can realize automated configuration from 3D design to control system, eliminating the workload of manually writing configuration files and improving development efficiency; 2. This invention ensures consistency between mechanical design and control configuration through a unified model definition, avoiding the problem of asynchronous control parameters caused by design changes; 3. The modular hardware interface plug-in design of this invention supports rapid adaptation and replacement of various hardware models, improving system scalability; 4. This invention incorporates a simulation verification process, which can detect control logic problems in advance in a virtual environment, reducing the risk of debugging on a real machine; 5. The configuration generation engine of this invention supports template-based customization and can adapt to different types of robot application scenarios.

[0017] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0018] Figure 1 This is a flowchart of an embodiment of a robot control system configuration generation method based on model definition according to the present invention.

[0019] Figure 2 This is a system architecture diagram of the hardware interface plug-in library in an embodiment of a model-defined robot control system configuration generation method of the present invention.

[0020] Figure 3 This is a schematic diagram illustrating the working principle of the configuration generation engine in an embodiment of a model-defined robot control system configuration generation method of the present invention. Figure 4 This is a system schematic diagram of an embodiment of a robot control system configuration generation system based on model definition according to the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] An Example of a Model-Defined Robot Control System Configuration Generation Method See Figures 1 to 3 This embodiment provides a model-defined robot control system configuration generation method, including: Step S1: Extract the robot's kinematic and dynamic parameters from the 3D model file to generate a unified robot description format file containing link geometry information, joint types, and transmission relationships; Step S2: Read the hardware interface plugin library, obtain the communication protocol templates and parameter configuration items corresponding to various hardware models, and establish a mapping relationship table between joints and hardware models; Step S3: Parse the preset control strategy configuration file and extract the control mode, PID initial parameters and motion safety conditions for each joint; Step S4: Based on the unified robot description format file, the mapping relationship between joints and hardware models, and the control strategy, the ROS2-control system configuration file is automatically generated through the configuration generation engine. Step S5: Load the control system configuration file into the robot controller, and communicate with the actual hardware through the hardware interface plug-in to achieve real-time control of the robot.

[0024] In step S1 above, kinematic and dynamic parameters are extracted from the 3D model file, including: The CAD software plugin automatically identifies the joint constraint type in the assembly and extracts the joint axis position, axis direction, range of motion, as well as the link mass, center of mass position, and inertia tensor parameters. The CAD software plugin is compatible with assembly files in SolidWorks or Fusion 360 format. It generates a unified robot description format file from the extracted parameters. The unified robot description format file is in URDF or SDF format, and the hardware model identifier and control mode identifier are embedded in the unified robot description format file through custom tags.

[0025] In this embodiment, hardware model identifiers and control mode identifiers are embedded in the unified robot description format file using custom tags, including: In the unified robot description format file, each joint corresponds to <joint>In the tag, add a custom attribute field hardware_model to identify the hardware model associated with the joint; add a custom attribute field control_mode to identify the control mode of the joint, which includes position control, speed control or torque control. exist <transmission>In the tag, through<hardware_interface> The sub-tag embeds a hardware communication interface type identifier, including a CANopen protocol identifier, an EtherCAT protocol identifier, or a serial communication identifier, as well as the corresponding communication parameters, including CAN ID, baud rate, and encoder resolution; exist <link> The tag embeds the dynamic parameter identifiers of the link through custom attribute fields, including mass, center of mass coordinates center_of_mass, and matrix elements of the inertia tensor ixx, iyy, izz, ixy, ixz, and iyz. The unified robot description format file adopts URDF or SDF format. Custom tags follow the XML namespace specification. By declaring a custom namespace prefix in the file header, it is ensured that custom attributes are compatible with the standard parser and do not affect the normal reading and parsing of the file.

[0026] In step S2 above, each plugin in the hardware interface plugin library inherits from the hardware_interface::SystemInterface base class of the ROS2-control control system, and encapsulates the communication details with the specified hardware model. The communication details include the data frame format and timing of CANopen protocol, EtherCAT protocol or serial communication. Each plugin provides a unified command interface and status feedback interface to the upper layer. The command interface includes a position command interface, a speed command interface, and a torque command interface. The status feedback interface includes a position feedback interface, a speed feedback interface, a torque feedback interface, and a status flag interface. The command interface and status feedback interface adopt a unified data structure definition. The data structure includes a timestamp field, a data validity flag field, and a data value field, so that the upper-layer control algorithm does not need to be aware of the differences in the underlying hardware communication protocol. It can complete the drive control of different hardware models by calling the unified interface.

[0027] In this embodiment, the hardware interface plugin library is read to obtain communication protocol templates and parameter configuration items corresponding to various hardware models, including: The plugin management module scans the hardware interface plugin library directory and loads the metadata description file of each plugin. The metadata description file records the list of hardware models supported by the plugin, the communication protocol type, the configurable parameters and their value ranges. The communication protocol types include CANopen protocol, EtherCAT protocol and serial communication protocol. The configurable parameters include CAN ID, baud rate, encoder resolution, number of motor pole pairs and transmission ratio. A hardware model list table is generated based on the metadata description file. Each entry in the hardware model list table contains a hardware model identifier, the corresponding plug-in name, a communication protocol template, and a parameter configuration item template. The mapping relationship between joints and hardware models is established in the following way: Based on the transmission ratio, maximum torque requirement, and motion speed requirement of each joint, the system automatically matches the appropriate hardware model from the hardware model list and generates an initial mapping relationship table. It provides a graphical configuration interface that allows users to manually adjust the initial mapping table, including modifying the hardware model of a single joint, adjusting the CAN ID allocation of multiple joints under the same hardware model, and setting the bus topology. The final confirmed mapping table is stored in YAML format and referenced in the joint tags of the unified robot description format file through the hardware_model attribute, ensuring that the configuration generation engine can accurately obtain the hardware plug-in type and communication parameters corresponding to each joint based on the mapping table.

[0028] In step S4 above, the ROS2-control system configuration file includes the following configuration sections: The hardware interface configuration section specifies the hardware plug-ins and communication parameters associated with each joint, including: The hardware plug-in type field points to the specific plug-in name in the hardware interface plug-in library. The plug-in encapsulates the communication details of the CANopen protocol, EtherCAT protocol, or serial communication. The communication parameter fields include CAN ID, baud rate, encoder resolution, number of motor pole pairs and transmission ratio. Each parameter field is associated with the hardware_model attribute of the corresponding joint in the unified robot description format file. The command interface and status feedback interface fields are as follows: the command interface includes the position command interface, the speed command interface, and the torque command interface; the status feedback interface includes the position feedback interface, the speed feedback interface, the torque feedback interface, and the status flag interface. The controller configuration section is used to define the controller type, the list of associated joints, and the PID parameters, specifically including: The controller type field includes at least one of JointTrajectoryController, JointGroupPositionController, JointGroupVelocityController, and diff_drive_controller. The controller type is automatically selected by the template engine of the configuration generation engine based on the robot type. The Joint List field is used to reference the joint names in the Unified Robot Description Format file and corresponds one-to-one with the communication parameters in the Hardware Interface Configuration section. The PID parameter fields include proportional gain P, integral gain I, derivative gain D, as well as feedforward gain and filter parameters. The initial values ​​of the PID parameters are extracted from the control strategy configuration file and automatically optimized based on the simulation results during the simulation verification step. The safety configuration section defines position soft limits, speed limits, and following error thresholds, specifically including: The position soft limit field includes the minimum position threshold and the maximum position threshold. The position threshold is generated based on the joint motion range in the unified robot description format file and the position_limit parameter in the control strategy configuration file, and the unit is radians or degrees. The speed limit field includes the maximum speed threshold and the maximum acceleration threshold. The speed / acceleration thresholds are generated based on the velocity_limit and acceleration_limit parameters in the control policy configuration file. The following error threshold field is used in trajectory tracking control to determine the deviation between the command and the actual state. When the deviation exceeds the threshold, a safety protection action is triggered. Additional safety condition fields include at least one of motor current threshold and communication timeout threshold. The motor current threshold is set according to the current_limit parameter in the control strategy configuration file. The communication timeout threshold is used to detect whether the communication link between the hardware interface plug-in and the driver is normal. The hardware interface configuration, controller configuration, and safety configuration are organized in the same ROS2-control configuration file in YAML format. Each part is isolated by a unified namespace. The configuration generation engine automatically generates a complete configuration file based on the number of joints in the unified robot description format file, the plug-in type in the hardware mapping table, and the parameters in the control strategy configuration file, using a template-filling method.

[0029] In step S3 above, the motion safety conditions include at least one of the following: joint position soft limit, joint velocity limit, joint acceleration limit, motor current threshold, and communication timeout threshold.

[0030] In this embodiment, a simulation verification step is also included: After generating the ROS2-control system configuration file, the configuration file is loaded into the simulation environment, which can be either the Gazebo simulation environment or the Ignition simulation environment. At the same time, the virtual robot model corresponding to the unified robot description format file is loaded. The link geometry information, joint type, transmission ratio and range of motion of the virtual robot model are consistent with those of the unified robot description format file. The mass and inertia tensor parameters of each link are extracted from the unified robot description format file to initialize the dynamic characteristics of the virtual robot. A virtual hardware communication link is established through the hardware interface configuration section of the configuration file. Each controller defined in the controller configuration section is activated, and test motion sequences are executed on the virtual robot model. These test motion sequences include at least: single-joint position step response test, multi-joint coordinated trajectory tracking test, and emergency stop and safety limit trigger test. During the test, the joint position, velocity, and torque status data of the virtual robot model, as well as the command data output by the controller, are collected in real time to verify the correctness of the following control logic: In position control mode, is the tracking error between the actual joint position and the commanded position within the allowable range? In speed control mode, does the actual speed of the joint converge to the commanded speed? In torque control mode, does the joint output torque match the command torque? Does the safety protection mechanism trigger correctly when the joint position exceeds the soft limit, the speed exceeds the speed limit, or the motor current exceeds the current threshold?

[0031] Based on the collected status data and command data, the following performance metrics are calculated: Root mean square error (RMSE) of position tracking; Speed ​​response overshoot and settling time; Maximum following error in trajectory tracking; The trigger response time of the security protection mechanism; The performance indicators are compared with the preset qualified thresholds. If any indicator exceeds the qualified threshold, an anomaly diagnosis report is generated. The anomaly diagnosis report marks the joint number where the anomaly occurred, the anomaly type, and the corresponding configuration parameter item. When any performance metric exceeds the acceptable threshold, the automatic PID parameter optimization process is initiated, including: Determine the joint number and corresponding PID parameter item that need to be adjusted based on the abnormal diagnosis report; The particle swarm optimization algorithm or Bayesian optimization algorithm is adopted, with the minimization of the root mean square error of position tracking as the objective function. The initial PID parameters in the control strategy configuration file are used as the search starting point, and iterative optimization is performed within the preset parameter search space. The parameter search space is jointly defined by the value range of PID parameters and safety constraints. After generating candidate PID parameter sets in each iteration, the test motion sequence is executed in the simulation environment to evaluate the performance indicators of the candidate parameter sets until the objective function converges or the maximum number of iterations is reached. Write the optimized PID parameters into the PID parameter field of the corresponding joint in the control strategy configuration file, and update the PID parameters in the controller configuration section of the ROS2-control system configuration file. After substituting the optimized PID parameters into the simulation environment and executing the complete test motion sequence again, and confirming that all performance indicators are within the acceptable threshold range, the final ROS2-control system configuration file is output. The configuration file contains the optimized PID parameters and includes a performance indicator report that has passed the simulation verification, which can be loaded into the real robot controller later.

[0032] Furthermore, in step S1 above, the kinematic and dynamic parameters of the robot are extracted from the 3D model file. In this embodiment, a six-DOF collaborative robot is designed using SolidWorks software. By developing a SolidWorks plugin, the rotational joint constraints in the assembly are automatically identified, and the axis position, axis direction, and range of motion (±180°) of each joint are extracted. The mass, center of mass position, and inertia tensor of each link are also calculated. The plugin generates the extracted parameters into a URDF format file and, according to the annotation method, places them in the URDF... <transmission>Add a custom attribute hardware_model="mydriver_can" to the tag to identify the hardware model associated with this joint.

[0033] Further, in step S2 above, the hardware interface plugin library is read. In this embodiment, the hardware interface plugin library contains plugins for various motor drivers, such as the Maxon driver plugin for the CANopen protocol and the Elmo driver plugin for the EtherCAT protocol. Each plugin encapsulates the communication protocol details and provides unified read() and write() interfaces. The system reads the plugin library, obtains the parameter items supported by each plugin, such as CAN ID, baud rate, encoder resolution, etc., and establishes a mapping table between joints and hardware models.

[0034] Furthermore, in step S3 above, the control policy configuration file is parsed. In this embodiment, a control policy file in YAML format is pre-written, with the following content: yaml joint1: control_mode: position pid: {p: 100.0, i: 0.1, d: 1.0} safety: position_limit: [-175, 175] velocity_limit: 180 current_limit: 2.0 joint2: control_mode: position pid: {p: 150.0, i: 0.2, d: 1.5} safety: position_limit: [-90, 90] velocity_limit: 180 current_limit: 2.0 Furthermore, in step S4 above, the configuration generation engine automatically generates the ROS2-control configuration file. The configuration generation engine first parses the generated URDF file to obtain the names of each joint and the transmission ratio; then, based on the hardware mapping relationship, it obtains the hardware plug-in type and parameters corresponding to each joint; finally, it combines the control strategy parameters to populate the predefined controller template. A snippet of the ROS2-control configuration file (YAML format) generated in this embodiment is as follows: yaml controller_manager: ros__parameters: update_rate: 1000 joint_trajectory_controller: type: joint_trajectory_controller / JointTrajectoryController joints: - joint1 - joint2 - joint3 - joint4 - joint5 - joint6 command_interfaces: - position state_interfaces: - position - velocity my_robot_hardware: type: my_package / MyRobotHardware joints: - joint1 - joint2 - joint3 - joint4 - joint5 - joint6 joint1: hardware_model: mydriver_can can_id: 1 encoder_resolution: 16384 pid: {p: 100.0, i: 0.1, d: 1.0} safety: {min_position: -3.054, max_position: 3.054, max_velocity:3.14} joint2: hardware_model: mydriver_can can_id: 2 encoder_resolution: 16384 pid: {p: 150.0, i: 0.2, d: 1.5} safety: {min_position: -1.571, max_position: 1.571, max_velocity:3.14} Furthermore, in step S5 above, the generated configuration file is loaded into the robot controller. In this embodiment, the controller runs the ROS2 Humble distribution and loads the generated configuration file using the ros2 control load_controller command. The hardware interface plugin initializes CAN communication according to the configuration parameters and establishes connections with the drivers of each joint to achieve real-time control.

[0035] Furthermore, in the simulation verification step, before actual operation, the generated configuration file is loaded into the Gazebo simulation environment. The smoothness and safety of motion planning are verified through the virtual robot model, and the PID parameters are fine-tuned based on the simulation results.

[0036] An Implementation Example of a Model-Defined Robot Control System Configuration Generation System like Figure 4 As shown, a model-defined robot control system configuration generation system includes: The model parsing module extracts robot kinematics and dynamics parameters from 3D model files, generating a unified robot description format file, i.e., a URDF file, containing link geometry information, joint types, and transmission relationships. This module integrates a CAD software plugin, enabling it to recognize assembly files from mainstream CAD software such as SolidWorks and Fusion 360. The hardware mapping module is used to read the hardware interface plugin library, obtain the communication protocol templates and parameter configuration items corresponding to various hardware models, and establish the mapping relationship between joints and hardware models. This module maintains a hardware model list and provides a graphical interface for users to select the hardware model and configuration parameters corresponding to each joint.

[0037] The strategy configuration module is used to parse the preset control strategy configuration file and extract the control mode, PID initial parameters, and motion safety conditions of each joint. This module supports configuration files in formats such as YAML and JSON and provides parameter validation functions.

[0038] The configuration generation engine is used to automatically generate ROS2-control system configuration files based on a unified robot description format file, the mapping relationship between joints and hardware models, and the control strategy. The engine has a built-in template engine that supports custom template extensions.

[0039] The controller loading module loads the control system configuration file into the robot controller and communicates with the actual hardware via a hardware interface plugin to achieve real-time control of the robot. This module provides both a command-line interface and a ROS2 service interface for easy integration into automated deployment processes.

[0040] The simulation verification module is used to load the generated configuration file into the simulation environment, verify the correctness of the control logic, and optimize the parameters based on the simulation results.

[0041] In this embodiment, the modules communicate with each other through a standard data format. The model parsing module outputs a URDF file, the hardware mapping module outputs a hardware mapping table, the strategy configuration module outputs a control parameter table, and the configuration generation engine integrates the three to generate the final ROS2-control configuration file, realizing full-process automation from design to control.

[0042] In practical applications, this invention is applied to the drive wheel control of a mobile robot chassis. The mobile robot chassis includes two drive wheels and four driven wheels, with the drive wheels using brushless DC motors equipped with Hall sensors. Chassis geometric parameters are extracted using a CAD plugin, and the hardware mapping module maps the drive wheels to the bldc_can_plugin hardware plugin. The control strategy is configured as speed control mode, and the PID parameters are determined after simulation optimization. The generated ROS2-control configuration file implements chassis motion control through diff_drive_controller, verifying the applicability of this invention on different types of robots.

[0043] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0044] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.< / transmission> < / transmission> < / joint> < / transmission> < / joint>

Claims

1. A method for generating configurations for a robot control system based on model definition, characterized in that, include: Extract the robot's kinematic and dynamic parameters from the 3D model file to generate a unified robot description format file containing link geometry information, joint types, and transmission relationships; Read the hardware interface plugin library, obtain the communication protocol templates and parameter configuration items corresponding to various hardware models, and establish a mapping table between joints and hardware models; Parse the preset control strategy configuration file to extract the control mode, PID initial parameters, and motion safety conditions for each joint; Based on the unified robot description format file, the mapping relationship between joints and hardware models, and the control strategy, the ROS2-control system configuration file is automatically generated through the configuration generation engine. The control system configuration file is loaded into the robot controller, and the robot communicates with the actual hardware through a hardware interface plug-in to achieve real-time control of the robot.

2. The method according to claim 1, characterized in that, Extract kinematic and dynamic parameters from the 3D model file, including: The CAD software plugin automatically identifies the joint constraint type in the assembly and extracts the joint axis position, axis direction, range of motion, as well as the link mass, center of mass position, and inertia tensor parameters. The CAD software plugin is compatible with assembly files in SolidWorks or Fusion 360 format. It generates a unified robot description format file from the extracted parameters. The unified robot description format file is in URDF or SDF format, and the hardware model identifier and control mode identifier are embedded in the unified robot description format file through custom tags.

3. The method according to claim 2, characterized in that, In the unified robot description format file, hardware model identifiers and control mode identifiers are embedded using custom tags, including: In the unified robot description format file, each joint corresponds to <joint> In the tag, add a custom attribute field hardware_model to identify the hardware model associated with the joint; add a custom attribute field control_mode to identify the control mode of the joint, which includes position control, speed control or torque control.< / joint> exist <transmission> In the tag, through<hardware_interface> The sub-tag embeds a hardware communication interface type identifier, including a CANopen protocol identifier, an EtherCAT protocol identifier, or a serial communication identifier, as well as the corresponding communication parameters, including CAN ID, baud rate, and encoder resolution;< / transmission> exist <link> The tag embeds the dynamic parameter identifiers of the link through custom attribute fields, including mass, center of mass coordinates center_of_mass, and matrix elements of the inertia tensor ixx, iyy, izz, ixy, ixz, and iyz.

4. The method according to claim 1, characterized in that: Each plugin in the hardware interface plugin library inherits from the hardware_interface::SystemInterface base class of the ROS2-control system, encapsulating the communication details with the specified hardware model. The communication details include the data frame format and timing of CANopen protocol, EtherCAT protocol or serial communication. Each plugin provides a unified command interface and status feedback interface to the upper layer. The command interface includes a position command interface, a speed command interface, and a torque command interface. The status feedback interface includes a position feedback interface, a speed feedback interface, a torque feedback interface, and a status flag interface. The command interface and status feedback interface adopt a unified data structure definition, which includes a timestamp field, a data validity flag field, and a data value field.

5. The method according to claim 1, characterized in that, Read the hardware interface plugin library to obtain communication protocol templates and parameter configuration items corresponding to various hardware models, including: The plugin management module scans the hardware interface plugin library directory and loads the metadata description file of each plugin. The metadata description file records the list of hardware models supported by the plugin, the communication protocol type, the configurable parameters and their value ranges. The communication protocol types include CANopen protocol, EtherCAT protocol and serial communication protocol. The configurable parameters include CANID, baud rate, encoder resolution, number of motor pole pairs and transmission ratio. A hardware model list table is generated based on the metadata description file. Each entry in the hardware model list table contains a hardware model identifier, the corresponding plug-in name, a communication protocol template, and a parameter configuration item template. The mapping relationship between joints and hardware models is established in the following way: Based on the transmission ratio, maximum torque requirement, and motion speed requirement of each joint, the system automatically matches the appropriate hardware model from the hardware model list and generates an initial mapping relationship table. It provides a graphical configuration interface that allows users to manually adjust the initial mapping table, including modifying the hardware model of a single joint, adjusting the CAN ID allocation of multiple joints under the same hardware model, and setting the bus topology. The final confirmed mapping table is stored in YAML format and referenced in the joint tags of the unified robot description format file through the hardware_model attribute.

6. The method according to claim 1, characterized in that, The ROS2-control system configuration file includes the following configuration sections: The hardware interface configuration section specifies the hardware plug-ins and communication parameters associated with each joint, including: The hardware plugin type field points to the specific plugin name in the hardware interface plugin library; The communication parameter fields include CAN ID, baud rate, encoder resolution, number of motor pole pairs and transmission ratio. Each parameter field is associated with the hardware_model attribute of the corresponding joint in the unified robot description format file. The command interface and status feedback interface fields are as follows: the command interface includes the position command interface, the speed command interface, and the torque command interface; the status feedback interface includes the position feedback interface, the speed feedback interface, the torque feedback interface, and the status flag interface. The controller configuration section is used to define the controller type, the list of associated joints, and the PID parameters, specifically including: The controller type field is automatically selected by the template engine of the configuration generation engine based on the robot type; The Joint List field is used to reference the joint names in the Unified Robot Description Format file and corresponds one-to-one with the communication parameters in the Hardware Interface Configuration section. The PID parameter fields include proportional gain P, integral gain I, derivative gain D, as well as feedforward gain and filter parameters. The initial values ​​of the PID parameters are extracted from the control strategy configuration file and automatically optimized based on the simulation results during the simulation verification step. The safety configuration section defines position soft limits, speed limits, and following error thresholds, specifically including: The position soft limit field includes the minimum position threshold and the maximum position threshold. The position threshold is generated based on the joint range of motion in the unified robot description format file and the position_limit parameter in the control strategy configuration file. The speed limit field includes the maximum speed threshold and the maximum acceleration threshold. The speed / acceleration thresholds are generated based on the velocity_limit and acceleration_limit parameters in the control policy configuration file. The following error threshold field is used in trajectory tracking control to determine the deviation between the command and the actual state. When the deviation exceeds the threshold, a safety protection action is triggered. Additional safety condition fields include at least one of the following: motor current threshold and communication timeout threshold. The motor current threshold is set according to the current_limit parameter in the control strategy configuration file, and the communication timeout threshold is used to detect whether the communication link between the hardware interface plug-in and the driver is normal.

7. The method according to claim 1, characterized in that: The sports safety conditions include at least one of the following: joint position soft limit, joint velocity limit, joint acceleration limit, motor current threshold, and communication timeout threshold.

8. The method according to any one of claims 1 to 7, characterized in that, It also includes simulation verification steps: After generating the ROS2-control system configuration file, the configuration file is loaded into the simulation environment, which can be either the Gazebo simulation environment or the Ignition simulation environment. At the same time, the virtual robot model corresponding to the unified robot description format file is loaded. The link geometry information, joint type, transmission ratio and range of motion of the virtual robot model are consistent with those of the unified robot description format file. The mass and inertia tensor parameters of each link are extracted from the unified robot description format file to initialize the dynamic characteristics of the virtual robot. A virtual hardware communication link is established through the hardware interface configuration section of the configuration file. Each controller defined in the controller configuration section is activated, and test motion sequences are executed on the virtual robot model. These test motion sequences include at least: single-joint position step response test, multi-joint coordinated trajectory tracking test, and emergency stop and safety limit trigger test. During the test, the joint position, velocity, and torque status data of the virtual robot model, as well as the command data output by the controller, are collected in real time to verify the correctness of the following control logic: In position control mode, is the tracking error between the actual joint position and the commanded position within the allowable range? In speed control mode, does the actual speed of the joint converge to the commanded speed? In torque control mode, does the joint output torque match the command torque? Does the safety protection mechanism trigger correctly when the joint position exceeds the soft limit, the speed exceeds the speed limit, or the motor current exceeds the current threshold? 9. The method according to claim 8, characterized in that, Based on the collected status data and command data, the following performance metrics are calculated: Root mean square error (RMSE) of position tracking; Speed ​​response overshoot and settling time; Maximum following error in trajectory tracking; The trigger response time of the security protection mechanism; The performance indicators are compared with the preset qualified thresholds. If any indicator exceeds the qualified threshold, an anomaly diagnosis report is generated. The anomaly diagnosis report marks the joint number where the anomaly occurred, the anomaly type, and the corresponding configuration parameter item. When any performance metric exceeds the acceptable threshold, the automatic PID parameter optimization process is initiated, including: Determine the joint number and corresponding PID parameter item that need to be adjusted based on the abnormal diagnosis report; The particle swarm optimization algorithm or Bayesian optimization algorithm is adopted, with the minimization of the root mean square error of position tracking as the objective function. The initial PID parameters in the control strategy configuration file are used as the search starting point, and iterative optimization is performed in the parameter search space. The parameter search space is jointly defined by the value range of PID parameters and safety constraints. After generating candidate PID parameter sets in each iteration, the test motion sequence is executed in the simulation environment to evaluate the performance indicators of the candidate parameter sets until the objective function converges or the maximum number of iterations is reached. Write the optimized PID parameters into the PID parameter field of the corresponding joint in the control strategy configuration file, and update the PID parameters in the controller configuration section of the ROS2-control system configuration file. Substitute the optimized PID parameters into the simulation environment and execute the complete test motion sequence again. After confirming that all performance indicators are within the acceptable threshold range, output the final ROS2-control system configuration file. The configuration file contains the optimized PID parameters and includes a performance indicator report that has passed the simulation verification.

10. A model-defined robot control system configuration generation system, characterized in that, include: The model parsing module is used to extract robot kinematic and dynamic parameters from 3D model files and generate a unified robot description format file containing link geometry information, joint types and transmission relationships; The hardware mapping module is used to read the hardware interface plug-in library, obtain the communication protocol templates and parameter configuration items corresponding to various hardware models, and establish the mapping relationship between joints and hardware models. The strategy configuration module is used to parse the preset control strategy configuration file and extract the control mode, PID initial parameters and motion safety conditions of each joint. The configuration generation engine is used to automatically generate ROS2-control system configuration files based on a unified robot description format file, the mapping relationship between joints and hardware models, and the control strategy. The controller loading module is used to load the control system configuration file into the robot controller and communicate with the actual hardware through the hardware interface plug-in to achieve real-time control of the robot.

Images