Construction method for mechanical arm kinematics model adaptive to multiple types of algorithms

Abstract

The invention relates to a construction method of a mechanical arm kinematics model adapted to various algorithms, the model and a mechanical arm motion determination method. The construction method comprises the following steps: analyzing a URDF file of a mechanical arm to obtain a father-son connection relationship between mechanical arm connecting rods and a DH parameter between each pair of adjacent connecting rods; a model presentation layer of the mechanical arm kinematics model is constructed according to the father-child connection relation and the DH parameters, and a model access interface is configured for the model presentation layer; packaging different kinematics algorithm libraries into different back-end adapters, configuring a unified calling interface for the different back-end adapters, and calling the different back-end adapters through the calling interface; wherein different back-end adapters inherit the same abstract base class; each back-end adapter is further configured to obtain kinematic parameters of the robotic arm through the model access interface. Therefore, decoupling of the model and the algorithm library can be realized, different kinematics algorithm libraries can be called through a unified interface, and the different algorithm libraries can exert respective advantages.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of robots, and particularly to a construction method of a kinematic model of a robot arm for adapting to multiple algorithms. BACKGROUND

[0002] The kinematic model of a robot arm is the basis for realizing functions such as trajectory planning and pose control of the robot arm.

[0003] The existing kinematic model of a robot arm can be realized by using multiple algorithm libraries, but the existing algorithm libraries are often developed for specific robot models, that is, the specific algorithms are tightly coupled to the specific robot models, resulting in poor code reusability and the need to rewrite a large amount of code when the algorithm library is replaced or the robot model is replaced. In addition, different algorithm libraries have their own advantages, but because the algorithms are tightly coupled to the specific robot models, users cannot flexibly switch to select different algorithm libraries according to task requirements. Furthermore, the kinematic model of a robot arm is often described by using a URDF file, but the URDF file does not directly provide DH parameters, which need to be manually derived before being used in subsequent algorithms. This manual derivation of DH parameters is inefficient and has a high error rate. SUMMARY

[0004] In view of the above problems of the prior art, the present application provides a construction method of a kinematic model of a robot arm for adapting to multiple algorithms, which realizes decoupling of the algorithm library and the specific robot model, thereby improving the code reusability and enabling users to flexibly select different algorithm libraries according to requirements. In addition, the DH parameters can be automatically extracted from the URDF file.

[0005] To achieve the above object, the first aspect of the present application provides a construction method of a kinematic model of a robot arm for adapting to multiple algorithms, comprising: parsing a URDF file of a robot arm to obtain parent-child connection relationships between links of the robot arm and DH parameters between each pair of adjacent links; constructing a model representation layer of the kinematic model of the robot arm according to the parent-child connection relationships between the links of the robot arm and the DH parameters between each pair of adjacent links, and configuring a model access interface for the model representation layer; encapsulating different kinematic algorithm libraries as different backend adapters, configuring a uniform calling interface for the different backend adapters, and calling the different backend adapters through the calling interface; wherein the different backend adapters inherit the same abstract base class; each backend adapter is further configured to obtain kinematic parameters of the robot arm from the model representation layer through the model access interface.

[0006] From the above, different algorithm libraries encapsulated by different backend adapters can be flexibly called by a user through the calling interface, and required data can be obtained from the model representation layer through the access interface, and based on the setting of the calling interface and the access interface, the decoupling of the specific algorithm library and the upper layer is realized, so that the code reuse rate can be improved. In addition, the DH parameters are obtained by automatically parsing the URDF file, and manual derivation is not required, thereby improving the efficiency and accuracy.

[0007] As an implementation form of the first aspect, the model representation layer is constructed according to the parent-child connection relationship between the links of the robot arm and the DH parameters between each pair of adjacent links, and includes: constructing a topological structure tree of the robot arm according to the parent-child connection relationship between the links, the topological structure tree being used to represent a kinematic chain of the robot arm, and each node of the topological structure tree storing parameter information of a corresponding link, the parameter information including at least one of: a local coordinate of the link, a geometric feature of the link, a mass of the link, and an inertia tensor of the link; and storing the DH parameters between each pair of adjacent links, initial values of the joints, and motion ranges of the joints in a unified format data structure to construct a set of kinematic parameters.

[0008] As an implementation form of the first aspect, the model representation layer is configured with a model access interface, including at least one of: the model representation layer is configured with an access interface for obtaining any one or more parameters in the topological structure tree; the model representation layer is configured with an access interface for obtaining any one or more parameters in the set of kinematic parameters; and the model representation layer is configured with an access interface for obtaining any one or more parameters in the topological structure tree or the set of kinematic parameters that are updated.

[0009] From the above, the parent-child connection relationship between the links is stored in the topological structure tree with a unified structure, the kinematic-related parameters are stored in the set of kinematic parameters, and respective access interfaces are set, so that the algorithm can obtain corresponding data as needed.

[0010] As an implementation form of the first aspect, the abstract base class includes a calling interface of at least one of: a first calling interface configured to perform forward kinematics calculation on the robot arm, the forward kinematics calculation being to determine an end pose of the robot arm according to joint parameters of the robot arm; a second calling interface configured to perform inverse kinematics calculation on the robot arm, the inverse kinematics calculation being to determine a plurality of feasible joint parameter solutions according to a target pose of the robot arm; and a third calling interface configured to perform Jacobian matrix calculation on the robot arm, the Jacobian matrix calculation being to determine a Jacobian matrix of the robot arm according to the joint parameters of the robot arm.

