Sensitifity of Force Dependent Kinematics (FDK) to inital driver definition

Main Forum
1

Hello everybody,

I have a question regarding the sensitivity of a FDK-controlled measurement in respect to the initial definition of the measurement constrain.
The problem is the following:
I am currently working on the lumbar spine model of the AAUHuman model with the aim to control the intervertebral joints by FDK. To do so, I customized the lumber Rhythm (Driver SpineRhythmDrv) in JointsLumbar.any by defining CType as forcedep while driving a rotational measure between Pelvis and T12 to make the model fully constrained.
This worked without problem and the InverseDynamics results were also reasonable, thus there seem to be no error in the implementation of the FDK control.

As FDK solves the kinematics stepwise by finding the model configuration which minimizes the supplementary forces that balance the system, the result should be independent from how the joint configuration was defined initially.
However, when I subsequently edited the entries of SRMatrixes.any in the last 3 columns on the right hand side the result of the Study changed remarkably. If I for example all non-zero entries on the the right-hand sight in the first three rows are multiplied by 10 (i.e. if the rotation of the L5-Sacrum joint is assumed to be 10 times the rotation in the T12-L1 joint) the result of the inverse dynamics changes by up to 10 % compared to default. Thus, the inital definition of the configuration of the FDK-controlled measure seems to notably influence the outcome of the FDK derived force equilibrium.
Does anybody had the same observation for FDK controlled joints?
What could be an explanation for this behavior?
Is there a best practice for the selection of initial values (i.e. measurment drivers) for FDK controlled joints?
Thanks for any answers!

Best regards
Tobias

2

Hi Tobias,

It is hard to say for sure without seeing the actual code and how the FDK analysis runs.

But… Since we are looking for the equilibrium at each time step -we might have not a single, but multiple solutions if the configuration allows for that. By selecting a different starting point you might simply hit an alternative point.

Secondly, if you observe FDK errors it simply means you do not achieve equilibrium and your solutions might differ quite a lot.

Are you using SpineFixationWithFDK as a base for your model? I have not noticed this behaviour when implemented this model. I could check the problem using this one, how different it is to yours?

Kind regards,
Pavel

3

Hello Pavel,

Thanks for the fast response!
No, no FDK errors were observed at any of my simulation.
Actually my model is very close to SpineFixationWithFDK, thus I tried different initiations in this model as well and the overall result was similar: The result of a FDK controlled joint/joints is notably depending on how the FDK is initiated.
To ease the comparison later on, I chose the same motion task for all simulations:
AnyVar InitialFlexionExtension = 0; // Degrees
AnyVar InitialLateralBending = 0; // Degrees
AnyVar InitialTorsion = 0; // Degrees
AnyVar FinalFlexionExtension = -20; // Degrees
AnyVar FinalLateralBending = 0; // Degrees
AnyVar FinalTorsion = 0; // Degrees
AnyVar SimTime = 1; // Seconds
and excluded the fixation by outcommenting #include “Model/SpineFixation.any”

  1. I investigated the impact of the choice of the joint, that is freed to avoid over-constrained situation: To do so, I compared a the default setup (L5-Sacrum commented out) to too other examples (L3-L4 and T12-L1 commented out). In my opinion, it should not make a difference, which joint is freed. However, the difference between segmental angles was remarkably, especially in the beginning. But even at the final simulation step the difference to the default condition was up to 45% to the one were T12-L1 was freed. How could one explain this different behavior?
  2. I changed the first entry (controlling the joint flexion) in all rows in the DriverVel vector of the FDK_Measure, to take up a fraction of the lumbar flexion. This comes closer to my inital question of how the configuration of a spial rhythm impacts the results, eventhough FDK is defined for all the joints. In my opinion, this should not influence the result of the study as the motion of the joints is not derived in a feedforward pathway, but iteratively for each step. When I drove all FDK-controlled joints by 50% of the overall velocity (which is of cause an overprediction), there was again a difference in results , even-though it was much smaller than in the case before and smaller than what i observed when changing the entries of a FDK-controlled lumbar rhythm. Thus only the freed joint L5-Sacrum (the only one without artificial acceleration by the entries in the DriverVel) changed by slightly more than 0.5% compared to default, which is not such a big issue. However, I still wonder how the definition of DriverVel might influence the result of the study, even though this information should not be used by FDK.
    Do you know about a comprehensive sensitivity study done on the initiation of FDK?

