Getting "resultant knee force" from a state trajectory?

[Ross Miller]

Hi all,

I would like to compute, as an output in post-processing of a Moco simulation, the "resultant force" at the knee joint, in an inverse dynamics sense i.e. the typical "force at the joint" calculated from an inverse dynamics analysis.

The output from Moco's "joint reactions" seems to be what I would usually call a "joint contact force":

resultant_force = muscle_forces + joint_contact_forces + any_other_forces_like_ligaments_etc

Alternatively, if there's a way to resolve the muscle forces along the axes of a particular body's reference frame, I could then compute the resultant_force with the above equation.

Thanks!
Ross

[Aravind Sundararajan]

Hi Ross,

I believe you want to iterate through the states in the states trajectory and realize the model to accelerations? and you can call calcReactionOnChildExpressedInGround for each relevant joint? This might not be the right call. I had previously used the muscle geometry paths to resolve forces in the body reference frames moving up the kinematic chains in a post hoc analysis, but that was for joint contact forces as well

-Sunny

[Karthick Ganesan]

I think one could do an inverse dynamic analysis through the OpenSim's ID Tool using the Moco Solution. I have not tried it though.
-Karthick.

[Ross Miller]

Thanks Sunny and Karthick

calcReactionOnChildExpressedInGround

I think this is what I'm already doing. "Joint reactions" in OpenSim are what many of us refer to as "joint loads" or "joint contact forces":

https://simtk-confluence.stanford.edu:8 ... s+Analysis

I think one could do an inverse dynamic analysis through the OpenSim's ID Tool using the Moco Solution

I think this would work to get resultant joint moments, but since the axial knee translation is not a DoF in my model, it would not give me that axial resultant force that I'm looking for. I guess I could make it a DoF and lock it or weld it, not sure how Moco handles that though.

Ross

[Pasha van Bijlert]

Hi Ross,

This might be a semantics issue, but that link on the joint reactions says "Specifically, it calculates the joint forces and moments transferred between consecutive bodies as a result of all loads acting on the model."

Isn't this exactly what you're after? The way that I'm interpreting that terminology is that the joint reactions in opensim are what you might call constraint forces when setting up the equations of motion manually. Those should then oppose the combined effects of muscles, ligaments, any other actuators, inertial forces, etc. Basically, exactly all the forces and moments required to stop any two segments from "flying apart". Is that not correct?

Edit: The link also says: "These loads represent the contributions of all un-modeled joint structures that would produce the desired joint kinematics, such as cartilage contact and any omitted ligaments." which is how I'd describe constraint forces


Cheers,
Pasha

[Ross Miller]

The OpenSim/Moco joint reaction force is a constraint force of sorts, but I don't think it's equal to the inverse dynamics joint force as a general rule.

The typical "joint force" from typical inverse dynamics (this force goes by many names so I'm just calling it "joint force" F, which is the force I want to know) is the sum of all internal structural forces at the joint, regardless of whether those structures are explicitly modeled or not:

Code: Select all

F = (sum of muscle forces) + (sum of ligament forces) + (sum of contact forces) + (joint capsule tension) + (skin tension) + (clothing tension) + etc.

Inverse dynamics doesn't know anything about those structural forces, it just calculates F from the motion of the model. Most of the forces on the right-hand side of my equation above are not explicitly defined in the model. Usually we only have muscle forces, e.g.:

Code: Select all

F = (sum of muscle forces) + joint_reaction_force

Ross

[Pasha van Bijlert]

Hi Ross,

I think my confusion is that I'd expected the JointReactions to equal your F, not just a component of it. Are you specifically looking for forces, or are you looking for reaction moments?

The reason I thought the Reactions equal your F is because, in a simple hinge, I'd expect nonzero components in everything except the free Dof. So for instance, a hinge that can rotate about Z, I'd expect Fx Fy Fz Mx and My to have nonzero components (to make it behave like a hinge), but the Mz would be zero. This is true in my simulations, if I look at the reactions in a 1 DoF joint with muscles crossing it but no ExpressionBasedCoordinateForces. If I look at a joint that also has an EBCF, this is no longer true. Apparently the joint reactions at that point also incorporate the EBCF, but since you know the expression you can compute them and subtract it from that free DoF. I don't know if this helps?

Cheers,
Pasha

[Ross Miller]

Hi Pasha,

The force from inverse dynamics ("F" above) is the force I'm looking for. It is not equal to what OpenSim/Moco defines as a "joint reaction force", at least not for a general case. The only case I can think of where they would be equal would be if there are no muscles or any other actuators producing forces at a joint along the axis in question.

For example, in a real knee, muscles produce tensile forces along that joint's long axis and this pulls the joint surfaces into each other. That contact generates a compressive force in the opposite direction along the long axis, stopping the joint surfaces from passing through each other.

In a knee modeled as a hinge joint, muscle forces are still acting to press the joint surfaces into each other, and there is no physical contact modeled to stop this, e.g. no springs in the joint representing cartilage or bone. So there is a "reaction force" that must be applied to make it behave like a hinge. But this force is not the inverse dynamics force. The inverse dynamics force would be the vector sum of this force plus the muscle forces (and forces in any other actuators at the joint with a component along this axis).

Part of the confusion here I think is the terminology we use in our field for these forces. Bill Baltzopoulos had a nice paper on this recently (https://www.tandfonline.com/doi/abs/10. ... ode=rspb20), I think he suggests calling the "inverse dynamics force" a "partial joint reaction force" or something similar. Oftentimes the "force from inverse dynamics" (traditional Bresler-&-Frankel/David-Winter-style inverse dynamics) is called the "joint reaction force" but it's not really a "reaction force" physically, although this gets kind of philosophical. E.g. in the inverse dynamics model itself, which has no actuation at the joints other than torques that magically appear, yes this is a "reaction force", but in the real joint that it is modeling, it is not a "reaction force" (it's the sum of all the internal structural forces, muscles + ligaments + contact + etc.).

Ross

[Pasha van Bijlert]

Hi Ross,

Thank you for your in-depth explanation. I agree that the terminology is a bit confusing, I will have a look at the paper. So by that terminology, you're saying that OpenSim's JointReactionAnalysis reports the "total reaction force", and that you're looking for the "partial reaction force"?

Cheers,
Pasha

[Aravind Sundararajan]

Hi Ross,

Thank you for your in-depth explanation. I agree that the terminology is a bit confusing, I will have a look at the paper. So by that terminology, you're saying that OpenSim's JointReactionAnalysis reports the "total reaction force", and that you're looking for the "partial reaction force"?

Cheers,
Pasha

in my understanding, the generalized forces necessary to move the model along the kinematic trajectory in the inverse dynamics sense (assuming ideal torque/force actuators) is just not the same as the joint loading.