You can find the latest documentation for all current versions of software here:

DOCUMENTATION HOME

Vicon Core Software will also install documentation/help guide when you install the software.

Once installed, launch the software and select Help > View Installed Help

The following software will install Help:

Nexus 2, Shōgun, Tracker 3, Blade 3, Pegasus, CaraLive, CaraPost, Polygon 4

There are four gap filling options available in Nexus 2.

Woltring (Quintic spline)

This has slightly different behaviour for the pipeline operation compared to the manual fill.

Both versions generate a quintic spline using valid frames around the gap as seed data. The gap is filled using the interpolated values from the spline. If there are insufficient frames surrounding the gap, the fill is rejected.

Pipeline

Searches backwards and forwards from the gap looking for (Number of Gap Frames / 2) + 5 consecutive valid frames on each side, but will accept a minimum of 5 valid frames on either or both sides if the preferred range is not available. Searches the entire length of the clip looking for the valid frame ranges.

Manual

Searches up to (Number of Gap Frames / 2) + 5 frames backwards and forwards from the gap. Requires a minimum of 10 valid frames in this range – these are not required to be consecutive.

Pattern

Manual fill operation only.

Generates linear interpolations between the valid frames either side of the gap and between the same frames in a donor trajectory. The interpolated value in the gap trajectory is then offset by the difference between the interpolated and true values in the donor trajectory. Mathematically:

Let F(t) be the value in the position of the trajectory to fill at frame t, and D(t) that of the donor trajectory. Let t0 and t1 be the valid frames before and after the gap, respectively. Then if we define the interpolated position V of trajectory Gat frame t as:

V(G(t)) = ( G(t1)-G(t0) ) * ( t – t0 ) / ( t1-t0 ) + G(t0)

then:

F(t) = V(F(t)) – V(D(t)) + D(t)

Rejects the fill if the donor trajectory has any invalid frames within the gap region, or if the donor or fill trajectory are invalid at either t0 or t1

Rigid Body

Takes a number of trajectories and assumes these move as a rigid body. The gaps in the selected trajectory are filled as if this trajectory is also a part of the same body. Manual filling is restricted to 3 donor trajectories and fills gaps in a single trajectory; the pipeline operation will use as many donor trajectories as possible, and will attempt to fill the gaps in each selected trajectory using all the other selected trajectories as donors.

Define the state at frame t as an (n x 3) matrix M(t) whose rows are the position vectors of the donor trajectories, P(t) as the position of the fill trajectory, and tx as a reference frame in which the positions of the donors and fill trajectory are all known.

We transform M into M by subtracting the mean value of the column i from each row entry M(t)(i,j):

M(i,j) = M(i,j) – O(j), where O(j) = ( (i=1->n) ∑ M(i,j) / n )

We then create a covariance matrix C = M(tx)’ M(t) and perform an SVD such that C = U S V*

We take L to be the the identity matrix, except that if det( V U* ) < 0, then L(3,3) = -1. Then we can generate a rotation matrix R(tx) = V L U* (This is effectively the Kabsch algorithm to find the optimal rotation between two point clouds)

The interpolated position at frame t based on reference frame tx is then defined as:

G(t, tx) = R(tx) ( P(t) – O(tx) ) + O(t)

and

F(t) = ( G(t, t1) – G(t, t0) ) * ( t – t0 ) / ( t1 – t0 ) + G(t, t0)

where t0 and t1 are the valid frames before and after the gap, respectively.

The fill is rejected if there are fewer than 3 valid donor trajectories at any frame t0 <= t <= t1, or if the trajectory to fill is invalid at t0 or t1.

Kinematic

Determines the fill based on the position and orientation of a segment. The manual operation operates on a single selected trajectory, while the pipeline operation attempts to fill gaps in all trajectories associated with the selected segment.

The mathematics of this operation are simply:

G(t, tx) = R(t) R(tx)’ ( P(t) – O(tx) ) + O(t)

and

F(t) = ( G(t, t1) – G(t, t0) ) * ( t – t0 ) / ( t1 – t0 ) + G(t, t0)

where R(t) is the rotation matrix defining the orientation of the segment in the world at frame t, O(t) is the origin position of the segment at frame t, and t0 and t1 are the valid frames before and after the gap, respectively.

The fill is rejected if there are no kinematics for the selected segment at any frame t0 <= t <= t1, or if the trajectory to fill is invalid at t0 or t1.

To configure force plates for analog data capture:

1. Go to the Resources pane > Systems tab, click the Go Live button.

2. In the System tab, right-click the Devices node, point to Add Analog Device and select the proper force plates.

The selected force plate node automatically expands to display the newly created device. If the appropriate type is not displayed, contact Vicon Support.

3. In the Properties section at the bottom of the System resources pane, select Show Advanced.

4. In the General section

• Either load the manufacturer’s Calibration File.
• OR, enter the Calibration Matrix 6×6 Matrix values manually

5. In the Source section

• From the drop-down list, select a Source to which the device is attached (i.e. Lock+ or Giganet MX)
• Select the appropriate pins for the force plate channels.
• Select the Gain for the Source from the choice of gains available for the Lock+.

Please Note: Expand force plate node to expose the Force, Moment and CoP (Center of Pressure) channels. A Green Arrow indicated a connected source device and a Yellow yield indicates that a channel has not been assigned a pin.

6. In the Dimensions section, add in values from force plate manufacturer’s manual if not already entered

7. In the Positions section, position the force plate in respect to the wand and the origin of the plate.

8. In the Orientation section, orient the plate so it makes sense in respect to your capture volume.

9. In the Origin section, add in values from force plate manufacturer’s manual if not already entered.

10. To tare the force plate at zero load:

• Complete a hardware zero with the force plate Amplifier, if possible.
• Click the Zero Level browse button and enter the matrix properties.
• You can also tare the force plate by right-clicking on the force plate name in the System resources tree and selecting Zero Level.

11. In the capture volume, have someone step onto the force plate. You should see the force vector display in real time.

• Switch to a Graph View pane. If necessary, select Components from the Graph Type drop-down list. A real-time graph of the Force output is displayed. Verify that the vertical (Fz) force component is equal to [known mass * 9.81].

For further details on configuring analog force plates, please refer to the Configure Force Plates section of the installed Nexus Help.

To facilitate working with very large unprocessed data files, you can choose which files will be loaded (.x2d camera data and/or .x1d analog data), and how many frames of the trial are loaded.

To do this click Show Trial Loading Options on the ProEclipse/Data Management toolbar at the top right of the ProEclipse/Data Management window. A new area will appear called Raw Data Loading Options

How to work with large trial data:

1. In order to select only required frames, in the Raw Data Loading Options area, select Load Range From and type the frame to start from in the first box and the end frame in the second box.

2. If required, choose whether to load both MX centroid/grayscale data (X2D) and raw analog data (X1D) files, or only one of these options.

3. Process the file(s) as normal.

Only the selected range and files will be processed, it is recommended that you save the section under a new name using File | Copy As…

Vicon Nexus 2 is compatible with, and has been tested with MATLAB R2013b. Nexus may function with other versions of MATLAB, but other versions have not been extensively tested by Vicon.

To use MATLAB with Vicon Nexus 2, ensure that, in addition to installing MATLAB, you install .NET Framework version 4.5

To set MATLAB path:

Once Nexus, MATLAB and the appropriate .NET Framework version are installed, you will want to set the path.

Windows 7: Go to the Start Menu > All Programs > Vicon > Nexus 2.X > Set MATLAB Path.

Windows 10:  Start > All Apps > Vicon > Set MATLAB Path

This will give MATLAB access to the Nexus scripting functions.

To Configure MATLAB for scripting with Nexus:

Within MATLAB, create an instance of the ViconNexus object to get access to its methods; type the following line in the Command Window:

vicon = ViconNexus()

To obtain MATLAB Command List:

To see which functions you have access to write the following line in the Command Window:

methods ViconNexus

To obtain MATLAB Command Help:

If you need guidance for the use of any of the displayed functions you can run either of the following lines in the Command Window.

help ViconNexus/commandName

For example:

help ViconNexus/GetTrajectory

OR

help commandName

For example:

help GetTrajectory

To troubleshoot MATLAB Scripts:

To troubleshoot or run your script, you must have a trial open within Nexus

For further information please see the installed or online help guide.  This can be found under the Help tab within Nexus.

You can find the latest MATLAB troubleshooting tips here:

MATLAB TROUBLESHOOTING

Solutions include:

• Nexus unresponsive when running script
• MATLAB Error when constructing an instance
• Generic type error

and many more.

To launch Python:

1. Click Start and point to All Programs (or press the Windows key) and then start to type Python.

2. Click the Python symbol.

3. To automatically configure Python for scripting with Nexus, at the command prompt, enter the following:

import ViconNexus
vicon = ViconNexus.ViconNexus()

To obtain Python Command List:

Ensure you have launched and configured Python as described above, then at the Python command prompt, enter:

vicon.DisplayCommandList()

To obtain Python Comman Help:

To obtain help on each command that you can use with Nexus, at the Python command prompt, enter:

vicon.DisplayCommandHelp(’commandName’)

Where commandName is the command for which you want to display help.

For example, the following command displays help on GetTrajectory:

vicon.DisplayCommandHelp(’GetTrajectory’)

Help on GetTrajectory is displayed.

Vicon Plug-in Gait (conventional gait model) has been ported into Matlab code and is freely available for download from the associated page below or by browsing the download section.

Plug-in Gait Matlab forms part of the Advanced Gait Workflow (AGW) installer.

This code runs Plug-in Gait on non AGW trials (as per conventional gait workflow). Plug-in Gait Matlab also makes use of functional joint centres (hip and knee) as created by SCoRE and SARA.

The Plug-in Gait Matlab code can also be run in conjunction with native Plug-in Gait, allowing a direct comparison between the two versions, which provide the same results, assuming the code has not been edited.

– Please note Plug-in Gait Matlab is not intended for Clinical use.

Optimum Common Shape Technique (OCST) is a mathematical approach that finds the Average or Common shape for selected sets of markers (3 or more). The first pass through all frames allows the process to see each shape configuration. From this a common shape is calculated. The second pass through the data for processing forces the common shape and creates virtual markers. Alternatively, the real trajectories can be left in place (not moved or replaced) but the Segment elements can be calculated using the new positions.

OCST is important as it allows a non-rigid cluster (skin based markers) to be described as if it were truly rigid. Forcing a virtual rigidity allows the use of other algorithms that are reliant on an expectation of rigidity (i.e SCoRE and SARA).

The OCST method has been implemented in Nexus 2.

Research Publication: W.R. Taylor, E.I. Kornaropoulos, G.N. Duda, S. Kratzenstein, R.M. Ehrig, A. Arampatzis, M.O. Heller. Repeatability and reproducibility of OSSCA, a functional approach for assessing the kinematics of the lower limb. Gait & Posture 32 (2010) 231–236

Symmetrical Center of Rotation Estimation (SCoRE) is an optimization algorithm that uses function calibration frames between a Parent and Child segment to estimate the Center Point of Rotation. The Parent and Child segments are expected to be rigid, these can either use Rigid Cluster or Skin Based Markers + OSCT processing.

The main value of this operation is to provide a more repeatable Hip Joint center location. SCoRE locates the joint center only, Kinematic and Kinetics are still calculated by a Full Biomechanical Model (ie Plug-in Gait).

The SCoRE method has been implemented in Nexus 2.

Research Publication: Rainald M. Ehrig, William R. Taylor, Georg N. Duda, Markus O. Heller. A survey of formal methods for determining the centre of rotation of ball joints. Journal of Biomechanics 39 (2006) 2798–2809

Symmetrical Axis of Rotation Approach (SARA) is an optimization algorithm that uses function calibration frames between a Parent and Child segment to estimate the Axis of Rotation. The Parent and Child segments are expected to be rigid, these can either use Rigid Cluster or Skin Based Markers + OSCT processing.

The main value of this operation is to provide a more repeatable Knee Joint Axis. SARA locates the joint axis only, Kinematic and Kinetics are still calculated by a Full Biomechanical Model (ie Plug-in Gait).

The SARA method has been implemented in Nexus 2.

Research Publication: Rainald M. Ehrig, William R. Taylor, Georg N. Duda, Markus O. Heller. A survey of formal methods for determining functional joint axes. Journal of Biomechanics 40 (2007) 2150–2157

There are several references available that pertain to the Woltring Filter. In-depth information about this filter can be found at the International Society of Biomechanics web page. The direct web address is:

http://isbweb.org/software/sigproc.html

There are numerous resources at this site that explain the Woltring filter as well as a link to download the original Fortran code.

The question of Butterworth vs. Woltring is actually not that complex a question. From the above-stated web, Woltring has shown that spline smoothing is equivalent to a double Butterworth filter. The difference is that with splines it is possible to process data with unequal sampling intervals and the boundary conditions are well defined, and in the text Three-Dimensional Analysis of Human Movement by Allard, Stokes, and Blanchi, on page 93 under the section: Spline Package GCVSPL. For periodic, equidistantly sampled splines, the equivalence with the double Butterworth filter (Equation 5.14) can be demonstrated via a Fourier transformation and a variational argument.

So essentially, using a Woltring filter is equivalent to using a Butterworth filter. Because the Butterworth filter is an analog filter that has been in use for a long time, you would naturally expect to find many references that use this filter. The history of the Woltring filter is relatively young, therefore its use may not be as well documented. The development of this filter was designed to apply more specifically to kinematic data which is prevalent in biomechanics research.

The MSE setting (mean squared error) and GCV setting (General Cross Validation) are documented in the website listed above.

Our own investigation yielded this response: GCV makes an estimate of noise by doing General Cross Validation for all the data points and uses some statistical processes to choose a noise level with which to filter to give the final results. The MSE method allows you to simply type the noise level in, and the spline is fitted to the data points allowing the given level of tolerance. The units are in mm^2. This processing method is thus quicker and ensures the same level of smoothing for all trajectories, whereas the GCV smoothing can vary from trajectory to trajectory. It is arguable which approach is better. If a particular site is very familiar with the details of this filter, they could measure the noise in their system and apply an appropriate MSE value. In truth, the MSE option allows people who want to get graphs as smooth as VCM to do that, by experimenting with their values.

Our implementation was taken directly from the work done by Herman Woltring.

See his original work in the following:

• Woltring, H.J. (1986) A FORTAN package for generalized cross-validatory spline smoothing and differentiation. Advances in Engineering Software, 8(2), 104-113.

In addition, Mr. Woltring wrote up this topic in Chapter 5 (Smoothing and Differentation Tewchniques Applied to 3-D Data) in a text dedicated to the topic. This text, Three-Dimensional Analysis of Human Movement was edited by Paul Allard, Ian A.F. Stokes, and Jean-Pierre Blanchi. It was copyrighted in 1995 and published by Human Kinetics. They can be reached at 800-747-4457 or at http://www.humankinetics.com

Some others that may be useful:

• Dohrmann, C.R., Busby, H.R., & Trujillo, D.M. (1988). Smoothing Noisy Data Using Dynamic Programming and Generalized Cross-Validation. ASME Journal of Biomechanical Engineering, 110, 37-41.
• Craven, P., & Wahba, G. (1979). Smoothing Noisy Data with Spline Functions, Estimating the Correct Degree of Smoothing by the Method of Generalized Cross-Validation. Numerical Mathematics, 31, 377-403.
• Busby, H.R., & Trujillo, D.M. (1985). Numerical Experiments With a New Differentiation Filter. Journal of Biomechanical Engineering, 107, 293-299.
• Hodgson, A.J. (1994). Considerations in Applying Dynamic Programming Filters to the Smoothing of Noisy Data. ASME Journal of Biomechanical Engineering, 116, 528-531.
• Trujillo, D.M., & Busby, H.R. (1983). Investigation of a Technique for the Differentiation of Empirical Data. Journal of Dynamic Systems, Measurement, and Control, 105, 200-202.
• Cappello, A., La Palombara, P.F., & Leardini, A. 1996. Optimization and Smoothing Techniques in Movement Analysis. International Journal of Bio-Medical Computing, 41, 137-151.
• Corradini, M.L., Fioretti, S., & Leo, T. (1993). Numerical Differentiation in Movement Analysis: How to Standardise the Evaluation of Techniques. Medical & Biological Engineering & Computing, 31, 187-197.
• Dujardin, F.H., Ertaud, J.Y., Aucouturier, T., Nguen, J., & Thomine, J.M. (1997). Smoothing Technique Using Fourier Transforms Applied to Stereometric Data Obtained From Optoelectronic Recordings of Human Gait. Human Movement Science, 16, 275-282.
• Fioretti, S. (1996). Signal Processing in Movement Analysis (a state-space approach). Human Movement Science, 15, 389-410.
• Giakas, G., & Baltzopoulos, V. (1997). A Comparison of Automatic Filtering Techniques Applied to Biomechanical Walking Data. Journal of Biomechanics, 30, 847-850.
• Vint, P.F., & Hinrichs, R.N. (1996). Endpoint error in Smoothing and Differentiating Raw Kinematic Data: An Evaluation of Four Popular Methods. Journal of Biomechanics, 29, 1637-1642.

VVID files can be viewed by using the VVID Viewer.

The VVID Video Viewer is a tool that allows users to view Nexus’ propriety raw video format – VVID.

This file can be downloaded from the Downloads > Utilities and SDKs section.

Bodybuilder Example Models can be downloaded from the associated pages below or by browsing the download section.

The file contains 34 models ranging from a Golf model to a Flow model calculating inter-segmental power flows.

There is a limit to the size that a Bodybuilder Model and its associated *.mp file can be. The limit on the length of the total combined model script (*.mod + *.mp) is 32766 characters. For Bodybuilder version 3.51 and later, a warning dialogue preventing the entry of too much text will be presented when the limit is reached. No warning dialogue will be presented in Bodybuilder versions prior to 3.51, but these will fail to save models that exceeded this limit. The most recent release of Bodybuilder has removed this limitation.

The Vicon DataStream Software Development Kit (SDK) allows easy programmable access to the information contained in the Vicon DataStream. The function calls within the SDK allow users to connect to and request data from the Vicon DataStream.

The Virtual-Reality Peripheral Network (VRPN) is a library that provides an interface between 3D immersive applications and tracking systems used for Virtools. Vicon Tracker 3 has a built-in VRPN server that will stream data natively into these applications or will allow for the development of simple interfaces using VRPN.

Virtools, a commercial application, has support for VRPN and can be configured to connect with Vicon Tracker as follows.

A full VRDevice.cfg file is included below.

Note

Head@TrackerPC is the way Virtools connects to the VRPN server within Tracker. The format is object_name@PC_Name. This configuration file will look for an object called “Head” on the Tracker server called “TrackerPC.”

=======================================
vrpnTracker_0 Head@TrackerPC
neutralPosition_0 0.0 0.0 0.0
neutralQuaternion_0 0.0 0.0 0.0 1.0
axisPermute_0 0 2 1
axisSign_0 1 1 1
trackerScale_0 1
TrackerGroup_0 T0:0:6
=================

This VRDevice.cfg also contains other directives that:

• Map the Vicon coordinates properly to the Virtools coordinates:

axisPermute_0 0 2 1
axisSign_0 1 1 1

• Add a tracker group with:

TrackerGroup_0 T0:0:6

To complete the process, do the following:

• Add the VRPN settings to a VRPack.cfg file, which is in the same folder as the .cmo. That way it can be tested with Virtools Dev.
• For versions of Tracker before 1.2 in the composition, activate the Use Scale option and change the value of

trackerScale_0

in your VRDevice.cfg file to 0.001 (converts Vicon mm to Virtools m).

For a full description of any of these configuration options, please refer to the Virtools documentation.

The Integer format measures the maximum range between real data points, and determines a scale factor. The data is then scaled to that range when saved to the c3d file, and all values are written with the Integer format. When the data is then read into another program (i.e. Polygon), the scale factor is applied to the data converting it into Real data. The real data format saves the data as is without any multiplication by a scale factor and writes it to the c3d file utilizing the Real format. Certain types of data are best suited for the Real format option since no resolution is given up in the storage of the data. Not all programs may be able to read both Integer and Real formatted c3d files, so use care when choosing your preferred option. More details on the .c3d format are available on C3D.org

Plug In Gait, is based on the following journal papers:

Bell, A.L., Pedersen, D.R. & Brand, R.A. (1990). A comparison of the accuracy of several hip center location prediction methods. Journal of Biomechanics, 23, 617-621

Davis, R., Ounpuu, S., Tyburski, D. & Gage, J. (1991). A gait analysis data collection and reduction technique. Human Movement Sciences, 10, 575-587

Kadaba, M.P., Ramakrishnan, H.K. & Wooten, M.E. (1987). J.L. Stein, ed. Lower extremity joint moments and ground reaction torque in adult gait. Biomechanics of Normal and Prosthetic Gait. BED Vol (4)/DSC Vol 7. American Society of Mechanical Engineers. 87-92.

Kadaba, M.P., Ramakrishnan, H.K., Wootten, M.E, Gainey, J., Gorton, G. & Cochran, G.V.B (1989). Repeatability of kinematic, kinetics and electromyographic data in normal adult gait. Journal of Orthopaedic Research, 7, 849-860

Kadaba, M.P., Ramakrishnan, H.K. & Wooten, M.E. (1990). Lower extremity kinematics during level walking. Journal of Orthopaedic Research, 8, (3) 383-392

Macleod, A. And Morris, J.R.W. (1987). Investigation of inherent experimental noise in kinematic experiments using superficial markers. Biomechanics X-B, Human Kinetics Publishers, Inc., Chicago, 1035-1039.

Ramakrishnan, H.K., Wootten M.E & Kadaba, M.P. (1989). On the estimation of three dimensional joint angular motion in gait analysis. 35th annual Meeting, Orthopaedic Research Society, February 6-9, 1989, Las Vegas, Nevada.

Ramakrishnan, H.K., Masiello G. & Kadaba M.P. (1991). On the estimation of the three dimensional joint moments in gait. 1991 Biomechanics Symposium, ASME 1991, 120, 333-339.

Sutherland, D.H. (1984). Gait Disorders in Childhood and Adolescence. Williams and Wilkins, Baltimore.

Winter, D.A. (1990) Biomechanics and motor control of human movement. John Wiley & Sons, Inc.

These references have information on kinematic and kinetic calculations, as well as anthropometrics and repeatability of the model. The upper body model has not been validated in any peer reviewed journal papers and therefore there are no articles on repeatability of the upper body model.

The required measurements for full body plug-in gait and lower body plug-in gait include mass, height, leg length, knee width, ankle width, shoulder offset, elbow width, wrist width, and hand thickness.

These measurements should all be entered in either kilograms or millimetres. All lengths or distances will be required in millimetres. The measurements for inter-ASIS distance, ASIS-trochanter distance, and tibial torsion are all optional entries. If they are not entered in, the model will calculate them.

Here are the precise required measurements for the model:

Mass: The mass of the subject in Kilograms (2.2lb=1kg)

Height: The height of the subject.

Leg length: Measured from the ASIS to the medial malleolus. If a patient cannot straighten his/her legs, take the measurement in two pieces: ASIS to knee and knee to medial malleolus.

Knee width: Measurement of the knee width about the flexion axis.

Ankle width: Measurement of the ankle width about the medial and lateral malleoli.

Shoulder offset: The vertical distance from the center of the glenohumeral joint to the marker on the acromion clavicular joint. Some researchers have used the (anterior/posterior girth)/2 to establish a guideline for the parameter.

Elbow width: The distance between the medial and lateral epicondyles of the humerus.

Wrist width: Should probably be called “wrist thickness.” It is the anterior (palm side) and posterior (back) distance of the wrist at the position where a wrist marker bar is attached.  If the wrist markers are attached directly to the skin, this value should be zero.

Hand thickness: The distance between the dorsal and palmar surfaces of the hand at the point where you attach the hand marker.

The following measurements are optional and/or calculated by the model:

Inter-ASIS distance: The model will calculate this distance based on the position of the LASI and RASI markers. If you are collecting data on an obese patient and cannot properly place the ASIS markers, place those markers laterally and preserve the vector direction and level of the ASIS. Palpate the LASI and RASI points and manually measure this distance, then input into the appropriate field.

Head Angle: The absolute angle of the head with the global coordinate system. This is calculated for you if you check the option box when processing the static trial.

ASIS-Trochanter distance: The perpendicular distance from the trochanter to the ASIS point. If this value is not entered, then a regression formula is used to calculate the hip joint center. If this value is entered, it will be factored into an equation which represents the hip joint center.

Tibial torsion: The angle between the ankle flexion axis and the knee flexion axis. The sign convention is that if a negative value of tibial torsion is entered, the ankle flexion/extension axis will be adjusted from the KAD’s defined position to a position dictated by the tibial torsion value.

Thigh rotation offset: When a KAD is used, this value is calculated to account for the position of the thigh marker. By using the KAD, placement of the thigh marker in the plane of the hip joint center and the knee joint center is not crucial. Please note that if you do not use a KAD, this value will be reported as zero because the model is assuming that the thigh marker has been placed exactly in the plane of the hip joint center and the knee joint center. This value is calculated for you.

Shank rotation offset: Similar to the thigh rotation offset. This value is calculated in a KAD is present and removes the importance of placing the shank marker in the exact plane of the knee joint center and ankle joint center. If you do not use a KAD, these values will be zero. This value is calculated for you.

The first step in the shoulder modelling process is the definition of the shoulder, elbow and wrist centres and the Thorax, Clavicle and Humerus segments. The shoulder angle calculations are then based on YXZ Euler angle rotations between the Thorax and the Humerus Segments as follows:

• LShoulderAngles 1 Flexion Anti-clockwise about Thorax Y, 2 Abduction Anti-clockwise about Thorax X, 3 Internal Rotation Anti-clockwise about Thorax Z
• RShoulderAngles 1 Flexion Anti-clockwise about Thorax Y, 2 Abduction Clockwise about Thorax X, 3 Internal Rotation Clockwise about Thorax Z

The explanation for the sometimes strange angles seen when using the above method for determining shoulder motion is the occurrence of ‘Gimbal Lock’ and the quirk in clinical descriptions of motion known as ‘Codman’s Paradox’. ‘Gimbal Lock’. Gimbal Lock occurs when using Euler angles and any of the rotation angles becomes close to 90 degrees, for example lifting the arm to point directly sideways or in front (shoulder abduction about an anterior axis or shoulder flexion about a lateral axis respectively).

In either of these positions the other two axes of rotation become aligned with one another, making it impossible to distinguish them from one another, a singularity occurs and the solution to the calculation of angles becomes unobtainable. For example, assume that the humerus is being rotated in relation to the thorax in the order Y,X,Z and that the rotation about the X-axis is 90 degrees. In such a situation, rotation in the Y-axis is performed first and correctly. The X-axis rotation also occurs correctly BUT rotates the Z axis onto the Y axis. Thus, any rotation in the Y-axis can also be interpreted as a rotation about the Z-axis.

True gimbal lock is rare, arising only when two axes are close to perfectly aligned. ‘Codman’s Paradox’: The second issue however, is that in each non-singular case there are two possible angular solutions, giving rise to the phenomenon of “Codman’s Paradox” in anatomy (Codman, E.A. (1934). The Shoulder. Rupture of the Supraspinatus Tendon and other Lesions in or about the Subacromial Bursa. Boston: Thomas Todd Company), where different combinations of numerical values of the three angles produce similar physical orientations of the segment. This is not actually a paradox, but a consequence of the non-commutative nature of three-dimensional rotations and can be mathematically explained through the properties of rotation matrices (Politti, J.C., Goroso, G., Valentinuzzi, M.E., & Bravo, O. (1998).

Codman’s Paradox of the Arm Rotations is Not a Paradox: Mathematical Validation. Medical Engineering & Physics, 20, 257-260). Codman proposed that the completely elevated humerus could be shown to be in either extreme external rotation or in extreme internal rotation by lowering it either in the coronal or sagittal plane respectively, without allowing any rotation about the humeral longitudinal axis.

For a demonstration of this, follow the sequence below:

1. Place the arm at the side, elbow flexed to 90 degrees and the forearm internally rotated across the stomach.
2. Elevate the arm 180 degrees in the sagittal plane.
3. Lower the arm 180 degrees to the side in the coronal plane.
4. Note that the forearm now points 180 degrees externally rotated from its original position with no rotation about the humeral longitudinal axis actually having occurred.
5. Appreciate the difficulty then in describing whether the fully elevated humerus was internally or externally rotated.

This ambiguity can cause switching between one solution and the other, resulting in sudden discontinuities. A combination of ‘Gimbal Lock’ and ‘Codman’s Paradox’ can lead to unexpected results when joint modelling is carried out.

The table below displays the Upper Body Segment angles from Plug-in Gait.

All Upper Body angles are calculate in rotation order YXZ.

As Euler angles are calculated, each rotation causes the axis for the subsequent rotation to be shifted. X’ indicates an axis which has been acted upon and shifted by one previous rotation, X’’ indicates a rotation axis which has been acted upon and shifted by two previous rotations.

The table below displays the Lower Body Segment angles from Plug-in Gait.

All Lower Body angles are calculate in rotation order YXZ except for Ankle Angles which are calculated in order YZX.

As Euler angles are calculated, each rotation causes the axis for the subsequent rotation to be shifted. X’ indicates an axis which has been acted upon and shifted by one previous rotation, X’’ indicates a rotation axis which has been acted upon and shifted by two previous rotations.

You can collect data without wands and still get similar results using Plug-in Gait. You can even generate a three dimensional skeleton. The origin of the wands has a little bit of history behind it, but the basic intent is the make the rotation about the long axis of the segment more obvious. A marker directly on the shank will rotate the same amount as a marker on a rod, however, the closer that a marker is to the segment the harder it is to see the rotation. On subjects with smaller segments, it may not be advisable to place the markers directly on the shank.

The ‘Progression Direction’ is defined in order to represent the general direction in which the subject walks in the global coordinate system. A coordinate system matrix (similar to a segment definition) is then defined and denoted the ‘Progression Frame’. This allows the calculation by Plug-in Gait and Polygon of ‘progression’ related variables (HeadAngles, ThoraxAngles, PelvisAngles, FootProgressAngles, Step Width) in relation to this frame.

In Plug-in Gait, the lower body Progression Direction is found by looking at the first and last valid position in a trial of the LASI marker. If the distance between the first and last valid position of the LASI marker is greater than a threshold of 800 mm, the X displacement of LASI is compared to its Y displacement. If the X displacement is greater, the subject is deemed to have been walking along the X axis, either positively or negatively, depending on the sign of the X offset. If the Y displacement is greater, the subject is deemed to have been walking along the Y axis, either positively or negatively, depending on the sign of the Y offset.

If the distance between the first and last frame of the LASI marker is less than a threshold of 800 mm however, the Progression Direction is calculated using the direction the pelvis is facing during the middle of the trial. This direction is calculated as a mean over 10% of the frames of the complete trial. Within these frames, only those which have data for all the pelvis markers are used. For each such frame, the rear pelvis position is calculated from either the SACR marker directly, or the centre point of the LPSI and RPSI markers. The front of the pelvis is calculated as the centre point between the LASI and RASI markers. The pelvis direction is calculated as the direction vector from the rear position to the front. This direction is then used in place of the LASI displacement, as described above and compared to the laboratory X and Y axes to choose the Progression Direction.

Following this definition, the Progression Direction in which the subject walks is assumed to be one of four possibilities; Global axes positive X, Global axes positive Y, Global axes negative X or Global axes negative Y and not diagonally to any of these, for example.

In Plug-in Gait, the upper body Progression Direction is adopted as the same as the lower body’s Progression Direction, if it has one. If no lower body Progression Direction has been calculated, an upper body Progression Direction is independently calculated in just the same way as for the lower body. C7 is tested first to determine if the subject moved a distance greater than the threshold. If not, the other thorax markers T10 CLAV and STRN are used to determine the general direction the thorax faces from a mean of 10% of the frames in the middle of the trial.

Once the Progression Direction along one of the four possible axes directions is determined, the Progression Frame is defined such that its X-axis is oriented positively along this Progression Direction. The Z axis is always assumed to be directed vertically upwards and the Progression Frame is defined following the right-hand rule. The diagram below shows this clearly for each of four circumstances where a subject walks along the different axis directions.

The ‘Progression Angles’ of the head, thorax, pelvis and feet, calculated by Plug in Gait, are the YXZ Cardan angles calculated from the rotation transformation of the subject’s Progression Frame for the trial, onto the orientation of each of these segments on a sample-by-sample basis.

The ‘Step Length’ calculated by Plug-in Gait, is the distance when the foot down event occurs, between the chosen marker (TOE by default) and the opposite foot’s corresponding marker, ALONG the Progression Direction. For example, with the LTOE and RTOE markers chosen in the ‘Gait Cycle Parameter Generation Options’ for the ‘Generate Gait Cycle Parameters’ Workstation pipeline entry, the Left Step Length will be calculated as the distance between the LTOE marker and the RTOE marker along the Progression Direction.

The ‘Stride Length’ calculated by Plug-in Gait, is the distance moved by the chosen marker (TOE by default), ALONG the Progression Direction between one foot down event and the next (i.e. from the start to the end of the gait cycle). For example, with the LTOE and RTOE markers chosen in the ‘Gait Cycle Parameter Generation Options’ for the ‘Generate Gait Cycle Parameters’ Workstation pipeline entry, the Left Stride Length will be calculated as the distance between the LTOE marker at the occurrence of one foot down event and the LTOE marker at the occurrence of the next foot down event, along the Progression Direction.

The ‘Step Width’ calculated by Polygon, is the distance when the foot down event occurs, between the chosen marker (TOE by default) and the opposite foot’s corresponding marker, NORMAL to the Progression Direction. For example, with the LTOE and RTOE markers chosen in the “Analysis” node’s Properties, the Left Step Width will be calculated as the distance between the LTOE marker and the RTOE marker normal to the Progression Direction

In Nexus the Generate Gait Cycle Parameters Pipeline Operation can be used in conjunction with the Gait events to calculate standard Gait Cycle Spatial and Temporal Parameters.

In Nexus, the parameters are based on the first cycle for each side where all the necessary events are found.

Polygon can re-calculate the parameters and define them using the first cycle (default) or the average of all defined cycles. [To use the average of all defined cycles in Polygon, right click on the trial subject’s Analysis node, select Properties, and check the box labeled Use Average of Nominated Cycles.]

These Parameters and available units (the units can be change in the Generate Gait Cycle Parameters Options box) are:

Cadence – 1/s; 1/min; steps/s; steps/min; strides/s; strides/min

Walking speed – m/s; cm/s; mm/s; in/s

Step Time – s; %

Foot Off/Contact events – s; %

Single/Double Support – s; %

Stride/Step Length – m; cm; mm; in

The Distance Parameters are based in the marker position at the time, by default the toe marker (LTOE for left and RTOE for right) is used for the calculation. This can be changed in the Options box of the Generate Gait Cycle Parameters Pipeline Operation.

Cadence: number of strides per unit time (usually per minute). The left and right cadence are first calculated separately based on either a single stride or an average of the defined gait cycles. The overall cadence is the average of the left and the right.

Stride time: time between successive ipsilateral foot strikes.

Step time: time between contralateral and the following ipsilateral foot contact, expressed in seconds or %GC.

Foot contact/off events are all expressed relative to the ipsilateral gait cycle, either as absolute time from ipsilateral foot contact or as %GC, as per the Polygon preference. Single and double support calculations are only valid for walking, i.e. when the contralateral foot off/contact events happen within the ipsilateral stance phase.

Foot off: time of ipsilateral foot off.

Opposite foot contact: time of contralateral foot contact.

Opposite foot off: time of contralateral foot off.

Single support: time from contralateral foot off to contralateral foot contact.

Double support: time from ipsilateral foot contact to contralateral foot off plus time from contralateral foot contact to ipsilateral foot off.

Limp index: the foot contact to foot off time of the ipsilateral foot is divided by the foot off to foot contact time plus the double support time. In other words, the limp index calculates the time the ipsilateral foot is on the ground and divides it by the time the contralateral foot is on the ground during the ipsilateral GC.

All distance and speed measurements use a reference marker on each foot, by default the LTOE/RTOE markers, but this can be changed in the preferences. The marker’s position is evaluated in 3D at the time of the events.

Four 3D points are defined:

IP1 is the ipsilateral marker’s position at the first ipsilateral foot contact.

IP2 is the ipsilateral marker’s position at the second ipsilateral foot contact.

CP is the contralateral marker’s position at the contralateral foot contact.

CPP is CP projected onto the IP1 to IP2 vector.

Stride length: is the distance from IP1 to IP2.

Step length: is the distance from CPP to IP2.

Step width: is the distance from CP to CPP.

Walking speed: is stride length divided by stride time.

The Forces calculated by Plug-in Gait and displayed by Polygon are in the local co-ordinate frame of the distal segment in the hierarchical Kinetic Chain. This means that the Ankle joint forces are recorded in the foot segment axis system. Therefore Ground Reaction force Z will look similar to Ankle Force X, Ground Reaction Force Y will look similar to Ankle Force Z and Ground Reaction Force X will look similar to Ankle Force Y.

For the tibia this will change as the axis orientation now changes. Z force is therefore compression or tension at the joint, Y force is mediolateral forces at the joint while X force is Anteroposterior forces at the joint.

The positive force acts in the positive direction of the axis in the distal segment on which it acts and a negative force acts in the negative direction along the axis.

In Plug-in Gait we use an external moment and force description. That means that a negative force is compression and a positive force, tension, for the Z axis. A positive force for the right side is medial and negative lateral for the Y axis and a positive force is anterior and negative posterior for the X axis.

The report uses a whole folder because there are potentially quite a few files that are associated with a single report. For example, there is one Rich Text Format file per text pane, one data file, one report file, any number of movie (*.avi) files, marker set files (*.mkr) and so on.

To avoid the files being spread around and to keep everything nicely in one place, Polygon copies everything to the report folder. This means that you could end up with more than one copy of your movie files, for example, which may seem unnecessary to you. However, in this day and age when hard disk storage comes in dozens of gigabytes and is cheaper than ever before, the decision was made to copy all the files to keep the report tidy rather than to try and optimize for storage.

The envelope algorithm in Polygon is intended to produce a curve which gives an idea of the shape of the underlying raw EMG. It is based on a running average algorithm, but has been modified to give better response to the peaks in the raw EMG data (a simple running average will produce an envelope curve which fits nowhere near the peaks of the raw data).

The envelope algorithm takes a single parameter which is the width of the envelope as it passes through the raw data. What this means is that if you have entered, say, 10 ms for the envelope width parameter, any given sample in the time series will be affected by the sample within a 10ms envelope either side of it. If this sounds too technical suffice to say that the lower the value the more “tight fitting” the envelope will be.

Furthermore, increasing the value will “smooth” the curve. There’s no way to determine a “perfect” value, so the best strategy is to experiment a bit – try to overlay the enveloped EMG using different parameter values (for example 10,20,30,40 and 50) and the raw EMG to get an idea of what the algorithm produces given different parameter values.

The default value is 25

You can create a new Polygon Report as a blank report or as a report based on a template. There are several ways to create a new blank report:

Create a Report from Data Management (Eclipse)

On the Home ribbon, click the Data Manager Button or press F2.

In the Data Manager, double-click the trial you want to add to the report.

Click the New Report button on the toolbar. A new report is added below the trial you selected.

Type a name for the report.

Double-click the report and click No when asked if you want to base the report on a template. A blank report is created.

Import data into the report.

Create a Report from within Polygon

On the Home ribbon, click the down arrow on the New button.

Or

From the Quick Access Bar above the Ribbon, click the down arrow on the New button.

Select Blank from the drop-down menu.

In the New Report dialog, browse to the location where you want to save the report.

In Report Name, enter a name for the report. Then click OK.

If you are creating the report in a new directory, click Yes to the prompt, Directory not found. Create? A blank report is created.

Creating a Report from a Template

Note: You will require a Polygon Template (.tpl file) available.

Use one of the above mentioned methods to create a blank report (when using the New button select template from the drop-down menu).

When asked if you want to base the report on a template click Yes.

In the window that opens, browse to the location of the template you want to use.

The Data Bar is empty until you import trial data (*.c3d files) that were processed in Vicon Nexus. Data can be imported from either the Data Manager (Eclipse) or the Home Ribbon. You can import a variety of files into Polygon reports, including web pages, videos, and more. Most files become panes within Polygon for which you can create hyperlinks. Files that you can import:

Import Data from Data Manager (Eclipse)

Open the report for which you want to import data or create a new report.

On the Home ribbon, click the Data Manager button or press F2.

With Data Manager still open, double-click on the trial name you want to add to the report.

The Trial will appear in the Data Bar

When you are finished, close the Data Manager.

Import Data from the Home Ribbon

Import File:

Open the report for which you want to import data or create a new report.

On the Home ribbon, click Import File.

In the Import File dialog, browse to the location of the c3d file you want to import.

Double click on the c3d file (In the drop-down you can filter the file types – optional).

The Trial will appear in the Data Bar.

Import Video:

Open the report for which you want to import data or create a new report.

On the Home ribbon, click Import Video.

In the Import File dialog, browse to the location of the .avi or .mpg file you want to import.

Double click on the file.

The Video will appear in the Data Bar.

Import Web Page:

Click the Home button on the Ribbon.

Click the Import Web Page button.

In the window that opens, enter the web page URL.

Click OK.

The web page opens in an HTML window in the Report Workspace. Web pages can be accessed by clicking Multimedia Files in the upper portion of the Data Bar. Then double-click the web page in the lower portion of the Data Bar

1. Make sure all analog and digital devices to be collected within Nexus are turned on. Wait at least 45 minutes after turning on the system to calibrate.

Please Note: Calibration should occur whenever cameras have had any movement.  Preferably, cameras are calibrated at least each day the system is used.

2. Open Nexus. All cameras will populate within the Systems tab automatically.

3. Select the appropriate System Configuration file for the data collection. Configured analog devices will populate under Devices. Add configured digital devices, right click on Devices > Add Digital Device and select the appropriate devices.

Verify analog/digital devices are set-up correctly.  For example, if there are any force plates, make sure the force vectors are correct.

4. Select all cameras and go to the Camera view. Verify all reflective material or markers have been removed from the volume. If a reflective area is unable to be removed, it will be masked.

5. Go to the Tools pane > System Preparation button > Mask Cameras. Select Start to mask the cameras. Existing masks will be removed and replaced with new masks.  Once all reflections are covered with a blue mask, select Stop.

6. Go to Calibrate Cameras and select Start. Nexus will begin calibration as the wand is moved throughout the volume. Once all cameras have recorded the wand for a specific number of frames Nexus will calculate feedback values.  Look at the Camera Calibration Feedback table to verify calibration was good.

7. Change the Camera view to 3D Perspective. Set the wand at the origin of the volume. Go to Set Volume Origin  > Start and then Set to position the cameras around the wand.

System preparation is now complete and you can move on to data capture.

1. Go to Data Management and make sure a Session folder has been created for the subject.

2. Go to the Resource pane > Subjects tab and create a new subject from a labeling skeleton.  The subject will be listed below with the associated labeling skeleton in parentheses.

