MarkerTracking.InitialConditions : Kinematic analysis failed in time step 0 : Position analysis is not completed

Hello, everyone:
I encountered some problems with my MoCap model. When I ran the ParameterIdentification or MarkerTracking, I got this error--MarkerTracking.InitialConditions: Kinematic analysis failed in time step 0 : Position analysis is not completed.
I have made effort to adjust the initial posture. I also increased the KinematicTol. But this error still exists. I don't know how to solve the problem. I attached the zip file to make it easier for everyone to help me find the cause of the error. I really appreciate if anyone could help me.
Best regards.
Zhanpeng LiPlug-in-gait_Simple.zip (865.4 KB)

Hi Zhanpeng Li,

I think you do not have enough markers to define position of the body in a unique way. For example, you have only 2 markers on pelvis - this is not sufficient to constrain all 6dof of pelvis segment. You may need to add additional drivers (kinematic constraints) to make your problem solvable.

Regards,
Pavel

Dear Pavel:
Your suggestion is right. In ExtraDrivers.any, I truned the switch ' #define BM_MANNEQUIN_DRIVER_DEFAULT ON ' , then it can successfully run InitialConditions. However, when I ran Kinematics, an error occurred: MarkerTracking.Kinematics : Kinematic analysis failed in time step 15 : Position analysis is not completed .
In the ExtraDrivers.any, there are only upper body drivers. How to add other drives? Is there an easy way? I re-uploaded the file because I made some changes.Plug-in-gait_Simple.zip (754.6 KB)
Thank you very much.
Best regards.
Zhanpeng Li

Dear Zhanpeng Li,

Kinematic failures could generally happen for many reasons. But most likely in your case you have conflicting drivers - markers and default drivers want to do different things. You enabled many mannequin drivers, but you only needed those that would help you with the free degrees of freedom. Everything else has a potential to cause kinematic failures.

For example, you probably have 6 mannequin drivers on 6 dof of pelvis and 2 markers - markers force the pelvis to be in one place, 3 translations from the mannequin drivers in another. The solver could find some sort of tradeoff for 15 steps, but then errors become too large.

I would recommend you to understand your problem better and add only relevant mannequin drivers.

And regarding the other question: you can add drivers by making a copy of existing ones and adjusting them by adding kinematic measures of interest instead of what was there before. Please also revisit tutorials to learn a little more about number of free DoF and corresponding drivers.

Kind regards,
Pavel

1 Like

Dear Pavel,

I have made effort to correct my model to run Kinematics. In the previous LowerExtremity model, I changed the parameter 'BM_MANNEQUIN_DRIVER_DEFAULT' to ON in ExtraDrivers.any, and removed the vert marker on the head in MarkerProtocol.any, then it can successfully run Kinematics.

Now, I use the FullBody model and I add all the markers, but it doesn't work well. I tried to remove some drivers, but Kinematics still can't be run. it is difficult for me. Could you help me adjust the model?Thank you very much.
Please open FullBody.main.any Plug-in-gait_Simple.zip (803.6 KB)

Best regards,
Zhanpeng Li

Hi Zhanpneg,

Please specify which AMMR this model loads with?

The AMMR version I have tried with fails to load, is that also what you see? please describe the problem in more detail.

Best regards
Søren

Best regards
Søren

Dear Søren,

The AMMR is 2.1.1. The problem is kinematic analysis failed when I run Studies.Marker Tracking.Kinematics.

Error information: MarkerTracking.Kinematics: Kinematic analysis failed in time step 25 : Position analysis is not completed.

According to your suggestion, I converted the 3d coordinate data into a c3d file. The marker of my c3d file didn't comply with the standard marker protocol. So something is not going well.

At first I used the LowerExtremity MoCap model without arm markers. I encountered the same problem - Kinematic analysis failed. Pavel said it might be conflicting drivers - markers and default drivers want to do different things. (Note: I enabled all the mannequin drivers) So I tried to disabled some mannequin drivers and markers. Finally, I found that when I removed the 'vert marker' on the head, it can successfully run kinematics even if I enabled all the mannequin drivers. It can roughly guess that the marker driver on the head conflicts with the mannequin drivers.

On the basis of the LowerExtremity model, I expanded it to FullBody model. I added all the markers. The problem of kinematic analysis failure becomes more complicated. I can't solve the problem by myself, so I ask for your help.
Your help is much appreciated.

Best regards,
Zhanpeng Li

Dear Zhanpeng,

I have tried to make the model run but i have not managed to do within the time i had avaible:

Here are my findings:

  • Hip makers looks strangely positioned, looks to be a trochanter marker but is placed on Pelvis segment, possibly move these to thigh.
  • You are using an older AMMR version i would recommend to use the newest version.
  • The arm markers looks odd the upper arms ends up rather short compared to lower arm if the markers are to match. Did the wrist maker really sit on the wrist joint and not the hand ? that would make more sense.
  • The defines
  #define BM_MANNEQUIN_DRIVER_SKULL_THORAX_FLEXION OFF
  #define BM_MANNEQUIN_DRIVER_SKULL_THORAX_LATERALBENDING ON
  #define BM_MANNEQUIN_DRIVER_SKULL_THORAX_ROTATION ON


has no impact since they are associated with a newer AMMR version not the one you use, instead the this define can be used

 #define BM_MANNEQUIN_DRIVER_NECK OFF

but id does not separate into different dofs.

Generally try to make change the markers into the correct position.

It also looks like the markers positions of the right and left arm was not the same in the experiment right arm looks like it needs to be shorter than left arm.? was markers symmetrically placed in experiment.

Secondly try to make the parameter optimization run you can insert this line in the trialspecific file to limit the number of steps #define N_STEP_PARAM_OPT 1 before running paramstudy disable the optimization of the makers locations in the makerprocol file there are still a few markers being optimized, and in there are not enough markers here to do that.

Hope it helps.

Best regards
Søren

1 Like

Dear Søren,
I have completed the parameterization of the movement. However, I encountered new problems:

  1. I extracted the angle data of each joint from the Mocap model, and then input the data into the AnyKinEqInterPolDriver of the FreePosture model to realize the parameterization of the motion. However, the parameterized motion is not completely consistent with the original motion, see the two pictures below(Ignore the head motion).

How can the deviation between the parameterized motion and the original motion be reduced?

  1. There are warnings when load the model:
WARNING for Main.HumanModel.BodyModel.Trunk.Buckle.Segments.BuckleSeg: Non-orthogonal axes were adjusted.
WARNING for Main.HumanModel.BodyModel.Trunk.Buckle.Slider1.Seg: Non-orthogonal axes were adjusted.
WARNING for Main.HumanModel.BodyModel.Trunk.Buckle.Slider2.Seg: Non-orthogonal axes were adjusted.
WARNING for Main.HumanModel.BodyModel.Trunk.Buckle.Slider3.Seg: Non-orthogonal axes were adjusted.
WARNING for Main.HumanModel.BodyModel.Trunk.Buckle.Slider4.Seg: Non-orthogonal axes were adjusted.
WARNING for Main.HumanModel.BodyModel.Trunk.Buckle.Slider5.Seg: Non-orthogonal axes were adjusted.

  1. It is failed to run InverseDynamics. Maybe due to the high speed of the motion.
WARNING(OBJ.MCH.MUS3) :   F:/LZP/F..1/FreePostureFullBodyStatic.Main.any(96)  :   Study.InverseDynamics  :  Overloaded muscle configuration.
WARNING(OBJ.MCH.MUS3) :   F:/LZP/F..1/FreePostureFullBodyStatic.Main.any(96)  :   Study.InverseDynamics  :  Overloaded muscle configuration.
WARNING(OBJ.MCH.MUS3) :   F:/LZP/F..1/FreePostureFullBodyStatic.Main.any(96)  :   Study.InverseDynamics  :  Overloaded muscle configuration.
WARNING(OBJ.MCH.MUS3) :   F:/LZP/F..1/FreePostureFullBodyStatic.Main.any(96)  :   Study.InverseDynamics  :  Overloaded muscle configuration.
WARNING(OBJ.MCH.MUS3) :   F:/LZP/F..1/FreePostureFullBodyStatic.Main.any(96)  :   Study.InverseDynamics  :  Overloaded muscle configuration.
WARNING(OBJ.MCH.MUS3) :   F:/LZP/F..1/FreePostureFullBodyStatic.Main.any(96)  :   Study.InverseDynamics  :  Overloaded muscle configuration.
WARNING(OBJ.MCH.MUS3) :   F:/LZP/F..1/FreePostureFullBodyStatic.Main.any(96)  :   Study.InverseDynamics  :  Overloaded muscle configuration.
ERROR(OBJ.MCH.MUS4) :   F:/LZP/F..1/FreePostureFullBodyStatic.Main.any(96)  :   Study.InverseDynamics  :  Muscle recruitment solver :  solver aborted due to singular KKT matrix

How to solve the problems?
I attached the file. Please open 'FreePostureFullBodyMove.Main.any'. AMMR is v2.1.1.
Looking forward to your suggestions. Thanks very much.
FreePosture_V1.zip (39.6 KB)

Best regards
Zhanpeng Li

Hi Zhanpeng,

I would look at the type of interpolation you are using in the free posture model this will influence the final position.

Secondly i would do this comparison within the mocap model , so compare motion tracking kinematics with inverse dynamics kinematics this will be essentially the same thing, but it would be easier and things should be matching up better.

Best regards
Søren

