Closed traversaro closed 4 months ago
As for https://github.com/robotology/icub-models-generator/pull/244#issuecomment-1632668705, not sure if someone in iRonCub is still using simmechanics-to-urdf (hopefully not), but if that is still the case this could be interesting for iRonCub @vpunithreddy @FabioBergonti .
Me too, nice tool!
Fix https://github.com/robotology/icub-models-generator/issues/205 .
While looking into https://github.com/robotology/icub-models-generator/pull/260, I found really annoying that it was basically impossible to generate the models locally, and hence do any kind of debugging. This is the problem tracked in https://github.com/robotology/icub-models-generator/issues/205 .
The problem is particularly sensitive in this case as for historical reason this script requires a huge stack of code (CMake, Python, I just realized we are also still using ruby here) and libraries that require to use a precise old version to workaround bugs and problems. On one hand, it is highly unlike we will ever cleanup this, as all the effort for new robots is on the creo2urdf effort (see https://github.com/icub-tech-iit/creo2urdf). However, realistically we will need to be able to generate models for iCub robots for an indefinite amount of time in the future. Why not take the occasion to use this as a testbench for setting up an example of reproducible research software?
To do so, I added pixi support to this repo. In a nutshell, pixi use conda packages, but it simplifies the management of so-called "lock files" (in the case of pixi,
pixi.lock
) that capture exactly the version of all the software dependencies used at some point in time. Furthermore, pixi also have a "task" system, in which manual step can be automated in a cross-platform way.After doing this, once you have pixi installed, process of generating models in a
icub-models
folder contained in the robotology-superbuild boils down to:See the README for more details.
The main advantage w.r.t. to regular conda environment files (such as the one added in https://github.com/robotology/icub-models-generator/pull/244) is that the automatically generated
pixi.toml
file tracks the exact version of software used. So if in the future a new version ofcatkin_pkg
(see https://github.com/robotology/icub-models-generator/blob/a42368e1a2ef2b7640a6c517b9b525735e852488/environment.yml#L15), or some transitive dependency of the packages listed in the environment breaks the software, the pixi workflows will continue to work as it uses the exact version saved inpixi.lock
. Using conda, one could achieve something similar usingconda-lock
, but being an external tool its use is not straightforwardly integrated in conda/mamba.Note that in general I am not happy to add some pixi task code on top of the CMake glue code that is used to launch the Python scripts, but that is the price we pay for reproducibility and being able to solve https://github.com/robotology/icub-models-generator/issues/205 .