[0011] As an implementation form of the first aspect, the different backend adapters inherit the same abstract base class, including that the different backend adapters implement the first calling interface, the second calling interface and the third calling interface.

[0012] From the above, the above three calling interfaces almost cover the calculations commonly used in the kinematics calculation of the robot arm, and by making different algorithms implement the above interfaces, a basis is provided for decoupling the algorithms from specific models.

[0013] As an implementation form of the first aspect, the backend adapters include: a symbolic calculation type backend adapter configured to perform motion calculation of the robot arm based on a symbolic algorithm library of a robot arm kinematics model; and a numerical calculation type adapter configured to perform motion calculation of the robot arm based on a numerical algorithm library of the robot arm kinematics model.

[0014] As an implementation form of the first aspect, further including: verifying the DH parameters between each pair of adjacent links by at least one of the following: comparing the number of joints in the DH parameters and the number of degrees of freedom of the robot arm, comparing the joint types of the DH parameters and the joint types in the URDF file, and if the number is equal and the types are the same, this verification is passed; constructing a robot arm motion model based on the DH parameters, determining a zero position pose of the robot arm based on the robot arm motion model, comparing the zero position pose with a zero position pose in the URDF file, and if the Euclidean distance between the two is less than a first preset threshold, this verification is passed; rendering the robot arm motion model constructed based on the DH parameters and the original robot arm motion model based on the URDF file side by side in a three-dimensional simulation environment, and determining the structural difference between the two, and if the structural difference between the two is less than a second preset threshold, this verification is passed.

[0015] From the above, by verifying the extracted DH parameters, the accuracy of the DH parameters can be ensured.

[0016] As an implementation form of the first aspect, further including: generating a simulation model for kinematics verification in a physical simulation environment based on the URDF file; inputting the same kinematics calculation parameters into the simulation model for kinematics verification and the robot arm kinematics model for adapting to multiple algorithms respectively, and obtaining first output data of the simulation model for kinematics verification and second output data of the robot arm kinematics model for adapting to multiple algorithms; comparing the difference between the first output data and the second output data, and displaying the difference or generating a simulation verification report based on the difference.

[0017] From the above, by verifying the constructed model, the visual error of the model can be obtained, which is convenient for adjustment.

[0018] The second aspect of the present application provides a kinematics model of a robot arm for adapting a multi-class algorithm, the model being constructed by the method of any one of the first aspect, the model comprising: a calling interface, the calling interface being used to call different backend adapters, the different backend adapters encapsulating different kinematics algorithm libraries, the different backend adapters inheriting the same abstract base class; a model access interface of a model representation layer, the backend adapters obtaining kinematics parameters of the robot arm from the model representation layer through the model access interface; wherein the model representation layer is constructed based on parent-child connection relationships between robot arm links and DH parameters between each pair of adjacent links, the parent-child connection relationships between the robot arm links and the DH parameters between each pair of adjacent links being obtained based on parsing of a URDF file of the robot arm.

[0019] The beneficial effects of the present aspect can be seen from the descriptions of the beneficial effects of the respective parts of the first aspect.

[0020] The third aspect of the present application provides a method for determining robot arm movement based on the kinematics model of the robot arm of the second aspect, the method comprising: in response to selection of a target backend adapter and a target calculation method, activating the target backend adapter and calling the target calculation method through the calling interface; in response to calling of the target backend adapter, obtaining kinematics parameters of the robot arm from the model representation layer through the model access interface; and determining, by the target backend adapter, a kinematics result corresponding to the target calculation method based on the target calculation method and the kinematics parameters of the robot arm.

[0021] The beneficial effects of the present aspect can also be seen from the descriptions of the beneficial effects of the respective parts of the first aspect.

[0022] The fourth aspect of the present application provides a computing device, comprising: at least one processor; and at least one memory connected with the processor and storing program instructions, the program instructions causing the at least one processor to perform the method of any one of the first aspect or the third aspect when executed by the at least one processor.

[0023] The beneficial effects of the present aspect can be seen from the descriptions of the beneficial effects of the respective parts of the first aspect.

[0024] The fifth aspect of the present application provides a computer-readable storage medium having program instructions stored thereon, the program instructions causing the computer to perform the method of any one of the first aspect or the third aspect when executed by the computer.

[0025] The beneficial effects of the present aspect can also be seen from the descriptions of the beneficial effects of the respective parts of the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0026] Various technical features of the present application and relationships between them will be further illustrated below with reference to the accompanying drawings. The accompanying drawings are exemplary, some technical features are not shown in actual proportion, and some technical features in the drawings can be omitted, which are conventional in the technical field to which the present application belongs and are not essential for understanding and implementing the present application, or additional technical features are shown, which are not essential for understanding and implementing the present application. That is, the combination of various technical features shown in the drawings is not intended to limit the present application. In addition, throughout the present application, the same reference signs refer to the same contents. The specific drawings are as follows:

