Welcome to Basics of Biomechanics, a series of blog posts covering foundational topics in the field using practical, data-driven examples. In this first post we look at the importance of knowing exactly where you are in your data timeline.
Biomechanical analysis involves the interpretation of time-varying signals measured during a physical activity of interest. Therefore, before we can interpret what we have measured we need to know precisely when it was measured during the activity. For example, in the video below we used a force plate system to record vertical ground reaction force during a test protocol consisting of two vertical countermovement jumps (note: the video unfortunately darkens to show the controls when you hover the mouse over it but if you move the mouse away the video is much brighter).
Challenge #1: without playing the video, can you identify the point on the force-time graph where the lowest vertical position (bottom of squat) occurs for the second jump? Play the video to see if you are right!
Notice that if we had not captured the video of the jump, it would be difficult to visually identify exactly when each point on the force-time graph on the left was happening in relation to the motion of the person. Clearly, video is a helpful tool to help us make visual sense of our measurements. We can use it to check that the protocol was followed correctly and corroborate our interpretations of the data. However, when we want to extract key features from our data it is often necessary to employ a more rigorous and systematic approach to segmenting our data timeline. This involves breaking the recorded activity down into very specific periods of time (phases). Each phase is a portion of time between two very specific points in time (events). For example, in our jump testing example we may be interested in extracting the peak force during the landing phase. But when exactly does the landing phase occur? How do we identify the events where it starts and ends? We can only identify an event if we have a robust functional definition for that event (what exactly it means in reality).
Challenge #2: go through the video of the jumps again and try to identify where you think the landing phases are on the timeline and why you think these definitions make sense. Try to think about how this relates to the force-time curve.
It is always good to give the events in your analysis intuitive, official names. Let us now assume the functional definition that our landing phase starts the moment one of the feet touches the ground after flight and call that “Contact”. We will also define the end of landing as the first moment the person returns to a stationary standing position after Contact and call this event “Stable”. Many biomechanical software packages make it possible to add these kinds of event labels into the data timeline so that we can store their time stamp values for later use in our processing pipeline. One method of doing this is manual tagging of the timeline via mouse, keyboard or touchscreen. If you are using video as your event reference, you will need to make a visual interpretation of where the events occur in the video based on their functional definitions. If you want to use a measured signal (such as force) to do manual tagging you need to first decide on a standard numerical interpretation.
Challenge #3: using the force-time curve as your event reference, what numerical (mathematical) interpretation of Contact and Stable would you use to manually tag the timeline in the video? Can you think of any testing situation or jump execution where your approach might lead to errors?
In the figure below, we show the two landing phases we detected on the measurement timeline (one for each jump). After this timing analysis, it is easy to find our desired outcome (the peak force) on the curve for each landing (green circles). However, consider a scenario in which you have a database of hundreds of jump recordings like this that need to be analysed. Manually tagging such a large number of timelines with events is tedious and could potentially be very costly as it is very time consuming and subject to human error. An alternative approach would be automated event detection which involves using computer algorithms to search for events within the measured signals using a specific numerical interpretation of the event definitions. In fact, we did this for the figure below using a custom built algorithm (programmed in Matlab) that operates on the force plate measurements, but many software packages also make event detection algorithms available in their user interface. To conclude our landing phase example, it is worth highlighting that whether you use automated event detection or manual tagging, it is important to understand and clearly communicate the event definitions and the interpretation used (because they can vary). Here Contact was interpreted as the first time the force value exceeded 20N after the flight phase and Stable was taken as the first time after Contact that the force varied by less than 5% of body weight within a 1-second leading sliding window. This is the level of detail required for clarity, especially in research studies.
As illustrated in the diagram below, more detailed time segmentation can be required when we record different protocols containing multiple repeated movements in a recording and where we identify multiple phases within each repeated movement. Recordings are data files stored on a device and each recording has a measurement timeline (similar to a video timeline). If there are multiple repeats of a movement, we first want to tag or detect them in the timeline and then identify the phases within them. Notice that for our jump analysis we have only one protocol consisting of two jump repeats, and that each jump repeat has its own three standard phases (loading, flight and landing). Also notice that the jump phases are continuous e.g. the loading and flight phase definitions both incorporate the take-off point, whereas the repeats are discontinuous (there is a rest period between jumps). This is different to other types of activities such as gait analysis where the repeats (gait cycles) are continuous (i.e. the end of one cycle is the start of the next cycle).
The measurement variable in our jump analysis example was non-sided (i.e. we analysed combined vertical force for both legs), and so our events and phases were non-sided (there was no left side loading phase or right side flight phase). In contrast, applications such as gait analysis often involve measurements of a specific side, e.g. left hip angles. Since left and right side movement during gait is also asynchronous, we use left side phases for left side measurements and right side phases for right side measurements. In the figure below you can see how the left and right gait cycles occur out of phase with each other. The gait cycle can be broken down into many more phases (e.g. double support, loading response etc.) but for the sake of illustration we have just kept to stance and swing (note: events are only shown here for one left and one right side gait cycle but occur throughout).
Segmenting your timeline with events and phases has some subtle benefits. For example, it is useful for data cleaning i.e. if you want to exclude a portion of a specific recording such as a bad jump repeat or a few gait cycles you can simply exclude the relevant events. There are also subtle challenges. Perhaps the most common is incorrect automated event detection – where the algorithm adds an event when it shouldn’t, misses an event or simply places an event too early or too late in the timeline – because these errors can go undetected if we do not somehow verify their results. Despite their massive advantage of speed, event detection algorithms can fail for various reasons and should therefore not be blindly trusted. Errors can occur due to deviations from the expected protocol or performance e.g. in reality the jumper looks stable after landing in the video but their force curve oscillated enough due to slight weight-shifting that the Stable event is not found. Similarly, some events might not always actually occur (perhaps the jumper stumbles and simply never reaches stability after the jump). When you find an event detection error, you then need to inspect the data and decide whether to exclude the phase or the entire repeat from your analysis, or whether to refine your algorithm and redo the detection. Another challenge is when your event definition and\or interpretation are not widely agreed upon within the literature. For example, there may be several interpretations of an event defined as “mid-stance” in running analysis (when peak force occurs, when the shank is vertical, halfway along the timeline into stance, etc.). In these cases it is important to know the different interpretations out there and to clearly communicate your choice.
Final challenge: can you think of some reasons why our numerical definitions of Contact and Stable make sense, or perhaps don’t make sense? Do you agree with the 20N threshold for Contact or the 5% threshold for Stable? Is our 1s sliding window too long or too short? And do you agree with the use of a leading window instead of a lagging or centered window? Please leave your comments below!
In conclusion, a solid grounding in the theory and practice of how to break down the data timeline is essential for biomechanics researchers and practitioners alike. Whether we use automated algorithms or manual methods, we need to be familiar with what the events and phases underlying our analysis mean and how they were identified. It is also helpful to implement quality control checks, such as visualizations of events and phases overlaid onto data plots as well as cross-referencing with video where possible, to give us confidence in our data processing and conclusions.
Very nice of the need to identify events in your data streams.