Non-planar moving force plates in C3D

[Ben van Basten]

Hello!

I'm investigating how to store moving, non-planar, force plates in C3D (in particular type 2 and type 4).

I am aware that the corners of the plate can be stored, in lab coordinate space, in the FORCE_PLATFORM/CORNERS section. However, this is a static parameter. I could also add additional analog channels to encode the force platform transformation over time, but this might be non-standard.

I am not sure, but I think one could transform the local forces and moments such that they will be correct for muscoloskeletal analysis. (any confirmation would be appreciated)

Yet another big problem would be that any visualization will be incorrect as the CoP/point of application cannot be derived without knowing the position and orientation of the force plate. CoP is generally also not stored in type-2 and type-4 force plate C3Ds.

So, is there a way to store these non-planar moving plates in C3D, that (if exists) conforms to some standardization? Or do we need to add a new force plate type?

Regards,

Ben van Basten
Motek

[Wagner De Godoy]

Re: Non-planar moving force plates in C3D

Dear Dr. van Basten,

Maybe my suggestion is simple-minded - I have not found the information on the force plates type 2 and 4 mentioned in your message.
For an AMTI force plate a calculation option could be to attach a rigid cluster with reflective markers to the froce plate to create a local coordinate system (FP-LCS) to store the 3d coordinates of the platform corners. Subsequently, for each capture frame, the coordinates of the platform corners would be transformed between FP-LCS and the laboratory (global) coordinate system (GCS) in the FORCE_PLATFORM/CORNERS section. I think forces, moments and CoP would be adjusted to the patient for kinetic calculations.
I hope this information, if correct, can contribute to your research.
Best Regards,

[Ben van Basten]

Re: Non-planar moving force plates in C3D

Dear Mr. de Godoy,

Thank you for your input on the transformation! We have the mathematics already available in our software. We don't need additional markers as the force plate is mounted in a 2-DoF treadmill, which reports its DoF values (inclination, lateral sway).

The question we have is whether there is a standard way of storing non-planar, moving (mounted in 2-DoF treadmill) force plates in C3D so this data can be used in external packages such as AnyBody and Visual3D.


Regards,

Ben

[Edmund Cramp]

Re: Non-planar moving force plates in C3D

I would suggest discussing this with C-Motion, they have implemented a number of different force plates in C3D over many years.

I think that Wagner De Godoy's suggestion is a good one - C3D was designed to describe the the location of the force plate within the 3D co-ordinate system so the force data is recorded in synchronization with the 3D data in both time and space. So if you are potentially moving the force plate from frame to frame throughout the data collection, all that is needed is to know the location of the force plate in each frame. I think that measuring the location would be more accurate that having to translate the reported DoF into the 3D co-ordinate system - an accurate calculation needs to know where the force plate is, not where it thinks it is.

If you have four markers on the plate corners, identified as FP1C1, FP1C2, FP1C3, FP1C4 then you could create a parameter array FORCE_PLATFORM:POINTS_LABELS[FP#,4] to store the corner marker POINT:LABELS and I think that you would have all the information needed to create a new C3D plate type that precisely relocates the force plate in each frame.

[Ben van Basten]

Re: Non-planar moving force plates in C3D

Thanks Edmund,

Storing the corner marker names might be a good idea! I hope this is easily done in BTK, the library that we use for C3D reading.

I am currently in contact with C-Motion to discuss a small extension to the format to deal with this issue. PM me if you want to be involved in this discussion.

Ben

[Allan Carman]

Re: Non-planar moving force plates in C3D

Ben

I would like to see an additional force plate type. It would have six channels consisting of global force vectors and the global centre of pressure data expressed in the global axes system and in the global units. Two main reasons:

It gives a way of including devices other that plates such as weights carried or forces on a pulley/cable system or other unusual situations of external forces. It would be treated like a force plate but has no C3D origin, corner or calibration parameters. The forces could be constant or measured (load cell) and point of application and force direction defined from 3D markers or virtual 3D points relative to segment locations or external objects.

It gives an alternative and simplified way of transferring force plate data between 3^rd party software. The 3D motion capture system collects voltage data and applies calibration information and coordinate transforms to arrive at the forces and centre of pressure in the global axes system in the correct units. This data could be exported in C3D as the plate type mentioned, instead of the raw channel data. It removes the problematic nature and sometimes confusion and errors in having to interpret the plate type, origin data, corners, units of measurement. To visualize the force plate the corner information can still be included in the C3D file. I am particularly thinking of reading into or transferring between 3^rd partly software where raw data and all the force plate detail is not required. The option of exporting individual channel data and complete forceplate calibration data is still there if required.

Cheers
Allan

[Ben van Basten]

Re: Non-planar moving force plates in C3D

Thanks Allan,

Indeed, load cells and other force sensors should also be taken into account in this new type.

I'm currently discussing several options with C-Motion (Scott Selbie) and Edmund. One suggestion is to add a ROTATION channel that contains a 4x4 transformation matrix indicating the position and orientation of the force measurement device for each frame. These ROTATION channels are currently already used in various projects. Next to this, all we need to change to the format is to add one new parameter to the FORCE_PLATFORM group that specifies the name of this ROTATION signal.

I'm not sure, but I think this would be sufficient for both moving non-planar plates and other types of load cells. Local forces, moments (and CoP) can than be derived like we always do, with the addition of a final transformation of putting them in lab space using the rotation signal. The nice thing of this approach is that we can properly visualize the moving plates, as we know their movement.

I also like your suggestion. Storing global forces, moments and cop might eliminate the nuisance of retrieving the correct global forces etc from various plate types with their origins, corners and scaling. Would there be any drawbacks to this approach?

[Edmund Cramp]

Re: Non-planar moving force plates in C3D

Would there be any drawbacks to this approach?

There are two areas where the C3D format works really well, synchronization and locations. Sampling a load cell with an ADC connected to a motion capture system generally guarantees that the data will be synchronized with every other sensor, or 3D data, collected. But without a known location for the load cell data in the collected 3D volume you can't know where it is relative to the 3D data. You have a force vector but it's location in the 3D space is uncertain and clearly variable. If the load cell or force plate is moving, then the only way to be certain of where it is in time and space is going to be to stick some markers on it.

Certainly you could record a device generated ROTATION signal that would document the signal vector, but you still have the problem of knowing where it is in the calibrated 3D space, and there is the issue of synchronization to know the specific rotation at the instant that every collected 3D frame (or any other analog signal) is recorded. Synchronization of analog samples is generally easy to verify and detect any latency in each signal, but when signals arrive via multiple methods, involving multiple sampling and re-sampling rates, then signal latency can easily sneak in undetected.

I'm not saying that the ROTATION idea will not work, but I suspect that it will be complex and much more difficult to implement than simply adding a couple of markers to define the source location frame by frame.

[Allan Carman]

Re: Non-planar moving force plates in C3D

In the 3D data collection process it is basically adding 3D markers or virtual segment locations to give frame by frame force origin and direction. The force transducer gives magnitude. Calculating global force vectors and force origins (or CoP) is relatively straight forward compared to force plates. I have done this previously with a body-support harness (load cell in the cable above participant, markers and virtual 3D points) to calculate kinetics of unweighting the trunk. Although I developed my own 3D analysis software to do this, it would be the 3D collection software where the analogue force data and respective markers would be defined as well as the method for calculating the global force vectors and origin (CoP). The C3D software then gives a tool for exporting and sharing this frame by frame force vector and origin data. Which would also be used as a simpler way of transferring force plate data without the need to recalculate the global force vectors and CoP from local force plate channel data.

The limitation in using 3D markers is the higher sampling frequency of analogue data compared to the 3D frame rate. To get the force vector and origin data for each analogue sample would require interpolating the 3D data.

On the moving force plate. This might not be as simple as placing four markers on the corners of the plate to define a moving frame by frame plate local axes. Then calculating local plate forces and CoP and then transforming these to the global 3D axes. The raw channels of your plate are going to be influenced by plate orientation relative to gravity, changing channel zeros, and the calculation of forces, moments and CoP. At first thought I don’t think it is going to be as easy as a straight transformation of calculated local forces and CoP as in a fixed force plate.

Cheers
Allan

[Ben van Basten]

Re: Non-planar moving force plates in C3D

On the moving force plate. This might not be as simple as placing four markers on the corners of the plate to define a moving frame by frame plate local axes. Then calculating local plate forces and CoP and then transforming these to the global 3D axes. The raw channels of your plate are going to be influenced by plate orientation relative to gravity, changing channel zeros, and the calculation of forces, moments and CoP. At first thought I don’t think it is going to be as easy as a straight transformation of calculated local forces and CoP as in a fixed force plate.

Yes, in case of moving or tilted plates, gravity and inertia compensation needs to be performed.

[Ben van Basten]

Re: Non-planar moving force plates in C3D

Certainly you could record a device generated ROTATION signal that would document the signal vector, but you still have the problem of knowing where it is in the calibrated 3D space [...]

To my knowledge, the ROTATION signal is a 4x4 transformation matrix that would allow us to transform the local forces to lab/3D space. Why wouldn't this be possible?

In an ideal world, I think the recording/acquisition software should take care of adding a synchronized ROTATION signal describing the trajectory of the force plates. Whether this information comes from motor feedback of an actuated treadmill, derived from >4 markers or other instrumentation (IMU, goniometer) should be abstracted, as it is not important to the subsequent user of this C3D. This gives some flexibility that optical mocap might not be required.

I'm not saying that the ROTATION idea will not work, but I suspect that it will be complex and much more difficult to implement than simply adding a couple of markers to define the source location frame by frame.

[Ton van den Bogert]

Re: Non-planar moving force plates in C3D

Yes, in case of moving or tilted plates, gravity and inertia compensation needs to be performed.

Below is a reference [1] for how to do that.

I have no experience with C3D, but have processed data from various labs and registration of force plate and mocap coordinate systems is always an important issue. You need to know the transformation (translation \((\mathbf{r})\) and rotation \((\mathbf{R})\)) from the force plate (local) coordinate system to the mocap coordinate system (global). The force and moment data from the force plate then transform as follows (note Biomch-L can now do Latex equations):

\(\mathbf{F}_{global} = \mathbf{R}\mathbf{F}_{local}\)

\(\mathbf{M}_{global} = \mathbf{R}\mathbf{M}_{local} + \mathbf{r}\times\mathbf{F}_{global}\)

If the force plate is stationary, and integrated with a mocap system, the vendor usually does this for you before exporting the data, using a registration device during calibration. Cortex (Motion Analysis Corp.) does that.

If the force plate is not stationary, they could use markers to do a time varying registration, and do the transformations for you. However, it makes sense not to do that unless they also take care of the inertia/gravity compensation otherwise the data would not be useful anyway.

I agree that it would make sense to extend the C3D standard with channels for (\mathbf{r}(t))and (\mathbf{R}(t)), or channels for force plate markers. The advantage of the latter would be that it also defines the contact surface, so center of pressure on that moving surface can be calculated from the 3D force and moment. Alternatively, you need to define the surface separately, in the force plate's local coordinate system (e.g. Z=0). I would also like to reiterate that the coordinate transformation described above is not sufficient if gravity and inertia effects are not corrected.

Finally a word of caution (at the risk of going somewhat off topic). If your force plate data includes 3D force, 3D moment, and center of pressure, and you want to apply ground reaction load to a musculoskeletal model, you should only use force and moment. Ignore the center of pressure data. The force must be applied to the foot at the global origin (even though the foot may be nowhere near the global origin), and the moment then represents the fact that the physical force is in a different location.

The center of pressure is just another way to represent the moment. You can actually use 3D force and center of pressure (and not the moment), but then you also need to include a scalar "free moment" on an surface normal axis through the center of pressure as an additional input. If your data file does not include free moment, force and center of pressure are not sufficient for a 3D dynamic analysis!

Using force and moment is simpler and has the advantage that low-pass filtering can be done, which is important for activities with impact [2]. Center of pressure can't be processed with a low-pass filter because the noise spectrum is not stationary. In the swing phase, center of pressure is almost zero divided by almost zero, and extremely noisy.

A good source for the theory of force plates, and relationship between moments and center of pressure is http://www.kwon3d.com/theory/grf.html

Ton van den Bogert

1. Hnat, SK, van Basten B, van den Bogert AJ (2018) Compensation for inertial and gravity effects in a moving force platform. J Biomech 75: 96-101.
2. Kristianslund W, Krosshaug T, van den Bogert AJ (2012) Effect of low pass filtering on joint moments from inverse dynamics: Implications for injury prevention. J Biomech 45: 666-671.

[Edmund Cramp]

Re: Non-planar moving force plates in C3D

Essentially the C3D format defines the data recording, and synchronization of the data samples, and defines a standardized method of storing the parameters that define the recorded data values. Supporting new sensors is not a problem, all that needs to be done is to sample the sensor outputs and store the information needed to calculate the results, which is generally just the data scaling and locations of the sensors. The actual calculations that generate force and moment values are performed by software that reads the data from the C3D file and can, if desired, write the results of the calculations back to the C3D file.

So all we need to know is where the sensor is in the 3D space and record the sensor output - if only life was that easy. If the subject is on the force plate and the plate is moving, then the plate is both sensing the force applied, and applying a force vector to the subject - that is going to be an interesting calculation but it’s not really a C3D issue.

If the force plate data is to be written to a C3D file without any 3D point data then there should be no problems, provided that the sensor signals and rotation signals can be stored as signed 16-bit integers or floating point values, each signal can be stored as an analog channel value, each with a unique scale and sampled at any rate. It will be necessary to demonstrate that the sensor and rotation signals are synchronized but that is a data collection issue, not a C3D file issue - anyone will be able to read the data and export it.

If 3D locations are to be recorded in the same file then the data collection system that generates the C3D file will need to synchronize all of the signals to write an accurate C3D file. This is a data collection issue, potentially when multiple sample rates exist there can be synchronization and data sampling problems. When the 3D system is sampling data at a fixed camera rate and sampling analog force plate data it’s relatively easy to synchronize multiple analog samples with 3D data samples. But when sensor data is independently pre-sampled by independent devices, and transmitted via USB or a network to the data collection system, the data from each device will usually need to be translated from different internal device sample rates to the data collection sample rate with the potential for sampling and synchronization issues when the system tried to assemble everything and generates an output.

[Allan Carman]

Re: Non-planar moving force plates in C3D

A few more thoughts, some are getting off the origin topic

Whether the force plate produces local forces and moments or a combination of forces the end goal is to calculate global forces and centre of pressure (CoP) that accurately align with the 3D system. Small errors in CoP (ie. centimeters) will make substantial errors in resultant ankle joint moments. The location of the centre of the force plate surface, although used to transform local plate CoP to global 3D space, is not relevant to inverse dynamics and calculation of resultant joint moments.

The force plate forces (Fx,Fy,Fz), moments (Mx,My,Mz) and centre of plate surface relative to the true origin (a,b,c) can be used to calculate free moments Tx, Ty and Tz. However these are not usually explicitly calculated but combined within the CoP equations to calculate CoP from the forces, moments and location of centre of the plate surface.

If you have the force vector (Fx,Fy,Fz) and free moment Tz this is not enough information to allow for calculation of CoP (point of force application) or to do inverse dynamics.

The Kwon page in describing the calculation of center of pressure is incorrect in its description, derivation and resulting equation for the free moment Tz.
http://www.kwon3d.com/theory/grf/cop.html, equations 1, 2 and 3.

One small thing, in the C3D manual page 88 in describing force plate type 1 labels the free moment as Mz. This should be Tz as Mx, My, Mz refer to the moments measured by the plate about the true origin of the plate.

I would agree with Edmund Cramp that there are implementation issues that are part of the data collection and analysis process and not a C3D file problem. Such as moving force plates, combining marker data with analogue with different frame rates or synchronization between devices. Like others I support the use and development of the C3D file. It has advantages of flexibility and all the information needed to import/export, interpret and analysis the data is contained within the one file.

Allan

[Ton van den Bogert]

Re: Non-planar moving force plates in C3D

I think Allan misuses the term "free moment", perhaps he means the global moment.

"free moment" in this context it is defined as a scalar (one variable, not three): the moment on an axis that is perpendicular to the contact surface and goes through the center of pressure. So we should definitely not talk about Tx,Tx,Tz. If the z-axis is perpendicular to the surface, the free moment can be labeled Tz, or expressed as a vector: [0,0,Tz]. At the center of pressure, Tx and Ty are by definition zero.

Allan, can you elaborate on the error in Kwon's equations? I don't see the error. Keep in mind that [Mx,My,Mz] is defined there as the (local) moment with respect to the true origin, which is located at [a,b,c] relative to the global origin O. This is the Mx,My,Mz that comes directly out of the AMTI force plate, or for other load cell configurations, calculated by summing the load cell contributions as specified in equation (4).

Kwon defines (x,y) as the center of pressure in the global coordinate system. He makes it somewhat confusing by using local and global variables in the same equations, but the equations are not wrong as far as I can tell.

I find it more clear to first convert from local force and moment data to global force and moment data, using the equations from my previous post.

Then for dynamic analysis, you can use the global Fx,Fy,Fz,Mx,My,Mz, or the global Fx,Fy,Fz,x,y,Tz. You always need six variables. You can convert between the two representations as follows:

COPx = -My/Fz
COPy = Mx/Fz
Tz = Mz - COPx*Fy + COPy*Fx

Or the other way around:

Mx = Fz * COPy
My = -Fz * COPx
Mz = Tz + COPx * Fy - COPy * Fx

This shows that Tz is the moment on the global Z axis, minus the moment that is due to the center of pressure not being on the global Z axis.

I agree with Allan that you can't do dynamic analysis based on Fx,Fy,Fz,Tz. You need six variables. If you tried this, you get huge errors in the joint moments so you immediately know it's wrong. But also you can't do dynamic analysis with Fx,Fy,Fz,COPx,COPy because that is only five variables. Neglecting Tz will not give huge errors, and only in transverse (global) plane joint moments, so this error can easily go undetected.

All of this assumes that z=0 is the contact surface. If the contact surface is a different plane, the dynamic analysis with force, COP, T still works, and produces correct joint moments, but the COP variables do not have a physical meaning anymore.

These are some reasons why I prefer not to use COP as input for dynamic analysis. It's not wrong, but there are issues with low pass filtering, when the contact plane is different (you need different equations), and the risk of accidentally neglecting Tz.

Ton