Describe the problem you got
Summary
I may have found a possible inconsistency between the physical OpenArm joint behavior and the URDF definition of openarm_joint1.
In the current URDF/xacro, openarm_joint1 is defined with the following axis:
<joint name="${prefix}joint1" type="revolute">
<xacro:openarm-kinematics name="joint1" config="${kinematics}" reflect="${reflect}"/>
<parent link="${prefix}link0" />
<child link="${prefix}link1" />
<axis xyz="0 0 1" />
<xacro:openarm-limits name="joint1" config="${joint_limits}" offset="${-2.094396 if arm_prefix=='left_' else 0}"/>
</joint>However, on my physical OpenArm, joint 1 appears to be the main shoulder joint used to raise the arm from a hanging-down posture to a forward horizontal posture. In that motion, joint 1 changes the most, while the other joints change only slightly.
Because of this, I expected the gravity torque for joint 1 to be large in such a posture. However, using the current URDF, KDL reports almost zero gravity torque for joint 1.
Environment
ROS 2 Jazzy
OpenArm description package from the current repository
KDL gravity calculation using KDL::ChainDynParam
Gravity vector used in KDL:
KDL::Vector(0, 0.0, -9.81)
Chain:
root_link = "openarm_link0";
leaf_link = "openarm_hand";
Test 1: current URDF
With the current generated URDF, openarm_joint1 has <axis xyz="0 0 1"/>
I moved the physical arm from a hanging-down posture to a forward horizontal posture. In this motion, the physical joint 1 changed the most.
However, the gravity torque logger showed that joint 1 gravity torque was almost zero. For example, in one run, the summary was:
j1 max_abs_grav=8.22453e-17
j2 max_abs_grav=2.35278
j4 max_abs_grav=0.722887
So, even though joint 1 moved significantly, KDL did not assign any meaningful gravity torque to joint 1. The gravity torque appeared mainly in joint 2 and joint 4 instead.
This seems consistent with the current URDF definition, because axis="0 0 1" makes joint 1 rotate around the root Z axis, which is parallel to the gravity direction. Therefore, KDL naturally computes almost zero gravity torque for that joint.
Test 2: temporary diagnostic URDF with joint1 axis="0 1 0"
As a diagnostic test, I modified only the generated URDF temporarily: <axis xyz="0 1 0"/> for openarm_joint1.
Then I repeated the same gravity torque logging experiment.
With this temporary URDF, the gravity torque result looked much more physically plausible:
j1 max_abs_grav=14.7494
j4 max_abs_grav=4.71959
j7 max_abs_grav=0.762434
Around the forward-horizontal posture, the logger showed:
sample=16
j1 q=1.35977 grav=-14.5826 tau_ff=-grav=14.5826
j4 q=0.132944 grav=-4.69974 tau_ff=-grav=4.69974
sample=17
j1 q=1.4456 grav=-14.7494 tau_ff=-grav=14.7494
j4 q=0.110056 grav=-4.71959 tau_ff=-grav=4.71959
This matches the physical intuition much better: the main gravity load appears on the shoulder joint that raises the arm forward, with a secondary load on the elbow.
Questions
Is openarm_joint1 intended to rotate around the Z axis in the current URDF?
If so, could you clarify the intended physical meaning of joint 1? On my hardware, the first joint appears to be the main joint for raising the arm from a hanging-down posture to a forward horizontal posture.
If not, should the axis of openarm_joint1 be something like:
or possibly the opposite sign:
, depending on the coordinate convention?
Why this matters
This affects gravity compensation. With the current URDF, KDL computes almost no gravity compensation torque for joint 1. As a result, gravity compensation based on the current model cannot support the physical joint 1 during forward arm raising.
Using the diagnostic axis="0 1 0" version, the computed gravity torque for joint 1 becomes approximately 15 Nm in the forward-horizontal posture, which seems much more consistent with the physical behavior.
Describe the problem you got
Summary
I may have found a possible inconsistency between the physical OpenArm joint behavior and the URDF definition of
openarm_joint1.In the current URDF/xacro,
openarm_joint1is defined with the following axis:However, on my physical OpenArm, joint 1 appears to be the main shoulder joint used to raise the arm from a hanging-down posture to a forward horizontal posture. In that motion, joint 1 changes the most, while the other joints change only slightly.
Because of this, I expected the gravity torque for joint 1 to be large in such a posture. However, using the current URDF, KDL reports almost zero gravity torque for joint 1.
Environment
ROS 2 Jazzy
OpenArm description package from the current repository
KDL gravity calculation using KDL::ChainDynParam
Gravity vector used in KDL:
KDL::Vector(0, 0.0, -9.81)
Chain:
root_link = "openarm_link0";
leaf_link = "openarm_hand";
Test 1: current URDF
With the current generated URDF, openarm_joint1 has
<axis xyz="0 0 1"/>I moved the physical arm from a hanging-down posture to a forward horizontal posture. In this motion, the physical joint 1 changed the most.
However, the gravity torque logger showed that joint 1 gravity torque was almost zero. For example, in one run, the summary was:
So, even though joint 1 moved significantly, KDL did not assign any meaningful gravity torque to joint 1. The gravity torque appeared mainly in joint 2 and joint 4 instead.
This seems consistent with the current URDF definition, because axis="0 0 1" makes joint 1 rotate around the root Z axis, which is parallel to the gravity direction. Therefore, KDL naturally computes almost zero gravity torque for that joint.
Test 2: temporary diagnostic URDF with joint1 axis="0 1 0"
As a diagnostic test, I modified only the generated URDF temporarily:
<axis xyz="0 1 0"/>for openarm_joint1.Then I repeated the same gravity torque logging experiment.
With this temporary URDF, the gravity torque result looked much more physically plausible:
Around the forward-horizontal posture, the logger showed:
This matches the physical intuition much better: the main gravity load appears on the shoulder joint that raises the arm forward, with a secondary load on the elbow.
Questions
Is openarm_joint1 intended to rotate around the Z axis in the current URDF?
If so, could you clarify the intended physical meaning of joint 1? On my hardware, the first joint appears to be the main joint for raising the arm from a hanging-down posture to a forward horizontal posture.
If not, should the axis of openarm_joint1 be something like:
or possibly the opposite sign:
, depending on the coordinate convention?
Why this matters
This affects gravity compensation. With the current URDF, KDL computes almost no gravity compensation torque for joint 1. As a result, gravity compensation based on the current model cannot support the physical joint 1 during forward arm raising.
Using the diagnostic axis="0 1 0" version, the computed gravity torque for joint 1 becomes approximately 15 Nm in the forward-horizontal posture, which seems much more consistent with the physical behavior.