Matlab version of example2DWalking

[Ross Miller]

Also again, I've noticed that with the default Hermite-Simpson collocation scheme, when you set the number of intervals to N, you get a collocation problem that is solved at 2N+1 nodes. From reading up on H-S I believe the solutions at these "extra" nodes are real, it's not just graphically interpolated data (maybe Nick or Chris can comment on that). So at least for walking, setting the number of intervals to 100 is probably overkill, you could probably get away with 50 intervals and this will also speed up the time per iteration quite a bit. Faster movements might need finer grids though.

Ross

[Karthick Ganesan]

Dear Ross Miller,
With wrapping, after displaying the number of threads the iterations never started. After waiting for less than an hour I terminated the program.
Thanks for sharing your experience on mesh refinement and for your comments on the number of nodes.. It is very useful.
Thanks,
Karthick.

[Christopher Dembia]

Ross,

With Hermite-Simpson, the solution contains N + 1 time points for the endpoints of the N mesh intervals, and N time points for the midpoints of the mesh intervals. This is what Betts calls a "separated" Hermite-Simpson formulation.

-Chris

[Pasha van Bijlert]

Hello all,

I tend to periodically refer back to this thread because of all the valuable information in it. I've been playing around with tendon dynamics, and a few comments on page 1 and 2 of this thread caught my eye. The example code provided by prof. Umberger constrains periodicity of the joint kinematics, and the muscle activations. If you enable tendon dynamics, but don't enforce tendon symmetry, does this imply that you could get solutions where you have fully symmetric joint kinematics and muscle activations, but potentially (slightly) asymmetric muscle forces? In other words, if you're looking for simulations which are symmetric with respect to the start and ends of each half-stride, should you enforce tendon symmetry as well?

Similarly, control symmetry is also not constrained, I believe. Is there a benefit to adding this to the formulation as well?

Best wishes,
Pasha

[Ross Miller]

Hi Pasha,

I think you'll want to add periodicity constraints for both the tendon forces and the controls. The forces are state variables in Moco so they need their own periodicity constraint. Same story for the controls, periodic activations won't ensure periodic excitations.

If you're simulating a full stride of locomotion (and want everything to be periodic except the pelvis progression), this code should work:

Code: Select all

% Define the periodicity goal
periodicityGoal = MocoPeriodicityGoal('periodicityGoal');
problem.addGoal(periodicityGoal);

% All states are periodic except pelvis anterior-posterior translation
for i = 1:model.getNumStateVariables()
    currentStateName = string(model.getStateVariableNames().getitem(i-1));
    if (~contains(currentStateName,'pelvis_tx/value'))
       periodicityGoal.addStatePair(MocoPeriodicityGoalPair(currentStateName));
    end
end

% All controls are periodic
for i = 1:model.getNumControls()
    currentControlName = string(problem.createRep().createControlInfoNames().get(i-1));
    periodicityGoal.addControlPair(MocoPeriodicityGoalPair(currentControlName));
end

Ross

[Pasha van Bijlert]

Hi Ross,

After incorporating these constraints, the optimizer converges a lot (6x) faster than if you have it run without. I was getting periodic gait before, but the controls & tendon forces were probably not perfectly periodic. I'm trying it out a couple of more times to see if the speed increase was just a fluke, but it does make sense since the problem is under-constrained if you're not enforcing tendon periodicity.

Thanks for the inspiration for scripting the controls as well. I wonder if it's actually necessary for the final result, to have fully constrained activation + tendon dynamics, and also fully constrained control periodicity? I.e.: if activation and tendon force are constrained to be periodic, does this not automatically converge to periodic controls as well? Either way, incorporating it as an extra constraint definitely reduces the search space, so I guess it's a good idea regardless.

I've combined your strategy for periodic full-stride controls with prof. Umberger's single-step code and incorporated it like so:

Code: Select all

% Symmetric controls
for i = 1:model.getNumControls()
    currentControlName = string(problem.createRep().createControlInfoNames().get(i-1));
    
        if contains(currentControlName,'_r')
            pair = MocoPeriodicityGoalPair(currentControlName, ...
                           regexprep(currentControlName,'_r','_l'));
            symmetryGoal.addControlPair(pair);
        end
        if contains(currentControlName,'_l')
            pair = MocoPeriodicityGoalPair(currentControlName, ...
                           regexprep(currentControlName,'_l','_r'));
            symmetryGoal.addControlPair(pair);
        end
end

Pasha

[Ross Miller]

The excitation-activation relationship is a function of both activation magnitude and activation "rate" (slope, dAct/dt), at least generally speaking. I think this is also the case for Moco's muscle model. Without a controls periodicity constraint, I think what will happen is you will get activations that are periodic, but the slopes of the activations will not (necessarily) be periodic, and same story for the muscle forces (magnitude is periodic but not slope) even if the generalized coordinates and speeds are periodic.

I think this will be the case at least for any model that has more muscles than DoF.

Ross

[Pasha van Bijlert]

Hi Ross,

Thanks for that explanation! I suppose it's like fitting a slightly different curve through the same start and end point.


Pasha