[0027] Figure 1 A first flowchart of a construction method of a kinematic model of a robot arm for adapting to multiple algorithms provided by an embodiment of the present application;

[0028] Figure 2 A second flowchart of a construction method of a kinematic model of a robot arm for adapting to multiple algorithms provided by an embodiment of the present application;

[0029] Figure 3 A structural schematic diagram of a construction device of a kinematic model of a robot arm for adapting to multiple algorithms provided by an embodiment of the present application;

[0030] Figure 4 A structural schematic diagram of a computing device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0031] The technical solutions provided by the present application will be further described below in combination with the drawings and embodiments. It should be understood that the solutions provided in the embodiments of the present application are mainly to illustrate possible implementation manners of the technical solutions of the present application, and should not be interpreted as the only limitation of the technical solutions of the present application. Those skilled in the art can know that the technical solutions provided by the present application are also applicable to similar technical problems as the system structure and method evolve.

[0032] It should be understood that the present application provides a solution for adapting a kinematic model of a robot arm to multiple algorithms. Since the principles of these technical solutions for solving problems are the same or similar, in the introduction of the following specific embodiments, some repetitions can not be described again, but should be regarded as mutual reference between these specific embodiments, which can be combined with each other.

[0033] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. If there is any inconsistency, the meaning explained in the specification or derived from the content described in the specification shall prevail. In addition, the terms used herein are only for the purpose of describing the embodiments of the present application, and are not intended to limit the present application.

[0034] In order to accurately describe the technical content in the present application, and in order to accurately understand the present application, before the specific embodiments are described, the following explanations or definitions of the terms used in the specification are given:

[0035] 1) Unified Robot Description Format (URDF): an open-source file format based on XML, used to describe the physical structure of a robot, including links, joints, inertia properties, visual / collision geometry, etc.

[0036] 2) DH Parameters: Denavit-Hartenberg Parameters, sometimes written as D-H Parameters, a standard method to describe the spatial relationship between adjacent links using four standard parameters (link length a, twist angle a, joint offset d, joint angle q). DH parameters are the "mathematical language" of robot kinematics modeling. Through this set of unified parameters, the pose (position and orientation) of each link on the entire kinematic chain from the robot base to the end effector can be calculated. DH parameters include standard DH parameters and improved DH parameters, both of which use the above four standard parameters. The difference is that the coordinate system of the standard DH parameters belongs to the previous link, and the z-axis is aligned with the current joint, while the coordinate system of the improved DH parameters belongs to the current link, and the z-axis is aligned with the current joint.

[0037] 3) Base Kinematics Backend: Kinematics Backend Abstract Base Class, an abstract class defined using object-oriented programming (such as ABC in Python), which defines the unified interface that all kinematics algorithm backends must implement.

[0038] 4) Forward Kinematics: Forward Kinematics function, given all joint vectors of the robot arm, calculate the pose of the end effector in Cartesian space.

[0039] 5) Inverse Kinematics: Inverse Kinematics function, given the target pose of the end effector, solve one or more sets of joint variables that satisfy the pose.

[0040] 6) Jacobian: Jacobian matrix, a matrix that describes the linear mapping relationship between joint velocity and end effector velocity in Cartesian space.

[0041] 7) **kwargs: keyword arguments, in Python function definition, **kwargs allows a function to receive a dictionary of arbitrary length, containing those keyword arguments that are not explicitly defined in the function signature, providing great flexibility, different algorithm libraries have their own specific parameters (for example, the number of iterations max_iter, tolerance tolerance, whether to enable collision detection collision_check). Through **kwargs, the unified API interface can pass these "algorithm-specific parameters" to the underlying specific library without modifying the interface itself.

[0042] 8) CasADi Adapter: CasADi Adapter, a class that specifically implements the Base Kinematics Backend interface, which internally uses the CasADi library for calculation, constructs the kinematics problem as a symbolic optimization problem, and solves it using a nonlinear solver. The advantage is high accuracy, easy to add complex constraints, and very suitable for trajectory optimization and offline calculation. In this application, the CasADi adapter is a kind of symbolic calculation backend. When the user selects this adapter, the system will use the powerful symbolic calculation and optimization capabilities of CasADi to solve the kinematics problem.

[0043] 9) PyRoboPlan Adapter: PyRoboPlan Adapter, a class that specifically implements the Base Kinematics Backend interface, which internally uses the PyRoboPlan library for calculation, which provides high-speed numerical calculation, usually using numerical iterative methods (such as damped least squares) to solve, the calculation speed is extremely fast, can reach milliseconds or even microseconds, suitable for real-time control and motion planning.

[0044] 10) Pinocchio Adapter: Pinocchio Adapter, a class that specifically implements the Base Kinematics Backend interface, which internally uses the Pinocchio library for calculation, Pinocchio is known for its fast C++ kernel, like the PyRoboPlan adapter, it also provides high-speed numerical calculation, the calculation speed is extremely fast, can reach milliseconds or even microseconds, suitable for real-time control and motion planning.

[0045] 11) SpatialMath Adapter: SpatialMath Adapter, a class that implements the BaseKinematics Backend interface, is an adapter based on Peter Corke's SpatialMath (originally Robotics Toolbox for Python) library, providing classic and mature algorithm implementations, commonly used in education, research and prototyping development.

