IK in 4.0

[Robert Huffman]

We have been attempting to port some of our analysis from 3.3 to 4.0 and have noted significant differences in our IK results. This was discovered on modified versions of the Rajagopal Full Body model available on the OpenSim website. However, I believe I have recreated the issue starting with the files as released in the "Full Body Model w/Sample Sim" downloaded from "https://simtk.org/projects/full_body#". I have attached 3 IK setup files for reference. The first is the unaltered "ik_setup_run.xml" delivered with the package. The second, "ik_setup_run_RTH1_Off.xml", is the same file with the RTH1 marker apply field set to false as below:

<IKMarkerTask name="RTH1">
<!--Whether or not this task will be used during inverse kinematics solve.-->
<apply>false</apply>
<!--Weight given to a marker or coordinate for solving inverse kinematics problems.-->
<weight>50</weight>
</IKMarkerTask>

In the third file, "ik_setup_run_RTH1_1.0.xml", the apply field is set back to true, but the weight field is set to 1.0 as below:

<IKMarkerTask name="RTH1">
<!--Whether or not this task will be used during inverse kinematics solve.-->
<apply>true</apply>
<!--Weight given to a marker or coordinate for solving inverse kinematics problems.-->
<weight>1</weight>
</IKMarkerTask>

When we run IK using these three files, we see that the trajectories vary between the original setup and the "<apply>false</apply>" scenarios. This is expected, however, when we compare the "<apply>false</apply>" trajectory with the "<apply>true</apply>,<weight>1</weight>" trajectory, they appear to be exactly the same. It is also true that in the "<apply>false</apply>" scenario, IK reports errors associated with the RTH1 marker.

Our suspicion is that IK is somehow interpreting "<apply>false</apply>" as "<apply>true</apply>,<weight>1</weight>"?

Anyway, let us know if we are doing some thing wrong.

Regards,
Ken Huffman

[jimmy d]

There was a bug in how the IK weights were set in 3.3 that was fixed for 4.0-- this is most likely the reason for the differences.

[Robert Huffman]

How does this explain that when we set the <apply> to "false" in the IK setup file, IK still reports errors associated with that marker? Are you saying that setting the <apply> field to "false" in 4.0 does not cause that marker to be ignored by IK?

[David Frenkel]

James, thank you for the 3.3 error reference. I am in the same group as the original poster, and we think there may be an issue in 4.0 that one can see without reference to 3.3.

Briefly:
We find that <apply>false</apply> doesn't turn off the marker, but leaves it on, although with the weight reset to the default value of 1. We infer it from the fact that a marker with <apply> set to "false" and with <weight> set to any number produces an identical IK output to when <apply> is set to "true" and <weight> is set to 1.

Elaborating:
Three runs with the following options for one of the markers,
===
<apply>true</apply>
<weight>1</weight>
===
<apply>false</apply>
<weight>25</weight>
===
<apply>false</apply>
<weight>1</weight>
===
produced three identical *.mot output files, which all differed from the output produced with
===
<apply>true</apply>
<weight>25</weight>
===
.

[jimmy d]

There does seem to be some bug in the IK marker reference's. We will attempt to fix this for the next minor release-- in the mean time it seems like the best hack is to remove markers from the model that you don't want to be tracked.

[David Frenkel]

Thanks, James.

Is the next minor release 4.1? Is there an estimated date for it?

[jimmy d]

Is the next minor release 4.1? Is there an estimated date for it?

More like 4.01
No estimated date yet-- hoping for mid-summer.