Difference between the ‘Reactions’ toolbox and ‘FrictionContactMuscles’ toolbox

Hi,

I have a question about the difference between the ‘Reactions’ toolbox and ‘FrictionContactMuscles’ toolbox in the ‘AAUHuman->Toolbox’ folder.

In the ‘ArmCurl’ example, the ‘Reactions’ toolbox is uses as follows:

#include "../../../Body/AAUHuman/ToolBox/Reactions/XPush.any"
#include "../../../Body/AAUHuman/ToolBox/Reactions/XPull.any"
#include "../../../Body/AAUHuman/ToolBox/Reactions/YPush.any"
//#include "../../../Body/AAUHuman/ToolBox/Reactions/YPull.any"
#include "../../../Body/AAUHuman/ToolBox/Reactions/ZPush.any" 
#include "../../../Body/AAUHuman/ToolBox/Reactions/ZPull.any"

But in the ‘PedalDemoConditional’ example, the ‘FrictionContactMuscles’ toolbox is used as follows:

AnyFolder ConditionalContact={
    AnyVar StaticFrictionCoefficient=0.8;
    AnyVar Strength=2000;
    
    AnyFolder ToeLateralContactNodeLeft= {
      
      AnyRefFrame &TargetObject=  ..LegL.Seg.Foot.ToeLateralContactNode;//Location where the force is applied
      AnyRefFrame &BaseObject=Main.Model.EnvironmentModel.GlobalRef; //Object which delivers the forces  
      AnyRefFrame &StrengthObject=TargetObject; //Node used for strength measurement, occasionally this is different from the target object
      
      AnyFolder &DrawRef=Main.DrawSettings; //reference to the folder which contains drawsettings
      //low limit for the strength measure function, if the distance measured along Direction[0] is below this val. the strength will be zero (negative)
      AnyVar UserDefinedLimitLow=-0.05; 
      //high limit for the strength measure function, if the distance measured along Direction[0] is above this val. the strength will be zero
      AnyVar UserDefinedLimitHigh=0.05; 
      
      //high limit for the strength measure function, if the radius measured along the plane with Direction[0] as normal is above this val. the strength will be zero
      AnyVar UserDefinedRadiusLimit=0.4; 
      
      AnyVar Strength =.Strength;  //strength of muscles
      AnyVar StaticFrictionCoefficient=.StaticFrictionCoefficient; //Friction coefficient
      AnyVar ScaleFactor =1; //scale factor for draw vectors it can be set differently than by the drawsettings
      
      
      AnyIntArray Direction={1,0,2}; //first element gives normal direction
      #include  "..\..\..\Body\AAUHuman\ToolBox\FrictionContactMuscles\ContactSurfaceLinPush.any"
    };

I could understand that the Conditional contact element can be used when the contact can be conditionally occurred.
But if the contact always occurs between two different AnyRefNode objects, is there any difference between using the ‘Reactions’ toolbox and ‘FrictionContactMuscles’ toolbox?

Thanks for reading this question and I hope to get your advice.

Best regards,
Moonki

Hi Moonki,

Yes there is a difference also if there is constant contact.

The file Xpush.any (and similar) will simply create a pushing or pulling muscle. Each of the included muscle acts independent from the others.
So you may have no normal force and friction at the same time, even though this is not possible in reality.

Using the conditional contact elements this is resolved and on top there is also the option of having the contact force as conditional, so i would recommend using this.

Best regards
Søren

Hi Søren,

Thank you very much for your nice reply!

I’d like to get another advice from you.

Now I’m trying to use the conditional contact element to replace the ground reaction force to predict it in the ‘GaitFullBody’ example.

In the ‘JointAndDriversOptimized.any’ file in the ‘GaitFullBody’ example, there are some codes like this:

AnyKinEqInterPolDriver JntDriverTrunk = {
    FileErrorContinueOnOff = On;
    Type = Bspline;
    BsplineOrder = 4;
    FileName = Main.ModelSetup.C3DFileData.NameOfFile+"-output-euler-trunk.txt";
    AnyKinMeasureOrg &PelvisPosX = ...HumanModel.Interface.Trunk.PelvisPosX;
    AnyKinMeasureOrg &PelvisPosY = ...HumanModel.Interface.Trunk.PelvisPosY;
    AnyKinMeasureOrg &PelvisPosZ = ...HumanModel.Interface.Trunk.PelvisPosZ;
    AnyKinMeasureOrg &PelvisRotX = ...HumanModel.Interface.Trunk.PelvisRotX;
    AnyKinMeasureOrg &PelvisRotY = ...HumanModel.Interface.Trunk.PelvisRotY;
    AnyKinMeasureOrg &PelvisRotZ = ...HumanModel.Interface.Trunk.PelvisRotZ;
    AnyKinMeasureOrg &PelvisThoraxExtension = ...HumanModel.Interface.Trunk.PelvisThoraxExtension;
    AnyKinMeasureOrg &PelvisThoraxLateralBending = ...HumanModel.Interface.Trunk.PelvisThoraxLateralBending;
    AnyKinMeasureOrg &PelvisThoraxRotation = ...HumanModel.Interface.Trunk.PelvisThoraxRotation;
    Reaction.Type={On,On,On,On,On,On,Off,Off,Off};
};

The interesting thing that I found is that ‘Reaction.Type’ elements are ‘On’ for the positions and rotations on the pelvis.

I understand that this makes some virtual forces that are acted on the pelvis.

If I remove the ground reaction forces in the ‘GaitFullBody’ example and put some codes for conditional contact elements, can I set this ‘Reaction.Type’ as ‘Off’?

Best regards and thanks again,
Moonki

Hi Mooonki,

Yes in principle you can remove these reactions and supply instead the contact conditions on the feets that will calculated the force.

The reactions between the pelvis and ground is valid if you have measured forces, it is not valid if these are not measured but applied as conditional forces. Then the reaction in pelvis would end up carry too much weight.

When running the model with conditional contact on the feets you will also need to have the arms in the model, otherwise you will not get a good estimate on the reaction forces. The resultant force on the feet will be a combination of the true force and forces arising from difference in anthropometric between model and subject.

Best regards
Søren

Hi Søren,

Thanks for your another reply. I will try the conditional contact elements more.

Best regards,
Moonki

Hi,

I’m sorry but I’d like to ask an additional question.

Even if I use the conditional contact elements for replacing the ground reaction forces, sometimes the inverse dynamics analysis fails when I turned off the residual reaction forces and torques that are applied at the pelvis from the ground. Especially I guess that the calculated reaction forces by the conditional contact elements can’t generate the enough moments for the COM(center of mass) of the whole system.

Instead of using AnyReacForce objects, I guess that using AnyGeneralMuscle objects can be better.

My guess is that because AnyReacForce object can have unlimited values of forces and torques, AnyGeneralMuscle objects can have their limits so it would be better to minimize those residual forces and torques to fit the equilibrium equations of the motion.

So I would like to ask your opinion whether it is better to use AnyGeneralMuscle objects for the residual forces and torques at the pelvis.

Best regards,
Moonki

Hi Moonki,

Just to clarify i understand your question inthe following way:

You have replaced measured forces at the feets by conditional contact

This leads to problems with recruitment in some timesteps

To resolve this you are considering adding AnyGeneral muscle as pelvis reactions because they would have a more limiting effect than an AnyReacForce?

This is true…

I think there can be two ways of resolving this recruitment problem.
[ol]
[li]Make sure the contact points in the feet forms a large three-pod
[/li][li]Set the friction coefficient to one
[/li][li]Play around with the strength values of the contact muscles it may cause problems both if too high and too low
[/li][/ol]

You can also add the muscles in the pelvis ground reaction, we have sometime done this uisng very weak muscles. The idea is that if these muscles are very weak they will only be used if there really is a need for them to balance the model, in normal circumstance they would not be used.

A model like this is not the most easy one, it will not be as stable as a model with applied measured forces and having pelvis hooked up to the ground.

Best regards
Søren

Hi, Søren.

Thanks very much for your ideas to resolve the recruitment problem.

Best regards,
Moonki