Accelerations initial guess with implicit multibody dynamics

[Ross Miller]

Hi all,

Suppose I have a MocoSolution with explicit multibody dynamics, and I want to use this as the initial guess for a problem with implicit multibody dynamics. Generating that guess is easy enough, I can use solver.createGuess() and put the previous solution's states and controls in there, but since that solution had no acceleration states, createGuess() is populating the values for those states and is (I think) just setting them all to zero. This leads to an initial guess with very large constraint violations, which I think is part of the trouble I'm having getting implicit dynamics to work well.

Is there a way to get Moco to generated an educated guess at the accelerations, e.g. by differentiating the generalized speeds in the explicit solution?

More generally, so far I've not found much benefit to using implicit multibody dynamics in Moco. The combination of explicit multibody dynamics and implicit muscle contractile dynamics seems to work much better. By "work" I mean converges consistently in a reasonable number of iterations and CPU time, with reasonably low cost. I've tried lots of different approaches to using implicit multibody dynamics and am not able to get consistent convergence with good tracking and low weights on the accelerations on a fine collocation grid. This is for 3-D tracking and predictive simulations of walking. The need to include the accelerations and dF/dt for muscle forces with the implicit formulation also concerns me. For dF/dt I don't think it's a big deal, it seems I can put a small weight on those such that they are a trivial part of the cost function, but for the multibody accelerations I often need to put a heavy weight on those to get convergence and there are lots of movements where that's not ideal. Sometimes I can then take that solution as the initial guess for a problem with small weight on the accelerations and repeat that process iteratively until they are a tiny fraction of the cost, but I haven't gotten that process to work yet on fine grids, and even if it goes work it's time-consuming and in the end produces essentially the same result I started with with the explicit dynamics solution.

I mention all this because I'd be interested in learning if others have gotten better results using implicit multibody dynamics, and how you've done this and for what types of simulations. I always used implicit formulations in DC problems prior to Moco and had good results with them, but the formulations I was using didn't need the accelerations and dF/dt in the cost functions, and I think that is what's throwing me off.

Thanks much!
Ross

[Nicholas Bianco]

Hi Ross,

We added a few methods to MocoTrajectory for this purpose: check out generateAccelerationsFromValues() and generateAccelerationsFromSpeeds().

I agree with your concerns about implicit dynamics in Moco, and ideally we don't need to use such high weights to get convergence. We've tried scaling trajectory variables and while it didn't seem to have a large impact on convergence, we should revisit scaling as it should improve performance. Especially for acceleration variables, since their peak magnitudes can be much larger than coordinate values and excitations/activations.

It's a little confusing that Moco works better with explicit dynamics, since others (e.g., Ton) find better performance when using implicit dynamics. Ton also includes all trajectory variables in the cost to help regularize the problem; we could consider including an option for this in Moco as well (although this should benefit both implicit and explicit dynamics).

It's been very helpful to know that you get good results with explicit dynamics. I've borrowed some of your settings from the UMocoD project for my simulations and have found similarly good results using explicit dynamics. If explicit dynamics works well like this for most problems, then maybe improving implicit dynamics isn't crucial. Although I'm curious to get more feedback from others using implicit dynamics.

-Nick

[Ton van den Bogert]

It is nice that MOCO allows you to do these tests, and even use implicit for muscles, and explicit for multibody dynamics!

Here are some random thoughts:

With my own code, I never compared implicit to explicit dynamics on the same optimization problem with the same model, so this may still be an open question. When I switched to implicit dynamics, this also gave me exact analytical derivatives (without finite difference approximation) so the comparison would not be fair.

My implicit dynamics method does not introduce accelerations as additional trajectory variables, so that may be a difference.

Intuitively, implicit dynamics should be numerically more stable because accelerations (which are potentially near infinity) are never solved from the equations of motion. You can even have a singular mass matrix, as long as the stiffness matrix is not zero (I tried that).

