Stronger model, but no higher jumps

[Carlos Gonçalves]

I'm working on predictive simulations of squat jumps, and everything seems okay. However, since I decided to work with the same model but with higher/stronger muscle maximum isometric forces, I couldn't get the expected increase in jump height.

I'm using a set of two goals nowadays, the major one is a MocoMarkerFinalGoal measuring the top of the head related to a virtual target really high (a jump of 60cm), and another MocoControlGoal to prevent unexpected cocontraction.

This strategy was already in Direct Methods for Predicting Movement Biomechanics Based Upon Optimal Control Theory with Implementation in OpenSim, https://link.springer.com/article/10.10 ... 015-1538-6, where only the jump height is maximized.

Any suggestions for explaining this behavior?

If I simulate a 100% increase in all muscles' maximum isometric forces, I get roughly the same height but with less muscle activation. Does it make sense? Do I need to change my goals' weight for every new model variation?

Best regards.

[Ton van den Bogert]

You are right, the jump should be higher.

I don't think it is the goals weighting. With less activation, the controls goal now has a lower value and that would still favor a higher jump.

It would be good to plot the optimal controls. In a maximal effort task, the optimal control solution should be "bang-bang" which is the muscle should be either at the minimum or at the maximum control input, never in between. When solving these problems numerically, it is always good to check that solutions are consistent with known optimal control theory.

The first thing I would look at is the bounds on the state trajectory. Maybe something else (other than muscle strength) is limiting the performance. Maybe your angular velocities are already at the upper bound, for instance.

Ton van den Bogert

[Carlos Gonçalves]

Thanks a lot for the reply, Prof. van den Bogert,

That is an excellent point. I'm attaching the activations and muscle moments for the main muscles for the right hip joint. At the left is the reference model, and at the right is the stronger model (100% increase in max isometric force). Sorry for the legend and labels in Portuguese.

problemStrongModel.png (169.24 KiB) Viewed 997 times

Going through my log files and also my code, I could see that I have the following states:

• Coordinates values
  The most important coordinates (hip, knee, ankle) have initial and final bounds to mimic a squat jump.

• Coordinates speeds
  Used the same setting for all: problem.setStateInfoPattern('/jointset/.*/speed', [], 0, 0), resulting in [-50 50] (default)

• Muscle activation
  All bounded to [0.01 1] (default)

• Norm tendon force
  All bounded to [0 5] (default)

Inspecting the plots, I couldn't notice any saturation (capping) in the states, even in the implicit derivative of the norm. tendon force. But I realized maybe I shouldn't set the final bound of pelvis_tx speed and pelvis_tz speed to 0.0.

During the simulation visualization or analysis, I get some warnings regarding "buckling" and "exceeding maximum contraction velocity" at the flight phase. I don't know if this might be a clue to solving the problem.

I will try something with these new bounds for pelvis_tx speed and pelvis_tz speed and post the result here.

Best regards.

Carlos

[Ton van den Bogert]

Carlos,

Thanks for posting those graphs. Your muscle activations don't look like the expected bang-bang control. You are probably aware of the old work from Stanford and Amsterdam on squat jump optimization [2,3]. These demonstrate a bang-bang control solution.

The 50 rad/s bound on angular velocities should be high enough (based on a quick calculation).

With setStateInfoPattern() you are requiring all linear and angular velocities to be zero at the final time. That is a difficult task, and maybe this is why the muscles can't be fully utilized.

For a maximal height jump, maybe you should not constrain any velocities at the final time. If an unconstrained final state produces unrealistic movements, you can still add certain bounds or objectives to prevent that.

If I understand correctly, the buckling warning means that the fibers are shortening faster than maximum shortening velocity, and if Hill's equation is extrapolated, that would produce a negative fiber force, causing the series elasticity to buckle because it can't carry compressive loads.

It's not surprising that muscle fibers reach their maximal shortening velocity just before toe off in a maximal effort jump. Maximum shortening velocity can be a performance-limiting factor in explosive movements. If your jump height is unrealistically low, you could consider increasing the maximal fiber shortening velocity in the model. In sprint running, Nicos Haralabidis [1] did this: "We set the maximum shortening velocity parameter of all the MTUs to be 12 optimal fibre lengths per second based upon an in vivo estimate of the maximum shortening velocity of human muscle (De Ruiter et al., 2000)."

I don't know if those buckling warnings mean that the solution is still valid. If the model simply produces zero muscle force in that case, it would be fine, as long as the optimization is still successful. It would be hard to impose a trajectory bound on the shortening velocity because it's not a state variable. It would be good to hear from the Moco team about this.

In my own work (not with Moco), I give the series elasticity a small compressive stiffness. Then, a negative fiber force does not cause numerical problems. If the optimization objective has a small term related to muscle effort, negative fiber force is automatically avoided because it requires control effort while resulting only in a very small amount of force. That way, the dynamics is smooth and does not require any "if" statements that can introduce discontinuities in the 2nd derivative. If Moco deals with it in a different manner, that would be fine, as I mentioned.

Ton van den Bogert

[1] Haralabidis N, Serrancoli G, Colyer S, Bezodis I, Salo A, Cazzola D. 2021. Three-dimensional data-tracking simulations of sprinting using a direct collocation optimal control approach. PeerJ 9:e10975.

[2] Pandy MG, Zajac FE (1991) Optimal muscular coordination strategies for jumping. J Biomech 24: 1-10.

