iCubNancy01 urdf

[traversaro]

@InriaBrice commented on Fri Jun 30 2017

Hi !

We need some features about iCubNancy01 urdf to convert urdf to sdf file with gz sdf -p command :

Links can't have masse = 0,
Links can't have inertia matrix diagonal null -> ixx, iyy, izz != 0,
It happens for link like wrist or hip_yaw, so it's not an end effector (we can't just remove this link otherwise hand can't be here ),

We need a version without dh frame because we just don't use them,

About Center of masses of links, soemtimes it seems like they are not at the right position (especially in the arms they are a bit forward ).

Also if it is possible to have all link frame with X axis forward and Z axis upward.

Also i was asking myself, why meshes are not Centered at origin in .dae files ? ( Also it's possible to set frame meshes to get X forward and Z upward ) .

I think link wrist could be more in the middle of the forearm, i mean at the middle of end of the forearm, they are actually ahead and in the forearm.

Also it would be nice if iCub was turned forward ( looking at +X axis ), without turn robot in gazebo or whatever (just with urdf spawn )

For now i customized all to get something like expected, but some inertia matrix are making robot a bit instable.

---

@traversaro commented on Tue Jul 04 2017

Hi @InriaBrice , moving the issue over to icub-model-generator where we already have all the other discussions on the generated models.

[traversaro]

Hi @InriaBrice, I will reply inline to each point.

Links can't have masse = 0,
Links can't have inertia matrix diagonal null -> ixx, iyy, izz != 0,
It happens for link like wrist or hip_yaw, so it's not an end effector (we can't just remove this link otherwise hand can't be here ),
About Center of masses of links, sometimes it seems like they are not at the right position (especially in the arms they are a bit forward ).
I think link wrist could be more in the middle of the forearm, i mean at the middle of end of the forearm, they are actually ahead and in the forearm.
For now i customized all to get something like expected, but some inertia matrix are making robot a bit instable.

All these problems are due to the iCubNancy01 model being generated using the dh generation pipeline (see https://github.com/robotology-playground/icub-model-generator#pipelines), that conbines parameters that were manually extracted from the CAD years ago and that we have no way to verify. The problem way to address this problems is to use the new simmechanics-based generation model to generate iCubNancy models, but as stated in robotology-legacy/yarp-wholebodyinterface#78 (comment) :

As discussed f2f : iCubNancy is a v2.5 with arm v1 (probably, according to the photos in #13 (comment)). For the purpose of replicating the iCub stand up demo the best strategy is perhaps to use a model v2.5 without backpack . Such a model will have the wrong kinematics for the forearm, but the effect of this on the standup demo will be probably negligible.

So, we need to find a way of patching the model generated using simmechanics to have arm v1 kinematics. Note that the differences between the kinematics of iCub arm v1 and v2 are just a few millimeters (4mm and 9mm), on the offset of some wrist joints: http://wiki.icub.org/wiki/ICubFowardKinematics_right . If those differences do not scare you, I would suggest to use one of the models of type "v2.5 without backpack", such as iCubDarmstadt01 or iCubGenova01 (see https://github.com/robotology-playground/icub-model-generator#generated-models). To properly produce such parameters, I opened a separate issue: #51 .

We need a version without dh frame because we just don't use them,

The dh "frames" are represented in URDF as massless links without children, attached to their parent with a fixed joint. This links should be automatically removed during the URDF --> SDF conversion, so which kind of problem are you experiencing?

Also if it is possible to have all link frame with X axis forward and Z axis upward.

What is your use case for having the links with this orientation? For some links, we are bound for backward compatibility with some iCub software to have the link oriented in a different way (see http://wiki.icub.org/wiki/ICubForwardKinematics), so it would be tricky to change the orientation of all links. In all our (IIT) software, whenever we need to have some reference for the position/orientation we add a new frame, as hard-coding the assumption of the orientation of the link frame could create problem if this assumption is violated. Unfortunately, this does not play well with the SDF format, that remove automatically URDF massless links during the conversion process.

Also i was asking myself, why meshes are not Centered at origin in .dae files ?

The mesh came from a different model (not automatically generated) produce by UPMC. We did not produce those meshes, and we never edited them. What is the problem with meshes not centered in the origin.

( Also it's possible to set frame meshes to get X forward and Z upward ) .

This would require postprocessing, what is the rationale/requirement for having the frames meshes oriented in this way?

[InriaBrice]

Some people here are using Xsense suit, so it's easier to have all link frame oriented in same way to do transform.

Ok for now dh frame are just ignored, but maybe one day they will change the way they parse urdf and then it will throw an error. Anyway it's not a big problem, more like a remark.

The main problem for this kind of link is for hip or shoulder, if they are ignored the whole limb is ignored.

For meshes which are centered you have most of time their link frame not at the same position. If meshes was centered, you could just say " i want my link frame at the same position than my meshes".
At the end if your meshe is not centered, and you correct it by positioning at the good places in your URDF, it look like the same than if you centered your meshes and just put it without correction in your URDF. So i think it's easier and more intuitive. Specially when you want to do small change of position.

Forgot : in my URDF i need to NOT have dh_frame, because our multi-body framework parsing can't read them. ( it's a bit long to explain )

[traversaro]

Thanks for the feedback @InriaBrice (just a small comment: never edit a comment without adding a new comment as well, as people subscribed to the issue will not receive any notification about whatever you added to the edited comment.