CREO2URDF – Validation of MVP-1 – Followup

[pattacini]

This follows up on #16 and aims to complete the optional points below:

• [x] Get the rest position from Creo and set it in the iDynTree::RevoluteJoint ~- [ ] Get the joints limits from Creo and set it in the iDynTree::RevoluteJoint~ ~- [ ] Align stl path as we manage in other urdf with relative/package path~ ~- [ ] Add a gazebo control board in the resulting urdf~
• [x] Generate protk.dat via cmake with the correct paths

[mfussi66]

In https://github.com/icub-tech-iit/creo2urdf/issues/1 we also mentioned:

In this context, we will consider both the options, with and without the intermediate shrinkwraps.

At the moment we are gathering the datums without the copy geometry data structure, typical of shrinkwraps. Shall we add the processing of copy geometries to the checklist?

[Nicogene]

This point has been moved in #23.

Align stl path as we manage in other urdf with relative/package path

This is something that we want in the urdf of MVP2/3 but right now could obstacle the development/testing. I would do it later when creo2urdf will be more mature.

Add a gazebo control board in the resulting urdf

Same as before, at this stage it was needed only to validate the joint we created, but this has been already done in #16. See #24.

Get the joints limits from Creo and set it in the iDynTree::RevoluteJoint

This point instead seems impossible to do it right now with the license we have. I found that basically we need to access to this information:

For doing it, we need to handle the ModelItem as MechItem and get all Mech constraint:

Unfortunately, we does not have the TOOLKIT for Mechanica license, I had the proof by adding this simple snippet:

            ProMechDisplacementData foo;
            ProMechDisplacementRegularConstr* bar;
            ProMechdisplacementdataTranslationconstrsGet(foo, &bar);

And when trying to load the plugin we get this error

Actually, also the SimScape Multibody Link seemed to ignore the limits set in the cad, probably Mathworks also miss the license for handling mechanisms from C/C++ API.

Speaking with @fiorisi, it came out that it makes sense to investigate if we can buy this license because in this way we could get directly from the cad all the information of the joints needed for creating the urdf without using csv/yml.

cc @pattacini @mfussi66 @traversaro @salvi-mattia @maggia80 @Mick3Lozzo

[octo-reminder[bot]]

invalid json response body at https://api.github.com/repos/icub-tech-iit/creo2urdf/contents/.github%2Focto-reminder.yml reason: Unexpected end of JSON input

[Nicogene]

Get the rest position from Creo and set it in the iDynTree::RevoluteJoint

About this point probably we did a mistake in defining the joint. We should set the rotation around the rotation axis to 0 and then set that rotation we read from the cad as rest position.

@traversaro sounds good to you?

[traversaro]

Get the rest position from Creo and set it in the iDynTree::RevoluteJoint

About this point probably we did a mistake in defining the joint. We should set the rotation around the rotation axis to 0 and then set that rotation we read from the cad as rest position.

@traversaro sounds good to you?

Yes, that is the definition of rest position.

[Nicogene]

Get the rest position from Creo and set it in the iDynTree::RevoluteJoint

About this point probably we did a mistake in defining the joint. We should set the rotation around the rotation axis to 0 and then set that rotation we read from the cad as rest position. @traversaro sounds good to you?

Yes, that is the definition of rest position.

If not specified the rest position taken is the transform passed to the Joint object?

In particular, I am not sure that this (https://github.com/icub-tech-iit/creo2urdf/pull/25/commits/5bfe68045b659a1b655f84380587f1ad2f26fb54) makes sense and it is actually needed.

[traversaro]

If not specified the rest position taken is the transform passed to the Joint object?

Yes, that is indeed the preferred way to set the rest transform so you are sure to set coeherntly the axis and the transform.

In particular, I am not sure that this (https://github.com/icub-tech-iit/creo2urdf/commit/5bfe68045b659a1b655f84380587f1ad2f26fb54) makes sense and it is actually needed.

What is the rationale for that?

[Nicogene]

Today I had a T2T alignment with @traversaro and it came out that:

• https://github.com/icub-tech-iit/creo2urdf/commit/5bfe68045b659a1b655f84380587f1ad2f26fb54 this is not correct, this works only if the axis is oriented as one of the principal axes.
• We would need to read the information of the joint rotation, or to set it in the assembly to 0, in order to pass it to joint.setRestTransform(rest_transform) but from our understanding, this is not possible to do it via API with our current license (https://github.com/icub-tech-iit/creo2urdf/issues/18#issuecomment-1544025162)
• In the absence of this information we need that to do the assumption that in the assembly all the joints as to be set to 0 before pressing the button
  • e302ef6 (#25)
  • 1b0b24e (#25)
• We discovered that the validation done in #16 is not 100% correct, because we changed the joint value and then regenerate the urdf, but instead, we should in this order
  • Generate the urdf with a given joint configuration
  • Change the joint configuration to X
  • Load the urdf from idyntree
  • Set X in KinDynComputations
  • Compute the transform and compare it with the one we read from Creo.

For this last point, we need to disjoint the generation and validation in two different buttons. This activity has been added to #23.

The points of this issue have been done, and the rest position has not to be changed, but indeed we need to fix the validation of the urdf.

cc @pattacini @mfussi66 @fiorisi