Model scaling and Moco

[Ross Miller]

Hi all,

I've had some trials/tribulations recently in generating "multi-subject" simulations of walking, using the ScaleTool in OpenSim to alter a generic model's height and mass for Moco simulations, and thought I would share them. Might save some time and trouble for others.

Suppose you have a good simulation result for one model, then want to scale the model and use the old unscaled model's simulation result as the initial guess for the new scaled model. Will this work well? My experience has been that it will not work well if you substantially change the height of the model. What this seems to do, at least with the typical OpenSim model definitions where the pelvis is jointed to the ground, is it produces an initial guess where the model's feet are either a considerable distance above or below the ground. This generates large violations of the system dynamics constraints, which IPOPT seems to struggle with minimizing.

How to fix this? What's worked reasonably well for me is to scale the model in the OpenSim GUI, which places the scaled model visually right next to the original model, then adjust the height of the scaled model's pelvis coordinate until its feet are just sitting on the ground like the original model, then add that pelvis height adjustment to the initial guess to be used with the scaled model. Here's an example Matlab code where I added 6 cm of pelvis height:

Code: Select all

% Load a previous solution and adjust its vertical pelvis coordinate
prevSolution = MocoTrajectory('previous_solution.sto');
prevPelvisTy = prevSolution.getStateMat('/jointset/groundPelvis/pelvis_ty/value');
prevPelvisTy = prevPelvisTy+0.06;
prevSolution.setState('/jointset/groundPelvis/pelvis_ty/value',prevPelvisTy);
solver.setGuess(prevSolution);

There are probably better/more efficient/more automated ways of doing this, but I think the spirit of it (adjust the height of the pelvis in the initial guess to avoid physically impossible foot contact situations) is good advice.

I've also had better results (more consistent convergence) by running the initial simulation with a new scaled model on a coarse grid, e.g. 10 intervals per step instead of 50. This coarse grid will usually converge on a good result then I can use it as the initial guess on a finer grid. Often for the coarse grid I'll have to relax the convergence criteria a little.

Lastly, I discovered recently that the ScaleTool was not adjusting the values for optimal fiber length and tendon slack length if using DGF muscles, prior to the latest OpenSim 4.4 release. So if you are using ScaleTool and DGF muscles and expecting those values to be scaled as they normally are with that tool, make sure you're using 4.4, or if not using 4.4, define the muscles as some other type and convert them to DGF type after scaling.

Ross

[Nicholas Bianco]

Great post Ross!

It's also been my experience that problems with foot-ground contact are sensitive to the pelvis/model height. I usually take the latter approach of generating an initial solution on a course grid to let the model figure out orientations and positions of the feet relative to the ground that produce good contact forces. But this approach is interesting too. Do you think it actually saved you time in the end, compared to just creating a new initial guess?

I did want to clarify one thing about the ScaleTool bug. Pre-4.4, if you were scaling model with Millard2012EquilibriumMuscles and then converting to DGF muscles, then your model would still have the correct optimal fiber lengths and tendon slack lengths. But if you replaced the model muscles with DGF muscles before scaling, then yes, you would have incorrect values.

-Nick

[Ross Miller]

Great post Ross!

It's also been my experience that problems with foot-ground contact are sensitive to the pelvis/model height. I usually take the latter approach of generating an initial solution on a course grid to let the model figure out orientations and positions of the feet relative to the ground that produce good contact forces. But this approach is interesting too. Do you think it actually saved you time in the end, compared to just creating a new initial guess?

I also first generate a solution on a coarse grid, I'm just using the previous solution from another similar model to generate the guess on that coarse grid. I'm not sure if the approach I described saves time vs. other approaches, but it does seem to converge with good consistency for the model I'm using recently (~30 DOF, ~100 muscles). It's been a while since I've tried any other approaches.

I did want to clarify one thing about the ScaleTool bug. Pre-4.4, if you were scaling model with Millard2012EquilibriumMuscles and then converting to DGF muscles, then your model would still have the correct optimal fiber lengths and tendon slack lengths. But if you replaced the model muscles with DGF muscles before scaling, then yes, you would have incorrect values.

-Nick

This is what I was I meant as well, sorry if I was unclear. ScaleTool definitely works as expected on other types of muscles pre-4.4, or at least on Millard muscles (I haven't checked all of them).

If performing a tracking problem of kinematics and GRF, where you have all the data needed to run CMC, I keep meaning to try a CMC solution as the initial guess. This seems like it would work well and would fit nicely in some sort of automated workflow, but I haven't tried it.

Ross

[Nicholas Bianco]

I also first generate a solution on a coarse grid, I'm just using the previous solution from another similar model to generate the guess on that coarse grid. I'm not sure if the approach I described saves time vs. other approaches, but it does seem to converge with good consistency for the model I'm using recently (~30 DOF, ~100 muscles). It's been a while since I've tried any other approaches.

Thanks for the info. It's definitely a nice idea; I'm always interested in ways to automate this stuff, especially when creating initial guesses. Creating the initial guess for optimal control problems often feels like the equivalent to the model scaling step for the standard OpenSim pipeline.

This is what I was I meant as well, sorry if I was unclear.

No, you were clear. I just wanted to add a little more detail here for others reading.

If performing a tracking problem of kinematics and GRF, where you have all the data needed to run CMC, I keep meaning to try a CMC solution as the initial guess. This seems like it would work well and would fit nicely in some sort of automated workflow, but I haven't tried it.

I'd be curious too if this would work well. My concern for that wouldn't be that the CMC solution would be a good initial guess, but it might not be worth taking the time to get CMC to work for every problem you want to solve.

One idea I've had is to solve the following series of problems:
1. Solve a torque-driven kinematic + GRF tracking problem
2. Use the solution from step 1 to solve a MocoInverse problem with muscles
3. Combine the solutions from step 1 and 2 for a muscle-driven tracking problem initial guess

I think the problems in step 1 and 2 could be set up to solve fairly consistently.

[Ross Miller]

One idea I've had is to solve the following series of problems:
1. Solve a torque-driven kinematic + GRF tracking problem
2. Use the solution from step 1 to solve a MocoInverse problem with muscles
3. Combine the solutions from step 1 and 2 for a muscle-driven tracking problem initial guess

I think the problems in step 1 and 2 could be set up to solve fairly consistently.

That's a good idea, and would probably work better than CMC (ground contact dynamics violations would be smaller/zero).

[Evan Dooley]

Just wanted to second (or third) the idea of the simulation with foot-floor contact seems to be very sensitive to initial pelvis height of the model. More specifically, if one of the contact objects starts under the floor the simulation will time-out or converge to an unreasonable solution for the dynamics violations Ross mentions.

I fixed this in my torque driven set up by raising the pelvis height 2 cm in my initial guess (using Matlab API):

Code: Select all

%%  Set initial location & orientation & SPEED
                            % get motion
                            stateTable = readtable(stofilename,'FileType','text','VariableNamingRule','preserve');
                            allCoords = model.getCoordinateSet();
                            for k = 0:allCoords.getSize()-1
                                coord = allCoords.get(k);
                                coordName = string(coord.getName());
                                coordPath = char(coord.getAbsolutePathString()); % need to add '/value' to use in state info
                                % set up position
                                init_position = stateTable.([coordPath,'/value'])(1);
                                if contains(coordName,'_ty')
                                    init_position = init_position + 0.02;
                                end % clear floor
                                problem.setStateInfo([coordPath,'/value'],[coord.getRangeMin(), coord.getRangeMax()],init_position);%[coord.getRangeMin(), coord.getRangeMax()]
                                % set up speed
                                init_speed_min = min(stateTable.([coordPath,'/speed']));
                                init_speed_max = max(stateTable.([coordPath,'/speed']));
                                init_speed_bounds = [init_speed_min, init_speed_max];
                                rangeBuffer = max(abs(init_speed_bounds))*0.25; % can go 25% above and below the recorded max/min for the trial
                                speed_range = [init_speed_min-rangeBuffer, init_speed_max+rangeBuffer];
                                problem.setStateInfo([coordPath,'/speed'], speed_range, init_speed_bounds); % set the speed info to the problem statement
                            end

This works for scaling my model (based on Rajagopal 2016 model) to three different people of varying height/mass (137cm/27kg; 171cm/63kg; 175cm/71kg). The start of the simulation is the model coming down to the floor, but I have started ahead of the step of interest that the model has settled by the time it gets to that step.

However, when I move to the muscle driven simulations 2 cm seems to be too far off, so I have been setting it up to guess that the pelvis height is the pelvis height from the IK results for the walking trial. Though I am very new to the muscle driven simulations, so there could be compounding factors making this solution not hold as well.

Thanks for having this discussion on the forum to share the ideas with the rest of us. Always greatly appreciated.

Best,
Evan

[Nicholas Bianco]

Hi Evan,

I often don't track the pelvis_ty coordinate value for exactly the reasons you've illustrated. I will track the pelvis_ty speed though, and if you want to track the pelvis_ty value trajectory, but not the magnitude, you can add a scale factor to MocoStateTrackingGoal via "addScaleFactor".

-Nick

[Ross Miller]

I also often do not include pelvis_ty (or the other two pelvis translations) in tracking.

Ross