IK problem occured only in the first few frames in Opensim3.3

Provide easy-to-use, extensible software for modeling, simulating, controlling, and analyzing the neuromusculoskeletal system.
POST REPLY
User avatar
X.Z. Wang
Posts: 2
Joined: Mon Apr 19, 2021 7:48 pm

IK problem occured only in the first few frames in Opensim3.3

Post by X.Z. Wang » Tue Jun 14, 2022 8:07 pm

Dear all:
I met a strange problem when executing IK that I cannot figure out what was going wrong. As you can see in the attached figures, the neighbouring two frames (230 and 231) have nearly the same experiment data (blue markers), but a dramatically difference in the IK results of the two can be clearly seen (pink markers). The figures below showed the dividing point before which the IK results of the frames are as similarly strange as that of frame 230. And interestingly, this phenomenon usually only occurs in the first several frames during a IK execution, and a sudden change happens at the dividing point mentioned above.
Thus, I write this post to sincerely ask for suggestions about why it happens and how to deal with it. Thank you~~

(Notes: The model markers on the forearm and hand are not included in the IK setup file, and the coordinate axis showed is the world coordinate that doesn't move with the model.)
Attachments
a3e08e28c70b4dbb0635253a364ec08.png
a3e08e28c70b4dbb0635253a364ec08.png (217.7 KiB) Viewed 256 times
1c97d0ea60eea63fb41846afd4c16e4.png
1c97d0ea60eea63fb41846afd4c16e4.png (199.31 KiB) Viewed 256 times

Tags:

User avatar
John Davis
Posts: 56
Joined: Mon Aug 26, 2019 7:42 am

Re: IK problem occured only in the first few frames in Opensim3.3

Post by John Davis » Fri Jun 17, 2022 1:22 pm

In my experience when this happens it is almost always because one or more of the markers were labeled wrong for a few frames of data. When you look at the relevant frames in the raw data from your camera system, are the markers labeled correctly in the problematic frame? Sometimes cameras will inappropriately "gap-fill" a trajectory when a marker briefly drops out and it ends up swapping places with another marker. Inspecting the errors of each marker marker by enabling the set_report_marker_locations property in the IK tool setup might also help figure out what's causing the issue: you can compare the model marker locations to the experimental marker locations to see where (and when) discrepancies crop up.

Another thing that could be causing strange IK solutions like this would be if you are bumping up against the limits of your coordinate ranges of motion. I've seen this with the rotational coordinate about the vertical axis of the "root" segment of models (would be pelvis_rotation for a gait model, probably torso_rotation for yours): if this coordinate is limited to -90 to +90 degrees, but the model "should" be pointing outside this range of angles (e.g. because the lab's coordinate system is oriented differently) you can get really weird results. I'm not familiar with shoulder models but I think it's possible you could run into the same issue if certain shoulder coordinates were close to their limit.

User avatar
X.Z. Wang
Posts: 2
Joined: Mon Apr 19, 2021 7:48 pm

Re: IK problem occured only in the first few frames in Opensim3.3

Post by X.Z. Wang » Sat Jun 18, 2022 7:27 am

Hi John,
I've read your post carefully, and thanks a lot for your sincere reply~
For the first cause you listed that may lead to the strange IK result, I've experienced the marker labeling mistake that a marker's name changes suddenly in a few frames during gap-fill in Vicon Nexus. And I think it may result from a couple of markers that are closely fixed and small time gaps, which misleads the system into that labeling mistake. Considering experiment marker positions in the two frames 230 and 231 (fig.1 and 2) have nearly no visual change, sharp coordinate changes should be observed for at least two markers around these frames, which cannot be seen from the data file,However. And due to the accessibility of a most precise model pose for that experiment data showed in fig.2, range of motion may not be a block for the access to suitable poses in frame 230 and before.
Thanks again for your suggestions~~And fortunately, it only occurs in the first few frames during which captured data are not wanted, and I can go ahead with my work temporarily. Hope the puzzle can be solved in the following days.

POST REPLY