Another potential advantage of implicit multibody dynamics is that the Jacobian is sparser, though not extremely so. The mass matrix is zero whenever row and column DOFs are in different kinematic branches (limbs). The inverse mass matrix is always dense. Also the block that couples DOFs to muscle states becomes dense in the explicit formulation: all muscles accelerate all DOFs. See Fig 3 in my 2011 IUTAM paper for an illustration.

Better condition number and sparsity of the Jacobian should both be good for the NLP solver.

If the Jacobian of the trajectory optimization problem is estimated with finite differences, it could be more costly with implicit dynamics because there are more trajectory variables. Implicit dynamics f(q,qd,qdd)=0 has three Jacobians, while in explicit dynamics qdd = f(q,qd) you only have two. But the third one is simply the mass matrix, which should already be available without finite differences, if the code can take advantage of that knowledge.

To isolate the effect of condition number (mass matrix vs. inverse mass matrix), we should only look at the number of iterations in the NLP solver. The total computation time would also be affected by sparsity and how many finite differences were needed.

Ton van den Bogert

[Ross Miller]

Hi Nick,

I'm getting some strange behavior when I use generateAccelerationsFromSpeeds() and am not sure if it's a bug or I'm using it wrong:

Code: Select all

guess = MocoTrajectory('previous_soln_with_implicit_muscles_and_explicit_multibody_dyanmics.sto');
guess.generateAccelerationsFromSpeeds();
solver.setGuess(guess)

When I run this code I get an error that the problem has implicit auxiliary derivatives for normalized_tendon_force of the muscles but the trajectory does not. However, the previous solution in the .sto file does have those derivatives. If I use createGuess instead to generate a guess then populate it with the states and controls of that same .sto file, the code runs fine:

Code: Select all

guess = solver.createGuess();
prevSolution = MocoTrajectory('soln_track_N50_w50_6.sto');
prevStatesTable = prevSolution.exportToStatesTable();
prevControlsTable = prevSolution.exportToControlsTable();
guess.insertStatesTrajectory(prevStatesTable, true);
guess.insertControlsTrajectory(prevControlsTable, true);
solver.setGuess(guess);

but then I don't have the generated values for the accelerations, I just have whatever createGuess() makes (I think it uses zeros for them). If I add generateAccelerationsFromSpeeds() to this code:

Code: Select all

guess = solver.createGuess();
prevSolution = MocoTrajectory('soln_track_N50_w50_6.sto');
prevStatesTable = prevSolution.exportToStatesTable();
prevControlsTable = prevSolution.exportToControlsTable();
guess.insertStatesTrajectory(prevStatesTable, true);
guess.insertControlsTrajectory(prevControlsTable, true);
guess.generateAccelerationsFromSpeeds()
solver.setGuess(guess);

I get the same error (no auxiliary derivatives in the guess trajectory.

Any guesses? It seems like generateAccelerationsFromSpeeds() is deleting the auxiliary derivatives from the trajectory but maybe I'm using it wrong.

Ross

[Nicholas Bianco]

Hi Ross,

Ah darn, you've found a bug. Yes, the auxiliary derivatives are getting deleted when generateAccelerationsFromSpeeds() is called. I wrote that helper function before we had compliant tendon dynamics, and forgot to update it.

As a workaround, you should be able to use the addDerivative() function on MocoTrajectory to back in the implicit muscle derivatives.

-Nick

[Karthick Ganesan]

Oh. Thanks. I was also struck with the same issue. Now got the answer.

[Ross Miller]

Hi Karthick,

Have you gotten good results with implicit multibody dynamics? I'd be interested to know your solver settings and general workflow if you have. I'm still struggling with it.

Ross

[Karthick Ganesan]

Hi Ross Miller,
I am also struggling with it. My work flow is quite similar to yours. Its hard to get good convergence. I stopped at some point . I may have to start trying again.

Karthick.