Problem with exporting force data from C3D

[Chiho Ng]

Hi everyone,

I have met a problem when exporting force data from C3D file, which is the force points are not corresponding with the ones generated from the origin file(here is the qtm file from Qualisys). I have tried three versions of OpenSim and the results are the same. Does anyone know the reason and have any idea about how to figure it out?

Thank you so much!

Chiho Ng

[John Davis]

Hi Chiho Ng,

I've had similar issues with C3D data from Qualisys. I'm not sure what the issue is for your screenshot of the "X" force, but I do know what the issue is in the screenshot on the right: OpenSim's C3D converter calculates center of pressure from the raw force data (I think that's the ground_force_px component you have highlighted; that'd be the X component of the center of pressure) for all frames of data, even though the center of pressure is undefined when the vertical ground reaction force is undefined. Because center of pressure calculations involve dividing by the vertical ground reaction force (Fy), when Fy is really small you get wild oscillations in the center of pressure, because Fy is oscillating around zero because of noise.

The right way to do it is to first filter the raw force data (Fx Fy Fz Mx My Mz components as recorded by the origin of the plate), then set a threshold for the vertical ground reaction force (maybe 20 N or something), below which you will set the force to be exactly zero in all components. At these points the CoP is undefined, and you can usually just set it to [0,0,0]. There is some good discussion on this issue at this GitHub issue.

A few technical points I've learned when grappling with getting Qualisys data into OpenSim:

Something worth pointing out is that it is not necessary to calculate CoP at all, and the best possible approach from a numerical stability perspective is to avoid doing so entirely (see Ton van den Bogert's comment here). You can just apply the Fx Fy Fz Mx My Mz components to the model, from the origin of the force plate. In practice I still find it more useful to transform the raw force components into Fx Fy Fz CoPx CoPy and Tz (free moment) components because then you can actually visualize them in the OpenSim GUI to make sure they line up with your experimental data. OpenSim's osimC3D matlab function is supposed to support this way of treating the ground reaction force through the ForceLocation parameter but I couldn't get it to work with my data.

To make sure the QTM data line up with what OpenSim is calculating, you can export the force plate data to a TSV file and compare them to your calculated .mot file. Just disable filtering before you do this, and the calculated CoP should line up exactly with what QTM calculates. Be careful with the "local" vs "global" coordinate export option if you have more than one force plate, or if you have a force plate whose origin is not the lab coordinate origin. Also be careful if the origin of the plate is not at ground level; this need to be taken into account during the CoP calculations. Young-Hoo Kwon's website is very useful for all of this.

Ajay Seth has said that sometimes setting the CoP to be [0,0,0] during the swing phase of gait can cause issues at initial contact and toe-off because of OpenSim's splining routine. He recommends a trick where the CoP location is linearly interpolated from the last valid force measurement from one step to the CoP location for the first valid force measurement for the next step. By "valid force measurement" here I just mean frames of data where Fy is above your threshold.

I ended up just avoiding C3D exports completely and wrote some custom MATLAB code to go from TSV files exported from QTM to opensim-compatible .mot files. I can share this code with you if you'd like but it's heavily customized for the preprocessing I'm doing, so it has intermediate steps for assigning footstrikes and combining data from multiple force plates. I think the best solution would be to use the functions in the ezc3d package to extract the raw analog data and preprocess it. What I have in MATLAB works, but is a bit hacky.

Hope this is helpful! Getting GRF data from Qualisys into OpenSim was one of the most challenging parts of moving my analysis to OpenSim.

[soroosh bagheri]

Hi
You can use c3dtools.com, this is an online free web application to export .mot & .trc from c3d files.
if you have any problems you can post them from the "issues" option on the c3dtools.com

best regards
Soroosh

[Chiho Ng]

Hi John,

Thank you so much for your reply!!! It really helps!

I have set all the force points whose corresponding force values are lower than the specific value, and I got the force point curves that were nearly the same as that plotted from the values of TSV files exported by QTM. However, I found another problem, which is not the issue of OpenSim, which is the COPs calculated from the C3D file are not equal to that of TSV files. The values of differenr axis have an offset respectively. But this is wired as they are both exported from the same qtm document.

Have you ever met this problem? Thank you so much and I really appreciate your reply. It is really helpful to me!

[Chiho Ng]

Hi soroosh,

Thank you for your reply! This tool would be helpful!

However I want to integrate this conversion into my program, so I would like to figure out what the problems are when I using this function. Whatsoever, during the massive data processing, your tool is really helpful! Thank you for your sharing!

[John Davis]

A few things on the CoP coordinates:

First, if the CoP values are flipped for different axes make sure you check how your lab coordinate system related to the coordinate system orientation in OpenSim (Y axis points up, also compare which direction is "forward" according to the force plate).

Second, if you find that the CoP values have an offset (i.e. they are the same as in QTM, but just off by some constant amount) I'd check the TSV export setting in QTM: you can either export them in "local coordinates" which gives you the CoP relative to the origin of the force plane, or "global coordinates" which gives you the CoP relative to the lab coordinate system. This could be causing an offset in the CoP.

Third, the location of the CoP is influenced by where the origin of your force plate is located (and how it is oriented). Check the technical specification sheet or the user manual for your force plate to see where the origin is located relative to the force plate corners, and whether the origin is "under" the plate (if I recall correctly some plates have an origin that is not level with the top surface of the plate, but is "buried" inside it a bit). Force treadmills sometimes have a vertical offset you need to account for.

A TSV export of force plate data from QTM should also have these parameters listed in the header. They have names like "FORCE_PLATE_CORNER_POSX_POSY_X" and "FORCE_PLATE_OFFSET_X" for the location of the corners of the plate, and the location of the plate's origin.

One final thing to watch out for is that (at least for the two setups I've worked with) QTM exports ground action forces, not ground reaction forces, so if you don't account for that you might get unexpected sign flips in the location of your CoP data.

Let me know if you can't figure it out; I remember having some CoP offset issues for a while too and I have a whole bunch of notes on CoP calculations from QTM force plate parameters that I can dig out.

[Chiho Ng]

Hi John,

Thank you so much again for your answer!!!

I think I have figured out the problem! And thanks to your help, I have some deeper undenstanding about force plate, which are ignored by me brfore. Your help is really admirable!

Sincerely
Chiho Ng