Robot urdf model construction method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of robot modeling, and provides a robot URDF model construction method and device, electronic equipment and a storage medium. The method comprises the following steps: receiving a task description input by a user; clarifying and optimizing the task description to generate an optimized task description; performing semantic analysis on the optimized task description to extract task requirement parameters; selecting multiple candidate components from a robot component library based on the task requirement parameters; performing cross-domain compatibility pre-verification on the selected candidate components before the selected candidate components are combined; combining the candidate components that have passed the cross-domain compatibility pre-verification according to combination constraints between the components to generate multiple candidate URDF models; and evaluating the candidate URDF models based on the task requirement parameters and in combination with a Pareto frontier surface to obtain an optimal URDF model and output the optimal URDF model. The technical scheme significantly reduces the threshold of robot modeling and improves the matching efficiency of the model and the task.

Description

Technical Field

[0001] This application relates to the field of robot modeling technology, and in particular to a method, apparatus, electronic device and storage medium for constructing a robot URDF model. Background Technology

[0002] Robot modeling is the cornerstone of robot system design, simulation, and control algorithm development. The Unified Robot Description Format (URDF), as a universal model description standard within ecosystems such as Robot Operating Systems (ROS), defines the robot's kinematic chains, geometric appearance, physical properties, and sensor configuration in a structured manner. Efficiently and accurately constructing URDF models is crucial for shortening robot development cycles, reducing trial-and-error costs, and ensuring consistency between simulation and reality.

[0003] Currently, existing technologies attempt to automate or intelligentize the URDF model construction process to some extent. For example, some existing technologies disclose methods that analyze structured functional requirements, match components from a component library, automatically combine components based on assembly point matching rules, and finally select the optimal assembly scheme through performance prediction. These methods, to some extent, encode human design experience into rules, improving the efficiency of model construction.

[0004] However, these existing technical solutions still have the following significant limitations, making it difficult to cope with complex and flexible practical engineering needs: 1) They typically assume that the user's input task requirements are clear and unambiguous, lacking an active identification and interactive clarification mechanism for the inherent ambiguity and contradictions in natural language descriptions, leading to unstable input quality in automated processes; 2) Existing solutions mostly focus on the mechanical interfaces and kinematic matching of components, neglecting the compatibility issues of different components in soft aspects such as control protocols, communication interfaces, and software drivers, resulting in the automatically assembled model potentially facing difficult-to-integrate soft obstacles during system integration; 3) When selecting the optimal model from multiple feasible solutions, existing methods often use relatively simple single-objective evaluation or weighted scoring, making it difficult to scientifically and comprehensively weigh the inherent conflicts and trade-offs between multi-dimensional objectives such as performance, cost, and long-term reliability, which may lead to poor performance of the selected solution in actual long-term operation. These defects restrict the practicality, integration success rate, and long-term operational reliability of the output results of automated design systems. Summary of the Invention

[0005] Based on this, it is necessary to address the shortcomings of the existing technologies, such as the lack of proactive clarification of ambiguous requirements, neglect of cross-domain compatibility verification of software and hardware, and difficulty in scientifically balancing multiple objectives in decision-making. Therefore, a robot URDF model construction method, device, electronic equipment, and storage medium are proposed.

[0006] Firstly, a method for constructing a robot URDF model is provided, the method comprising:

[0007] Receive a task description input by the user, wherein the task description is natural language text;

[0008] The task description is clarified and optimized by: identifying ambiguous or conflicting requirements in the task description, generating clarification questions for the ambiguous or conflicting requirements based on a preset robotics domain knowledge base and feeding them back to the user, and receiving supplementary or corrective input from the user on the clarification questions to generate an optimized task description.

[0009] Semantic analysis is performed on the optimized task description to extract task requirement parameters, which include at least one of load capacity, mobility range, and accuracy requirements.

[0010] Based on the task requirement parameters, select multiple candidate components from the robot component library;

[0011] Before combining the selected candidate components, perform cross-domain compatibility pre-verification on the selected candidate components: verify the compatibility between any two candidate components to be connected at the level of control protocol, communication bus type and software driver interface, and eliminate component combinations with cross-domain compatibility conflicts.

[0012] Based on the combination constraints between components, the candidate components that have passed the cross-domain compatibility pre-verification are combined to generate multiple candidate URDF models. The combination constraints include geometric constraints and dynamic constraints.

[0013] Based on the task requirement parameters, the candidate URDF models are evaluated using the Pareto front to obtain and output the optimal URDF model.

[0014] Secondly, a robot URDF model building device is provided, the device comprising:

[0015] The receiving module is used to receive a task description input by the user, wherein the task description is natural language text;

[0016] The optimization module is used to clarify and optimize the task description: identify ambiguous or conflicting requirements in the task description, generate clarification questions for the ambiguous or conflicting requirements based on a preset robot domain knowledge base and feed them back to the user, and receive supplementary or corrective input from the user on the clarification questions to generate an optimized task description.

[0017] The analysis module is used to perform semantic analysis on the optimized task description and extract task requirement parameters, which include at least one of load capacity, mobility range, and accuracy requirements.

[0018] The selection module is used to select multiple candidate components from the robot component library based on the task requirement parameters. The robot component library includes joints, links, actuators, and sensor components.

[0019] The verification module is used to perform cross-domain compatibility pre-verification on the selected candidate components before combining them: verifying the compatibility between any two candidate components to be connected at the level of control protocol, communication bus type and software driver interface, and eliminating component combinations with cross-domain compatibility conflicts.

[0020] The generation module is used to combine the candidate components that have been pre-verified for cross-domain compatibility according to the combination constraints between components to generate multiple candidate URDF models. The combination constraints include geometric constraints and dynamic constraints.

[0021] The evaluation module is used to evaluate the candidate URDF models based on task requirement parameters and in conjunction with the Pareto front, to obtain and output the optimal URDF model.

[0022] Thirdly, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described robot URDF model construction method.

[0023] Fourthly, a storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described robot URDF model construction method.

[0024] As can be seen from the technical solution provided in this application, on the one hand, since the technical solution of this application does not directly parse the natural language task description after receiving it, but first performs clarification optimization including identifying ambiguous and conflicting requirements, generating interactive clarification questions based on the knowledge base, and receiving user corrections, this process transforms a one-time, potentially incomplete input into a human-machine collaborative iterative confirmation process. This process can proactively discover and eliminate ambiguities and contradictions in the original requirements, generating a clear and consistent optimized task description, thereby providing a solid and reliable requirement input for all subsequent automated steps, reducing the risk of the entire design process failing due to misunderstandings of requirements from the source. On the other hand, after component selection and before traditional geometric and dynamic combination, cross-domain compatibility pre-verification is introduced to specifically verify the compatibility between candidate components at the soft interface level, such as control protocols, communication buses, and software drivers, and eliminate conflicting combinations, thereby expanding the compatibility check from a single mechanical and physical domain to a broader scope. In multiple domains, including control, communication, and software, the automatically generated candidate URDF models are ensured to be not only mechanically assemblable and kinematically feasible, but also possess a solid integration foundation at the electrical and software levels. This avoids major rework issues caused by software incompatibility discovered late in the design process, improving the first-time success rate of the design results. Thirdly, when evaluating multiple candidate URDF models, a strategy combining Pareto fronts is adopted. This strategy does not simply rank the models, but first places all models in a multi-dimensional objective space, identifies the Pareto front representing the optimal trade-off, and then selects from it. This systematically presents all non-dominated optimal solution sets, and makes the final choice based on clearly defined decision rules within a scientifically defined optimal solution set. This ensures that the final output optimal model is the result of rigorous multi-objective optimization analysis, achieving a good balance among multiple key indicators. The decision-making process is more transparent and reasonable, avoiding the decision-making trap of falling into local optima or sacrificing one aspect for another. In summary, the technical solution of this application improves the reliability and scientific rigor of the entire process from requirement input and design error prevention to solution decision-making by introducing task clarification optimization, cross-domain compatibility pre-verification, and Pareto front-based evaluation. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein:

[0026] Figure 1 This is a flowchart of a robot URDF model construction method in one embodiment;

[0027] Figure 2 This is a structural block diagram of a robot URDF model building device in one embodiment;

[0028] Figure 3 This is a structural block diagram of an electronic device in one embodiment. Detailed Implementation

[0029] The technical solutions of the embodiments of the present 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 the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] Currently, existing technologies attempt to automate or intelligentize the URDF model construction process to some extent. For example, some existing technologies disclose methods that analyze structured functional requirements, match components from a component library, automatically combine components based on assembly point matching rules, and finally select the optimal assembly scheme through performance prediction. These methods, to some extent, encode human design experience into rules, improving the efficiency of model construction. However, these existing technical solutions still have the following significant limitations, making it difficult to cope with complex and flexible practical engineering needs: 1) They typically assume that the user's input task requirements are clear and unambiguous, lacking an active identification and interactive clarification mechanism for the inherent ambiguity and contradictions in natural language descriptions, leading to unstable input quality in automated processes; 2) Existing solutions mostly focus on the mechanical interfaces and kinematic matching of components, neglecting the compatibility issues of different components in soft aspects such as control protocols, communication interfaces, and software drivers, resulting in the automatically assembled model potentially facing difficult-to-integrate soft obstacles during system integration; 3) When selecting the optimal model from multiple feasible solutions, existing methods often use relatively simple single-objective evaluation or weighted scoring, making it difficult to scientifically and comprehensively weigh the inherent conflicts and trade-offs between multi-dimensional objectives such as performance, cost, and long-term reliability, which may lead to poor performance of the selected solution in actual long-term operation. These defects restrict the practicality, integration success rate, and long-term operational reliability of the output results of automated design systems.

[0031] To address the aforementioned problems in the existing technology, this application proposes a method for constructing a robot URDF model, the main process of which is as follows: Figure 1 As shown, it mainly includes steps S101 to S107, which are detailed below:

