Page 1 of 1

Wrist Joint Constraints in MoBL_ARMS model

Posted: Thu Jun 06, 2019 4:50 pm
by jamarsh
Hi there,

I'm having an issue in porting the MoBL_ARMS model from v3.3 to v4.0. I open the 3.3 model file in 4.0 and the only warning that appears is that the 'deviation' and 'flexion' coordinates were labeled as rotational joints, but are actually coupled.

The coupled coordinates are: wrist_hand_r1 (coupled with deviation) and wrist_hand_r3 (coupled with flexion).

The issue is that both deviation and flexion now do not act properly when using the sliders in the coordinates tab. Additionally, deviation and flexion values are now in radians (instead of degrees) in the viewer. In 3.3 they were all in degrees.

The most noticeable issue is when in max extension (negative flexion). At about -0.328 rad the wrist stops extending (lower limit is -1.222 rad). At this point, the other wrist coordinates (deviation and pro_sup) stop responding as well. If I adjust the sliders for deviation and pro_sup and then start to flex the wrist, once I pass that -0.328 value the other coordinates snap into their new positions.

Everything works as expected in v3.3, deviation and flexion values are also in degrees. Additionally, the other constrained joints in the model (the shoulder) work as normal as well.

What I have tried/ looked at:
  • Disabling the constraints - at which point I can manually manipulate the coordinates to work. The extension locking issue is also corrected
  • Changing the joints to coupled in v3.3 before opening in v4.0
  • Comparing the coordinates, joints, and constraints in the model file - there were no differences
  • Comparing the wrist constraints to other constraints. The only notable difference was that the 'SimmSpline' function had a name ( <SimmSpline name="f18"> )
To make matters even weirder -

Does anyone know what is causing these issues? Is there anything else I can test or try to fix it?

I've attached some pictures showing the difference in wrist flexion/ extension between v3.3 and v4.0 for reference. I've also attached the and the model file generated by default in v4.0, the original version is available here: https://simtk.org/frs/?group_id=657.

Thanks,

Joe Marsh

Re: Wrist Joint Constraints in MoBL_ARMS model

Posted: Fri Jun 07, 2019 11:16 am
by jamarsh
I tried opening the MoBL_ARMS model without muscles ("MoBL_ARMS_module1_nomuscles.osim) in v4.0, and it looks like it works correctly.

Besides the muscles not being present the only difference between the model with no muscles and the one with muscles is this bit of code:

Code: Select all

<!--Flag indicating whether or not the values of the coordinates should be prescribed according to the function above. It is ignored if the no prescribed function is specified.-->
<prescribed>false</prescribed>
Which is in the coordinates section of every joint.

I tried deleting those lines of code from every joint and still no luck in getting the wrist joint to work in 4.0

Re: Wrist Joint Constraints in MoBL_ARMS model

Posted: Fri Jun 07, 2019 11:17 am
by jimmy
There is some information in the changelog.
The MotionType of a Coordinate is now fully determined by the Joint. The user cannot set the MotionType for a Coordinate. There are instances such as in the leg6dof9musc and Rajagopal2015 models, where a Coordinate was assigned an incorrect type (e.g. when a coordinate of a CustomJoint is not a measure of a Cartesian angle). In 4.0, the coordinate is correctly marked as Coupled since a function couples the coordinate value to the angular displacement of the patella in Cartesian space. NOTE, this causes issues (e.g. opensim-org/opensim-gui#617, #2088) when using kinematics files generated in 3.3 (or earlier) where Rotational coordinates have been converted to degrees. Because OpenSim 4.0 does not recognize the coordinate's MotionType to be Rotational it will not convert it back to radians internally.
The arms model has a a few weird joints so I am not surprised that this is in an issue. I would say that you should reach out to the model Authors and ask them to update their model for 4.0. Otherwise, if you can't make the updates yourself, I would suggest just using 3.3.