massMatrix and inverseDynamics are something wrong....( Am I using wrong?)

I've tested it by simple 2 DOF arm.

Then, I think massMatrix and inverseDynamics have some bugs..

In a 2 DOF arm, massMatrix gave me wrong inertia matrix...

(each length 1 [m], CoM : 0.5 [m], I = 0....... dynamics equations are already provided in the robotics textbook.)

InverseDynamics : summing inertia torque and coriolis torque and gravity torque may be something mistakes. Moreover, I can not believe calculated inertia torque values.

I am wondering if everyone is using mathworks's robot dynamics functions without problems.

Related documents need to be presented in more detail.

[Carlos Santacruz]

Hi Sehun,

I am using the robot dynamics functions and I haven't experienced any issues. If the values of the massMatrix and inverseDynamics are not what you expect based on textbook formulas, it might be related to the inertia values that you are specifying for each link. The rigid body expects the inertia tensor relative to the body frame of the link as mentioned here:

https://www.mathworks.com/help/robotics/ref/rigidbody.html

However, most robotics texbooks formulas use inertia tensors relative to the center of mass of the link.

For example, in the URDF you also specify the inertia tensors relative to the center of mass but the importrobot function converts the inertia to the body frame so you don't have to worry about this.

However, if you create the rigid body tree manually, you need to make sure that the inertia you assign to the rigidbody is relative to the body frame.

If this doesn't resolve your issue, it would be helpful if you can post the example.

Cheers,

Carlos

[Taishin Chung]

Hi Sehun,

Even if I agree with most of what Carlos mentioned, I still have found some problems in massMatrix.

After 'robot=importrobot('TwoLink.urdf',"urdf")' convert the inertia to the body attached frame, I found robot.massMatrix() function still using the inertia relative to center of mass rather than to the body attached frame, 'robot.Bodies{1,i+1}.Inertia'.

Using Solidworks and its urdf-export add-on which gives the moments of inertia both relative to the center of mass and to the body attached frame, I could verify this problem.

I wonder about others' opinions

with regards,

Taishin

Answer 1

[Boris Blagojevic]

Hello Sehun,

i encountered a similiar problem. The Mass Matrix of a 5-DoF Robot, calculated with Lagrange and Newton-Euler manually, doesn't match the result of the built-in massMatrix function. It appears to have a constant offset for all joint configurations for some entries, while others are equal to the analytically derived values.

Gravity Torque and Velocity Product seem to be fine at least.

This is a serious problem with the ROS-Toolbox and requires a response from the staff, if you ask me. I won't trust this Toolbox any longer, until this issue is fixed.

Greetings

BB

[Sajjad Monfared]

Hi Boris,

I experienced similar issue with Mass Matrix having offset for some entries in the matrix for a high-DOF robot. I modeled the robot in multibody environment and exported it as a rigidBodyTree object. After examining the robot properties, it turned out that in robotics toolbox the inertia tensor is computed with respect to body frame rather than center of mass frame which causes an offset when traslating inertia tensor between the two frames.

Just make sure you are defining inertial properites of the robot in accordance with the toolbox conventions.

Best,

Sajjad