[0046] 12) Robotics Toolbox Adapter: Robotics Toolbox Adapter, a class that implements the BaseKinematics Backend interface, usually refers to the encapsulation of MATLAB or Python version of Robotics Toolbox, providing rich kinematics, dynamics and visualization tools, widely used in academic research.

[0047] 13) MuJoCo: It is a high-performance physics simulation engine. In this embodiment, the URDF model is loaded in the MuJoCo simulation environment, and its kinematics output is automatically extracted, which is used to automatically compare the calculation results of the unified kinematics model with the high-fidelity simulation results of MuJoCo, realizing closed-loop verification.

[0048] 14) Joint properties: that is, the type of joint, generally including rotary joints, translational joints, fixed joints, etc.

[0049] 15) Joint motion range: for non-fixed joints, the upper and lower limits of the position (angle or displacement) motion.

[0050] 16) Joint rotation axis direction: that is, the reference direction vector of joint rotation or translation.

[0051] 17) Initial value of joint: that is, the pose of the joint at zero position. For rotary joints, the initial value is an angle, usually in radians. For translational joints, the initial value is a displacement, usually in meters.

[0052] 18) Local coordinates of the link: the Cartesian coordinate system fixed to each link of the robot, usually at the center of mass or geometric center of the link.

[0053] 19) Collision model: a simplified geometric model for collision detection, commonly used for collision detection in motion planning.

[0054] 20) Homogeneous transformation matrix: is the core mathematical object in robot kinematics, which is a 4×4 real matrix, which completely describes the pose (position + attitude) of the end effector of the robot arm relative to the base under the current joint configuration.

[0055] A method for constructing a kinematics model of a robot arm for adapting to multiple algorithms is provided in the embodiment, and will be described in detail below with reference to the accompanying drawings. As shown in Figure 1 and Figure 2 , the method comprises steps S110-S130, and specifically:

[0056] S110: parsing a URDF file of the robot arm to obtain a parent-child connection relationship between links of the robot arm and DH parameters between each pair of adjacent links.

[0057] In the embodiment, the URDF file of the robot arm is automatically loaded and parsed to obtain at least the parent-child connection relationship between the links and the DH parameters between each pair of adjacent links. Here, the obtained DH parameters can be standard DH parameters or improved DH parameters. In some embodiments, by automatically loading and parsing the URDF file of the robot arm, the properties of the joints, the joint motion ranges, the rotational axis directions of the joints, the shapes of the links, the masses of the links, the centers of mass of the links, the inertia tensors of the links, the local coordinates of the links, the collision models, etc. can also be obtained.

[0058] In some embodiments, in order to ensure the accuracy of the DH parameters obtained by automatic parsing, the following three verification mechanisms can be set, that is, the following methods can be used to verify whether the obtained DH parameters are accurate:

[0059] The first is to verify the structural consistency of the DH parameters: compare whether the number of joints in the DH parameters and the number of degrees of freedom of the robot arm are the same, and compare whether the joint types (i.e., joint properties) in the DH parameters and the original defined joint types in the URDF file are the same. If the number of joints and the number of degrees of freedom of the robot arm are the same and the joint types in the DH parameters and the original defined joint types in the URDF file are the same, it is considered that the structural consistency is met, and this verification is passed.

[0060] The second is to verify the kinematic closed loop: based on the DH parameters obtained by parsing, a robot arm motion model is reconstructed and a zero position pose (i.e., a default pose) of the robot arm is determined based on the model. The zero position pose is compared with the zero position pose in the URDF file, and the Euclidean distance between them is calculated. If the Euclidean distance between them is less than a first preset threshold, it is considered that the kinematic closed loop verification is met, and this verification is passed. Wherein, the first preset threshold is generally less than .

[0061] The third item is visual verification: render the reconstructed manipulator motion model based on the DH parameters and the original manipulator motion model based on the URDF file side by side in a three-dimensional simulation environment, and compare the structural differences between the two, such as comparing the differences in local coordinates of the joints, superimposing the geometric shapes of the links to compare the differences, and synchronously playing back the motion trajectories of the two to compare the differences, so that the differences between the two can be determined intuitively. If the structural difference between the two is less than the second preset threshold, it is considered that this item is verified. It should be understood that since there are many parameters that can be intuitively compared, the user can choose one or multiple quantities to compare. Different parameters correspond to different second preset thresholds, and therefore the second preset threshold is set according to the specific parameters, and the specific value is not limited here.

[0062] S120: Construct a model representation layer of the kinematics model of the manipulator according to the parent-child connection relationship between the links of the manipulator and the DH parameters between each pair of adjacent links, and configure a model access interface for the model representation layer.

[0063] In some embodiments, the DH parameters used to construct the model representation layer of the kinematics model of the manipulator can be the DH parameters automatically parsed from the URDF file. In other embodiments, the DH parameters used can also be data verified by the above three verification mechanisms, so as to ensure the accuracy of the DH parameters.

[0064] In this embodiment, the model representation layer is independent of specific backend algorithms, and can realize complete decoupling of the backend algorithms and the model through encapsulation of structured data. Specifically, the model representation layer is formed by uniformly integrating various heterogeneous parameters parsed from the URDF file (see the introduction of step S110). More specifically:

[0065] Construct a topological structure tree: construct a topological structure tree of the manipulator according to the parent-child connection relationship between the links, which is used to represent the kinematic chain structure of the manipulator and can support various expressions such as series, parallel, and hybrid configurations. In the topological structure tree, each node stores parameter information of the corresponding link, which can include local coordinates of the link, geometric characteristics of the link, mass of the link, inertia tensor of the link, etc. The above link parameter information is parsed from the URDF file.

[0066] Construct a kinematics parameter set: store the DH parameters, initial values of the joints (i.e., the pose at zero position), and the motion range of the joints through a unified format data structure, so as to realize the normalized description of these parameters. The kinematics parameter set is used to store the kinematics data of the manipulator.

[0067] Configure a model access interface for the model representation layer, which includes:

[0068] An access interface for obtaining any one or more parameters in the topology tree. For example, the topology relationship in the topology tree can be obtained through get_kinematic_chain().

[0069] An access interface for obtaining any one or more parameters in the kinematics parameter set. For example, the movement range of a specified joint in the kinematics parameter set can be obtained through get_joint_limits(joint_id).

[0070] An access interface for updating any one or more parameters in the topology tree or the kinematics parameter set. For example, the updated parameters can be obtained through update_dynamic_params(), such as the updated parameters when the mass, center of mass, or inertia tensor of the robot arm changes.

[0071] An interface for obtaining the homogeneous transformation matrix under the current configuration, which needs to obtain data from the topology tree and the kinematics parameter set to generate the homogeneous transformation matrix.

[0072] In this embodiment, the specific robot arm data is encapsulated into the topology tree and the kinematics parameter set through a unified structure, and a calling interface is set to directly call the required data, thereby completely eliminating the dependence on specific algorithm libraries.

[0073] S130: encapsulate different kinematics algorithm libraries as different backend adapters, and configure a unified calling interface for different backend adapters, and call different backend adapters through the calling interface; wherein the different backend adapters inherit the same abstract base class; each backend adapter is further configured to obtain the kinematics parameters of the robot arm from the model representation layer through the model access interface.

[0074] In this embodiment, a group of abstract base classes (Base Kinematics Backend) are defined, which specify that all backend adapters must inherit the abstract base class and implement a unified interface. In this embodiment, the abstract base class specifically defines the following calling interfaces (API interfaces in this embodiment):

[0075] The first calling interface is configured to perform forward kinematics calculation on the robot arm, and determines the pose of the robot arm end effector in the Cartesian space by receiving a joint angle vector or list. Through forward kinematics calculation, the mapping relationship from the joint space to the Cartesian space of the robot arm can be realized.

[0076] Second calling interface: configured to perform inverse kinematics calculation on the robot arm, and determine a plurality of feasible joint parameter solutions by receiving a target pose. In the inverse kinematics calculation, an initial joint angle guess can also be input, which refers to a set of starting joint variable values in the inverse kinematics solving process, used to guide the numerical iteration or optimization algorithm to search for a feasible solution satisfying the target pose from a reasonable starting point. The extended parameters **kwargs of the algorithm can also be input, thereby specifying the number of iterations, tolerance threshold, etc.

[0077] Third calling interface: configured to perform Jacobian calculation on the robot arm, and determine the linear mapping relationship (i.e., Jacobian matrix) between joint speed and end effector speed in Cartesian space by receiving joint parameters of the robot arm.

[0078] In the embodiment, different backend adapters need to implement the above three angle interfaces (the first calling interface, the second calling interface and the third calling interface).

[0079] The backend adapters in the embodiment can include symbolic computation type backend adapters and numerical computation type adapters. The symbolic computation type backend adapters are used to perform motion calculation of the robot arm based on a symbolic algorithm library of a robot arm kinematics model, such as a CasADi adapter. The numerical computation type adapters are used to perform motion calculation of the robot arm based on a numerical algorithm library of a robot arm kinematics model, such as a PyRoboPlan adapter and a Pinocchio adapter. In addition, the backend adapters in the embodiment can also include SpatialMath adapters and Robotics Toolbox adapters, which are generally considered to be between the symbolic computation type backend adapters and the numerical computation type adapters, but are more inclined to the numerical computation type adapters.

[0080] In the embodiment, the symbolic computation type backend adapter, taking the CasADi adapter as an example, completes the calculation process by inheriting the above abstract base class (Base Kinematics Backend) and implementing the unified interfaces (the first calling interface, the second calling interface and the third calling interface) defined thereby. The specific calculation process is as follows:

[0081] In the initialization phase, DH parameters are obtained from the model representation layer. Then, symbolic variables in the DH parameters are converted to symbolic variables (e.g., ca.SX type) by calling, for example, _build_symbolic_model, and symbolic expressions of the serial homogeneous transformation matrices from the base to the end effector are automatically generated based on the topology tree of the model representation layer. These expressions collectively form an auto-differentiable efficient computation graph, which is pre-compiled for later use.

[0082] When performing forward kinematics calculation: the CasADi adapter takes joint angles as input parameters and brings them into the pre-compiled forward kinematics computation graph to calculate the corresponding end pose.

