CREO2URDF – Use the OTK for getting the relevant information for the urdf

[Nicogene]

Task description

This is the follow-up of #11.

We would like to:

• Extract info about the axis
• Extract info about the transformation between links
• Extract mass and inertia moment info of links
• Start using idyntree

Definition of done

The above list is completed

[Nicogene]

Today we started working here: #14

Right now we managed to:

• Port to OTK removing the last Toolkit leftovers
• For each part print the mass, com and inertia tensor.

About the last point we are not sure which one of these are needed for the urdf (cc @traversaro @fiorisi)

Right now we are struggling on changing the unit of measure ( worst case we do the conversion mm->m by hand) and getting the axis/transformation parent-child without visiting the components in the assembly

cc @pattacini

[Nicogene]

Side note about the axis problem.
In our 2bars.asm we have the axis of the mechanism defined as follows:

But on the asm of ergocub instead is "nested"

And getting the feature information we have

I am afraid that this difference will need to access to it in different ways.

@salvi-mattia @Mick3Lozzo @fiorisi can explain the differences in defining the mechanism?

For now, we remain focused on mvp-1 and then on how it is defined in 2bars.asm, but for the future, we have to keep in mind this difference

[salvi-mattia]

the second one is shrinkwrap made
this process nests the datumz [axis, planes, csys] in that ext geom copy
I'm afraid it alsa changes the names

while we made tests in the past with @mfussi66 we had a first stint with creo parts and than a second with the shrinkwrapped parts

[traversaro]

About the last point we are not sure which one of these are needed for the urdf (cc @traversaro @fiorisi)

Using CREO nomenclature and filling a bit the gaps as they do not provided a full description of this quantities or the rotation frame in which they are expressed, the iDynTree::SpatialInertiaRaw class can be built both via the inertia tensor w.r.t. to the coordinate frame i.e. coord_sys_inertia_tensor (using the iDynTree::SpatialInertiaRaw constructor) or the inertia tensor w.r.t. to the cg i.e. cg_inertia_tensor (using the iDynTree::SpatialInertiaRaw::fromRotationalInertiaWrtCenterOfMass helper method).

However, it is a good idea to double check this assumptions. In particular, it is important to understand the orientation with which this inertia is expressed. For URDF/iDynTree, the inertia needs to be expressed with the orientation of the link frame, and in this case I am not sure which orientation are we using instead.