[0032] Step S101: Receive a task description input by the user, wherein the task description is natural language text.

[0033] Users input natural language text describing the tasks the robot is expected to perform through the system's human-computer interaction interface. For example, a user could input, "Design a robot to pick up electronic motherboards weighing no more than 3 kg on an assembly line and accurately place them into a designated fixture," or "A six-axis robotic arm with a working radius of no less than 1.5 meters is needed for arc welding operations." This step transforms the user's intuitive, high-level operational intentions into the starting point for system processing, replacing the cumbersome process of requiring users to directly configure complex engineering parameters in traditional methods.

[0034] Step S102: Clarify and optimize the task description: Identify ambiguous or conflicting requirements in the task description, generate clarification questions for the ambiguous or conflicting requirements based on the preset robot domain knowledge base, and provide feedback to the user. Receive supplementary or corrective input from the user on the clarification questions to generate an optimized task description.

[0035] Step S102 is to ensure the accuracy and completeness of the input task description, and to avoid the failure of subsequent automated processes due to ambiguity in the initial description. Specifically, step S102 can be implemented through steps S1021 to S1023, as detailed below:

[0036] Step S1021: Identify ambiguous or conflicting requirements in the task description.

[0037] The system performs preliminary semantic analysis on the input task descriptions, identifying potentially ambiguous, missing, or contradictory key information. For example, in the description of "quickly moving heavy objects," both "quickly" and "heavy objects" are qualitative descriptions lacking quantitative standards, making it a fuzzy requirement. Similarly, in the description of "requiring both extremely high precision and extremely low cost," simultaneously achieving optimal results may be difficult in engineering, representing a potentially conflicting requirement. The identification process can be achieved by matching a pre-defined fuzzy keyword library (e.g., "quick," "precise," "large") and a conflict rule library (e.g., the combination of "high precision" and "low cost" triggers an alarm).

[0038] Step S1022: Based on the preset robotics domain knowledge base, generate clarification questions for ambiguous or conflicting needs and provide feedback to the user.

[0039] The system's embedded robotics domain knowledge base includes not only component parameters but also mapping experience between typical tasks and performance parameters. When ambiguous or conflicting requirements are identified, the system generates specific guiding questions based on this knowledge base. For example, for "rapidly moving heavy objects," the system might generate questions such as: "Please clarify the specific cycle time requirement for 'rapid' (e.g., how many times per hour) and the specific mass range of the 'heavy object' (e.g., 5-10 kg)." For conflicting requirements, questions like: "When accuracy and cost need to be balanced, which metric has higher priority?" are generated. These questions are presented to the user through an interactive interface.

[0040] Step S1023: Receive supplementary or corrective input from the user regarding the clarification question to generate an optimized task description for subsequent semantic analysis.

[0041] Following system prompts, users quantify ambiguous points and prioritize conflicting ones. The system then merges the user's additional input with the original description to create an optimized, unambiguous task description. This optimized description will serve as input for step S103.

[0042] As can be seen from steps S1021 to S1023 of the above embodiments, by actively engaging in human-computer interaction, a potentially unsuccessful automation attempt is transformed into an iterative requirement confirmation process, which significantly improves the system's robustness to complex and incomplete natural language input and ensures that subsequent automation processes are built on a solid and clear requirement foundation.

[0043] Step S103: Perform semantic analysis on the optimized task description and extract task requirement parameters, wherein the task requirement parameters include at least one of load capacity, movement range, and accuracy requirements.

[0044] Traditional methods rely on engineers interpreting task descriptions, which is highly subjective and inefficient. The technical solution adopted in this application involves semantic analysis of the optimized task description to extract task requirement parameters. This approach achieves automatic conversion from fuzzy natural language descriptions to precise engineering parameters, significantly improving the accuracy and efficiency of parameter extraction. Furthermore, it can understand the multiple performance requirements implicit in complex tasks such as "assembling precision electronic components," providing a reliable quantitative basis for subsequent component selection. This solves the model design defects caused by misunderstandings of requirements in traditional methods. Specifically, semantic analysis of the optimized task description to extract task requirement parameters can be achieved through the following steps S1031 to S1033:

[0045] Step S1031: Perform word segmentation and part-of-speech tagging on the optimized task description.

[0046] The system invokes a word segmentation tool and, in conjunction with a dictionary of robotics terminology (e.g., "SCARA", "RV reducer", "repetitive positioning accuracy", etc.), accurately segments the optimized task description text. Part-of-speech tagging is then performed to identify nouns, verbs, adjectives, numerals, quantifiers, etc., laying the foundation for subsequent information extraction.

[0047] Step S1032: Extract key entities and relationships to form a task requirement diagram.

[0048] Specifically, a trained named entity recognition model can be used to extract key entities from the text. These entities include: robot action objects (e.g., "electronic motherboard," "workpiece"), environmental conditions (e.g., "assembly line," "1.5-meter radius"), and performance modifiers (e.g., "precise," "fast"), etc. Simultaneously, through dependency parsing or relation extraction models, relationships between entities are identified. These relationships primarily include action types (e.g., "grasp," "place," "weld") and explicit performance indicator associations (e.g., "weight not exceeding 3 kg"). Subsequently, the system constructs a structured task requirement graph, with entities as nodes and relationships as edges. This task requirement graph is a structured representation of the task semantics.

[0049] Step S1033: Map the task requirement graph to task requirement parameters.

[0050] The system traverses the task requirement graph according to predefined mapping rules, transforming the elements in the graph into quantified task requirement parameters. In this embodiment, the mapping rules are stored in a domain knowledge base, for example:

[0051] 1) Action "grab" + object "electronic motherboard" -> Implicit requirement: The end effector type is "gripper" and it needs to be compliantly controlled;

[0052] 2) "Weight not exceeding 3 kg" -> Quantitative parameter: Load capacity <= 3 kg;

[0053] 3) "Precise Placement" -> Repeat positioning accuracy <= 0.05 mm;

[0054] 4) "Working radius not less than 1.5 meters" -> Quantitative parameter: Movement range (radial) >= 1.5 m.

[0055] In the example above, the symbol "->" represents a mapping. Ultimately, a set of structured parameters is output, serving as the basis for decisions in all subsequent steps.

[0056] Through steps S1031 to S1033, unstructured language descriptions can be transformed into quantitative engineering indicators that machines can accurately understand and process, providing a computable basis for task-driven approaches and eliminating errors and uncertainties in human interpretation.

[0057] Step S104: Select multiple candidate components from the robot component library based on the task requirement parameters.

[0058] After obtaining the clearly defined task requirements parameters, it is necessary to select from a robot component library containing various components such as joints, links, motors, reducers, and sensors. Each component in the library has standardized attribute descriptions, including geometric dimensions, mass, inertia, rated torque, speed, accuracy, cost, interface type, control protocol, communication bus support, software driver information, and performance degradation model parameters based on accelerated life testing, etc.

[0059] Specifically, selecting multiple candidate components from the robot component library based on task requirement parameters can be achieved through the following steps S1041 and S1042:

[0060] Step S1041: Calculate the matching degree between each component and the task requirement parameters.

[0061] The system calculates a matching score for each candidate component, using the following formula:

[0062]

[0063] in, This represents the matching score of component i. A higher score indicates that the component better meets the task requirements. n represents the number of task requirement parameters. This represents the weight of the task requirement parameter j, which can be dynamically adjusted based on keywords in the task description (e.g., increasing the weight of the precision parameter if the description emphasizes "high precision"), and satisfies the following conditions: , Indicates task requirement parameters j Numerical or categorical data (e.g., load 3.0 kg); This represents the characteristic value of component i on the task requirement parameter j (e.g., rated load 5.0 kg). This represents the similarity function used to calculate... and The similarity between them.

[0064] The system differentiates the calculation rules for the similarity function based on the parameter type:

[0065] 1) For parameters where "the larger the better" (e.g., load capacity, speed): When the component's characteristic value c is greater than or equal to the task requirement value q, the component's capacity is considered to fully meet or even exceed the requirement, and the similarity is set to the maximum value of 1. (when (Time). When the component's capabilities are insufficient, the similarity decays according to the ratio of c to q. Its value is less than 1.

[0066] 2) For parameters where "smaller is better" (e.g., accuracy error, cost): when the component's characteristic value is less than or equal to the task requirement value, the component's performance is considered to meet the requirements, and the similarity is set to the maximum value of 1. (when (Time). When component performance fails to meet standards, the similarity decays according to the ratio of q to c. Its value is less than 1.

[0067] Step S1042: Select components with matching scores higher than a preset threshold as candidate components.

[0068] For each type of component (e.g., lumbar joint motor), the system selects a matching score. The top K components, or all components exceeding the threshold T, form the initial candidate component set for that position.

[0069] In some embodiments, to further improve the "composability" within the candidate component set and avoid selecting "isolated" components that are difficult to combine with other components, after forming the initial candidate component set, a compatibility pre-screening based on historical data can also be performed. That is, the selection of multiple candidate components from the robot component library in the above embodiments further includes the following steps S104C to S104E for pre-screening the initially matched candidate components:

[0070] Step S104C: Based on the historical combination success rate data between components, calculate the combination compatibility score between any two candidate components.

[0071] The system maintains a historical combination database, recording instances of component combinations that have successfully generated feasible robot models in the past. Based on this data, the combination compatibility score CompScore(A,B) for any two components can be calculated. A specific calculation method is as follows: count the number of times component A and component B appear as direct partners in all historically successful models, divide this number by the total number of historically successful models, and normalize the result. The ratio obtained is CompScore(A,B). The higher the CompScore(A,B) value (the closer it is to 1), the better the compatibility between the two components in historical experience, and the greater the probability that they together constitute a feasible design.

[0072] Step S104D: Based on the combination compatibility score between any two candidate components, remove isolated components from the initially matched component set whose combination compatibility scores with all other components are lower than the preset compatibility threshold, so as to obtain the pre-screened component set.

[0073] For the robot configuration to be built, the system determines, based on its topology, which other components (e.g., "link 1" and "link 2") should be evaluated for compatibility with candidate components at each component position (e.g., "joint 2"). For each component X in the initial candidate set, the average of its combination compatibility score (CompScore) with candidate components at all possible connection positions is calculated. If this average is lower than a preset compatibility threshold, X is considered an isolated component that is difficult to pair with other available components in the current configuration context, and it is likely difficult to form a feasible local connection. The system removes such components from the candidate set. It should be noted that the above compatibility threshold can be set based on historical data analysis. For example, the lower quantile (e.g., 10th percentile) of the combination compatibility score (CompScore) of all historically successful combinations of component pairs can be used as the threshold. Alternatively, it can be adjusted based on experience or through experiments: an initial value (e.g., 0.1) can be set, and if too few components remain after filtering, the threshold can be appropriately lowered; if a large number of invalid combinations are still generated, the threshold can be increased. The core idea is to filter out component pairs that have rarely or never been successfully paired in history.

[0074] Step S104E: Use the pre-screened component set as candidate components for subsequent combination.

[0075] After parameter matching, configuration screening, and compatibility pre-screening, a high-quality set of candidate components is finally obtained that meets the performance requirements, conforms to the direction in terms of configuration, and has good internal compatibility historically. It performs fine-grained screening of massive components from three dimensions: "capability matching", "architecture adaptation", and "historical compatibility". This not only significantly reduces the search space for combinatorial optimization in the early stages of the process and significantly improves the efficiency of subsequent steps, but more importantly, by eliminating mismatched configurations and incompatible components, it avoids a large number of combinatorial paths that are bound to fail in advance, guiding the search to focus on high-potential solution areas, thereby improving the success rate of generating feasible and high-quality models.

[0076] Step S105: Before combining the selected candidate components, perform the following cross-domain compatibility pre-verification: verify the compatibility between any two candidate components to be connected at the level of control protocol, communication bus type and software driver interface, and eliminate component combinations with cross-domain compatibility conflicts.

[0077] Existing technologies typically only verify the matching of mechanical assembly points. However, in actual robot integration, components from different suppliers, even if mechanically connectable, may fail to work together due to incompatibility at the control, communication, and software levels. This application introduces cross-domain compatibility pre-verification to eliminate such "soft incompatibility" risks early in the assembly process, significantly improving the system integration feasibility of the generated solution. Specific verifications include verifying control protocol compatibility, communication bus type compatibility, and software driver interface compatibility, detailed below:

[0078] 1) Verify control protocol compatibility, specifically by checking whether the motion control protocol (e.g., EtherCAT, CANopen, Modbus) versions claimed to be supported by the two components to be connected are consistent, or whether there is a known, reliable protocol conversion gateway or mapping rule base that supports their interoperability.

[0079] 2) Verify the compatibility of communication bus types. Specifically, check whether the physical communication interface (e.g., RJ45, DB9, terminal block) type of the two candidate components matches the electrical standard (e.g., RS485, CAN_H / L) and confirm that their configurable baud rate ranges overlap.

[0080] 3) Verify software driver interface compatibility. Specifically, check whether the device driver files (e.g., ROS driver, PLC function block) of the two candidate components are developed for the same robot middleware framework (e.g., ROS1 Noetic, ROS2 Humble) and compatible versions to avoid driver loading failure due to API incompatibility.

[0081] It should be noted that the robot middleware framework mentioned above refers to a standardized software platform located between the underlying hardware, operating system and upper-level applications (such as motion planning, perception algorithms, etc.) in the robot operating system. Its core function is to abstract hardware details, manage resources and provide a general mechanism for communication and data exchange between components.

[0082] The system performs the above verification for each pair of potentially connected candidate components, eliminating component combinations with cross-domain compatibility conflicts (i.e., component combinations that fail at least one of the above verifications for control protocol compatibility, communication bus type compatibility, and software driver interface compatibility), thereby obtaining a pre-verified set of candidate components. This step avoids the common problem in the integration phase where hard connections are successful but soft controls are not, from the design stage.

[0083] Step S106: Based on the combination constraints between components, combine the pre-validated candidate components to generate multiple candidate URDF models, where the combination constraints include geometric constraints and dynamic constraints.

[0084] In traditional robot design, engineers need to manually try various component combinations and verify their feasibility and performance through experience-based judgment or tedious simulations. This is a process with high trial-and-error costs and heavy reliance on expert experience. This application automates the enumeration and generation of feasible robot configurations by formalizing the combinatorial problem into a constraint satisfaction problem and solving it using a backtracking algorithm. Specifically, step S106 can be implemented through steps S1061 to S1063, as detailed below:

[0085] Step S1061: Establish a constraint satisfaction problem model. In this model, variables represent component types, domains represent specific components, and constraints include geometric constraints and dynamic constraints.

[0086] The system abstracts the robot's configuration as a sequence; for example, for a serial manipulator, the sequence is [base joint, link 1, joint 2, link 2, ..., end flange]. Each position in the sequence is a variable representing the required component type at that location. The domain of each variable is the set of all pre-validated candidate components output from step S105 that are applicable to that position. Constraints define the conditions that these variables (components) must satisfy when taking values ​​(being instantiated by specific components), mainly including geometric constraints and dynamic constraints, which together ensure that the generated robot is physically manufacturable and kinematically feasible.

[0087] Step S1062: Use a backtracking algorithm to solve the constraint satisfaction problem and generate a sequence of component connections that satisfy both geometric and dynamic constraints.

[0088] The system employs a backtracking algorithm as the solver. The algorithm starts with the first variable (e.g., the base joint) and performs a depth-first search, as detailed in steps S1062a to S1062d:

[0089] Step S1062a: Assign a value to the current variable, specifically: select a specific component that has not yet been tried from the domain of the variable (i.e., the pre-validated candidate component set) and assign a value to it.

[0090] Step S1062b: Constraint check, which may specifically be: performing a constraint check on the currently formed partial component sequence (i.e., partial solution) to verify whether it satisfies all geometric and dynamic constraints.

[0091] Step S1062c: Process the check results, including: if all geometric and dynamic constraints are satisfied and there are still unassigned variables, the algorithm moves on to the next variable and repeats step S1062a.

[0092] If all geometric and dynamic constraints are satisfied and all variables have been assigned values, a feasible component connection sequence is successfully generated.

[0093] If any geometric or dynamic constraint is violated, the algorithm attempts to assign the next optional component in its domain to the current variable (i.e., repeat step S1062a to select a new value for the same variable).

[0094] Step S1062d: Backtracking: If all components in the domain of the current variable have been tried and all result in constraint violations, then the current partial solution has no path. At this point, the algorithm performs backtracking: undoes the assignment of the current variable, returns to the previously assigned variable, and tries the next optional component in its domain for that variable. Then, it continues the search from that point, repeating steps S1062a to S1062c.

[0095] From steps S1062a to S1062d in the example above, it can be seen that, on the one hand, when choosing a value for the current variable causes a local constraint (e.g., a mismatch with the interface of the selected component) to be violated immediately, the algorithm can immediately realize that this path is not violating and switch paths at the same decision level, rather than delving into subsequent variables to construct a more complex local combination that is destined to fail overall. This is equivalent to pruning branches that are unlikely to bear fruit early in the search tree; on the other hand, by timely eliminating invalid options at the current level, the algorithm greatly reduces the search space that needs to be explored. If this is not done, and instead each conflict is directly backtracked to the upper level, the algorithm will perform a large number of repetitive and inefficient short loops of "backtracking-slightly advancing-again conflict," failing to effectively utilize the conflict information already discovered to guide other choices at the same level, thus causing the combinatorial explosion problem to be uncontrollable. In other words, through the above iterative process of "trying-checking-advancing or backtracking," the system can systematically explore all possible component combinations and finally output all component connection sequences that satisfy geometric and dynamic constraints.

[0096] To improve search efficiency, especially when the component library is large and the combinatorial space is exploding, this application also includes heuristic strategies for steps S1062A to S1062C, which are detailed below:

[0097] Step S1062A: When selecting components for the current joint, prioritize the component with the highest historical successful combination frequency with the selected components.

[0098] The system queries the historical combination database. For example, when selecting a motor for "Joint 2", if the currently selected "Link 1" is a certain model, then among the candidate components for "Joint 2", motor models that have historically been successfully paired with that model of "Link 1" will be given higher selection priority. This utilizes historical experience to guide the search direction.

[0099] Step S1062B: When encountering a constraint conflict and backtracking, prioritize backtracking to the preceding decision node that is closest to the current decision node and has an untried alternative component.

[0100] When trying all components for the current variable results in a conflict, backtracking is necessary. This strategy specifies that instead of always backtracking to the very beginning of the sequence, it backtracks to the most recent decision node that still has untried candidate components. This reduces inefficient deep backtracking and improves search efficiency.

[0101] Step S1062C: Record and update the component combination sequence and its performance evaluation results corresponding to each successful generation of a complete kinematic chain, and use it as historical data to optimize subsequent heuristic selections.

