How can I maximize how many gait metrics are reported in a Walk trial?

Summary: To maximize the number of gait cycles that can be measured in your trials, use as long a straight walkway as possible. The shortest recommended walkway is 7m long, with turns executed past the ends of this walkway.

Overview: APDM's GaitTrack algorithm is designed to analyze steady-state gait. These are gait patterns where the subject is walking in a straight line on a relatively smooth, level surface. This is largely motivated by a design requirement to be able to compare "apples to apples" across different subject populations. Abnormal gait from, for example, subjects with movement disorders, can still be successfully analyzed with the GaitTrack algorithm. In fact, GaitTrack does a better job of analyzing abnormal gait relative to many other common algorithms that are focused on stereotypical movements such as midswing detection. Regardless, understanding GaitTrack's constraints and limitations can help you maximize the number of usable metrics that computed from your recordings.

There are four primary phases of Mobility Lab's GaitTrack algorithm

1. Still period detection
2. Stride detection
3. Stride validation
4. Stride sequencing
5. Metric computation

1) Still period detection: The GaitTrack algorithm requires the detection of at least one still period for each foot within the recording to estimate the bias and orientation of the sensors. The still period does not necessarily have to happen at the beginning of the trial, but the standard 3s countdown at the beginning of a trial where the subject is instructed to stand still is intended to serve this purpose.

2) Stride Detection: In order to provide gait metrics, Mobility Lab requires a minimum number of strides during a Walk trial or logged recording. A template matching approach is used for stride detection that requires at least 2 strides from each foot. This is done for each foot independently. If we cannot detect at least 2strides from each foot over the course of the whole trial, we return an error and do not report any gait metrics.

3) Stride Validation: Once all of the strides have been detected, they must pass certain validation criteria. For example, if the elevation of the foot is found to change significantly from one stride to the next, it is assumed that the subject was walking on an incline or stairs for that particular stride and it will not be used. For another example, if the stride is found to fall within a detected turn, it will not be used.

4) Stride sequencing: After stride validation, the algorithm matches the detected strides up into L->R sequences and discard ones that do not match defined timing criteria. In order to maximize the number of metrics that can be computed, it is desirable to put together long sequences of valid strides (L->R->L->R->L->...).

5) Metric Computation: Metrics can only be computed from L->R->L->R stride sequences (heel strike to heel strike) in order to capture both the L->R->L gait cycle and the R->L->R gait cycle . These are the "Valid" gait cycles that we report in the visual report immediately following a Walk trial, or the CSV export of the metric results.

6) Metric Thresholding: As a final step against reporting inaccurate values, each of the computed metrics are compared against minimum and maximum acceptable thresholds for that metric type. Any metric values that do not lie within the acceptable range will be discarded. These cases are rare, and may result from poor sensor placement (e.g., a sensor that is not fully secured to the foot) or possibly an algorithmic issue. An example of an "out of range" metric is a negative elevation at midswing.