Best regards
Tobias

4

Tobias,

Generally speaking the results should not change. There should be an explanation to this behavior. I have changed initial guesses in SpineFIxationWithFDK and did not get different results.

Do you have surface contacts in your model? What tolerances do you use? If they are too high - you could get pretty much anything.

It could also be that you are simply driving something without realizing.

Could you confirm that you use the original SpineFixationWithFDK (outcommented the fixation part)? Could you post code/model demonstrating how you change something?

Regards,
Pavel

5

Hi Tobias,

5 cents from me.

I think the explanation is that the DriverVel should always be set to zero for FDK dofs.

To me it seems like if it is set, it will introduce a new “static” equlibrium because that velocity may (and, as far as I can see without writing out the math, will for the spine) introduce a velocity-dependent term in the equations of motion coming from segment angular velocities. Hence, to obtain the equilbrium, the model most assume a posture where this additional term is balanced as well. This means that you will obtain a different solution for different velocities.

Notice that this is not the intended use of FDK. We seek to find the quasi-static equilibrium (quasi because the dynamics of non-FDK dofs are taken into account) but with the velocity and acceleration terms in the FDK dofs being zero.

Best regards
Michael

6

Hallo Pavel and Michael

Thanks for your reply!
@Pavel: I just repeated the sensibility study on the freed DOF in the SpineFixationWithFDK model. To minimize any error sources, I downloaded the newest AMMR 1.6.3 to make sure that I work with the latest version of the model. Subsequently I did the following customization:

  1.  Excluding the fixation device by out-commenting  #include "Model/SpineFixation.any"

  2.  Adapting Input-Parameters in InputParameters.any:

AnyVar ImplantStiffnessCoefficient = 1;

AnyVar InitialFlexionExtension = 0;    // Degrees
AnyVar InitialLateralBending = 0;        // Degrees
AnyVar InitialTorsion = 0;               // Degrees

AnyVar FinalFlexionExtension = -20;       // Degrees
AnyVar FinalLateralBending = 0;          // Degrees
AnyVar FinalTorsion = 0;                 // Degrees

AnyVar SimTime = 1;                     // Seconds

  1.  Run InverseDynamics with different freed DOF (1st L5-Sacrum, 2nd L2-L3, 3rd T12-L1): to do so the particular DOF was out-commented in the FDK_measures driver in drivers.any while all the other 5 DoF were set to be active

  2.  Evaluation: From the Output-File LumbarSpineFlexExt.txt the joint angles for each intervertebral joint were taken and compared to the default setting (L5-Sacrum out-commented) by calculating absolute and relative errors between the outputs. The obtained Output files can be found in the attachment.

Result: As can be seen from the attached output files, the resulting angles of the simulations differ notably with absolute errors of up to 1.6° and final relative errors of up to 45.78% for the case of T12-L5 out-commented
As I did no further changes apart from the reported ones, I wonder how can these errors be explained? Would you be so kind to take a look if you get the same results as me for the default and the T12-L1-freed case? If yes, what would be an appropriate selection for the freed-DOF in a complex model like the spine?

@Michael: I tried to implement all FDK-driven DOFs with 0 velocity drivers: However, it leads to unrealistic results and even failure in my model. In detail, I work with a detailed thoracolumbar spine-model in which all intervertebral joints as well as all costotransverse and costovertebral joints should be FDK controlled. To control the motion, I implemented a driver for each the lumbar (T12-Sacrum) and the thoracic region (T1-T12) and leaving one intervertebral DOF uncontrolled (Default: lumbar Sacrum-L5, thoracic T11-T12) while all other intervertebral joints are FDK controlled with a AnyKinEqSimpleDriver driver with a 0-velocity and 0-position vector. It turned out however, that the result is rather unrealistic and clearly depends on the selection of the DOF. In the lumbar region a 20° flexion motion in default setting (L5-Sacrum freed) is characterized by a strong flexion motion in the Sacrum-L3 region (peaking at Sacrum-L5) and an extension motion in T12-L3 (peeking at T12-L1). In the thoracic region around the freed DOF is extending while the rest of the joints is flexing.