[0102] For each successfully generated complete feasible sequence, the performance data of the sequence and its subsequent evaluation (e.g., overall performance score) are recorded in the historical database. During this process, the system extracts all directly adjacent component pairs from each successful sequence and updates the "historical successful combination experience values" of these component pairs in the database based on the overall performance score of the sequence. These continuously accumulating and weighted updated experience value data constitute the direct basis for the "historical successful combination frequency" judgment in step S1062A, enabling the heuristic strategy to continuously evolve and become increasingly intelligent as the system is used. Specifically, updating the "historical successful combination experience values" of these component pairs in the database based on the overall performance score of the sequence can be achieved as follows: whenever a complete candidate URDF model is successfully generated and its overall performance index score P (e.g., P=92) is obtained through evaluation, an update process is triggered, including: parsing the component connection sequence of the successful model […]. , , , ..., ,..., Extract all directly adjacent component pairs from it, i.e.: ( , ), ( , ),..., ( , ), ..., ( , For each extracted component pair ( , Then, perform the following update operation: Calculate the contribution weight for this update: the weight is not fixed at 1, but is positively correlated with the overall performance index score P of the sequence. A simple mapping is to define a weight function. For example: w = P / 100 (if P is a perfect score of 100), making high-performance sequences (high P-values) contribute more, or setting a threshold, only when... Updates are only triggered for high-quality sequences (e.g., P = 80), in which case w = 1; updates are performed using the concepts of exponential moving average or weighted average, ensuring that the empirical values ​​absorb new information without excessively forgetting history. Taking weighted average as an example: the current empirical value is read from the database. and current cumulative weights ,pass + as well as

[0103] As can be seen from steps S1062A to S1062C above, the heuristic strategy transforms a blind, potentially combinatorial, exhaustive search process into a directional search process guided by data-driven historical success experiences and local conflict resolution strategies, greatly improving the efficiency and success rate of finding feasible solutions in a vast solution space.

[0104] In each constraint check step of the backtracking algorithm, the core is to verify the combined constraints. The following provides a detailed explanation of geometric constraints, dynamic constraints, and their verification:

[0105] 1) Geometric constraints, which are used to ensure physical compatibility when components are connected. Traditional compatibility checks only focus on interface matching; this method extends this approach. Geometric constraint verification first checks interface matching using a formula:

[0106]

[0107] in, This indicates the geometric constraint satisfaction level. A value of 1 indicates that all connection points satisfy the geometric constraints, while a value of 0 indicates that at least one connection point does not satisfy them. m represents the number of connection points between the two components. and Indicates the first k Two components at a connection point, or This indicates the type of component at the k-th connection point, including shaft type (e.g., output shaft, input shaft) and interface size (e.g., flange diameter, bolt hole spacing). It is an indicator function, when and Returns 1 if a match is found, otherwise returns 0. Only if a match is found. At this point, component composition is considered preliminarily feasible at the interface level. Specifically, in the embodiments of this application, for each of the m connection points in a candidate component composition, a type-matching-based verification method can be used for point-by-point detection. During implementation, for each connection point k, the two components... and The system extracts the interface type features (including shaft type, mounting hole diameter, thread specification, flange size, etc.) and compares and verifies them using a predefined matching rule base. The indicator function is activated only if the interface types of the two components are completely compatible. Returns 1 otherwise; the geometric constraint satisfaction is finally obtained through a series of multiplication operations. Only when all connection points pass verification (i.e. Only when the physical connection compatibility between components is verified can the assembly be considered geometrically feasible. This automated verification effectively solves the assembly conflict problem caused by interface mismatch in traditional robot design. It avoids the risk of oversight by manual inspection and significantly improves the reliability and efficiency of model building, providing a key guarantee for generating directly manufacturable robot models.

[0108] In addition, geometric constraints also include 3D spatial interference checks. 3D spatial interference checks are crucial for ensuring collision-free operation of components in 3D space. Specifically, this involves: the system pre-calculating a simplified 3D model for each component in the component library, such as an Axis-Aligned Bounding Box (AABB) or Oriented Bounding Box (OBB); during the assembly verification process, the system calculates the spatial pose of each component based on the local kinematic chains formed by the currently assigned components; a hierarchical collision detection algorithm based on bounding boxes is used to quickly detect whether there is static interference (i.e., overlap under the current pose) between the bounding boxes of any two components; for components with moving joints, the system also samples multiple poses within their motion range for dynamic interference checks to predict whether collisions will occur during movement. Only a combination of precise interface matching verification and the aforementioned static or dynamic interference checks is considered to satisfy the complete geometric constraints. This dual verification mechanism of precise interface matching + spatial collision prediction solves the physical space conflict problem, thereby ensuring the physical assemblability and motion safety of the generated model.

[0109] 2) Dynamic constraints, i.e., used to ensure the feasibility of the robot's motion performance. This is a rapid pre-screening process, avoiding time-consuming high-fidelity dynamic simulations for all combinations. Dynamic constraint verification is the core of ensuring that the generated robot model can not only be assembled but also operate safely and effectively. This application adopts a series of simplified but engineering-critical dynamic feasibility verification formulas, achieving a balance between computational efficiency and evaluation accuracy. Specifically, dynamic constraint verification mainly includes the following: joint torque capacity verification, joint velocity and acceleration capacity verification, and structural natural frequency and vibration characteristics verification:

[0110] 2.1) Joint Torque Capacity Verification: For each joint in the kinematic chain, the system needs to verify whether the maximum torque required to execute a typical task trajectory is less than the rated continuous output torque of the joint component (including the motor and reducer), with a safety margin. The core verification inequality is:

[0111]

[0112] in, Is joint j at any moment t The required torque is obtained through inverse dynamics calculations. It is the rated continuous output torque of the component selected for joint j. It is the safety factor (usually) To enable rapid estimation during the combination phase, A simplified model based on Newton-Euler recursion can be used for calculation, taking into account the effects of inertial force, gravity, Coriolis force, centrifugal force, and end effector load. Specifically, The calculation formula is as follows:

[0113]

[0114] Where j represents the joint index of the torque to be calculated (1≤j≤n), and n represents the total number of joints in the robot's kinematic chain. , , These are represented as n×1 dimensional vectors representing joint position, velocity, and acceleration, respectively. This represents the acceleration of the i-th link. Let represent the homogeneous transformation matrix from the base coordinate system to the link i-coordinate system. This represents the 6×6 spatial inertia matrix of link i in its center-of-mass coordinate system (containing information on mass, center of mass, and moment of inertia). Represents the transformation matrix For joint j position The partial derivative reflects the influence of the motion of joint j on the motion of link i. Represents the trace operation of a matrix. It is the geometric Jacobian matrix for joint j, which maps the spatial motion velocities (linear and angular velocities) of the end effector to the joint velocities; express transpose, It is a 6×1 dimensional vector, usually represented as ,in, , and Representing forces respectively (This typically includes the weight of the end effector, the gravity of the workpiece being gripped, and the expected operating forces generated during contact with the environment while performing the task) in the x, y, and z axes, while , and It is torque (from the above forces) The components in the x, y, and z axes (generated not through the centroid of the end effector or in tasks requiring the application of torsional torque).

[0115] In one embodiment of this application, in order to quickly verify the joint torque capacity, a peak estimation model based on typical trajectories (e.g., maximum acceleration start, constant speed, maximum deceleration stop) is typically used.

[0116] 2.2) Verification of joint velocity and acceleration capabilities: The actual motion requirements of the joint (e.g., actual motion velocity) and acceleration The value must not exceed the physical limits of its components. The specific implementation of the verification is as follows:

[0117]

[0118] in, and The parameters are directly obtained from the component library for that joint model (e.g., direct drive, with harmonic deceleration). It should be noted that in the above formula for verifying joint velocity and acceleration capabilities, T represents the total motion time of the planned typical robot task trajectory, or a complete motion cycle considered during dynamic verification. Specifically, when verifying joint velocity and acceleration capabilities, the system plans one or more typical test trajectories for the currently assembled candidate robot configurations. These include, for example, point-to-point fastest motion (i.e., the trajectory that takes the shortest time to move from a starting point to a target point while satisfying robot physical constraints (e.g., maximum joint velocity, maximum acceleration / deceleration, torque limits)), uniform circular motion, etc. T is the time required to execute such a complete test trajectory once. During verification, the system calculates the velocity of joint j within the entire time interval [0, T]. and acceleration The curve is calculated, and its absolute value is taken as the maximum value over the entire time period, compared with the maximum allowable rated value for that joint model in the component library. and The comparison is then performed. Therefore, T defines the time window for verification, ensuring that the evaluation is conducted on a complete and representative motion process.

[0119] 2.3) Verification of Structural Natural Frequency and Vibration Characteristics: To avoid harmful resonance during robot operation, the first-order natural frequency, i.e., the fundamental frequency, of its mechanical structure should be significantly higher than the main motion excitation frequency. The verification conditions are:

[0120]

[0121] in, It is the first-order natural frequency of the candidate model. The primary excitation frequency is determined by the task motion planning, and k is the safety factor (usually, k...). 2.5). For common serial robotic arms, the system's fundamental frequency... The equivalent stiffness can be estimated. and equivalent quality Make the following approximation:

[0122]

[0123] equivalent stiffness Typically determined by the weakest link in a series structure, specifically, the system extracts the torsional stiffness of all joints and the bending stiffness of links in the current candidate combination from the component library, which can be approximated as the harmonic average of these stiffness values ​​or directly taken as the minimum value. The estimation can be performed using the lumped mass method, which calculates the mass of all links in the kinematic chain based on their contribution to the end effector position.

[0124] The aforementioned dynamic constraint verification and geometric constraint verification together constitute the complete technical effect of combined constraints. In other words, in the backtracking algorithm, whenever a component is attempted to be assigned to a joint, or a local kinematic chain is constructed, the system calls the simplified dynamic model mentioned above for rapid verification. Only component combinations that simultaneously pass the geometric compatibility check, the aforementioned rapid dynamic feasibility verification, and the workspace pre-screening (i.e., the subsequent steps S1063 to S107) are retained and used to further construct complete candidate URDF models. This ensures that the algorithm's exploration always points to physically assemblable and preliminarily feasible design schemes in terms of motion performance, which is a key step in realizing the automatic generation from an "assemblable" model to a "runnable" model.

