I am using the GaitFullBody template in the AMMRV1.4.1 to work with C3D data from the Microsoft Kinect (which may have significant error). This device provides ‘marker’ locations at the distal end of segments (estimated to be within the joint center) so for the arm there are only markers at the shoulder JC, elbow JC, wrist JC, and the tip of the middle finger. I added/changed the appropriate markers, positioned them, and increased the marker error tolerance to obtain motion that looks pretty good except for the right elbow. At 25% through the trial the elbow ‘flips’ around such that it is in an impossible position - i.e. 180 deg pronated at the elbow joint. I have tried adjusting the OptXYZ, WeightXYZ, and shoulder rhythm ON/OFF but without much luck. Do you have any suggestions to fix this?

If you only have markers in shoulder jc, elbow jc, wrist jc, and finger, this is not a good marker configuration for controlling the pronation/supination. Basically these markers do not change much when pronating the forearm, and this is the fundamental problem here.

To control the pronation/supination you need additional markers which are placed medial and laterally in the wrist for example, such markers would change the position with an elbow pronation. Alternative a joint driver on the pronation/supination dof could be applied, and maybe the angle can be taken kinect somehow?, and applied directly to the pronation dof in the model using some appropiate offset.

Unfortunately, the Kinect is a markerless system so I cannot just add markers. Nor is there a forearm pronation output. It sounds like the best option might be to just fix or make-up the pronation angle to something that looks about right.
This is a limitation of the Kinect system and there is not much we can do about it. Thanks for trying,

Cool video, at 2.24 min into the video he says he can export to bvh…

AnyBody can read in this format using AnyInputBVH. This could bring you forward since the BVH file contains joint angles, so you could use a combo of the markers you have already have and the pronation angle taken from the right location in the BVH file.

I haven’t been able to spend too much time on this but I did look at the demo file for reading in BVH files, and it’s not yet very clear to me how to use it. The columns are not labeled as in a c3d file but I assume that if I can somehow pick-out the correct column of data I could set-up an interpolation driver to drive elbow pronation. In the gaitfullbody model is this the variable I would need to drive?: Main.Studies.KinematicStudyForParameterIdentification.
HumanModel.BodyModel.Interface.Right.ElbowPronation.Pos

Related to this issue, I have another question: Is there a model similar to the GaitFullBody model that is driven solely by a BVH file? I found out that the output from iPi software is only BVH and we have to go through additional trouble of converting to a c3d file. If we can use a BVH file directly that would save us the trouble. Is there anything like this?

Also, an additional question: We would like to approximately understand the amount of energy used to move the body for a given task (ignoring external forces, at least initially). One of the outputs is Pmech and for one of the joint angle output files I included Pmech in the output. See below. However, the values were all zero. Is this the power as exerted by muscles and hence if there are no muscles included the power is zero? Or is this be the power required to accelerate the body segments? These should be the same if there is no wasted or negative work but for this case we are happy to neglect that. Is there an easy way to determine the energy used?

The dof " Main.Studies.KinematicStudyForParameterIdentificat ion.
HumanModel.BodyModel.Interface.Right.ElbowPronation" is the one to drive for the right elbow pronation. You are right the BVH files do not usually contain a description of names etc that allow you determine which dof it is, but it should be possible to find the elbowpronation somehow…

Sorry we do not have model like the GaitFullBody driven solely by BVH, but this is entirely feasible.

The PMech value of the study is the “Current mechanical power applied to the system.” The reason why it is zero in this analysis is that it is being solved using the “Kinematics.PosAnalysisOnlyOnOff=On;”

This means that no velocities are calculated here… so for this model please repeat this for the inverse dynamic study then you will see a value.

The muscles also have the possibility to read out powers, please look at Pmt and PMet.

Thank you for your quick reply and suggestions. I still have not figured out the BVH file but that is okay, at least for now, since we are satisfied with fixing the elbow at a reasonable pronation angle (vs. backwards).

