OpenSim model generation with just one or two lower limb bone meshes?

[Karen Fitzgerald]

Hi all,

I had a few questions somebody may be able to help me with. Perhaps These are obvious questions but I haven't currently had success with what I'm doing.

My problem is I have subject specific segmented data of the right pelvis and proximal portion of the femur. I also have motion capture data for the same subject.

Following the Bone Mesh Generation Workflow tutorial I can get create lower limb meshes (currently I just have the right femur). http://map-client-fai-workshop.readthed ... shgen.html

My question is now if I now try to run the OpenSim Model Generation Workflow to create a full opensim 2392 model with my new femur mesh can I assume that for the fieldworkmodeldictsourcestep plugin I should just point it to the new femur mesh, i.e the .ini file would only have one entry:

Code: Select all

[femur-r]
geof = ../../wfdata/FAS-906/map_output/fitted_meshes/my-femur-right.geof
ens = ../../wfdata/common_data/atlas_meshes/femur_right_quartic_flat.ens
mesh = ../../wfdata/common_data/atlas_meshes/femur_right_quartic_flat.mesh

Also its not clear what this .ens file is (do I need to re-create it) and do I manually create this .mesh file from my .stl file created in Bone Mesh Generation step?

Thanks all for your help.

Karen

[Bryce Killen]

Hi Karen,

A few clarification questions which may help.

The .ini file used in the fieldworkmoeldictsourcestep is simply a file to define the directories for your meshed geometries. For you it seems like you will have a meshed pelvis and right femur. In your ini file you should have two entries, 1 for Femur , 1 for Pelvis

Code: Select all

[pelvis]
geof = C:/Users/s2799022/Desktop/Data/M01_FullSSModel/Output/pelvis.geof
ens = C:/Users/s2799022/Desktop/MAPcourse/mapclient-fai-workshop-master/wfdata/common_data/atlas_meshes/pelvis_combined_cubic_flat.ens
mesh = C:/Users/s2799022/Desktop/MAPcourse/mapclient-fai-workshop-master/wfdata/common_data/atlas_meshes/pelvis_combined_cubic_flat.mesh

[femur-r]
geof = C:/Users/s2799022/Desktop/Data/M01_FullSSModel/Output/femur-r.geof
ens = C:/Users/s2799022/Desktop/MAPcourse/mapclient-fai-workshop-master/wfdata/common_data/atlas_meshes/femur_right_quartic_flat.ens
mesh = C:/Users/s2799022/Desktop/MAPcourse/mapclient-fai-workshop-master/wfdata/common_data/atlas_meshes/femur_right_quartic_flat.mesh

In all cases, when you edit the .ini file you need to only edit the "geof" entry, which will point to your subject-specific meshes file for the respective bone. The .mesh and the .ens files define the element based model, they define the interaction and connections between different nodes and elements.

