simtk.org

Hi everyone,

I don't think we'll implement a "symmetry" constraint in the way that you're describing it. To me, a model kinematic constraint (as discussed below) is the most natural way to constrain your system in these cases. There's no way to avoid additional forces related to constraints: if you constrain the kinematics of your system via a constraint, there must be a force to enforce the motion.

When using Simbody kinematic constraints, additional constraint forces is added to the system explicitly to enforce the constrained motion. These forces are generated via a set of Lagrange multipliers that are transformed to generalized forces via multiplication with the system's constraint Jacobian. (This isn't exactly how it works in Simbody for reasons related to computational efficiency, but this explanation is equivalent and sufficient for the discussion here).

Lastly, if you're only concerned with left-right symmetric motions, why not just simulate a 2D model? The model could have one leg with double strengths in the muscles. It's always prudent to simplify your model as much as possible while still retaining the salient features important to answering your research questions.

Best,
Nick

Hi Nick,

I missed your response here.

I don't think we'll implement a "symmetry" constraint in the way that you're describing it. To me, a model kinematic constraint (as discussed below) is the most natural way to constrain your system in these cases. There's no way to avoid additional forces related to constraints: if you constrain the kinematics of your system via a constraint, there must be a force to enforce the motion.

I think I may have been unclear about the type of constraint I was suggesting. I was suggesting a constraint (or cost term) that lets you constrain the control space of the optimization. Something like [activation_muscle_1 - activation_muscle_2] = 0. I think this limits the possible coordination patterns available to the model, without inducing constraint forces. This has applications beyond enforcing bilateral symmetry in 3D, it's a flexible way of investigating many control strategies. I think you could use it to enforce synergies (if the specified muscles are on the same side), force fan shaped muscles that are split up in a model to have similar excitations (if you believe they can't be individually controlled), and also investigate the effect of bilaterally symmetric control strategies in an asymmetric model.

Cheers,
Pasha

Hi Pasha,

Ah okay, we actually do have something like this in a test case: https://github.com/opensim-org/opensim- ... s.cpp#L901.

It wouldn't be too hard to convert this to a real MocoPathConstraint.

-Nick

Hi Nick,

Cool that something like this is in the works! I'm not too sure how to interpret the code in the link you've posted. Are these essentially trials that, if they work, make it into future releases of moco?

Cheers,
Pasha

Hi Pasha,

This is just a test case that we run every time that we make a change to the codebase to make sure that nothing has broken. If there's enough interest it could potentially make it into Moco, but no guarantees.

My preference would be to implement support for OpenSim Controllers instead, as that would enable this application as well as other interesting applications (e.g., muscle synergies).

-Nick

Hello Nick and Pasha,

Thanks a lot for the feedback. I think there are some nice crossroads from what I'm trying to do, what Nick showed with the piece of code, and what Simon Jeng did in the other forum topic with his own MocoFrameOrientationConstraint . For specific research questions, we will need to code (sometimes) our specific goals.

About using two legs, I really cannot escape it. This is the start of a long project where soon asymmetries will be added, tracking of subjects movements, and so on. Hope I can help with this symmetry question later. I will try to document the progress here.

Best regards.

rosshm wrote: ↑

Wed Dec 22, 2021 7:51 am

Does the solution have non-zero controls for the coordinate actuators? That is possible, though seems unlikely.

I've had issues before where the GUI couldn't find muscles that weren't placed under the "ForceSet" tag in the .osim file.

Ross

Ross!

Just an update, I think I found out why the GUI AnalyzeTool was giving zero values at the ForceReport. I was not providing the controls file for the tool (only had the states files at the moment). Just realized it because my API call to the AnalyzeTool had this step. To compare everything "I gave it a try" in order to compare the results with the same inputs.

Hi Carlos,

About using two legs, I really cannot escape it. This is the start of a long project where soon asymmetries will be added, tracking of subjects movements, and so on.

No worries. If that's what you need, that's what you need. I ask a lot of questions here because in many cases Moco already has the capabilities that people need, but that's not always the case.

Hopefully Simon's addition works well for you.

Best,
Nick