search

robotology / icub-models

Official URDF and SDF models of the iCub humanoid robot.
Creative Commons Attribution Share Alike 4.0 International
33 stars 34 forks source link

Check the torso pitch joint limits on iCubGazeboV3 #57

Closed GiulioRomualdi closed 4 years ago

GiulioRomualdi commented 4 years ago

I was tuning the PID position control in the simulated version of iCub3 and I noticed that something wired on the torso joint limits.

Accordingly to the motorgui the torso pitch has to be a value between -18 deg and +45 deg. However, the range of motion seems to be not coherent with the real robot.

I drop here a gif. Is there a way to check if the limits are wrong?

icub3-torso-pitch

The values seem to be in accordance with https://github.com/robotology/robots-configuration/blob/40b8e8893fd11e42fff53a1454854319bd922ad7/iCubGenova09/hardware/motorControl/torso-eb5-j0_2-mc.xml#L15-L16. However, the range of motion is strange.

cc @traversaro and @S-Dafarra

S-Dafarra commented 4 years ago

I quickly checked and on the robot it seems the opposite. -19 when on the back and +67 when on the front. I guess it is because of the motor axis.

GiulioRomualdi commented 4 years ago

-19 when on the back and +67 when on the front. I guess it is because of the motor axis.

Does this mean that the joint axis is mounted in the opposite direction?

traversaro commented 4 years ago

I guess it is because of the motor axis.

Exactly. The sign of the motor axis direction is something that is not exported properly when converting a Creo Mechanism to SimMechanics, so ofter that is randomly assigned. We then handle that with the reverseRotationAxis parameter in reverseRotationAxis, and then we check if the direction matches what we expect in https://github.com/robotology/icub-model-generator/blob/master/tests/icub-model-test.cpp#L237, but it is possible that in that case the direction of the axis in iCub2 does not match the one in iCub3, see the related PR https://github.com/robotology/icub-model-generator/pull/149 .

traversaro commented 4 years ago

cc @Nicogene

traversaro commented 4 years ago

Note that for axis direction for iCub 2.* we have a reference in http://wiki.icub.org/wiki/ICub_Model_naming_conventions#Joint_additional_information , while we still lack this for iCub 3.

traversaro commented 4 years ago

It is probably obvious, but a quick fix for an existing model is just to invert the axis in https://github.com/robotology/icub-models/blob/devel/iCub/robots/iCubGazeboV3/model.urdf#L349 .

traversaro commented 4 years ago

We then handle that with the reverseRotationAxis parameter in reverseRotationAxis, and then we check if the direction matches what we expect in https://github.com/robotology/icub-model-generator/blob/master/tests/icub-model-test.cpp#L237, but it is possible that in that case the direction of the axis in iCub2 does not match the one in iCub3, see the related PR robotology/icub-model-generator#149 .

I just realized that what is happening in the test is that probably the axis are expressed in the root_link frame, and for iCub 2 the root_link frame is assigned using the convention described in http://wiki.icub.org/wiki/ICubForwardKinematics, while for iCub 3 the root_link frame is assigned using the x-front y-left convention used for the rest of the links.

Nicogene commented 4 years ago

I just realized that what is happening in the test is that probably the axis are expressed in the root_link frame, and for iCub 2 the root_link frame is assigned using the convention described in http://wiki.icub.org/wiki/ICubForwardKinematics, while for iCub 3 the root_link frame is assigned using the x-front y-left convention used for the rest of the links.

I was wondering why the tests didn't find this issue, I'll open a PR right now

GiulioRomualdi commented 4 years ago

I'll open a PR right now

Really thank you @Nicogene!