The attribute of the inertial element in the URDF are the one expressed w.r.t. the center of mass (see http://wiki.ros.org/urdf/XML/link#Elements, https://github.com/robotology/idyntree/blob/cdfe1296960dfd87c53ea90fd131f456ea0ce48a/src/model_io/codecs/src/InertialElement.cpp#L104 and https://github.com/robotology/idyntree/blob/cdfe1296960dfd87c53ea90fd131f456ea0ce48a/src/model_io/codecs/src/URDFModelExport.cpp#L94).

Small OT comment: I am quite curious about why they define what they call "inertia matrix" that is typically just used as as synonim of the "inertia tensor", I am not sure if they provide more details in the docs?

[Nicogene]

Using CREO nomenclature and filling a bit the gaps as they do not provided a full description of this quantities or the rotation frame in which they are expressed, the iDynTree::SpatialInertiaRaw class can be built both via the inertia tensor w.r.t. to the coordinate frame i.e. coord_sys_inertia_tensor (using the iDynTree::SpatialInertiaRaw constructor) or the inertia tensor w.r.t. to the cg i.e. cg_inertia_tensor (using the iDynTree::SpatialInertiaRaw::fromRotationalInertiaWrtCenterOfMass helper method).

When asking from creo the mass properties of a part thet inertia tensor are displayed as follow

INERTIA with respect to CSYS coordinate frame:  (KILOGRAM * MM^2)

INERTIA TENSOR:
Ixx Ixy Ixz  7.8379469e+00 -2.2498100e-06  0.0000000e+00
Iyx Iyy Iyz -2.2498100e-06  2.5232490e-01  8.1580121e-01
Izx Izy Izz  0.0000000e+00  8.1580121e-01  7.7518654e+00

INERTIA at CENTER OF GRAVITY with respect to CSYS coordinate frame:  (KILOGRAM * MM^2)

INERTIA TENSOR:
Ixx Ixy Ixz  2.4666081e+00 -2.2498100e-06  0.0000000e+00
Iyx Iyy Iyz -2.2498100e-06  1.2542249e-01  0.0000000e+00
Izx Izy Izz  0.0000000e+00  0.0000000e+00  2.5074290e+00

Where CSYS should be the coordinate system of the part (i.e. link)

[salvi-mattia]

I'm not sure that the csys of the part and the one used to represent the link in URDF coincide.
anyway you can ask for the inertia tensor represented in a chosen csys

[fiorisi]

I'm not sure that the csys of the part and the one used to represent the link in URDF coincide. anyway you can ask for the inertia tensor represented in a chosen csys

Yes you should be able to specify a SYS, but if not specified should be the part origin.
If I remember correctly, the one we should be interested in is the one at the center of gravity. See https://wiki.ros.org/urdf/XML/link

[Nicogene]

Yes you should be able to specify a SYS, but if not specified should be the part origin.
If I remember correctly, the one we should be interested in is the one at the center of gravity. See wiki.ros.org/urdf/XML/link

Yes indeed, @mfussi66 and I thought the same when we checked the urdf specification.
@traversaro do you agree?

[mfussi66]

and getting the axis/transformation parent-child without visiting the components in the assembly

Not anymore! Well, for now I was able at the moment to get the segment describing the axis, so it can be used to define the rotation axis. I defined 2 additional axes as test:

Maybe we can get the same data from the copy geometries by using the C functions instead of C++:

[traversaro]

Yes you should be able to specify a SYS, but if not specified should be the part origin.
If I remember correctly, the one we should be interested in is the one at the center of gravity. See wiki.ros.org/urdf/XML/link

Yes indeed, @mfussi66 and I thought the same when we checked the urdf specification. @traversaro do you agree?

Yes, see my comment in #13 (comment) . Anyhow, notice that it is also important to correctly specify the orientation of the frame where the inertia is expressed.

[mfussi66]

Now we are also able to retrieve the transform between the ASM_CSYS (which is our root frame) and a part CSYS:

UPDATE:
and now we also have the unit vectors of the axes

[Nicogene]

Start using idyntree

Since we basically have all the informations to give to iDynTree::Model for generating the urdf, we started this last point.

Unfortunately linking idyntree::idyntree_highlevel gives problems when loading the plugin, probably we have to investigate if it is just a problem of installation of idyntree or if creo doesn't not allow to create dll that links libraries different from the stl and the creo ones.

We will investigate it the next days

[mfussi66]

Start using idyntree

Since we basically have all the informations to give to iDynTree::Model for generating the urdf, we started this last point.

Unfortunately linking idyntree::idyntree_highlevel gives problems when loading the plugin, probably we have to investigate if it is just a problem of installation of idyntree or if creo doesn't not allow to create dll that links libraries different from the stl and the creo ones.

We will investigate it the next days

I found this knowledge base article that says:

PTC Technical Support does not help / support on using any third party libraries in combination with Pro/Toolkit.

Usage of other UI Toolkits / Libraries ( windows MFC etc.) along with Pro/Toolkit works only in asynchronous mode (exe).

Any such usage of third party toolkit / Libraries in combination with Creo Toolkit Applications is entirely left to users discretion and capability.

There is some help regarding that:

• http://support.ptc.com/cs/cs_22/howto/ptk1725/ptk1725.htm
• https://www.ptc.com/en/support/article/cs105537?source=ArticleViewerRelated

[traversaro]

Start using idyntree

Since we basically have all the informations to give to iDynTree::Model for generating the urdf, we started this last point.

Unfortunately linking idyntree::idyntree_highlevel gives problems when loading the plugin, probably we have to investigate if it is just a problem of installation of idyntree or if creo doesn't not allow to create dll that links libraries different from the stl and the creo ones.

We will investigate it the next days

Did you made sure that the iDynTree dll are in the PATH?

[Nicogene]

Did you made sure that the iDynTree dll are in the PATH?

Yes, but then I realized that probably was due to the fact we just added the idyntree lib dir of the conda environment to the PATH, but then probably the libraries linked by idyntree were not in the path and this triggered the error in loading the plugin in creo.

We will try with a clean/proper installation of idyntree

[traversaro]

Did you made sure that the iDynTree dll are in the PATH?

Yes, but then I realized that probably was due to the fact we just added the idyntree lib dir of the conda environment to the PATH, but then probably the libraries linked by idyntree were not in the path and this triggered the error in loading the plugin in creo.

All the required .dll to load should be in %CONDA_PREFIX%\Library\bin, so it should be sufficient to add that one to the PATH. Just to double check: did you added %CONDA_PREFIX%\Library\bin or %CONDA_PREFIX%\Library\lib to the path? The correct one is %CONDA_PREFIX%\Library\bin.

[mfussi66]

%CONDA_PREFIX%\Library\lib

This one! I could try with \bin

[mfussi66]

It does work 🚀

[Nicogene]

Alonside @mfussi66, we managed to create our first idyntree model using the information retrieved by Creo, see 6fdbce2

We wanted also to export the urdf, but we had issues while using ModelExporter.

Only adding this line:

iDynTree::ModelExporter mdl_exporter;

triggers an error loading the plugin as when we put the wrong path in the PATH

Even if we added iDynTree::idyntree-modelio to target_link_libraries, @traversaro have any idea what could be the problem?

In any case, we are very close to MVP-1 🚀

cc @fiorisi @salvi-mattia @Mick3Lozzo @maggia80

[traversaro]

@traversaro have any idea what could be the problem?

Linking iDynTree::idyntree-modelio should be sufficient. Do you have the exact error message? This could contains hints to the actual error.

Furthermore, to check if a .dll can found all the .dll on which it depends, you can try to open the Creo plugin in https://github.com/lucasg/Dependencies and check if there is any missing .dll .

[Nicogene]

Setting PRO_TK_DBG_DLL_LOAD to true as suggested here I got:

Pro/ENGINEER: OS error 127 while loading 'C:\Users\ngenesio\icub-tech-iit\creo2urdf\build\x64-Release\bin\creo2urdf.dll'

Where 127 means:

ERROR_PROC_NOT_FOUND

    127 (0x7F)

    The specified procedure could not be found.

Furthermore, to check if a .dll can found all the .dll on which it depends, you can try to open the Creo plugin in lucasg/Dependencies and check if there is any missing .dll .

Working:

Faulty:

[traversaro]

Are you sure that ucore68.dll is a .dll related to iDynTree? It seems relaed to Creo, see https://www.ptc.com/en/support/article/CS135880 . Can you check if somewhere in the PC where Creo is installed a ucore68.dll file is available?

I see that it is missing in both Working and not-working case, but probably that means that the PATH used by Dependencies is not the same PATH used by Creo, probably you can try to print the PATH as seen in the plugin to do tests in a consistent way.

[Nicogene]

Are you sure that ucore68.dll is a .dll related to iDynTree? It seems relaed to Creo, see ptc.com/en/support/article/CS135880 . Can you check if somewhere in the PC where Creo is installed a ucore68.dll file is available?

I see that it is missing in both Working and not-working case, but probably that means that the PATH used by Dependencies is not the same PATH used by Creo, probably you can try to print the PATH as seen in the plugin to do tests in a consistent way.

Yes indeed it is a Creo dll see:

[Nicogene]

This is my PATH:

Path=%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;C:\Users\ngenesio\AppData\Local\mambaforge\envs\robotologyenv\Library\bin;C:\Users\ngenesio\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\ngenesio\AppData\Local\Pandoc\

This is what i got from getenv("PATH") from the creo2urdf plugin:

C:\Users\ngenesio\AppData\Local\mambaforge\condabin;C:\Program Files\PTC\Creo 9.0.2.0\Common Files\x86e_win64\lib;C:\Python311\Scripts\;C:\Python311\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Microsoft SQL Server\150\Tools\Binn\;C:\Program Files\MATLAB\R2022a\runtime\win64;C:\Program Files\MATLAB\R2022a\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Docker\Docker\resources\bin;C:\ProgramData\chocolatey\bin;C:\Program Files\CMake\bin;C:\Program Files\Git\cmd;C:\Users\ngenesio\AppData\Local\Microsoft\WindowsApps;C:\Users\ngenesio\AppData\Local\mambaforge\envs\robotologyenv\Library\bin;C:\Users\ngenesio\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\ngenesio\AppData\Local\Pandoc\;C:\Program Files\PTC\Creo 9.0.2.0\Common Files\x86e_win64\deflib;C:\Program Files\PTC\Creo 9.0.2.0\Common Files\libs\dfor\lib;C:\Program Files\PTC\Creo 9.0.2.0\Parametric\bin

[traversaro]

Can you use the PATH as seens from the creo2urdf plugin when using Dependencies?

[Nicogene]

Can you use the PATH as seens from the creo2urdf plugin when using Dependencies?

The only difference is that now it found ucore68.dll

[Nicogene]

Alongside @traversaro we continued the debugging but unfortunately, without finding a solution.

We narrowed down the problem, and now just linking LibXml2::LibXml2 is sufficient to fail the load of the dll on Creo.

We tried:

• Build a .exe that links LibXml2::LibXml2 -> works
• Build a .exe that links the faulty creo2urdf::creo2urdf and invokes a dummy hello function -> works
• Build a .exe that load with LibraryLoad() the faulty creo2urdf.dll, but it is loaded just fine, no 127 error.

All these tests have been done in a terminal where the PATH was set to the same used by Creo:

C:\Users\ngenesio\AppData\Local\mambaforge\condabin;C:\Program Files\PTC\Creo 9.0.2.0\Common Files\x86e_win64\lib;C:\Python311\Scripts\;C:\Python311\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Microsoft SQL Server\150\Tools\Binn\;C:\Program Files\MATLAB\R2022a\runtime\win64;C:\Program Files\MATLAB\R2022a\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Docker\Docker\resources\bin;C:\ProgramData\chocolatey\bin;C:\Program Files\CMake\bin;C:\Program Files\Git\cmd;C:\Users\ngenesio\AppData\Local\Microsoft\WindowsApps;C:\Users\ngenesio\AppData\Local\mambaforge\envs\robotologyenv\Library\bin;C:\Users\ngenesio\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\ngenesio\AppData\Local\Pandoc\;C:\Program Files\PTC\Creo 9.0.2.0\Common Files\x86e_win64\deflib;C:\Program Files\PTC\Creo 9.0.2.0\Common Files\libs\dfor\lib;C:\Program Files\PTC\Creo 9.0.2.0\Parametric\bin

Here is the source of the exe

#include <cstdlib>
#include <iomanip>
#include <iostream>
#include <iDynTree/ModelIO/ModelExporter.h>
#include <iDynTree/Model/Model.h>
#include <iDynTree/Model/RevoluteJoint.h>
#include <creo2urdf/Creo2Urdf.h>
#include <windows.h>
#include <iostream>

int main(int argc, char* argv[]) {
    iDynTree::ModelExporter mdl_exporter;
    iDynTree::Model idyn_model;
    std::cout<<"This is Val "<<hello(val)<<std::endl;

    HINSTANCE hGetProcIDDLL = LoadLibrary("C:\\Users\\ngenesio\\icub-tech-iit\\creo2urdf\\build\\x64-Release\\bin\\creo2urdf.dll");

    if (!hGetProcIDDLL) {
        std::cout << "could not load the dynamic library" << std::endl;
        return EXIT_FAILURE;
    }
    else {
        std::cout << "Library loaded!" << std::endl;
    }

    /*...*/

    return EXIT_SUCCESS;

Our option are now:

• Contact technical support (even if they states they do not give support when using third-party libraries)

PTC Technical Support does not help / support on using any third party libraries in combination with Pro/Toolkit.

• Try with idyntree compiled all static

[Nicogene]

Thanks to the precious help of @traversaro I managed to link statically idyntree and all its dependencies following these instructions.

I added them in the readme, see 8df332c

And now habemus urdf! 🎸

<?xml version="1.0"?>
<robot name="2BARS">
  <link name="BAR">
    <inertial>
      <mass value="0.00741938044781609"/>
      <origin xyz="0 -15 3.5" rpy="0 -0 0"/>
      <inertia ixx="-0.8349706673190365" ixy="0" ixz="0" iyy="-0.001970110919505899" iyz="-0.3895174735103447" izz="-0.7157575641017974"/>
    </inertial>
  </link>
  <joint name="BAR--BARLONGER" type="continuous">
    <origin xyz="0 0 6.811996306092723e-15" rpy="0 -0 -0.7060878385670463"/>
    <axis xyz="0 0 1"/>
    <parent link="BAR"/>
    <child link="BARLONGER"/>
  </joint>
  <link name="BARLONGER">
    <inertial>
      <mass value="0.010359380471568048"/>
      <origin xyz="0 -22.5 3.5" rpy="0 -0 0"/>
      <inertia ixx="-2.904730637223145" ixy="-2.2498100353314738e-6" ixz="0" iyy="-0.001479921769347553" iyz="-0.8158012121359837" izz="-2.7370073443897516"/>
    </inertial>
  </link>
</robot>

The next point will be to add the visuals to the urdf, here is some useful links:

• https://github.com/iit-danieli-joint-lab/robotsuits-simulations/blob/e70473e5faa81a2804e078123d44188743afe8e4/src/libraries/idjl-robotsuits/idjl_robotsuits.cpp#L23
• https://github.com/iit-danieli-joint-lab/robotsuits-simulations/blob/e70473e5faa81a2804e078123d44188743afe8e4/src/libraries/idjl-robotsuits/idjl_robotsuits.cpp#L23
• https://github.com/iit-danieli-joint-lab/idjl-software/blob/3e9c209646317ff0c7815bce1bbbab1fddb0d2ce/cxx/tools/idjl-robot-model-generator/idjl_robot_meshes_generator.cpp#L187
• https://github.com/iit-danieli-joint-lab/idjl-software/blob/3e9c209646317ff0c7815bce1bbbab1fddb0d2ce/cxx/tools/idjl-robot-model-generator/idjl_abb_model_generator.cpp#L39

 

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

[Nicogene]

Today I committed some fixes/enhancements:

• 910f588 conversion mmtom
• 115fe0f added the visual/collision meshes and fixed continuous joint.

For the latter point in iDynTree if a joint has no limits it is considered continuous, right now I hardcoded 0-180, we ought to get them from the cad. Here is the resulting urdf:

<?xml version="1.0"?>
<robot name="2BARS">
  <link name="BAR">
    <inertial>
      <mass value="0.00741938044781609"/>
      <origin xyz="0 -0.015 0.0035" rpy="0 -0 0"/>
      <inertia ixx="-8.349706673190367e-7" ixy="0" ixz="0" iyy="-1.970110919505906e-9" iyz="-3.895174735103447e-7" izz="-7.157575641017976e-7"/>
    </inertial>
    <visual>
      <origin xyz="0 0 0" rpy="0 -0 0"/>
      <geometry>
        <mesh filename="BAR.stl" scale="0.001 0.001 0.001"/>
      </geometry>
      <material name="">
        <color rgba="0.5 0.5 0.5 1"/>
      </material>
    </visual>
    <collision>
      <origin xyz="0 0 0" rpy="0 -0 0"/>
      <geometry>
        <mesh filename="BAR.stl" scale="0.001 0.001 0.001"/>
      </geometry>
      <material name="">
        <color rgba="0.5 0.5 0.5 1"/>
      </material>
    </collision>
  </link>
  <joint name="BAR--BARLONGER" type="revolute">
    <origin xyz="0 0 6.811996306092723e-18" rpy="0 -0 -0.7060878385670463"/>
    <axis xyz="0 0 1"/>
    <parent link="BAR"/>
    <child link="BARLONGER"/>
    <limit lower="0" upper="3.141592653589793" effort="1e+9" velocity="1e+9"/>
  </joint>
  <link name="BARLONGER">
    <inertial>
      <mass value="0.010359380471568048"/>
      <origin xyz="0 -0.0225 0.0035" rpy="0 -0 0"/>
      <inertia ixx="-2.9047306372231453e-6" ixy="-2.249810035331474e-12" ixz="0" iyy="-1.4799217693475475e-9" iyz="-8.158012121359838e-7" izz="-2.7370073443897514e-6"/>
    </inertial>
    <visual>
      <origin xyz="0 0 0" rpy="0 -0 0"/>
      <geometry>
        <mesh filename="BARLONGER.stl" scale="0.001 0.001 0.001"/>
      </geometry>
      <material name="">
        <color rgba="0.5 0.5 0.5 1"/>
      </material>
    </visual>
    <collision>
      <origin xyz="0 0 0" rpy="0 -0 0"/>
      <geometry>
        <mesh filename="BARLONGER.stl" scale="0.001 0.001 0.001"/>
      </geometry>
      <material name="">
        <color rgba="0.5 0.5 0.5 1"/>
      </material>
    </collision>
  </link>
</robot>

I think we can consider this activity done and open a followup with the remaining points

[traversaro]

A comment for future activities, probably a bit OT here but I do not know where to write it otherwise. Probably before scaling up in complexity you may want to check if the revolute joint is exported as expected? If we have a way to vary he joint angle in Creo, a possible end-to-end check is to compute the transform between BAR and BARLONGER with different joint angles in both Creo (via the Analysis > Measure > Transform) and in iDynTree (via iDynTree::KinDynComputations::getRelativeTransform), and check if the value correspond. I am bit afraid of the subtleness of the semantics of the quantities passed between iDynTree, Creo and URDF, so if we could check if everything works as expected at some point it would be great.

[Nicogene]

A comment for future activities, probably a bit OT here but I do not know where to write it otherwise. Probably before scaling up in complexity you may want to check if the revolute joint is exported as expected? If we have a way to vary he joint angle in Creo, a possible end-to-end check is to compute the transform between BAR and BARLONGER with different joint angles in both Creo (via the Analysis > Measure > Transform) and in iDynTree (via iDynTree::KinDynComputations::getRelativeTransform), and check if the value correspond. I am bit afraid of the subtleness of the semantics of the quantities passed between iDynTree, Creo and URDF, so if we could check if everything works as expected at some point it would be great.

Good point, I think that the next activity will be mostly focused on validation on what we got