Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a machinery to easily access model locations on C++ and Python #130

Merged
merged 5 commits into from
Feb 16, 2022

Conversation

GiulioRomualdi
Copy link
Member

With this PR I want to propose a solution for the #91. In 3c869f1, I implemented a C++ library that will allow us to easily access the location of a model installed in by icub-models repo. The location of the files is automatically generated by a cmake machine that is in charge to set the path accordingly to the installation folder.

I also implemented the python bindings (with pybind11) 8d7efc7. In theory, it would be possible to use swig to support more language. However, since I've never used it I've preferred to start with something simpler.

This is an python script where I used the module. I replicated the API suggested by @traversaro in #91 (comment)

>>> import icub_models
>>> print(f"Models have been installed in: {icub_models.get_models_path()}")
Models have been installed in: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots
>>> print(f"Available robots: {icub_models.get_robot_names()}")
Available robots: {'iCubErzelli02', 'iCubGazeboV3', 'iCubGenova09', 'iCubNancy01', 'iCubParis01', 'iCubLisboa01', 'iCubParis02', 'iCubGazeboV2_5_visuomanip', 'iCubGenova04_plus', 'iCubGazeboV2_5_plus', 'iCubGazeboV2_5', 'iCubGenova02', 'left_wrist_mk2', 'iCubDarmstadt01', 'iCubGenova04', 'iCubGazeboV2_6', 'iCubGenova03', 'iCubGenova01', 'iCubGazeboV2_7', 'left_hand_mk3'}
>>> for robot_name in icub_models.get_robot_names():
...     print(f"{robot_name}: {icub_models.get_model_file(robot_name)}")
... 
iCubErzelli02: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubErzelli02/model.urdf
iCubGazeboV3: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGazeboV3/model.urdf
iCubGenova09: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGenova09/model.urdf
iCubNancy01: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubNancy01/model.urdf
iCubParis01: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubParis01/model.urdf
iCubLisboa01: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubLisboa01/model.urdf
iCubParis02: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubParis02/model.urdf
iCubGazeboV2_5_visuomanip: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGazeboV2_5_visuomanip/model.urdf
iCubGenova04_plus: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGenova04_plus/model.urdf
iCubGazeboV2_5_plus: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGazeboV2_5_plus/model.urdf
iCubGazeboV2_5: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGazeboV2_5/model.urdf
iCubGenova02: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGenova02/model.urdf
left_wrist_mk2: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/left_wrist_mk2/model.urdf
iCubDarmstadt01: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubDarmstadt01/model.urdf
iCubGenova04: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGenova04/model.urdf
iCubGazeboV2_6: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGazeboV2_6/model.urdf
iCubGenova03: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGenova03/model.urdf
iCubGenova01: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGenova01/model.urdf
iCubGazeboV2_7: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/iCubGazeboV2_7/model.urdf
left_hand_mk3: /home/gromualdi/robot-code/robotology-superbuild/build/install/share/iCub/robots/left_hand_mk3/model.urdf

@GiulioRomualdi
Copy link
Member Author

cc @traversaro @Nicogene

endif()
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/METADATA "")
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/METADATA "Metadata-Version: 2.1${NEW_LINE}")
file(APPEND ${CMAKE_CURRENT_BINARY_DIR}/METADATA "Name: icub_models${NEW_LINE}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that for pep-0008 the use of underscore in package names is discouraged, see https://www.python.org/dev/peps/pep-0008/#package-and-module-names, while the underscore is actuall suggested for the module name.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double checking with @diegoferigo .

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I interpret the PEP correctly, it states that the usage of underscores in module names is discouraged. Practically, if you cannot find a single name descriptive enough, this suggestion from a very old PEP is not really followed and you can find pretty often _.

This being said, the module name is different from the package name, and this section of CMake code is about the resulting package name. In this case, it does not matter much, because underscores in the metadata are parsed as dashes by PyPI and pip. What differs is just the sdist / wheel package name. And I mean, a package with name icub-models containing a module stored in folder icub_models so that it can be imported as import icub_models, when packaged, produces icub-models-....{zip|wheel}. This bother mostly CI since you have to take care of two different names. Since packages named icub_models can be installed with pip as pip install icub-models regardless, I'd suggest to keep all naming consistent, using always _.

bindings/CMakeLists.txt Outdated Show resolved Hide resolved
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/INSTALLER "${ICUB_MODELS_PYTHON_PIP_METADATA_INSTALLER}${NEW_LINE}")
install(
FILES "${CMAKE_CURRENT_BINARY_DIR}/METADATA" "${CMAKE_CURRENT_BINARY_DIR}/INSTALLER"
DESTINATION ${PYTHON_METADATA_PARENT_DIR}/icub_models-${PROJECT_VERSION}.dist-info)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that even if we call python package name icub-models, the directory name here should use underscore, see conda-forge/opencv-feedstock#300 (comment) .

Copy link
Member

@traversaro traversaro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot @GiulioRomualdi ! My only doubt for what regards this implementation is that by itself is not relocatable. This is not a problem as long as we just distribute binaries via apt packages (as in that case the CMAKE_INSTALL_PREFIX used to install the binaries is always the same, i.e. /usr or /opt/something) or conda (as conda handles automatically strings in the binary packages to make them relocatable).

However, if we ever want to ship this via PyPI, this may be a problem. However, I do not think this should block the PR as in any case this is a great step forward, and if necessary I think it would be trivial to replace the pybind11 Python library with a native Python library for which handling the relocatability is trivial.

@GiulioRomualdi
Copy link
Member Author

GiulioRomualdi commented Feb 16, 2022

Hi @traversaro, I applied the suggestions you proposed. Before merging the PR I would like to highlight:

  1. I set the project version in the CMake file. The version is the same of the latest release
  2. I opened the PR on devel. I don't know if it is fine or I should change the base branch to master
  3. I should write something in the readme

@traversaro
Copy link
Member

I opened the PR on devel. I don't know if it is fine or I should change the base branch to master

Devel is fine.

I should write something in the readme

Yes, that would great otherwise people will never know of the feature! The README probably would need a revamp in general (see #90), but I think that for this feature I think it is ok to just add two sections after https://github.com/robotology/icub-models#use-the-models-with-gazebo, something like:

  • Use the models from the C++ helper library
  • Use the models from the Python helper library
    Where you just provide the minimal snippets of code.


# Output package is:
#
# bipedal_locomotion
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# bipedal_locomotion
# icub_models

install(FILES "${ICUB_MODELS_PYTHON_PACKAGE}/__init__.py"
DESTINATION ${PYTHON_INSTDIR})

# Install pip metadata files to ensure that blf installed via CMake is listed by pip list
Copy link
Contributor

@xEnVrE xEnVrE Feb 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly to #130 (comment), the reference to blf seems to be a leftover as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You got me

@GiulioRomualdi
Copy link
Member Author

@traversaro I updated the README in 6da40e2

@traversaro
Copy link
Member

For me it is ok! Can you add a note in the CHANGELOG.md ? Thanks!

@traversaro traversaro merged commit f286488 into robotology:devel Feb 16, 2022
@traversaro
Copy link
Member

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants