Migrate away from urdf_parser_py?

[traversaro]

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 Package in conda-forge #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: clemense/yourdfpy#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: icub-tech-iit/urdf-modifiers#30 (comment) .	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.

[GiulioRomualdi]

Exposing the iDynTree (or Pinocchio) parser? Is it possible?

[traversaro]

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.

[Giulero]

I was with @CarlottaSartore and she told me that another possible parser could be urchin. What's your opinion?

[traversaro]

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 mmatl/urdfpy#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.

[traversaro]

icub-tech-iit/ergocub-gazebo-simulations#49 we were affected by a urdf_parser_py bug (tracked in ros/urdf_parser_py#82).