Inverse Dynamics Fails in Mo_CapModel

Hello,

I have succeed inputing the C3D file and the kinematics operation can be done successfully.
But there is still some questions.
First, after I did the InitioonConditions, The process went well. But the look of the model seems to be strange as you can see in the picture – His stomach is going too far forward. Also the ankle eversion of his left foot is abnormal too. Is there some reasons? How should do?

Second, I do the inverse dynamics operation and the whole step is 1748.
Sometimes it fails for the reason that : " C:/P…s/A…y/A…1/AMMR/A…n/E…s/M…3/M…l/JointsAndDriversOptimized.any(12) : JntDriverTrunk : Time, ‘t’, has an invalid value for this interpolation" in step 91.
Sometimes it fails with the reason that :“Muscle Recruitment solver: solver aborted after maximum number of iterations” in step 258.
Really hope someone can help me with these.

Thank you
Lydian

Hi Lydian,

Here are some answers:

The posture on the picture looks a bit strange as you pointed out. To correct it i would add an extra driver for ankle inversion eversion because it appears that you have only one marker on the forefootthis can be done in the extradrivers.any file. Since the ankle, heel and toe marker are almost on a line they are not well suited for controlling the inversion/eversion. Secondly the posture of the spine can be adjusted by alterning the hip markers a bit, this will change the pelvic tilt.

The first of the two errors you list “l/JointsAndDriversOptimized.any(12) : JntDriverTrunk : Time, ‘t’, has an invalid value for this interpolation” in step 91." means that you have tried to run the inverse dynamic analysis on the model but the motion data was not ready, because the kinematic analysis must have been either stopped or failed.

The muscle recruitment error can be due to missing boundary conditions… in the image of the model i see no forceplates?

If your c3d file contains forceplate data the forceplates needs to be enabled, if you have no forceplate data you will need to use the GRF prediction model instead.

Best regards
Søren

Hello,

Thank you for your reply.
1 As for the ankle, they are normal after changing in the extradrivers.any file.
2 The posture of spine changes little as I adjust the hip and trunk markers and the look gets better but seems to be abnormal too. Also, the distance between the red and relative blue markers is close when the position of the spine is abnormal. That is to say, when I change the number in the “sRelOpt” , the red marker moves and their diatance becomes farther which may affect the kinematics operation. So I think if there are other reasons?
3 The kinematic operation runs successfully too. But as for the inverse dynamics, there are some problems.
3.1 First, it shows some warnnings saying:"Flexor_Carpi_Radialis.SPLine : Number of allowed iterations for contact solution has been exceeded in Main.Studies.HumanModel.BodyModel.Right.ShoulderArm.Mus.Flexor_Carpi_Radialis.SPLine. Final error at time 1.987865e-001: 2.170215e-007 rel error, 3.340991e-006 abs error".
Another kind of warnning is about " Flexor_Digitorum_Superficialis__Digit2.SPLine : Penetration of surface : cyl : Via-point 'Main.Studies.HumanModel.BodyModel.Right.ShoulderArm.Seg.Radius.Via_Flexor_Digitorum_Superficialis_Digit2' on 'Main.Studies.HumanModel.BodyModel.Right.ShoulderArm.Mus.Flexor_Digitorum_Superficialis__Digit2.SPLine' is located below the wrapping surface 'Main.Studies.HumanModel.BodyModel.Right.ShoulderArm.Seg.Hand.Ref.FlexorMuscleCyl.cyl"
3.2 After those warnnings, it failed in step 609 (all steps are 1748) for the reason “Muscle recruitment solver : solver aborted after maximum number of iterations
As the c3d contains no forceplate data, I use the GRF prediction model instead according to your reply. So I am wondering the reasons cotributing to the problems above.

4 As the inverse dynamics finished incompletely, I look at the results in chart 2D/3D. The GRF_Prediction_Right/Left is zero while the muscle force and muscle activity show some datas. This c3d is about a person jumping forward and maybe the GRF prediction method does not suit jummping?

5 Also the MaxMuscleActivity data is abnormal too as you can see in the picture"

"
I am also wondering where I can see the units as for different objects like “AnklePlantarFlexion” and some others.

Looking forward to your reply. Thanks for your reading.
Best Wishes
Lydian

Hi Lydian,

Here are some quick answers:

1: sounds good
2: i still think if you moved all markers on the pelvis by rotating them a bit around the pelvis center it might help solving this issue. I did can not see on the picture if you have marker on the lower spine, it could also be part of the problem if you have this.
3: These error related to muscle wrapping and i think you ignore them for now they are details in the big picture.
4: Clearly the activation is entirely wrong i think you GRF prediction is not work, You may bee to adjust the normal direction of the virtual plates See the file “ForcePlates_GRFPreiction.any” you may also need to adjust some of the other settings of the plates like LimitDistHigh and Low. These changes should make it possible for the model to have contact to ground, something i suspect the model is lacking right now, this could explain the high activation and the muscle recruitment error.

Concerning the units you can not really see them in AnyBody. It is the user who decides the units when constructing the models. The AMMR models are in SI units. Rotational measures will report angles in radians, but many of these angles are then converted into degrees for convenience. In a mannequin.any file all input angles are in degrees but if you look at angular output in the interface folder it is in radians, which can be confusing.

If you are in doubt what a value represents try to locate it in the script to get ensure you understand what it represents.

Hope it helps.

Best regards
Søren

Hello,

Thank you for your reply!
Most problems are solved now.

Best Wishes
Lydian

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