MocoInverse vs MocoTrack

[Ana de Sousa]

Hi! I have a question regarding the use of MocoInverse in simulations, particularly when pipelining predictions for muscle-driven models.

Here's the context:

In my cycling simulations, I initially used torque-driven models (without muscles) for their speed and simplicity, which allowed me to quickly identify issues. However, when transitioning to muscle-driven models, I've been using the results from the torque simulations as trajectories to be tracked using MocoInverse.

The simulations converge, but the results are not physically feasible (there's a lot of variation in crank speed, which was basically constant in torque-driven solutions). To try to address this, I've tried:

1. filtering the muscle-driven result as an initial guess.
2. decreasing the tolerance.
3. increasing the muscle forces.
4. increasing the reserve actuators.

Unfortunately, none of these changes led to significant improvements. Additionally, I'm unable to achieve convergence when using synergies (afther the MocoInverse), I think it is because of the speed variation.

One suggestion I received was to avoid using MocoInverse and instead solve the problem in the same way as the torque-driven model, but using the muscle-driven model. The idea is to use the torque-driven trajectories as an initial guess for the muscle-driven model.

This got me thinking that I don't fully understand what MocoInverse is doing, and I would appreciate some clarification. I'd also like to hear your opinion on directly transitioning to muscle-driven predictions.

From what I understand, MocoInverse is essentially tracking motion from the torque-driven simulations, but it doesn't account for the dynamics (i.e., moments or forces). It's a method of tracking the motion but not the forces, correct?

Also, I understand that MocoInverse is different from MocoTrack, as MocoTrack prescribes (i.e. imposes) the movement, while MocoInverse doesn't, allowing the movement to change (which is possibly causing the issue with the speed). Is that correct?

I would greatly appreciate any clarifications, tips, help, support regarding my understanding about MocoTrack and MocoInverse, and whether switching to muscle-driven predictions directly would be a better approach.

Thanks in advance!

[Jon Stingel]

Hi Ana,

Happy to try and help a little. Based on your descriptions it could be good to clarify a few things about your problem setup, as well as working definitions for the different tools.

MocoInverse problems are typically going to be problems were you have some kinematic information that you would like to exactly match, and you want to solve for the actuator behavior needed to generate this. You can, however, also add forces to the inverse problem by prescribing them to the model as external loads (e.g. ModOpAddExternalLoads is used to add ground reaction data in some of the examples) which will also be directly applyed in the problem. So, in this case, the optimizer is going to try and find the set of muscle activations that can generate the provided motion/forces to the best of its abilities. If you provide external forces and kinematics that don't mesh well, the optimizer could have a hard time doing this and may not find a solution.

Second is MocoTrack. In this problem, you have more freedom to specify what things you want the optimizer to match or track. For example, you could prescribe the GRF, just like a MocoInverse problem, but track the input kinematics (while allowing the optimizer to deviate in order to find a good solution). Or, you could track both the input kinematics and GRF, allowing the optimizer to deviate from each of them to find a solution.

For your problem, its sounds like you are taking good steps, a couple of thoughts:

• If you are happy with the kinematics and forces in the torque-driven problems, putting them directly into a MocoInverse problem seems reasonable. This way the kinematics/external forces shouldn't change; you would just need to ensure that your muscles are capable of generating the same joint torques (and include any residuals that were present in the torque driven solution).

• Switching to a MocoTrack problem is also another feasible approach as it gives the optimizer more freedom (but increases the problem complexity).

Perhaps you can say more about what predictions you are trying to make, as that may inform the best route to take.

Hope this helps!
Jon

[Ana de Sousa]

Hi Jon, thanks a lot for your detailed response - it is really helpful.

I want to share more about my setup so you can hopefully provide further guidance.

I'm working with fully predictive simulations, so I use no experimental data. I can reliably predict a torque-driven problem (e.g., maintaining 30 rpm cycling for 10 seconds) and extract both the movement and dynamics from that (using ideal actuators on hips and knees, with ankles locked).

I then feed this kinematic information into MocoInverse. I wouldn't expect the kinematics to be hard to solve because it's essentially a four-bar system with the pelvis and ankles fixed. For dynamics, I've constrained the pelvis and ankles to the bike's positions (seat, crank, pedals, etc), which means I can't add external loads as far as I know (and I wouldn't want to, given that I'm not using experimental data).

However, MocoInverse isn't predicting the kinematics as accurately as I'd hoped - it does converge, but the resulting motion doesn't match well (see attached images). This might be related to the issue you mentioned about external forces and kinematics not aligning properly?

With that in mind, do you think it's worth trying MocoTrack just to handle the kinematics and let the optimiser adjust other aspects?

torque_driven.png (57.2 KiB) Viewed 164 times

muscle_driven.png (125.2 KiB) Viewed 164 times

Thanks again!
Ana

[Jon Stingel]

Thanks Ana,

I think I still don't quite have a full understanding of the problem setup and model configuration, but it's starting to sound like it could be something regarding the model constraints that you have, and how you are setting up the problem. Here are a few more thoughts/questions:

• Do you have the same constraints for the pelvis and feet (or ankles?) for both the torque-driven and muscle-driven problems? How are these constraints set up?

• You lock the ankle joint; if you don't want the ankle to move, I may recommend to actually implement a weld joint instead. This tends to work better in Moco problems.

• Are there large residual actuator activities in the results of the torque-driven problem? Do you still have the reserve and residual actuators in the model for the MocoInverse problem? A good way to debug if not would be to include the same torque actuators in addition to the muscles (at least to start), so that you know the model is capable of recreating the same motion.

Hope these are helpful!
Jon

[Ana de Sousa]

Hi Jon,

Thanks again for this conversation. Reviewing the modeling part is indeed on my to-do list.

Here are the answers to your questions:

1. "Do you have the same constraints for the pelvis and feet (or ankles?) for both the torque-driven and muscle-driven problems? How are these constraints set up?"

I'm constraining the feet and pelvis differently. For the feet, I use a ConstantDistanceConstraint between the calcaneus and the pedal on each side:

Code: Select all

right_foot_constraint = osim.ConstantDistanceConstraint(
    calcn_r,
    osim.Vec3(configBike.pos_calcn_x, configBike.pos_calcn_y, 0.),
    pedal_r,
    osim.Vec3(0.),
    distance_pedal_foot
)

For the pelvis, I replace the existing joint with a weld joint. This also addresses your question about locking vs. welding-it's just an old habit of mine to say "lock" In reality, I'm welding:

Code: Select all

osim.ModelFactory.replaceJointWithWeldJoint(model, "back")
osim.ModelFactory.replaceJointWithWeldJoint(model, "ankle_r")
osim.ModelFactory.replaceJointWithWeldJoint(model, "ankle_l")
osim.ModelFactory.replaceJointWithWeldJoint(model, "ground_pelvis")

2. "Are there large residual actuator activities in the results of the torque-driven problem?"
No, there is no residual actuator in the torque-driven problem.

3. "Do you still have the reserve and residual actuators in the model for the MocoInverse problem?"
I only add the residual actuators afterward:

Code: Select all

model_processor.append(osim.ModOpAddReserves(5))

[Jon Stingel]

Hi Ana,

That all sounds good. I would go back to my previous message and start by just making sure that the model with muscles has the capacity to generate the same motion (potentially by including the full strength torque actuators from the torque-driven problem).

Another thought: assuming you have some sort of effort term in your cost function, changing to muscles from torque actuators is going to change the objective value, which can lead to a different result. You may need to do some tuning in order to get the same kinematic results.

Happy to help troubleshoot further!
Jon