For some model and coordinate inputs to MocoTrack, 'inDegrees=yes' is not respected

[carmichaelong]

From March 2020 Workshop, a participant used a modified drop landing model and coordinates file as input to a MocoTrack problem. The coordinates file had inDegrees=yes but this was not respected as the *_tracked_states.sto file had the same values in the table but the header had inDegrees=no.

Still WIP as I try to isolate the problem. Steps tried so far:

1. Using the participant's files in C++ still yielded the same behavior, so it doesn't seem MATLAB specific.
2. Using the 2d_gait.osim model and referenceCoordinates.sto did not have the same behavior (i.e., worked as intended, the *_tracked_states.sto file correctly converted to radians and the header had inDegrees=no). To create the corresponding reference file in degrees, I used:

Model myModel = Model("2D_gait.osim");
myModel.initSystem();
Storage myStorage = Storage("referenceCoordinates.sto");
myModel.getSimbodyEngine().convertRadiansToDegrees(myStorage);
myStorage.print("referenceCoordinates_deg.sto");

[chrisdembia]

It's good to know that it works in some cases.

If the issue is model-specific, it could be related to coordinates that 3.3 treated as rotational but that 4.0 treats as coupled.

[aaronsfox]

Hi @chrisdembia & @carmichaelong

I have a potential kink to add to this issue. I've been running a gait sim with a 'coordinates.sto' file serving as the joint coordinate states for the optimisation to track. This was in degrees (and appropriately labelled) and this worked fine in an inverse simulation when the filename was placed into a TableProcessor - but when used in a tracking simulation caused some headaches. Despite being appropriately labelled and the *tracked_states.sto file being converted to radians correctly - the end optimisations joint coordinates finished really messed up. The kink here is that the states tracking goal objective result was really low - so it thought it did a good job!

Since then I went back to the start and made sure the original coordinates file was in radians, and now I have a much more accurate solution. The tracked joint coordinate states match well with the original file, and the corresponding states goal objective value has remained low.

[chrisdembia]

Thanks for sharing. Would you be willing to share files to reproduce your issue, over email?

[aaronsfox]

No problems @chrisdembia - I'm just waiting for a final test optimisation to finish on this data. I'll send through the relevant data and code to you by e-mail once it's done.

[chrisdembia]

In files that @carmichaelong sent me from the March OpenSim workshop, the issue is that OpenSim includes any trailing whitespace in the value of inDegrees. A Storage file with inDegrees=yes<lots-of-whitespace> will be parsed so that the whitespace is included in the table's metadata.

@aaronsfox, I'm not sure this is the cause of the issue for you, but if so, there's a quick fix: remove the trailing whitespace.

I'll try to address this in opensim-core's DelimFileAdapter.

[aaronsfox]

@chrisdembia I just ran a quick test on the code I sent you - it didn't seem that there was white space added within the process I used. Nonetheless, I've just started working with radians in all contexts now and haven't come across the issue I mentioned. It's somewhat of a band-aid solution, but advising to work with radians may be a good idea