Dealing with armature in crba, computeAllTerms and other dynamics algos

[proyan]

Currently we can load the rotor parameters inside Pinocchio, but they are not used anywhere in the algorithms. As a result, forwardDynamics, and ImpulseDynamics are useless if you need the armature, since both internally computes the mass during computeAllTerms.

I can take care of adding the armature values to crba and computeAllTerms by either: 1) Modify the current algos and add a (by default armature is zero) value to the mass diagonals() 2) create a separate algo.

Would (1) be okay with you?

[proyan]

@jcarpent It would definitely be useful if implemented. That is why I started this issue. Obviously it is not an immediate concern for crocoddyl, since there are ways around a proper implementation that we are using. But I see that you feel motivated to finally close this issue, so I don't want to discourage you ;).

[gabrielebndn]

Adding Coriolis effects to the motor rotations would certainly make the model a bit more precise, but I think usually they are sort of negligible due to the high gear ratio. For one thing, they are usually neglected when modelling series elastic actuators (Spong assumption). If we limit ourselves to rigid robots: does JointMimic support dynamic computations? Because, if it does, I think the motor effects could be perfectly simulated (including Coriolis) using existing Pinocchio machinery: it would be enough to add a JointMimic, where the reference joint is the real joint, the scaling is equal to the gear ratio, and the link is the motor. How about that?

[jcarpent]

From my point of view, the actual state of JointMimic is not the correct design choice. I would rather suggest handling the presence of a gear ratio only for JointRevolute, with dedicated math for it but yet simple.

But the very long-term strategy would be to add the notion of transmission and actuation, and I do think, as @nmansard, that this should be done in Pinocchio to take into account the real sparsity of the operations.

[cmastalli]

@jcarpent handling the structure defined by actuation and mechanism is a good motivation to extend Pinocchio in this topic. Having a quick and dirty solution that is just engineering, it should be avoided because it creates distraction. I believe dirty solutions can always been implemented by any user in their internal projects.

Maybe it is also relevant to discuss how we could describe these models, inside the SRDF? Or using the mechanism tags of the URDF used in ros-control?

[jcarpent]

I think SDF format is the right choice.

[jviereck]

What's the status of this? The reflective inertia is sort of important for lightweight robots like solo and bolt. I might be able to contribute some time for implementing this feature given that someone provides me with a rough idea on what needs to be done.

[jcarpent]

As many new inovative features, these are already in place in https://github.com/stack-of-tasks/pinocchio/tree/pinocchio3-preview

[jviereck]

This is amazing, thanks for the information!

[jcarpent]

@jviereck This remains unsafe in the sense that the API may change (slightly) + it may still have some bugs (to fix).

[jcarpent]

Done in pinocchio-3x which should be released soon.