Why doesn't Mobility Lab detect as many gait cycles as I expect?

Summary: To maximize the number of gait cycles that can be measured in your trials, use as long a walkway as possible.

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

  1. Still period detection
  2. Step detection
  3. Step validation
  4. Step 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 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 5 steps from each foot. This is done for each foot independently. If we cannot detect at least 5 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.

Note that even with a 15 foot walk way, you may only get one L->R->L->R step sequence before a turn is initiated. If the subject is walking fast or has a long stride, you might not get any. 7m (23ft) is the minimum walkway that Mobility Lab administrators should use for this reason. The longer and straighter the walkway the better, and the more times the subject walks up and down the walkway the better. The best thing that you can do to maximize the number of metrics that are reported is to increase the length of the walkway.
Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.