seventeen subjects have been recorded by Xsens MVN Awinda inertial motion capture system with 17 wireless motion trackers and an update rate set to 60 Hz.
I am interested in estimating the Ground Reaction Force out of the BVH files. Here, the Xsens T-pose is in the beginning of every BVH file I am going to analyse. Thus, I was loading the inverse dynamic model, running the BVH_PreProcess and started to run the analysis. Some estimations succeeded, others resulted in errors. While analysing the BVH data of two different subjects I got errors during kinematic analysis. It is said that the constraints are above tolerance.
Please find one screenshot attached. I would be happy if you could assist me in how to proceed.
Please try to avoid having the T-pose in the export since this may cause problems, when the model needs to go from t-pose to real position within one frame.
So either manually delete the frame in the bvh file or export the bvh again.
Thanks for your reply. In my data the T-pose is captured within the first frame. Thus, I adjusted the StartFrame in trialspecificdata.any. I set the StartFrame to ‘2’, loaded the model, started the BVH_PreProcess and ran the analysis, but I still got an error in kinematic analysis. Then, I set the StartFrame to ‘7’ to be absolutely sure that there is no T-pose related data in the future analysis. However, again I got an error in kinematic analysis.
both approaches you have recommended above worked, thanks a lot.
However, in the updated environment (approach 2, v.7.2.3, AMMR 2.2.3) the inverse dynamic analysis took about 6 days whereas the first approach (Rotation1PiFixOnOff = Off with AMMR 2.2.1) took only 1 day. For time reasons I would prefer approach 1. Can you tell me what Rotation1PiFixOnOff = Off causes? Do you think it is harmful for acurate data?
6 days sounds as a lot, how many frames do you have in the study?
Normally it can be a good idea to split long analysis into several to avoid having too many frames in the study.
The Rotation1PiFixOnOff is a setting that allows a filter to be enabled which will look at the rotation data in the BVH file and seek to remove jumps of 1PI. If this filter is off it will not be applied so if the data has these jumps the kinematic analysis may stop. If you do not see kinematic problems with the setting to be off you will usually be fine. If the filter is on it can sometime cause problems because the jumps in the angles may not always be exactly 1PI.
The new version 7.2.3 should resolve all issues with jumps in angles, we have not noticed a slow down but we will check it, is this something you see consistently also for models with fewer frames?