robots/dexterous_hand_description/dex5_1/Dex5-URDF-R/Dex5-URDF-R.urdf declares
effort="0" on 16 of its 20 actuated joints. The mirror file has none.
Parsed from both files, (effort, velocity) distributions:
Dex5-URDF-R.urdf 20 joints, 16 zero-effort
('0.93', '4.18') x4
('0', '0.76794') x2
('0', '3.1415926') x3
('0', '3.368485398') x3
...
Dex5-URDF-L.urdf 20 joints, 0 zero-effort
('0.93', '4.18') x4
('0.93', '0.76794')x3
('0.93', '3.1416') x4
('0.93', '3.3685') x4
Two things make this look like a defect rather than an intentional difference:
- the left hand carries
effort="0.93" on all 20, and the right file's own
first four joints are also 0.93 — so the value is not in dispute, it is
present in both files and was lost on 16 of the right hand's joints;
Roll_41R and Roll_51R additionally carry velocity="0".
URDF spells "unlimited" by omitting the attribute, so a declared effort="0"
is a declared inability to apply torque. In a consumer that honours it — anything
propagating getJointInfo()[10] into a position-control force, which is the
standard idiom in PyBullet, and equivalently in Gazebo and ros2_control — those
joints do not move at all, while the left hand's do.
The correct value is recoverable exactly: effort="0.93", from the mirror
file.
A caveat worth stating: MuJoCo's URDF path largely ignores effort, so a
MuJoCo-based workflow will not show this. The right hand looks fine in one
toolchain and is inert in another, with no error in either — which is probably
why it has survived.
I have not opened a PR because I do not know whether the velocity values should
also be mirrored (the two files use slightly different precision on the same
numbers — 3.1415926 vs 3.1416 — which suggests they were generated
separately rather than mirrored programmatically, so I did not want to guess at
which is canonical).
robots/dexterous_hand_description/dex5_1/Dex5-URDF-R/Dex5-URDF-R.urdfdeclareseffort="0"on 16 of its 20 actuated joints. The mirror file has none.Parsed from both files,
(effort, velocity)distributions:Two things make this look like a defect rather than an intentional difference:
effort="0.93"on all 20, and the right file's ownfirst four joints are also
0.93— so the value is not in dispute, it ispresent in both files and was lost on 16 of the right hand's joints;
Roll_41RandRoll_51Radditionally carryvelocity="0".URDF spells "unlimited" by omitting the attribute, so a declared
effort="0"is a declared inability to apply torque. In a consumer that honours it — anything
propagating
getJointInfo()[10]into a position-controlforce, which is thestandard idiom in PyBullet, and equivalently in Gazebo and
ros2_control— thosejoints do not move at all, while the left hand's do.
The correct value is recoverable exactly:
effort="0.93", from the mirrorfile.
A caveat worth stating: MuJoCo's URDF path largely ignores
effort, so aMuJoCo-based workflow will not show this. The right hand looks fine in one
toolchain and is inert in another, with no error in either — which is probably
why it has survived.
I have not opened a PR because I do not know whether the velocity values should
also be mirrored (the two files use slightly different precision on the same
numbers —
3.1415926vs3.1416— which suggests they were generatedseparately rather than mirrored programmatically, so I did not want to guess at
which is canonical).