I’m using the version 5.0 of the software and I’m trying to simulate the shoulder joint as a non-conforming joint, involving little perpendicular movements of the humeral head on the glenoid, which are due to the GH reaction force.
I switched the CType value in the Y direction to ‘ForceDep’ and in the X direction to ‘Soft’. However, the displacement that I get in the Y direction is too important. I think this is due to the ligaments that are supposed to maintain shoulder stability when the arm is along the body.
Can we set a parameter that will avoid these large displacements, like a tolerance or something else ?
I found the problem related to the too large displacements. It was related to the use of the quadratic recruitment criterion, resulting in a non-activated rotator cuff. Using the MinMaxStrict recruit the rotator cuff works to limit the translation to smaller values.
Now I the following error at step 9 of the inverse dynamics analysis:
There is no tolerance parameter to limit the displacement of the force dependent DoF. The only way to limit it is by the force itself, so typically adding some joint stiffness or ligaments.
Now about the error. Depending on your model configuration it can be that some hard constraints are affected by the force dependent ones. So if the force dependent DoF are doing wild things it can lead to this error. It can also be that at some point there are not enough forces to hold the force dependent DoF and the mechanical system collapses.
Try to constrain a bit more your force dependent DoF by adding ligaments, as I undertood they are not included yet.
Thank you for these advices. How can I add joint stiffness ? Adding ligaments will be a difficult journey, but I think that we should do it one day or another.
What is the difference between the ‘hard’ and ‘soft’ constraint types of the CType option ?
In all cases you need forces to balance the force dependent kinematic DoF at any time. Most of the time just the muscles are not enough because they can be inactive at some point of the simulation. So it is good to have either ligaments or joint stiffness there, depending on the available data.
For the CType: Hard is the normal default constraint type that was always used, where no violation of the constraint is allowed. The Soft type is using the over determinate kinematic solver, and here violation is allowed but the system will do the best compromise to minimize this violation. So a soft constraint is much less subject to faillure than a hard one, but in return you have less control on it.
I’m not able to find the right way to add translational stiffness in the GH joint, based on the example. I tried to add a force which acts when the translational components of the “GHLin” are non-zero, but the simulation does not converge. I tried to add ligaments around the GH joint, but I would have to use ShortestPath Ligaments, which does not exist in AnyBody. Also, the mechanical properties of GH ligaments are hard to find in the literature.
If you know the correct way to add translational stiffness, please tell me !
The script for the translational stiffness should be very similar to the rotational one in the example. You just have to replace the rotational measure of the joint by the a linear measure between the two nodes, and input length instead of angles in the interpolation function. Then the AnyForce is applied to the linear measure.
The reasons for simulation not converging could be that the stiffness is too low, or maybe the force is applied in the wrong way (make sure it is not pushing the joint away, that happens), or one of the directions is not carried.
How do I check if the force acts in the right direction ? I tried to plot the force with a vector, but I cannot process the same way as the GHReactions.any, because the kinematic measure is a AnyKinSPLine. How do I proceed with this kind of kinematic measure ?
Actually with a PLine or SPLine it is quite simple. When the force is negative it means the line is pulling, trying to shorten itself. This is what you want for your ligament model.
And if the force is positive it means the line is pushing.
So in the interpolation function used to apply the force to the SPLine I guess you have length as input in the T menber, and you should have negative forces in the Data menber.
I’m trying to understand how the “Force dependant kinematics” algorithm works. Because there is no velocity and acceleration, does the system compute a position at which the equilibrium will be held ? If yes, is this the reason why I get a reaction force purely perpendicular to the glenoid surface when I use this algorithm ? If so, it will be difficult to simulate instability at the GH joint using this algorithm.
The algorithm will enforce that the velocity and acceleration is zero for the DOF you are driving the with the force dependency, that is correct.
Without knowing the details of your joint reaction setup this will not automatically give a perpendicular reaction force. The direction of the reaction force will depend on the rest of the model, and how the reaction force has been implemented?
I was referencing to the shoulder “GHReactions.any”. In reality, the force is not purely perpendicular to the glenoid but close to be perpendicular. However, without velocity and acceleration, its semi-static. Thus, instability cannot be simulated, right ?
If the humeral head translate to much upward, does the model will not be able to keep the resultant force within the glenoid and give an error, which would indicates a potential superior instability. I ask the question because John told me that the only way to show GH instability with the GHReactions.any is to force the model to end with an error or with overloaded muscle because it is not able to find a muscle recruitment for the giving configuration.
It is correct that the algorithm will find the equilibrium where the velocities and acc is zero so it is not well suited for finding an unstable configuration.
If you move the head too much upwards your are right at some point it will not be able to balance the force and it will fail.
Yes it is pretty clear. Is it possible to mix forward and inverse dynamics in the same software ? I think Simulink (Matlab) does that !?!? If yes, is it part of your short term planning ? I think instability and accelerated movements come together ! What’s your opinion ?
Anyway, your implementation of the Force dependent kinematics is a really good improvement that will help me much. I think that it is reliable for low velocity elevations of the arm. While using it, I found humeral head displacements up to 7 mm. I look forward to test it with my massive rotator cuff tear configuration !!
I simulate an elevation in the plane of the scapula from 0 to 135 degrees with the force dependant kinematics. I use a stiffness in the inferior, superior, anterior and posterior directions applied at the GHLin, and the value comes from the literature (4000 N/m).
The results show high humeral displacements. When I look at the rotator cuff activities, I find low values, compared to EMG data from the literature.
How can I improve the model to activate more the rotator cuff muscles at the beginning of the movement ? I tried to tighten the constraining zone of the GH reaction force, to force the reaction force to be more toward the glenoid midst, but it does not seems to help much.
Are you asking me this question while already knowing the answer ? I think that the constraint that force the joint reaction force to stay inside the glenoid cavity and thus recruits the rotator cuff accordingly is no longer valid while simulating the humeral displacement. In fact, I get a really similar activity of the rotator cuff while both preventing and allowing humeral translations. Maybe we should find another way to link the humeral translation to rotator cuff activity.
I did not know the answer sorry, but i think your arguments sounds reasonable. This reaction constrain most likely controls a lot.
I am not fully aware of the geometry you have in the joint, maybe there are some contact taking place which could be used on top of the cavity constraint.
? I think that the constraint that force the joint reaction force to stay inside the glenoid cavity and thus recruits the rotator cuff accordingly is no longer valid while simulating the humeral displacement. In fact, I get a really similar activity of the rotator cuff while both preventing and allowing humeral translations. Maybe we should find another way to link the humeral translation to rotator cuff activity.