Settings of the kinematic solver

Main Forum
1

Hello

I am getting this Error, see details below. How do we go about making adjustments for a “more appropriate settings of the kinematic solver” ?

8.0) Inverse dynamic analysis…
WARNING(OBJ.MCH.KIN6) : E:/Damon/++ A…l_1/Body/A…n/Arm/Interface.any(82) : GHMeasure : Close to singular position : Orientation close to Gimbal Lock, i.e., first and third axis of rotation being parallel
Failed to resolve kinematic constraints. Newton relaxation too small. (final kin. error = 3.263981E-003)
Constraint no. 520 above error tolerance 0.000001, error = 0.000001.
Constraint no. 603 above error tolerance 0.000001, error = 0.000003.
Constraint no. 727 above error tolerance 0.000001, error = 0.000001.
Constraint no. 786 above error tolerance 0.000001, error = 0.000002.
Constraint no. 787 above error tolerance 0.000001, error = 0.000002.
Constraint no. 819 above error tolerance 0.000001, error = 0.000002.
Constraint no. 821 above error tolerance 0.000001, error = 0.000002.
Constraint no. 877 above error tolerance 0.000001, error = 0.000011.
Constraint no. 878 above error tolerance 0.000001, error = 0.000033.
Constraint no. 879 above error tolerance 0.000001, error = 0.000009.
Constraint no. 880 above error tolerance 0.000001, error = 0.000003.
Constraint no. 881 above error tolerance 0.000001, error = 0.000002.
Constraint no. 882 above error tolerance 0.000001, error = 0.000003.
Constraint no. 883 above error tolerance 0.000001, error = 0.000008.
Constraint no. 885 above error tolerance 0.000001, error = 0.000001.
Constraint no. 886 above error tolerance 0.000001, error = 0.000008.
Constraint no. 887 above error tolerance 0.000001, error = 0.000019.
Constraint no. 888 above error tolerance 0.000001, error = 0.000010.
Constraint no. 889 above error tolerance 0.000001, error = 0.000003.
Constraint no. 890 above error tolerance 0.000001, error = 0.000004.
Constraint no. 895 above error tolerance 0.000001, error = 0.000009.
Constraint no. 896 above error tolerance 0.000001, error = 0.000008.
Constraint no. 897 above error tolerance 0.000001, error = 0.000002.
Constraint no. 898 above error tolerance 0.000001, error = 0.000002.
Constraint no. 900 above error tolerance 0.000001, error = 0.000011.
Constraint no. 932 above error tolerance 0.000001, error = 0.000050.
Constraint no. 933 above error tolerance 0.000001, error = 0.000117.
Constraint no. 935 above error tolerance 0.000001, error = 0.000024.
Constraint no. 936 above error tolerance 0.000001, error = 0.000004.
Constraint no. 952 above error tolerance 0.000001, error = 0.000319.
Constraint no. 953 above error tolerance 0.000001, error = 0.003264.
Constraint no. 954 above error tolerance 0.000001, error = 0.003263.
Constraint no. 962 above error tolerance 0.000001, error = 0.000011.
Constraint no. 963 above error tolerance 0.000001, error = 0.000008.
Constraint no. 964 above error tolerance 0.000001, error = 0.000008.
Constraint no. 1007 above error tolerance 0.000001, error = 0.000002.
Constraint no. 1020 above error tolerance 0.000001, error = 0.000001.
Constraint no. 1021 above error tolerance 0.000001, error = 0.000001.
Constraint no. 1024 above error tolerance 0.000001, error = 0.000003.
Constraint no. 1025 above error tolerance 0.000001, error = 0.000002.
Constraint no. 1026 above error tolerance 0.000001, error = 0.000003.
Constraint no. 1027 above error tolerance 0.000001, error = 0.000003.
Constraint no. 1028 above error tolerance 0.000001, error = 0.000003.
Constraint no. 1029 above error tolerance 0.000001, error = 0.000003.
Constraint no. 1035 above error tolerance 0.000001, error = 0.000010.
Constraint no. 1036 above error tolerance 0.000001, error = 0.000015.
Constraint no. 1037 above error tolerance 0.000001, error = 0.000027.
Constraint no. 1038 above error tolerance 0.000001, error = 0.000014.
Constraint no. 1043 above error tolerance 0.000001, error = 0.000002.
8.51) …Inverse dynamic analysis terminated
ERROR(OBJ.MCH.KIN3) : E:/D…n/+…1/+…w/3…c/1 - UniversityOfMiamiBoxLiftingModel_5_1_12_30-30-UR_v1.main.any(946) : InverseDynamicStudy.InverseDynamics : Kinematic analysis failed in time step 51

