Geometric constraint engine and implementation method for supporting kinematic pair constraint in geometric constraint engine
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-07
- Publication Date
- 2026-03-31
Smart Images
Figure CN121765853A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of computer technology, and more specifically, relates to a geometric constraint engine and an implementation method for supporting kinematic pair constraints in the geometric constraint engine. Background Technology
[0002] In the fields of computer-aided design (CAD) and virtual simulation of mechanical systems, geometric constraint engines are the core tools for simulating motion between components, while kinematic pairs (such as revolute pairs and sliding pairs) are key to defining the relative motion of components, and their functions need to be realized through composite basic constraints.
[0003] However, existing geometric constraint engines have significant drawbacks: they only provide low-level interfaces for basic constraints such as coincidence and parallelism, and do not support direct definition of kinematic pairs. Users need to manually sort out the constraint logic of kinematic pairs and create basic constraints one by one, which is cumbersome. The mapping between kinematic pairs and basic constraints requires professional knowledge. Ordinary users are prone to simulation anomalies due to misunderstandings or incorrect parameter configurations (such as deviations in direction vectors or origin coordinates). Furthermore, error troubleshooting requires verification one by one, which is extremely inefficient. At the same time, the engine lacks high-level encapsulation interfaces for kinematic pairs. Application layer development needs to directly call the low-level interfaces, resulting in a lot of redundant code and a long development cycle, making it difficult to meet the needs of efficient and accurate motion simulation. Summary of the Invention
[0004] The purpose of this application is to provide a geometric constraint engine and a method for supporting kinematic pair constraints in the geometric constraint engine. It aims to solve the technical problem that existing geometric constraint engines only provide basic constraint low-level interfaces and do not support direct definition of kinematic pairs when supporting kinematic pair constraints. Users manually combine constraints, which is prone to errors due to reliance on professional knowledge, and it is difficult to meet the requirements of efficient and accurate motion simulation.
[0005] To achieve the above objectives, according to the first aspect of this application, a method for supporting kinematic pair constraints in a geometric constraint engine is provided, applied to a geometric constraint engine comprising an application layer, an engine layer, and a kernel layer, the method comprising: The application layer provides an interactive interface to receive user input regarding the target kinematic pair type, component information involved in the motion, and kinematic pair parameters. The engine layer determines the activation information of the kinematic pair constraint based on the local coordinate system of the pre-generated connector element. The activation information includes the activation position determined by the origin coordinates of the connector element and the activation direction determined by the z-axis direction vector of the connector element. The kernel layer receives the target kinematic pair type, the component information, and the kinematic pair parameters transmitted by the application layer, as well as the activation information transmitted by the engine layer; and calls a pre-built mapping library of kinematic pair types and basic constraint combinations to automatically generate the corresponding basic constraint set based on the target kinematic pair type and the activation information. The kernel layer reads the kinematic pair parameters, sets the values of the basic dimensional constraints in the basic constraint set, and calls the constraint solver to solve the basic constraint set, outputting the simulation results of the kinematic pair constraints.
[0006] According to a second aspect of this application, a geometric constraint engine is provided, comprising: The application layer provides an interactive interface to receive user input regarding the target kinematic pair type, component information involved in the motion, and kinematic pair parameters. The engine layer, connected to the application layer, is used to determine the activation information of the kinematic pair constraint based on the local coordinate system of the pre-generated connector element. The activation information includes the activation position determined by the origin coordinates of the connector element and the activation direction determined by the z-axis direction vector of the connector element. The kernel layer, connecting the application layer and the engine layer, is used to receive the target kinematic pair type, the component information, and the kinematic pair parameters transmitted by the application layer, as well as the activation information transmitted by the engine layer; and to call a pre-built mapping library of kinematic pair types and basic constraint combinations to automatically generate the corresponding basic constraint set according to the target kinematic pair type and the activation information. The kernel layer is also used to read the kinematic pair parameters, set the values of the basic dimensional constraints in the basic constraint set, and call the constraint solver to solve the basic constraint set, and output the simulation results of the kinematic pair constraints.
[0007] The beneficial effects of the embodiments in this application compared with the prior art are: This application provides a method for supporting kinematic pair constraints in a geometric constraint engine. The geometric constraint engine includes an application layer, an engine layer, and a kernel layer. The method receives user input regarding the target kinematic pair type, participating component information, and kinematic pair parameters through an interactive interface provided by the application layer. The engine layer determines the effectiveness information of the kinematic pair constraints based on a pre-generated local coordinate system of the connector elements. The kernel layer receives the target kinematic pair type, component information, and kinematic pair parameters from the application layer, as well as the effectiveness information from the engine layer. It then calls a pre-built mapping library of kinematic pair types and basic constraint combinations to automatically generate a corresponding set of basic constraints based on the target kinematic pair type and effectiveness information. The kernel layer reads the kinematic pair parameters, sets the values of the basic dimensional constraints in the basic constraint set, and calls a constraint solver to solve the basic constraint set, outputting the simulation results of the kinematic pair constraints.
[0008] This method directly receives the target kinematic pair type input by the user at the application layer, and the kernel layer calls a pre-built mapping library to automatically match and generate the corresponding basic constraint set based on the kinematic pair type. This eliminates the need for users to manually sort and create the basic constraint set, simplifying the operation process. The engine layer automatically determines the activation information based on pre-generated connector elements, and the kernel layer accurately generates the corresponding basic constraint set based on this activation information, reducing the user's dependence on the underlying constraint logic and lowering the risk of parameter configuration errors. The application layer provides a dedicated interaction interface for kinematic pairs, encapsulating the details of the underlying constraints, and the kernel layer automatically completes the constraint generation and solving, reducing redundant code in the application layer development and improving development efficiency. Attached Figure Description
[0009] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0010] Figure 1 This is a flowchart illustrating an implementation method for supporting kinematic pair constraints in a geometric constraint engine, as provided in an embodiment of this application. Figure 2 This is a flowchart illustrating an optional implementation method for supporting kinematic pair constraints in a geometric constraint engine, provided in an embodiment of this application. Figure 3 This is a schematic diagram of an optional connector element generation based on the circular cross-section of a component, provided in an embodiment of this application; Figure 4aThis is a schematic diagram illustrating the constraint effect of an optional sliding pair based on different component circular cross-section positioning connector elements provided in this application embodiment; Figure 4b This is a schematic diagram illustrating the constraint effect of an optional sliding pair based on different component circular cross-section positioning connector elements provided in this application embodiment; Figure 4c This is a schematic diagram illustrating the constraint effect of an optional sliding pair based on different component circular cross-section positioning connector elements provided in this application embodiment; Figure 5 This is a schematic diagram of an optional basic constraint for mapping sliding pairs based on connector elements, provided in an embodiment of this application. Figure 6 This is a schematic diagram of the architecture of a geometric constraint engine provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0011] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0012] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.
[0013] It should also be understood that, in the description of this application, unless otherwise stated, the " / " used in the specification and appended claims indicates that the related objects are in an "or" relationship. For example, A / B can mean A or B. The "and / or" in this application is merely a description of the relationship between the related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.
[0014] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, but are only used for distinguishing descriptions, and the terms "first" and "second" do not necessarily imply that they are different, nor should they be construed as indicating or implying relative importance.
[0015] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."
[0016] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0017] First, some terms used in the embodiments of this application will be explained to facilitate understanding by those skilled in the art.
[0018] A geometric constraint engine is a computational module used in fields such as computer-aided design (CAD) and virtual simulation of mechanical systems to handle geometric constraint relationships between components.
[0019] Kinematic pair constraints are standardized constraint forms used in virtual simulation and computer-aided design of mechanical systems to define the relative motion relationship between two or more components.
[0020] Connector elements are feature positioning components in the geometry constraint engine that are associated with mechanical components. They provide precise application references for kinematic pair constraints. By establishing the association between the component and the kinematic pair constraint, the constraint is made to act accurately on the specific geometric features of the component, ensuring that the kinematic pair constraint takes effect as expected in the simulation.
[0021] The above is a brief introduction to the terms used in the embodiments of this application, and will not be repeated below.
[0022] This application provides an example of an implementation method for supporting kinematic pair constraints in a geometric constraint engine. Please refer to [link / reference]. Figure 1 As shown, Figure 1 The diagram illustrates a schematic flowchart of an implementation method for supporting kinematic pair constraints in a geometric constraint engine, as provided in this application. This is illustrative and not limiting; the method can be applied to a geometric constraint engine, which includes an application layer, an engine layer, and a kernel layer. The method includes: S101 receives the target kinematic pair type, component information involved in the motion, and kinematic pair parameters from the user through the interaction interface provided by the application layer.
[0023] S102, the engine layer determines the activation information of the kinematic pair constraint based on the local coordinate system of the pre-generated connector element. The activation information includes the activation position determined by the origin coordinate of the connector element and the activation direction determined by the z-axis direction vector of the connector element.
[0024] S103 receives the target kinematic pair type, component information, and kinematic pair parameters from the application layer through the kernel layer, as well as the activation information from the engine layer, and calls the pre-built mapping library of kinematic pair type and basic constraint combination to automatically generate the corresponding basic constraint set based on the target kinematic pair type and activation information.
[0025] S104 reads the kinematic pair parameters through the kernel layer, sets the values of the basic dimensional constraints in the basic constraint set, and calls the constraint solver to solve the basic constraint set, outputting the simulation results of the kinematic pair constraints.
[0026] The following section provides a detailed description of a method for supporting kinematic pair constraints in a geometric constraint engine, based on a specific application scenario. This embodiment uses the simulation of sliding pair constraints in a mechanical system as an example to illustrate the collaborative working process of the application layer, engine layer, and kernel layer. The three-layer architecture of the geometric constraint engine respectively undertakes user interaction, positioning calculation, and constraint solving functions, ultimately achieving accurate simulation of sliding motion between components.
[0027] As an optional implementation, the application layer of the geometric constraint engine provides a visual interactive interface and standardized functional interfaces for receiving configuration information from users regarding kinematic pair constraints. Specifically, users complete the following operations through the application layer's interactive interface: selecting the target kinematic pair type, specifying the component information involved in the motion, and inputting the kinematic pair parameters.
[0028] In some embodiments, the user selects "sliding joint" from the list of kinematic pair types in the interactive interface. This selection instruction is passed to the application layer through the type selection sub-interface of the kinematic pair dedicated function interface, which clarifies that the kinematic pair type in this simulation is a sliding joint.
[0029] In some embodiments, the user selects two components involved in the motion from the 3D model library, namely the guide rail component and the slider component, and specifies them as associated components of the sliding pair constraint through the interface. The application layer records the unique identifier of the component (such as ID101 and ID102) and the corresponding rigid body model information (including the component's global coordinate system parameters, geometric contour data, etc.).
[0030] In some embodiments, the user sets the motion parameters of the sliding pair through the parameter configuration sub-interface of the application layer, including the sliding distance range (e.g., 0-100mm) and the current sliding distance (e.g., 50mm), so as to use the above motion parameters for the numerical configuration of subsequent basic constraints.
[0031] In some embodiments, after receiving the target kinematic pair type selected by the user through the interactive interface, the information of the components participating in the motion, and the input kinematic pair parameters, the application layer packages the target kinematic pair type (sliding pair), component information (ID101, ID102, and rigid body data), and kinematic pair parameters (sliding distance, etc.) into structured data and passes them to the engine layer and kernel layer respectively. Specifically, the rigid body data of the components is passed to the engine layer for associating with pre-generated connector elements; the target kinematic pair type and kinematic pair parameters are passed to the kernel layer for the generation and solving of constraint sets.
[0032] In some embodiments, the engine layer uses pre-generated connector elements to locate the effective position and direction of the kinematic pair constraint. The connector element is a positioning component created by the engine layer for each component based on previously selected component feature elements, such as the axis of the guide rail component and the end face of the shaft hole of the slider component. It is understood that, in this embodiment, before the user configures the sliding pair constraint, the engine layer has already extracted the geometric properties (direction vector of the guide rail axis, coordinates of the shaft hole center, etc.) of the component feature elements based on the user's selection of the component feature elements (e.g., the user selects the axis of the guide rail component as the sliding reference and the center of the shaft hole of the slider component as the sliding starting point), and generated connector elements that remain relatively stationary with the rigid body of the component. Each connector element has an independent local coordinate system, the origin of which corresponds to the key position of the feature element (e.g., the center of the shaft hole), and the z-axis corresponds to the reference direction of the component feature element (e.g., the direction of the guide rail axis).
[0033] After the application layer passes the component information (ID101, ID102) to the engine layer, the engine layer indexes the corresponding connector element through the component's unique identifier. The connector element corresponding to the guide rail component (ID101) is denoted as C1, and the connector element corresponding to the slider component (ID102) is denoted as C2. The engine layer reads the local coordinate system parameters of C1 and C2: determined by the origin coordinates (x1, y1, z1) of C1 and the origin coordinates (x2, y2, z2) of C2, corresponding to the points of action of the sliding joint constraint on the guide rail and slider, respectively; and determined by the z-axis direction vectors (a1, b1, c1) of C1 and (a2, b2, c2) of C2, corresponding to the reference direction of the sliding motion (i.e., the direction of the guide rail axis).
[0034] In some embodiments, the engine layer associates the aforementioned activation information (activation location, activation direction) with the unique identifiers of the components (ID101, ID102), forming a correspondence between component-connector-activation information, ensuring that the kernel layer can accurately identify the component and action parameters corresponding to each constraint. Subsequently, the engine layer transmits the associated activation information to the kernel layer, providing a location basis for the generation of the basic constraint set.
[0035] In some embodiments, the kernel layer receives the target kinematic pair type (sliding pair), component information, and kinematic pair parameters from the application layer, and simultaneously receives the activation information (origin coordinates and z-axis direction vectors of C1 and C2) from the engine layer. Based on a pre-built mapping library, it generates the corresponding set of basic constraints. The kernel layer's mapping library predefines the basic constraint combination rules for sliding pairs; that is, sliding pairs must be implemented through a combination of z-axis coincidence constraints, origin-z-axis distance constraints, and x-axis parallel constraints. Specifically, z-axis coincidence constraints ensure consistent sliding directions, origin-z-axis distance constraints limit the sliding distance, and x-axis parallel constraints restrict rotation around the z-axis. Based on the activation information from the engine layer, the kernel layer transforms the abstract constraint rules into specific parameterized constraints. In some embodiments, the z-axis coincidence constraint is based on the z-axis direction vectors (a1, b1, c1) of C1 and (a2, b2, c2) of C2, generating a constraint that the z-axis of C1 and C2 coincide, ensuring that the slider slides along the guide rail axis. The origin distance constraint along the z-axis is based on the origins (x1, y1, z1) of C1 and (x2, y2, z2) of C2, combined with the z-axis direction vector of C1, generating a constraint that the distance between the two origins in the z-axis direction is equal to the sliding distance. The x-axis parallel constraint is based on the x-axis direction vectors of C1 and C2, generating a constraint that the x-axis of C1 is parallel to the x-axis of C2, preventing the slider from rotating around the guide rail axis. Through the above embodiments, the kernel layer automatically generates the basic constraint set corresponding to the sliding joint based on the target kinematic pair type and effectiveness information, without requiring the user to manually configure the parameters of each constraint.
[0036] In some embodiments, after generating the basic constraint set, the kernel layer combines the kinematic pair parameters passed from the application layer to complete the constraint numerical configuration, and then calls the constraint solver to solve the problem, finally outputting the simulation results. For example, the kernel layer reads the kinematic pair parameters (current sliding distance 50mm) passed from the application layer, assigns this value to the origin-z-axis distance constraint, that is, sets the distance between the origins of C1 and C2 in the z-axis direction to 50mm, and keeps other constraints (such as z-axis coincidence and x-axis parallelism) with default geometric relationship constraints (such as the angle between direction vectors being 0). The kernel layer calls the constraint solver (such as a numerical iteration-based solution algorithm) to transform the basic constraint set into a system of equations for solution. During the solution process, the solver uses the rigid body coordinate system parameters of the component as variables, and iteratively calculates the variable values that satisfy all constraint conditions, thus obtaining the position and orientation of the slider component relative to the guide rail component (such as the three-dimensional coordinates and angles of the slider after moving 50mm along the guide rail axis). After the solution is completed, the kernel layer feeds back the solved component position and orientation data to the engine layer, which then further passes it to the application layer. The application layer updates the 3D model display of the component in the visualization interface based on the data, intuitively presenting the state of the slider after sliding 50mm along the guide rail, and outputting simulation data (such as the displacement and velocity of the slider) for users to view or for subsequent analysis.
[0037] In summary, this implementation method achieves rapid definition and accurate simulation of sliding joint constraints by receiving user configuration at the application layer, locating constraint activation information at the engine layer, and automatically generating and solving the basic constraint set at the kernel layer. This method is also applicable to other kinematic joint types such as fastened joints, revolute joints, and cylindrical joints. Simulations of different motion forms can be completed simply by calling the corresponding basic constraint combination rules from the mapping library, effectively reducing the user's operational threshold and improving the efficiency and accuracy of kinematic joint constraint configuration.
[0038] In one possible implementation, before the geometric constraint engine receives user input regarding the target kinematic pair type, component information involved in the motion, and kinematic pair parameters through the interaction interface provided by the application layer, the method further includes: The application layer provides an interactive interface to receive the component feature elements and their geometric attributes from the user. The geometric attributes include the center of the circle, the origin coordinates, the axis direction vector, or the plane normal vector of the component feature element. The engine layer receives component feature elements and their geometric attributes from the application layer, generates connector elements with their own local coordinate system based on the geometric attributes, and uses the connector elements as positioning components for kinematic pair constraints.
[0039] The following detailed description of the embodiments of this application is based on a simulation scenario of a rotating joint constraint in a mechanical system. This embodiment will fully present the entire process from the user selecting component feature elements and generating connector elements to the final output of motion simulation results, clearly demonstrating the collaborative working mechanism of the application layer, engine layer, and kernel layer.
[0040] Before users configure kinematic pair constraints, the geometric constraint engine needs to obtain the feature elements and their geometric properties on the components used to locate the kinematic pairs, providing basic data for the subsequent generation of connector elements. The application layer provides a visual interactive interface, allowing users to select feature elements from the 3D model. Taking the simulation of a "revolute joint" as an example, users need to specify feature elements for the two components involved in the rotational motion (such as a "shaft component" and a "bearing component") respectively: For shaft components, users can click to select the cylindrical surface at the end of the shaft component as a feature element in the visual interactive interface. The geometric properties of this feature element include the center coordinates of the cylindrical surface (i.e., the center of the shaft end, denoted as (x0, y0, z0)) and the axial direction vector of the cylindrical surface (i.e., the extension direction of the shaft, denoted as (a0, b0, c0)).
[0041] For bearing components, users select the cylindrical surface of the inner wall of the bearing component as a feature element in the visual interactive interface. The geometric attributes of the bearing component include the center coordinates of the inner cylindrical surface (i.e., the center of the bearing hole, denoted as (x1, y1, z1)) and the direction vector of the inner axis (i.e., the assembly direction of the bearing, denoted as (a1, b1, c1)). The application layer collects the identifiers of the above feature elements (such as "shaft component - cylindrical surface 1" and "bearing component - cylindrical surface 2") and their geometric attributes (center coordinates, direction vector of axis, etc.) through the interactive interface, and packages this information into structured data and passes it to the engine layer for generating connector elements.
[0042] In some embodiments, after receiving the component feature elements and their geometric attributes from the application layer, the engine layer generates connector elements based on this information. A connector element is a positioning component with its own local coordinate system, remaining relatively stationary with respect to the rigid body of the corresponding component. First, for each feature element, the engine layer extracts key parameters for constructing the local coordinate system from the geometric attributes: for the feature elements of a shaft component, the center coordinates (x0, y0, z0) of the cylindrical surface are used as the origin of the connector element; the axial direction vector (a0, b0, c0) of the cylindrical surface is used as the z-axis direction vector of the connector element, ensuring that the z-axis is consistent with the axis of rotation of the shaft; for the feature elements of a bearing component, the center coordinates (x1, y1, z1) of the inner cylindrical surface are used as the origin of the connector element; the axial direction vector (a1, b1, c1) of the inner wall is used as the z-axis direction vector of the connector element, ensuring that the z-axis is consistent with the assembly axis of the bearing.
[0043] Subsequently, the engine layer calculates the relative transformation matrix between the local coordinate system of the connector element and the rigid body coordinate system of the component, based on the rigid body coordinate system parameters of the component (i.e., the component's own global coordinate system). This matrix records the translation (origin offset) and rotation (axis angle) of the connector element relative to the component, ensuring that the connector element remains relatively stationary with respect to the component during the component's movement (i.e., their relative position and orientation remain unchanged).
[0044] Finally, the engine layer combines the rigid body information of the components (such as component ID and rigid body coordinate system parameters) with the aforementioned relative transformation matrix to generate two connector elements, denoted as Connector C-axis (corresponding to the axis component) and Connector C-bearing (corresponding to the bearing component), respectively. Each connector element contains complete local coordinate system parameters (origin coordinates, x / y / z axis direction vectors), which serve as the positioning reference for subsequent revolute joint constraints.
[0045] After generating the connector element, the user configures the specific parameters of the revolute joint constraint through the application layer. The application layer provides a dedicated function interface for kinematic pairs. The user selects "revolute joint" from the kinematic pair list through this dedicated function interface, specifying that the constraint type is to restrict the rotation of two components around a fixed axis; selects the shaft component and bearing component as the associated components of the revolute joint, and the application layer records their unique identifiers (such as "shaft-001" and "bearing-002"); and sets the rotation angle range (such as 0°-360°) and the current rotation angle (such as 90°). These parameters will be used for the subsequent numerical configuration of the basic constraints.
[0046] The application layer transmits the target kinematic pair type, component information, and kinematic pair parameters to the engine layer and kernel layer, respectively. The component information is used to associate with the generated connector elements, and the kinematic pair type and parameters are used for constraint solving. After receiving the component information from the application layer, the engine layer indexes the corresponding connector elements (C-axis and C-bearing) using the component's unique identifier and determines the effectiveness information of the revolute joint constraint based on its local coordinate system. For example, the origin coordinates (x0, y0, z0) of the C-axis and the origin coordinates (x1, y1, z1) of the C-bearing are used as the effective positions of the revolute joint constraint, corresponding to the points of action of the rotational axis on the shaft component and the bearing component, respectively; the z-axis direction vectors (a0, b0, c0) of the C-axis and (a1, b1, c1) of the C-bearing are used as the effective directions of the revolute joint constraint, corresponding to the reference axis direction of the rotational motion.
[0047] The engine layer associates the activation information (activation location, activation direction) with the component information ("shaft-001", "bearing-002") to ensure that the kernel layer can identify the target and parameters corresponding to each constraint. The associated activation information is then passed to the kernel layer. The kernel layer receives the target kinematic pair type (revolute joint), component information, kinematic pair parameters, and activation information from the application layer, and generates and solves the basic constraint set. It then calls the constraint solver to transform the basic constraint set into a system of equations, calculating the position and orientation of the shaft component after rotating 90° relative to the bearing component. The solution results are fed back to the application layer via the engine layer. The application layer updates the 3D model display of the component in the visualization interface, presenting the rotated state and outputting simulation data such as rotation angle and position coordinates.
[0048] In summary, this implementation method first obtains the component feature elements to generate connector elements, then locates the effective information of the kinematic pair constraints based on the connectors, and finally automatically generates and solves the basic constraints by the kernel layer, achieving efficient configuration and accurate simulation of revolute joint constraints. This process is also applicable to other kinematic pair types; only the constraint combination rules in the mapping library need to be adjusted to meet the simulation requirements of different motion forms, effectively solving the problems of complex operation and error susceptibility in existing technologies.
[0049] One possible implementation involves generating connector elements with their own local coordinate systems based on geometric attributes through the engine layer, including: Based on geometric properties, the engine layer extracts the origin coordinates and z-axis direction vector of the local coordinate system used to construct the connector element; The engine layer calculates the relative transformation matrix between the rigid body coordinate system of the connector element and the corresponding component based on the origin coordinates and the z-axis direction vector. The relative transformation matrix is used to record the relative position and orientation of the connector element and the corresponding component. The engine layer receives the rigid body information of the components from the application layer, and generates connector elements by combining the relative transformation matrix, so that the connector elements and the rigid bodies of the corresponding components remain relatively stationary.
[0050] like Figure 2As shown, users interactively select feature elements (such as axes, circular planes, etc.) on the component. The application layer then automatically extracts the origin and coordinate axis information based on the geometric properties of the feature element (such as the center / origin, the direction vector of the axis, and the normal vector of the plane), and calculates the relative transformation matrix with the rigid body coordinate system of the component. Further, the application layer passes the rigid body information of the component and the relative transformation matrix to the engine layer to locate and generate connector elements, which are used by the kernel layer to calculate the effective position and direction of the kinematic pair constraints (the effective position of the kinematic pair constraint is reflected in the origin of the two connectors, and the effective direction is reflected in the z-axis of the two connectors. For example, the sliding distance refers to the parallel distance between the origins of the two connectors along the z-axis of a certain connector (the sliding pair constraint also restricts the z-axis of the two connectors from coinciding)).
[0051] Here, a component refers to a real-world part model in three-dimensional space, and the relative transformation matrix records the relative position and orientation of a coordinate system in three-dimensional space relative to the component. During the motion simulation solution process, the engine layer obtains the coordinate system information of the connector element by performing relative transformations on the coordinate system of the rigid body of the component.
[0052] Still Figure 2 As shown, the engine layer calculates the translation vector of the connector element relative to the origin of the component coordinate system using the transformation matrix, and calculates the origin position of the connector using the translation vector, thus completing the positioning of the origin of the connector coordinate system. Further, the engine layer calculates the rotation parameters of the connector element's x / y / z axes relative to the x / y / z axes of the component coordinate system using the transformation matrix, and calculates the x / y / z axis directions of the connector using the rotation parameters, thus completing the axial positioning of the connector coordinate system. Finally, the engine layer generates the connector element in three-dimensional space based on the origin and x / y / z axes of the connector.
[0053] After locating and generating connector elements, the kernel layer can use the origin of the connector element to calculate the effective position of the kinematic pair constraint, and the z-axis of the connector element to calculate the effective direction of the kinematic pair constraint. For example, in the process of generating sliding pair constraints based on connector elements, the sliding distance of the sliding pair refers to the parallel distance between the origins of the two connectors along the z-axis of one of the connectors (the sliding pair constraint also restricts the z-axis of the two connectors from coinciding).
[0054] The specific connector element positioning and generation process is as follows: Figure 3 As shown, when the user selects the circular cross-section of the component as the reference feature of the sliding pair, the application layer obtains the translation vector of the transformation matrix based on the center of the circular plane of each component relative to the origin of the component coordinate system, which is used to calculate the origin of the connector local coordinate system. The application layer also obtains the rotation information of the transformation matrix based on the normal direction of the circular plane of each component relative to the z-axis of the component coordinate system, which is used to calculate the z-axis of the connector local coordinate system.
[0055] After locating the connector's local coordinate system, the engine layer uses the coordinate system information to generate the corresponding circular cross-sectional position of the connector element in three-dimensional space. Figure 4a , Figure 4b , Figure 4c These are schematic diagrams illustrating the effective constraint of sliding pairs for connector elements with different circular cross-sections, such as... Figure 4a , Figure 4b , Figure 4c As shown (connector elements are only used for constraint assistance, so they are represented by a coordinate system in 3D space). By introducing connector elements into the engine layer, the application layer no longer needs to pass the simulation information of kinematic pair constraints to the engine layer by creating basic elements and basic constraints. Instead, it can flexibly adjust the simulation effect of kinematic pair constraints by simply changing the relative transformation information. Figure 4a , Figure 4b , Figure 4c This displays the coordinate system position of the component in 3D space, the position of the corresponding circular cross-section on the component, and the connector element generated on that circular cross-section. When the user selects... Figure 4a , Figure 4b , Figure 4c The circular cross-sections at different positions (above / below / left) of the component interact, and the engine layer calculates the relative matrix to locate the connector element. The sliding pair based on the connector element will take effect at the corresponding position (above / below / left) of the component's circular cross-section.
[0056] The following section details the specific implementation process of generating connector elements based on geometric attributes at the engine layer, using the characteristic element processing scenario of shaft and hole parts in mechanical components as an example. This allows for the extraction of key geometric parameters from the characteristic elements, calculation of the relative transformation matrix, and the generation of connector elements that remain relatively stationary with the rigid body of the component, providing a precise positioning reference for kinematic pair constraints.
[0057] In some embodiments, after receiving the component feature elements and their geometric attributes from the application layer, the engine layer first extracts the core parameters for constructing the local coordinate system of the connector element from the geometric attributes: the origin coordinates and the z-axis direction vector. Taking a shaft-type part as an example, the user selects the "cylindrical surface" at the end of the shaft-type part as a feature element through the application layer. The geometric attributes of this feature element are passed from the application layer to the engine layer, including: the center coordinates of the cylindrical surface (i.e., the center of the shaft end, which is (x-axis end, y-axis end, z-axis end) in the global coordinate system of the component) and the axial direction vector of the cylindrical surface (i.e., the extension direction of the shaft, denoted as (vx-axis, vy-axis, vz-axis)).
[0058] For this feature element, the engine layer directly determines the center coordinates of the cylindrical surface as the origin coordinates of the connector element (O-axis connector), that is, O-axis connector = (x-axis end, y-axis end, z-axis end); at the same time, the axis direction vector of the cylindrical surface is determined as the z-axis direction vector of the connector element (Z-axis connector), that is, Z-axis connector = (vx-axis, vy-axis, vz-axis).
[0059] Similarly, for hole-type parts, the user selects the "cylindrical surface" of the inner wall of the hole-type part as the feature element. The geometric attributes passed by the application layer include the center coordinates of the hole (x-hole center, y-hole center, z-hole center) and the axial direction vector of the hole (vx-hole, vy-hole, vz-hole). The engine layer extracts the center coordinates of the hole as the origin of the corresponding connector element (O-hole connector = (x-hole center, y-hole center, z-hole center)), and the axial direction vector of the hole as the z-axis direction vector of the connector (Z-hole connector = (vx-hole, vy-hole, vz-hole)).
[0060] Through the above operations, the engine layer extracts the core parameters of the local coordinate system of the connector element, ensuring that the origin corresponds to the key positioning point of the feature element (such as the center of the shaft end, the center of the hole), and the z-axis corresponds to the reference direction of the feature element (such as the extension direction of the shaft, the through direction of the hole).
[0061] In this embodiment, the relative transformation matrix is a mathematical model that records the relative position and orientation between the connector element and the corresponding rigid body coordinate system of the component. Its function is to ensure that the connector element always remains relatively stationary with respect to the component during the component's movement.
[0062] In some embodiments, the engine layer calculates the relative transformation matrix between the connector element and the rigid body coordinate system of the corresponding component based on the extracted origin coordinates and z-axis direction vector.
[0063] It should be understood that the rigid body coordinate system of a component is a reference coordinate system describing the overall position and attitude of the component. Its parameters (including the origin coordinates O_rigid_body = (x_rigid_body, y_rigid_body, z_rigid_body) and the x, y, and z axis direction vectors (X_rigid_body, Y_rigid_body, Z_rigid_body)) are transmitted from the application layer to the engine layer along with the component's rigid body information. For example, the origin of the rigid body coordinate system of a shaft-type part may be located at its geometric center, and the z-axis may be aligned with the length direction of the shaft.
[0064] The translation component of the relative transformation matrix describes the positional offset of the connector element's origin relative to the origin of the rigid body coordinate system of the component. The engine layer calculates this offset through vector operations: translation vector T = O connector - O rigid body (i.e., (x connector - x rigid body, y connector - y rigid body, z connector - z rigid body)). For shaft-type parts, if the offset of the connector origin (shaft end center) relative to the origin (geometric center) of the rigid body coordinate system is (0, 0, 50 mm), then the translation vector T_axis = (0, 0, 50).
[0065] The rotation component of the relative transformation matrix is used to describe the directional difference between the connector element's z-axis and the component's rigid body coordinate system's z-axis. The engine layer calculates the rotation parameter through the angle between the direction vectors: Let the connector's z-axis direction vector be Zconnector, and the component's rigid body coordinate system's z-axis vector be Zrigid body, with the angle between them being θ (calculated using the vector dot product formula: cosθ = (Zconnector)connector)z). Z-rigid body) / (|Z connector|) The rotation axis is a unit vector perpendicular to both vectors (calculated via the cross product: rotation axis U = (Z connector × Z rigid body) / |Z connector × Z rigid body|). Based on θ and U, the engine layer uses the Rodriguez rotation formula to calculate the rotation matrix R, recording the rotation relationship between the connector's z-axis and the rigid body coordinate system's z-axis. If the connector's z-axis of a shaft-type part is aligned with the rigid body coordinate system's z-axis (θ = 0), then the rotation matrix R is an identity matrix.
[0066] Next, the engine layer combines the translation vector T and the rotation matrix R into a 4×4 homogeneous transformation matrix M (i.e., the relative transformation matrix). The top-left 3×3 portion of the matrix represents the rotation matrix R, the top-right 3×1 portion represents the translation vector T, the bottom-left corner is (0,0,0), and the bottom-right corner is 1. This matrix completely records the translation and rotation relationship between the connector element's local coordinate system and the component's rigid body coordinate system, i.e.: connector coordinate system = M × component rigid body coordinate system. After obtaining the relative transformation matrix, the engine layer, combined with the component rigid body information passed from the application layer (including the component's unique identifier, real-time parameters of the rigid body coordinate system, etc.), generates the connector element and ensures that the generated connector element remains relatively stationary with respect to the component rigid body.
[0067] In some embodiments, the engine layer assigns a unique identifier to each component (e.g., "axis-001" and "hole-002") and binds the connector element to the component identifier, establishing a "component-connector" correspondence (e.g., "axis-001" is bound to "axis connector", and "hole-002" is bound to "hole connector"). Based on the extracted origin coordinates, z-axis direction vector, and rotation information in the relative transformation matrix, the engine layer further determines the x-axis and y-axis direction vectors of the connector element (calculated by orthogonal vectors perpendicular to the z-axis to ensure that the x, y, and z axes are mutually perpendicular), thereby constructing a complete local coordinate system (including origin O, x-axis X, y-axis Y, and z-axis Z).
[0068] The engine layer associates the relative transformation matrix with the rigid body coordinate system parameters of the component, ensuring that during component movement (such as translation or rotation of the rigid body coordinate system), the local coordinate system of the connector element is always derived from the rigid body coordinate system through the relative transformation matrix. Specifically, when the component's rigid body coordinate system is updated to new parameters (O' rigid body, X' rigid body, Y' rigid body, Z' rigid body), the connector element's coordinate system is automatically updated to O' connector = M × O' rigid body, X' connector = M × X' rigid body, and so on. This association mechanism ensures that the relative position and orientation of the connector element and the component's rigid body remain unchanged, achieving relative stillness.
[0069] Ultimately, the connector element generated by the engine layer contains complete local coordinate system parameters (origin, x / y / z axis direction vectors) and their association with the components. As a positioning component for subsequent kinematic pair constraints, it provides a precise reference for determining the effective position and direction of the constraints.
[0070] Through the above embodiments, the engine layer generates connector elements based on the geometric properties of the component feature elements selected by the user, establishes a rigid relationship between the connector and the rigid body of the component through a relative transformation matrix, ensures the stability of the positioning reference during motion simulation, and lays the foundation for the accurate solution of subsequent kinematic pair constraints.
[0071] In one possible implementation, the engine layer calculates the relative transformation matrix between the connector element and the rigid body coordinate system of the corresponding component based on the origin coordinates and the z-axis direction vector, including: When the component feature element is a circular plane, the origin coordinates of the corresponding connector element are determined based on the center of the circular plane, and the z-axis direction vector of the corresponding connector element is determined based on the normal direction of the circular plane.
[0072] The following section uses the flange end face (a typical circular plane feature element) in a mechanical component as an example to explain in detail how the engine layer calculates the relative transformation matrix between the connector element and the corresponding rigid body coordinate system of the component when the component feature element is a circular plane. This process extracts the geometric properties of the circular plane, derives the relative position and direction relationship, and finally generates a transformation matrix that records the relative attitude of the connector and the component, providing a stable positioning reference for the kinematic pair constraints.
[0073] When a user selects a circular plane of a component (such as the connection face of a flange) as a feature element, the application layer passes the geometric properties of that circular plane to the engine layer. These properties include: the center coordinates of the circular plane (three-dimensional coordinates in the global coordinate system, denoted as (x-center, y-center, z-center)) and the normal vector of the circular plane (a unit vector perpendicular to the circular plane, denoted as (vx-normal, vy-normal, vz-normal)). The engine layer directly determines the center coordinates of the circular plane as the origin coordinates of the connector element (O-connector), i.e., O-connector = (x-center, y-center, z-center); simultaneously, it determines the normal vector of the circular plane as the z-axis direction vector of the connector element (Z-connector), i.e., Z-connector = (vx-normal, vy-normal, vz-normal). Specifically, the center of the circular plane is the geometric center of this feature, making it suitable as the point of application for kinematic pair constraints (such as the rotation center of a flange connection); while the normal direction is perpendicular to the plane and can be used as the reference direction for the kinematic pair (such as the flange rotating around the normal direction), ensuring that the coordinate system of the connector element is highly matched with the geometric features of the circular plane.
[0074] The rigid body coordinate system of a component serves as the reference for describing its overall position and orientation. The rigid body coordinate system parameters are transmitted from the application layer to the engine layer along with the component's rigid body information. These parameters include: the origin coordinates of the rigid body coordinate system (O rigid body = (x rigid body, y rigid body, z rigid body)) and the x, y, and z axis direction vectors (X rigid body = (vxx rigid body, vxy rigid body, vxz rigid body), Y rigid body = (vyx rigid body, vyy rigid body, vyz rigid body), Z rigid body = (vzx rigid body, vzy rigid body, vzx rigid body)). Taking a flange as an example, the origin of its rigid body coordinate system is located at the geometric center of the flange (e.g., the center of symmetry of all bolt holes), the z-axis is along the axial direction of the flange (consistent with or parallel to the end face normal), and the x and y axes are perpendicular to each other in the radial plane of the flange. III. Calculation of Translation Components of Relative Transformation Matrix The translation components of the relative transformation matrix are used to describe the positional offset of the connector element origin (center of the circular plane) relative to the origin of the component's rigid body coordinate system. The calculation process is as follows: The engine layer calculates the translation vector T through vector subtraction, i.e.: T = O connector - O rigid body = (x center - x rigid body, y center - y rigid body, z center - z rigid body). For example, if the origin of the flange rigid body coordinate system is located at the geometric center (0,0,0), and the user-selected center coordinates of the circular plane (end face) are (0,0,100mm) (i.e., the end face is 100mm away from the geometric center), then the translation vector T = (0,0,100), indicating that the connector origin is offset by 100mm relative to the rigid body origin along the positive z-axis.
[0075] In this embodiment, the rotation component is used to describe the directional difference between the connector element's z-axis (circular plane normal) and the component's rigid body coordinate system z-axis, ensuring that the relative posture of the connector and the component is accurately recorded. First, let the connector's z-axis direction vector be Z_connector (circular plane normal), and the component's rigid body coordinate system z-axis vector be Z_rigid body. If the flange's rigid body coordinate system z-axis is aligned with the end face normal direction (e.g., the flange axis is perpendicular to the end face), then the Z_connector and Z_rigid body have the same direction vector (angle is 0); if there is tilt (e.g., the end face forms a certain angle with the axis), then there is an angle θ between them.
[0076] Then, the angle θ between the Z connector and the Z rigid body is calculated using the vector dot product: cosθ = (Z connector) Z-rigid body) / (|Z connector|) |Z rigid body| (Since both are unit vectors, the denominator is 1, therefore cosθ = Z connector The rotation axis U, perpendicular to the two vectors, is calculated using the cross product of vectors for the Z-connector (Z-rigid body): U = (Z-connector × Z-rigid body) / |Z-connector × Z-rigid body| (where U is a unit vector, and its direction is the axis of rotation). Based on the rotation angle θ and the rotation axis U, the engine layer uses the Rodriguez rotation formula to calculate the rotation matrix R. This formula generates a 3×3 rotation matrix as follows: R = I + sinθ·[U]× + (1 - cosθ)·[U]ײ where I is a 3×3 identity matrix and [U]× is the antisymmetric matrix of U. If the Z-connector and Z-rigid body have the same direction (θ = 0), then sinθ = 0, 1 - cosθ = 0, and the rotation matrix R is an identity matrix, indicating that there is no relative rotation between the connector z-axis and the rigid body z-axis.
[0077] The engine layer synthesizes the translation vector T and rotation matrix R into a 4×4 homogeneous relative transformation matrix, recording the transformation relationship between the local coordinate system of the connector element and the rigid body coordinate system of the component. That is, any point Pconnector in the connector coordinate system can be transformed by Pconnector = M × Prigid body (where Prigid body is the coordinate of the point in the rigid body coordinate system). When the rigid body coordinate system of the component is updated with motion, the connector coordinate system is updated synchronously through this matrix, always remaining relatively stationary with respect to the component.
[0078] Through the above embodiments, the engine layer accurately calculates the relative transformation matrix between the connector and the rigid coordinate system of the component based on the center (origin) and normal direction (z-axis) of the circular plane feature elements. This provides a mathematical basis for the effective position and direction positioning of the subsequent kinematic pair constraints, ensuring the accuracy and stability of the constraint effect in motion simulation.
[0079] In one possible implementation, the application layer provides a dedicated kinematic pair function interface including a kinematic pair type selection sub-interface and a parameter configuration sub-interface. The kinematic pair type selection sub-interface is used to receive the user's selection instruction for the target kinematic pair type, and the parameter configuration sub-interface is used to receive the user's input rotation distance parameter, sliding distance parameter, and parameter range limitation information.
[0080] The following section, using a user interaction scenario in mechanical system motion simulation, details the specific implementation of the dedicated kinematic pair function interface provided by the application layer. It focuses on the functional design, user interaction flow, and data processing logic of the kinematic pair type selection sub-interface and parameter configuration sub-interface, to demonstrate the standardized support of the interface for kinematic pair constraint configuration.
[0081] The kinematic pair type selection sub-interface is the core interactive component of the application layer that receives user instructions on selecting the target kinematic pair type. Its design goal is to provide users with an intuitive and standardized mechanism for filtering and confirming kinematic pair types, shielding them from the complexity of underlying constraint combinations.
[0082] In the application layer's visual interactive interface, the kinematic pair type selection sub-interface is presented as a list or category menu of kinematic pair types. The list contains common kinematic pair types in mechanical systems, specifically including basic kinematic pairs (such as fastening pairs, revolute pairs, sliding pairs, cylindrical pairs, ball pairs, planar pairs, slot pairs, and parallel pairs) and kinematic pair relationships (such as gear pairs and helical pairs). Each type is accompanied by a corresponding icon (e.g., a "rotation about an axis" icon for revolute pairs and a "translation along an axis" icon for sliding pairs) to facilitate quick user identification.
[0083] When configuring kinematic pair constraints, users first activate the sub-interface by clicking the mouse or using touch. For example, when configuring constraints for "slider and guide rail," the user finds the "sliding pair" option in the list and clicks it. The sub-interface will provide real-time feedback on the selection status (e.g., highlighting the selected item and displaying a brief description box stating "sliding pair: restricts the translation of the component along a fixed axis"). If the user mistakenly selects the wrong option, they can switch to another option by clicking again; the interface supports real-time modification.
[0084] After receiving the user's selection instruction, the sub-interface first verifies the validity of the selected kinematic pair type (e.g., checking if it is a system-predefined type to avoid invalid input). Then, it converts the selection result into a standardized type identifier (e.g., "SLIDE" for sliding joint, "REVOLUTE" for revolute joint), and associates it with the identifiers of the components involved in the motion (e.g., slider ID, guide rail ID), forming "type-component" association data. This data is formatted into structured information by the application layer and synchronously transmitted to the engine layer (for associating connector elements) and the kernel layer (for calling the corresponding constraint combinations in the mapping library).
[0085] Through the above embodiments, the motion pair type selection sub-interface achieves accurate capture and standardized conversion of user selection commands, ensuring that the subsequent engine layer and kernel layer can perform collaborative processing based on a unified type identifier.
[0086] In other embodiments, the parameter configuration sub-interface is used to receive specific parameters of the kinematic pair (such as rotation distance and sliding distance) and parameter range limitation information input by the user. Its specific function is to provide an adapted parameter input interface for different types of kinematic pairs to ensure the validity and relevance of the parameters.
[0087] It should be understood that the parameter configuration sub-interface has dynamic loading capabilities. Based on the type of the motion pair, the sub-interface selects the type identifier passed to automatically load the required parameter inputs for the corresponding motion pair, avoiding interference from irrelevant parameters. For example: When the user selects "Revolute Pair", the sub-interface loads the "Rotation Angle" input box (in degrees or radians) and the "Angle Range Limit" option (e.g., minimum 0°, maximum 360°); when the user selects "Sliding Pair", the sub-interface loads the "Sliding Distance" input box (in millimeters or meters) and the "Distance Range Limit" option (e.g., minimum 0mm, maximum 100mm); when the user selects "Gear Pair", the sub-interface loads the "Transmission Ratio" input box (e.g., 1:2) and the "Rotation Direction Limit" option (same direction / opposite direction).
[0088] The sub-interface offers diverse parameter input methods, including a numeric input box (supporting direct number input), a slider control (supporting drag-and-drop selection of values), and a drop-down menu (supporting preset frequently used values). It also includes built-in parameter validation logic: when the user-input parameter exceeds the set range (e.g., a sliding distance input of 150mm, while the range is limited to 0-100mm), the interface will display a prompt box "Parameter exceeds range, please re-enter," and highlight the input box; for angle parameters, it automatically checks for non-numeric characters (e.g., "90a"), and if present, prompts "Format error, only numeric input is supported"; for gear ratios, it checks if the input is positive (to avoid invalid ratios), and if a negative number is entered, prompts "The gear ratio must be positive; the direction is set via a separate option."
[0089] After the user completes the parameter configuration and clicks "Confirm," the sub-interface further associates the parameter information (such as a sliding distance of 50mm and a range of 0-100mm) with the kinematic pair type identifier and component identifier to form a complete "kinematic pair configuration data package." This data package is encrypted at the application layer (optional, for data security) and then transmitted to the kernel layer, allowing the kernel layer to set specific constraint values when generating the basic constraint set (such as assigning a sliding distance of 50mm to the "origin-z-axis distance constraint").
[0090] As an optional implementation, the following example, using a "slider-guide rail sliding pair" configuration, demonstrates the collaborative workflow of the two sub-interfaces: The user clicks "Sliding Pair" in the kinematic pair type selection sub-interface; the interface returns the type identifier "SLIDE" and associates the component information of the slider (ID:1001) and guide rail (ID:1002); the parameter configuration sub-interface automatically loads the "Sliding Distance" input box and the "Distance Range" setting (default 0-100mm) based on the "SLIDE" identifier; the user enters "50" (unit: mm) in the input box and confirms the range limit. The range is 0-100mm. After the sub-interface verification is passed, the parameter information "distance=50,range=[0,100]" is generated. The application layer encapsulates "type=SLIDE, component=1001&1002, parameter=50&[0,100]" into a configuration data packet and passes it to the engine layer and kernel layer. The engine layer associates the corresponding connector element based on the component ID, and the kernel layer calls the mapping library based on the "SLIDE" type to generate the basic constraint set of the sliding joint, and sets "50mm" as the value of the distance constraint along the z-axis from the origin, and finally completes the solution.
[0091] Through the collaborative design of the kinematic pair type selection sub-interface and the parameter configuration sub-interface, the application layer achieves standardized and automated support for kinematic pair constraint configuration. Users do not need to pay attention to the combination logic of the underlying basic constraints, but only need to complete the type selection and parameter input through intuitive interaction, which significantly reduces the operation threshold and improves the efficiency and accuracy of kinematic pair constraint configuration.
[0092] In one possible implementation, the effectiveness information of the kinematic pair constraints is determined by the engine layer based on the local coordinate system of a pre-generated connector element, including: The engine layer assigns a unique identifier to each component participating in the motion as component information, and assigns an associated identifier to the connector element corresponding to each component, establishing a mapping relationship table between the unique identifier, the associated identifier, and the effective information of the corresponding connector element; The mapping relationship table is encapsulated into structured data through the engine layer; Structured data is passed from the engine layer to the kernel layer; The kernel layer uses a unique identifier determined based on component information to index the validity information of the corresponding connector element from the structured data.
[0093] The following section uses a simulation scenario of "rotational pairs of shafts and bearings" in a mechanical system to explain in detail how the engine layer determines the effectiveness information of kinematic pair constraints based on the local coordinate system of pre-generated connector elements, and transmits it to the kernel layer through structured data to provide a positioning basis for the generation of the basic constraint set.
[0094] Before determining the effectiveness information of kinematic pair constraints, the engine layer must first associate the components involved in the motion, their corresponding connector elements, and the effectiveness information through unique identifiers to ensure the accuracy of data association. Specifically, The engine layer assigns a unique identifier (hereinafter referred to as "Component ID") to each component involved in motion. This identifier is in string format (e.g., "Component_Shaft_001" for shaft components, "Component_Bearing_002" for bearing components) to uniquely distinguish different components. Simultaneously, an association identifier (hereinafter referred to as "Connector ID") is assigned to the connector element corresponding to each component. This identifier is logically associated with the Component ID (e.g., "Connector_Shaft_001" corresponds to the connector of the shaft component, "Connector_Bearing_002" corresponds to the connector of the bearing component), clearly defining the dependency relationship between the connector and the component.
[0095] In some embodiments, the activation information is based on the local coordinate system parameters of the connector element, including: activation position and activation direction. The activation position is the origin coordinate of the connector element, represented by three-dimensional coordinate values (e.g., the origin coordinate of the shaft connector is (x-axis, y-axis, z-axis), and the origin coordinate of the bearing connector is (x-bearing, y-bearing, z-bearing)); the activation direction is the z-axis direction vector of the connector element, represented by a unit vector (e.g., the z-axis vector of the shaft connector is (vx-axis, vy-axis, vz-axis), and the z-axis vector of the bearing connector is (vx-bearing, vy-bearing, vz-bearing)).
[0096] The engine layer constructs a "component-connector-effectiveness information" mapping table based on component ID, connector ID, and effectiveness information. This mapping table associates the component ID with the corresponding connector ID, and then associates the connector ID with its effectiveness information (effectiveness position and effectiveness direction). Taking a revolute joint as an example, the content logic of the mapping table is as follows: Component ID "Component_Shaft_001" is associated with connector ID "Connector_Shaft_001", and the corresponding effectiveness information is the origin (x-axis, y-axis, z-axis) and the z-axis vector (vx-axis, vy-axis, vz-axis); Component ID "Component_Bearing_002" is associated with connector ID "Connector_Bearing_002", and the corresponding effectiveness information is the origin (x-bearing, y-bearing, z-bearing) and the z-axis vector (vx-bearing, vy-bearing, vz-bearing).
[0097] To ensure the mapping table can be accurately parsed by the kernel layer, the engine layer needs to encapsulate it into standardized structured data. This structured data uses a hierarchical nested format, with the top level containing a "kinematic joint identifier" (e.g., "Revolute_Joint_001" indicates the current revolute joint) and a "list of associated components." Each element in the "list of associated components" corresponds to a component participating in the motion, containing four fields: component ID, connector ID, effective position, and effective direction. This structured data, through explicit field definitions, makes the association between components, connectors, and effective information explicit, facilitating encapsulation and transmission by the engine layer, as well as parsing and use by the kernel layer. During the encapsulation process, the engine layer performs format validation on the data (e.g., checking if coordinate values are valid numbers and if direction vectors are unit vectors) to ensure data validity.
[0098] After the engine layer encapsulates the structured data, it transmits the data to the kernel layer through the communication interface within the geometric constraint engine (such as an inter-process communication interface or a function call interface). The following requirements must be met during this transmission: First, ensure that all fields of the structured data (such as component ID, effective position, and effective direction) are transmitted completely to avoid kernel layer parsing failures due to missing fields. Second, maintain the "component ID - connector ID - effective information" association during transmission to ensure that the data received by the kernel layer is consistent with the data generated by the engine layer. Third, if the user adjusts the component's feature elements during interaction (such as reselecting the axis's rotation center), the engine layer must update the mapping table and structured data in real time and retransmit them to the kernel layer to ensure that the kernel layer uses the latest effective information.
[0099] After receiving structured data at the kernel layer, it needs to index the corresponding activation information from the structured data based on the component information (i.e., the component IDs participating in the motion) passed by the application layer. For example, the kernel layer reads the structured data through preset parsing logic (such as a JSON parser), extracts fields such as "joint_id" and "components", and converts the data into memory objects (such as a structure array) that the kernel layer can directly process. The kernel layer then obtains the component IDs participating in the motion (such as "Component_Shaft_001" and "Component_Bearing_002") from the component information passed by the application layer, and... The kernel layer matches identical "component_id" entries one by one in the "components" list of structured data. For successfully matched components, the kernel layer extracts the effective information from their corresponding fields. For example, for "Component_Shaft_001", it extracts the effective position (x-axis, y-axis, z-axis) and effective direction (vx-axis, vy-axis, vz-axis); for "Component_Bearing_002", it extracts the effective position (x-bearing, y-bearing, z-bearing) and effective direction (vx-bearing, vy-bearing, vz-bearing). The extracted effective information is directly used to generate the basic constraint set. For example, in a revolute joint, the kernel layer generates a "z-axis coincident constraint" based on the z-axis direction vectors of the two connectors and an "origin coincident constraint" based on the origin coordinates of the two connectors, ensuring that the position and direction of the constraint are consistent with the feature elements selected by the user.
[0100] Through the above embodiments, the engine layer realizes the accurate location, association and transmission of kinematic pair constraint effectiveness information, while the kernel layer quickly indexes the required effectiveness information through component ID, providing a reliable positioning benchmark for the automatic generation of basic constraints, ensuring the consistency of kinematic pair constraints throughout the entire process from user interaction to kernel solution, and effectively improving the accuracy and efficiency of motion simulation.
[0101] In the field of mechanical motion simulation, kinematic pairs define the constraints that govern the fixed, rotational, and translational relationships between multiple rigid bodies. They are mainly divided into basic kinematic pairs and kinematic pair relationships. Basic kinematic pairs define the constraints that govern the fixed, rotational, and translational relationships between two rigid bodies, and mainly include fasteners, cylindrical pairs, revolute pairs, sliding pairs, ball pairs, planar pairs, and slot pairs. Kinematic pair relationships define the constraints that govern the fixed, rotational, and translational relationships between multiple rigid bodies by constraining the parameters of two kinematic pairs. A ratio is defined, and the parameter value of the first kinematic pair constraint divided by the parameter value of the second kinematic pair constraint is equal to this ratio. Kinematic pair relationships mainly include helical pairs and gear pairs. In this embodiment, the effective position and direction of the kinematic pair constraints are specified using the coordinate system information of the connector element, such as the origin and the x / y / z axes, and a mapping scheme for each kinematic pair with respect to the basic constraints is established.
[0102] In one possible implementation, when the target kinematic pair type is a clamped pair, the predefined set of basic constraints in the mapping library includes: The origin coincidence constraint, x-axis coincidence constraint, y-axis coincidence constraint, and z-axis coincidence constraint of the two connector elements are used to restrict the two components to remain relatively stationary.
[0103] The fastening pair is a basic type of fastening pair, primarily mapped to the coincident constraints of the origins of the two connectors and the three axes, thereby maintaining the relative static motion of the two components. Therefore, the mapping formula for the fastening pair constraint is:
[0104] in, This represents the origin of the coordinate system for the connector element. This represents the x-axis of the coordinate system of the first connector element. This represents the y-axis of the coordinate system of the first connector element. This represents the z-axis of the coordinate system of the first connector element. This represents the x-axis of the coordinate system of the second connector element. This represents the y-axis of the coordinate system of the second connector element. This represents the z-axis of the coordinate system of the second connector element.
[0105] Taking the rigid fixation of a flange and base in a mechanical system as an example, this section explains the basic constraint set and implementation logic of the fastening pair. The core objective of the fastening pair is to restrict the relative translation and rotation of the two components, keeping them relatively stationary. The predefined basic constraint set in the mapping library achieves this objective through the following four constraints: Origin coincidence constraint, based on the effective position (origin coordinates) of the two connector elements, constrains the origins of the two elements to completely coincide in three-dimensional space (distance is 0), eliminating relative translation.
[0106] The x-axis coincidence constraint, based on the x-axis direction vectors of the two connectors, constrains them to be collinear in the same direction (the direction vectors are equal), eliminating relative rotation around the y and z axes.
[0107] The y-axis coincidence constraint, based on the y-axis direction vectors of the two connectors, constrains them to be collinear in the same direction along the y-axis, eliminating relative rotation around the x and z axes.
[0108] The z-axis coincidence constraint, based on the z-axis direction vectors of the two connectors, constrains them to be collinear in the same direction along the z-axis, eliminating relative rotation around the x and y axes.
[0109] After receiving the connector activation information (origin coordinates, three-axis direction vectors) from the engine layer, the kernel layer calls the mapping library to generate the aforementioned constraint set, and uses the constraint solver to calculate the component attitude that satisfies all constraints. Ultimately, the positions and attitudes of the two components are completely synchronized, achieving relative stillness, and the simulation results are visualized at the application layer (e.g., the flange and base always move synchronously).
[0110] In one possible implementation, when the target kinematic pair type is a sliding pair, the predefined set of basic constraints in the mapping library includes: The z-axis coincidence constraint of the two connector elements, the distance constraint of the origin of the two connector elements in the z-axis direction, and the x-axis parallel constraint of the two connector elements are used to restrict the two components to translate only along the z-axis.
[0111] In some embodiments, Figure 5 This is a schematic diagram illustrating the basic constraints for mapping sliding pairs based on connector elements, as shown below. Figure 5 As shown, a sliding joint is a basic type of joint. A sliding joint can be mapped to basic constraints such as "two connectors coinciding on the z-axis," "two connectors having parallel x / y axes," and "two connectors having XOY plane distance constraints." This ensures that the two components can only translate relative to each other along the z-axis, and cannot rotate around the z-axis. Therefore, the mapping formula for the sliding joint constraint is:
[0112] in, This represents the origin of the coordinate system for the connector element. This represents the x-axis of the coordinate system of the first connector element. This represents the z-axis of the coordinate system of the first connector element. This represents the x-axis of the coordinate system of the second connector element. This represents the z-axis of the coordinate system of the second connector element. This represents the sliding distance along the z-axis.
[0113] Taking the sliding connection between the slider and the guide rail as an example, this section explains the basic constraint set and operational logic of the sliding pair. The core objective of the sliding pair is to restrict the two components to relative translation only along a fixed axis (z-axis). The predefined basic constraint set in the mapping library achieves this objective through the following three constraints: The z-axis coincidence constraint, based on the z-axis direction vectors of the two connector elements, constrains them to be collinear in the same direction (with the same direction vector), ensuring that the sliding direction is unique (along the z-axis).
[0114] The distance constraint of the origin in the z-axis direction is based on the origin coordinates of the two connectors. It only restricts the distance between them in the z-axis direction (equal to the sliding parameter), allowing relative translation along the z-axis, while constraining the distance in the x and y directions to 0 (restricting translation in other directions).
[0115] The x-axis parallel constraint, based on the x-axis direction vectors of the two connectors, constrains the two to be parallel along the x-axis (the angle between the direction vectors is 0), restricts relative rotation around the z-axis, and ensures attitude stability during sliding.
[0116] After receiving the connector activation information at the kernel layer, the mapping library is invoked to generate the aforementioned constraints, and the solver calculates the component positions that satisfy the constraints. Ultimately, the slider can only translate along the z-axis of the guide rail; movement in other directions is restricted. The simulation results at the application layer represent the slider smoothly sliding along the guide rail.
[0117] When the target kinematic pair type is a spherical joint, the spherical joint belongs to the basic joint type. It is mapped to the coincidence constraint of the origins of the two connectors and the angular constraint of the z-axis, thus ensuring that the two components can only rotate around any axis passing through the origin. Therefore, the mapping formula for the spherical joint constraint is:
[0118] in, This represents the origin of the coordinate system for the connector element. This represents the z-axis of the coordinate system of the first connector element. This represents the z-axis of the coordinate system of the second connector element. This represents the 3D angle between the two z-axis.
[0119] In one possible implementation, when the target kinematic pair type is a cylindrical pair, the predefined set of basic constraints in the mapping library includes: The z-axis coincidence constraint of the two connector elements, the distance constraint of the origin of the two connector elements in the direction perpendicular to the z-axis, and the x-axis angle constraint of the two connector elements are used to allow the two components to translate along the z-axis and rotate about the z-axis.
[0120] Cylindrical joints are a basic type of joint, primarily mapped to the coincidence constraint along the z-axis, the angular constraint along the x-axis, and the distance constraint at the origin of the two connectors. This allows the two components to translate relative to each other along the z-axis and rotate around it. Therefore, the mapping formula for cylindrical joint constraints is:
[0121] in, This represents the origin of the coordinate system for the connector element. This represents the x-axis of the coordinate system of the first connector element. This represents the y-axis of the coordinate system of the first connector element. This represents the z-axis of the coordinate system of the first connector element. This represents the x-axis of the coordinate system of the second connector element. This represents the y-axis of the coordinate system of the second connector element. This represents the z-axis of the coordinate system of the second connector element. This represents the sliding distance along the z-axis. This represents the rotation angle around the z-axis.
[0122] Taking the fit between a shaft and a bushing as an example, this section explains the basic constraint set and operational logic of a cylindrical joint. The core objective of a cylindrical joint is to allow relative translation between the two components along a fixed axis (z-axis), while also allowing relative rotation around that axis, and restricting movement in other directions. The predefined set of basic constraints in the mapping library achieves this objective through the following three constraints: The z-axis coincidence constraint, based on the z-axis direction vectors of the two connector elements, constrains the two z-axis to be collinear in the same direction (with consistent direction vectors), thus establishing the reference axis (z-axis) for translation and rotation.
[0123] The distance constraint of the origin in the direction perpendicular to the z-axis restricts the distance between the origins of the two connectors in the x and y directions to 0 (only the distance in the z-axis direction is allowed to change), ensuring that there is no relative translation in the plane perpendicular to the z-axis.
[0124] The x-axis angle constraint allows for an angle between the x-axis of the two connectors (this angle is the rotation angle around the z-axis), does not restrict relative rotation around the z-axis, and restricts rotation in other directions through x-axis association.
[0125] After the kernel layer generates the above constraints based on the connector activation information, the solver calculates the following results: the two components can translate freely along the z-axis and rotate relative to each other around the z-axis, while movement in other directions is restricted. In the simulation, this manifests as the shaft being able to slide axially and rotate around its axis within the bushing.
[0126] In one possible implementation, when the target kinematic pair type is a revolute joint, the predefined set of basic constraints in the mapping library includes: z-axis coincidence constraint of the two connector elements, origin coincidence constraint of the two connector elements, and x-axis angle constraint of the two connector elements, to restrict the two components to rotate only about the z-axis.
[0127] A revolute joint is a basic type of joint, mapped to the coincidence constraint on the z-axis and the angular constraint on the x-axis of the two connectors. This ensures that the two components can only rotate relative to each other around the z-axis, and cannot translate along the z-axis. Therefore, the mapping formula for the revolute joint constraint is:
[0128] in, This represents the origin of the coordinate system for the connector element. This represents the x-axis of the coordinate system of the first connector element. This represents the z-axis of the coordinate system of the first connector element. This represents the x-axis of the coordinate system of the second connector element. This represents the z-axis of the coordinate system of the second connector element. This represents the rotation angle around the z-axis.
[0129] Taking the hinge connection between a door and its frame as an example, this section explains the basic constraint set and operational logic of a revolute joint. The core objective of a revolute joint is to restrict the two components to relative rotation only around a fixed axis (z-axis), prohibiting translation or rotation in other directions. The predefined basic constraint set in the mapping library achieves this objective through the following three constraints: The z-axis coincidence constraint, based on the z-axis direction vectors of the two connectors, constrains the two to be collinear in the same direction (with the same direction vector), thus establishing a unique rotational reference axis (z-axis).
[0130] Origin coincidence constraint restricts the origin coordinates of the two connectors to be completely coincident (distance is 0), eliminates relative translation along the x, y, and z axes, and ensures rotation around the same center point.
[0131] The x-axis angle constraint allows for an angle between the two connectors along the x-axis (this angle is the rotation angle around the z-axis), but restricts the angle to change only along the z-axis direction and prohibits rotation around the x and y axes.
[0132] After the kernel layer generates the above constraints based on the connector activation information, the solver calculation results satisfy the following: the two components can only rotate relative to each other around the z-axis, and movement in other directions is restricted. In the simulation, this manifests as the door rotating around the hinge axis (z-axis) of the door frame, unable to translate or rotate off the axis.
[0133] In one possible implementation, when the target kinematic pair type is a parallel pair, the predefined set of basic constraints in the mapping library includes: z-axis parallel constraints of the two connector elements, distance constraints of the origins of the two connector elements in the z-axis direction, distance constraints of the origins of the two connector elements in the x-axis direction, distance constraints of the origins of the two connector elements in the y-axis direction, and x-axis angular constraints of the two connector elements, to allow the two components to rotate along the z-axis and translate along the x-axis, y-axis, or z-axis.
[0134] Parallel joints are a basic type of joint, primarily mapped to the parallel constraints along the z-axis, the angular constraints along the x-axis, the parallel distance constraints of the origin about the x-axis, the parallel distance constraints of the origin about the y-axis, and the parallel distance constraints of the origin about the z-axis between the two connectors. This allows the two components to rotate relative to each other along the z-axis, and also translate along the x-axis, y-axis, or z-axis. Therefore, the mapping formula for parallel joint constraints is:
[0135] in, This represents the origin of the coordinate system for the connector element. This represents the x-axis of the coordinate system of the first connector element. This represents the y-axis of the coordinate system of the first connector element. This represents the z-axis of the coordinate system of the first connector element. This represents the x-axis of the coordinate system of the second connector element. This represents the z-axis of the coordinate system of the second connector element. This represents the sliding distance along the z-axis. This represents the sliding distance along the x-axis. This represents the sliding distance along the y-axis. This represents the rotation angle around the z-axis.
[0136] Taking the connection of two parallel rods as an example, this section explains the basic constraint set and operational logic of a parallel joint. The core objective of a parallel joint is to allow the two components to rotate relative to each other along the z-axis, and simultaneously translate relative to each other along the x, y, and z axes, while always maintaining parallelism along the z-axis. The predefined set of basic constraints in the mapping library achieves this objective through the following five constraints: The z-axis parallel constraint, based on the z-axis direction vectors of the two connectors, constrains the two to be parallel along the z-axis (the angle between the direction vectors is 0), ensuring that the two components always maintain the same direction, and providing a reference direction for translation and rotation.
[0137] The distance constraint of the origin in the z-axis direction limits the distance between the origins of the two connectors in the z-axis direction to a fixed value (such as a preset spacing), allowing translation along the z-axis (synchronous movement as a whole), but keeping the relative distance unchanged.
[0138] The distance constraint of the origin in the x-axis direction restricts the distance between the two origins in the x-axis direction to a fixed value, allowing translation along the x-axis while maintaining the stability of their relative lateral positions.
[0139] The distance constraint of the origin in the y-axis direction restricts the distance between the two origins in the y-axis direction to a fixed value, allowing translation along the y-axis while maintaining the stability of their relative longitudinal positions.
[0140] The x-axis angle constraint allows for an angle between the x-axis of the two connectors (this angle is the rotation angle around the z-axis), does not restrict relative rotation around the z-axis, and restricts rotation around the x and y axes through x-axis association.
[0141] After generating the above constraints at the kernel layer, the solver's calculation results satisfy the following: the two components can translate along the x, y, and z axes (maintaining relative distance) and can rotate relative to each other around the z-axis, but always remain parallel to each other along the z-axis. In the simulation, this manifests as the two parallel rods being able to translate synchronously and rotate relative to each other around the axis, always maintaining a parallel state.
[0142] In one possible implementation, when the target kinematic pair type is a slot pair, the predefined set of basic constraints in the mapping library includes: The two connector elements are subject to z-axis parallel constraints, origin distance constraints, origin-x-axis coincidence constraints, and x-axis angle constraints to allow the two components to rotate along the z-axis and translate along the x-axis.
[0143] The slot joint is a basic type of joint, primarily mapped to the parallel constraints along the z-axis, the angular constraints along the x-axis, the distance constraints between the origins, and the coincidence constraints between the origins and the x-axis of the two connectors. This allows the two components to rotate relative to each other along the z-axis and translate relative to each other along the x-axis. Therefore, the mapping formula for the slot joint constraints is:
[0144] in, This represents the origin of the coordinate system for the connector element. This represents the x-axis of the coordinate system of the first connector element. This represents the z-axis of the coordinate system of the first connector element. This represents the x-axis of the coordinate system of the second connector element. This represents the z-axis of the coordinate system of the second connector element. This represents the sliding distance along the x-axis. This represents the rotation angle around the z-axis.
[0145] Taking the cooperation between the slider and the long slot as an example, this paper explains the basic constraint set and the logic of the slot pair.
[0146] The core objective of a slot joint is to allow two components to rotate relative to each other along the z-axis, while restricting relative translation only along the x-axis and limiting movement in other directions. The predefined set of basic constraints in the mapping library achieves this objective through the following four constraints: The z-axis parallel constraint is based on the z-axis direction vectors of the two connectors, constraining them to be parallel along the z-axis (the angle between the direction vectors is 0), establishing the rotation reference direction, and ensuring that the attitude reference is consistent when rotating around the z-axis.
[0147] Origin distance constraint restricts the distance between the origins of the two connectors in the y-axis direction to a fixed value (such as the slot width), prohibits relative translation along the y-axis, and ensures that the slider does not disengage from the lateral constraint of the slot.
[0148] The origin coincides with the x-axis constraint, which ensures that the origins of both connectors are on the x-axis (with the same y-coordinate), further limiting the relative position and ensuring that translation occurs only along the x-axis direction.
[0149] The x-axis angle constraint allows for an angle between the x-axis of the two connectors (this angle is the rotation angle around the z-axis), does not restrict relative rotation around the z-axis, and restricts rotation around the x and y axes through x-axis association.
[0150] After the above constraints are generated in the kernel layer, the solver calculation results satisfy the following: the two components can translate relative to each other along the x-axis (such as the slider sliding in the slot) and can rotate relative to each other around the z-axis (such as the slider rotating in the slot), but cannot translate along the y-axis or deviate from the x-axis direction. In the simulation, this is manifested as the slider sliding and rotating stably in the slot.
[0151] In one possible implementation, when the target kinematic pair type is a gear pair, the predefined set of basic constraints in the mapping library includes: The two kinematic pairs are constrained by a parallel constraint on the rotation axis, and the ratio of the angle parameter of the first kinematic pair constraint to the angle parameter of the second kinematic pair constraint is equal to a set ratio constraint, so as to realize the gear transmission relationship.
[0152] A gear pair is a constraint relating two kinematic pairs with rotational angles. It is primarily mapped to the first angle parameter divided by the second angle parameter equaling their defined ratio, and the parallelism of the rotation axes of the two kinematic pairs. This achieves a gear relationship, meaning that the relative rotation of the kinematic pair constraint corresponding to the first angle parameter can drive the relative rotation of the kinematic pair constraint corresponding to the second angle parameter, which is parallel to its rotation axis. Therefore, the mapping formula for the gear pair constraint is:
[0153] in, The axis of rotation representing the first kinematic pair constraint. The axis of rotation representing the second kinematic pair constraint. This represents the angle parameter of the first kinematic pair constraint. This represents the angle parameter of the second kinematic pair constraint. This indicates the ratio defined in the gear pair.
[0154] Taking the meshing transmission of a pair of cylindrical gears as an example, this section explains the basic constraint set and operational logic of a gear pair. The goal of the gear pair is to achieve synchronous transmission of the two gears around their respective axes of rotation, keeping the axes parallel and the rotation angles proportionally related. The predefined basic constraint set in the mapping library achieves this goal through the following two constraints: The rotation axis parallel constraint is based on the z-axis direction vectors of the two gear connectors (corresponding to the rotation axes of the two gears respectively), constraining the z-axis of the two gears to be parallel (the angle between the direction vectors is 0), ensuring that the rotation axes do not intersect or tilt when the gears mesh, thus avoiding transmission interference.
[0155] Angle parameter ratio constraint, associating the rotation angle parameters of the two gears (rotation angles around their respective z-axis), constrains the ratio of the angle parameter θ1 of the first gear to the angle parameter θ2 of the second gear to be equal to a set ratio (such as transmission ratio i=θ1 / θ2=z2 / z1, where z1 and z2 are the number of teeth of the two gears), realizing the transmission relationship of "the driving gear rotating to drive the driven gear to rotate proportionally".
[0156] After the kernel layer generates the above constraints based on the connector activation information, the solver calculation results satisfy the following: the rotation axes of the two gears are always parallel, and the rotation angle changes synchronously according to the set transmission ratio. In the simulation, this is manifested as the gears meshing and rotating with the speed ratio consistent with the set value, without any jamming or misalignment.
[0157] In one possible implementation, when the target kinematic pair type is a planar pair, the predefined set of basic constraints in the mapping library includes: The z-axis parallel constraint of the two connector elements, the coincidence constraint of the origin of the two connector elements in the z-axis direction, the distance constraint of the origin of the two connector elements in the x-axis direction, the distance constraint of the origin of the two connector elements in the y-axis direction, and the x-axis angle constraint of the two connector elements are used to allow the two components to rotate along the z-axis and translate along the x-axis or y-axis.
[0158] Planar joints are a basic type of joint, primarily mapped to the parallel constraints along the z-axis, the angular constraints along the x-axis, the parallel distance constraints of the origin about the x-axis, the parallel distance constraints of the origin about the y-axis, and the coincidence constraints of the origin and the z-axis between the two connectors. This allows the two components to rotate relative to each other along the z-axis and translate relative to each other along the x-axis or y-axis. Therefore, the mapping formula for planar joint constraints is:
[0159] in, This represents the origin of the coordinate system for the connector element. This represents the x-axis of the coordinate system of the first connector element. This represents the y-axis of the coordinate system of the first connector element. This represents the z-axis of the coordinate system of the first connector element. This represents the x-axis of the coordinate system of the second connector element. This represents the z-axis of the coordinate system of the second connector element. This represents the sliding distance along the x-axis. This represents the sliding distance along the y-axis. This represents the rotation angle around the z-axis.
[0160] Taking the motion of a slider within a planar worktable as an example, this section explains the basic constraint set and operational logic of a planar joint. The goal of a planar joint is to allow two components to move within the same plane (translation along the x and y axes, and rotation about the z-axis), but restrict translation along the direction perpendicular to the plane (z-axis) and rotation about the x and y axes. The predefined set of basic constraints in the mapping library achieves this goal through the following five constraints: The z-axis parallel constraint is based on the z-axis direction vectors of the two connectors, constraining them to be parallel along the z-axis (the angle between the direction vectors is 0), establishing the normal reference of the plane, and ensuring that the two components are always coplanar and have the same plane direction.
[0161] The coincidence constraint of the origin in the z-axis direction restricts the distance between the origins of the two connectors in the z-axis direction to 0 (equal z coordinates), limits the range of motion to the same plane, and prohibits relative translation along the z-axis.
[0162] The distance constraint between the origins along the x-axis does not fix the distance between the two origins along the x-axis (allowing for free variation), providing degrees of freedom for relative translation along the x-axis.
[0163] The distance constraint between the origins along the y-axis does not fix the distance between the two origins along the y-axis (allowing for free variation), providing degrees of freedom for relative translation along the y-axis.
[0164] The x-axis angle constraint allows for an angle between the x-axis of the two connectors (this angle is the rotation angle around the z-axis), does not restrict relative rotation around the z-axis, and restricts rotation around the x and y axes through x-axis association.
[0165] After generating the above constraints at the kernel layer, the solver's calculation results satisfy the following: the two components can translate freely along the x-axis and y-axis in the same plane, and can rotate relative to each other around the z-axis, but cannot translate along the z-axis or rotate off the plane. In the simulation, this is manifested as the slider sliding and rotating arbitrarily within the worktable surface, always remaining in contact with the surface and not detaching.
[0166] When the target kinematic pair type is a helical pair, a helical pair is a kinematic pair relationship applied to a cylindrical pair. It restricts the angular parameter of the cylindrical pair to be divided by its distance parameter, which equals a defined ratio. This achieves a screw-like relationship, meaning that the rotation of the second connector relative to the first connector can drive its own translation relative to the first connector on its rotation axis. Therefore, the mapping formula for the helical pair constraint is:
[0167] in, The distance parameter represents the cylindrical joint. This represents the angular parameters of the cylindrical joint. This indicates the proportion defined in the helical pair.
[0168] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0169] Corresponding to the implementation method of supporting kinematic pair constraints in the geometric constraint engine in the above embodiment, Figure 6 This is a schematic diagram of the architecture of a geometric constraint engine provided in an embodiment of this application, with reference to... Figure 6 The geometry constraint engine includes: Application layer 601 is used to provide an interactive interface to receive user input of the target kinematic pair type, component information involved in the motion, and kinematic pair parameters of the kinematic pair constraint; Engine layer 602 connects to application layer 601 and is used to determine the effectiveness information of kinematic pair constraints based on the local coordinate system of the pre-generated connector element. The effectiveness information includes the effectiveness position determined by the origin coordinates of the connector element and the effectiveness direction determined by the z-axis direction vector of the connector element. The kernel layer 603 connects the application layer 601 and the engine layer 602. It is used to receive the target kinematic pair type, component information and kinematic pair parameters transmitted by the application layer, as well as the activation information transmitted by the engine layer; and to call the pre-built mapping library of kinematic pair type and basic constraint combination to automatically generate the corresponding basic constraint set according to the target kinematic pair type and activation information. Kernel layer 603 is also used to read kinematic pair parameters, set the values of basic dimensional constraints in the basic constraint set, and call the constraint solver to solve the basic constraint set and output the simulation results of the kinematic pair constraints.
[0170] The following section, using a simulation scenario of the rotational motion of a robotic arm elbow joint, provides a detailed explanation of the structure and working process of the geometric constraint engine described in this invention, clearly demonstrating the collaborative mechanism of the application layer, engine layer, and kernel layer.
[0171] The application layer serves as the user interaction entry point, providing a visual interface and standardized interfaces, and is responsible for receiving user configuration commands and parameters; the engine layer determines the effective position and direction of the kinematic pair constraints based on pre-generated connector elements; the kernel layer generates a set of basic constraints based on the input information and solves them, outputting simulation results.
[0172] The application layer receives user input through interactive interfaces (such as buttons, input boxes, and drop-down menus in a graphical interface). In the simulation of the robotic arm elbow joint, the user selects "revolute joint" in the "kinematic joint type" drop-down menu through the application layer, specifying that the constraint type is to restrict the rotation of the two arm segments around a fixed axis. The "upper arm segment" and "lower arm segment" are selected from the model library as associated components, and the application layer records their unique identifiers (such as "Arm_Upper_001" and "Arm_Lower_002"). The user sets the rotation angle range (-90°~90°) and the current angle (30°) in the parameter input box. After the application layer verifies the parameter format (such as excluding non-numeric inputs), it transmits the above information to the engine layer (component identifier) and the kernel layer (kinematic joint type and parameters) respectively.
[0173] The engine layer connects to the application layer and determines the activation information based on pre-generated connector elements. Before the user configures constraints, the engine layer has already generated connector elements, "Connector C Upper" (corresponding to the upper arm segment) and "Connector C Lower" (corresponding to the lower arm segment), based on the component feature elements selected by the user (such as the elbow joint axis of the upper arm segment and the corresponding shaft hole of the lower arm segment). Each connector has a local coordinate system (the origin is the joint center, and the z-axis is the direction of the rotation axis). After receiving the component identifier from the application layer, the engine layer indexes the corresponding connector element and extracts the activation information: Activation position: the origin coordinates of C Upper (x upper, y upper, z upper) and C Lower (x lower, y lower, z lower), corresponding to the points of action of the rotation axis on the two arm segments; Activation direction: the z-axis direction vector of C Upper (vx upper, vy upper, vz upper) and C Lower (vx lower, vy lower, vz lower), corresponding to the direction of the rotation axis.
[0174] The engine layer associates the activation information with the component identifier, encapsulates it into structured data (including origin coordinates, z-axis vector, and component ID), and passes it to the kernel layer. The kernel layer connects the application layer and the engine layer, and is responsible for constraint generation and solving. The kernel layer receives the "revolute joint" type, component identifier, rotation parameter (30°) from the application layer, and the activation information from the engine layer. The kernel layer calls a pre-built mapping library to match the corresponding basic constraint combination according to the "revolute joint" type, including: z-axis coincidence constraint (the z-axis direction vectors of the upper and lower C axes are the same); origin coincidence constraint (the origin coordinates of the upper and lower C axes are equal); and x-axis angle constraint (the x-axis angle between the upper and lower C axes is 30°).
[0175] The kernel layer assigns the rotation parameter (30°) to the x-axis angle constraint, calls the constraint solver (such as an iterative algorithm-based solver) to solve the constraint set, and calculates the position and orientation of the lower arm segment after rotating 30° relative to the upper arm segment. The kernel layer feeds back the solution results (the 3D coordinates and rotation angle of the lower arm segment) to the engine layer, and then to the application layer. The application layer updates the robotic arm model in the visualization interface, intuitively presenting the state of the elbow joint after rotating 30°, and outputs simulation data (such as joint angles, arm end position, etc.).
[0176] In summary, this geometric constraint engine achieves efficient simulation of kinematic pair constraints by receiving configuration at the application layer, locating and applying activation information at the engine layer, and automatically generating and solving constraints at the kernel layer. This architecture is applicable to various types of kinematic pairs (such as sliding pairs and gear pairs), and only requires predefined constraint combinations in the mapping library to meet the motion simulation needs of different scenarios, significantly improving the convenience and accuracy of constraint configuration.
[0177] The geometric constraint engine provided in this application embodiment, and the method for supporting kinematic pair constraints in the geometric constraint engine, wherein the application layer calculates the relative transformation matrix based on the relative position of the circular cross section and the component in the user-interacted visualization interface and sends it to the engine layer.
[0178] The engine layer calculates the translation vector and rotation parameters of the connector relative to the component coordinate system based on the component and transformation matrix. Then, it locates the coordinate system of the connector element based on the translation vector and rotation parameters and generates the connector in 3D space. Further, the engine layer determines the effective position of the kinematic pair based on the origin of the connector and the effective direction of the kinematic pair based on the z-axis of the connector. Based on the kinematic pair parameters, it creates kinematic pair constraints of the corresponding kinematic pair type and sends them to the kernel layer.
[0179] The kernel layer invokes the mapping library based on the kinematic pair constraints, automatically generating the corresponding set of basic constraints according to the kinematic pair type. For example, mapping a sliding pair to the distance constraint between the origins of the two connectors and the coincidence constraint of the z-axis of the two connectors. Simultaneously, it reads the relevant parameters of the kinematic pair constraints and sets the values of the basic dimensional constraints after mapping (e.g., setting the distance value of the origin distance constraint between the two connectors based on the sliding distance parameter). Finally, the kernel layer calls the constraint solver to solve the generated set of basic constraints.
[0180] After the constraint solver transforms the basic constraints into a system of equations for solution, it returns the solution results (such as the origin position and axial vector of the connector and component) to the kernel layer. The kernel layer then updates the position of the connector and component and feeds it back to the engine layer. The engine layer returns the position of the connector and component to the application layer, and the application layer renders the solved component and connector in the visualization interface based on this information.
[0181] The geometric constraint engine and the method for supporting kinematic pair constraints in the geometric constraint engine provided in the embodiments of this application can achieve, but are not limited to, the following technical effects: 1. Significantly reduces user operation complexity: Users do not need to manually create and configure basic constraints. They only need to select the kinematic pair type through the application layer interface and select the component feature through the element connector to complete the definition of the kinematic pair constraint. The operation steps are simplified from "manually creating N basic constraints + repeatedly configuring parameters" to "selecting the kinematic pair type + configuring kinematic parameters with one click", which greatly reduces the complexity of using the kinematic pair function. 2. Achieve black-box characteristics and improve interface usability: The application layer completely shields the complex logic of the underlying basic constraints. Users only need to focus on business-level information such as "motion pair type" and "participating components" without needing to understand the constraint combination details of the motion pair constraints, which significantly reduces the development and usage threshold of the application layer.
[0182] 3. Improve the accuracy of motion pair configuration: The element connector automatically extracts positioning parameters based on component features, avoiding deviations caused by manual parameter input by the user; the kernel automatically generates basic constraints through a preset mapping library, ensuring the logical correctness of constraint combinations and reducing simulation anomalies caused by configuration errors from the source.
[0183] 4. Enhance system scalability and maintainability: When adding a new kinematic pair type, only the mapping relationship between the kinematic pair and the basic constraint needs to be added to the kernel mapping library, without modifying the application layer interface; for the logical optimization of existing kinematic pair constraints, only the constraint combination rules in the mapping library need to be adjusted, realizing "one-stop modification, global effect", which facilitates system upgrades and maintenance.
[0184] This application also provides an electronic device, which includes one or more processors and a memory; The memory is coupled to one or more processors. The memory is used to store computer program code, which includes computer instructions. One or more processors call the computer instructions to cause the electronic device to execute the aforementioned implementation method for supporting kinematic pair constraints in the geometric constraint engine.
[0185] Figure 7This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 700 can be a mobile phone, smart screen, tablet computer, wearable electronic device, in-vehicle electronic device, augmented reality (AR) device, virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), projector, or a communication device such as a server, storage device, or base station, or a smart car, etc. This application embodiment does not impose any limitations on the specific type of electronic device.
[0186] The memory 701 can be used to store computer software programs 702 and modules. The processor 703 executes various functional applications and data processing of the electronic device by running the software programs and modules stored in the memory 701. The memory 701 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device (such as audio data, telephone directory, etc.). In addition, the memory 701 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.
[0187] The processor 703 may include one or more processors such as a central processing unit (CPU), an application processor (AP), and a baseband processor. The processor can serve as the nerve center and command center of the wireless router. The processor 703 can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. The memory 701 can be used to store executable program code, including instructions. The processor 703 executes various functional applications and data processing of the network device by running the instructions stored in the memory. The memory 701 may include a program storage area and a data storage area, such as storing data for audio signals to be played. For example, the memory may be Double Data Rate Synchronous Dynamic Random Access Memory (DDR) or Flash memory.
[0188] This application also provides a computer-readable storage medium storing computer instructions; when the computer-readable storage medium is run on an electronic device, the electronic device executes the aforementioned method for supporting kinematic pair constraints in a geometric constraint engine.
[0189] The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or can include one or more data storage devices such as servers or data centers that can be integrated with media. The available medium can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media, or semiconductor media (e.g., solid-state disks (SSDs)).
[0190] This application also provides a computer program product containing computer instructions, which, when run on an electronic device, enables the electronic device to execute the aforementioned method for supporting kinematic pair constraints in a geometric constraint engine.
[0191] The computer storage medium and computer program product provided in the embodiments of this application are used to execute the methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects corresponding to the methods provided above, and will not be repeated here.
[0192] In the above embodiments, implementation can also be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, optical fiber, Digital Subscriber Line, DSL) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that integrates one or more available media. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc., and the storage medium can also include combinations of the above types of memory.
[0193] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0194] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0195] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0196] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. 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 this application, and should all be included within the protection scope of this application.
Claims
1. A method for supporting implementation of kinematic pair constraints in a geometric constraint engine, characterized in that, The application is applied to a geometric constraint engine including an application layer, an engine layer and a kernel layer, and comprises: Through an interactive interface provided by the application layer, a target type of a kinematic pair constraint input by a user, component information participating in kinematics and kinematic pair parameters are received; Through the engine layer, based on a local coordinate system of a connector element generated in advance, validity information of the kinematic pair constraint is determined, the validity information including a validity position determined by an origin coordinate of the connector element and a validity direction determined by a z-axis direction vector of the connector element; Through the kernel layer, the target type of the kinematic pair, the component information and the kinematic pair parameters transferred by the application layer are received, and the validity information transferred by the engine layer is received; and a pre-constructed mapping library of kinematic pair types and basic constraint combinations is called to automatically generate a corresponding basic constraint set according to the target type of the kinematic pair and the validity information; Through the kernel layer, the kinematic pair parameters are read, values of basic dimension constraints in the basic constraint set are set, and a constraint solver is called to solve the basic constraint set to output a simulation result of the kinematic pair constraint.
2. The method of claim 1, wherein, Before the geometric constraint engine receives, through an interactive interface provided by the application layer, a target type of a kinematic pair constraint input by a user, component information participating in kinematics and kinematic pair parameters, the method further comprises: Through an interactive interface provided by the application layer, a component feature element input by the user and geometric attributes of the component feature element are received, the geometric attributes including a center of a circle, an origin coordinate, an axis direction vector or a plane normal vector of the component feature element; Through the engine layer, the component feature element and the geometric attributes thereof transferred by the application layer are received, a connector element with a local coordinate system is generated based on the geometric attributes, and the connector element is taken as a positioning component of the kinematic pair constraint.
3. The method of claim 2, wherein, Through the engine layer, a connector element with a local coordinate system is generated based on the geometric attributes, and comprises: Through the engine layer, an origin coordinate and a z-axis direction vector used for constructing the local coordinate system of the connector element are extracted according to the geometric attributes; Through the engine layer, a relative transformation matrix between the connector element and a rigid body coordinate system of a corresponding component is calculated based on the origin coordinate and the z-axis direction vector, the relative transformation matrix being used for recording a relative position and direction of the connector element and the corresponding component; Through the engine layer, component rigid body information transferred by the application layer is received, and the connector element is generated in combination with the relative transformation matrix, so that the connector element and the rigid body of the corresponding component remain relatively static.
4. The method of claim 3, wherein, The calculation of the relative transformation matrix between the connector element and the rigid body coordinate system of the corresponding component based on the origin coordinate and the z-axis direction vector by the engine layer comprises: In the case that the component feature element is a circle plane, the origin coordinate of the corresponding connector element is determined based on a center of the circle plane, and the z-axis direction vector of the corresponding connector element is determined based on a normal direction of the circle plane.
5. The method of claim 1, wherein, The application layer provides a motion pair special function interface, which includes a motion pair type selection sub-interface and a parameter configuration sub-interface; the motion pair type selection sub-interface is configured to receive a selection instruction of the target motion pair type from the user, and the parameter configuration sub-interface is configured to receive a rotation distance parameter, a sliding distance parameter and parameter range limit information input by the user.
6. The method according to any one of claims 1 to 5, characterized in that, The engine layer determines the validity information of the motion pair constraint based on the local coordinate system of the connector element generated in advance, including: The engine layer assigns a unique identifier to each component involved in the motion as the component information, and assigns an associated identifier to each connector element corresponding to the component, and establishes a mapping relationship table between the unique identifier and the associated identifier, and the validity information of the corresponding connector element; The engine layer encapsulates the mapping relationship table into structured data; The engine layer transmits the structured data to the kernel layer; The kernel layer indexes the validity information of the corresponding connector element from the structured data based on the unique identifier determined by the component information.
7. The method according to any one of claims 1 to 5, characterized in that, In the case that the target motion pair type is a fastening pair, the pre-defined basic constraint set in the mapping library includes: The origin coincidence constraint of the two connector elements, the x-axis coincidence constraint of the two connector elements, the y-axis coincidence constraint of the two connector elements, and the z-axis coincidence constraint of the two connector elements, to limit the two components to keep relative static.
8. The method according to any one of claims 1 to 5, characterized in that, In the case that the target motion pair type is a sliding pair, the pre-defined basic constraint set in the mapping library includes: The z-axis coincidence constraint of the two connector elements, the distance constraint of the origin of the two connector elements in the z-axis direction, and the x-axis parallel constraint of the two connector elements, to limit the two components to only translate along the z-axis.
9. The method according to any one of claims 1 to 5, characterized in that, In the case that the target motion pair type is a cylindrical pair, the pre-defined basic constraint set in the mapping library includes: The z-axis coincidence constraint of the two connector elements, the distance constraint of the origin of the two connector elements in the direction perpendicular to the z-axis, and the x-axis angle constraint of the two connector elements, to allow the two components to translate along the z-axis and rotate around the z-axis.
10. The method according to any one of claims 1 to 5, characterized in that, In the case that the target motion pair type is a rotating pair, the pre-defined basic constraint set in the mapping library includes: The z-axis coincidence constraint of the two connector elements, the origin coincidence constraint of the two connector elements, and the x-axis angle constraint of the two connector elements, to limit the two components to only rotate around the z-axis.
11. The method according to any one of claims 1 to 5, characterized in that, In the case that the target motion pair type is a parallel pair, the pre-defined basic constraint set in the mapping library includes: The z-axis parallel constraint of the two connector elements, the distance constraint of the origin of the two connector elements in the z-axis direction, the distance constraint of the origin of the two connector elements in the x-axis direction, the distance constraint of the origin of the two connector elements in the y-axis direction, and the x-axis angle constraint of the two connector elements, to allow the two components to rotate along the z-axis and translate along the x-axis, y-axis or z-axis.
12. The method according to any one of claims 1 to 5, characterized in that, In the case that the target motion pair type is a slot pair, the pre-defined basic constraint set in the mapping library includes: A z-axis parallel constraint of the two connector elements, a distance constraint of the two connector elements, a constraint that the origins of the two connector elements coincide with the x-axis, an x-axis angle constraint of the two connector elements, to allow the two components to rotate along the z-axis and to translate along the x-axis.
13. The method according to any one of claims 1 to 5, characterized in that, In a case where the target kinematic pair type is a gear pair, the predefined basic constraint set in the mapping library comprises: A rotation axis parallel constraint of the two kinematic pair constraints, a constraint that a ratio of an angle parameter of the first kinematic pair constraint to an angle parameter of the second kinematic pair constraint is equal to a set ratio, to achieve a gear transmission relationship.
14. The method according to any one of claims 1 to 5, characterized in that, In a case where the target kinematic pair type is a planar pair, the predefined basic constraint set in the mapping library comprises: A z-axis parallel constraint of the two connector elements, a constraint that the origins of the two connector elements coincide in the z-axis direction, a distance constraint of the origins of the two connector elements in the x-axis direction, a distance constraint of the origins of the two connector elements in the y-axis direction, and an x-axis angle constraint of the two connector elements, to allow the two components to rotate along the z-axis and to translate along the x-axis or the y-axis.
15. A geometric constraint engine, characterized by, Comprise: An application layer, configured to provide an interactive interface to receive a target kinematic pair type of a kinematic pair constraint input by a user, component information participating in motion, and kinematic pair parameters; An engine layer connected to the application layer, configured to determine, based on a local coordinate system of a connector element generated in advance, effective information of the kinematic pair constraint, the effective information comprising an effective position determined by an origin coordinate of the connector element and an effective direction determined by a z-axis direction vector of the connector element; A kernel layer connected to the application layer and the engine layer, configured to receive the target kinematic pair type, the component information, and the kinematic pair parameters transmitted by the application layer, and receive the effective information transmitted by the engine layer; Call a mapping library of pre-built kinematic pair types and basic constraint combinations to automatically generate a corresponding basic constraint set according to the target kinematic pair type and the effective information; The kernel layer is further configured to read the kinematic pair parameters, set values of basic dimension constraints in the basic constraint set, and call a constraint solver to solve the basic constraint set, and output a simulation result of the kinematic pair constraint.