[0125] Step S1063: Generate candidate URDF models based on the connection sequences.

[0126] For each feasible component connection sequence found by the backtracking algorithm, the system automatically assembles them into a complete URDF model. This process includes: instantiating a normalized URDF fragment for each component according to the sequence order; and automatically calculating and filling in the coordinate system transformation relationships (i.e., the coordinate transformations in the URDF) between adjacent links and joints based on the component's geometric interface parameters. <origin>(The xyz and rpy attributes of the tag); finally, a complete and correctly formatted URDF file is generated. At this point, the system has generated multiple candidate URDF models, each representing a feasible robot design scheme in terms of geometric connectivity and basic dynamic performance.

[0127] Step S107: Based on the task requirement parameters, evaluate the candidate URDF models using the Pareto front to obtain and output the optimal URDF model.

[0128] After generating multiple candidate URDF models, the core challenge lies in scientifically selecting the optimal solution. Traditional methods either rely on a single metric for ranking or employ subjective weighted scoring, making it difficult to objectively address the inherent conflicts between multiple objectives such as performance, cost, and reliability. The method proposed in this application, which combines evaluation with Pareto fronts, is a key innovation in the scientific decision-making aspect of this scheme. This method first identifies all non-dominated high-quality solutions, i.e., the Pareto front, and then applies explicit preferences to this solution set for the final selection, ensuring that the output is a scientifically optimal solution under the trade-off of multiple objectives, rather than a simple winner for a single objective. As an embodiment of this application, evaluating candidate URDF models based on task requirement parameters and combining Pareto fronts to obtain and output the optimal URDF model can be achieved through steps S1071 to S1075, as detailed below:

[0129] Step S1071: Combine the component lifetime and performance degradation models obtained from the component library to predict the performance degradation trajectory of each candidate URDF model within its target lifetime.

[0130] Step S1071 introduces a reliability-based full lifecycle design concept, representing a significant improvement over existing evaluation methods that only consider performance in a "new state." The system performs the following operations: steps S1071A to S1071C.

[0131] Step S1071A) Obtain the performance degradation model, that is: for each component in the candidate URDF model, read the preset performance degradation model parameters from its metadata. These parameters are usually obtained by fitting accelerated life test data, and the model form can be physical (e.g., simulating bearing wear leading to a linear increase in the coefficient of friction) or data-driven (e.g., using a Weibull distribution to describe the failure rate of electronic components).

[0132] Step S1071B) Drive the model to predict degradation, that is: based on the target lifespan (e.g., 20,000 hours) defined by the task requirement parameters and the predicted typical task load profile, drive the performance degradation model of each component to simulate and calculate the degradation curve of the key performance parameters (e.g., joint efficiency, transmission accuracy, sensor sensitivity) of each component over time throughout the entire lifespan.

[0133] Step S1071C) System-level performance derivation: Based on the performance degradation curves of each component, the evolution trajectory of the task performance (e.g., end-point repeatability accuracy, maximum stable speed), cost, and robustness of the entire candidate URDF model over time is derived through a system-level simulation model. This trajectory serves as the performance degradation trajectory for each candidate URDF model within its target lifetime. This performance degradation trajectory is used to calculate the task performance score, cost score, and robustness score for each candidate model at multiple time points within its target lifetime.

[0134] Step S1072: Based on the performance degradation trajectory of each candidate URDF model during its target lifetime, calculate the task performance score, cost score, and robustness score of each candidate URDF model at multiple time points during its target lifetime, and calculate the initial comprehensive performance index score of each candidate URDF model at the beginning of the target lifetime according to the preset weight coefficients.

[0135] Specifically, based on the evolutionary trajectory of task performance, cost, and robustness, the task performance score, cost score, and robustness score of each candidate URDF model at the beginning of its target lifetime (i.e., the new state) can be extracted. Then, according to preset weighting coefficients ( , , The initial comprehensive performance index score at the beginning of the target lifetime of each candidate URDF model is calculated using the following formula. :

[0136]

[0137] in, A higher score indicates a better model. This indicates the task performance score. Indicates the cost score. Indicates robustness score, , and This represents the weighting coefficient, which is dynamically adjusted based on task requirements to meet... + Automatically upgrade when the task description emphasizes "high precision". The value increases when the keyword "cost control" appears. Weighting, which is strengthened when describing "reliable operation". Percentage. The system generates a large amount of performance data through Monte Carlo simulation and parameter scanning, and finally selects the comprehensive score. The highest-ranking candidate URDF model is output as the optimal URDF model. This technical solution transforms the traditional model evaluation process, which relies on expert experience, into an objective, quantitative decision-making process. It not only solves the subjectivity problem of weight allocation in multi-objective optimization but also significantly improves the efficiency and accuracy of scheme selection through automated evaluation. This ensures that the output robot model achieves an optimal balance in performance, cost, and reliability, providing scientific and reliable decision support for the engineering application of industrial robots. The following sections explain how to calculate the task performance score (Perf), cost score (Cost), and robustness score (Robustness).

[0138] Step S1072D) Calculate the task performance score Perf: The system loads a candidate URDF model in a dynamic simulation environment (e.g., Gazebo, MuJoCo) and drives it to accurately execute a standard test trajectory derived from the task requirement parameters, such as point-to-point motion, continuous path tracking, etc. By collecting actual motion data from the end effector and comparing it with the theoretical trajectory, a series of quantitative performance indicators are calculated, such as trajectory tracking accuracy, repeatability accuracy, cycle time, maximum stable speed, etc. The measured values ​​of each performance indicator are... With task requirements Comparisons were made. For performance metrics where "bigger is better" (e.g., speed), the score was compared to... for (If the actual measured value) Exceeding or being greater than or equal to the task requirement value ,but (Counted as 1); for performance metrics where "smaller is better" (e.g., error), the score ratio is... for (If the actual measured value) Less than or equal to the task requirement value ,but (Counted as 1). Ultimately, Perf is a weighted sum of the scores for each performance metric, weighted according to their importance: The subscript i in the above parameters is the number of the performance index.

[0139] Step S1072E) Calculate the Cost Score: The cost score is calculated based on the lifecycle cost model. First, obtain the purchase cost, rated power, and mean time between failures (MTBF) data for all components constituting the candidate URDF model; then perform multi-dimensional calculations, namely: calculate the annual depreciation cost based on the purchase cost and preset depreciation rules (e.g., 5-year straight-line depreciation); calculate the annual energy consumption cost based on the rated power, preset typical operating cycles, and energy unit price.

[0140] in, It represents the power consumption integral (i.e., annual energy cost). This refers to the joint motor current. This refers to the voltage of the joint motor. This represents the static power consumption of the control system. The annual electricity cost can be converted to an industrial electricity price of 0.8 yuan / kWh. T represents the time spent in a complete, pre-defined typical work cycle. This typical work cycle is a standardized sequence of operations derived from task requirements parameters, representing the robot's daily operating mode (e.g., completing a "grasp-transfer-place" process). Based on the mean time between failures (MTBF) and a pre-defined single maintenance cost, the annual expected maintenance cost is calculated. Combining the annual depreciation cost, annual energy consumption cost, and annual expected maintenance cost, the estimated annual total cost of the candidate model is obtained. The cost score can be set as the industry benchmark annual cost. Compared with the model's total annual cost The ratio, i.e. A ratio greater than 1 indicates that the cost is better than the industry benchmark. For example, if the industry benchmark annual cost of welding robots is 150,000 yuan, and the model's total annual cost is 120,000 yuan, then the cost score Cost = 150,000 / 120,000 = 1.25 (>1 indicates better than the benchmark).

[0141] Step S1072F) calculates the robustness score, which is mainly used to evaluate the performance stability of the model under uncertainty factors. It can be obtained through the following steps S'1072A to S'1072D:

[0142] Step S'1072A: Define a set of parameter disturbance scenarios, including positive and negative deviations in load mass, increases in joint friction coefficient, and control cycle delay.

[0143] These perturbations simulate parameter uncertainties in the real world.

[0144] Step S'1072B: Under each parameter perturbation scenario, drive the candidate URDF model to repeatedly execute its benchmark trajectory.

[0145] It should be noted that the benchmark test trajectory here is a typical motion path that can fully test the robot's various performance characteristics, automatically generated by a trajectory planning algorithm based on parameters such as load capacity, range of motion, and accuracy requirements in the task requirements. This path may include combinations of point-to-point motion, circular interpolation motion, or continuous path tracking motion, etc.

[0146] Step S'1072C: Record the degree of degradation of the model's key performance indicators relative to the unperturbed baseline for each disturbance scenario. For example, record the percentage increase in the RMS error of the end-point positioning accuracy.

[0147] Step S'1072D: Calculate the weighted average of the performance degradation under all perturbation scenarios, invert the average value, and normalize it to obtain the robustness score of the candidate model.

[0148] For example, the average degree of degradation is Robustness can then be calculated as The smaller the degradation, the closer the robustness score is to 1.

[0149] Unlike existing technologies that only evaluate once at "time zero", this method calculates the model's scores at multiple key time points (e.g., initial, middle, and final) during the lifetime based on the estimated lifetime performance degradation trajectory when calculating the above-mentioned Perf, Cost, and Robustness. This results in a set of time-varying score sequences used to evaluate the model's long-term performance retention capability.

[0150] Step S1073: Place all candidate URDF models in a three-dimensional space with task performance score, cost score, and robustness score as coordinate axes, and use a multi-objective optimization algorithm to identify the Pareto front from all candidate URDF models.

[0151] Each candidate URDF model can be represented as a point in three-dimensional space using its three scores: Perf, Cost, and Robustness at the end of the target lifetime (or the average over the entire lifetime). The system invokes a multi-objective optimization algorithm to perform Pareto sorting on all model points. The Pareto front consists of all non-dominated solutions, meaning that for any model on this front, no other model outperforms it in all three metrics (Perf, Cost, and Robustness). This step classifies all candidate solutions; the models on the front represent the best performance-cost-robustness trade-off achievable under the current component library and constraints.

[0152] Step S1074: Based on the preset weight coefficients, recalculate the Pareto front comprehensive performance index score of each candidate URDF model on the Pareto front.

[0153] The system determines a set of weighting coefficients based on the preferences implied in the task requirements description (e.g., "cost-sensitive" or "performance-first"), or user-preset preferences. , , ),satisfy Subsequently, the same formula from step S1072 is used only for models located on the Pareto front. + + Robustness is calculated by determining the Pareto front score for each candidate URDF model. This is equivalent to refining the scoring based on explicit user preferences within the optimal solution set. It should be noted that... The calculation formulas use Perf, Cost, and Robustness with the initial values, but the calculation scope is limited to the model on the pre-Pareto front surface.

[0154] Step S1075: From the Pareto front, select the Pareto front comprehensive performance index score at the end of the target lifetime, compared with the initial comprehensive performance index score. The candidate URDF model with the lowest decay rate is selected as the optimal URDF model.

[0155] At the Pareto front, the system compares the long-term stability of all models. Specifically, based on the evolution trajectories of task performance, cost, and robustness obtained from the above embodiments, the value of each front model at the end of the target lifetime, i.e., the Pareto front comprehensive performance index score, is derived. Subsequently, the initial value of each candidate URDF model from its target lifetime (i.e., the initial comprehensive performance index score) is calculated. The system calculates the decay rate of the final value; ultimately, it selects the candidate URDF model with the lowest decay rate as the optimal URDF model and outputs it. This decision criterion profoundly reflects the method's pursuit of long-term operational reliability: it not only requires the model to perform well initially, but also requires it to have the slowest performance degradation throughout its entire life cycle, thereby ensuring the long-term value of the investment.

[0156] Furthermore, to enhance the transparency and credibility of the automated design system, a structured interpretability report is generated simultaneously when outputting the optimal URDF model file. This interpretability report is not simply a list of components, but rather, through end-to-end decision tracing technology, clearly elucidates the reasons for the selection of each key component in the model (e.g., a specific model of joint motor, reducer, or linkage). The report may include the component's score in the initial matching degree calculation in step S1041. The component's contribution to various parameters is detailed; the verification results (e.g., protocol matching success) of the component with connecting components (e.g., preceding / following joints or links) in step S105 cross-domain compatibility pre-verification; the performance degradation model parameters of the component and their impact on the long-term performance degradation trajectory of the entire model in step S1071 lifetime performance prediction; and the position and contribution of the solution to which the component belongs in step S1072 Pareto front identification and step S1074 final decision, for example, whether its low cost helped the solution reach the cost-optimal Pareto front, or whether its high reliability enabled the solution to win in long-term degradation rate, etc.

[0157] The aforementioned interpretability report white-boxes the automated decision-making process, enabling engineers or users to clearly understand the quantitative basis and multi-objective trade-off logic behind each design choice. This not only helps build user trust in the automated design results but also provides valuable data support and insights for subsequent manual review, scheme fine-tuning, or knowledge accumulation.

[0158] After outputting the optimal URDF model through step S107, to ensure the model's ultimate reliability and continuous optimization potential in practical applications, this application also provides several extended and enhanced scheme verification and post-processing steps, such as model verification and iteration, digital twin deployment and online optimization, etc. These steps together constitute a complete technical closed loop from automated design to engineering verification and even continuous operation and maintenance support. The following details these steps:

[0159] Although the optimal model has been selected through the aforementioned rigorous multi-objective evaluation, it may still have unexposed defects in more complex, high-fidelity simulation environments or actual working conditions. Model verification and iteration introduce an automated iterative closed loop of "design-simulation-feedback-optimization," significantly different from the one-time solution generation and evaluation process in existing technologies. Specifically, model verification and iteration can be achieved through steps S1081 to S1083, detailed below:

[0160] Step S1081: Import the optimal URDF model into the physics simulation engine and perform high-fidelity task scenario simulation.

[0161] The system imports the optimal URDF model into a simulation engine with higher physical fidelity (e.g., based on NVIDIA Isaac Sim, high-precision configured Gazebo, or MuJoCo) to construct a simulation environment that includes accurate contact mechanics, complex environmental interactions, realistic sensor noise models, and complete task scenarios. Within this environment, the model is driven to perform long-duration, highly complex tasks, such as simulating an assembly cycle that operates continuously for 8 hours, or a handling task involving sudden external disturbances (e.g., instantaneous impact loads).

[0162] Step S1082: If the simulation results meet the preset performance acceptance criteria, then output the URDF model as the final model.

[0163] Based on high-fidelity simulation data, the system calculates more comprehensive and stringent performance indicators, such as temperature rise after long-term operation, trajectory recovery capability under disturbance, and energy efficiency, and compares them with preset performance acceptance standards that exceed the initial task requirements. If all indicators meet the standards, the model passes the final verification and can be delivered as the final URDF model for generating control code, manufacturing drawings, or procurement lists.

[0164] Step S1083: If the simulation results do not meet the acceptance criteria, the weight coefficients in the component selection strategy will be automatically adjusted, or the thresholds of some combination constraints will be relaxed, and the model building process starting from component selection will be re-triggered for iterative optimization.

[0165] If high-fidelity simulation reveals unforeseen defects in the model (e.g., joint overheating under sustained load, or inducing harmful vibrations under specific dynamic loads), it indicates that the initial component selection strategy (i.e., matching weights) or combined constraints (e.g., dynamic safety factor) may be overly optimistic or incomplete. In this case, the system does not stall but automatically initiates an iterative optimization process. For example, if excessive motor temperature rise is detected, the system may automatically increase the weight of the load capacity parameter or slightly decrease the safety factor threshold for joint torque verification. Subsequently, the system automatically re-triggers the complete model building process starting from step S104. In the new loop, the system generates new candidate models based on the adjusted strategy and constraints and re-evaluates and selects one. This iterative process can be performed automatically multiple times until a model that can pass high-fidelity simulation verification is found, or the user terminates the process. It empowers the system with the ability to learn and adjust autonomously from failures, enabling it to discover and correct deep-seated engineering problems that the simplified model could not predict in the early stages. Through automated iterative optimization, the final output model's engineering reliability approaches the theoretical limit.

[0166] To extend the value of this method from the design phase to the robot's operation and maintenance phase, this application supports deploying the final validated URDF model into a digital twin system, enabling connection and co-evolution with the physical world. Specifically, digital twin deployment and online optimization can be achieved through the following steps S1091 to S1093:

[0167] Step S1091: Deploy the optimal URDF model into the digital twin system and establish a connection with the physical simulation environment or the actual robot hardware.

[0168] The final validated URDF model is instantiated as a high-fidelity virtual entity in the digital twin system. This system can connect to two levels: 1) a higher-fidelity offline simulation environment for continuous exploration and prediction of theoretical performance limits; and 2) actual robot hardware, which synchronizes the physical robot's state data in real time through sensor networks (e.g., joint encoders, torque sensors, vibration sensors), making the virtual model an accurate mirror of the physical entity.

[0169] Step S1092: Run the optimal URDF model in the digital twin system to perform the target task and collect its performance data in real time under actual or simulated conditions.

[0170] In a digital twin system, a virtual model is driven to perform tasks. If connected to actual hardware, the virtual model moves and updates its state synchronously with the physical robot in real time; if connected to a simulation environment, the virtual model runs in the simulation. The system continuously collects real-time performance data, including trajectory tracking error, actual joint temperature and vibration spectrum, real-time energy consumption, stress and strain of key components, etc. These data reflect the model's true performance under actual or simulated working conditions.

[0171] Step S1093: Based on the deviation between the collected real-time performance data and the task requirement parameters, perform online fine-tuning and optimization of the parameters of one or more components in the optimal URDF model.

[0172] The digital twin system analyzes the collected real-time performance data and compares it with the original task requirements or better performance targets. When a persistent performance deviation is detected (e.g., actual repeatability accuracy slowly deteriorates over time without failure), the system can initiate online parameter fine-tuning. This fine-tuning does not involve replacing components, but rather performing small-scale, adaptive calibration and optimization within the parameter space of the URDF model. For example, it fine-tunes joint friction parameters and damping coefficients to make the dynamic model more closely match the actual dynamic characteristics of the physical robot; optimizes the estimated values ​​of the center of mass position or inertia tensor of links, and performs parameter identification based on actual motion data; calibrates the noise model parameters of virtual sensors to better match the signal-to-noise ratio characteristics of real sensors, and so on. These fine-tuned model parameters update the URDF model in the digital twin in real time, allowing it to continuously evolve and become an increasingly accurate digital copy of the physical entity.

[0173] A continuous optimization loop of "design-deployment-calibration" was created. The static URDF model, initially generated automatically by task-driven mechanisms, evolved into a "living" model capable of co-evolving with the physical entity and continuously self-calibrating. This not only greatly improved the predictive reliability of the simulation model for the actual system, but also provided a dynamic and accurate model foundation for model-based predictive maintenance, real-time monitoring of performance degradation, lifetime prediction, and adaptive optimization of control parameters.