Dear Søren:
I have solved the first problem. The reason for the inconsistency of the two motions is due to the inconsistent definition of the pelvis node. The definition of the pelvis node in the Mocap model is ‘HumanModel.Trunk.SegmentsLumbar.PelvisSeg.AnatomicalFrame’, while the definition of the pelvis node in the FreePosture model is ‘HumanModel.Trunk.SegmentsLumbar.PelvisSeg’. Now the parametric motion is consistent with the motion in the Mocap model, and it can successfully run InverseDynamics.

However, the warnings still exist:
1.WARNING for Main.HumanModel.BodyModel.Trunk.Buckle.Segments.BuckleSeg: Non-orthogonal axes were adjusted.
2.When running InverseDynamics--WARNING(OBJ.MCH.MUS3) : Study.InverseDynamics : Overloaded muscle configuration.
The modified modelFreePosture_V1.zip (39.6 KB)
What are the reasons for these warnings? And how to solve them?
Thanks for your help.

Best regards
Zhanpeng Li

Hi Zhanpeng,

First question is how is the model supported?

The free posture model simply has reactions on pelvis to the world nothing else, so not really realistic in most case it is mostly made for displaying an easy way to set the posture.

So you most likely need to add to support to feet's?

I still do not understand why not using the mocap model for the entire simulation?

Best regards
Søren

Dear Søren:
I'm sorry that I didn't explain my research background in advance. This may be confusing.

I want to use the inverse-inverse dynamics method to predict movement. My final goal is to simulate the injury situation in downhill skiing. The motion includes two phases: jumping and landing. In AnyBody, The model flies in the air in the first 18 steps, then the model lands on the snow slope(I haven't added slope and skis yet). In reality, there is no support to feets during the flight phase, but the muscles overloaded in AnyBody. Maybe Freeposture model lacks some reaction force. Is there a better model to accomplish my task? What is your opinion?

I don’t know if I describe the problem clearly. I will try to make you understand.

Best regards
Zhanpeng Li

Hi Zhangpeng,

I would still use the mocap model for this.

In the jump there is motion on the pelvis, which you constraint to zero in the freeposture model this will impact results, this could be one of the reasons for overloading.

Another possible reason could be accelerations introduced by the measurement, please check the accelerations of the segments in the model, on a segment this is the rDDot property.

Best regards
Søren

Dear Søren,

I changed the human model according to your suggestion and it works. But I still don’t understand something in your suggestions:

In the jump there is motion on the pelvis, which you constraint to zero in the freeposture model this will impact results, this could be one of the reasons for overloading.

Could you explain in detail?Thank you.

Best regards
Zhanpeng

Hi Zhanpeng.

The freeposture model has the pelvic locked into a fixed position, unless you have altered this. This means the translation/rotation of the human model wrt to ground is zero.

In reality this is by far the case in a downhill skiing motion, and this will impact your results, since the model will be "artificially" locked in space.

Best regards
Søren

Dear Søren,

The model I am using now is Standing Model. I changed the driver type to AnyKinEqInterPolDriver. These interpolation drivers are from Freeposture Model. Now there is no overloading warning, but the MaxMuscleActivity reaches 1.0 at some point.

I still don't fully understand “pelvis locked”. Could you show how to implement "locked" mechanism? Are these codes?

AnyKinEqInterPolDriver PelvisGroundDriver ={
    AnyKinLinear lin ={
      AnyFixedRefFrame &ref1 =....EnvironmentModel.GlobalRef;
      AnySeg &ref2 =....HumanModel.Trunk.SegmentsLumbar.PelvisSeg;
    };
    AnyKinRotational rot ={
      AnyFixedRefFrame &ref1 =....EnvironmentModel.GlobalRef;
      AnySeg &ref2 =....HumanModel.Trunk.SegmentsLumbar.PelvisSeg;
      Type=RotAxesAngles;
    };
        Data={
      .JntPos.PelvisPosXVec,
      .JntPos.PelvisPosYVec,
      .JntPos.PelvisPosZVec,
      pi/180*.JntPos.PelvisRotZVec,
      pi/180*.JntPos.PelvisRotYVec,
      pi/180*.JntPos.PelvisRotXVec
    };
    T=.JntPos.PelvisPosTime;
    Reaction.Type={On,On,On,On,On,On};
    Type=Bspline;
  };

Thank you.

Best regards
Zhanpeng

Hi Zhanpeng,

Yes this is the code, this will drive the pelvis using the data in the vectors, when i wrote before i assume this movement would be zero, i forgot we had this moving version. Note that the reaction.type is all ON this means that pelvis has six reactions to the world, which will unload the model, this will not be a realistic boundary condition for a skiing model.

The overloading may come from accelerations imposed by the motion data, try to check rddot on eg. hands or feets... if needed apply a lower cutoff frequency if possible (be careful not to go so low that motion changes)

Best regards
Søren

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