-
Notifications
You must be signed in to change notification settings - Fork 38
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
Bipedal-locomotion-framework and iDynTree. A love that has come to an end #63
Comments
To be honest, it is not clear to me the outcome. Do you want to completely remove |
The main idea is to keep iDynTree in private dependency (except for Correct me if I'm mistaken @traversaro |
Yes, the idea is that Eigen::VectorXd or |
I think this should have been the original design of the public APIs :) I am a big fan of STL-only APIs (e.g. robotology/gym-ignition#158 and the wearable interfaces for interfaces I recently desiged), they simplify system integration to a level that is priceless. The PIMPL idiom should also be a must. Of course, everything keeps working fine in the case only vectors are required. When there are APIs that need to accept or return matrices, a math-oriented library is often necessary. Now that Eigen solved its problems in public APIs, I will start advocating for this solution. |
Discussing with @traversaro and @S-Dafarra we decided to start using the Eigen in the public API. For this reason, I will change the code of #61 to be in accordance with this new choice. I kindly ask @S-Dafarra to do the same for #62. For the already existing code, I start the conversion in the "free time". I will open a PR for each existing component |
CC @dic-iit/dynamic-interaction-control |
The choice of using Eigen in the public API of |
I guess that then we can close robotology/idyntree#707 ? |
Disclaimer The title of the issue is deliberately provocative.
In robotology/idyntree#707 I show the possibility to use
Eigen
iniDynTree
public API. The main pro of using Eigen is enabling the linear algebra.Discussing with @traversaro we realized that even if describing an
iDynTree::VectorFixSize<>
withEigen
is relatively simple robotology/idyntree#709, implementing the same approach for aniDynTree::VectorDynSize
is way less trivial. Indeed iniDynTree
, the concept ofcapacity
is widely used. This concept does not have a corresponding inEigen
.In order to solve #56 and other similar problems, we (@traversaro and I) drew 2 + 1 possible solutions:
Nothing changes We keep the status quo.
Introduce
operator+()
(and all the others) in iDynTree between matrices and vectorAvoid to use
iDynTree
in bipedal locomotion framework:Eigen
It will be easy to use the library in other projects. Hopefully, the library will be used also in other labs sinceEigen
can be considered asnumpy
forPython
. In the past, we already usedEigen
instead of iDynTree inosqp-eigen
.In order to tackle the second point we should write a simple interface to
iDynTree::KinDynComputations
that takes as inputEigen
Objects. The interface becomes useless as soon as theKinDynComputations
class acceptsiDynTree::Span
We should make a decision as fast as possible since the code in the repository is increasing day after day. (In theory, we should decide before merging #61 #62)
@dic-iit/dynamic-interaction-control
The text was updated successfully, but these errors were encountered: