Closed gabrielenava closed 5 years ago
That's strange on my PC this command line executed in the test folder generates the correct model. As an example this is the root_link
:
The only warning I get is the following:
Inertia: [[ 3.00000000e-04 -7.03830522e-06 -4.61427517e-04] [ -7.03830522e-06 3.00000000e-04 -6.20681339e-05] [ -4.61427517e-04 -6.20681339e-05 3.00000000e-04]] is not a valid Inertia matrix because it has negative inertias on the principal axis. Warning: inertia matrix for link r_foot is not physically consistent.
I have to check the dependencies. Do you have any warning about the meshes?
Also the last build seems fine. I fear that some dependency has been modified. Probably @drdanz can restart the build on Travis and we should be able to see if this is the case.
I tried uninstalling and reinstalling everything, but still the same. Here is my terminal output:
gnava@iiticublap120 ~/Software/github/robotology/simmechanics-to-urdf/test (master) $ simmechanics_to_urdf LEGS_MECHANISM.xml --yaml legs_simmechanics_options.yaml --csv-joints joint_parameters.csv --output xml --outputfile testurdf.urdf
/usr/local/lib/python2.7/dist-packages/simmechanics_to_urdf-0.2-py2.7.egg/simmechanics_to_urdf/firstgen.py:289: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
Inertia: [[ 3.00000000e-04 -7.03830522e-06 -4.61427517e-04]
[-7.03830522e-06 3.00000000e-04 -6.20681339e-05]
[-4.61427517e-04 -6.20681339e-05 3.00000000e-04]] is not a valid Inertia matrix because it has negative inertias on the principal axis.
there is a warning concerning the YAML loader too.
I fix easily the warning by changing the yaml.load
here to yaml.safe_load
, but still the issue is there.
Ok, I did a bit of analysis of the problem. it seems that the visual
and collision
elements are generated correctly by https://github.com/robotology/simmechanics-to-urdf/blob/master/simmechanics_to_urdf/firstgen.py. In fact, I added the line
print(visual)
right before this command and I can see the visual elements printed on the terminal with no errors:
geometry:
filename: model://iCubHeidelberg01_model/dae_meshes/sim_root_link.dae
scale:
- 0.001
- 0.001
- 0.001
material:
color:
rgba:
- 0
- 1
- 0
- 1
name: green
texture: None
origin:
rpy:
- 1.5707963267948961
- 0
- -1.5707963267948961
xyz:
- -0.036399999999999995
- 0
- 0.032
This made me tought that the culprit should be the class urdf.Link()
from urdf_parser_py. I checked in their github repo and - surprise! there is an issue about exactly this problem! See https://github.com/ros/urdf_parser_py/issues/42
I will try to revert back to previous commits of the urdf_parser_py
and I'll add more details.
I fixed the issue! the problem was due to multiple causes, all of them related to the urdf_parser_py
:
there is a problem using the urdf.Link
class for setting visual and collision elements. I moved to the fork
associated with this PR: https://github.com/ros/urdf_parser_py/pull/47
there was a conflict between the urdf.py
class installed by the urdf_parser_py
repo and the same class that came along with the ros installation. Therefore I was actually always using the wrong class, that was located in /opt/ros/melodic/lib/python2.7/dist-packages/urdf_parser_py
, rather than the one coming from the aforementioned PR, located in /usr/local/lib/python2.7/dist-packages/urdf_parser_py
. Renaming the urdf_parser_py
folder located in /opt/ros/....
to urdf_parser_py_OLD
allowed me to point the correct class, and this fixed the issue!
See the first link of the urdf:
<link name="root_link">
<inertial>
<origin xyz="-0.0026057700000000003 2.6285900000000003e-06 -0.0551054" rpy="0 0 0"/>
<mass value="1.73671"/>
<inertia ixx="0.102027" ixy="3.49564e-06" ixz="-0.000139376" iyy="0.0882212" iyz="3.14137e-06" izz="0.187815"/>
</inertial>
<visual>
<origin xyz="0 0 -0.03475" rpy="0 0 0"/>
<geometry>
<mesh filename="sim_drone.stl" scale="0.001 0.001 0.001"/>
</geometry>
<material name="green">
<color rgba="0 1 0 1"/>
</material>
</visual>
<collision>
<origin xyz="0 0 -0.03475" rpy="0 0 0"/>
<geometry>
<mesh filename="sim_drone.stl" scale="0.001 0.001 0.001"/>
</geometry>
</collision>
</link>
closing the issue.
Thanks @gabrielenava for this check! 🙂
In order to catch this kind of issues earlier probably could be useful to have nightly builds that take place automatically and specific [unit test]() that fail if the generated urdf
model is not well formed.
In Travis we can use Cron Jobs. If we agree we can open a dedicated issue to discuss the implementation of this feature.
cc @traversaro @DanielePucci
@fiorisi Fine to me!
Thanks @gabrielenava for the in-depth debugging.
closing the issue.
I am not sure why we are closing the issue. As far as I understand, if anyone installs the simmechanics-to-urdf
following the documentation contained in the README, it will be affected by the issue, right? The idea is to track this general issue in https://github.com/robotology/simmechanics-to-urdf/issues/36 ?
@traversaro I agree. Considering the title of the issue probably we should keep it open.
Nevertheless, following your comment The idea is to track this general issue in #36 ?
probably we can keep only one.
There is also a link to the solution explained here.
I tried to generate the
urdf
model contained in thetest/
folder of this repository. Theyaml
configuration files contains details concerning the meshes renaming in theurdf
, see https://github.com/robotology/simmechanics-to-urdf/blob/master/test/legs_simmechanics_options.yaml#L1.However, the generated urdf links do not contain any visual and collision elements. See the generated urdf below:
No error message is displayed