Built-in Knee Varus Valgus Rotation

Main Forum
1

Hi everyone,

In the AAUHuman/LegTLEM/Seg.any there's a DesignVar named VarusValgusRotation that, from what I understood, introduces a fixed rotation of the knee joint axis, determined by the two epicondyles, in the frontal plane (around the x axis). Is that correct?
There's a comment saying that the name of this variable is deprecated. Is there any reason why it shouldn't be used?
When such alignment measurements are available, from a static pose analysis such EOS or even from a clinical evaluation, they are probably more representative of the whole stance phase leg alignment rather than the default "0°" alignment.

Similarly, a TibialTorsionOffset is defined for the ankle but this one is not marked as deprecated.
If you think that these rotational offsets can still be used for such applications, it might make sense to add a note in the AMMR Documentation of the leg parameters?

And on a more technical note, how can I modify its value directly in AnyScript when using the default root version of the AMMR? I am running a bunch of AnyMoCap models from the console, and rather than setting its value through class operations (right click --> set value in the GUI, or through the class operations in AnyPyTools), I'd prefer to assign the value directly in the SubjectSpecificData.any file for each subject, as it would be a bit more handy for my pipeline.

Thanks!
Enrico

2

Hi Enrico

I do think that the variables work. There was another variable called AxisRot which should be removed. I think the deprecation notice is really about that one.

That said, it is very simplistic way of changing the varus-valgus. All it does is rotate the joint axis in the frontal plane and it only affects the knee joint axis of the thigh. I think that is why it has not been made available as a setting in for example HumanModel.Antrhopometics. I will think about if we make it easily configurable anyway. But the correct/nice way of doing this would be through some sort of scaling/morphing.

However, it is still useful in some situations where you only want to change the angle slightly. You can optimize the value in a MoCap model, similar to how optimize marker positions/ segment length, if you add a AnyDesVar to "ParameterIdentification" study in your MoCap model.

AnyDesVar VarusValgus = {
   Val = Main.HumanModel.BodyModel.Right.Leg.Seg.Thigh.KneeJoint.VarusValgusRotation;
};

The next version of the AMMR (2.3) has this build into the OptimizeAnthropometricsOnOff helper class template. So you can do this:

  OptimizeAnthropometricsOnOff OptimizeAntropometricsOnOff (
    ...
    LEFT_VARUS_VALGUS = ON,
    RIGHT_VARUS_VALGUS = ON,
    RIGHT_TIBIAL_TORSION = ON,
    LEFT_TIBIAL_TORSION = ON,
3

Hi Morten,

Thanks for the help.
The variables work indeed, I just wasn't sure for whether they were still meant to be used so thanks for clarifying it.

I did originally implement it with AnyDesVar in the parameter identification study as follows:

AnyDesVar RightVarusValgus = {
Val = Main.HumanModel.BodyModel.Right.Leg.Seg.Thigh.KneeJoint.VarusValgusRotation;
Min = Main.HumanModel.Anthropometrics.ValgusRight; //defined in SubjectSpecificData
Max = Main.HumanModel.Anthropometrics.ValgusRight; //defined in SubjectSpecificData
};

but the final value was not exactly what I passed as input. I guess it was still allowing some tolerance/trade-off while optimizing also the markers' position?

Now I've defined it in this manner:

AnyOperationSetValue SetValue_RightValgus = {
Target = { &Main.HumanModel.BodyModel.Right.Leg.Seg.Thigh.KneeJoint.VarusValgusRotation };
Source = { &Main.HumanModel.Anthropometrics.ValgusRight };
};

and even if it involves running an additional operation in my pipeline, it works well and the final value is exactly what I passed as an input.

It could anyway be that the optimized version from a static MoCap trial is more representative of the real angle during compared to my input measurement collected from a slightly different standing pose in a EOS scanner, but in principle I think it would be better to match the exact input varus/valgus measurement, when known, and more freely optimize the markers' position, rather than finding a trade off between the two.

It's nice to know that this option will be more easily accessible in the 7.2.3.
I was also playing with a optimization of the tibial torsion value (using AnyDesVar between -pi/6 and +pi/6 since I had no measurements for that) and I got a better visual match between virtual and real markers for ankles and feet. Anyway I imagine the results could be dependent on the weights and allowed optimization directions of the markers (on the malleoli for instance). You probably already thought of this, but I think some general indications might be useful for other users too when the next version is released.

I agree with you that a more detailed scaling/morphing would be ideal, especially when planning to use limb alignment measurements for activities of daily living rather than gait, in which the varus/valgus overall range of motion could be larger. However, for such activities a more complex knee model rather than a simple hinge would be the first necessary requirement. In the meantime I will keep playing with this simplified approach and try to think of when it could be used and when not.

Thanks again!
Cheers,
Enrico

4

Yes. I am not sure how that would work.If you want to contrain the value to something in the optimization study you better make a real contraint.

AnyDesMeasure VarusContraint = {
  Val = Main.HumanModel.BodyModel.Right.Leg.Seg.Thigh.KneeJoint.VarusValgusRotation
           -Main.HumanModel.Anthropometrics.ValgusRight; 
  Type = EqualToZero;
};

But your solution with "AnyOperationSetValue " is just as fine.

I think it would be better to match the exact input varus/valgus measurement, when known, and more freely optimize the markers' position, rather than finding a trade off between the two.

Yes. I also think that a static trial may not be enough to identify the varus valgus angle. Maybe if you could get that info if you had a dynamic reference trial. On the other hand, if you just set the varus-valugus angle you may have problem with the hip distance, as that is usually also hard coded.

It's nice to know that this option will be more easily accessible in the 7.3

I won't promise that. But if you have a good idea to how we should be implement it we may be able to do it. The real problem is that it is dependent on hip distance. So if you just impose a measured varus/valgus angle you really also need add the right hip distance.

/Morten

5

Hi Morten,

Your code looks definitely more elegant than mine :slight_smile:

Anyway, I do have hip to hip distances available in my data, but the more I think about it the more I see the necessity to have a multi DOF knee joint that allows for knee ab/adduction during dynamic activities.

Anyway I will try to run my simulations, at least for the gait stance phase, with and without the built-in VarusValgusRotation variable and post some updates here if I find anything interesting.

Thanks again for the help!
Enrico

6

This topic was automatically closed 125 days after the last reply. New replies are no longer allowed.