Tropter Solver

[Aaron Fox]

Hi Moco Team,

I am running an optimisation that includes parameters (contact sphere locations and radii) within a tracking simulation (tracking states and GRFs). Effectively I'm trying to solve for the torque controls of a running gait cycle while optimising the contact sphere parameters to match up to the experimental GRFs (similar to the tracking simulations described by Falisse et al. 2019 - https://doi.org/10.1098/rsif.2019.0402). I recall reading somewhere that the Tropter solver is the better option when including parameters, and the mass optimisation example included in the Matlab code uses Tropter - correct?

I am able to run the mass optimisation code fine and it runs quite quickly (~ 8 seconds or something). The problem I'm trying to solve is much more complex than this (I think 42 states, 19 controls, and 36 parameters) - and this results in a much higher number of seeds for the Jacobian (i.e. 205 vs. less than 10 in the mass example). It seems that unlike with the CasADi solver where iterations are progressively reported, the Tropter solver doesn't report anything after the seeds until a solution is found. Due to this it seems difficult to understand if the solver is progressing - the reason I ask is the aforementioned problem I've set up has been running for approximately 16 hours and is still going. Understandably optimal control solutions can take a long time - but I guess I'm just querying whether there's a way to get a progress check or get the current solution (i.e. if you stop a CasADi solver you still get the current non-converged solution printed).

Any advice would be much appreciated.

Thanks,

Aaron

[Christopher Dembia]

The CasADi solver is fine for parameter optimization if the parameter is a model property that does NOT require invoking Model::initSystem() to take effect. We can easily optimize the stiffness of an OpenSim SpringGeneralizedForce with the CasADi solver because this property does not require Model::initSystem() to take effect. See the CasADi solver's "parameters_require_initsystem" property.

Unfortunately, the locations and radii of contact spheres do require Model::initSystem() to take effect. You can still use CasADi solver but it will be extremely slow, because invoking initSystem() is quite expensive.

The Tropter solver should report information about each iteration; make sure you leave the solver's verbosity at its default setting.

To get information about intermediate iterations, set the solver's optim_max_iterations to a small number, and unseal() the solution returned by solve().

[Christopher Dembia]

If you're willing to fix your kinematics to your experimental kinematics, then calibrating your contact parameters does not require solving a direct collocation problem. I suggest that, instead, you solve an optimization problem with variables for only the contact parameters, with no constraints, and minimize the error between the contact force data and the model-generated forces.

For an example, refer to this extremely messy (and probably no longer functional) sandbox code: https://github.com/opensim-org/opensim- ... ontact.cpp.

Furthermore, I think Antoine Falisse's experience is that calibrating the contact parameters is not essential to obtaining good contact forces. Minor changes in kinematics can improve the match between modeled and experimental contact forces, regardless of the contact parameters.

[Aaron Fox]

Fair enough - thanks Chris. I guess my hope was to optimise some of those aspects at the same time (i.e. minor kinematic changes with adapting contact parameters). I agree though that a more simple optimisation procedure focusing on only one thing (i.e. only kinematic changes or contact parameter changes) would simplify this issue.

I did read that from Antonie's paper - and I do hear a bit that contact parameters don't matter that much - the problem is my simulations never end up that way as soon as I add contact

[Christopher Dembia]

Solving the combined tracking+calibration would be great, but given Moco's current state, I would discourage this approach.

Have you looked at the latest example2DWalking code in the Moco repository (post-0.3 release)? With the help of Brian Umberger, this example now includes GRF tracking.

Personally, I find it more pleasant to start with a problem that works already and slowly evolve the problem to the one you hope to solve.

Since you are experienced with extending Moco in C++, you have another option available: use or develop your own contact model that does not depend on Simbody. You can design your OpenSim component such that initSystem() is not necessary.

You might be able to extend the existing 2D point contact models we have in Moco: https://github.com/opensim-org/opensim- ... actForce.h

We haven't advertised these components because they are not fully developed or tested.

Please let us know if you want to go this route; I'm happy to chat with you about the details.

[Aaron Fox]

Hi Chris,

Thanks for the feedback.

I'm not sure I have the capacity yet to extend the contact models outside of Simbody within C++ (I'm still somewhat teaching myself some aspects of this language) - but am interested in the other contact force classes you pointed out. Are there any specific advantages to using the different contact models outlined in the 2D point contact classes you linked to?

I'll have a look at the updated 2D walking example and see how it works with my current simulation problem.

Aaron

[Christopher Dembia]

Happy to help with extending/editing the models.

The advantage is that you can optimize the parameters of the contact model with CasADi solver without requiring initSystem().

[Brian Umberger]

Hi Aaron,

I was also considering optimizing contact sphere parameters in one of our application where it might actually be worth the effort. I appreciate the discussion in this thread about whether that is worthwhile, and suggestions for more efficient ways to go about it. Regardless, I do have a procedural question though.

If I add a MocoParameter to an existing problem that works (like the 2-D walking example) it does not get added to the initial guess. Even if I update or reset the problem, I get an error like:

Input 0 (x0) has mismatching shape. Got 2795-by-1. Allowed dimensions, in general, are:
- The input dimension N-by-M (here 2796-by-1)

In this case I added only one MocoParameter so x0 was too small by one element. Did you encounter this issue, and if so what was the solution, as it sounds like you got an optimization running.

Thanks,
Brian

[Aaron Fox]

Hi Brian,

I did encounter this error - and my solution was to avoid it

I noted the same thing as you, that the number of additional parameters added aligned with the shape error message. The error kind of prompted me to think back to the parameter optimisation examples, and I recalled that it was recommended the Tropter solver be used for this. I switched back and that fixed the error - so I assumed that was the source of the problem. Now that Chris has mentioned the Casadi solver can be used for parameter optimisation I guess it does suggest that some sort of bug/error is causing this, rather than just the solver being used.

Aaron

[Christopher Dembia]

I think the issue is using MocoTrack, which can set a guess for you but does not account for optimizing a parameter.

Try solver.clearGuess() before solving the problem to see if that'll make the error go away.

Here's how we set an initial guess for a parameter optimization when using MocoTrack:
https://github.com/stanfordnmbl/mocopap ... #L646-L683