[0174] From the above appendix Figure 1 As can be seen from the example of the robot URDF model construction method, on the one hand, since the technical solution of this application does not directly parse the natural language task description after receiving it, but first performs clarification optimization including identifying ambiguous and conflicting requirements, generating interactive clarification questions based on the knowledge base, and receiving user corrections, this process transforms a one-time, potentially incomplete input into a human-machine collaborative iterative confirmation process. This process can proactively discover and eliminate ambiguities and contradictions in the original requirements, generating a clear and consistent optimized task description, thereby providing a solid and reliable requirement input for all subsequent automation steps, reducing the risk of the entire design process failing due to misunderstandings of requirements from the source. On the other hand, after component selection and before traditional geometric and dynamic combination, cross-domain compatibility pre-verification is introduced to specifically verify the compatibility between candidate components at the soft interface level, such as control protocols, communication buses, and software drivers, and eliminate conflicting combinations, thus expanding the compatibility check from a single mechanical and physical domain to a broader scope. Extending to multiple domains such as control, communication, and software, this ensures that the automatically generated candidate URDF models are not only mechanically assemblable and kinematically feasible, but also possess a solid integration foundation at the electrical and software levels. This avoids major rework issues caused by discovering software incompatibilities late in the design process, thus improving the first-time success rate of the design results. Thirdly, when evaluating multiple candidate URDF models, a strategy combining Pareto fronts is adopted. This strategy does not simply rank the models, but first places all models in a multi-dimensional objective space, identifies the Pareto front representing the optimal trade-off, and then selects from it. This systematically presents all non-dominated optimal solution sets, and makes the final choice based on clear decision rules within this scientifically defined optimal solution set. This ensures that the final output optimal model is the result of rigorous multi-objective optimization analysis, achieving a good balance among multiple key indicators. The decision-making process is more transparent and reasonable, avoiding the decision-making trap of falling into local optima or sacrificing one aspect for another. In summary, the technical solution of this application improves the reliability and scientific rigor of the entire process from requirement input and design error prevention to solution decision-making by introducing task clarification optimization, cross-domain compatibility pre-verification, and Pareto front-based evaluation.

[0175] Please see Figure 2 As shown, in one embodiment, a robot URDF model building device is provided. This device may include a receiving module 201, an optimization module 202, an analysis module 203, a selection module 204, a verification module 205, a generation module 206, and an evaluation module 207, as detailed below:

[0176] The receiving module 201 is used to receive a task description input by the user, wherein the task description is natural language text;

[0177] The optimization module 202 is used to clarify and optimize the task description: identify ambiguous or conflicting requirements in the task description, generate clarification questions for ambiguous or conflicting requirements based on a preset robot domain knowledge base and provide feedback to the user, and receive supplementary or corrective input from the user on the clarification questions to generate an optimized task description.

[0178] Analysis module 203 is used to perform semantic analysis on the optimized task description and extract task requirement parameters, wherein the task requirement parameters include at least one of load capacity, movement range, and accuracy requirements.

[0179] The selection module 204 is used to select multiple candidate components from the robot component library based on task requirement parameters. The robot component library includes joints, links, actuators and sensor components.

[0180] The verification module 205 is used to perform cross-domain compatibility pre-verification on the selected candidate components before combining them: verifying the compatibility between any two candidate components to be connected at the level of control protocol, communication bus type and software driver interface, and eliminating component combinations with cross-domain compatibility conflicts.

[0181] The generation module 206 is used to combine the candidate components that have been pre-verified for cross-domain compatibility according to the combination constraints between components to generate multiple candidate URDF models, wherein the combination constraints include geometric constraints and dynamic constraints;

[0182] Evaluation module 207 is used to evaluate candidate URDF models based on task requirement parameters and Pareto frontier, and to obtain and output the optimal URDF model.

[0183] From the above appendix Figure 2 As can be seen from the example of the robot URDF model building device, on the one hand, since the technical solution of this application does not directly parse the natural language task description after receiving it, but first performs clarification optimization including identifying ambiguous and conflicting requirements, generating interactive clarification questions based on the knowledge base, and receiving user corrections, this process transforms a one-time, potentially incomplete input into a human-machine collaborative iterative confirmation process. This proactively discovers and eliminates ambiguities and contradictions in the original requirements, generating a clear and consistent optimized task description. This provides a solid and reliable requirement input for all subsequent automation steps, reducing the risk of the entire design process failing due to misunderstandings of requirements. On the other hand, after component selection and before traditional geometric and dynamic combinations, cross-domain compatibility pre-verification is introduced. This specifically verifies the compatibility between candidate components at the soft interface level, such as control protocols, communication buses, and software drivers, and eliminates conflicting combinations. This expands the compatibility check from a single mechanical-physical domain to a broader scope. Extending to multiple domains such as control, communication, and software, this ensures that the automatically generated candidate URDF models are not only mechanically assemblable and kinematically feasible, but also possess a solid integration foundation at the electrical and software levels. This avoids major rework issues caused by discovering software incompatibilities late in the design process, thus improving the first-time success rate of the design results. Thirdly, when evaluating multiple candidate URDF models, a strategy combining Pareto fronts is adopted. This strategy does not simply rank the models, but first places all models in a multi-dimensional objective space, identifies the Pareto front representing the optimal trade-off, and then selects from it. This systematically presents all non-dominated optimal solution sets, and makes the final choice based on clear decision rules within this scientifically defined optimal solution set. This ensures that the final output optimal model is the result of rigorous multi-objective optimization analysis, achieving a good balance among multiple key indicators. The decision-making process is more transparent and reasonable, avoiding the decision-making trap of falling into local optima or sacrificing one aspect for another. In summary, the technical solution of this application improves the reliability and scientific rigor of the entire process from requirement input and design error prevention to solution decision-making by introducing task clarification optimization, cross-domain compatibility pre-verification, and Pareto front-based evaluation.

[0184] Optionally, the above Figure 2 Example analysis module 203 may include word segmentation units, extraction units, and mapping units, wherein:

[0185] The word segmentation unit is used to segment and tag the optimized task description.

[0186] The extraction unit is used to extract key entities and relationships to form a task requirement graph. Key entities include robot action objects and environmental conditions, and relationships include action types and performance indicators.

[0187] The mapping unit is used to map the task requirement graph to the task requirement parameters.

[0188] Optionally, the above Figure 2 The selection module 204 in the example may include a calculation unit and a selection unit, wherein:

[0189] The calculation unit is used to calculate the matching degree between each component and the task requirement parameters. The matching degree calculation formula is as follows:

[0190]

[0191] in, This represents the matching score of component i, which is positively correlated with task requirements. n represents the number of task requirement parameters. This represents the weight of the task requirement parameter j, satisfying... , This represents the numerical or categorical data of the task requirement parameter j. This represents the characteristic value of component i on task requirement parameter j, which can be numerical or categorical data. This represents the similarity function used to calculate... and The similarity between them;

[0192] The selection unit is used to select components with a matching score higher than a preset threshold as candidate components.

[0193] Optionally, the above Figure 2 Example generation module 206 may include model building unit, sequence generation unit, and model generation unit, wherein:

[0194] The model building unit is used to establish a model for constraint satisfaction problems. Variables represent component types, domains represent specific components, and constraints include geometric and dynamic constraints.

[0195] The sequence generation unit is used to solve constraint satisfaction problems using a backtracking algorithm, generating a sequence of component connections that satisfy both geometric and dynamic constraints.

[0196] The model generation unit is used to generate candidate URDF models based on the component connection sequence that satisfies geometric and dynamic constraints.

[0197] Optionally, in the cross-domain compatibility pre-verification, verifying control protocol compatibility includes: checking whether the motion control protocol versions claimed to be supported by the two components to be connected are consistent or whether there are known interoperability mapping rules; verifying communication bus type compatibility includes: checking whether the physical communication interface types and baud rate configuration ranges of the two components are compatible; verifying software driver interface compatibility includes: checking whether the device driver files of the two components are for the same robot middleware framework and version.

[0198] Optionally, the above Figure 2 The example evaluation module 207 may include an indicator score calculation unit, an identification unit, a recalculation unit, and an optimization unit, wherein:

[0199] The indicator score calculation unit is used to combine the component lifetime and performance degradation models obtained from the component library to predict the performance degradation trajectory of each candidate URDF model within its target lifetime and calculate the comprehensive performance indicator score of each candidate model.

[0200] The identification unit is used to place all candidate models in a three-dimensional space with task performance score, cost score, and robustness score as coordinate axes, and a multi-objective optimization algorithm is used to identify the Pareto front from all candidate models.

[0201] The recalculation unit is used to recalculate the overall performance index score of each model on the Pareto front based on preset weight coefficients.

[0202] The optimization unit is used to select the candidate model with the lowest overall performance index score decay rate at the end of the target lifetime from the Pareto front as the optimal URDF model.

[0203] Optionally, the indicator score calculation unit in the above example may include a reading unit, a driving unit, and a deduction unit, wherein:

[0204] The read unit is used to read the performance degradation model parameters based on accelerated life test fitting from the metadata of each component in the candidate URDF model;

[0205] The drive unit is used to drive the performance degradation model based on the target lifespan and a predefined task load profile, and to simulate and calculate the decay curves of key performance parameters of each component over time.

[0206] The derivation unit is used to deduce the trajectory of the overall performance index score of the entire candidate URDF model decaying over time based on the performance decay curves of each component and through the system-level model.

[0207] In one embodiment, an electronic device is provided, the internal structure of which can be shown as follows: Figure 3 As shown, the electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computational and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a robot URDF model construction method.

[0208] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the following steps:

[0209] Receive a task description input from the user, where the task description is natural language text;

[0210] The task description is clarified and optimized as follows: Identify ambiguous or conflicting requirements in the task description, generate clarification questions for the ambiguous or conflicting requirements based on a preset robotics domain knowledge base, and provide feedback to the user. The user is also given supplementary or corrective input on the clarification questions to generate an optimized task description.

[0211] Semantic analysis is performed on the optimized task description to extract task requirement parameters, which include at least one of load capacity, movement range, and accuracy requirements.

[0212] Based on task requirement parameters, select multiple candidate components from the robot component library;

[0213] Before combining the selected candidate components, perform the following cross-domain compatibility pre-verification on the selected candidate components: verify the compatibility between any two candidate components to be connected at the level of control protocol, communication bus type and software driver interface, and eliminate component combinations with cross-domain compatibility conflicts.

