Compute second-order derivative of generalized static torque

[IoannisDadiotis]

Hi,

I would like to ask how can I analytically compute the second-order derivative of the generalized static torque wrt the configuration vector q.

\tau = g(q) - \sum J(q)^T f_{ext}

I can see in the documentation there is computeStaticTorque() and computeStaticTorqueDerivatives() but not a direct method for the second-order derivative.

I am encountering the following options:

• Differentiating each term separately, according to which:

  \frac{\partial^2 \tau}{\partial q^2} = \frac{\partial^2}{\partial q^2}(g(q)) - \sum \frac{\partial^2}{\partial q^2}(J(q)^T) \cdot f_{ext}

  However, for this the second-order derivatives of the generalized gravity terms and the frame Jacobian are needed. I am not sure what is the way to go for these computations.

• Using ComputeRNEASecondOrderDerivatives(). I saw that you have already included the RNEA second-order derivatives so I guess maybe I can compute what I want by calling this function with zero generalized velocities and accelerations (to render the computation equal to static torque case), right? Regarding this option I have few questions:

  1. Why the external forces are not included as parameters of ComputeRNEASecondOrderDerivatives()?
  2. How efficient in terms of time is ComputeRNEASecondOrderDerivatives() for the static case? In particular, are computations related with the derivatives wrt velocity and acceleration ignored? (regardless of static or dynamic case it would be nice to be able to compute separately each derivative). From a fast comparison between computeStaticTorqueDerivatives() and ComputeRNEADerivatives()(zero velocity and acceleration) I realized that the latter requires two-three times higher execution time. This makes me think that using the RNEA derivatives may not be optimal for the static case. I used std::chrono for capturing the time.

Thank you in advance for any information!

P.S. While writing this issue I realized that ComputeRNEASecondOrderDerivatives is written with capital C in contrast to other compute*methods in pinocchio. So maybe this is something you want to fix in the future.

[jcarpent]

P.S. While writing this issue I realized that ComputeRNEASecondOrderDerivatives is written with capital C in contrast to other compute*methods in pinocchio. So maybe this is something you want to fix in the future.

Yes, you're totally right. I will fix this issue.

[cmastalli]

Hi @IoannisDadiotis,

Pinocchio's support for second-order derivatives is not fully available. This goes beyond implementing classical algorithms, and it requires further research. This responds to your first question.

When computing the first or second-order derivatives for static torques only, then we can leverage this fact and reduce computation. This could be written in Pinocchio's documentation, I agree with this. I hope this responds to your second question. But if you are keen to know more about it, then it is most probably useful if you read Justin's and other papers on this topic.

Cheers, Carlos

[IoannisDadiotis]

Hi @cmastalli and thank you for the fast response! From your answer I understand that currently in pinocchio it's not possible to compute the second-order derivative of the generalized static torque wrt the configuration q under the presence of external forces (since the is no support for external forces in ComputeRNEASecondOrderDerivatives).

From my side the issue can be closed if you or @jcarpent have nothing to add.

[jcarpent]

We can do it. It will take time and certain engineering efforts. @IoannisDadiotis How do you want to collaborate on it?

[jcarpent]

@IoannisDadiotis kind reminder ;)

[IoannisDadiotis]

@jcarpent thanks for the reminder.

I don't think I have the time needed for this, considering that I am just a user of the library and I don't have previous experience on low-level developments within pinocchio. I have thought that for my application maybe it is easier and faster to access the 2nd order derivatives using automatic differentiation with CppADCodeGen.