It seems like the tolerance limit is exceeding the threshold value in the right side. I have checked the model after completing the RunParameterIdentification using a static trial data. The right elbow is twisted compared to the left elbow which is the difference between left and right side. How can I fix this twisted elbow on the right side? I have used the similar markers and coordinate directions on both left and right for optimization. What are the possible reasons to have this difference between left and right, and how to fix that.
On a different note, this same optimization works fine to run a "running' trial, but fails to run the "walking" trial. This seems to be unusual.
In addition, the static optimization (RunParameterIdentification) takes a long time to complete (about 3 hours). I have done the optimization in 2 steps. Lower body optimization runs fine and I have no issues with this. But the upper body optimization is taking a long time and doesn't look good.
The problem with the twisted elbow can often occur when there is a single marker on the elbow. Especially, when you are doing a standing trial (or any other trial with the arms straight), you can run into a posture that is close to gimbal lock. The solver may find incorrect solutions in this case.
What you can do in such situations is to add a weak driver on appropriate degrees of freedom (pronation/supination or glenohumeral external rotation) that will guide the solver to the correct solution. You can find the file ExtraDrivers.any through LabSpecificData.any. In the folder ExtraDrivers, you can enable the weak drivers through the BM statements:
#define BM_MANNEQUIN_DRIVER_GLENOHUMERAL_EXTERNAL_ROTATION_RIGHT ON
#define BM_MANNEQUIN_DRIVER_GLENOHUMERAL_EXTERNAL_ROTATION_LEFT ON
#define BM_MANNEQUIN_DRIVER_ELBOW_PRONATION_LEFT ON
#define BM_MANNEQUIN_DRIVER_ELBOW_PRONATION_RIGHT ON
There, you can also set the weight of these weak drivers:
You may not need both GH ExternalRotation and Elbow Pronation. See what works for you.
Regarding the time for optimization, hopefully the above fix should reduce the time. It's possible that the solver took a long time because it could not converge to a solution.
Thank you for your response. I am facing similar issues and I thought it might be better to reply here rather than creating a new post. Please see attached for the specific errors.
I am using BVH kinematics here and the participant performed lifting, carrying, pushing, pulling, and cart pushing. I get that error when the kinematics get to the cart pushing operation. Can you advice on the right weak drivers to activate? Also, I get some errors that I am close to gimbal lock but I am unsure how to resolve this since I am using actual kinematics.
The BVH model is a little bit different compared to the c3d model. Firstly, there is no parameter optimization process, and secondly, the markers in the bvh model are virtual markers. So, essentially, the bvh model generates a stick figure model that follows the joint angles from the raw data. There are virtual markers on the stick figure and the human model that go in the marker tracking process to generate the motion from the stick figure for the human model.
So, normally, the bvh model is more robust. When you see the error, do you see some joint at an extreme angle. This can cause some issues and you can try to add a weak driver for that degree of freedom. It's hard to say just from the error messages. But if you can share a picture from the time step that you see the error, it can be easier to identify some awkward posture that is causing the issue.
Thanks much for your reply. I have used the GH ExternalRotation weak driver and it helped to prevent the twisting in the elbow during optimization. It also reduced the time. However, I still have issues with the optimization in the upper body. Let me explain this issue:
I am doing the optimization in two steps. First, I do the lower body optimization (including the trunk). Then, I use the optimization output values as reference for lower body and do the upper body optimization. Lower body optimization works fine and I can use this lower body optimization technique as an universal protocol for different subjects and conditions (sometimes, I need to modify the relative position of some markers slightly and redo the lower-body optimization).
Then, I don't get expected result for upper body optimization, specially in the wrist and elbow. Anybody markers don't follow the experimental markers in upper-body optimization. I am in search of an universal technique that I can use for optimization of upper-body in different subjects and different conditions. Now, I have to use different markers and directions to run the upper-body optimization for different subjects and conditions. If I have the GHD driver turned on, sometimes a specific optimization marker-set doesn't work. I have the following markers in upper-body from Vicon Plug-in upperbody markerset (Upper body modeling with Plug-in Gait - Nexus 2.12 Documentation - Vicon Documentation)
CLAV, STRN, LSHO, RSHO, LUPA, RUPA, LELB, RELB, LFRM, RFRM, LWRA, RWRA, LWRB, RWRB
Could you please suggest me on how I should use these upper-body markers to optimize the upper-body? which markers and which optimization directions? weight? Please let me know if you need any additional information.
Please see the pictures attached. I have used the GHD External rotation, Wrist Flexion and Wrist Abduction weak drivers. Elbow pronation driver did not help in most cases.
It would be great to have your feedback on this. Thank you in advance.
In my opinion, you should also optimize the forearm marker. It's not placed on an anatomical landmark, so it's position will be different for different subjects. If it's not getting optimized, then it's normal that the optimizer will try to fit the arm to best match the position of the forearm and the two wrist markers. This will bring an error if there is uncertainty about the forearm marker.
On the one hand, it's not desirable to introduce extra drivers because they will work against the mocap data. But, on the other hand, if your mocap data is not working, then it may make sense to introduce it.
Besides the weak drivers, you may also consider adding range of motion limits for specific joints. You can read more about it over here.