[0214] Based on the composition constraints between components, the candidate components that have been pre-validated for cross-domain compatibility are combined to generate multiple candidate URDF models. The composition constraints include geometric constraints and dynamic constraints.

[0215] Based on the task requirement parameters, the candidate URDF models are evaluated using the Pareto front to obtain and output the optimal URDF model.

[0216] The aforementioned computer program significantly lowers the barrier to robot modeling and improves the efficiency of matching models with tasks.

[0217] In one embodiment, a storage medium is provided that stores a computer program, which, when executed by a processor, performs the following steps:

[0218] Receive a task description input from the user, where the task description is natural language text;

[0219] The task description is clarified and optimized as follows: Identify ambiguous or conflicting requirements in the task description, generate clarification questions for the ambiguous or conflicting requirements based on a preset robotics domain knowledge base, and provide feedback to the user. The user is also given supplementary or corrective input on the clarification questions to generate an optimized task description.

[0220] Semantic analysis is performed on the optimized task description to extract task requirement parameters, which include at least one of load capacity, movement range, and accuracy requirements.

[0221] Based on task requirement parameters, select multiple candidate components from the robot component library;

[0222] Before combining the selected candidate components, perform the following cross-domain compatibility pre-verification on the selected candidate components: verify the compatibility between any two candidate components to be connected at the level of control protocol, communication bus type and software driver interface, and eliminate component combinations with cross-domain compatibility conflicts.

[0223] Based on the composition constraints between components, the candidate components that have been pre-validated for cross-domain compatibility are combined to generate multiple candidate URDF models. The composition constraints include geometric constraints and dynamic constraints.

[0224] Based on the task requirement parameters, the candidate URDF models are evaluated using the Pareto front to obtain and output the optimal URDF model.

[0225] The aforementioned computer program significantly lowers the barrier to robot modeling and improves the efficiency of matching models with tasks.

[0226] The steps described above, implemented by the computer program when executed by the processor, significantly lower the barrier to robot modeling and improve the efficiency of matching models with tasks.

[0227] It should be noted that the functions or steps that the storage medium or electronic device can achieve are described in the relevant descriptions of the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0228] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0229] 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 used as 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.

[0230] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention 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. Such 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 the present invention, and should all be included within the protection scope of the present invention.< / origin>

Claims

1. A method for constructing a robot URDF model, characterized in that, The method includes: Receive a task description input by the user, wherein the task description is natural language text; The task description is clarified and optimized by: identifying ambiguous or conflicting requirements in the task description, generating clarification questions for the ambiguous or conflicting requirements based on a preset robotics domain knowledge base and feeding them back to the user, and receiving supplementary or corrective input from the user on the clarification questions to generate an optimized task description. Semantic analysis is performed on the optimized task description to extract task requirement parameters, which include at least one of load capacity, mobility range, and accuracy requirements. Based on the task requirement parameters, select multiple candidate components from the robot component library; Before combining the selected candidate components, perform cross-domain compatibility pre-verification on the selected candidate components: verify the compatibility between any two candidate components to be connected at the level of control protocol, communication bus type and software driver interface, and eliminate component combinations with cross-domain compatibility conflicts. Based on the composition constraints between components, the candidate components that have undergone cross-domain compatibility pre-validation are combined to generate multiple candidate URDF models. The composition constraints include geometric constraints and dynamic constraints. The process of combining the candidate components based on the composition constraints between components includes: establishing a constraint satisfaction problem model, where variables represent component types, domains represent specific components, and constraints include geometric constraints and dynamic constraints; solving the constraint satisfaction problem using a backtracking algorithm to generate a component connection sequence that satisfies the geometric and dynamic constraints; and generating candidate URDF models based on the component connection sequence. Based on task requirement parameters, the candidate URDF models are evaluated using Pareto fronts to obtain and output the optimal URDF model. This evaluation includes: using component lifetime and performance degradation models obtained from a component library to predict the performance degradation trajectory of each candidate URDF model within its target lifetime; calculating the task performance score, cost score, and robustness score of each candidate URDF model at multiple time points within its target lifetime based on the performance degradation trajectory; and calculating the target performance score of each candidate URDF model according to preset weighting coefficients. The initial comprehensive performance index score at the beginning of the lifespan is calculated; all candidate URDF models are placed in a three-dimensional space with task performance score, cost score, and robustness score as coordinate axes, and a multi-objective optimization algorithm is used to identify the Pareto front from all candidate URDF models; based on preset weight coefficients, the Pareto front comprehensive performance index score of each candidate URDF model on the Pareto front is recalculated; from the Pareto front, the candidate URDF model with the lowest decay rate of the Pareto front comprehensive performance index score at the end of the target lifespan compared to the initial comprehensive performance index score is selected as the optimal URDF model.

2. The robot URDF model construction method according to claim 1, characterized in that, The step of performing semantic analysis on the optimized task description and extracting task requirement parameters includes: The optimized task description is then segmented and tagged with parts of speech. Extract key entities and relationships to form a task requirement graph. The key entities include robot action objects and environmental conditions, and the relationships include action types and performance indicators. Map the task requirement graph to the task requirement parameters.

3. The robot URDF model construction method according to claim 1, characterized in that, The selection of multiple candidate components from the robot component library based on task requirement parameters includes: Calculate the matching degree between each component and the task requirement parameters. The formula for calculating the matching degree is as follows: in, This represents the matching score of component i, which is positively correlated with task requirements, and n represents the number of task requirement parameters. This represents the weight of the task requirement parameter i, satisfying... , This represents the numerical or categorical data of the task requirement parameter j. This represents the characteristic value of component i on the task requirement parameter j. This represents the similarity function used to calculate... and The similarity between them; Components with a matching score higher than a preset threshold are selected as candidate components.

4. The robot URDF model construction method according to claim 1, characterized in that, In the cross-domain compatibility pre-verification, verifying control protocol compatibility includes checking whether the motion control protocol versions claimed to be supported by the two components to be connected are consistent or whether there are known interoperability mapping rules. Verifying communication bus type compatibility includes checking whether the physical communication interface types and baud rate configuration ranges of the two candidate components are compatible. Verifying software driver interface compatibility includes checking whether the device driver files of two candidate components are for the same robot middleware framework and version.

5. The robot URDF model construction method according to claim 1, characterized in that, The method of combining component lifetime and performance degradation models obtained from the component library to predict the performance degradation trajectory of each candidate URDF model within its target lifetime includes: For each component in the candidate URDF model, read the performance degradation model parameters based on accelerated life test fitting from its metadata; Based on the target lifespan and the predefined task load profile, the performance degradation model is driven to simulate and calculate the decay curves of key performance parameters of each component over time. Based on the performance degradation curves of each component, the evolution trajectory of the task performance, cost, and robustness of the entire candidate URDF model over time is deduced through a system-level model, serving as the performance degradation trajectory of each candidate URDF model within its target lifetime.

6. A robot URDF model building device, characterized in that, The device includes: The receiving module is used to receive a task description input by the user, wherein the task description is natural language text; The optimization module is used to clarify and optimize the task description: identify ambiguous or conflicting requirements in the task description, generate clarification questions for the ambiguous or conflicting requirements based on a preset robot domain knowledge base and feed them back to the user, and receive supplementary or corrective input from the user on the clarification questions to generate an optimized task description. The analysis module is used to perform semantic analysis on the optimized task description and extract task requirement parameters, which include at least one of load capacity, mobility range, and accuracy requirements. The selection module is used to select multiple candidate components from the robot component library based on the task requirement parameters. The robot component library includes joints, links, actuators, and sensor components. The verification module is used to perform cross-domain compatibility pre-verification on the selected candidate components before combining them: verifying the compatibility between any two candidate components to be connected at the level of control protocol, communication bus type and software driver interface, and eliminating component combinations with cross-domain compatibility conflicts. The generation module is used to combine candidate components that have undergone cross-domain compatibility pre-validation based on the combination constraints between components to generate multiple candidate URDF models. The combination constraints include geometric constraints and dynamic constraints. The process of combining candidate components that have undergone cross-domain compatibility pre-validation based on the combination constraints between components includes: establishing a constraint satisfaction problem model, where variables in the constraint satisfaction problem model represent component types, domains represent specific components, and constraints include geometric constraints and dynamic constraints; solving the constraint satisfaction problem using a backtracking algorithm to generate a component connection sequence that satisfies the geometric constraints and dynamic constraints; and generating candidate URDF models based on the component connection sequence. The evaluation module is used to evaluate the candidate URDF models based on task requirement parameters and incorporating Pareto fronts, obtaining and outputting the optimal URDF model. The evaluation based on task requirement parameters and incorporating Pareto fronts includes: using component lifetime and performance degradation models obtained from a component library to predict the performance degradation trajectory of each candidate URDF model within its target lifetime; calculating the task performance score, cost score, and robustness score of each candidate URDF model at multiple time points within its target lifetime based on the performance degradation trajectory; and calculating the optimal URDF model for each candidate URDF model according to preset weighting coefficients. The initial comprehensive performance index score at the beginning of the target lifetime is determined. All candidate URDF models are placed in a three-dimensional space with task performance score, cost score, and robustness score as coordinate axes. Using a multi-objective optimization algorithm, the Pareto front is identified from all candidate URDF models. Based on preset weight coefficients, the Pareto front comprehensive performance index score of each candidate URDF model on the Pareto front is recalculated. From the Pareto front, the candidate URDF model with the lowest decay rate of the Pareto front comprehensive performance index score at the end of the target lifetime compared to the initial comprehensive performance index score is selected as the optimal URDF model.

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 steps of the method 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 a processor, it implements the steps of the method as described in any one of claims 1 to 5.

Images