Basically in iDynTree the joint axis can have any direction and offset, while for URDF the joint axis must pass through the child link frame origin. However, the check to ensure this in the URDF exported had a bug, as it checked the origin of the axis was 0,0,0, but it is perfectly fine for the axis to have a non-zero offset, as long as the axis still passes through the origin of the frame. For example, if you have an axis defined as (direction: [1,0,0], offset: [1,0,0]), that is ok for URDF as it passes through the origin, but it was rejected before this PR.
This PR fixes the problem by actually checking the distance between the axis (expressed in the child link frame) and the origin of the child link frame (that is simply [0 0 0]) is different from zero, rather then simply checking that the axis offset is different from zero.
Furthermore, tests have been added to ensure that the new check works as expected.
I noticed this today in https://github.com/icub-tech-iit/creo2urdf/issues/97#issuecomment-2163188586 .
Basically in iDynTree the joint axis can have any direction and offset, while for URDF the joint axis must pass through the child link frame origin. However, the check to ensure this in the URDF exported had a bug, as it checked the origin of the axis was 0,0,0, but it is perfectly fine for the axis to have a non-zero offset, as long as the axis still passes through the origin of the frame. For example, if you have an axis defined as (direction: [1,0,0], offset: [1,0,0]), that is ok for URDF as it passes through the origin, but it was rejected before this PR.
This PR fixes the problem by actually checking the distance between the axis (expressed in the child link frame) and the origin of the child link frame (that is simply
[0 0 0]
) is different from zero, rather then simply checking that the axis offset is different from zero.Furthermore, tests have been added to ensure that the new check works as expected.