Check if model is skeleton and use first csys if CSYS does not exist + small refactor of joints csv configuration

[mfussi66]

Fixes #112 .

[Nicogene]

LGTM, nice refactoring!
Have you tried to export a URDF from an assembly that has CSYS instead of linkFrames (e.g. icub)?

[mfussi66]

LGTM, nice refactoring! Have you tried to export a URDF from an assembly that has CSYS instead of linkFrames (e.g. icub)?

I did it only with the example assembly, I'll check with icub as well.

[mfussi66]

I can confirm that iCub2.7 seems to work just fine:

[traversaro]

Just a curiosity, how are you testing the model with MuJoCo? Are you running some script or command? Xref: robotology/icub-models#155 .

[mfussi66]

Just a curiosity, how are you testing the model with MuJoCo? Are you running some script or command? Xref: robotology/icub-models#155 .

Super simply by drag and drop using the simulate executable.

[traversaro]

Just a curiosity, how are you testing the model with MuJoCo? Are you running some script or command? Xref: robotology/icub-models#155 .

Super simply by drag and drop using the simulate executable.

Wow, I have no idea how this can work, as the package:// URIs are not interpreted by mujoco (see google-deepmind/mujoco#1432).

[mfussi66]

Wow, I have no idea how this can work, as the package:// URIs are not interpreted by mujoco (see google-deepmind/mujoco#1432).

Actually on this test on iCub, I changed the paths of the meshes in the urdf so it could be loaded with no problems on my windows environment without any ros/gazebo machinery.

Nonetheless, I noticed that if the .stl are all in the same folder as the urdf, they are correctly loaded regardless of the package:// URI. Maybe a fallback logic is involved?

[traversaro]

Wow, I have no idea how this can work, as the package:// URIs are not interpreted by mujoco (see google-deepmind/mujoco#1432).

Actually on this test on iCub, I changed the paths of the meshes in the urdf so it could be loaded with no problems on my windows environment without any ros/gazebo machinery.

Ahhh ok, so not simply by dragging and drop the model, also by modifying the path to the meshes. Are there other workarounds necessary?

Nonetheless, I noticed that if the .stl are all in the same folder as the urdf, they are correctly loaded regardless of the package:// URI. Maybe a fallback logic is involved?

Yes, mujoco basically throw away everything in the mesh uri beside the file name if I recall correctly, see google-deepmind/mujoco#1432 .

[Nicogene]

Wow, I have no idea how this can work, as the package:// URIs are not interpreted by mujoco (see google-deepmind/mujoco#1432).

Actually on this test on iCub, I changed the paths of the meshes in the urdf so it could be loaded with no problems on my windows environment without any ros/gazebo machinery.

Nonetheless, I noticed that if the .stl are all in the same folder as the urdf, they are correctly loaded regardless of the package:// URI. Maybe a fallback logic is involved?

This problem should be fixed by:

• Fix mesh file names when specified a fileformat != from %s #115

[mfussi66]

Are there other workarounds necessary?

AFAIK that's only it @traversaro