Summary: To maximize the number of gait cycles that can be measured in your trials, use as long a straight walkway as possible. You should also encourage a pivot turn at the end of the walkway, instead of a longer turn around a fixed object (e.g., a cone), to minimize the number of steps that overlap the turn event.
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 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
- Still period detection
- Step detection
- Step validation
- Step sequencing
- 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 these sensors. The still period does not necessarily have to happen at the beginning of the trial, but the 3s countdown at the beginning of a trial where the subject is instructed to stand still is intended to serve this purpose.
2) Step Detection: In order to provide gait metrics, Mobility Lab requires a minimum number of steps during a Walk trial or logged recording. A template matching approach is used for step detection that requires at least 2 steps from each foot. This is done for each foot independently. If we cannot detect at least 2 steps from each foot over the course of the whole trial, we return an error and do not report any gait metrics.
3) Step Validation: Once all of the steps have been detected, they must pass certain validation criteria. For example, if the elevation of the foot is found to change significantly from one step to the next, it is assumed that the subject was walking on an incline or stairs for that particular step and it will not be used. For another example, if the step is found to fall within a detected turn, it will not be used.
4) Step sequencing: After step validation, the algorithm matches the detected steps 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 steps (L->R->L->R->L->...).
5) Metric Computation: Metrics can only be computed from L->R->L->R step 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.