Upper Body Model

Main Forum
21

Thanks for the reply,

I’ve managed to successfully analyse several trials, however some fail during the Kinematic analysis.

For example:

Failed to resolve kinematic constraints. Newton relaxation too small. (final kin. error = 9.079811E-002)
Constraint no. 77 above error tolerance 0.001000, error = 0.014175.
Constraint no. 78 above error tolerance 0.001000, error = 0.008129.
Constraint no. 79 above error tolerance 0.001000, error = 0.002424.
Constraint no. 81 above error tolerance 0.001000, error = 0.001572.
Constraint no. 82 above error tolerance 0.001000, error = 0.014438.
Constraint no. 83 above error tolerance 0.001000, error = 0.011689.
Constraint no. 84 above error tolerance 0.001000, error = 0.001940.
Constraint no. 85 above error tolerance 0.001000, error = 0.003196.
Constraint no. 86 above error tolerance 0.001000, error = 0.001440.
Constraint no. 88 above error tolerance 0.001000, error = 0.001344.
Constraint no. 91 above error tolerance 0.001000, error = 0.001155.
Constraint no. 92 above error tolerance 0.001000, error = 0.001226.
Constraint no. 93 above error tolerance 0.001000, error = 0.001057.
Constraint no. 94 above error tolerance 0.001000, error = 0.003405.
Constraint no. 95 above error tolerance 0.001000, error = 0.005300.
Constraint no. 96 above error tolerance 0.001000, error = 0.002579.
Constraint no. 97 above error tolerance 0.001000, error = 0.002013.
Constraint no. 119 above error tolerance 0.001000, error = 0.006384.
Constraint no. 121 above error tolerance 0.001000, error = 0.004655.
Constraint no. 201 above error tolerance 0.001000, error = 0.005854.
Constraint no. 202 above error tolerance 0.001000, error = 0.001094.
Constraint no. 203 above error tolerance 0.001000, error = 0.001044.
Constraint no. 219 above error tolerance 0.001000, error = 0.004382.
Constraint no. 220 above error tolerance 0.001000, error = 0.001134.
Constraint no. 221 above error tolerance 0.001000, error = 0.007065.
Constraint no. 222 above error tolerance 0.001000, error = 0.024995.
Constraint no. 224 above error tolerance 0.001000, error = 0.001706.
Constraint no. 226 above error tolerance 0.001000, error = 0.001753.
Constraint no. 227 above error tolerance 0.001000, error = 0.007458.
Constraint no. 228 above error tolerance 0.001000, error = 0.003358.
Constraint no. 238 above error tolerance 0.001000, error = 0.001238.
Constraint no. 282 above error tolerance 0.001000, error = 0.088704.
Constraint no. 283 above error tolerance 0.001000, error = 0.003134.
Constraint no. 284 above error tolerance 0.001000, error = 0.090798.
Constraint no. 287 above error tolerance 0.001000, error = 0.003215.
Constraint no. 288 above error tolerance 0.001000, error = 0.001515.
Constraint no. 289 above error tolerance 0.001000, error = 0.001515.
Constraint no. 292 above error tolerance 0.001000, error = 0.001515.
Constraint no. #0 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Mus.ArtificialRake.LinCombDrv’ above error tolerance 0.001000, error = 0.005854.
Constraint no. #1 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Mus.ArtificialRake.LinCombDrv’ above error tolerance 0.001000, error = 0.001094.
Constraint no. #2 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Mus.ArtificialRake.LinCombDrv’ above error tolerance 0.001000, error = 0.001044.
Constraint no. #0 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Jnt.FE.Constraints’ above error tolerance 0.001000, error = 0.004382.
Constraint no. #1 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Jnt.FE.Constraints’ above error tolerance 0.001000, error = 0.001134.
Constraint no. #2 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Jnt.FE.Constraints’ above error tolerance 0.001000, error = 0.007065.
Constraint no. #3 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Jnt.FE.Constraints’ above error tolerance 0.001000, error = 0.024995.
Constraint no. #0 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Jnt.PSProximalConstraints’ above error tolerance 0.001000, error = 0.001706.
Constraint no. #2 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Jnt.PSProximalConstraints’ above error tolerance 0.001000, error = 0.001753.
Constraint no. #0 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Jnt.PSLinDistalConstraint’ above error tolerance 0.001000, error = 0.007458.
Constraint no. #1 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Jnt.PSLinDistalConstraint’ above error tolerance 0.001000, error = 0.003358.
Constraint no. #4 in ‘Main.Studies.KinematicStudyForParameterIdentification.HumanModel.BodyModel.Right.ShoulderArm.Jnt.WristJointDeviation.Constraints’ above error tolerance 0.001000, error = 0.001238.
0.57) …Kinematic analysis terminated
ERROR(OBJ.MCH.KIN3) : C:/D…s/h…s/A…a/A…y/A…x/A…3/A…n/E…s/C…3/GaitFullBody.main.any : KinematicStudyForParameterIdentification.Kinematics : Kinematic analysis failed in time step 57

