I have just personalized Plug-in-gait_Simple Lower_Extremity model for my subject. The subject performs a normal walking on a two-belt treadmill. I adjusted all the parameters such as Bodymass, Bodyheight, Forceplate type, Gravity direction, initial guess for the body posture, First and last frames, OptimizeAnthropometricsOnOff option and all other adjustment required to have a reliable analysis .
There is no problem when I run parameteridentification (not satisfactory with thorax markers yet) and marker tracking analysis. However, In the Inversdynamic stage I receive "Overloaded muscle configuration" error for muscles such as TibialisAnterior and ProneusLongus.
After a long investigation I realized that the problem is related to the moments when both feet touch the same belt. At these moments, no ground reaction force is applied to one of the feet and that foot shows different color for above-mentioned muscles and the muscle activity are significantly high (between 6 and 8!).
Am I right? is this the real reason causing the problem? If so, then what is the solution? I think there is something wrong with ForcePlateAutodetecton. Should I define the toe-off and heel-strikes manually?
Thanks in advance. Looking forward to hearing from you soon.
I think the issue can be the velocity setting for the contact detection. The default value for ground speed is zero, in a treadmill this will not work.
You can use the setting "GroundVelocity" to change this.
So when you create the forceplates, you write e.g.
It is good to mention, when feet are in contact with different treadmill bands as shown in the following picture, I receive no overloaded muscle configuration error:
I think Maybe something is wrong in Automatic-Detection?!
Another question is about the ALLOW_MULTI_LIMB_CONTACT option. Is this for the cases like here where both feet touch the same forceplate (treadmill belt)? I think it helps when I turn it ON.
Also, just for better understanding, muscle activity for the left leg muscles are plotted in the following chart:
I think you can simply supply the speed as non constant so either using and interpolation function or point at a moving segment with the velocity you want.
I think this overloaded situation could occur if kinematics of the foot suggest there was contact and the force-plate did not detect it quick enough, so it could be sync issue.
In this situation did the plate detect contact? if not it would also explain it. The color of the plate will indicate if contact was detected.
In this setup I think the ALLOW_MULTI_LIMB_CONTACT should not be used there is no chance of having both limbs on same plate.
I think at the overloaded configuration, AnyBody can detect the contact correctly right at the contact occurrence moment but the reaction force is applied late. I think it would be more understandable using animations as follows:
If you pay careful attention, for the first left foot heel-strike there is overload configuration because the right foot is also in contact with the left belt and it receives two reaction forces, one from the left and one from the right belt and when the left foot starts to touch the left belt it takes time to apply a reaction force to it and as soon as the reaction force is applied to the left foot, the overload configuration is solved:
However, for the second heel-strike there is no overload configuration because the right foot is only in contact with the right belt. In this situation only one Ground Reaction Force is applied to the right foot and the reaction force for the left belt is ready to be applied to the left foot as soon the contact is detected.
I would first disable multi limb contact if you did not already do this.
Secondly I would set both limbs to point at either right or left, this will enforce either left or right foot contact only.
This is the settings to do this.
LIMB1: objname, optional
Location of the limb 1 (defaults to: Main.HumanModel.BodyModel.Right.Leg.Seg.Foot)
LIMB2: objname, optional
Location of the limb 2 (defaults to: Main.HumanModel.BodyModel.Left.Leg.Seg.Foot)
Thanks for your suggestion. I could not perform your second point. I searched the AnyScript Reference but I could not find LIMB option. Where should I add these setting lines and what should I write exactly? Something like this:
I tried your suggestion. However, it does not solve the problem and I still have the mentioned problem:
I tried different combination for LIMB 1,2: LIMB2 for forceplate1 and LIMB1 for forceplate2 and both LIMB for one forceplate and the problem still remains. only if I use LIMB1 (right foot) for forceplate1 (left belt) and LIMB2 for forcepate2 then I would not receive the overload error but this configuration is just like turning off both forceplates and no ground reaction force vector is shown which is not reasonable!
It looks like both feet touch the same belt for some period of time but the detection only picks up one of them and applies all the force to one leg although in reality it was from both legs. However, there is no good fix for that I think because you do not know how the load has to be distributed between the two legs from your measured data - there are infinitely many ways the load can be distributed between the two legs.
Addtionally, I agree with Søren that it looks like the data has been heavily fitered too.
I am trying to do a treadmill gait simulation in FDK (AMS 7.2, AMMR 2.2), the analysis would fail at the moment of heel off. Any idea why would that happen?
Thanks for your reply. I attach the c3d data file which I have received and used for this analysis. Please take a look to see if there is something wrong with the data and its filtering.
I looked at both files the cropped_filtered file looks wrong the forces are too heavily filtered as I see it. The other file looks better but in this file there are many steps where the foot touch both plates, so you have to select carefully which frames to do the analysis on, but there some good steps there.
It is hard to answer with this info, I imagine it could be because the FDK DOF would need to move a lot, when the load changes, possibly try to use more timesteps,
.
