Kickoff meeting notes

[S-Dafarra]

Date

16 July 2020

Participants

@GiulioRomualdi @Giulero @S-Dafarra @isorrentino @prashanthr05 @diegoferigo @kouroshD @traversaro @DanielePucci

Discussion

(Silvio) Problem?

(Giulio) A library that would allow us to have the jacobian of objects in iDynTree. (Giulio) Right now I am fine in using only CasADi objects, but in the future I may need to have the jacobians of what it is included in iDynTree

(Silvio) Only the jacobian or the function that can be evaluated and nested into another function?

(Giulio) The second

(Silvio) Using iDynTree or something else, is not a dichotomy. There is a middle ground where we take what it useful fom KinDyn/iDyntree and use it in another library to get CasADi objects.
3 advantages:

• Model imported from file.
• bindings for matlab and python
• semantics of KinDyn computation which match the computation we do for floating base dynamics and that we use in the paper. There are several choices on how you can define the dynamics, and it is important to be clear on the semantics.
  We can consider implementing an interface which respects these 3 advantages.
  This library can be outside of iDynTree with a class from which you get the derivatives of the object you are interesed in, in the format you need. We can consider having as input directly an iDynTree model.

(Diego) What if we want to exploit automatic differentiation to learn inertial parameters. So I get q from the robots, would it be possible?

(Silvio) When you load the model, you usually take it from a file and the parameters are already there. Then you can substitute the parameters with a symbolic variable.

(Diego) Let's assume we create from scratch an interface similar to kindyncomputations. What should we change? I guess vector and matrices types. Inside there is also the model. In my opinion, relying only on CasADi may be limiting in the future. What is, also the vectors and matrices are interfaces for which we may have multiple implementations, including CasADi, but also Eigen, pytorch. Does it make sense?

(Silvio) Based on the existing libraries that do that, the safest bet is to use templates instead of interfaces.

(Diego) Yes, but templates are way more complex to start and to mantain.

(Giulio) Actually, Pinocchio is alreay very templated, so it should not be so difficult to mantain. Anyway, if we plan to use Pinocchio, only CppAD and CasADi, while pytorch is not supported, we are limited to that anyway.

(Diego) How are defined the operations on vector and matrices type on Pinocchio?

(Giulio) I only used in python and only with doubles
(Silvio) The complete list of methods and operators required is not written anywhere, I think they kind of expect the operators of Eigen.

(Diego) So why not creating already an interface with all the operators defined?
(Silvio) I don't know which kind of operators may be required
(Stefano) I would propose to start with a single type, then later on we can try to move to an interface.
(Giulio) stack-of-tasks/pinocchio#911

(Silvio) For me the minimum viable product is to first test the interface to have the 3 advantages above and use only Eigen types for the time being. Then we can check the consistency between iDynTree and this interface, then we can move to Casadi.
Another task would be to sort out the semantics differences between pinocchio and iDynTree. (robotology/idyntree#674)
(Giulio) Another macrotask would be to understand how to translate the iDyntree model to the Pinocchio model.
(Silvio) I would say that these two tasks may be independent because in the first version we may directly use a Pinocchio model.
(Giulio) Another task is to create a skeleton, with the CMake machinery which is not trivial

(Dani) Which level of C++ is needed in all these activities.

(Giulio) I would say that KinDyncomputations would require more knowledge of templates, while the for the model there are other difficulties but less templates.

Action points

(Dani) A possible work distribution can be:

• Stefano -> templates
• Giulio -> for the model
• it may be a nice exercise for Giuseppe to carry on the skeleton activity
• Silvio creates the repo (idynfor)
• Diego keep an eye open
• Stefano the entry point

(Diego) Please tag me for any PR

[DanielePucci]

CC @dic-iit/dynamic-interaction-control

[lrapetti]

Just as curiosity, what does the name idynfor stands for?

[DanielePucci]

@lrapetti, idynfor will, besides other things, be a tool that makes use of other tools and allows us to use some others. Hence, the library is for these other tools. It also represents the 4th big iteration of our library, so it was nice that for sounds pretty much like four. Analogously, idyntree was the third iteration of the library, and tree sounds like three.

[traversaro]

Analogously, idyntree was the third iteration of the library, and tree sounds like three.

Fun fact: idyntree was not the third iteration of the library, but rather the second. The tree/three assonance was non intentional and a common misunderstanding in the users. The name is a kind of pun on this, as it is not meant to be a drop-in replacement iDynTree for several use cases at least for the moment, so calling it as iDyn 2.0/3.0/4.0 was not reflecting the real situation.