Torque-Driven Marker Tracking Problem

[Katie Blessinger]

Hi all,

I'm working on a project that's similar to the example3DWalking (marker tracking example), but I'm looking to track a sit-to-stand motion. I'm working with a modified version of the Caruthers 2016 model for STS, and I've been able to produce IK/ID results with my model in OpenSim, but haven't been able to get MocoTrack to converge to a solution. Since I can produce IK/ID in OpenSim, I don't think there is an issue with my GRF/marker data files or model scaling process.

The model that I'm using has most of the upper body joints locked (elbow flexion, shoulder flexion etc.), and the lower body joints are not locked. [See fig for visual reference.]. I'm starting with a torque-driven model (like the marker tracking 3D gait example), with coordinate actuators at each of the lower body joint dof's (hip flex, knee flex, etc.). Also, for reference, I have been limiting iterations to 3000 (for time), but can increase this

I have a couple of questions that I'm hoping will help me be able to figure out why my MocoTrack problem is not converging:
1. If joints are locked (like the upper body joints in my model), Moco still treats them as states in the control problem (I believe). [In the .sto file that's produced after 3000 iterations (not converged), I can see my locked joints as columns.] Since my model has a large number (~20 joints) of upper body joints locked, does this significantly slow down the convergence? Is it better to replace these locked joints with weld joints? I'm wondering if my 3000 iterations was too small for this large number of states?

2. If it is fine to leave these joints as locked, should I be adding coordinate actuators to all of the model's joints? (Even if they are locked?) I currently am only adding actuators to the lower body (non-locked joints). (I'm wondering if my model just isn't actuated enough to move?)

Sorry for the lengthy post! Hopefully my explanation makes sense. (Happy to provide clarification or more details about the model/my matlab code, etc. if needed)

Enjoy the long weekend!
Katie Blessinger
Ohio State

[Nicholas Bianco]

Hi Katie,

Is the position of the model in the image you've posted the initial state of the model in the initial guess you provide to the problem? If so, that will be an issue, because the contact spheres at the feet are penetrating deep below the contact half-space. The contact half-space is visualized with that teal square, but the half-space extends infinitely in all directions. So the spheres at the feet are actually producing very large contact forces due to the large penetration depth, which will definitely lead to problems to fail. What you really need here is a contact "platform" that only produces forces on the visualized square. For now, you can try simulating a "squat-to-stand" problem, where the initial state is when the model's butt just lifts off the chair.

If joints are locked (like the upper body joints in my model), Moco still treats them as states in the control problem (I believe). [In the .sto file that's produced after 3000 iterations (not converged), I can see my locked joints as columns.] Since my model has a large number (~20 joints) of upper body joints locked, does this significantly slow down the convergence? Is it better to replace these locked joints with weld joints? I'm wondering if my 3000 iterations was too small for this large number of states?

Yes, I usually recommend replacing joints with WeldJoints to remove the unneeded states from the model. Locked coordinates are enforced via kinematic constraints, so it's also good to not have the problem deal with these constraints when the joint can just be welded. You can weld joints using ModelProcessor and the ModelOperator 'ModOpReplaceJointsWithWelds'. If for some reason you absolutely need to leave a locked coordinate in, add a CoordinateActuator to the joint so it can enforce the kinematic constraint.

Best,
Nick

[Katie Blessinger]

Hi Nick,

Thanks so much for the quick reply! Very helpful!

I'll follow up if I have more trouble, but doing the "squat" instead of "sit" and switching to welds seems to be helping so far (I had HUGE objective function values before)

Thank you!
Katie

[Katie Blessinger]

A couple follow up questions related to this (and the single leg squat to stand example):

For adding coordinate actuators to joints:
The example's addCoordinateActuator() function has actu.setMinControl(-1) and actu.setMaxControl(1). Do these just mean "on" in the flexion and extension directions? So for example, -1 for actuating knee extension and +1 for actuating knee flexion?

Just wanted to check that adjusting the strength of coordinate actuators is done via the setOptimalForce (for Matlab interface) and not the max/min control

Initial positions in MocoTrack, if not set in script by user
If we do not specify the initial position of the model, does Moco use the default model position (like the default position if you open the model in OpenSim) as an initial state of the model in the initial guess for the problem?

Thanks all!
Katie

[Nicholas Bianco]

Hi Katie,

1) Yes, use setOptimalForce() to set the strength of the actuator. setMinControl and setMaxControl set the bounds for the actuator control.

2) What do you mean by initial position of the model? Do you mean the value in the initial guess, or the initial value in the trajectory? By default, Moco uses the midpoint value between coordinate bounds to generate an initial guess if none is provided.

The initial values in the trajectory isn't constrained by default, but you can set bounds on these values using setStateInfo(). To do this with MocoTrack, you will need to get access to the underlying MocoStudy using MocoTrack::initialize().

-Nick

[Katie Blessinger]

Thanks Nick!
(Sorry I worded my second question poorly, but you answered it for me!)

Thanks again,
Katie