Kistler COP correction

[mrrezaie]

Hi,

Does ezc3d take into account the COP correction for Kistler force platforms? It can be found in FPCOPPOLY in FORCE_PLATFORM metadata.

Thank you

[pariterre]

I have not implemented anything specific yet for Kistler force platform. What are the nature of these corrections?

[mrrezaie]

Thanks for your response. As far as I know:

[definition]
https://www.c3d.org/docs/C3D_User_Guide_2008.pdf
FORCE_PLATFORM:FPCOPPOLY which contains a 2x6 matrix containing polynomial
correction factors for the center of pressure data.

In Kistler type, the matrix is specifically defined by the company for each force plate model and even serial number.

https://nbviewer.org/github/BMClab/BMC/blob/master/notebooks/KistlerForcePlateCalculation.ipynb

# Type 9281E11
        Px = [2.51997E-15, -2.18826E-10, -2.69254E-07, -4.85912E-11, 4.55731E-6, -4.18892E-2]
        Py = [2.83750E-15, -1.00051E-10, -2.05349E-06, -1.16374E-10, 4.71553E-6, 6.89265E-2]
# Type 9281E and 9281EA (SN: <= 616901)
        Px = [1.1604E-14, -8.39091E-10, -1.44293E-6, -2.85927E-10, 2.05575E-5, -0.113525]
        Py = [1.27251E-14, -3.13238E-10, -3.33888E-6, -6.49641E-10, 1.53937E-5, 1.12624E-1]
# Type 9281E and 9281EA (SN: >= 616902)
        Px = [7.92063E-15, -5.821E-10, -2.77102E-6, -1.76083E-10, 1.29695E-5, -0.0413979]
        Py = [8.82869E-15, -2.48554E-10, -1.76282E-6, -4.22186E-10, 1.2091E-5, 5.16279E-2]
# Type 9287C, 9287CA
        Px = [1.72454E-16, -4.82275E-11, 3.30016E-7, -9.46569E-12, 2.78736E-6, -8.20399E-3]
        Py = [2.20428E-16, -1.80864E-11, -7.30249E-7, -3.03080E-11, 2.64974E-6, 5.41166E-2]

Dax = (Px[0]*ay**4 + Px[1]*ay**2 + Px[2])*ax**3 + (Px[3]*ay**4 + Px[4]*ay**2 + Px[5])*ax
ax = ax - Dax

Day = (Py[0]*ax**4 + Py[1]*ax**2 + Py[2])*ay**3 + (Py[3]*ax**4 + Py[4]*ax**2 + Py[5])*ay
ay = ay - Day

[pariterre]

I see, that should not be too hard to implement.
Do you have a C3D kistler file that I could test on? :)

[mrrezaie]

Hope this helps:
test.zip

[pariterre]

Dear @mrrezaie

I know it's been a REAAAALLY long while since that issue was opened, my appologies! Still I had a look at what you asked. I implemented it but honestly I have concerns (so I haven't merged yet, see issue #297 ).

First

In the documentation you provided (and copied):

Dax = (Px[0]*ay**4 + Px[1]*ay**2 + Px[2])*ax**3 + (Px[3]*ay**4 + Px[4]*ay**2 + Px[5])*ax
ax = ax - Dax

Day = (Py[0]*ax**4 + Py[1]*ax**2 + Py[2])*ay**3 + (Py[3]*ax**4 + Py[4]*ax**2 + Py[5])*ay
ay = ay - Day

surprinsingly ax is updated BEFORE computing Day, while being used while computing it. I would personnally have expected that the offset would have been computed and only THEN subtracted. I could not find a way too validate this equation though. Which leads me to my second concern.

Second

In the 2008 c3d documentation you provided, the parameter FORCE_PLATFORM:FPCOPPOLY is indeed reported. However, it is no longer the case in more recent version of the c3d documentation.
What made me raised eyebrows is that when updating the tests for the Kistler force platform, I found myself having this result for the free moment (Tz):

Tz => [-26.062938932447089), -391.8241595747582), -0.33922107657657574]

The reason I have three values for the free moment is so I can validate if I have not made any mistake. It is expected the x and y being 0 (or very near), while they are currently very not. However, before applying th FPCOPPOLY values, I was getting:

