Differences

This shows you the differences between two versions of the page.

--- visual3d:getting_started:visual3d_faq [2024/07/19 19:17] – Corrected C-Motion email address to HAS-Motion. wikisysop
+++ visual3d:getting_started:visual3d_faq [2025/05/29 14:36] (current) – [Visual3D FAQ] wikisysop
@@ Line 1: / Line 1: @@
 ====== 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 C-Motion documentation wiki. Wherever appropriate, links to information within the wiki are provided. "Subject-specific" FAQ pages, dealing with individual topics, can be found by using the FAQ Category link at the bottom of this page and some questions here are also on those other pages.
+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 =====
-==== 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?
-**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]]
-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 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?\\
+**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?\\
+**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.
-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. 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!!!\\
+\\
+**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.
@@ Line 32: / Line 30: @@
 \\
-**Question**: What does **CalTester** do?\\
+**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.
-The COFP signal is created by transferring the centre 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 maximise 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]]
-See [[https://www.c-motion.com/v3dwiki/index.php/CalTester|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?\\
+**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?\\
+**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.
@@ Line 57: / Line 53: @@
-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 becauseVisual3D 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.
+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.
 \\