Clear Filters
Clear Filters

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

8 views (last 30 days)
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.
  2 Comments
Carlos Santacruz
Carlos Santacruz on 22 Jul 2020
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:
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
Taishin Chung on 10 Jul 2022
Edited: Taishin Chung on 10 Jul 2022
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

Sign in to comment.

Answers (1)

Boris Blagojevic
Boris Blagojevic on 22 Jun 2020
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
  1 Comment
Sajjad Monfared
Sajjad Monfared on 1 Dec 2020
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

Sign in to comment.

Products


Release

R2020a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!