Moco goals for average speed in cycling model

[Nicholas Bianco]

Hi Ana,

Is there a practical difference between setting the max force to 10.0 and letting the control signal roam from -1 to 1?

The main thing to consider is the effect on the control effort cost. If the control signal is between [-1, 1], then the control cost integrand at a time point is never larger than one. But if the control signal is between [-10, 10], and you're using a squared cost, then the instantaneous cost can be as large as 100. And then those instantaneous costs will be integrated over the trajectory.

So, in short, the size the control signal can rapidly inflate the control cost, which then might dominate other cost terms (if you have a multi-objective cost function, which you do here with your tracking goal). I usually recommend to keep control signals between [-1, 1] to make cost function term weighting easier. (If all trajectory variables are near [-1, 1] it can also help the optimizer converge, but you can also automate this with scale_variables_using_bounds).

Best,
Nick

[Ana de Sousa]

Hi Nick, that makes sense. I changed it back to control ranged from -1 to 1.

I am grateful for your assistance over the past few weeks. I'm confident to say that the issue I mentioned in this post has been successfully resolved. Thanks again! =]

[Ana de Sousa]

Hi everyone!

I resumed the simulations recently and would like some extra help, if possible. I have the human model with 4 actuators on the joints (left and right hip and knees), and the feet are connected to the pedals of a crankset.

With your help (thank you!), I've achieved the following milestones:

P1) Joint Torque Prediction for Position Change: I can predict the joint torques needed for the model to move from an initial position to a final position (e.g., 0 to 360).
P2) Joint Torque Prediction for Speed Pattern: I can predict the joint torques required for the model to follow a speed pattern. For instance, I can determine the torques needed to make the model cycle at 180deg/s for 2s. I use the solution as a guess for subsequent periods.

Presentation1.png (111.18 KiB) Viewed 8386 times

However, I'm struggling with P2. Specifically, the simulations do not converge for durations beyond 4s.

Attempts made:
1. Using the unsealed .sto file as a guess for the next solution. I've concatenated it 5x.
2. Increasing the number of meshes.
3. Introducing both speed and angle patterns (made the convergence worse).

Simulation details:
- Tolerance values: convergence - 1e0, constraint - 1e-2
- Number of meshes: frequency * duration time (frequency set to 10)

Goal and boundaries:
I have one goal focused on speed tracking and specific boundaries.

Code: Select all

tracking = osim.MocoStateTrackingGoal()
tracking.setName('speed_tracking')
tracking.setReference(ref)
tracking.setAllowUnusedReferences(True)
tracking.setWeightForState('/jointset/crank_angle/crank_angle/speed', 1.0)
tracking.setWeightForState('/jointset/crank_angle/crank_angle/value', 0.0)
problem.addGoal(tracking)

problem.setTimeBounds(0.0, end_time)
problem.setStateInfo('/jointset/crank_angle/crank_angle/value', [], 0.0, [])
problem.setStateInfo('/jointset/crank_angle/crank_angle/speed', [-np.deg2rad(max_speed*1.2), np.deg2rad(max_speed*1.2)], 0, [])

Do you have any suggestions?

But I have some specific questions regarding guesses:

1. If I run the optimisation and use the solution as a guess for the same problem (same time duration, tolerances, etc.), shouldn't it converge at iteration 1? I'm experiencing issues with this.
2. How does the "guess" work for different time frames? If the final time of the guess is 4.0s, and I extend the problem to 4.5s, what happens? Does it use random values in this 0.5s, or does it interpolate to 4.5?

Again, I truly appreciate all your time and assistance. Cheers!

[Ross Miller]

Hi Ana,

If my math is correct here, it looks like you might be simulating an almost-impossibly-fast condition and that might be where the convergence trouble is coming from. Model is rotating the crank at ~175 rad/s, which is a "cadence" of about 28 pedal revolutions per second or almost 1700 rotations per minute. A "normal" cadence in cycling is more like 90 rotations per minute. For something that fast, I'm guessing a mesh density of ~10 nodes per second isn't enough to resolve the dynamics of such a fast motion.

Not sure how you are implementing the pedaling speed in the model currently, but I guess my suggestion is to slow it down and see if that helps the convergence.

Also on your first question, the "interior-point" algorithm (the IP in IPOPT) "bumps" the solution away from the initial guess before the optimizer starts. So even if the initial guess already meets the convergence criteria, iterations will still run.

Ross

[Ana de Sousa]

Hi Ross, thanks for the answer!

In the plots, I wrongly wrote rad/s; it is deg/s. My bad! The velocity is 1/2 cycle per second, or 1 cycle every 2s. So, this should be fine.

What do you mean by "bumping the solution"?

[Ross Miller]

IPOPT perturbs the initial guess from the initial guess that's provided by the user by a small amount.

[Ana de Sousa]

IPOPT perturbs the initial guess from the initial guess that's provided by the user by a small amount.

Ah, that explains a lot. Thanks a lot, Ross! Do you know if there is a way to modify that? Also, do you have some idea what happens in a case where my guess is, for example, 4s, and I try to predict something for 4.5s? Edit: another question that I have is regarding the number of meshes. If they are different, what does IPOPT do? Does it interpolate?

If you could also indicate a place to look for that information, that also works for me. Cheers!

[Ross Miller]

IPOPT perturbs the initial guess from the initial guess that's provided by the user by a small amount.

Ah, that explains a lot. Thanks a lot, Ross! Do you know if there is a way to modify that? Also, do you have some idea what happens in a case where my guess is, for example, 4s, and I try to predict something for 4.5s? Edit: another question that I have is regarding the number of meshes. If they are different, what does IPOPT do? Does it interpolate?

If you could also indicate a place to look for that information, that also works for me. Cheers!

In IPOPT I believe the parameter "eps" in "ActualGuess = ProvidedGuess + eps" is adjustable, but not sure how or if that adjustment can be easily accessed in Moco. I've never adjusted it in ~15 years of using IPOPT for various things so I don't think it's usually a source of problems.

IPOPT simply won't run if the guess isn't compatible with the problem, so the resolutions to those things are all Moco-specific. I'm not sure what happens in Moco when the guess and problem have different time bases or different mesh resolutions but Nick can probably clarify.

Ross

[Nicholas Bianco]

I'm not sure what happens in Moco when the guess and problem have different time bases or different mesh resolutions but Nick can probably clarify.

Moco will resample the portion of the trajectory in the guess that matches the time range defined by the MocoProblem. In other words, if your guess contains time points between [0, 2] seconds, but the problem only lies between [0, 1] seconds, the values in the guess between [1, 2] will be ignored.

[Ana de Sousa]

Hey Nick and Ross, these answers clarified a lot, thanks!