-
Notifications
You must be signed in to change notification settings - Fork 57
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
Why the loaders? #5
Comments
@gabrielebndn I think the loaders have been thought to be easy to use. Avoiding looking for a particular description of a robot (path_name, etc.). I don't see really the point of not having them. |
I don't know. Design-wise, I do not like them, for all the reasons listed above |
I agree with 1. We should not use robot-wrapper in the loader, to make it easier to not use robot-wrapper in later applications. |
@gabrielebndn sorry for a late reply. I agree with @nmansard. We could remove the robot wrapper dependency, and then add a dedicate visualization (for user inspection only) in GV (and / or meshcat). I hadn't have time to work on it. Feel free to do it if you want. Note that we could install this package without Pinocchio dependency (or loaders), i.e. sudo apt install robotpkg-example-robot-data or cmake -DBUILD_PYTHON_INTERFACE=OFF ../
sudo make install |
In robots_loader.py there are many utility methods to load a
RobotWrapper
containing one of the robots of this repository.Is it really needed? I do not like these special methods. There are many reasons why I say this:
First of all, they are based on
RobotWrapper
, and we should not encourage the use ofRobotWrapper
For most robots, they amount to little more than a call to
RobotWrapper.BuildFromURDF
. Pinocchio methods are already convenient enough to load robots.They make the code employing them less transparent
They introduce a dependency to Pinocchio
They are not general
They are not flexible.
They introduce yet-another-way of doing the same thing, i. e. loading a URDF model. Do we really need another way? This is not really desirable, as goes, for instance, the Zen of Python :
There should be one-- and preferably only one --obvious way to do it.
We already havebuildModelsFromUrdf
andcreateDatas(models)
RobotWrapper
interfaceThey make the robots contained in this repo sort of "special", because they have a special way to be loaded
They are confusing to newcomers, because they hide too much detail and then they will not know how to load a generic robot or a slightly modified one (I can call some newcomers to testify)
Summarizing, I think this loader functions are a bad idea and should be removed
The text was updated successfully, but these errors were encountered: