Closed sm3304love closed 1 year ago
sm3304love
commented
1 year ago http://hades.mech.northwestern.edu/images/b/b6/UR5-parameters.m
The same thing happened when I used the UR5 parameter provided by Modern Robotics - Northwestern Mechatronics Wiki.
HuanWeng
commented
1 year ago The torque value going positive and negative actually makes sense to me since the arm speeds up (positive accel. required) and slows down (negative accel. required), as the motion trajectory. I see your .fig animation and that confused me because at least it seems like the arm didn't start at the home configuration.
I would suggest checking out the Gazebo simulation, and then the kinematics using your trajectory, and then dynamics.
I can take a look at that function if you still have trouble and have a complete example with all parameters in the code.
sm3304love
commented
1 year ago @HuanWeng
As you said, I used Gazebo Simulation to control the UR10e by giving the Effort command. When the robot was summoned from Gazebo, it could not start from home configuration due to gravity, so I read the joint position data from Gazebo and put it in the initial theta value. The results are shown in the image below.
In my opinion, the calculated torque is too small to move the UR10e.
stevenjj
commented
1 year ago @sm3304love : Instead of using InverseDynamicsTrajectory, I would first use GravityForces(thetalist, g, Mlist, Glist, Slist) with very small PD gains and see if you can hold a joint configuration.
Checking if gravity compensation works first is an easy way to isolate errors.
Also, at the zero configuration, you can easily calculate the expected torque value since you know the center-of-mass locations of all the links. So you will have another way to check for torque consistency.
sm3304love
commented
1 year ago @stevenjj @HuanWeng
As you said, I tried to apply it using GravityForces(thetalist, g, Mlist, Glist, Slist). But still, the UR10e does not resist gravity. If the Effort value is set arbitrarily high, the UR10e will move. Perhaps the torque required by the robot is very large.
But I know that torque -23.0659Nm is by no means a small value. In fact, if I add a torque of -71.077Nm to only the 2nd joint while keeping the torque of the other links at zero, the 2nd joint will move. However, if I give -23.0659Nm to only the 3rd joint, the 3rd joint will not move.
When I checked the coordinate system of UR10e, it was the same as the image below. I understand that the coordinate system of the manipulator generally sets the rotation axis of the motor to the Z axis. Can this be a problem?
Additionally, we checked the joint state when the UR10e was on the floor due to gravity, set it to initial theta position, set the desired theta to [0; 0; 0; 0; 0; 0; 0; 0; 0] and tried InverseDynamicsTrajectory. It still doesn't withstand gravity.
sm3304love
commented
1 year ago I think there was a problem with the Mlist. I don't think it's a problem with Gazebo or code.
Hello. I want to implement the UR10e Force control using InverseDynamicsTrajectory Function. However, I would like to ask you a question because the calculated torque does not seem to be the correct value.
Here is UR10e Dynamcis parameter
UR10e URDF
Slist :
Mlist :
Glist :
And, this is my code
Taumat calculated by the above code
Since only the first joint rotates by pi/2, I think the torque absolute value of the first joint should increase and then decrease. However, the value of the calculated torque is really confusing because it has a value that goes between positive and negative values. can you please help me?