What makes an optimisation 'infeasible'?

[Aaron Fox]

Hi All,

I'm currently encountering an issue while trying to run a muscle-driven tracking simulation of sprinting. It is structured in a very similar way to the walking examples that come packaged with Moco (i.e. a combination of state & GRF tracking, with effort and symmetry goals too). I've been able to solve this as a torque-driven simulation, and am now progressing to a model that contains muscles - fairly simplistic though with no passive forces, and only the plantarflexors having tendon compliance. Given this, I know the muscles are the problem in my optimisation not solving.

The problem seems to be the dual infeasibility values (inf_du in IPOPT output), as these just continuously inflate through iterations (up to e+10!). So my question is, what aspects within an optimisation contribute to this dual infeasibility calculation - with particular reference to muscles. It's a fairly broad question and probably has a number of answers - but I'm interested to see if there is anything clear that could be contributing to this issue.

Aaron

[Aaron Fox]

UPDATE HERE: It's possible the removal of residual actuators at the pelvis were playing a role in the inflation of the inf_du values here. In my haste I realised that these had been removed from the initial torque driven problem, and adding them back I'm seeing much less of an inflation in the dual infeasibility.

If anyone cares to weigh in that this is another potential reason to confirm that would be great!

Aaron

[Pasha van Bijlert]

Hi Aaron,

I definitely had issues related to very high infeasibility when adding tendon compliance of many muscles, while still using explicit tendon dynamics. For a simpler model, I still got away with explicit tendon dynamics, for a more complex one I didn't.

A second issue worth considering (which you may already have done, so sorry if it's obvious): when switching from torque based actuation to Hill-type muscles, you also need to worry about whether your muscles can provide the required amount of force over the correct joint ranges. If they can't, then the available amount of joint torque might be too low. I get around this by setting the fiber lengths in each muscle as a fraction of the length change it experiences when moving the related joint through a relevant range (as described by Sellers et al. 2013). In your case you're probably using actual human measurements, but it's still worth considering if they lead to internally consistent muscle tuning (since the Hill type muscle isn't a perfect representation).

Cheers,
Pasha

[Ton van den Bogert]

I can confirm Pasha's suggestion. In my work on sprinting, I had to make the muscles faster and stronger (increase Fmax and Vmax). With "normal" muscle properties, my model could not run faster than about 3 m/s.

This also explains why it works better with reserve actuators: they can increase the joint torques beyond what the muscles can do. Reserve actuators will make it easier to find a solution, but you're not exactly using a model based on physics and physiology anymore. This will overestimate sprint performance. You could use the solution with reserve actuators as an initial guess, perhaps, for a final solution that is only driven by muscles.

Recently, I tend to avoid feasibility issues by allowing muscle excitation and activation to go as high as 500%. Then, when the solution has muscle activations much higher than 100%, I know that the muscle was probably too weak or too slow. Then I know where the model might need to be improved. I think this is better than reserve actuators.

Ton van den Bogert

[Ross Miller]

Hi Aaron,

"Infeasible" here I think means IPOPT can't find a solution that meets the convergence criteria. I don't have a great understanding of what inf_du is exactly (inf_pr I think is the largest constraint violation) but from the IPOPT implementation paper it looks to be the gradient of the problem or something similar, so a high value indicates the current point is not close to a minimum. Similarly, when IPOPT iterates and can't gradually reduce inf_du to ~zero, it means that it's not able to proceed downhill towards a minimum. IPOPT is more complicated than this in reality but I think that's the basics of it.

I've not had good results for complex models on fine collocation grids with a torque-driven solution as the initial guess for a muscle-driven problem. My model with 31 DoF and 84 muscles on a 100-node grid has 31x3x100=9300 unknown states and controls for a torque-driven problem (not bad for direct collocation) but adding the 84 muscles balloons this up to (31x2 + 84x3)x100 = 31,400 unknowns, plus another 8,400 if the contractile dynamics are implicit, plus all the constraints associated with them. It's a vast increase in problem complexity and if the initial guess is not good on a problem like that (i.e. has large constraint violations of the muscle state equations), IPOPT will struggle.

For me it worked better to use a muscle-driven model from the beginning and increment the complexity of the model and the grid density. Then once I have a good solution with the model complexity and grid density that I want, that seems to work well as the initial guess for other problems, e.g. a good solution for walking can be the initial guess for running. But to get that good solution for walking, I first did it with a 2-D model on a coarse grid, gradually refined the grid with that model, then gradually added complexity to the model one piece at a time, each time repeating the optimization with the prior grid's or prior model's solution as the initial guess.

I agree with Ton that supra-maximal excitations are a better approach than reserve actuators.

Hope this helps,
Ross

[Pasha van Bijlert]

Hi all,

I really like the idea of allowing supra-maximal excitations & activations to find out what's limiting your model, thank you!

Ross, I just found this in your UMocoD scripts, is this how you'd implement it in Moco?

Code: Select all

problem.setStateInfoPattern('/forceset/.*/normalized_tendon_force', [0, 1.8], [], []);
problem.setStateInfoPattern('/forceset/.*/activation',   [0.001, 1.0], [], []);

Where presumably you'd scale up the upper bound on both the normalized tendon force up from 1.8, and activation up from 1.0, to some desired value.

Would something like

Code: Select all

problem.setControlInfo( '/forceset/.*' , [0.001, 2]);

work for clamping controls between 0.001 & 2 for all controllable muscles in the forceset? I'm not sure if I'm using that '.*' expression correctly.

Cheers,
Pasha

[Ross Miller]

I normally set the max bound on the control and activation to 2.0 to implement this.

I've not previously changed the bounds on the normalized tendon forces, but I'm also usually simulating walking, where the peak forces are not usually close to 1.8*Fo. For movements like sprinting it may be necessary to set the max muscle force bounds to something larger as well.

Ross

[Aaron Fox]

Hi All,

Thanks for the various suggestions. Agree with Pasha that the supra-maximal activations is a great idea! One of those things where I've always added reserve actuators to solve that problem, but simply allowing the muscles to activate more also helps solve that initial issue.

Aaron