When I instead define the intervertebral DOF by a FDK-controlled Spinal rhythm, the result tends to be much more stable to different implementation of the spinal rhythm matrix and additionally the results are much more physiological (all DOF flexing to a similar extend). Furthermore the result is quite different to the previous described FDK implementation with a 0-velocity driver.
Is this FDK-controlled-spinal-rhythm-approach in your opinion valid or where do you see a contradiction to the intended implementation of FDK. How could the deviation between the results be explained? Where would be a good start for troubleshooting? I am afraid I can’t upload the model itself, but I would be happy to send you further information or output-files.
Thank you very much for your help!
Cheers Tobi

7

Tobias,

Just FYI - we are looking into the problem.
I have tried to make a very small example and i can see similar behaviour, but i can definitely see that these are simply different solutions. Starting from different guesses gets you slightly different predictions.

I will update when we have more to say.

Kind regards,
Pavel

8

Good morning Pavel!

Thanks a lot! Please keep me updated about your findings.
In the meanwhile i did a small investigation to see if the result is depending notably on the tolerance definition of the FDK. However, a ten times smaller force tolerance (ForceTol = 0.0001) only leads to tiny differences in the intervertebral motion and thus is not responsible for the difference in results!
Looking forward to hear from you!

Best regards
Tobias

9

Hi Tobias,

We have identified the reason behind the difference in results. This is happening due to the nature of FDK, which tries to minimize reaction forces/moments in the FDK degrees of freedom in the given time point. By choosing different level to be excluded we solve a slightly different problem and leave the remaining DoF in a suboptimal condition if we think of it in terms of a reaction force/moment, the muscle recruitment ensures that the system is in equilibrium by finding needed forces to balance the body. The current solutions are not wrong, but slightly suboptimal in the described sense – we can see that the differences up to half a degree in most of the cases, and all solutions look quite similar to the optimal posture, which can be found using a couple of different approaches:

  1. Inverse inverse dynamics analysis: an optimization problem is solved with the design variables being the individual IVA and the objective function being the objective function of the muscle recruitment optimization, sum of all muscles activities in the power of 3. By minimizing this objective function we find the most relaxed and “natural posture”.
  2. Second approach is to construct a new set of FDK DoFs, which will include all angles at the same time, but would still have a single DoF that would stay free to “close” the kinematic chain. One of the solutions is to use the same number (5=6-1) of orthogonal linear combinations (curvature modes) of all angles to construct new FDK measures (a couple of options, see commented block as well):
AnyKinEqSimpleDriver FDK_Modes = { // Flexion ONLY
         AnyKinMeasureLinComb LinComb = {
      OutDim = 5; // 6DoF-1DoF to close the kinematic chain (excluding lin. comb {1, 1, 1, 1, 1, 1})
//      Coef = { // solution #1, all mutually orthogonal as well as to {1, 1, 1, 1, 1, 1}
//        {1, -1,  0,  0,  0,  0},
//        {1,  1, -2,  0,  0,  0},
//        {1,  1,  1, -3,  0,  0},
//        {1,  1,  1,  1, -4,  0},
//        {1,  1,  1,  1,  1, -5}
//      };

      Coef = { // solution #2, orthogonal to {1, 1, 1, 1, 1, 1}
        {1, -1,  0,  0,  0,  0},
        {0,  1, -1,  0,  0,  0},
        {0,  0,  1, -1,  0,  0},
        {0,  0,  0,  1, -1,  0},
        {0,  0,  0,  0,  1, -1}
      };

      AnyKinMeasureOrg org = {
        AnySphericalJoint &jntt12l1 = ...refJoints.T12L1Jnt;
        AnySphericalJoint &jnt12 = ...refJoints.L1L2Jnt;    
        AnySphericalJoint &jnt23 = ...refJoints.L2L3Jnt; 
        AnySphericalJoint &jnt34 = ...refJoints.L3L4Jnt;
        AnySphericalJoint &jnt45 = ...refJoints.L4L5Jnt;
        AnySphericalJoint &jnt5sacrum = ...refJoints.L5SacrumJnt;      
        MeasureOrganizer = {0,3,6,9,12,15};
      };
    };

    DriverPos={0,0,0,0,0};
    DriverVel={0,0,0,0,0};
    CType={ForceDep,ForceDep,ForceDep,ForceDep,ForceDep};
    Reaction.Type={Off,Off,Off,Off,Off};
};

We will probably change the model to use the second solution in the next version of AMMR or will at least make it possible to switch it on. Thanks for finding this behavior.

Kind regards,
Pavel