[0083] When performing Jacobian matrix calculation: the CasADi adapter takes the derivative of the symbolic expressions of forward kinematics with respect to joint variables to obtain the Jacobian matrix.

[0084] When performing inverse kinematics calculation: the CasADi adapter takes joint symbolic variables as optimization variables, constructs a cost function based on the error between the current pose and the target pose of the end effector of the robot arm, and dynamically adds joint motion range constraints and other conditions through **kwargs. Then, a nonlinear solver such as IPOPT inherited by CasADi is called to solve the problem, thereby outputting a feasible solution.

[0085] In this embodiment, the numerical calculation adapter, taking the PyRoboPlan adapter as an example, completes the calculation process by inheriting the above abstract base class (Base Kinematics Backend) and implementing the defined unified interface (first calling interface, second calling interface, and third calling interface). The specific calculation process is as follows:

[0086] In the initialization phase, the PyRoboPlan adapter obtains DH parameters and other information from the model representation layer. Then, the DH parameters are converted to the form required by PyRoboPlan.

[0087] When performing forward kinematics calculation: the forward kinematics calculation function of PyRoboPlan is called to perform complete forward kinematics calculation using a parallel computing architecture based on spatial vectors, and the end pose is output.

[0088] When performing inverse kinematics calculation: the inverse kinematics calculation function of PyRoboPlan is called, and when the collision detection enable flag is received through **kwargs, the collision detection function is automatically activated, thereby outputting a collision-free feasible solution.

[0089] When performing Jacobian matrix calculation: the Jacobian matrix calculation function of PyRoboPlan is called to calculate the geometric Jacobian matrix of the end effector based on the current joint angles.

[0090] In the embodiment, different backend adapters can be selected through the following interfaces. For example, the backend adapter (such as “CasADi” or “PyRoboPlan”) is dynamically switched through set_backend (); the instance activated by the current backend adapter is called through, for example, forward_kinematics (), which represents the call of the forward kinematics function, and the inverse kinematics function is represented through inverse_kinematics (); and the algorithm-specific parameters can be dynamically input through, for example, **kwargs.

[0091] Based on the above scheme, the user can switch the backend adapter through set_backend (), thereby realizing the isolation from the underlying algorithm library and significantly improving the reusability of the underlying algorithm code.

[0092] In some embodiments, after the construction of the kinematics model of the robot arm adapted to the multi-class algorithm, the model can be simulated and verified, specifically including:

[0093] Based on the URDF file, a simulation model for kinematics verification is generated in the physical simulation environment MuJoCo, the kinematics calculation parameters are input into the simulation model for kinematics verification to obtain first output data, the same kinematics calculation parameters are input into the kinematics model for multi-class algorithm adaptation to obtain second output data, the first output data and the second output data are aligned in the millisecond level of time stamp, thereby obtaining the difference between the two, which can include position error, attitude error, etc. The maximum deviation value or root mean square error value and other quantitative indicators can also be counted, and three-dimensional visualization reports in the form of error heat maps, trajectory overlap comparison animations, etc. The motion trajectories of the two can also be played back synchronously, so that the trajectory offset of the two can be directly displayed.

[0094] Another embodiment of the present application provides a kinematics model of a robot arm adapted to a multi-class algorithm, which is constructed based on the method provided in the above embodiment. Therefore, the embodiment will not repeat the above-mentioned embodiments.

[0095] The model includes a calling interface and a model access interface of the model representation layer.

[0096] The calling interface is used to call different backend adapters, different backend adapters encapsulate different kinematics algorithm libraries, and different backend adapters inherit the same abstract base class, which includes forward kinematics calculation, inverse kinematics calculation, and Jacobian matrix calculation.

[0097] The model access interface of the model representation layer, through which the backend adapter obtains the kinematics parameters of the robot arm from the model representation layer; wherein the model representation layer is constructed based on the parent-child connection relationship between the robot arm links and the DH parameters between each pair of adjacent links, and the parent-child connection relationship between the robot arm links and the DH parameters between each pair of adjacent links are obtained based on the URDF file analysis of the robot arm.

[0098] Another embodiment of the present application also provides a method for determining the movement of a robot arm based on the model in the above embodiment, and the embodiment will not be repeated here.

[0099] The method comprises calling an interface to activate the target backend adapter and call the target calculation method through the calling interface in response to the selection of the target backend adapter and the target calculation method, wherein the target calculation method comprises forward kinematics calculation, inverse kinematics calculation and Jacobian matrix calculation.

[0100] The model access interface obtains the kinematics parameters of the robot arm from the model representation layer through the model access interface in response to the calling of the target backend adapter.

[0101] The target backend adapter determines the kinematics result corresponding to the target calculation method based on the target calculation method and the kinematics parameters of the robot arm.

[0102] Still another embodiment of the present application provides a construction device for adapting the kinematics model of a robot arm to multiple algorithms, and it should be understood that, Figure 3 Only a structured schematic diagram of a construction device for adapting the kinematics model of a robot arm to multiple algorithms is exemplarily shown, and the present application does not limit the division of functional modules in the device. As shown in Figure 3 The construction device 30 for adapting the kinematics model of a robot arm to multiple algorithms can be logically divided into multiple modules, each module can have different functions, and the function of each module is realized by the processor in the computing device reading and executing the instructions in the memory. Exemplarily, the device 30 comprises an analysis module 310, a first construction module 320, and a second construction module 330.

