HAS-Motion Software Documentation

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Visual3D FAQ ======

This Frequently Asked Questions page contains a fairly eclectic mix of questions regarding Visual3D. It is made up of questions that are regularly asked by users via support@has-motion.ca and the typical answers provided by us to those questions. More complete solutions/answers/explanations can be found within the HAS-Motion documentation wiki. Wherever appropriate, links to information within the wiki are provided. Modeling FAQs can be found [[visual3d:documentation:modeling:modeling_faq|here]].
===== FAQs =====

**Question**: I’m doing **inverse dynamic analyses** but in some trials my participant has **two feet on one force platform** at the same time, and in others **one of their feet is simultaneously in contact with two different force platforms**. What should I do?

If two feet are on the same force platform at the same time, Visual3D has no way of parsing the FORCE data into two separate parts, one for each foot. This means that inverse dynamic calculations are invalid and shouldn’t be carried out. Conversely, one foot contacting two platforms isn’t a problem. Visual3D automatically ‘assigns’ segments to forces based on the distance of the COFP from the segments in the model. Put simply, the nearest segment to the COFP is assigned to the force. There is a threshold value that the separation distance must be within (0.2m), and we don’t advise altering this without good reason. This assignment means that inverse dynamics are still calculated when a foot ‘straddles’ two platforms. Also, most people aren’t aware that [[visual3d:documentation:pipeline:event_commands:automatic_gait_events|Automatic_Gait_Events]] are based on force assignments, so bad or absent assignments can create issues with these. We advise that force assignment should always be checked carefully.

See [[Visual3D:Documentation:Kinematics_and_Kinetics:External_Forces:Force_Assignment|Force Assignments]]


\\
**Question**: In the **calculation of joint moments**, I have read that the forces and marker trajectories should be filtered with the same cut off frequency. I know this and do so. I also use the settings option to “use processed targets to calculate link model based items”. Does checking this option also mean that processed forces are used in the calculation or does “targets” only refer to the marker traces?

The best approach in Visual3D is to filter the TARGET::ORIGINAL and the ANALOG::ORIGINAL data and not filter the FORCE, COFP and FREEMOMENT signals. Then check both "Use Processed Analogs for Ground Reaction Force Calculations" and "Use Processed Targets for Model/Segment/Link Model Based items". In general, most people filter their target data with a lower cut-off frequency then their force plate data because (i) the force signal to noise ratio is better and (ii) the force tends to have a higher frequency content than the target data, however you are correct about using the same cut-off frequency being recommended in the literature for inverse dynamics. Checking the "Use Processed Analogs for Ground Reaction Force Calculations" option means Visual3D uses the filtered Analog data to compute the ORIGINAL FORCE, COFP and FREEMOMENT signals. Don’t forget to "RECALC" after you filter the ANALOG data.

\\
**Question**: When I look at **“Data Values”** in a FORCE signal, within the Signals and Events tree, what are the **X SUB, Y SUB and Z SUB** values?

Many people collect analog data at a higher rate than their motion capture data, which is the point rate. This is fine, as long as the higher rate is an integer multiple of the point rate. When force data are applied to a model, the resulting Link_Model_Based data are at point rate. This is because forces applied to segments cannot be calculated where the segment location is unknown (between point frames), i.e. there are no target data to generate segment locations for the ‘extra’ analog frames. However, the FORCE data retain the analog data rate. These ‘extra’ sample points are displayed as SUB frames within the point rate. The first subframe is synchronized with the point data, and it is this first subframe that is used for Inverse Dynamics calculations. Other Link_Model_Based data, which are based on segments, are also sampled at the point rate, since segmental data can only ever be calculated at point rate.


\\
**Question**: I can’t get my data out of Visual3D and into **OpenSim**, Help!!!

OpenSim and Visual3D are used for two different purposes. OpenSim is used for muscle modelling/simulations, while Visual3D is used for modelling/analysing motion capture data. Visual3D allows users to export the data they have collected using their motion capture system into OpenSim for muscle modelling Difficulties tend not to involve the export/import itself, but are caused by prior data collection and processing issues. In order to accurately export your data to OpenSim, the Visual3D model must match the OpenSim model (the default export from Visual3D uses the gait_2392_simbody.osim). This means that in order to export the data from Visual3D, all of the segments in the OpenSim model must exist (containing two feet, two shanks, two thighs, a pelvis and a trunk). The model should not contain any “extra” segments (for example, a second trunk segment). Also, OpenSim expects the subject to walk in the laboratory’s +Y direct and the laboratory’s +Z direction to be up. If this isn’t the case for you, you can create a virtual lab to ensure your data are “compliant”, but this virtual lab must be called “v3d_lab”. The most common problems are when one, or more, of these conditions isn’t met.

See [[Visual3D:Documentation:Kinematics_and_Kinetics:OpenSim|OpenSim documentation]]

\\
**Question**: What does **CalTester** do?

The COFP signal is created by transferring the center of pressure calculated inside the force platform’s coordinate system into the global, laboratory coordinate system. This transfer is based on the location of the force platform’s corners and the offset between the top of the force sensors and the top of the platform’s surface. The correct position of the COFP is key to accurate inverse dynamic calculations. Put simply, CalTester allows you to compare the position of the COFP, which has been transformed from the force platform’s coordinate system into the global, laboratory coordinate system with how that position is represented using motion capture data. We can do this because we know where the end of the calibrated CalTester rod is in space, and can compare this to the calculated position of the COFP. The two can then be ‘calibrated’ to bring them closer together by altering the force platform location parameters. In order to ensure best results it is important to follow a few simple steps. Always begin the data capture with the CalTester rod not in contact with the force platform, but make sure the base plate is in situ. This allows Visual3D to calculate a baseline zero for all the force platform channels. Once the rod is in contact with the base plate, the CalTester should be the only thing that comes in contact with the force platform. Ensure the rod is loaded longitudinally with a load of at least 200 N and that, during the data collection, the angle of the rod is no more than about 20 degrees. This will maximize accuracy of COFP calculation from the kinetic data and prevent the CalTester rod’s tip sliding away from the bottom of the dimple in the base plate and being elevated.

