Hello everyone,
I am currently looking at ways to make my simulation workflow more efficient. My setup involves using BVH data from Xsens and force plate data from two Bertec (type 2) force plates (one for each leg). I modified the script from the BVH example to fit my needs. This is how my current work flow goes:
Running BVH_Optimize_origin (script that moves the bvh model feet/hands to a knows position in global space) on the first few seconds of the trial where I know the position of the feet on the force plates. I don't run this script on the entire trial as it takes a long time to complete.
I then use the origin position information and run the full trial IK and ID.
However, due to the inaccuracy of the actual location of the feet during measurement and some sensor drift, I have to manually slightly tweak the the positions on top of step 1 to get good results. This can take quite a bit of time.
I was wondering if there is a way to directly apply the GRFs to a foot segment of the subject (ex: heel) without having to worry about the location of the model relative to the force plates. Because I have GRF data for each leg, I assume this would be possible. If so, how would I go about achieving this? Or is my understanding on this flawed? Any help is much appreciated and I'm sorry if this question has already been asked (I couldn't find it in the forums).
I can't think of a way that you would be able to use the force plate data without the location of the feet on the force plate. You can think about the error that you will have between the center of pressure (COP) from the measured force plate data and the error in the location of the feet. All of that error will be reflected in the inverse dynamics analysis.
For your situation, I can understand that with the inaccuracy in the feet location during the calibration and the sensor drift, the BVH_Optimize_Origin might not work sufficiently. And I can't think of ways that will make this whole process more efficient. There are some ways that you can use but they will require manual adjustment. Here are some ideas:
Can you maybe chop your trial into multiple bvh files and run the origin optimization individually on these chopped trials?
If possible, you can consider doing the origin optimization using multiple intervals in your trial (a time interval at the beginning and if you know another interval with the feet/hand location known, you can add that in the same optimization model): this should consider the effect of sensor drift to an extent.
You can consider running the bvh data with the GRF prediction model, and compare the trajectories of the COP from the measured force plate data and the GRF prediction model. This may also give you a good indication of the error in the BVH origin. Of course, there are some other conditions before you can use GRF prediction model. Based on the error in the COP trajectories you can think of some method to adjust for the sensor drift?
Hello Dave,
I tried applying Fx,Fy,Fz and Mz directly on the footcontactnode on each foot but results were not realistic therefore I am going with the first suggestion of yours to run the origin optimization on a small snippet of the start of the trial and then run the full simulation on the desired interval.
However, i've been having a small problem when running the optimization code. for some reason. I try to set the position of both feet on the desired locations at the start of a trial and see if I can get the origin optimization code to converge. when the code works correctly I get a result that compromises the position between the two desired locations and gives me a fairly accurate result.
WARNING(OBJ1) : PsoasMajorLeft.any(143) : PML4I_TM.SPLine : Number of allowed iterations during contact penetration removal has been exceeded in line segment 0. Final error at time 1.00002 : 6.4973e-08 rel error, 2.01726e-06 abs error
WARNING(OBJ1) : PsoasMajorLeft.any(173) : PML5_TM.SPLine : Number of allowed iterations during contact penetration removal has been exceeded in line segment 0. Final error at time 1.00002 : 8.95319e-08 rel error, 3.10935e-06 abs error
WARNING(OBJ1) : PsoasMajorLeft.any(143) : PML4I_TM.SPLine : Number of allowed iterations during contact penetration removal has been exceeded in line segment 0. Final error at time 1.00002 : 6.4973e-08 rel error, 2.01726e-06 abs error
WARNING(OBJ1) : PsoasMajorLeft.any(143) : PML4I_TM.SPLine : Number of allowed iterations during contact penetration removal has been exceeded in line segment 0. Final error at time 1.00002 : 6.4973e-08 rel error, 2.01726e-06 abs error
and this :
WARNING(OBJ1) : Mus.any(2106) : GluteusMaximusInferior3.SPLine : Number of allowed iterations during contact penetration removal has been exceeded in line segment 0. Final error at time 1.00002 : 1.05382e-05 rel error, 2.08431e-05 abs error
WARNING(OBJ1) : Mus.any(2106) : GluteusMaximusInferior3.SPLine : Number of allowed iterations during contact penetration removal has been exceeded in line segment 0. Final error at time 1.00002 : 1.05382e-05 rel error, 2.08431e-05 abs error
WARNING(OBJ1) : Mus.any(2000) : GluteusMaximusSuperior4.SPLine : Number of allowed iterations during contact penetration removal has been exceeded in line segment 0. Final error at time 1.00002 : 0.000579913 rel error, 0.000287812 abs error
WARNING(OBJ1) : Mus.any(2000) : GluteusMaximusSuperior4.SPLine : Number of allowed iterations during contact penetration removal has been exceeded in line segment 0. Final error at time 1.00002 : 0.000579913 rel error, 0.000287812 abs error
error more often when the optimization fails than when it succeeeds. Turning off one limb and optmizing for only one foot also doesn't work. Note that the same error happens many more times than what's shown above.
I have seen that happen a few times and, from my experience, when the model starts "exploding", it normally doesn't converge. That's because the errors in all the joint constraints force the optimizer to more or less return to the original position. And the errors that you see are normal when your model has exploded.
Optimization, generally, depends a lot on the initial perturbation. So, it can sometimes go in the wrong direction and fail like that.
Normally, you can use a guess for the initial position of the origin and that can help you to an extent. The problem can be that the same initial position may not work on all the trials.
Thanks for the input. From my testing I have found that (as you said) giving a better guess of the initial position, changing up the active interval slightly and changing the length of the overall trial leads to sometimes being able to overcome the exploding model problem.