[0103] Specifically, the parsing module 310 is configured to parse a URDF file of a robot arm to obtain parent-child connection relationships between links of the robot arm and DH parameters between each pair of adjacent links; the first construction module 320 is configured to construct a model representation layer of a kinematics model of the robot arm according to the parent-child connection relationships between the links of the robot arm and the DH parameters between each pair of adjacent links, and configure a model access interface for the model representation layer; and the second construction module 330 is configured to encapsulate different kinematics algorithm libraries as different backend adapters, configure a uniform calling interface for the different backend adapters, and call the different backend adapters through the calling interface; wherein the different backend adapters inherit the same abstract base class; and each backend adapter is further configured to obtain kinematics parameters of the robot arm from the model representation layer through the model access interface.

[0104] The specific implementation of each functional module in this embodiment can refer to the description of the above embodiments, and will not be described here.

[0105] Figure 4 is a structural schematic diagram of a computing device 900 provided by an embodiment of the present application. The computing device can execute each optional embodiment of the above method for constructing a kinematics model of a robot arm adapted to multiple types of algorithms. The computing device can be a terminal or a chip or chip system inside the terminal. As shown in the figure, the computing device 900 includes a processor 910, a memory 920, and a communication interface 930. Figure 4

[0106] It should be understood that Figure 4 The communication interface 930 in the computing device 900 shown in the figure can be used for communication between other devices, and can specifically include one or more transceiver circuits or interface circuits.

[0107] The processor 910 can be connected with the memory 920. The memory 920 can be used to store program codes and data. Therefore, the memory 920 can be a storage unit inside the processor 910, or an external storage unit independent of the processor 910, or a component including the storage unit inside the processor 910 and the external storage unit independent of the processor 910.

[0108] ​Optionally, the computing device 900 can also include a bus. The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be a proprietary bus, etc. The bus can be a combination of buses. The bus can be a set of buses. The bus can be a single bus. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 A line without arrows is used in the figure to represent a bus, but it does not mean that there is only one bus or only one type of bus.

[0109] It should be understood that the processor 910 can be a central processing unit (CPU) in the embodiments of the present application. The processor can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. Alternatively, the processor 910 can be one or more integrated circuits for executing relevant programs to implement the technical solutions provided by the embodiments of the present application.

[0110] The memory 920 can include read-only memory and random access memory, and provide instructions and data to the processor 910. A part of the processor 910 can also include non-volatile random access memory. For example, the processor 910 can also store device type information.

[0111] When the computing device 900 is running, the processor 910 executes computer-executable instructions in the memory 920 to perform any of the operation steps of the above method and any optional embodiments thereof.

[0112] It should be understood that the computing device 900 according to the embodiments of the present application can correspond to a subject performing the corresponding method according to the embodiments of the present application, and the above and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding flow of each method of the embodiments, and for brevity, will not be repeated here.

[0113] Those skilled in the art can clearly understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0114] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the above-described system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

[0115] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other ways. For example, the above-described device embodiments are only schematic, for example, the division of the units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0116] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0117] In addition, each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically independently, or two or more units can be integrated into one unit.

[0118] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the parts that make contributions to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program code storage media.

[0119] The embodiments of the present application also provide a computer readable storage medium, which stores a computer program. The program is executed by a processor to perform the above method, which includes at least one of the schemes described in the above embodiments.

[0120] The computer storage medium of the embodiments of the present application can adopt any combination of one or more computer readable media. The computer readable medium can be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination of the above. More specific examples (non-exhaustive list) of the computer readable storage medium include: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or apparatus.

[0121] The computer readable signal medium can include a data signal propagated in a baseband or as a part of a carrier wave, in which a computer readable program code is borne. Such a propagated data signal can take various forms, including but not limited to an electromagnetic signal, an optical signal or any suitable combination of the above. The computer readable signal medium can also be any computer readable medium other than the computer readable storage medium, which can send, propagate or transmit a program for use by or in conjunction with an instruction execution system, device or apparatus.

[0122] The program code embodied on the computer readable media can be transmitted using any appropriate medium, including, but not limited to, wireless, wire line, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0123] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0124] It is noted that the foregoing has been a detailed description of a few embodiments of the application. Accordingly, the application is not limited to that in the above description but instead encompasses all alternatives falling within the scope of the application.

Claims

1. A method for constructing a kinematic model of a robotic arm for adapting to multiple algorithms, characterized in that, include: Parse the URDF file of the robotic arm to obtain the parent-child connection relationship between the links of the robotic arm and the DH parameters between each pair of adjacent links; The model representation layer of the robotic arm kinematics model is constructed based on the parent-child connection relationship between the links of the robotic arm and the DH parameters between each pair of adjacent links, and a model access interface is configured for the model representation layer. Different kinematics algorithm libraries are encapsulated as different backend adapters, and a unified calling interface is configured for different backend adapters. Different backend adapters are called through the calling interface. The different backend adapters inherit from the same abstract base class. Each backend adapter is also configured to obtain the kinematic parameters of the robotic arm from the model representation layer through the model access interface.

