Hi fellow modelers,
A little bug spotted in inverse dynamics.
If "lowpass_cutoff_frequency_for_coordinates" is set in .xml, all values to be output get filtered, including time.
As a result, if the input IK time interval is uneven due to indivisible reciprocal of frequency, e.g. 1/60s or 1/150s, the filtered time interval will not be the same as the original IK time interval.
For example, the template motion data in Gait2392 starts and ends in 0.5s and 2.5s, and with a 60-Hz frequency, the data have a cyclic interval of 0.17-0.16-0.17s. Accordingly, this series of time gets filtered and the ID result begins with 0.492s and ends in 2.492s with a consistent interval of 0.16s. I've attached the .xml if you want to reproduce.
If you want, I can create an issue for opensim-core on GitHub.
[BUG] time gets filtered in ID
- Marlies Nitschke
- Posts: 6
- Joined: Tue May 16, 2017 5:43 am
Re: [BUG] time gets filtered in ID
Hi,
I also encountered that the ID result (.sto) has different time stamps compared to the IK result (.mot). I always thought that this might occur from the different sampling frequencies in the kinematics and forces. Thanks for looking deeper into it and finding out that it comes from the filtering!
I am wondering
1. whether the time stamps in the ID result file are simply wrong and the result was computed at the correct (IK) time points or
2. whether the ID was computed at the new time points
Depending on this, there are two ways to temporally overcome this issue (at least partly):
1. ignore the time stamps in the ID result and use the ones from the IK
2. resample (interpolate) the ID result to the time points of the IK
I am currently resampling the ID result. Nevertheless, I would be happy if the origin of the problem could be solved properly.
Best regards,
Marlies
I also encountered that the ID result (.sto) has different time stamps compared to the IK result (.mot). I always thought that this might occur from the different sampling frequencies in the kinematics and forces. Thanks for looking deeper into it and finding out that it comes from the filtering!
I am wondering
1. whether the time stamps in the ID result file are simply wrong and the result was computed at the correct (IK) time points or
2. whether the ID was computed at the new time points
Depending on this, there are two ways to temporally overcome this issue (at least partly):
1. ignore the time stamps in the ID result and use the ones from the IK
2. resample (interpolate) the ID result to the time points of the IK
I am currently resampling the ID result. Nevertheless, I would be happy if the origin of the problem could be solved properly.
Best regards,
Marlies
Re: [BUG] time gets filtered in ID
Hi Marlies,
Glad to know I brought up something useful, and I think I have the answer to your question.
1. It is impossible to calculate dynamics when motion has not yet taken place. As mentioned in the post, using the template IK data in Gait2392 beginning at 0.5s, the ID result starts at 0.492s, when there is no IK data for calculation.
2. If you try to filter the time stamp in Gait2392 template data with a 4th-order 6Hz Butterworth filter, you get exactly the same results (rounded to 3 digits) as you would from ID.
Glad to know I brought up something useful, and I think I have the answer to your question.
It is the time stamp that is wrong, because:marliesn wrote: ↑Wed Nov 10, 2021 3:07 amI also encountered that the ID result (.sto) has different time stamps compared to the IK result (.mot). I always thought that this might occur from the different sampling frequencies in the kinematics and forces. Thanks for looking deeper into it and finding out that it comes from the filtering!
1. It is impossible to calculate dynamics when motion has not yet taken place. As mentioned in the post, using the template IK data in Gait2392 beginning at 0.5s, the ID result starts at 0.492s, when there is no IK data for calculation.
2. If you try to filter the time stamp in Gait2392 template data with a 4th-order 6Hz Butterworth filter, you get exactly the same results (rounded to 3 digits) as you would from ID.
Therefore, one solution would be your suggestion No.1. However, it is better to simply set "lowpass_cutoff_frequency_for_coordinates" in your .xml file to -1 (no filter in ID), and filter the results by yourself after ID; only this time, remember not to filter the first column.
For the same reason, this would give you the wrong result (although only by a shift of a few milliseconds). Also, there's at least one instant of data you won't be able to get this way. Again with the Gait2392 data as an example, its ID results ends at 2.492s, whereas IK ends at 2.5s, there's no ID data after 2.5s so you cannot interpolate.
- Marlies Nitschke
- Posts: 6
- Joined: Tue May 16, 2017 5:43 am
Re: [BUG] time gets filtered in ID
Hi Ziyu,
I totally agree with your arguments on why it has to be the time stamp being wrong.
However, I do not fully agree with your solution method to filter after the ID. There are two main reasons for that:
1. Filtering with IIR filters will always introduce some edge effects. Hence, I recommend processing more than just the motion you are interested in by keeping additional samples at the beginning and end. You can then afterwards extract the motion you are interested in. This recommendation is independent of the bug you reported here.
2. I recommend filtering kinematics and kinetics with the same filter (type of filter and cutoff frequency) before performing ID (1, 2). The OpenSim ID tool is only filtering the kinematics.
(1) Van den Bogert, A. J. and de Koning, J. On optimal filtering for inverse dynamics analysis. In Proceedings of the IXth Biennial Conference of the Canadian Society for Biomechanics., 214-215 (Vancouver, British Columbia, 1996). https://isbweb.org/data/invdyn/csb96.pdf
(2) Derrick, T. R., van den Bogert, A. J., Cereatti, A., Dumas, R., Fantozzi, S., and Leardini, A. (2020). ISB recommendations on the reporting of intersegmental forces and moments during human motion analysis. Journal of Biomechanics, 99, 109533. https://doi.org/10.1016/j.jbiomech.2019.109533
I totally agree with your arguments on why it has to be the time stamp being wrong.
However, I do not fully agree with your solution method to filter after the ID. There are two main reasons for that:
1. Filtering with IIR filters will always introduce some edge effects. Hence, I recommend processing more than just the motion you are interested in by keeping additional samples at the beginning and end. You can then afterwards extract the motion you are interested in. This recommendation is independent of the bug you reported here.
2. I recommend filtering kinematics and kinetics with the same filter (type of filter and cutoff frequency) before performing ID (1, 2). The OpenSim ID tool is only filtering the kinematics.
(1) Van den Bogert, A. J. and de Koning, J. On optimal filtering for inverse dynamics analysis. In Proceedings of the IXth Biennial Conference of the Canadian Society for Biomechanics., 214-215 (Vancouver, British Columbia, 1996). https://isbweb.org/data/invdyn/csb96.pdf
(2) Derrick, T. R., van den Bogert, A. J., Cereatti, A., Dumas, R., Fantozzi, S., and Leardini, A. (2020). ISB recommendations on the reporting of intersegmental forces and moments during human motion analysis. Journal of Biomechanics, 99, 109533. https://doi.org/10.1016/j.jbiomech.2019.109533
Re: [BUG] time gets filtered in ID
Hi Marlies,
Thank you for the reply and you are partially right. I overlooked the fact that, as the name suggests, "lowpass_cutoff_frequency_for_coordinates" filters the IK result before calculation, not the ID result generate afterwards. When set to -1, OpenSim ID tool is calculating joint moments with kinematics unfiltered, whereas we only want the time unfiltered.
Therefore, I must retract my opinion in the previous comment of "one solution would be your suggestion No.1", as OpenSim is actually calculating ID with IK in the wrong time stamp so replacing the time stamp in ID is not enough. However, I still don't think your suggestion 2 of resampling ID result is correct. Again with Gait2392 template data as an example, the filtered IK starts with 0.492s, and I'm not sure if OpenSim calculate ID with GRFs extracted from 0.492s or from 0.5s (as suggested by the original IK); this needs to be confirmed by looking through the code.
You might think this can be checked by deleting the kinetic data before 0.5s and see if simulation still runs. Well, I did a little test by removing all data before 2.5s, and strangely OpenSim still yields ID result! So I guess the missing GRFs is filled in with zeros, and at this stage, you simply shouldn't trust the ID result if lowpass_cutoff_frequency_for_coordinates changes your time stamp.
As for filtering kinetic data, I would like to take the chance and elaborate on it. In fact, I looked into this a while back, and yes, many studies support using same filter frequency for kinematics and GRFs, but the evidence are quite weak as results are mixed. In the second paper you recommended, Derrick et al. (2020) nicely summarized the conundrum we face dealing with ID:
One way to get reasonably-looking result is to calculate ID with the GRFs in a high frequency (15 Hz), and then filter the joint moment values with 6Hz afterwards; this is what Camargo did in his code to obtain the figures in his paper. I'm not sure why this happened, but it is one example of not choosing the same cut-off frequency. In fact, this high-prefilter + low-postfilter is a new way of signal processing in ID, and could be worthwhile of investigation.
Back to our original problem, I would go for pre-filtering IK myself and then feed it to ID with lowpass_cutoff_frequency_for_coordinates set to -1 (whether to prefilter the GRFs or postfilter the moments should be case-specific). This way you can be sure that the time stamp of kinematics and GRFs matches for OpenSim to calculate a reliable ID.
But the best solution is to have this time-filter problem directly solved in OpenSim I would've debugged it myself if I had the time to look through the code, but I will at least issue it in GitHub so they can fix in the next version.
[1] Camargo, J., Ramanathan, A., Flanagan, W., & Young, A. (2021). A comprehensive, open-source dataset of lower limb biomechanics in multiple conditions of stairs, ramps, and level-ground ambulation and transitions. Journal of Biomechanics, 119, 110320. https://doi.org/10.1016/j.jbiomech.2021.110320
Thank you for the reply and you are partially right. I overlooked the fact that, as the name suggests, "lowpass_cutoff_frequency_for_coordinates" filters the IK result before calculation, not the ID result generate afterwards. When set to -1, OpenSim ID tool is calculating joint moments with kinematics unfiltered, whereas we only want the time unfiltered.
Therefore, I must retract my opinion in the previous comment of "one solution would be your suggestion No.1", as OpenSim is actually calculating ID with IK in the wrong time stamp so replacing the time stamp in ID is not enough. However, I still don't think your suggestion 2 of resampling ID result is correct. Again with Gait2392 template data as an example, the filtered IK starts with 0.492s, and I'm not sure if OpenSim calculate ID with GRFs extracted from 0.492s or from 0.5s (as suggested by the original IK); this needs to be confirmed by looking through the code.
You might think this can be checked by deleting the kinetic data before 0.5s and see if simulation still runs. Well, I did a little test by removing all data before 2.5s, and strangely OpenSim still yields ID result! So I guess the missing GRFs is filled in with zeros, and at this stage, you simply shouldn't trust the ID result if lowpass_cutoff_frequency_for_coordinates changes your time stamp.
As for filtering kinetic data, I would like to take the chance and elaborate on it. In fact, I looked into this a while back, and yes, many studies support using same filter frequency for kinematics and GRFs, but the evidence are quite weak as results are mixed. In the second paper you recommended, Derrick et al. (2020) nicely summarized the conundrum we face dealing with ID:
Basically, the selection of cut-off frequency should be case-specifc, and in my own experience, the same frequency is a bad chocie. I got interested in this question using the dataset from Camargo et al. (2021) [1]. When I filter the GRFs before ID either with 6 Hz (same as kinematic filter) or 10 Hz (commonly used value), I get an unrealistically high dorsiflexion moment in the beginning of a gait cycle; 6 Hz yields much worse result than 10 Hz.Several researchers have shown that a disparity in the frequency content can cause artifacts in the intersegmental moments that cannot be explained by the dynamics of the activity. This necessitates the same cutoff frequencies for kinetic and kinematic data filtering. However, this
poses a problem with impact forces that can be attenuated by low-pass cutoff frequencies that are in the range necessary to reduce noise in the kinematic data. Decisions concerning the cutoff frequency need to be made based on the purpose of the experiment and the variables being measured.
One way to get reasonably-looking result is to calculate ID with the GRFs in a high frequency (15 Hz), and then filter the joint moment values with 6Hz afterwards; this is what Camargo did in his code to obtain the figures in his paper. I'm not sure why this happened, but it is one example of not choosing the same cut-off frequency. In fact, this high-prefilter + low-postfilter is a new way of signal processing in ID, and could be worthwhile of investigation.
Back to our original problem, I would go for pre-filtering IK myself and then feed it to ID with lowpass_cutoff_frequency_for_coordinates set to -1 (whether to prefilter the GRFs or postfilter the moments should be case-specific). This way you can be sure that the time stamp of kinematics and GRFs matches for OpenSim to calculate a reliable ID.
But the best solution is to have this time-filter problem directly solved in OpenSim I would've debugged it myself if I had the time to look through the code, but I will at least issue it in GitHub so they can fix in the next version.
[1] Camargo, J., Ramanathan, A., Flanagan, W., & Young, A. (2021). A comprehensive, open-source dataset of lower limb biomechanics in multiple conditions of stairs, ramps, and level-ground ambulation and transitions. Journal of Biomechanics, 119, 110320. https://doi.org/10.1016/j.jbiomech.2021.110320
- Marlies Nitschke
- Posts: 6
- Joined: Tue May 16, 2017 5:43 am
Re: [BUG] time gets filtered in ID
Hi Ziyu,
I totally agree with you that none of the solutions are perfect.
I don't want to start here now a discussion about filtering, but did you try to use a residual analysis to determine the proper cut-off frequency for your data? And did you adapt the cut-off frequency to the fact that a dual pass filter is used? Winter's book is a great resource for both topics. And as I said previously, the edge effects of IIR filters should not be underestimated.
Best regards,
Marlies
I totally agree with you that none of the solutions are perfect.
I don't want to start here now a discussion about filtering, but did you try to use a residual analysis to determine the proper cut-off frequency for your data? And did you adapt the cut-off frequency to the fact that a dual pass filter is used? Winter's book is a great resource for both topics. And as I said previously, the edge effects of IIR filters should not be underestimated.
Best regards,
Marlies
Re: [BUG] time gets filtered in ID
Hi Marlies,
Thank you for the questions, and they are right on spot. I neglected that the dataset I work with already filters the data, hence naturally, applying an additional filter, whether 6 or 10 Hz, will lead to weird results. So I need to retest this theory of same kinematic-GRF filter frequency with my own data some day.
Since you've brought up Winter's book, there's one point I always find interesting. He noted that empirically for walking, a good filter frequency should be 6 times the stride frequency and 6 Hz is best for a normal walking cadence. Since gait analysis makes up a large part of biomechanics research, this value appears frequently in publications and, likely without researchers understanding the rationale, got inherited into other motions. As you mentioned, residual analysis is definitely the right way to go rather than picking some value from others.
With all that said, I agree with you, and people should really specify what they did in data filtering and why they did it.
Best,
Ziyu
Thank you for the questions, and they are right on spot. I neglected that the dataset I work with already filters the data, hence naturally, applying an additional filter, whether 6 or 10 Hz, will lead to weird results. So I need to retest this theory of same kinematic-GRF filter frequency with my own data some day.
Since you've brought up Winter's book, there's one point I always find interesting. He noted that empirically for walking, a good filter frequency should be 6 times the stride frequency and 6 Hz is best for a normal walking cadence. Since gait analysis makes up a large part of biomechanics research, this value appears frequently in publications and, likely without researchers understanding the rationale, got inherited into other motions. As you mentioned, residual analysis is definitely the right way to go rather than picking some value from others.
With all that said, I agree with you, and people should really specify what they did in data filtering and why they did it.
Best,
Ziyu