Xsens bvh file inverse dynamics error

Hey all,
While running analysis for inverse dynamics from Xsens kinematics file, I get the following errors. BVH file generated using XSens MVN Analyse 2019 and seems to be the case for all our BVH files. The demo BVH file has no issues.

Constraint #368 is above tolerance 1e-06, error = 0.211230, segment constr. 'Main.HumanModel.BodyModel.Right.Leg.Seg.Patella'.
Constraint #369 is above tolerance 1e-06, error = 11.980220, segment constr. 'Main.HumanModel.BodyModel.Left.ShoulderArm.Seg.Clavicula'.

Export setting for BVH in Xsens

  • Replace Initial frame with T-pose is checked
  • Units in cm

'Anybody' else have the same issue :slight_smile:


PS: Few other loading model issues encountered were solved by regenerating file using the latest MVN 2019.

Hi Vijeth,

Welcome to this forum.

I am not sure it is the cause of the problem, but i would not export the first frame as a T-pose.
This will mean that the model would have to go from t-pose to a completely different posture in one frame, this may cause problems.

Secondly i would export in m not cm.

I would have thought that both these things may have prevented you from running the kinematic analysis which you already completed?

Best regards

Hi Soren,

Thanks for your response. I tried unchecking the T pose and changed cm to meters. Still have same issues. Infact, even before I run the analysis, the models created by these bvh files look monstrous ! The warning are shown below. Still have the error tolerance issues.

Updating expressions…
WARNING(OBJ.MCH.KIN7) : C:/U…s/V…i/D…s/A…x/A…o/Body/A…n/L…M/Mus.any(98) : GastrocnemiusLateralis1.SPLine : Penetration of surface : cyl : Via-point ‘GastrocnemiusLateralis1Node’ on ‘SPLine’ is located below the wrapping surface’cyl
WARNING(OBJ.MCH.KIN7) : C:/U…s/V…i/D…s/A…x/A…o/Body/A…n/L…M/Mus.any(934) :


I think my advice on the changing from cm to m was not well thought through.

In the BVH settings there is a scale factor for translational scale the property is called

Main.ModelSetup.BVHFileData.TranslationScale (see labspecific.any file)

The model i AMMR has this property to be 0.01… so it expects the translations to be in cm in the BVH file.

So you can either change it to 1 if you did the export in m or keep it as 0.01 and do the export in cm, this will be the same.

Hope it helps

Best regards

Hi Soren,

As I mentioned, the demo file works with default setting (translationScale was 0.01). So makes we wonder if the demo bvh file is in cms.

Our files dont seem to even in cm scale. But in any case, I did change the scale to 1 and loaded a bvh file (exported in XSens in meters). I still the same error

Progressing to solve kinematic optimality conditions and hard constraints.
Failed to solve kinematic optimality conditions and hard constraints after 5 fallback attemps.
Constraint violations for study ‘Main.Studies.MarkerTracking’ :
Constraint #3 is above tolerance 1e-06, error = 0.000004, constr. #0 in ‘Main.HumanModel.BodyModel.Trunk.JointsLumbar.L5SacrumJnt.Constraints’.
Constraint #4 is above tolerance 1e-06, error = 0.000014, constr. #1 in ‘Main.HumanModel.BodyModel.Trunk.JointsLumbar.L5SacrumJnt.Constraints’.
Constraint #18 is above tolerance 1e-06, error = 0.000003, constr. #0 in ‘Main.HumanModel.BodyModel.Trunk.JointsLumbar.T12L1Jnt.Constraints’.

Is there something else I can change. Maybe increasing the tolerance? In most cases error is low except some, for e.g

Constraint #26 is above tolerance 1e-06, error = 0.083529, constr. #5 in ‘Main.HumanModel.BodyModel.Trunk.JointsLumbar.SpineRhythmDrv’.
Constraint #29 is above tolerance 1e-06, error = 0.054159, constr. #8 in ‘Main.HumanModel.BodyModel.Trunk.JointsLumbar.SpineRhythmDrv’.

Constraint #35 is above tolerance 1e-06, error = 0.100520, constr. #14 in ‘Main.HumanModel.BodyModel.Trunk.JointsLumbar.SpineRhythmDrv’.



Hi Vijeth,

If the file works with the scaling of 0.01 then this is likely to be the correct setting for the file.

To verify simply open the bvh file in a text editor and look at the values for “offset” these represent the joint distances/dimension of bones.

You can also look at the data section below in the file usually column 1-3 represent hip translations.

So if you see values there in cm use a scaling factor of 0.01

Best regards

Hey Soren,

So I looked at both the demo bvh001 file and our file. I have a few interesting updates.

  1. Scale is definitely in cms in demo file. So that is settled.

  2. Frame Time: 0.004167 in demo file and Frame Time: 0.016667 in our data. So it seems like our data is at 60Hz and demo file is using XSens link at 240 Hz

  3. I thought frame rate was the main issue until I poked around more at the demo file. I found this file called Output/BVH01_BVH_Trajectories.anyset When I deleted this in the demo folder, I got the same tolerance errors for even for the demo file !!

Loading and overriding values from : ‘…Output\BVH01_BVH_Trajectories.anyset’ …
ERROR(SCR.SCN1) : Cannot open file : …\MocapExamples\BVH_Xsens\Output\BVH01_BVH_Trajectories.anyset

*…Constraint violations for study ‘Main.Studies.MarkerTracking’ : *
Constraint #0 is above tolerance 1e-06, error = 0.000189, constr. #0 in ‘Main.HumanModel.BodyModel.Trunk.JointsLumbar.SacrumPelvisJnt.Constraints’.

The anyset files in output folder were not being regenerated. I then downloaded AMMR v2.0 and compared with AMMR2.2.1 and went down a rabbit hole. Turns out that AnyOperationSequence BVH_PreProcess was not being loaded in RunAnalysis.

So changing

Main =
   AnyOperationSequence BVH_PreProcess = ...


Main = 
  RunAnalysis.LoadParameters = {
      AnyOperationSequence BVH_PreProcess = ...

in BVH_ModelPreprocess.any helped me get further.

I think thats a bug in new version.

Currently running inverse on the entirety of my file, its a slow process. Maybe this issue is solved but will know for sure in a few hours. Meanwhile, I thought I’d let you know.


Hi Vijeth,

I wanted to point out that in the new AMMR version 2.2.1 there was an update to the BVH MoCap example: Pre-processing the BVH data is now a separate operation which saves the virtual marker positions to a file. Thus, this step can be skipped the next time the model is reloaded.

With regards to the sampling rate, I’d be curious to see how your model runs if you collect the data at 240 Hz. Is it possible to capture one test trial at 240 Hz to see if this is the issue?

Hope this helps.

Best Regards,

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