3. Go to the Tools pane > Subject Preparation button for subject calibration. Have the subject stand in the middle of the volume in the base pose with all markers visible.  Select Start under Subject Calibration.  Only one good frame of data is needed.  Once a trial with all markers present has been captured select Stop.

Please Note: Workflow is intended for Plug-In Gait templates.  If using another you might need a Range of Motion calibration trial.

4. Nexus goes offline and opens the trial for immediate processing. Reconstruct the markers of the loaded trial. Run the AutoInitialize pipeline followed by Plug-in Gait Static to Calibrate the subject for labeling and Plug-in Gait.

Please Note: Check the accuracy of the marker labels (Hotkey: CTRL+Space) prior to running the calibration pipeline operations.

5. Save the Trial and Subject. Then go back online.

6. Dynamic Trials can now be collected. Select the Capture tab, go down to the Capture section and select Start to begin data collection.  Change the name of the trial from Subject Name Cal 02 to something that correlates with the data collection.

To take advantage of the new Nexus 2.x labeling algorithms a Nexus 2.x VST must be used.  If all you have is a Nexus 1.x VST, please remake the VST within Nexus 2.x.  If you would like instructions on this process, please contact Vicon Support.

Calibrating your subject allows Nexus to calculate subject-specific parameters with regards to the size of the subject and the exact placement of markers.  Calibration of the subject leads to better automatic labeling during Live capture and offline processing.  During subject calibration, subject-specific information is what enables a skeleton labeling template (VST) to be converted to a subject-specific labeling skeleton (VSK). If a VST is not calibrated to the subject then the subject markers will not label well, if at all.

The subject should be calibrated at the beginning of each capture session, not before each trial. You only need to recalibrate if the subject marker placement changes, for example, if a marker falls off, or if the markers are moved.

Aiming cameras is useful for providing an initial, approximate calibration, before you fully calibrate the cameras.

To utilize Aim Cameras you will want to have your cameras roughly positioned within the volume.  Create a Target Volume, from the Window > Options, with the dimensions of the ideal capture volume.  Once configured, place the wand in the center of the capture volume and go to a camera view.

While in the Aim Camera mode, physically move the Vicon camera in the capture volume and check its coverage against the Target Volume.

Please Note: The Target Volume within the camera view will only be displayed if all 5 wand markers are visible.  Thus the camera might need focusing in order to circle fit the wand markers.

For step by step instructions with visualizations on this process, please refer to the Aim Vicon Cameras section of the installed Nexus help.

When creating or modifying a template you will notice each marker has a Status property.  The Status of a marker is set to either Required, Optional or Calibration Only.  A marker status can affect the way a template reconstructs and labels.

Required: A required marker will need to be on the subject during the calibration trial as well as all dynamic trials

Calibration Only: These markers are used during the calibration trial and are then removed from the marker list for the dynamic trials.

Optional: If an optional marker is on the subject for calibration, Nexus will expect that marker to remain on the subject during all the dynamic trials.  If the marker is not present during calibration, the optional marker is removed from the marker list.

For all Legacy Installers please contact Vicon Support

Click Here: Search boujou FAQs

If the cameras continue to connect with the previous version of software but don’t in the latest version then the software is probably being blocked by the Windows Defender Firewall. Although Vicon officially specifies that the Firewall should be turned off completely to ensure unobstructed communication with the cameras and connectivity devices, sometimes institutional protocols mandate it to be turned on. If this is the case:

1. Go to Control Panel > Windows Defender Firewall and click on Allow an app or feature through Windows Defender Firewall.
2. Scroll down the list of applications to look for the instance of Vicon software (Vicon Nexus, Vicon Tracker, Vicon Shogun, Vicon Evoke).
3. Select the application and click Details to ensure it refers to the version you are trying to run.
4. Click on Change Settings to enable the networks (Domain, Private, Public) that match those of the previous version. If this option is disabled then please contact the system’s administrator or your institution’s IT personnel for assistance.
5. Click OK.
6. Restart the Vicon software.

If this does not resolve the issue then please contact Vicon Support.

Most settings for Nexus 2.x can be found in C:\Users\Public\Documents\Vicon\Nexus2.x\Configurations.  This includes, but is not limited to, pipelines, view options and monitors.  A few exceptions include:

1. Model Templates; These can be found here: C:\Users\Public\Documents\Vicon\Nexus2.x\ModelTemplates
2. ProCalc Schemes; These can be found here: C:\Users\Public\Documents\Vicon\Eclipse
3. Toolbar icons: C:\Users\<user name>\AppData\Roaming\Vicon\Nexus2.x\Configurations\Toolbars

Simply copy the files you require from the relevant folder on the processing computer and paste them in their corresponding folder on the new computer.

If you cannot find a setting or are having issues with this process, please contact Vicon Support.

By default, Polygon 4 will generate Gait Cycle Parameters and write them to the subject’s Analysis node. Perform the following steps to apply a trial’s Analysis Outputs to a Polygon 4 report.

1. Load the trial within a Polygon 4 report.
2. Go to the Data tab within the Data Bar.
3. Expand the Subject.
4. Right-click the Analysis node and click Properties.
5. Un-check Automatically Generate Parameters and click OK.
6. Right-click on the Trial node and click Update.
7. Expand the Subject node and click on the Analysis node.

The contents of the trial’s Analysis Outputs will be available now to include in the report. The settings will be saved within the report as well as a template created from the report. The trial’s Analysis Outputs will override the parameters generated by Polygon so combine the Gait Cycle Parameters, Gait Deviation Index, etc., run the Compute Gait Cycle Parameters operation within a Nexus pipeline to write them to the trial’s Analysis Outputs group.

Typically, this is due to subsets of cameras being well calibrated together and those subsets not agreeing enough with each other. This can cause reconstructions to be generated from each subset, quite close in position to each other.

Try to capture during the wand wave, plenty of frames where all cameras see the wand at the same time if possible. A good strategy is to wave the wand across the floor with LEDs facing vertically upwards.

If not all cameras, try to ensure that cameras on two or three adjacent walls or two opposing walls can collect wand frames at the same time.

Try to avoid only waving the wand close to the edge of the volume where only 2 or 3 cameras may see the wand at the same time.

Before you begin camera calibration, ensure that: Cameras have fully warmed up to a stable operating temperature. Vicon recommends a minimum 30–60 minute warm-up period.