ami-iit / rod

The ultimate Python tool for RObot Descriptions processing.
https://pypi.org/project/rod/
BSD 3-Clause "New" or "Revised" License
13 stars 3 forks source link

Parse URDF models from ergocub-software #26

Closed flferretti closed 10 months ago

flferretti commented 10 months ago

I've encountered an issue while trying to parse the URDF model using the ergoCubGazeboV1_minContacts model from the ergocub-software repository. Specifically, the problem arises when rod tries to convert the model from URDF to SDF format.

Interestingly, removing the <gazebo> tags from the URDF resolves the problem. As a expected behaviour, I believe that if the rod tool doesn't recognize these tags, it should ideally ignore them and possibly log a warning message.

Here's the traceback I'm encountering:

Traceback (most recent call last):
  File "/home/flferretti/git/element_rl-for-codesign/src/evogym/envs/ergocub.py", line 686, in <module>
    env = ErgoCub()
  File "/home/flferretti/git/element_rl-for-codesign/src/evogym/envs/ergocub.py", line 243, in __init__
    model = self.simulator.insert_model_from_description(
  File "/home/flferretti/jaxsim/src/jaxsim/simulation/simulator.py", line 247, in insert_model_from_description
    model = jaxsim.high_level.model.Model.build_from_model_description(
  File "/home/flferretti/jaxsim/src/jaxsim/high_level/model.py", line 155, in build_from_model_description
    model_description = jaxsim.parsers.rod.build_model_description(
  File "/home/flferretti/jaxsim/src/jaxsim/parsers/rod/parser.py", line 315, in build_model_description
    sdf_data = extract_model_data(
  File "/home/flferretti/jaxsim/src/jaxsim/parsers/rod/parser.py", line 53, in extract_model_data
    sdf_element = rod.Sdf.load(sdf=model_description, is_urdf=is_urdf)
  File "/home/flferretti/.local/lib/python3.10/site-packages/rod/sdf/sdf.py", line 103, in load
    raise ValueError("Failed to parse 'sdf' argument")
ValueError: Failed to parse 'sdf' argument

C.C. @diegoferigo @traversaro

diegoferigo commented 10 months ago

Thanks for reporting the problem! The URDF to SDF conversion is not handled internally by rod. We pass through gazebosim/sdformat by calling process_model_description_with_sdformat that in turn tries to call the system's executable gz sdf -p </path/to/model.urdf>.

If the conversion fails, we should understand what's the problem on the sdformat side. This is relevant because the same logic is called when the model is imported in a generic Gazebo simulation. In other words, if the conversion fails, likely the URDF model cannot be imported neither in Gazebo.

Can you please call manually the following command and paste the produced error?

gz sdf -p /path/to/ergocub.urdf
traversaro commented 10 months ago

For me with gz-sim7 and latest release of ergocub-software

 gz sdf -p `resolve-robotics-uri-py package://ergoCub/robots/ergoCubGazeboV1_minContacts/model.urdf`

prints just at the beginnining a warning:

Warning [Utils.cc:130] [/sdf/model[@name="ergoCub"]/link[@name="head"]/sensor[@name="lasersensor_head"]/ray[@name="head_laser_sensor"][@name="head_laser_sensor"]:/home/traversaro/miniforge3/envs/testergocub/share/ergoCub/robots/ergoCubGazeboV1_minContacts/model.urdf:L0]: XML Attribute[name] in element[ray] not defined in SDF.

While this may be something in ergocub-software, rod perhaps is getting confused by the warning?

flferretti commented 10 months ago

Thanks for your response @diegoferigo. Actually, the command does not fail with gz-11.10.2, but it produces the SDF file as expected with the warning:

Warning [parser.cc:833] XML Attribute[name] in element[ray] not defined in SDF, ignoring.
gz sdf -p /home/flferretti/mambaforge/envs/test101/share/ergoCub/robots/ergoCubGazeboV1_minContacts/model.urdf > ergocub.sdf
traversaro commented 10 months ago

The problem on the ergocub models should be fixed by https://github.com/icub-tech-iit/ergocub-software/pull/164 . As a local modification, one can manually change <ray name="head_laser_sensor"> to <ray>.

flferretti commented 10 months ago

The warning is not produced anymore by rod with the most recent version. The issue strictly related to rod has been solved

C.C. @diegoferigo

traversaro commented 10 months ago

The warning is not produced anymore by rod with the most recent version. The issue strictly related to rod has been solved

With the most recent version of rod or the most recent version of something else? If it is solved with rod, probably we can close the issue?

flferretti commented 10 months ago

I was referring to most recent version of rod. Closing as solved