cvhammond
commented
2 years ago Written by @bfregly:
Jason,
I am glad that we are discussing this issue now, as it highlights that there is a higher-level issue that we need to resolve first before we can answer the immediate question of whether or not to require a pre-existing IK settings file for Joint Model Personalization.
Whatever we decide, we want the design of our four modules for model personalization to be:
Self-consistent with each other in terms of how inputs and outputs are defined, and
Consistent with OpenSim to the extent possible.Based on the information provided by Marleny, it appears that Joint Model Personalization is the ONLY model personalization module that could make use of an OpenSim .xml settings file. Since all of the other model personalization modules do not require any OpenSim settings file, I think it would be best for Joint Model Personalization not to require one either. Otherwise, Joint Model Personalization would require two settings files - an OpenSim settings file and an NMSM settings file. Since we will set all marker tracking weights to one during Joint Model Personalization anyway, and since we can extract which markers to track from the list of joints being calibrated (the list will contain the markers on the proximal and distal segment of each joint being calibrated), the marker tracking weights in an OpenSim IK settings file won't matter anyway.
I am now asking myself the question of whether any of the other model personalization modules will require an OpenSim settings file to run standard OpenSim analyses repeatedly. If we stick with the design philosophy that the user has to pre-generate and pre-process all the necessary input data to get it into shape for a module to do its job, then I don't think any of the other three modules would need an OpenSim settings file of any kind (Mohammad - please correct me if I am wrong). We will make users run their own Inverse Kinematics, Inverse Dynamics and Muscle Analyses to generate the inputs needed for Muscle-tendon Model Personalization, Ground Contact Model Personalization, and Neural Control Model Personalization. So what makes Joint Model Personalization different is that an explicit OpenSim analysis has to be run repeatedly as part of the module's calibration process (Oops! Maybe I am wrong here. I guess for Ground Contact Model Personalization, we have to run an OpenSim Point Kinematics analysis over and over as we tweak the motion of the feet and get updated positions and velocities of all the spring elements under each foot. I'll verify with Marleny that this is the case.)
The main challenge I see with eliminating the OpenSim IK settings file is the coordinates functionality. People need to use the coordinates functionality to a) impose motion on certain joints motions measured by some other means (e.g., knee motion measured using dynamic x-ray methods), or b) keep a joint near a certain angle (e.g., keep the lower back joint in a slightly flexed position rather than snapping back and forth between slightly flexed and slightly extended). So my current inclination is to include those capabilities in our JMP module. We could kill two birds with one stone simply by adding a
Adding coordinate tracking will require an addition to our cost function. Starting out, I would suggest simply adding coordinate error terms to the cost function identical to how we include marker error terms in the cost function. That way, coordinate tracking errors would be equally weighted with marker tracking errors. After we try some examples (I have some Knee Grand Challenge data with dynamic x-ray measurement of knee motion) that I can use to test out the combined cost function. Note that coordinate tracking will matter only in situations where multiple joints are being calibrated at the same time (e.g., if the ankle and hip are being calibrated while the knee motion uses tracked coordinates). It may be necessary to make the user input a
Given all of these observations, I propose that we do NOT read in an OpenSim IK settings file when doing JMP and instead read in the following IK settings information using our own JMP settings file:
It was suggested by @bfregly that we require an IK settings file (
<ik_settings_file>for each task. This would remove the need for a<time_range>and<marker_file_name>element at the task level because they can be inferred from the IK settings file.I think this boils down to: do we expect most/all of the GUI simulations to have done an IKSolver round before JMP and will they likely have a IK settings file already? If so, we should implement this change.