If you do no include a entry for a specific body (eg. tibiafibula-l) this geometry will be created in the fieldworldlowerlimbtwosidegenration step ( where you fit the MAP skeleton to your .trc file, this is the initial step when you create the subject-specifc g2392 model. If an entry is found in the .ini file, this entry/geometry is used instead of trc generated geometry.


To summarize

1. The mesh and the ens files are the generic files you downloaded with the mapclient
...mapclient-fai-workshop-master\wfdata\common_data\atlas_meshes\

2. You need to edit only the .geof file to your own generated .geof file from the BoneMeshGenerationStep

3. In the .ini file ONLY include the bones (femur-r etc) you have created subject-specific bones for. The others will be filled in using bones based on the TRC fitting step.

Hope this answers your questions, if anything is unclear don't hesitate to ask for any clarification

Thanks

Bryce Killen

[Karen Fitzgerald]

Hi Bryce,

Thanks for your speedy reply. Everything is laid out very clearly and makes complete sense to me as that is what I had done initially before posting up the question. But unfortunately something is going wrong.

As a check I decided to use the data provided with the mapclient ...mapclient-fai-workshop-master\FAS-906\ assuming I only had meshes for the right femur and the pelvis.

I used the mocap data (StaticCalibration.trc) and the right femur and the pelvis (FAS-906-femur-right.geof, FAS-906-pelvis.geof ) provided.

The .ini I used was this:

Code: Select all

[pelvis]
geof = C:/Users/kfitzge1/Documents/Work/mapclient-fai-workshop-master/wfdata/FAS-906/map_output/fitted_meshes/FAS-906-pelvis.geof
ens = C:/Users/kfitzge1/Documents/Work/mapclient-fai-workshop-master/wfdata/common_data/atlas_meshes/pelvis_combined_cubic_flat.ens
mesh = C:/Users/kfitzge1/Documents/Work/mapclient-fai-workshop-master/wfdata/common_data/atlas_meshes/pelvis_combined_cubic_flat.mesh

[femur-r]
geof = C:/Users/kfitzge1/Documents/Work/mapclient-fai-workshop-master/wfdata/FAS-906/map_output/fitted_meshes/FAS-906-femur-right.geof
ens = C:/Users/kfitzge1/Documents/Work/mapclient-fai-workshop-master/wfdata/common_data/atlas_meshes/femur_right_quartic_flat.ens
mesh = C:/Users/kfitzge1/Documents/Work/mapclient-fai-workshop-master/wfdata/common_data/atlas_meshes/femur_right_quartic_flat.mesh

Everything else for the workflow is set as per: http://map-client-fai-workshop.readthed ... imgen.html

The openSim model however is wrong (left leg far away from the rest of the body)


Any ideas?

Thanks so much for your help. Its great that there is somebody to answer questions.

[Bryce Killen]

Hi Karen,

The issue seems to be that for one reason or another the trc and MRI data have different origin , no too surprising given the different protocols for collecting each of these data.

The first thing to check is in the OpenSim model itself, if you check the joint hip_l , specifically if you check the location/orientation in both child and parent. The way the model is constructed, the orientation in parent and child should be 0 , 0 , 0 , also the location in child should be 0,0,0 if any of these are non zeros it could cause the problem you are seeing. If changing/checking those doesn't solve your problem the next step is to check the location in parent, this should also be identical to the entry for hip_r except for the z (last) entry which should have opposite polarity.

If these are both correct , it would seem something has gone wrong with one of the local transformations and we will have to dive a bit deeper but check that first.

Let me know how you go

Cheers
Bryce

[Bryce Killen]

Hi Karen,

Being the impatient/inquisitive person I am , I tried to replicate your problem. Good news, I had the exact same output as you did. Upon inspection the location in child was set to an incorrect value. This is related the the difference in coordinate frame / origin I mentioned in the previous reply.

I have a python script which will set all the DOF's and location in child to zero I can pass on if you would like. This may seem like a bit of a "cheat" by setting everything to zero as it no longer respects the MRI/TRC pose , however if you then go and run the MarkerPlacer tool in OpenSim the pose of the model is updated and will respect the pose in the Static trial.

Thanks
Bryce

[Karen Fitzgerald]

Hi Bryce,

Glad you had the same results as me. Yeah I figured the location in child was non zero, just hadn't got a chance to reply.

I was concerned about this 'cheat' as you say and what implications it would have further downstream. But now that you've explained it, it doesn't seem to be an issue.

That python script would be useful however for future cases, whats the best way of sharing?

Thanks for going to so much effort.

Best,

Karen

[Bryce Killen]

Hi Karen,

To provide a bit of extra info about why it isn't really a cheat. The origin on each body is actually defined based on shapes fit the bone. For example, a sphere in the acetabulum is used to define the position in parent for the hip. While the in theory the origin is based on a sphere fitted in the head of the femur. Due to this being the origin of the femur, when the geometry (output as vtp for OpenSim) is defined in it's local coordinate frame, this point is used as the origin of the body so in the local frame it will always be [0,0,0]. If for some reason there is a deformity of the femoral head/neck , the centre of the fitted sphere will still be defined as the origin of that femur geometry. Therefore the position of the joint in child will still be [0,0,0].

If you send me a message here on simTK with your email address I can just send you the script. I am in the process of developing a public repository for some of these "extra codes" I use with my MAP models, but I need to separate what I freely share in the public repo/keep close to my chest until development is finalized on other plugins / codes which aren't ready for release.

Also , if you haven't already head over to my forum post (below this post) about World Congress if you will be attending to vote in the poll.

Thanks
Bryce

[Karen Fitzgerald]

Hi Bryce,

Just a follow up question that I think is related.

I'm getting incorrect adjusted values for the optimal_fibre_length and tendon_slack_length only on the right femur after the Fieldwork Gait2392 Muscle HMF step in the OpenSIM Model Generation Workflow.

I'm guessing from looking at the size of the values that this is because its using the co-ordinates of the model when it has the incorrect location in child values (i.e non-zero). Is there a way around this? Maybe don't perform the Fieldwork Gait2392 Muscle HMF step, set the joint co-ordinates to zero in the model then perform the muscle adjustments on this model? Can this be done as a separate workflow maybe, I looked into it but haven't found a solution yet.


Thanks,

Karen

[Bryce Killen]

Hi Karen,

The process carried out in MAP does not necessarily guarantee accurate tendon slack and optimal fibre lengths. To overcome this you have a few options.
1)If you wish you can run the muscle fitting after the model has been set to the generic configuration, but there is no guarantee this will immediately fix your problem. To do this you will need another plugin (I can provide) to read in an OpenSim model as input for the muscle step
2)There is a new version of the muscle fitting step which uses different methods (detailed here: https://www.ncbi.nlm.nih.gov/pubmed/28573974). This may give you a closer estimation of physiological tendon slack and optimal fibre lengths. There is a MAP plugin for this but I will need to check whether I can share it.

But both of these solutions will not necessarily guarantee physiological step

Our approach, even after generating the model is to run a muscle parameter optimization routine, this method has been published and could fix some of the errors which you are seeing. The publication is here : https://www.ncbi.nlm.nih.gov/pubmed/26776930

I would recommend using some type of optimization routine to adjust these values, because we know even in scaled generic models this can be a problem.

Cheers