simtk.org

We seem to have run into an issue tied to saving the results of the Length Initialization step when running it with the Muscle-Tendon Personalization pipeline. It looks like it is tied to how the data is Passive Moment Data is getting reshaped for the eventual sto file. I'm guessing it is tied to either the numberOfMoments variables, since it is equal to 3 (number of trials within the passive dataset) and not 48 (number of moment within the model). Also for some reason when debugging the modelPassiveMoments variable that is created within the saveMtpPassiveMomentData appears to clear for some reason (unless I misunderstood line 33 and the permute is overwriting the data stored in the structure). The saved mat files of the workspaces are too large to attach (>500kb) and won't compress more, but can be emailed if needed. Cheers.

Hi Max!

Thank you for sending us your .mat files over email!

It looks to me like the problem is with the structure of your passive moment data.

When saving passive moments in the current version, we are assuming the experimental passive moment files are only actuating one joint at a time. If you look at the MTP tutorial (https://simtk.org/frs/?group_id=2397), you'll see that the passive moment inverse dynamics files only have one column with numbers, and every other column is zeros. This allows us to isolate only one joint per file when saving the passive moment data, and ignore the rest of the columns because we don't have data for them. This would allow us to reshape your data from 101x48x3 to just 101x3, because only one column out of the 48 would have numbers, so we can ignore the others.

The issue you're experiencing is due to your passive moment data not having this same "one actuated column, the rest are zeros" structure. Instead, every column has non-zero numbers in it. Therefore the code is not ignoring the other columns, and thus we have the reshape error.

To help solve this, could you please describe your passive moment data, namely how it was collected, and if there is a way it could conform to the aforementioned "one actuated column, the rest are zeros" structure?

Thanks, and let me know if you'd like me to clarify anything!
-Rob

Ahhh, I was curious how/why you all were able to get perfect single joint movements. So we are having to collect the passive movement data using motion capture (and subsequently OpenSim Inverse Kinematics) to get our joint angles. For cameras to successfully pick up markers the arm is held straight out in front of the person during the passive tasks, while the thumb or index finger is passively moved at an isokinetic pace. We don't collect any external force/torque recordings during these tasks. All but one of the tasks is moving the joint in a single direction, the caveat being that between researcher/subject variations and IK computational error the joint is not moved 'purely' in one direction.

What would your thoughts be on this method for conforming out data to the "one actuated column": If we go and take our passive tasks that targeting single joint movement and transforming it to fit the intended NMSMs data structure. For example, in our data if we took our passive Radial Thumb Ab/Adduction task (Th_ABAD_Radial prefix in our data), which is analogous to hip ab/adduction, and set all the joint angles calculated from IK to 0 except the single joint associated with Radial Thumb Ab/Adduction. Then run inverse dynamics and muscle analysis with the "conformed" kinematics in preparation for MTP length initialization. If this is possible, wouldn't this also open up the possibility of augmenting passive collection data by supplying synthetic passive range-of-motion tasks that we currently struggle to get with motion capture?

Hi Max!

Thank you for your explanation on how your passive data is collected. After further inspection, the format of your passive data is not compatible with MTP length initialization in its current form. We are working on expanding MTP length initialization to support use cases such as yours.

Your method to transfer your data to the currently supported structure seems to be sound and could work for the time being. If there is a specific joint that you are moving, then setting every other joint to be zero in the IK file could work.

Thank you for working with us, and we will have a fix out to support this use case in a future patch. In the meantime, feel free to reach out with any more questions regarding this.

-Rob

Hi Max,

I'd like to rescind my previous response. The error you're observing is purely a saving issue, therefore your MTP runs are still valid. I apologize for the misunderstanding.

We will still work on a change for saving passive moment data so that you can better visualize your MTP Length Initialization results.

Thanks,
-Rob

Hey Rob,

All around good news that its just a saving issue (awesome that the core MTP processing can handle the difference in passive data formats). In the meantime I do have one questions about getting the rest of my MTP results to save since if appears saving the passive moments is the first step in saving all the various MTP results, and the error prevents the rest of the saving scripts to run I'll follow up on the forum as well, but figured I would include it here. Would it make sense to replace line 48 in the MuscleTendonPersonalizationTool.m with a repeat of line 51, or is there a place where it would make sense to put the Matlab equivalent of Pythons try, except function, or would be better to run Matlab with the debugger running and run the remaining lines of the MuscleTendonPersonalizationTool.m in the debugger mode?

Thanks again for all your help.

All of the saving functions are entirely independent from each other, so you can just comment out lines 45-47 in saveMuscleTendonPersonalizationResults.m (the lines responsible for saving passive moments), and everything else will save. You don't need to change anything in MuscleTendonPersonalizationTool.m.