No announcement yet.

Historical gait data accuracy

  • Filter
  • Time
  • Show
Clear All
new posts

  • Historical gait data accuracy

    I was discussing this with a user recently and it was suggested that I should post this for the historical record. In the early days of clinical gait analysis I was often helping users set up gait labs, installing the original Vicon 3D motion capture systems, AMTI force plates, and MA100 systems that collected EMG and foot-switch data. Every configuration involved testing and verifying the lab data collection accuracy and once that was done, the labs would start collecting gait data for clinical research.
    Once the data was collected and analysed, I saw a few complaints from labs that the foot-switch data was not matching the force data, their heel switch always appeared to close before the heel hit the force plate. Everyone trusted the force plates so the analysis software was updated to adjust the foot-switch signal timing to synchronize the gait cycle foot switch data with the force plate data because the problem was seen as a foot-switch issue.
    Recently I was working with a lab user to help them verify their system accuracy and we saw a similar issue - we dropped a golf ball covered in reflective tape on the force plate, detecting the ball impact with a speaker connected to an EMG input and saw that the force data was being delayed slightly more than the EMG signal when both signals were compared with the golf ball trajectory. Trying to figure this out made me think about the days helping Dr Kadaba’s team install the Helen Hayes software in many labs; The initial lab installation always used the default AMTI filter setting of 1050Hz but when the Helen Hayes software was installed, the force plate filter settings were always changed to 10.5Hz which would have resulted in cleaner force plate data being delayed slightly and might explain why the heel foot-switch signal did not match the force plate Fz signal.
    I’m only writing this because I think might affect the historical records of normal gait data - I’m just reporting an issue that I’ve seen, I’m not saying that the original data is bad. Setting up the gait labs we had initially thought that we had verified the data collection accuracy, but we didn't realize that we needed to verify the working environment and always assumed that it was good until we saw the “foot-switch problem”.
    As a result, it might be a useful study for a user to verify their gait lab data collection accuracy and then repeat the original gait calculations and compare the results - hopefully verifying the historical data, or reporting any issues.
    Last edited by Edmund Cramp; October 13th, 2021, 10:36 AM.

  • #2
    That's fascinating!

    The 10.5 Hz low-pass filter for the force plate is not a bad idea, it matches closer to the low-pass filters used for kinematics, and helps prevent impact artifacts in the joint moments.

    But not a good idea to filter in real time (analog or digital) because this introduces a time lag in the signal. This is a good reminder to always record unfiltered data, so a zero-lag filter can be used off-line.

    With increasing interest in real-time analysis, we must be aware of this issue which really is inevitable in real-time applications. Joint moments and EMG envelope all require low pass filtering somewhere. As long as all signals are processed with the same real-time filter, at least they will have the same time lag.

    For reference the group delay and phase delay for a 2nd order Butterworth filter, at the low frequency limit, are both \(\tau = 1 / (\sqrt{2} \pi f_c)\), which for a 10.5 Hz filter would be 21 ms. Higher frequencies could be delayed up to 50% more. (I can post the full equations if anyone is interested).

    Did the golf ball test show delay times in that range?

    Ton van den Bogert


    • #3
      I just spent a while reviewing a lot of old force plate gait data (Heel marker and Fz) and it looks like the delays normally appear to be no more than one 3D frame (8, 16, or 20ms). It's worth remembering that the 3D marker sample rates are normally much lower than the analog sample rates. This can be a factor because the 3D impact accuracy is relative to the 3D sample rate when the marker is moving at 9.8 metres/second.
      One old ball-drop test showed the force data appearing about 20ms before the ball hit the plate when the test was performed at the end of the trial - a 3D/analog data synchronization issue that was resolved by the manufacturer afterwards. I was always been quite confident about the motion capture synchronization in the past because I had to demonstrate it when the labs were setup, but these days I see some significant delays in modern radio-telemetry based sensors so I would recommend that modern motion capture lab users consider always calibrating both the 3D volume and the data collection synchronization environment.