Hi all,
Thanks for developing this great tool! You have definitely saved me a significant amount of time! I am wondering if you
could please answer several questions I have in relation to the README outputs and just general questions.
1. In the Models folder there is a final.osim and optimized_scale_and_markers.osim - what is the difference between these models?
2. In the marker list I have several markers that are fixed, for example the radius and ulna markers, however their position in
the final.osim model is adjusted - is this to be expected?
3. If I have ground reaction forces in my uploaded C3D files does this lead to (inverse) dynamics been performed with the purpose
of null residuals whilst scaling is simultaneously done?
4. Is there a reason for why the optimization max iterations is 500? This does not lead to an optimized solution as the optimality
criteria are not met. Also, what are the equality constraints included within the optimization process?
5. What does ">> MARKER WARNING: Dropping marker "", only on 2.882883 percent of frames" mean?
6. What does ">> MARKER WARNING: Dropping marker r_knee for suspicious acceleration on frame 17" mean? Is it
possible to ignore this warning and use the marker?
7. What determines whether a marker is flickering? ">> MARKER WARNING: Ignored flickering marker r_shank_antsup from frames 13 to 15"
8. Why is a marker getting relabelled to another marker? Can this be avoided? ">> MARKER WARNING: Relabeled r_shank_antsup as r_knee on frame 16 to preserve smooth movement"?
Sorry for the bunch of questions!
Nicos
Interpretation of README outputs and general questions
-
Nicos Haralabidis
- Posts: 199
- Joined: Tue Aug 16, 2016 1:46 am
-
Ross Miller
- Posts: 375
- Joined: Tue Sep 22, 2009 2:02 pm
Re: Interpretation of README outputs and general questions
I just started using AddBiomechanics (it's awesome, thanks!) and have some questions similar to Nicos above:
1. Is it expected that markers tagged with <fixed>true</fixed> will be adjusted a bit?
2. If I upload a C3D file that includes both markers and GRF, how does AddBiomechanics figure out the force assignments? By "force assignments" I mean, for example, which forces are applied to which foot in walking?
3. I'm also confused on what the GRF are used for, if they are specified. In some places on the website it reads like only IK is being done, but in other places it reads like something ID-ish is also being done, involving residual reduction.
Ross
1. Is it expected that markers tagged with <fixed>true</fixed> will be adjusted a bit?
2. If I upload a C3D file that includes both markers and GRF, how does AddBiomechanics figure out the force assignments? By "force assignments" I mean, for example, which forces are applied to which foot in walking?
3. I'm also confused on what the GRF are used for, if they are specified. In some places on the website it reads like only IK is being done, but in other places it reads like something ID-ish is also being done, involving residual reduction.
Ross
-
Nicholas Bianco
- Posts: 1057
- Joined: Thu Oct 04, 2012 8:09 pm
Re: Interpretation of README outputs and general questions
Hi Nicos and Ross,
Thanks for the great questions and sorry for the delay, I just got added to the forum and catching up now. AddBiomechanics has changed a lot since you both posted, but it's worth addressing these questions based on how things currently stand.
Nicos:
1. The model "optimized_scale_and_markers.osim" is the model that gets produced after the scaling and inverse kinematics step, so it won't contain any changes to the model from inverse dynamics. However, it will contain updated mass properties using linearly scaled values based on the change in mass from the generic model to the subject.
2. Yes, that is expected. "Fixed" markers can still move, but movement is penalized heavily in the scaling+IK cost term. Tracking markers have the freedom to move much more, but are still regularized.
3. If you provide GRFs, then by default we run the inverse dynamics step which comes after the scaling+IK step. The main goal is to achieve dynamic consistency by reducing residuals, but the ID step won't drastically alter the kinematics, so it's possible to find a solution with non-zero residuals. There is an advanced option on the web interface to turn off the ID step if you wish to only run scaling+IK, if, for example, you don't want to separate the GRFs from the markers in a C3D file.
4. The max iterations was heuristically chosen as a good trade-off between performance and speed. We don't necessarily need this problem to "converge", we just need a good fit to the marker data. In fact, we choose the best solution across all iterations in the optimization, not just the final iteration.
5-8. In order for the AddBiomechanics algorithm to work properly, there is some baseline preprocessing that needs to be done to ensure that the marker trajectories in the optimization are smooth and continuous. If a marker is "dropped", it means it violates some of the heuristics we have in place that would prevent the problem from obtaining a good fit to the data. Markers above a large acceleration threshold (i.e., markers acceleration faster than a MLB baseball pitcher's hand), will get dropped. Markers that "flicker" between their trajectory and the lab origin due to occlusion will get dropped. Markers that swap trajectories temporarily with another marker due to bad filtering or incorrect labeling will be relabeled to the correct trajectory or will be dropped. It's not perfect, but we do as much as we can to make your data work in AddBiomechanics without fundamentally altering it. The best way to avoid these kind of errors is to thoroughly check that your marker data is totally smooth and consistent (which, I know, is easier said than done). Hopefully some more comprehensive marker labeling or preprocessing tools will be available soon.
A note about errors: we have made lots of updates to the front end to make warnings more clear and print out error messages when things fail. Hopefully these updates give you more useful information to debug issues rather than just receiving an uninformative "Error" notification. We are currently working on ways to make the warning/error information even more clear.
Ross:
1. Yes, see the answer to Nico's question #2.
2. AddBiomechanics uses the force plate geometry in the C3D file, the location of the feet (obtained after scaling+IK), and center-of-pressure trajectories to heuristically identify which forces belong to which feet in the data set. If you upload a MOT file with GRFs (i.e., no force plate geometry), we can still use the feet locations and COPs to match the force columns to the data. We went through several iterations of the heuristics to get consistent performance, and it's working much better now. But of course, if it's not working well for your data, please let us know here on the forum. Perhaps we could have an option that uses header information to match GRFs to feet, if, for example, you provide the name of the foot bodies in the header data.
3. See the answer to Nico's question #3. For more details on how the inverse dynamics step works to address dynamic inconsistencies, it is best to refer to the current version of the manuscript preprint: https://www.biorxiv.org/content/10.1101 ... 5.545116v1.
Hope this is helpful to you guys and anyone else reading! We'll be keeping a closer eye on the forum now, so please send your questions here.
Best,
Nick
Thanks for the great questions and sorry for the delay, I just got added to the forum and catching up now. AddBiomechanics has changed a lot since you both posted, but it's worth addressing these questions based on how things currently stand.
Nicos:
1. The model "optimized_scale_and_markers.osim" is the model that gets produced after the scaling and inverse kinematics step, so it won't contain any changes to the model from inverse dynamics. However, it will contain updated mass properties using linearly scaled values based on the change in mass from the generic model to the subject.
2. Yes, that is expected. "Fixed" markers can still move, but movement is penalized heavily in the scaling+IK cost term. Tracking markers have the freedom to move much more, but are still regularized.
3. If you provide GRFs, then by default we run the inverse dynamics step which comes after the scaling+IK step. The main goal is to achieve dynamic consistency by reducing residuals, but the ID step won't drastically alter the kinematics, so it's possible to find a solution with non-zero residuals. There is an advanced option on the web interface to turn off the ID step if you wish to only run scaling+IK, if, for example, you don't want to separate the GRFs from the markers in a C3D file.
4. The max iterations was heuristically chosen as a good trade-off between performance and speed. We don't necessarily need this problem to "converge", we just need a good fit to the marker data. In fact, we choose the best solution across all iterations in the optimization, not just the final iteration.
5-8. In order for the AddBiomechanics algorithm to work properly, there is some baseline preprocessing that needs to be done to ensure that the marker trajectories in the optimization are smooth and continuous. If a marker is "dropped", it means it violates some of the heuristics we have in place that would prevent the problem from obtaining a good fit to the data. Markers above a large acceleration threshold (i.e., markers acceleration faster than a MLB baseball pitcher's hand), will get dropped. Markers that "flicker" between their trajectory and the lab origin due to occlusion will get dropped. Markers that swap trajectories temporarily with another marker due to bad filtering or incorrect labeling will be relabeled to the correct trajectory or will be dropped. It's not perfect, but we do as much as we can to make your data work in AddBiomechanics without fundamentally altering it. The best way to avoid these kind of errors is to thoroughly check that your marker data is totally smooth and consistent (which, I know, is easier said than done). Hopefully some more comprehensive marker labeling or preprocessing tools will be available soon.
A note about errors: we have made lots of updates to the front end to make warnings more clear and print out error messages when things fail. Hopefully these updates give you more useful information to debug issues rather than just receiving an uninformative "Error" notification. We are currently working on ways to make the warning/error information even more clear.
Ross:
1. Yes, see the answer to Nico's question #2.
2. AddBiomechanics uses the force plate geometry in the C3D file, the location of the feet (obtained after scaling+IK), and center-of-pressure trajectories to heuristically identify which forces belong to which feet in the data set. If you upload a MOT file with GRFs (i.e., no force plate geometry), we can still use the feet locations and COPs to match the force columns to the data. We went through several iterations of the heuristics to get consistent performance, and it's working much better now. But of course, if it's not working well for your data, please let us know here on the forum. Perhaps we could have an option that uses header information to match GRFs to feet, if, for example, you provide the name of the foot bodies in the header data.
3. See the answer to Nico's question #3. For more details on how the inverse dynamics step works to address dynamic inconsistencies, it is best to refer to the current version of the manuscript preprint: https://www.biorxiv.org/content/10.1101 ... 5.545116v1.
Hope this is helpful to you guys and anyone else reading! We'll be keeping a closer eye on the forum now, so please send your questions here.
Best,
Nick