I’ve checked the markers etc, No Drop-outs, No sudden impossible marker positions etc, I’ve added a filter and weightfunction to exclude drop-outs, but still no luck…

Could you please explain to me what this error means?
Is the model having problems while fitting to the marker positions?

Greetings,

Hans

22

Also, I receive this message in at least one trial

ERROR(OBJ.LIB.OOS1) : C:/D…s/h…s/A…a/A…y/A…x/A…3/Body/A…n/Arm/Muscle.any : biceps_brachii_caput_longum.SPLine : Unexpected exception in the library OOSol :
OOSol exception : MISSING MESSAGE.

23

Hi Hans,

When is the kinematic error occuring?
If it is in the parameter optimization part then a better quess on the marker locations, segments lengths etc may help.

It could also happen if you try to optimize the parameters in a trial which do not have enough motion in it.

The OOSol error is relate to muscle wrapping failing…please for the specific muscle increase the variable StringMesh and see if it solves the problem.

If this not the case try to visualize the muscle in question together with the surface it wraps on(this can be done by adding an AnyDrawParamSurf inside the surface). Usually it can fail if the muscle slides onto the cylinder end caps for example.

Best regards
Søren

24

Hello Søren,

Thanks for your reply,

Yes it is the Parameter Optimization during the Kinematic Analysis:

0.0.3) …Initial conditions are fully updated.
0.0) Kinematic analysis…
—previous error post—

Movements do not look large; subject pushes a cane forward:
Entire body moves up & down, right arm slightly moves, but no large movements…

I’ve measured the subject’s Height, Lower Arm, Hand length and Weight,
I’ve inserted these values in TrialSpecificData.Any

I also increased the StringMesh value for the specified muscle,
from 60 to 100, but I still receive the same error message,

Greetings,

Hans

25

Hi Hans,

Sorry for the slow reply.

When you are running the parameter optimization i would recommend switching off all muscles. When the optimization is running it will try out various kinematic positions which may be unrealistic… and it could be that the muscle wrapping is not able to handle some of these positions.

Additionally it will the optimization down significantly to have the muscles in there.

In the gaitlowerextremity model of the repository the muscles are not used until the motion has been fully determined.

If you still have the kinematic error as well during the optimization it could be related to if you attempt to optimize a segment length but do not have any marker information that would be able to give the length of the segment.

The remedy is to try to switch off the segment optimizations and see if this solves the problem.

This is done usually in the ModelSetup.any file.

Bets regards
Søren

26

Hello Søren,

I don’t have any muscles active during the Parameters Optimization and I’ve switched off all Segment Lengths optimizations. I haven’t encountered the Muscle Wrapping error yet, but I still receive the ‘Failed in Kinematic step 0’ & ‘step 57’ or other steps.

The inverse dynamics analysis takes about 50 minutes to complete 340 steps, I do not wish to tone down the amount of steps, but I am seeking a method to decrease the amount of time…

Greetings,

Hans

27

I’ve added my Model in the attachment.

28

Hi Hans,

The model you send is set to run with Bas\IC S 2.c3d but is it not present. Please specify which one of the C3D files is giving you troubles and we should look at, and make sure it is included in the model.

Best regards, Sylvain.

29

My apologies,

I use this current model for my trials, it has the same test subject;

Problems occur with IC P 1 t/m 5

I’ll add them in a .zip file.

IC P 1 has problems in the Inverse Dynamics
IC P 2 & 3 have errors in Kinematics at time step 0
IC P 4 & 5 have errors in Kinematics at time step 57 - 59

Greetings,

Hans

30

On a side note:

I realize that IC P 2 & 3 have marker problems. Marker Clav drops out at the beginning. I do not yet know how to implement the Weight Function in my Model, which I`m guessing will solve some problems…

IC P 4 & 5 do not have marker drop outs and I don`t know how to fix the problem…

