Migrate away from urdf_parser_py?

traversaro commented 1 year ago

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.

GiulioRomualdi commented 1 year ago

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

traversaro commented 1 year ago

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 commented 1 year ago

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

traversaro commented 1 year ago

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.

traversaro commented 1 year ago

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).

Giulero commented 2 weeks ago

Reviving this issue! I don't know if, parser-wise, the situation has changed since some months ago. @traversaro in your opinion what would be "the best" option to migrate to?

flferretti commented 2 weeks ago

Reviving this issue! I don't know if, parser-wise, the situation has changed since some months ago. @traversaro in your opinion what would be "the best" option to migrate to?

Maybe https://github.com/ami-iit/rod can be an option

traversaro commented 2 weeks ago

Reviving this issue! I don't know if, parser-wise, the situation has changed since some months ago. @traversaro in your opinion what would be "the best" option to migrate to?

Maybe https://github.com/ami-iit/rod can be an option

If you are looking for something that can be installed via pypi, the downside of rod is that it relies on a gz sdf command being installed somehow in the system.

diegoferigo commented 2 weeks ago

Reviving this issue! I don't know if, parser-wise, the situation has changed since some months ago. @traversaro in your opinion what would be "the best" option to migrate to?

Maybe https://github.com/ami-iit/rod can be an option

If you are looking for something that can be installed via pypi, the downside of rod is that it relies on a gz sdf command being installed somehow in the system.

Yep this is the trade-off of rod (very much wanted). Although I'm the author or rod, I'm also a downstream user in few projects that use it to parse SDF/URDF. The positive side of the trade-off is that downstream projects can be sure that the model description specified by the user is well formed, with clear errors coming from sdformat if it's not. This is a huge offload of maintenance effort, particularly relevant since the URDF situation out there is quite fragmented and in my experience is quite common to have models that only work in the specific simulator/library they were paired originally, but when used somewhere else, they fail to load. The validation provided by sdformat ensures that a model, when loaded, is well formed.

Nowadays, the gz sdf command line only requires installing libsdformat13 gz-tools2 (or newer), there's no longer the need to install a complete Gazebo setup. If and only if this need is a burden that can be accepted, rod becomes quite appealing.

Note that rod can load SDF files without any system dependency when validation is disabled, but this is not really useful in practice since URDF is much more popular.

traversaro commented 2 weeks ago

@traversaro in your opinion what would be "the best" option to migrate to?

I am afraid there is no clear winner here as of November 2024.

This is quick assessment:

Repo	conda-forge package	Pros	Cons
https://github.com/ros/urdf_parser_py	`urdfdom-py`	Pure python (so easy for python developers to look into it), "official" parser maintained by the ROS team	Not available on pypi (or even worse, a really old version is available so people think it is available while actually it is not, see https://github.com/ros/urdf_parser_py/issues/85).
https://github.com/fishbotics/urchin	`urchin`	Pure python (so easy for python developers to look into it), available on both pypi and conda-forge. ami-iit has control on the official repo via me.	A bit confusing as it is a fork of urdfpy, so looking online you find much more reference to `urdfpy` rather that `urdfpy`
https://github.com/robotology/idyntree	`idyntree`	Extensively used in the lab, @traversaro can help on debugging issues (as long as he is around). It contains useful features to the model, like model reduction and base frame changes almost for free.	Implemented in C++, so not easy to look into/debug/modify by Python developers. Available on pypi, but wheel only on Linux. Parser itself implemented with libxml2 with SAX, so not easy to debug if a developer is not familiar with it.
https://github.com/ami-iit/rod	`rod`	Used of some projects in the lab, reusing the URDF -> SDF parser used by Gazebo, so "official" URDF parser used and maintained by the Gazebo team.	The actual URDF parser is implemented in C++, so not easy to look into/debug/modify by Python developers. Available on pypi, but the default version that you get from pypi is broken unless you install some additional packages (`libsdformat13`) that are not available in default apt repos since Ubuntu 24.04, so you also need to enable the gazebo custom apt repos. The chain of code related to parsing the code spans multiple repos (rod --> sdformat --> adam) so it may be complicated to follow the code path if they a developer is not familiar with Python/C++ and all this problem.
https://github.com/clemense/yourdfpy	`yourdfpy`	Pure python, apparently maintained, available on both pypi and conda-forge.	Never used before in the lab, yet another parser to which we need to worry about.

In a nutshell, as long as you install dependencies via conda-forge, everything is fine, while if the concern is being able to install via pypi e have a python code to look into it, the winner may be urchin, but I am not sure if this is enough to justify the effort to migrate.

@diegoferigo @flferretti @Giulero feel free to suggest changes on the Pro/Cons assessment.

traversaro commented 2 weeks ago

Ah, there is also https://github.com/clemense/yourdfpy, but I never used it (and I am biased on avoiding to add yet another URDF parser used in the lab). Also, Hugging Face robotics people may soon be releasing a fork of urdf_parser_py, according to https://github.com/dora-rs/dora/pull/704 .

traversaro commented 2 weeks ago

Ah, there is also https://github.com/clemense/yourdfpy, but I never used it (and I am biased on avoiding to add yet another URDF parser used in the lab)

However, the parser is already in conda-forge thanks to rerun and prefix people, so it is not so back. I think it make sense to add it to the table, at least.

Giulero commented 2 weeks ago

Thanks @traversaro for the analysis!

At this point, it seems the best options are likely urchin and idyntree. Here are my considerations:

urchin seems easy to use, and having control over it is a nice plus.
'idyntree' might be more difficult to integrate, but it could add useful features to the model, like model reduction and base frame changes almost for free.
Switching to sdf as internal representation also is an option, but it would require changes beyond just the model tree structure; it would also affect joint and link handling. Correct me if I'm wrong. That said, adding an Sdf importer is something we need to consider for the future.
I do not see many differences between yourdfpy and urchin. I prefer urchin since we have more control over it.

So, for now, it looks like urchin and idyntree are the best options!

traversaro commented 2 weeks ago

Thanks @Giulero, I updated the table by adding the useful features in idyntree as a pro.

traversaro commented 2 weeks ago

I decided to take the bull by the horns: https://github.com/ros/urdf_parser_py/issues/85#issuecomment-2466175775, hopefully we will eventually have an updated urdfdom-py Python package that contains the updated urdf_parser_py Python module on PyPI as well. This does not prevent us to switch to any other parser if we want, but is anyhow useful for all others uses of urdf_parser_py in the lab and in the wild.

ami-iit / adam

Migrate away from urdf_parser_py? #36