Tz => [-0.001218477848857239, -0.0013630671086886962, 0.87114378914262325]

which was much closer to the expected values for x and y.

My question is, since the parameter was removed from the C3D standard and that introducing this value seems to introduce error, could that be that is it no longer needed to apply these values as they would be computed before creating the C3D by the software the exported the file?

Thanks, and sorry again for my much waited answer!

[mrrezaie]

Hi, thank you so much for sparing your time on this. I'm hardly an expert, but as you said, the implementation and perhaps the equations are not correct. I will try to find other references for you.

My question is, since the parameter was removed from the C3D standard and that introducing this value seems to introduce error, could that be that is it no longer needed to apply these values as they would be computed before creating the C3D by the software the exported the file?

I'm not sure this parameter has been obsolete, since the C3D files exported by my 2023 QTM still include it. The point is that, if I disable COP correction, QTM doesn't export it. The differences sometime reach to ~10mm (or more). Do you think it is worth it?

[pariterre]

Hi!
10 mm is a lot!

I suggest that if you have access to an actual force platform, that you use some kind of very dense but small (in size) weigt with a reflective marker on it (exactly over the center of mass) and you compare the position of the weight with the projected one from the marker. Like this we have some kind of benchmark to choose from...

[mrrezaie]

Hi, I asked Qualisys and they kindly send me this equation:

So, the former equations are correct (except the initial ax update before calculating ay offset).

I also calculated the corrected COP as well as the free moment (only Tz) manually and they matched the Qualisys corrected values. Also, the differences between corrected and raw Tz are not too big. Could you please compare the free moment for the entire trial?

[pariterre]

Hi there!
Based on your last comment, I pushed a modified version of the code. If you are able to compile ezc3d for yourself, I would appreciate that you double check this new version (on the pariterre fork).

If you are installing via conda, I can push the new version now (before validating)

[mrrezaie]

Sorry, I don't know how to build it. Since this post, I have switched to OpenSim C3DFileAdapter due to interference in the libraries. I can compare the corrected and uncorrected C3D files by installing the Conda package (win). But maybe you can use a specific version just for testing, something like 0.0.0. In this case, it won't be installed as the latest version for other users, I think.

[pariterre]

I am pretty confident with the implementation. I accepted the PR and I will push it to conda as 1.5.5 today :)

[pariterre]

Hi @mrrezaie
Did you by any chance validated the results?

[mrrezaie]

Hi @pariterre

When I uncheck the FPCOPPOLY parameter in QTM (Qualisys) and re-save the c3d file, this error rises. Perhaps any sign/footprint of this parameter, which was added earlier, still exists somewhere:
test3_noFPCOPPOLY.zip

>>>import ezc3d
>>>print(ezc3d.__version__)
>>>ezc3d.c3d('test3_noFPCOPPOLY.c3d', extract_forceplat_data=True)

1.5.7
ValueError: Group::parameterIdx could not find FPCOPPOLY in the group FORCE_PLATFORM

So, I could compare the outputs of QTM and ezc3d v1.5.7 by setting the FPCOPPOLY parameters to zero and now they exactly match. I'm hardly an expert, but I think this is valid.
Contact frames:

However, when FPCOPPOLY is taken into account, the noises in non contact frames are amplified drastically.
All frames:

Thanks for your time and effort!!!

[pariterre]

Alrighty! Seems good then

Just to make sure by "unchecking" you mean that it is an option in the Qualisys software to have or not the FPCOPPOLY in the baked in the C3D file, meaning that if it is unchecked, then it won't be in the file. So I should add one last fix where if tihs "FPCOPPOLY" is not found, then I should set the value to 0?

[mrrezaie]

it is an option in the Qualisys software to have or not the FPCOPPOLY in the baked in the C3D file, meaning that if it is unchecked, then it won't be in the file.

Yes, this is a screenshot of this part in QTM:

So I should add one last fix where if tihs "FPCOPPOLY" is not found, then I should set the value to 0?

Perhaps it's better to use an if condition or try-catch expression instead of setting zero to this parameter; simply ignore this parameter if it rises error. As I said earlier, I'm not an eligible person in this regard 😄

Thank you.

[pariterre]

Complete in #311
Thanks for your help!