Error in loading urdf-model

[LorenzoFiori]

@lrapetti
I open this issue to report a problem I had when using urdf-modifiers, specifically using the example Link and Joint Modifier.

Running this command from the terminal:

(robsub) C:\Users\lfiori\RepoGit\element_human-body-estimation>Python src\TestModifier.py

which contains the following modified script:

from urdfModifiers.core.linkModifier import LinkModifier
from urdfModifiers.core.jointModifier import JointModifier
from urdfModifiers.core.modification import Modification
from urdfModifiers.utils import *
from urdfModifiers.geometry import *

urdf_path ="./models/humanModelTemplate/humanModelTemplate.urdf"
output_file = "./models/humanModelTemplate/humanModel_test1.urdf"
dummy_file = 'no_gazebo_plugins.urdf'
# Extract the <gazebo> tags from the urdf, as they collide with the library
robot, gazebo_plugin_text = utils.load_robot_and_gazebo_plugins(urdf_path,dummy_file)

# Create a link modifier by specifying link name and robot
# axis parameter is necessary for dimension and position modifications
link_modifier = LinkModifier.from_name('Pelvis', robot, axis=geometry.Side.Z)
# Same applies for JointModifier
#joint_modifier = JointModifier.from_name('r_elbow', robot, axis=geometry.Side.X)

# Create a new Modification instance
link_modifications = Modification()
# Make the link 0.2m long
link_modifications.add_dimension(0.3, absolute=True) 
# Double the link's density
#link_modifications.add_density(2.0, absolute=False) 

# Create a new Modification instance 
#joint_modifications = Modification()
# Move the origin of the joint to 0.4 in the modifier's axis
#joint_modifications.add_position(0.4, absolute=True) 

# Apply the modifications
link_modifier.modify(link_modifications)
#joint_modifier.modify(joint_modifications)

# Create a new Modification instance 
#joint_modification_joint_type = Modification()
#joint_modification_joint_type.add_joint_type(geometry.JointType.REVOLUTE)

# Apply the modification 
#joint_modifier.modify(joint_modification_joint_type)

# Write URDF to a new file, also adding back the previously removed <gazebo> tags                
utils.write_urdf_to_file(robot, output_file, gazebo_plugin_text)  

we get this error:

