adam
adam copied to clipboard
Migrate away from urdf_parser_py?
urdf_parser_py
is a bit of a problematic dependency:
- On PyPI, a really old version of it is packaged (0.0.4, while the latest is 1.2.0) : https://pypi.org/project/urdf-parser-py/#files vs https://github.com/ros/urdf_parser_py/releases/tag/1.2.0
- More in general, it is a package that is tipically packaged as a ROS package under the "urdfdom_py" name https://index.ros.org/r/urdfdom_py/, meaning that its mantainers do not care about its packaging on PyPI . Furtermore, being a ROS package in the conda world means that it is tipically package in the robostack channel, not on the conda-forge one. This complicates its packaging on conda-forge (see https://github.com/ami-iit/ADAM/issues/26), as to package it on conda-forge we would need to first package urdf_parser_py, but this could create possible conflicts with the urdf_parser_py packaged in robostack .
At the moment, I was kind of deadlocked w.r.t. to this. Anyhow, yesterday @GiulioRomualdi suggested that we could migrate from urdf_parser_py to another library to load the the URDF. At beginning I was not entusiastic about the idea, but if that would be feasible it would be indeed great. In the following I would list a few alternatives:
Library | Pro | Cons | Notes |
---|---|---|---|
Python bindings of iDynTree | The ami-iit controls it. | It is C++ library with Python bindings, it may be a bit difficult for pure python programmers to understand what's toing on. | |
yourdfpy |
Pure python | I tought it was mantained, but even this library is not compatible with latest numpy and related PR are not merged: https://github.com/clemense/yourdfpy/pull/46 | |
urdfpy |
Pure python | It has a lot of issue and it is not mantained, this is the library that was used in urdf_modifiers and we are in a similar situation: https://github.com/icub-tech-iit/urdf-modifiers/issues/30#issuecomment-1364040962 . | TL;DR: Do not use |
Initially I opened this issue noting that yourdfpy could be a well-mantained pure python library that it could make sense to use, but apparently it has mantainance problem as well, so I am deadlocked again. However, it is a bit too late as I already wrote the issue, so let's open the issue, perhaps it may be useful in the future.
Exposing the iDynTree (or Pinocchio) parser? Is it possible?
Exposing the iDynTree (or Pinocchio) parser? Is it possible?
The iDynTree parser is already exposed, it has the cons listed in the table but the pro that we obtain a rapresentation that is for sure 100% compatible with iDynTree, also w.r.t. to serialization, reduced joitns and similar aspects. However, I am afraid it is a bit more difficult to use than pure python libraries.
I was with @CarlottaSartore and she told me that another possible parser could be urchin. What's your opinion?
I was with @CarlottaSartore and she told me that another possible parser could be urchin. What's your opinion?
urchin is based a rebranded version of urdfpy, forked in a repo so that we can do releases (see https://github.com/mmatl/urdfpy/issues/31). Basically it is like urdfpy, but with the advantage that we can publish fixes for it on both PyPI and conda-forge. If you like it, feel free to use it.
https://github.com/icub-tech-iit/ergocub-gazebo-simulations/issues/49 we were affected by a urdf_parser_py bug (tracked in https://github.com/ros/urdf_parser_py/issues/82).