See [[caltester:caltester_mode_overview|CalTester documentation]]


\\
**Question**: I am interested in **calculating shoulder angles and moments during a throwing motion**, but I am not 100% sure about the information to input into Visual3D. In order to obtain the joint moment for the shoulder, what information would I have to put into “Resolution Coordinate System” or “Cardan Sequence”? Does this depend on the Cardan Sequence used to calculate joint angles?

A joint angle is a relative angle between two segments, one of which is termed the “reference segment” and is assumed to be stationary for the calculation. Calculation of a joint angle is typically done by taking rotations around the reference segment's X axis, a floating Y axis, and the non-reference segment's Z axis (X-Y-Z) in turn (hence a joint angle is NOT a vector). The final orientation of any segment relative to a reference segment depends on this rotation sequence. Modelling upper extremity movements can be problematic due to the large ranges of motion, in all three planes, at the shoulder. This means there is no single definition that is anatomically meaningful for the shoulder’s full range of motion. For a joint moment you can use either a “Resolution Coordinate System” or “Cardan Sequence” but not both. In the upper extremity it probably makes most sense to use a “Resolution Coordinate System”. This is because selecting the proper “Cardan Sequence” and interpreting the data at the shoulder can be tricky. For example in an X-Y-X rotation sequence, “gimbal lock” can occur when the Y rotation (shoulder ab-duction) approaches 90 degrees. This results in any interpretation of the data using this sequence being somewhat meaningless. Also, be aware that the joint moment is a vector (i.e. it has “magnitude” and “direction”), but when you resolve it into a “Cardan Sequence” it loses its properties as a vector. Finally, we suggest that IK (global optimisation) is used to “pin” the shoulder joint together by constraining translations.

\\
**Question**: I have all of my CMO files catalogued using the **CMO library**, and I want to reprocess analogue data using a different filter cut-off frequency. The problem I'm having is when I try to filter data via the pipeline an error message appears. This says "Info! Cannot overwrite an existing signal in the cmo library". How do I re-process my data using the CMO library?

Unfortunately the short answer is that you can’t re-process via the CMO library. The only way to modify the signals, therefore, is by opening each CMO file, recalculating, and then closing the CMO file. The CMO library is simply a folder containing a group of CMO files. These files are each indexed by their CMX file which contains processed information. It does not contain the model template, standing (calibration) trial or any data from the KINETIC_KINEMATIC folder. While it is impossible to process data via the library, using the CMO library can be a quick and easy way to interrogate large data sets once the initial processing has been completed.

See [[Visual3D:Documentation:Definitions:CMO_Library_|CMO Library]] and [[Visual3D:Documentation:Reports:Normative_Data_From_CMO_Library|Getting normative data from CMO library]]

\\
**Question**: Currently, I **fill any gaps in marker trajectories** using the motion analysis software that comes with the cameras. I do this before I export the c3d file and upload it into Visual3D. I have noticed that Visual3D has an ‘interpolate’ option in the pipeline that will also fill any gaps. Should I continue to gap fill as I am, or should I do it in Visual3D?\\


We recommend that gap filling is done in Visual3D. There are two reasons why we think so. Firstly, Visual3D always retains the raw (unfilled) target data in the TARGET::ORIGINAL folder. This allows you to easily re-process the original data without having to re-label from scratch. It is possible to re-process original data within motion capture software, such as Nexus or QTM for instance, but this requires a complete re-label, which can be time consuming and laborious (as we all know!). The second reason we think gap filling should be done within Visual3D is because Visual3D maintains an audit trial of how the TARGET data are processed. This includes any gap filling. Thus, years later you can simply open the CMO file and look at the processing history of your target data and determine whether gap filling was used, and if it was, what parameters were used to fill the gaps. If you gap fill in your motion analysis software, as time goes by you may not recall how the gaps were filled (we certainly wouldn’t!). If you are more comfortable filling any gaps in your motion analysis software that is fine, however we strongly recommend making a record of what was filled, and how it was filled for later reference.

\\
**Question**: I am trying to determine the mean and median power frequencies of **EMG data**. I want to use the **compute DFT coefficients** command but I’m a little unsure on values of base frequency and what number of coefficients. Can you give me some advice please?\\


Typically DFT coefficients are calculated over a cycle, thus you need to have your events created correctly first. Then you need to determine the baseline frequency and ‘number of frequencies’. You can use the default baseline frequency. This default is the ANALOG data rate divided by the number of samples in a ‘cycle’. For instance, if you are recording data at 2400 Hz and a cycle is 10,000 samples then the default baseline frequency is 2400/10000 = 0.24. Again, assuming the sampling rate is 2400 Hz then the maximum expected frequency in the data is 2400/2 = 1200 Hz. You need to create enough coefficients to calculate the maximum frequency of the signal. The number of coefficients is determined as the maximum expected frequency of the signal/baseline frequency. In the above example the number of frequencies would be 1200/0.24 = 5000.

See [[Visual3D:Documentation:Pipeline:Metric_Commands:Metric_Compute_DFT_Coefficients|Compute DFT Coefficients]]