IC P 1 has a marker drop out RUPC at the beginning, but the problem with the Muscle Library 00Sol error occurs midway, so I`m not sure what the problem or solution is…

31

Hi Hans,

Indeed several markers are dropping for IC P 2 & 3. I think the weight function will not help in this case because it will leave some DoF undriven, and the kinematic still won’t be solved. What you can do instead is start the simulation later so that the markers are in place at that time. It works fine when adding 0.4 to tStart in TrialSpecificData for IC P 2 and 0.1 for IC P 3.

The problem with IC P 4 and 5 is that the right arm is fully streched at some point. To avoid it just add 0.005 to the UpperArmLength and LowerArmLength in TrialSpecificData. It is just enough to keep a few deegres of flexion in the elbow, and that makes it run.

Finally for the muscle wrapping error you can try to increase the relative tolerance of the contact for this particular muscle. Find it in the code and use the SPLine.RelTol menber. Default value is 1e-008, try with SPLine.RelTol = 1e-006 for example.

Best regards, Sylvain.

32

Hello,

I haven’t gotten around to try the possible solutions you’ve provided me.

I`ll be off for the next 2-3 weeks, just to inform you why there will be no reply or new information for a while.

Thanks for the help so far,

Greetings,

Hans

33

Hello all,

I’ve been working on this model again and created some data.

I’ve managed to extract the Joint Moments automatically and save them to .CSV file to process in Matlab.

When I examined the Joint Moments for example of the GelnoHumeralFlexion I noticed that the output has a high peak at the first 0-10 % and low peak at the last 90-100%.

Because it is like this for all data/subjects, I`m wondering what the cause could be. I’m guessing that AnyBody treats the measurement data as if the movement starts from still (0 speed) and ends the same.

I’ve added an image of the data (in zip file because of the limited picture dimensions).

Thanks in advance for the reply,

Greetings,

Hans

34

Hi Hans.

Sorry for the slow answer.
The peak does not come from Anybody starting with zero speed. Speed and acceleration are calculated from the first time step.

But there could be an acceleration issue coming from the data itself, that happens. The best way to check it is to look at the acceleration of the arm in the chart window (either the joint or any node of the arm). If you see strange acceleration peaks at the same time as the joint moments peaks then it is likely the cause of it.

Best regards, Sylvain.

35

I’ve looked at the movement in space (.c3d) and at the calculated acceleration in AnyBody. The c3d data shows no peaks or otherwise weird behavior, but the acceleration in AnyBody does. The speed also shows normal data, so i`m not quite sure where this steep acceleration in the start originates from.

36

Hi,

Acceleration peaks sometimes come from a filtering issue. But if you use the model of the repository as template then the filtering of the data is included, so i doubt that this is the cause.

It could be that simply the original recorded movement is like this. I think it is worth to check it if you can.

Best regards, Sylvain.

37

Hello Sylvain,

Thanks for the reply,

I’ve also looked at the .c3d files and it does not show any of those peaks. I’ve checked every marker of the files in which these peaks occur but I couldn’t find anything that would resemble or be the cause of this.

I use the following filter, as you mentioned in your reply.

    Filter = 
    {
    AutomaticInitialConditionOnOff = On;
    FilterForwardBackwardOnOff = On;
    N = 2;
    Fc = {3};
    Type = LowPass;
    };

Greetings,

Hans

38

Hi,

The data should be filtered correctly then. So that means this is just how the data have been recorded. You may not see it when looking directly at the c3d data because only the position is recorded. There is not much to do about it in this case.

But the joint moment peak resulting is not so big it seems. If the movement is fast then it is normal to have some acceleration/deceleration at the begining and end. Does it creates any overloading of the muscles?

Best regards, Sylvain.

39

Helly Sylvain,

Thanks for the reply,

No, according to the references I’ve found so far, the muscles or joints should not be overloaded. It is just unusual considering I’ve recorded 1,5 gait cycle and thus the joint moment data should contain approximately 1,5 period. The first 1/3 should resemble the last 1/3 of the data, this it does with exception of the peaks at the beginning and end of the data. In other words, the acceleration and deceleration do not match when considering the data should be continuous.

Also, I’ve removed the cane from the model to look at the moments when only the arm needs to be moved, swinging an Air-Cane if you will. I’ve found a sine containing 50%-positive 50%-negative moments in the GlenohumeralFlexion. I would think this means that the Extensor is active during the 50%-negative part of the swing. Is this because the acceleration is faster than gravity and thus the arm should actively be moved downward?

Greetings,

Hans

40

Hi,

You wrote that earlier that the peaks are present in all trials. But i tried one of the c3d file you send before (for kinematic error debug) and there are no such acceleration peaks. The file is NC f1.c3d.

Did you check if it is subject specific? Maybe all the trial of one subject have those peaks while other subjects don’t.

Best regards, Sylvain.