ERROR(OBJ.MCH.KIN3) : ‘ObjectName’ : Kinematic analysis failed in time step ‘integer’
Explanation:
This error may arise when the kinematical analysis fails to complete. This implies that the kinematic constraints does not have a solution or simply that the solution was not be found with under the given numerical circumstances.
In the latter case, more appropriate settings of the kinematic solver may allow for a solution. Additionally, a better choice of initial positions will improve the solver ability to solve the constraints.

Sincerely thanks you so much
Damon Stambolian

2

Hi Damon,

This error description is quite broad and it would all depend on the actual configuration. Quite often it means that requested kinematic constraints cannot be satisfied for one or another reason: conflicts, insufficiency to describe the system, etc. And unfortunately I cannot help you with this very brief description.

But given that it is a box lifting simulation - possibly you have a wrist constraint, which somewhat frequently conflicts with other constraints. Could you have a look how it behaves and possibly give us a better description of your problem?

You could also try running kinematics only and possibly make a screenshot of the last successful step (sometimes it helps to see what will go wrong next).

Many thanks,
Pavel

3

Hello Pavel

Possible it is because of this foot angle. you can see in attachment. What do you think?

I also looked at the wrist in model view and did not see any problem. (i hid the box so we can see the wrist better) But the markers for the wrist were a little bit off from where they actually are on the body. What do you think?

Sincerely Thank you
Damon

4

Damon,

A couple of possible problems:

  • the configuration of foot markers is not great, try fixing ankle eversion.
  • wrist markers are not perfect, but might not be the problem. It seems that your box markers are not optimized very well - this will give you a very large error. Do you have a small weight on those markers? Could it be polluting the solution?

Kind regards,
Pavel

5

Hello Pavel

I’m pretty sure the weight of the box is attached to the hands, and the box markers define the 3D location of the box. Attached is the main code, and a better picture of the box and markers. What do you think? Do you think there is some problem with this?

I’m tried the eversion of the footby changing the "AnyVar SubTalarEversion "value. This did not work. So in the Vicon motion capture of this trail I created a new Toe Marker , a virtual marker so the toe was moved in some, this prevented the foot from being angled so much, and it ran in AB. See attachment.

Sincerely thank you very much!
Damon

6

Hi Damon,

  1. When I mentioned ‘weight’ of the box marker, i meant a kinematic error weight , which you define when adding a marker. Not the box mass. What I see is that the box markers are inaccurate compared to the measured motion. Meaning that kinematic error will be large, which might result in a failure that you are observing. That could have been fixed by changing marker relevance to be low (changing weight of the marker). But I believe it is not the case. Please define marker positions on the box better.

  2. And good to hear it helped.

Regards,
Pavel

7

Hello Pavel

Ive attach a zip file of the Virtual marker code to move the toe marker, used in Vicon Nexus, in case someone may want to use it.

This code can be used for any segment to add virtural markers. So if for example they forgot to put a marker on a segment during motion captue, it can be added later as long as the segment has at least three markers.

Sincerely very much thanks!!
Damon

8

Hi Damon,

I just saw the error between virtual and real markers - thus, the comment. Possibly something for you to check. But it solves - i guess it is ok.

Thanks for the initiative. Could you send it to me? I might find a better place to attach to than a thread on the forum.

Many thanks,
Pavel

9

Hello Pavel

I was able to upload in the Forum. But I can send it to you as well.

Sincerely have a great day,
Damon

10

Hello Pavel

I had said this before

"I’m pretty sure the locations of the red Box markers are defined by the .STL file for the CAD rendering of a box. Do you think these can be moved through adding code in the AB model? "

But i apologize i was wrong.

The markers for all the corners can be moved. For example for the marker A, the marker location can be improved by increasing the third value to 0.24. AnyRefNode A ={ sRel = {0.1, 0.1, 0.24}

11

Hi Damon,

Good to hear, hope this helps you to find further problems.

Kind regards,
Pavel

12