2. The method according to claim 1, characterized in that, The model representation layer, which constructs the kinematic model of the robotic arm based on the parent-child connection relationship between the links and the DH parameters between each pair of adjacent links, includes: A topology structure tree for the robotic arm is constructed based on the parent-child connection relationship between the links. The topology structure tree is used to represent the kinematic chain of the robotic arm. Each node of the topology structure tree stores the parameter information of the corresponding link. The parameter information includes at least one of the following: local coordinates of the link, geometric features of the link, mass of the link, and inertia tensor of the link. The DH parameters, initial values ​​of the joints, and range of motion of the joints between each pair of adjacent links are stored in a unified data structure to construct a set of kinematic parameters.

3. The method according to claim 2, characterized in that, Configuring a model access interface for the model representation layer includes at least one of the following: Configure the model representation layer with an access interface for obtaining any one or more parameters in the topology structure tree; Configure the model representation layer with an access interface for obtaining any one or more parameters from the kinematic parameter set; Configure the model representation layer with an access interface for obtaining any one or more parameters of the updated topology structure tree or kinematic parameter set.

4. The method according to claim 1, characterized in that, The abstract base class includes at least one of the following calling interfaces: The first calling interface is configured to perform positive kinematics calculations on the robotic arm, wherein the positive kinematics calculations determine the end-effector pose of the robotic arm based on the joint parameters of the robotic arm. The second calling interface is configured to perform inverse kinematics calculations on the robotic arm, wherein the inverse kinematics calculations are to determine multiple sets of feasible joint parameter solutions based on the target pose of the robotic arm. The third calling interface is configured to perform Jacobian matrix calculation on the robotic arm, wherein the Jacobian matrix calculation is to determine the Jacobian matrix of the robotic arm based on the joint parameters of the robotic arm.

5. The method according to claim 4, characterized in that, The different backend adapters inherit from the same abstract base class, including: The different backend adapters all implement the first calling interface, the second calling interface, and the third calling interface.

6. The method according to claim 4, characterized in that, The backend adapter includes: A symbolic computation backend adapter for performing motion calculations on the robotic arm based on a symbolic algorithm library using the robotic arm's kinematic model; and A numerical computation adapter for performing motion calculations on robotic arms based on a numerical algorithm library that uses the robotic arm's kinematic model.

7. The method according to claim 1, characterized in that, Also includes: Verify at least one of the following for the DH parameters between each pair of adjacent links: Compare the number of joints in the DH parameters with the number of degrees of freedom of the robotic arm, and compare the joint types in the DH parameters with the joint types in the URDF file. If the number of joints is equal and the types are the same, then the verification passes. A robotic arm motion model is constructed based on the DH parameters. The zero-position pose of the robotic arm is determined based on the robotic arm motion model. The zero-position pose is compared with the zero-position pose in the URDF file. If the Euclidean distance between the two is less than a first preset threshold, the verification is passed. In a 3D simulation environment, the robotic arm motion model constructed based on the DH parameters and the original robotic arm motion model based on the URDF file are rendered side by side, and the structural differences between the two are determined. If the structural differences between the two are less than a second preset threshold, the verification is successful.

8. The method according to claim 1, characterized in that, Also includes: A simulation model for kinematic verification is generated in a physical simulation environment based on the URDF file. The same kinematic calculation parameters are input into the simulation model used for kinematic verification and the robotic arm kinematic model used for adapting to multiple algorithms, respectively, and the first output data of the simulation model used for kinematic verification and the second output data of the robotic arm kinematic model used for adapting to multiple algorithms are obtained. Compare the differences between the first output data and the second output data, and display the differences or generate a simulation verification report based on the differences.

9. A kinematic model for a robotic arm adapted to multiple algorithms, said model being constructed using the method described in any one of claims 1-8, characterized in that, The model includes: The interface is used to call different backend adapters, which encapsulate different kinematics algorithm libraries and inherit from the same abstract base class. The model representation layer has a model access interface, through which the backend adapter obtains the kinematic parameters of the robotic arm from the model representation layer. The model representation layer is constructed based on the parent-child connection relationship between the robotic arm links and the DH parameters between each pair of adjacent links. The parent-child connection relationship between the robotic arm links and the DH parameters between each pair of adjacent links are obtained by parsing the URDF file of the robotic arm.

10. A method for determining the motion of a robotic arm based on the kinematic model of the robotic arm as described in claim 9, characterized in that, include: The API call responds to the selection of the target backend adapter and the target computation method by activating the target backend adapter and invoking the target computation method through the API call. The model access interface responds to the call of the target backend adapter and obtains the kinematic parameters of the robotic arm from the model representation layer through the model access interface; The target backend adapter determines the kinematic result corresponding to the target calculation method based on the target calculation method and the kinematic parameters of the robotic arm.

11. A computing device, characterized in that, include: At least one processor; And at least one memory connected to the processing and storing program instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any one of claims 1-8 or the method of claim 10.

12. A computer-readable storage medium, characterized in that, It stores program instructions that, when executed by a computer, cause the computer to perform the method described in any one of claims 1-8 or the method described in claim 10.

Images