[3] van Soest AJ, Schwab AL, Bobbert MF, van Ingen Schenau GJ (1993) The influence of the biarticularity of the gastrocnemius muscle on vertical-jumping achievement. J Biomech 26: 1-8.

[Ross Miller]

I would try to removing the ControlGoal entirely or setting its weight to some trivially small value even if it is not suspected to be the problem. If the cost function is something like J = (height-0.60)^2 + w*u^2, the stronger model could be choosing to jump at a submaximal height with submaximal excitations and this has a lower score than jumping to max height with ~max excitations if w is large.

It seems to me like jumping for max height should implicitly limit co-contraction since the co-contraction will limit your maximum joint moments.

Brian Umberger did a study a while ago on constraints necessary to simulate the full movement (jumping and landing), I can't remember the details but it was a lot of constraints. It would be interesting if including the landing movement greatly affects the peak jump height, that would be a nice paper!

Ross

[Carlos Gonçalves]

Thanks a lot for the comments, Prof. van den Bogert and Prof. Miller;

I've been dealing with those issues in the last month or more, and it is great to discuss them in such detail. I really appreciate it.

Regarding the buckling, I don't know if they are holding back the final jump height (20cm COM displacement from standing in plantarflexion, starting from the squat position with the reference model), but I will look at this with help of this tool https://github.com/modenaxe/MuscleParamOptimizer mentioned here viewtopicPhpbb.php?f=1815&t=12159&p=0&s ... 8bdc2e9421.

Thanks a lot for the references Prof. van den Bogert. I will take a good look at them. I have an optimum control background, but I need to dive into using it with biomechanics problems. I will try to remove the speed final bounds and report later here (I thought of enhancing the time zone intersection, sending now what I got at hand). I will also see what can be customized with DGF muscles regarding stiffness and damping (right now, I have no damping in fibers and tendons).

Prof. Miller, I already tried running the simulation without control goals, but the result has massive cocontractions, even in the flight phase. Generally, I got a smooth jump with a control weight of 10 and a final height weight of 2000. Below are the final costs for the simulations

Reference

• Control - 85.9294189209457

• Height - 325.25279141247125

• auxiliary_derivatives - 0.5559613396692317

Stronger

• Control - 69.38503879388713

• Height - 368.33886599025027

• auxiliary_derivatives - 0.38721244887486767

I totally agree the jump height may interfere with landing. We are currently working on a paper simulating jump height error estimation with a time-of-flight approach focusing on the different positions of the ankle between takeoff and landing. From what I regularly see, it is common that the position is different because there is an involuntary preparation to absorb the impact, which will make the jump height overestimated using only the time-of-flight. I hope this model can also help this in the future.

I hope to get back soon with some news. Thanks again and best regards.

Carlos

[Ross Miller]

I guess it's not surprising the model uses lots of muscle activity when airborne and without the control goal term since that activity doesn't affect the jump height.

Most jumping simulations I know of have only simulated the ground contact phase then extrapolated the jump height from the take-off conditions. Including the airborne phase and the landing is hard!

Have you tried using a smaller weight on the control goal? It looks like it's a fairly large portion of the overall cost function score. I would speculate there is some small weight that gets the model to jump close to the expected height and then also not use much muscle activity in the airborne phase.

Ross

[Carlos Gonçalves]

That's a great point, Ross.

I think my initial approach was to create a jump that should resemble a jump evaluation. Where, with arms akimbo, it often appears that full triple extension of the hip, knee, and plantarflexion. Maybe I started in the wrong direction, or the available Moco goals drove me to this current setup.

To simulate only the takeoff phase, the cost function would require a cost function to handle the center of mass velocity (maximize). Is it feasible? Maybe customizing some goals? Or using MocoOutputGoal?

Looking back, that might be the reason for what I'm doing. I tried my best with what was available.

Fun fact, at least we could laugh a little bit one year ago looking at this https://www.youtube.com/watch?v=ZSA0C-g ... ealsohuman and remembering Fernando Tatis "double-jump" (viewtopicPhpbb.php?f=1815&t=12049&p=0&s ... d26623f96d)

I will try creating a full-value search for the control weight; fingers crossed. Right now, the computer is running the simulation with no final bounds for coordinates speeds (except pelvis_ty). Double fingers crossed.

Thanks a lot again. Best regards.

Carlos

[Ross Miller]

CoM velocity would need a custom goal I think. Since it is not a state of the model, I don't think it could be used in MocoOutputGoal, but you could try something like pelvis vertical velocity with MocoOutputGoal.

Which Goal are you using for tracking of the 60-cm marker currently? I've been meaning to try something like this for sprinting.

Ross

[Carlos Gonçalves]

The jump height cost was designed using a custom marker on the top of the head and the MocoMarkerFinalGoal, as in the code below.

Code: Select all

finalCost = osim.MocoMarkerFinalGoal()
finalCost.setName("alturaSalto")
finalCost.setWeight(listParam[parmDict['targetWeight']])
finalCost.setPointName("/markerset/Top.Head")
finalCost.setReferenceLocation(osim.Vec3(0, listParam[parmDict['alturaMarcaF']], 0))
problem.addGoal(finalCost)

The behavior is not optimum since the top of the head may vary its distance to CoM in the flight phase, but it is doing its job for now. Later I won't escape coding myself some custom goals. For example, the left and right symmetry is obtained because it seems to be the most efficient way for the costs.

I will add to my TODO list researching the MocoOutputGoal and pelvis velocity.

Best regards. Great to share those thoughts with you all.

I hope I can share some new results on the changes discussed here. Convergence is far, far away.

Carlos.