Traceback (most recent call last):
  File "C:\Users\lfiori\RepoGit\element_human-body-estimation\src\TestModifier.py", line 11, in <module>
    robot, gazebo_plugin_text = utils.load_robot_and_gazebo_plugins(urdf_path,dummy_file)
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages\urdfModifiers\utils\utils.py", line 49, in load_robot_and_gazebo_plugins
    robot = URDF.load(dummy_fileName)
            ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages\urdfpy\urdf.py", line 3729, in load
    return URDF._from_xml(node, path)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages\urdfpy\urdf.py", line 3926, in _from_xml
    kwargs = cls._parse(node, path)
             ^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages\urdfpy\urdf.py", line 161, in _parse
    kwargs.update(cls._parse_simple_elements(node, path))
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages\urdfpy\urdf.py", line 137, in _parse_simple_elements
    v = [t._from_xml(n, path) for n in vs]
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages\urdfpy\urdf.py", line 137, in <listcomp>
    v = [t._from_xml(n, path) for n in vs]
         ^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages\urdfpy\urdf.py", line 931, in _from_xml
    return Material(**kwargs)
           ^^^^^^^^^^^^^^^^^^
  File "C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages\urdfpy\urdf.py", line 876, in __init__
    self.color = color
    ^^^^^^^^^^
  File "C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages\urdfpy\urdf.py", line 898, in color
    value = np.asanyarray(value).astype(np.float)
                                        ^^^^^^^^
  File "C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages\numpy\__init__.py", line 284, in __getattr__
    raise AttributeError("module {!r} has no attribute "
AttributeError: module 'numpy' has no attribute 'float'. Did you mean: 'cfloat'?

However, we were able to overcome this by removing this attribute from the `humanModelTemplate.urdf' (our model):

<material name="color">
        <color rgba="0.1 0.1 0.1 1"/>
</material>

Unfortunately, both the original and modified models can no longer be opened with:

idyntree-model-view --model humanModel_test1.urdf

but must be added again manually the attribute.

[lrapetti]

cc @Nicogene @CarlottaSartore

[CarlottaSartore]

@LorenzoFiori could you please point me to the urdf file you are using? Thanks :) and also which version of Numpy you are using

[CarlottaSartore]

I think that the issue lays in urdf py that when loads the color of a material does np.float() in numpy 1.24 the alias np.float() has been removed, which instead has been deprecated with numpy 1.22 (hence it gives a warning but still works).

So downgraded to numpy 1.22 should make it work

[traversaro]

I think that the issue lays in urdf py that when loads the color of a material does np.float() in numpy 1.24 the alias np.float() has been removed, which instead has been deprecated with numpy 1.22 (hence it gives a warning but still works).

So downgraded to numpy 1.22 should make it work

For what regards conda-forge, I should have fixed this with conda-forge/urdfpy-feedstock#4, as soon as CI passes I can merge and in ~10 minutes the new (fixed) package should be available. However, I have no control on the urdfpy package on PyPI.

More in general this is also related to #30 . The long term solution are discussed in #30 (comment), but in the meanwhile we could modify the README to document this situation, and in particular document a way to avoid this problems (i.e. use conda-forge or use pip and pin numpy?).

[traversaro]

Ok, the new urdfpy build pyha21a80b_2 is available in conda-forge, you should get it automatically if you create a new environment, or run mamba update urdfpy in an existing environment.

[lrapetti]

Ok, the new urdfpy build pyha21a80b_2 is available in conda-forge, you should get it automatically if you create a new environment, or run mamba update urdfpy in an existing environment.

@LorenzoFiori can you try this and verify you are able to correctly load the model with the colour?

[LorenzoFiori]

@CarlottaSartore and @traversaro thank you for your fast and helpful suggestions!

after upgrading within the existing environment with mamba update urdfpy, it now load the model with the color (@lrapetti)

@CarlottaSartore although I think it is a little late in the day as an answer:

our urdf-model

e this is about Numpy:

Name: numpy
Version: 1.24.0
Summary: Fundamental package for array computing in Python
Home-page: https://www.numpy.org
Author: Travis E. Oliphant et al.
Author-email:
License: BSD-3-Clause
Location: C:\Users\lfiori\AppData\Local\mambaforge\envs\robsub\Lib\site-packages
Requires:
Required-by: contourpy, h5py, imageio, matplotlib, pycollada, pyrender, scipy, trimesh, urdfModifiers, urdfpy

[Nicogene]

Shall we enforce the numpy version in setup.cfg?

[traversaro]

Shall we enforce the numpy version in setup.cfg?

The problem is that would prevent to use urdf-modifiers with numpy==1.24.0 with dependencies provided by conda-forge, even if that is working fine.

[lrapetti]

Hi @traversaro @Nicogene, the issue for @LorenzoFiori seems to be resolved so feel free to close the issue for us.

I don't know if you took any decision concerning:

Shall we enforce the numpy version in setup.cfg?

The problem is that would prevent to use urdf-modifiers with numpy==1.24.0 with dependencies provided by conda-forge, even if that is working fine.

[traversaro]

I think the best option is to document the numpy constraint in the documentation that install the dependency via pip, but not enforce it in setup.cfg.

[traversaro]

Prompted by @Nicogene, I looked into updating the README, but then I tought it was a better use of time to just solve once and for all the problem of the unmantained urdfpy dependency. So, I decided that the fastest option was to go for option B in #30 (comment), i.e. friendly fork urdfpy to a new library, and package that for PyPI. Exactly the second after I did this, I discovered that there was already a similar friendly fork at https://github.com/fishbotics/urchin, so let's check if we can converge to a single friendly fork, see also the discussion in mmatl/urdfpy#31 .

[traversaro]

Prompted by @Nicogene, I looked into updating the README, but then I tought it was a better use of time to just solve once and for all the problem of the unmantained urdfpy dependency. So, I decided that the fastest option was to go for option B in #30 (comment), i.e. friendly fork urdfpy to a new library, and package that for PyPI. Exactly the second after I did this, I discovered that there was already a similar friendly fork at https://github.com/fishbotics/urchin, so let's check if we can converge to a single friendly fork, see also the discussion in mmatl/urdfpy#31 .

The latest urchin 0.0.27 should work fine as a drop-in replacement of urdfpy, and soon it should be available in conda-forge : conda-forge/staged-recipes#22592 . At this point, I think we can start migrating our projects from urdfpy to urchin, see for example #33 .