Knee bending in wrong direction in full body model

Hello,

I am trying to drive the full body model by driving the hip on the Y axis (downwards). The model is working except that the knee is bending the other way.

The initial position of the mannequin looks like this:
image

I would like the knee to start this motion wen it is approximately 16°, so I added in the "TrialSpecificData.any" the following: Main.HumanModel.Mannequin.Posture.Right.KneeFlexion = 16*pi/180. I also tried to give it a higher angle (like 20° or 45°) or change the position of the metatarsals or the hip, but I cannot make it work.

Currently in the next steps the knee starts doing this:
image

I also thought that maybe it is because I have fixed the metatarsal at the wrong distance, so I tried putting it more upward so I can have the knee automatically in the desired position, but then I obtained this initial position:
image
From what I understood in the ...Mannequin.Posture, I can set the initial positions of the drivers. So I am not sure why this model is behaving like this? :thinking: I am surely doing something wrong but I don't know what.

I do have to mention that the Knee driver is switched off as I would like the model to determine the position of the knee while performing the motion I give it.

Best,
Diana

Hi Diana,

To me it looks like the model has two solutions and it ends up using the wrong one.

There are two ways to fix this start the model in a different location, this you have already tried but it is possible that this could be further improved. I would try with a higher angle in the knee as the starting guess.. but this is not a guarantee

Secondly you could add a joint limit in the model that would stop the knee from doing this. This will only work in a model which is using overdetermined kinematics.

To add a joint limit you can use code like this ;

AnyFolder KneeFlexion_Right=       {
          KinLimitsDriver Driver(
             KinMeasure= Main.HumanModel.BodyModel.Interface.Right.KneeFlexion
          ) =  { LowerLimit =0; HighLimit = 180; MeasureConversion=180/pi; };
       };

Best regards
Søren

1 Like

Hi Søren,

I have been trying to give it different starting position angles and while it works for higher angles, it usually stops during the simulation around step 42 due to "Failed to solve position constriants".

So I have tried to add the joint limiter, but now my model says it is "kinematically over-constrained". I thought that maybe the limit I gave does not satisfy the actual motion the knee performs so that is why I get that message, but when I tried to give as limits the actual motion the knee does (like in the images above), I still get the same error.

Best,
Diana

Best,
Diana

Hi Diana,

As i wrote the limit will only work if you are running the model using he over-constrained solver.

Otherwise you will the message you have seen.

Best regards
Søren

Hi Søren,

Sorry, I miss-read that!

I will try to use the over-constrained solver then.

Best,
Diana

Hi Søren,

I have tried to search for the over-constrained solver but in the documentation I have found [here](file:///C:/Program%20Files/AnyBody%20Technology/AnyBody.7.3/Documentation/AnyScriptReference/reference/classes/AnyKinSolverType.html?highlight=kinsol),I could only find the determinate drivers and nothing about the over-constrained one.

Could you point me in the right direction please?

Best,
Diana

Hi Diana,

Please see this tutorial

Towards the end of the tutorial the solver settings of the study is changed to overdetermined kinematics.

Best regards
Søren

Hi Søren,

Thank you! I did see this tutorial but I was looking for over-constrained, not over-determined. So it went over my head :sweat_smile:

I will try to implement this and see if it is working.

Best,
Diana

Hi Diana,

Sorry for the confusion, I should have written over-determined sorry about this.

Best regards
Søren

Hi Søren.

No worries, thank you for your help till now! I tried since then to implement the over-determined solver type, but after implementing it I came into another problem.

When I give it constraints as -180 to +180, then the knee acts as before, going in the wrong direction (as expected). But when I give it 0 to 180 or 5 to 180, then the model first descends and then starts bending.

I have activated the ground reaction forces as I would like to know them. So I have the area in which the foot is supposed to stay. I can see the model is first going down for a distance of X and then it starts bending. Also, I constrained the metatarsal in the XYZ positions and rotations to avoid any undesired movement to see if it is working.

So my problem is as follows:

First it starts descending through the GRF area:
image
Then it starts bending:
image
I have no errors in the kinematics if I run the model when it goes down, but if I try to run the inverse dynamics, then it tells me the kinematics have failed at step 0.

Would you have any idea how to fix this?

Update:
I have looked where the base plate for the GRF is defined, and it is at {0,0,0}.
I have the metatarsal constrained as well at {0,0,0}, but the model is still sliding down before bending.
I have also tried to define the base plate of the GRF on the heel or the metatarsal, but it does the same as before and I am not sure why.
I have noticed that Main.HumanModel.Mannequin.Posture.PelvisPosY is always 1.16, and I think it should be around 0.9-1.0. So I tried giving it a value between those, but the action is the same.

Best,
Diana

Diana,

Concerning the penetration of the floor my only explanation is that it must be a soft constraint between foot and floor? so look for a constrain with a CType ={Soft...} it needs to be CType={Hard} to act as a hard constraint.

Which model is your model based ?

I am asking because you write that the inverse dynamic study does not run.

I could understand if the error you saw in inverse analysis was a recruitment error?

Best regards
Søren

Hi Søren,

Yes! Indeed it was the soft constraint between the floor and the foot! Thank you! Now it is bending properly (not going down) but stopping half way. I will try to figure it out.

I am working on the Personalized Knee Model.

Yes, the error I have indeed is ERROR(OBJ.MCH.MUS4) : InverseDynamicsMoSyn.any(136) : InverseDynamicStudy.InverseDynamics : Muscle recruitment solver : solver aborted after maximum number of iterations.

Best,
Diana

This error means that the solver did not find a way to balance the model...

Reasons could be

  • Unrealistic acceleration imposed to the model, meaning the the foot contact area i not "big" enough for the model to keep the balance. If the model is running partly look at the GRF prediction and see if predicted CoP is about to move outside the foot? if the answer is yes you will need to modify the motion.
  • Is the normal direction in the grf prediction class correctly set?
  • Is the study definition of gravity correct?

Best regards
Søren

HI Søren,

Oh I see. I will look into those.

I have given the model a low acceleration, but it stops at step 0 always so I cannot look at the CoP.
The normal direction of the GRF is defined correctly. It was Z but I changed to Y since that is the vertical.
I have also set the gravity to act on Y as that is the upwards direction on the GlobalRefFrame.
I will keep trying.

Thank you for your help till now!

Best,
Diana

Hi Diana,

As a way to figure out what happends please try to increase these values.

Main.Studies.InverseDynamicStudy.ModelEnvironmentConnection.HumanGroundResiduals.WeakGeneralMuscles.MusMoldel1.F0 
Main.Studies.InverseDynamicStudy.ModelEnvironmentConnection.HumanGroundResiduals.WeakGeneralMuscles.MusMoldel2.F0

These values represents the strength of the muscles which creates residual forces from human to environment.

Note that by increasing these strengths the model will get unloaded... so increasing these is a way to understand which directions are needing support and in this way understand the problem. Once you have figured out the problem, these number should be reverted back to normal.

So increase the strength and look at the forces found at e.g.
Main.Studies.InverseDynamicStudy.ModelEnvironmentConnection.HumanGroundResiduals.PosX_Force

to get an understanding on which directions are causing the problem.

Best regards
Søren

Hi Søren,

Thank you! I will try to do that!

Best,
Diana

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