With regards to the Pmech calculation: I have tried the kinematic analysis with the “Kinematics.PosAnalysisOnlyOnOff” switch turned on and off and it makes no difference to the file - I still get zeros for Pmech. I have also tried the inverse dynamics analysis with the switch on and off, and with/without simple muscles but in every case I get the following error:
“KinematicStudyForParameterIdentification.InverseDynamics : Muscle recruitment solver : solver aborted due to singular KKT matrix”
I theory, I shouldn’t need muscles to determine Pmech but I thought that, possibly, without muscles there were a bunch of empty matrices causing the singularity error. Please let me know if you have other ideas to try.

I am sorry, what i suggested before about the kinematic analysis settings is wrong.

To calculate PMech you do need to run an inverse dynamcis analysis, otherwise the forces are not calculate/updated correctly.

You are right that you do not need the muscles to calcualte PMech but you do need the inverse dynamic analysis to caluclate the forces.

All models in the repository comes in two configurations one with muscles and one with moment generating muscles in the joints. Both configuratins should allow pmech to be calculated.

Since the inverse dynamic analysis fails in your model there must be a DOF in the model which is not balanced.

Simply add AnyReacForces to the joints in the model until it becomes stable, then remove them one by one to figure out which dof in the model that are missing muscles or reactions to be balanced.

I have been able to make a little bit of progress with regard to the power calculation and I am getting results, however, they don’t appear to be correct.

Before I get to the results I was just going to mention what I did to get the inverse dynamics analysis to run. I made a couple changes, at least that I can remember; (1) There was a BodyPartsSetup2.any file for the “MotionAndParameterOptimizationModel” and a BodyPartsSetup.any file for the “InverseDynamicModel” and I changes both of these to be “BodyPartsSetup2.any”. (2) I also made sure to operate the entire “RunMotionAndParameterOptimizationSequence” vs. just the “KinematicStudyForParameterIdentification” individually. I think the KKT matrix is altered in the MotionOptimization study and that helped the inverse dynamics to run without the singularity error.

Back to my issue with the power calculation - upon close inspection the position data appears to be discontinuous, and therefore the instantaneous velocity and power has sharp peaks and looks very noisy (see attachments). I have tried changing the filtering and also increased the “nStep” value from 1/6 to 1/1 in the “MotionAndParameterOptimizationModel” section but it doesn’t appear to make much difference. Here is the filtering that is currently being used (in the ModelSetup file):

MarkerInterPolType = Bspline;
MarkerBsplineOrder = 8;
MarkerFilterIndex = 0;
AnalogFilterIndex =1;
Filter = {
N = 2;
Fc = {10};
Type = LowPass;
};

Also, one last question. What is your convention/sign for work being done by gravity and work being done by the (torque) muscles? It’s not easy to tell, but it looks like the power is negative when the body is lowering/falling.

Sounds good that the inverse dynamic analysis is running…

I agree that the position data looks jumpy, i would try altering the cutoff frequency Fc by lower it a bit.

You can also alter the bsplineorder by increase it.

You are right concerning the Pmech sign convention when working against the gravity pmech is positive, please see the small example below, with one mass.

Main = {
[SIZE=3]AnyFolder[/SIZE] MyModel = {
[SIZE=3]AnyFixedRefFrame[/SIZE] GlobalRef = {};
[SIZE=3]AnySeg[/SIZE] Mass={ Mass=10; Jii={0,0,0}; [SIZE=3]AnyDrawRefFrame[/SIZE] drw ={};};
[SIZE=3]AnyKinEqSimpleDriver[/SIZE] drv ={
[SIZE=3]AnyPrismaticJoint[/SIZE] jnt={
[SIZE=3]AnyRefFrame[/SIZE] &ref1=..GlobalRef;
[SIZE=3]AnySeg[/SIZE] &ref2=..Mass;
Axis=y;
};
DriverPos={0};
DriverVel={1};
};
}; [SIZE=3]// MyModel
[/SIZE]
[SIZE=3]// The study: Operations to be performed on the model
[/SIZE][SIZE=3]AnyBodyStudy[/SIZE] MyStudy = {
[SIZE=3]AnyFolder[/SIZE] &Model = .MyModel;
Gravity = {0.0, -9.81, 0.0};
};
}; // Main