A Wearable System for the Estimation of Performance-Related Metrics during Running and Jumping Tasks

: Athletic performance, technique assessment, and injury prevention are all important aspects in sports for both professional and amateur athletes. Wearable technology is attracting the research community’s interest because of its capability to provide real-time biofeedback to coaches and athletes when on the ﬁeld and outside of more restrictive laboratory conditions. In this paper, a novel wearable motion sensor-based system has been designed and developed for athletic performance assessment during running and jumping tasks. The system consists of a number of components involving embedded systems (hardware and software), back-end analytics, information and communications technology (ICT) platforms, and a graphical user interface for data visualization by the coach. The system is able to provide automatic activity recognition, estimation of running and jumping metrics, as well as vertical ground reaction force (GRF) predictions, with sufﬁcient accuracy to provide valuable information as regards training outcomes. The developed system is low-power, sufﬁciently small for real-world scenarios, easy to use, and achieves the speciﬁed communication range. The system’s high sampling rate, levels of accuracy and performance enables it as a performance evaluation tool able to support coaches and athletes in their real-world practice.


Introduction
Athletic performance, technique assessment, and injury prevention are all aspects of great importance in sports at present, for coaches and athletes alike, and are experiencing a growth in interest from the research community.As a consequence, the development of automated, objective, and reliable performance monitoring and evaluation systems, through quantitative analyses of performance variables, is now seen as an essential tool for the improvement of athletic performance and the minimization of injury risk [1,2].
Wearable sensors represent an alternative to gold-standard lab-based assessments because of their potential to monitor performance without hindering it while providing real-time feedback with no space limitation or infrastructure set-up procedures, as well as their advantages in the areas of portability, low-cost, and ease-of-use [3][4][5].For instance, wearable technology may be used to estimate temporal (e.g., stride time), kinematic (e.g., joint range of motion), and dynamic parameters (e.g., joint forces and moments), as well as motor capacity, workload, and technique, in a number of sport tasks (e.g., swimming, running, team sports, jumping, and strength assessment) [6].
However, few studies have investigated the possibility of combining those disciplines to support coaches in predicting and minimizing injuries [7].For example, running-related injuries have a complex and multifactorial etiology that is also dependent on aberrant biomechanics and training load errors [8].Wearables, therefore, can provide important insights into the kinetics potentially responsible for injurious tissue loads, as well as indicate the effectiveness of an intervention [8].Thus, coaches' decision-making can be greatly enhanced by the use of wearable sensors to ensure that a biomechanical intervention is truly helping the athletes by minimizing the risk of running-related injuries [8].
In coaching practice, sport-specific activities (such as change-of-direction), jumping, running, and sprinting tasks are largely adopted for athletic performance evaluation [9,10] in a number of sports, e.g., soccer, rugby, etc.For example, it is common to examine jumps before and after training to assess the effectiveness of a specific intervention [11].Nevertheless, only a limited number of solutions, both in literature and on the market (for example, Xybermind [12]), have been developed to tackle most of the scenarios sport coaches deal with, with the majority of them merely targeting an automatic classification of different sport activities [13] and their intensity [14].
Running and running-related injuries have been widely investigated through the use of wearable sensors [15][16][17], typically considering spatio-temporal variables such as cadence, contact and swing time, stride length, symmetry, and so on.Nevertheless, loading and related metrics, with particular reference to the vertical ground reaction force (GRF), are also gaining the researchers' attention [18] because of their high correlation with tibial shock and stress injuries in runners [8].A number of papers have shown that GRF waveforms could be estimated effectively via neural networks [19][20][21][22][23][24] with superior results compared to biomechanical modeling, as demonstrated in a recent comparative study [25].
On the other hand, jumping tasks have also been extensively studied using wearable technology [26][27][28].However, many of those investigations generally focused on correctly estimating temporal events (e.g., take-off, landing), jump height, and flight time.
Given that the application of wearable sensors will revolutionize exercise science research because of their portability and capability of collecting a multitude of movement data, research in the area will be facilitated by the development of a meaningful solution able to identify and provide insights based on the analysis of a substantial amount of data collected [29].The aim of the present work is, therefore, to develop a complete integrated solution that could be used by coaches while athletes are performing running and jumping tasks for monitoring performance and evaluate possible injury risks.The objectives of the investigation are, therefore, many-fold:

•
To develop a wearable solution based on inertial measurement units (IMUs) which could be worn on different body locations and are suitable for different physical tasks;

•
To automatically detect every individual jump performed, as well as segment the running bouts and, as a consequence, each running stride from both legs; • To provide running performance metrics from the data recorded by the IMUs, such as contact time, step time, mean force, stability, cadence, etc.;

•
To provide vertical GRF waveforms for each segmented running stride for both legs and extrapolate the associated metrics;

•
To provide jumping metrics from the kinematics recorded by IMU, including flight time, jump height, peak force, mean force, etc., and for the different phases of the jump (eccentric and concentric); To provide an easy-to-use graphical interface for an effective visualization of the estimated variables.
The achievement of all these objectives will allow the development of a complete wearable solution that coaches and athletes could use in their real-world practice, which represent the ultimate goal of this work.The manuscript is organized as follows.The proposed system architecture is discussed in Section 2, while the hardware and the software components of the system are illustrated in Sections 3 and 4, respectively.The graphical interface is shown in Section 5. Testing and results are discussed in Section 6.A state-ofthe-art comparison with products on the market is illustrated in Section 7. Final discussion and conclusions are illustrated in Sections 8 and 9, respectively.

System Architecture
The system has been built to provide performance-related metrics based on the scenario where jumping tests are performed before and after training, and running is the main activity performed during training, as it generally occurs in sports such as soccer or rugby.While running, the system relies on two wirelessly synchronized boards located on the left and right shanks; on the other hand, only one device worn on the pelvis is required for jumping (Figure 1).The pelvis was preferred over the shank for the prediction of jumping forces since the sensor would be mounted closer to the subjects' center of mass, while the estimation of the total impact force would be unaffected by asymmetrical landings between the left and right foot.Adjustable Velcro straps are used in both cases for attachment to the athlete under test.The athlete can, therefore, use the same boards between activities by simply placing the boards on different body locations.This approach minimizes the number of devices simultaneously worn, which is never more than two units.The boards can perform in a number of modes (i.e., "USB", "running", or "jumping") depending on the number of times a touch button is pressed by the user.This control feature is also used for starting and stopping the collection of data which is stored internally on an SD memory card for post-processing.Whenever a device operates in "USB" mode, it can also be plugged in any computer able to read USB mass storage drives.
Complex back-end analytics, including activity recognition algorithms to automatically separate the time segment of interest for the analysis, are used separately on a computer to provide the various metrics requested for the different activities based on the data stored on the plugged-in device.A graphical user interface (GUI) has been developed and integrated in the system to visualize, export and save the results of the analysis and to allow coaches and athletes to interact with the system.A graphical depiction of the system adoption is shown in Figure 2. interface is shown in Section 5. Testing and results are discussed in Section 6.A state-ofthe-art comparison with products on the market is illustrated in Section 7. Final discussion and conclusions are illustrated in Sections 8 and 9, respectively.

System Architecture
The system has been built to provide performance-related metrics based on the scenario where jumping tests are performed before and after training, and running is the main activity performed during training, as it generally occurs in sports such as soccer or rugby.While running, the system relies on two wirelessly synchronized boards located on the left and right shanks; on the other hand, only one device worn on the pelvis is required for jumping (Figure 1).The pelvis was preferred over the shank for the prediction of jumping forces since the sensor would be mounted closer to the subjects' center of mass, while the estimation of the total impact force would be unaffected by asymmetrical landings between the left and right foot.Adjustable Velcro straps are used in both cases for attachment to the athlete under test.The athlete can, therefore, use the same boards between activities by simply placing the boards on different body locations.This approach minimizes the number of devices simultaneously worn, which is never more than two units.The boards can perform in a number of modes (i.e., "USB", "running", or "jumping") depending on the number of times a touch button is pressed by the user.This control feature is also used for starting and stopping the collection of data which is stored internally on an SD memory card for post-processing.Whenever a device operates in "USB" mode, it can also be plugged in any computer able to read USB mass storage drives.
Complex back-end analytics, including activity recognition algorithms to automatically separate the time segment of interest for the analysis, are used separately on a computer to provide the various metrics requested for the different activities based on the data stored on the plugged-in device.A graphical user interface (GUI) has been developed and integrated in the system to visualize, export and save the results of the analysis and to allow coaches and athletes to interact with the system.A graphical depiction of the system adoption is shown in Figure 2.  interface is shown in Section 5. Testing and results are discussed in Section 6.A state-ofthe-art comparison with products on the market is illustrated in Section 7. Final discussion and conclusions are illustrated in Sections 8 and 9, respectively.

System Architecture
The system has been built to provide performance-related metrics based on the scenario where jumping tests are performed before and after training, and running is the main activity performed during training, as it generally occurs in sports such as soccer or rugby.While running, the system relies on two wirelessly synchronized boards located on the left and right shanks; on the other hand, only one device worn on the pelvis is required for jumping (Figure 1).The pelvis was preferred over the shank for the prediction of jumping forces since the sensor would be mounted closer to the subjects' center of mass, while the estimation of the total impact force would be unaffected by asymmetrical landings between the left and right foot.Adjustable Velcro straps are used in both cases for attachment to the athlete under test.The athlete can, therefore, use the same boards between activities by simply placing the boards on different body locations.This approach minimizes the number of devices simultaneously worn, which is never more than two units.The boards can perform in a number of modes (i.e., "USB", "running", or "jumping") depending on the number of times a touch button is pressed by the user.This control feature is also used for starting and stopping the collection of data which is stored internally on an SD memory card for post-processing.Whenever a device operates in "USB" mode, it can also be plugged in any computer able to read USB mass storage drives.
Complex back-end analytics, including activity recognition algorithms to automatically separate the time segment of interest for the analysis, are used separately on a computer to provide the various metrics requested for the different activities based on the data stored on the plugged-in device.A graphical user interface (GUI) has been developed and integrated in the system to visualize, export and save the results of the analysis and to allow coaches and athletes to interact with the system.A graphical depiction of the system adoption is shown in Figure 2.  Graphical depiction of the system adoption.After data collection for a specific task, the device(s) are plugged-into a computer via USB, where a GUI will use back-end algorithms to process the data gathered in the device(s) and visualize the results to the end-users.

Hardware Design
The following section deals with the design and development of the hardware components of the proposed wearable system for performance assessment in sport tasks.

Hardware Platform
The requirements of the developed wearable solution involved the ideation of a system easy to use and to wear, requiring no physical connection between the two devices placed on the legs, while the units must exchange information wirelessly and allow easy access to the data from a computer.For this purpose, two identical boards were developed and designed to be autonomous from each other in terms of power supply and computational perspectives.When the units are located on the shanks while running, they store inertial data, which are wirelessly synchronized to each other by keeping the two devices connected with a constant wireless Bluetooth connection.
In addition, both units can work in a stand-alone asynchronous mode in order to analyze jumping tasks.In this case, the user can choose either of the two devices and use it to record and analyze the jumping activity.
Each board consists of a number of building blocks.Overall, the microcontroller is the main component of the system as it deals with the motion sensors, the wireless communication, the power management, the memory for data storage, and the computer interface to guarantee access to the files stored in the memory card for post processing.The microcontroller selected is the STM32F417IG from STMicroelectronics [30] as it offers low-power operations and high-performance by relying on an ARM ®® Cortex ®® -M4-based 32 bit architecture, with a single precision floating point unit, and an operating frequency of up to 168 MHz, and up to 1MB of Flash and 196 Kbytes of RAM.The board also includes a 9 DoF IMU (MPU-9250 from InvenSense [31]) connected to the microcontroller via I2C interface, with ranges of 16 g and 2000 dps for the accelerometer and the gyroscope, respectively.However, a magnetometer was not adopted due to the impact that magnetic interferences may have on the measurements.As recommended by the manufacturer, the IMU calibration process relied on the IMU's on-chip factory-trimmed scale factors to eliminate the need of an end-user calibration.The wireless communication is based on the BLE 5.0 protocol implemented on the "NRF52840" BLE 5.0 module from Nordic [32] and the associated ceramic chip antenna ACAG0801-2450-T from Abracon ®® [33].A microSD card reader is included for storing data on-board and is directly connected to the microcontroller with the SDIO (secure digital input output) card interface.A 604040 Li-ion battery (1100 mAh) is also included, which can be recharged through a type-C USB connection.Finally, a touch button is used to interact with each device, along with four LEDs for user feedback.Figure 3 shows the block diagram of the system, while Figure 4 illustrates the designed PCB board and the 3D printed plastic enclosure used to fit the electronics.

Hardware Operations
The touch button on the board is used to switch the device ON, which after some preliminary checks (e.g., SD card successfully mounted) enters into "USB" mode.The "USB" mode is a standby mode allowing communication between a computer and the devices over a wired connection.In order to avoid errors in the stored data files, only when the device is in "USB" mode is the user allowed to switch the device OFF, to connect to a computer, or to switch to "running" or "jumping" modes.
If two units are required for the analysis of running tasks (e.g., "running" mode), then a double tap on the touch button of both devices (while the devices are in "USB" mode) will switch the units ON and start wirelessly scanning for other nearby devices.

Hardware Operations
The touch button on the board is used to switch the device ON, which after some preliminary checks (e.g., SD card successfully mounted) enters into "USB" mode.The "USB" mode is a standby mode allowing communication between a computer and the devices over a wired connection.In order to avoid errors in the stored data files, only when the device is in "USB" mode is the user allowed to switch the device OFF, to connect to a computer, or to switch to "running" or "jumping" modes.
If two units are required for the analysis of running tasks (e.g., "running" mode), then a double tap on the touch button of both devices (while the devices are in "USB" mode) will switch the units ON and start wirelessly scanning for other nearby devices.The devices are worn with the touch button on the top side (Figure 4, right).When running, the devices are worn on the external side of the shanks, at approximately two thirds of the lower leg height.For jumping, a unit must be worn as close as possible to the center-of-mass on the lower back.
The developed hardware platform measures 50 mm × 90 mm × 10 mm and weighs 40 g (battery included).The sampling rate is set at 238 Hz and the achieved throughput is 1 Mbps with a communication range greater than 10 m in a NLOS (non-line-of-sight) scenario.The high sampling rate was required to accurately estimate GRF data in highly dynamic movements, as indicated in [34], which highlighted the need to adopt sampling rates higher than 200 Hz for these tasks.The power consumption is less than 100 mA (250 mW) and the system can operate continuously for more than 4 h.The full-battery charging time is 2-3 h.

Hardware Operations
The touch button on the board is used to switch the device ON, which after some preliminary checks (e.g., SD card successfully mounted) enters into "USB" mode.The "USB" mode is a standby mode allowing communication between a computer and the devices over a wired connection.In order to avoid errors in the stored data files, only when the device is in "USB" mode is the user allowed to switch the device OFF, to connect to a computer, or to switch to "running" or "jumping" modes.
If two units are required for the analysis of running tasks (e.g., "running" mode), then a double tap on the touch button of both devices (while the devices are in "USB" mode) will switch the units ON and start wirelessly scanning for other nearby devices.During the scanning time (90 s), both devices apply the synchronization protocol described in Section 3.3.If 90 s elapse with no other device found, the unit will automatically switch OFF.The synchronization protocol allows the boards to start the recording of the inertial data simultaneously, with the time-synchronized data being stored on the SD cards.During data recording, the user can tap the touch button of either board twice and automatically stop the data capture for both units at the same time, forcing the units to switch back to "USB" mode.
Alternatively, when a single unit is required for the monitoring of jumping tasks (e.g., "jumping" mode), then a double tap on the touch button of the device, currently in "USB" mode, followed a few seconds later by the user tapping the touch button twice, will start recording data on a single unit.Again, while the device is recording, the user can stop the data collection at any moment by tapping the touch button three times which forces the unit to switch back to "USB" mode.Pressing the touch button for six seconds will switch the device OFF at any moment.

Wireless Synchronization Protocol
Before recording a running task, it is required that the two units be within the BLE communication range and in-synch with each other.A flowchart of the synchronization protocol is shown in Figure 5.During the scanning time (90 s), both devices apply the synchronization protocol described in Section 3.3.If 90 s elapse with no other device found, the unit will automatically switch OFF.The synchronization protocol allows the boards to start the recording of the inertial data simultaneously, with the time-synchronized data being stored on the SD cards.During data recording, the user can tap the touch button of either board twice and automatically stop the data capture for both units at the same time, forcing the units to switch back to "USB" mode.Alternatively, when a single unit is required for the monitoring of jumping tasks (e.g., "jumping" mode), then a double tap on the touch button of the device, currently in "USB" mode, followed a few seconds later by the user tapping the touch button twice, will start recording data on a single unit.Again, while the device is recording, the user can stop the data collection at any moment by tapping the touch button three times which forces the unit to switch back to "USB" mode.Pressing the touch button for six seconds will switch the device OFF at any moment.

Wireless Synchronization Protocol
Before recording a running task, it is required that the two units be within the BLE communication range and in-synch with each other.A flowchart of the synchronization protocol is shown in Figure 5.The first device ("Device1") starts searching for a pairing device ("Device2"), which is in turn waiting for a time synchronization request.Three stages of command (CMD) exchange, as shown in the graphical description in Figure 6, are required before the devices are ready for data recording: The first device ("Device1") starts searching for a pairing device ("Device2"), which is in turn waiting for a time synchronization request.Three stages of command (CMD) exchange, as shown in the graphical description in Figure 6, are required before the devices are ready for data recording: 1.
Set-up: Device1 sends a time_synchronization_request and waits for the Device2 set-up.

2.
Device2 time synchronization: this phase starts when Device1 sends the CMD_Step1 command (at time t 1d1 ) to Device2 which is received at time t 1d2 = t 1d1 + δt (δt is the time required for the command to be transmitted between the two devices).

3.
Device1 time synchronization: after that CDM_Step1 is processed by Device2 (which requires a time slot x), this phase starts when Device2 sends the CMD_Step2 command (at time t 2d2 = t 1d2 + x) to Device1.Device1 then receives CMD_Step2 at time Data recording: after that CDM_Step2 is processed by Device1 (which requires another time slot x), this phase starts when Device1 sends the CMD_Step3 command (at time t 3d1 = t 2d1 + x) to Device2, and then starts immediately the data recording.Device2 receives CMD_Step3 at time t 3d2 = t 3d1 + δt and after processing the received packet starts the data recording.
Following this process, the post-processing analysis embedded in the back-end analytics estimates the time difference between t 3d1 and t 3d2 to re-align the two data streams.If for some reason (i.e., packet loss) the synchronization process is not successful during the command exchange (e.g., one device does not receive a reply by 60 s) both boards automatically switch OFF.
Finally, when the user taps the touch button of one device twice to complete the data collection, the device sends a stop command to the pairing device and the recording is terminated in both units.
In summary, the time synchronization procedure is required to temporally align the timestamps in the two boards, while considering that the clock of the boards may be slightly shifted.This process is essential in order to calculate running metrics which are dependent from an accurate estimation of the temporally synchronised gait events in both left and right legs.As indicated in [35], the efficient time-synchronization of a multi-unit, multisensor acquisition system for kinematic and static analysis is still considered a challenge in research, given the requirement to ensure a strict time synchronization between all the units to guarantee correct parameter estimation, and with off-the-shelf solutions requiring extra non-portable and complex hardware or without specifying details on the achieved accuracy.
It is worth underlining that in the developed protocol both units can act as "Device1" or "Device2" and those labels are not hard-wired: the label "Device1" is automatically assigned to the unit starting the synchronization communication, while the second unit is thus labeled "Device2".As a result, the labels "Device1" or "Device2" could be swapped between the two units during different running data collections.

Data Processing and Algorithms
The following sections deal with the description of the offline data post-processing and the implemented algorithms in the proposed wearable system.As the magnetometer is not considered in this system, no orientation has been calculated from the IMU and, thus, only raw accelerometer and gyroscope data in the local reference frame are used in all analyses.

Running Activity Recognition
Even after the devices' synchronization, it is essential to separate the collected inertial data into windows corresponding to the tasks of interest.This is particularly vital since each recording during a training trial may contain data from activities other than running, such as standing or walking.Therefore, a method able to detect the required activities and separate the corresponding windows of data was implemented based on the works by Olivares et al. [36].
In detail, the implemented algorithm uses the sagittal angular rate collected during a data capture and splits that signal in small windows of 0.5 s of length.Then, the variance of the signal in each of these windows is computed and if the obtained value is above or below a predefined threshold then the window is accordingly marked as active or inactive.
Finally, the process finds all the sequences of consecutive windows marked as active, and if the total duration of each active sequence is longer than a specific time threshold (for running the threshold was set to 20 s), then that sequence is recognized as a running trial; otherwise, the algorithm skips that sequence and checks the following one.Figure 7 demonstrates an example of the employed algorithm.

Data Processing and Algorithms
The following sections deal with the description of the offline data post-processing and the implemented algorithms in the proposed wearable system.As the magnetometer is not considered in this system, no orientation has been calculated from the IMU and, thus, only raw accelerometer and gyroscope data in the local reference frame are used in all analyses.

Running Activity Recognition
Even after the devices' synchronization, it is essential to separate the collected inertial data into windows corresponding to the tasks of interest.This is particularly vital since each recording during a training trial may contain data from activities other than running, such as standing or walking.Therefore, a method able to detect the required activities and separate the corresponding windows of data was implemented based on the works by Olivares et al. [36].
In detail, the implemented algorithm uses the sagittal angular rate collected during a data capture and splits that signal in small windows of 0.5 s of length.Then, the variance of the signal in each of these windows is computed and if the obtained value is above or below a predefined threshold then the window is accordingly marked as active or inactive.
Finally, the process finds all the sequences of consecutive windows marked as active, and if the total duration of each active sequence is longer than a specific time threshold (for running the threshold was set to 20 s), then that sequence is recognized as a running trial; otherwise, the algorithm skips that sequence and checks the following one.Figure 7 demonstrates an example of the employed algorithm.

Running-Related Metrics and Vertical GRF
Following running activity detection, the recorded accelerometry data associated with the running sequences are filtered with a low-pass, second order, zero-phase shift Butterworth filter with cut-off frequencies of 15 Hz, as performed in [24].The angular velocity was used for the detection of the gait events (heel-strike and toe-off), as presented in [37].Accelerations were scaled to 100 samples from heel-strike to toe-off (100% of stance phase).
The prediction of the vertical GRFs is performed with the development of an artificial neural network (ANN).The developed regression model is fed with the vertical local component of the IMUs' acceleration signal (e.g., shank's longitudinal acceleration) and is trained to estimate the vertical GRF component in the global frame.The developed regression ANN (Figure 8) consisted of three layers, with the input layer composed of 100 neurons, a hidden layer of 10 neurons (with tanh as activation function, and dropout regularization), and an output layer of 100 linear neurons.Further details on the ANN model developed are available in [23,24].
Finally, based on the recorded acceleration signals and the GRF predictions, a series of running metrics is calculated for each recorded trial.All reported metrics are the average of all stances that are included on each recording, apart from the total force metric.Additionally, every metric is calculated for each leg separately, apart from cadence and asymmetry.The considered metrics are as follows:


Num. Contacts: number of stances in each trial as determined by the event detection algorithm  Contact time: average stance time of all recorded steps in milliseconds  Swing time: average time between toe-off and heel-strike for each leg in milliseconds  Step time: average time between heel-strikes for each leg in milliseconds  Cadence: number of steps per minute (steps/min)  Peak time: average time of the maximum force, expressed as percentage of the stance phase

Running-Related Metrics and Vertical GRF
Following running activity detection, the recorded accelerometry data associated with the running sequences are filtered with a low-pass, second order, zero-phase shift Butterworth filter with cut-off frequencies of 15 Hz, as performed in [24].The angular velocity was used for the detection of the gait events (heel-strike and toe-off), as presented in [37].Accelerations were scaled to 100 samples from heel-strike to toe-off (100% of stance phase).
The prediction of the vertical GRFs is performed with the development of an artificial neural network (ANN).The developed regression model is fed with the vertical local component of the IMUs' acceleration signal (e.g., shank's longitudinal acceleration) and is trained to estimate the vertical GRF component in the global frame.The developed regression ANN (Figure 8) consisted of three layers, with the input layer composed of 100 neurons, a hidden layer of 10 neurons (with tanh as activation function, and dropout regularization), and an output layer of 100 linear neurons.Further details on the ANN model developed are available in [23,24].
Finally, based on the recorded acceleration signals and the GRF predictions, a series of running metrics is calculated for each recorded trial.All reported metrics are the average of all stances that are included on each recording, apart from the total force metric.Additionally, every metric is calculated for each leg separately, apart from cadence and asymmetry.The considered metrics are as follows:

•
Num. Contacts: number of stances in each trial as determined by the event detection algorithm • Contact time: average stance time of all recorded steps in milliseconds • Swing time: average time between toe-off and heel-strike for each leg in milliseconds • Step time: average time between heel-strikes for each leg in milliseconds Total force: sum of the peak forces of all stances, expressed in BW • Asymmetry: average absolute error between the force peaks of both legs in all stances as a percentage [38].Values closer to 0 indicate stronger symmetry in movements • Stability: absolute error between the GRF of two consecutive stances expressed as a percentage, and averaged over all the steps [39].Again, values closer to 0 indicate better stability • Fatigue: a dimensionless coefficient which is calculated as the slope of the linear regression line that fits the angular rate at the mid-swing events over all gait cycles [40].Total force: sum of the peak forces of all stances, expressed in BW  Asymmetry: average absolute error between the force peaks of both legs in all stances as a percentage [38].Values closer to 0 indicate stronger symmetry in movements  Stability: absolute error between the GRF of two consecutive stances expressed as a percentage, and averaged over all the steps [39].Again, values closer to 0 indicate better stability  Fatigue: a dimensionless coefficient which is calculated as the slope of the linear regression line that fits the angular rate at the mid-swing events over all gait cycles [40].

Jumping Activity Recognition and Event Detection
Similar to the running trials detection, a targeted algorithm was developed for the activity recognition of the jumping tasks.Jumping events and performance parameters were calculated solely using the acceleration and angular rates of a single IMU placed on the subject's pelvis.Countermovement and squat jumps were considered in this work.When a jump is detected, the acceleration signal is double integrated with respect to time, resulting in the computation of the body's center-of-mass velocity and position in three dimensions with respect to the local reference system.Specifically, for event detection, the proposed approach utilized both the vertical accelerations and sagittal angular rates recorded by the IMUs during data capture.The algorithm initially searches for the peaks of the linear acceleration signal which correspond to the landing of each separate jump.Subsequently, changes in variance in the angular rates are used to detect the initiation of the eccentric and concentric phases.In more detail, the start of the eccentric phase is identified as the time at which the variance of the sagittal angular rate is higher than a predefined threshold.The start of the concentric phase is, alternatively, identified as the time at which the velocity changed sign from negative to

Jumping Activity Recognition and Event Detection
Similar to the running trials detection, a targeted algorithm was developed for the activity recognition of the jumping tasks.Jumping events and performance parameters were calculated solely using the acceleration and angular rates of a single IMU placed on the subject's pelvis.Countermovement and squat jumps were considered in this work.When a jump is detected, the acceleration signal is double integrated with respect to time, resulting in the computation of the body's center-of-mass velocity and position in three dimensions with respect to the local reference system.Specifically, for event detection, the proposed approach utilized both the vertical accelerations and sagittal angular rates recorded by the IMUs during data capture.The algorithm initially searches for the peaks of the linear acceleration signal which correspond to the landing of each separate jump.Subsequently, changes in variance in the angular rates are used to detect the initiation of the eccentric and concentric phases.In more detail, the start of the eccentric phase is identified as the time at which the variance of the sagittal angular rate is higher than a predefined threshold.The start of the concentric phase is, alternatively, identified as the time at which the velocity changed sign from negative to positive, which also corresponds with the instant when the change in the displacement becomes positive.
Additionally, take-off is identified as the first local minimum of the acceleration after the absolute maximum of the velocity signal, corresponding to the time just before take-off.Landing is identified as the previous local minimum in acceleration with respect to the absolute maximum in the force, corresponding to the time just after landing.The phases and event detection definitions are taken from Cormie et al. [41].
Finally, the type of jump is also recognized: if the time between the initiation of the movement and landing is shorter than three seconds, then the task is identified as a countermovement jump, otherwise it is identified as a squat jump.The threshold was set at three seconds since, generally, when performing a squat jump, athletes are required to maintain the squat position for at least 1-2 s. Figure 9 shows an example of the implemented algorithm for the jumping task recognition.Following the jump task recognition, the algorithm proceeds in the detection of the temporal events (take-off, landing, etc.) for each separate jump.Figure 10 shows an example of the result of the event detection as performed by the algorithm.positive, which also corresponds with the instant when the change in the displacement becomes positive.Additionally, take-off is identified as the first local minimum of the acceleration after the absolute maximum of the velocity signal, corresponding to the time just before takeoff.Landing is identified as the previous local minimum in acceleration with respect to the absolute maximum in the force, corresponding to the time just after landing.The phases and event detection definitions are taken from Cormie et al. [41].
Finally, the type of jump is also recognized: if the time between the initiation of the movement and landing is shorter than three seconds, then the task is identified as a countermovement jump, otherwise it is identified as a squat jump.The threshold was set at three seconds since, generally, when performing a squat jump, athletes are required to maintain the squat position for at least 1-2 s. Figure 9 shows an example of the implemented algorithm for the jumping task recognition.Following the jump task recognition, the algorithm proceeds in the detection of the temporal events (take-off, landing, etc.) for each separate jump.Figure 10 shows an example of the result of the event detection as performed by the algorithm.

Jumping-Related Metrics
Following the activity and event detection, jumping metrics can be calculated for each jump.In particular, the force curve is obtained as the product of the vertical acceleration of the pelvis and the mass of the subject.The velocity curve is calculated as the time integral of the vertical acceleration of the pelvis, while the displacement curve is estimated as the time integral of the velocity signal.The power curve, finally, results as the product of the estimated force and velocity.
The peak force and peak power at the concentric and eccentric phases are defined as

Jumping-Related Metrics
Following the activity and event detection, jumping metrics can be calculated for each jump.In particular, the force curve is obtained as the product of the vertical acceleration of the pelvis and the mass of the subject.The velocity curve is calculated as the time integral of the vertical acceleration of the pelvis, while the displacement curve is estimated as the time integral of the velocity signal.The power curve, finally, results as the product of the estimated force and velocity.
The peak force and peak power at the concentric and eccentric phases are defined as the corresponding maximum metrics between the initiation and the end of the two phases.The peak force at landing corresponds to the overall maximum estimated force.Velocities at take-off and landing correspond to the estimated velocities at the two events, whereas flight time is the time between the landing and take-off events.Finally, jump height is obtained from the flight time using the formula discussed in [42] (Equation ( 1), where t FLIGHT is the time flight and g the gravitational acceleration).Figure 11 shows an example of the comparison between the actual and the modeled force curves during a jump.height = g × t FLIGHT 2 /8 (1) Figure 10.Example of event detection from the accelerometer in a countermovement jump.Force (blue), velocity (red), and displacement (green) curves are plotted and manually scaled to be shown in the same graph.

Jumping-Related Metrics
Following the activity and event detection, jumping metrics can be calculated for each jump.In particular, the force curve is obtained as the product of the vertical acceleration of the pelvis and the mass of the subject.The velocity curve is calculated as the time integral of the vertical acceleration of the pelvis, while the displacement curve is estimated as the time integral of the velocity signal.The power curve, finally, results as the product of the estimated force and velocity.
The peak force and peak power at the concentric and eccentric phases are defined as the corresponding maximum metrics between the initiation and the end of the two phases.The peak force at landing corresponds to the overall maximum estimated force.Velocities at take-off and landing correspond to the estimated velocities at the two events, whereas flight time is the time between the landing and take-off events.Finally, jump height is obtained from the flight time using the formula discussed in [42] (Equation ( 1), where tFLIGHT is the time flight and g the gravitational acceleration).Figure 11 shows an example of the comparison between the actual and the modeled force curves during a jump.height = g × tFLIGHT 2 /8 (1)

Graphical User Interface (GUI)
A GUI was developed with the two-fold objectives of allowing the end-users to interact with the hardware platform and the back-end analytics, as well as a tool for the visualization of the results.Based on the end-user requirements, the GUI specifically allows the user to:

•
Load the data collected and stored on-board the SD cards of the hardware platforms (when the boards are connected via USB to the computer).This step will automatically start the activity recognition process with the goal of detecting every data collection carried out and, for each of them, the number of running trials/jumps performed.

•
Annotate the demographic/anthropometric information for the athlete under test.

•
Analyze a specific running trial and compute the vertical GRFs and the running metrics from that trial showing the results graphically (Figure 12).The average GRF curves are also visible when clicking on the "Change View" Table.

•
Analyze a specific jump and compute the related metrics separately for eccentric and concentric phases, as well as visualizing the vertical acceleration, along with the jump events (start of the eccentric phase, start of the concentric phase, take-off, landing, and maximum compression).An example is depicted in Figure 13.

•
Export the computed results, subject information, and raw inertial data of a specific running/jumping analysis on an Excel file.

•
Load the results of an analysis previously saved on an Excel file.
• Format the SD cards of the hardware platforms, without the need to remove the SD cards from the boards.
events (start of the eccentric phase, start of the concentric phase, take-off, landing, and maximum compression).An example is depicted in Figure 13. Export the computed results, subject information, and raw inertial data of a specific running/jumping analysis on an Excel file.


Load the results of an analysis previously saved on an Excel file. Format the SD cards of the hardware platforms, without the need to remove the SD cards from the boards.The GUI and all the required algorithms were written in Python and then converted in a single user-friendly executable file of approximately 15 Mb working on computers with Windows 7/8/10 as the operating system.As a result, the end-user does not require to install specific libraries or license when using the executable file.

System Test and Analysis of Results
For the test and validation of the developed system, fourteen healthy volunteers were recruited (14 subjects; 10 males; mass 70 ± 8 kg; age 29 ± 3.4 years).Participants were excluded if they reported any previous musculoskeletal disorder.Recruits were aged be- The GUI and all the required algorithms were written in Python and then converted in a single user-friendly executable file of approximately 15 Mb working on computers with Windows 7/8/10 as the operating system.As a result, the end-user does not require to install specific libraries or license when using the executable file.

System Test and Analysis of Results
For the test and validation of the developed system, fourteen healthy volunteers were recruited (14 subjects; 10 males; mass 70 ± 8 kg; age 29 ± 3.4 years).Participants were excluded if they reported any previous musculoskeletal disorder.Recruits were aged between 20 to 40 years of age and were able to comfortably perform physical activity.
The gold-standard systems used for validation purposes included the Loadsol pressure in-soles (Novel, Germany) [43] for running tasks and the Podium's force plates (BTS Bioengineering, Italy) [44] for jumping tasks.The Loadsol system measures vertical GRFs on the plantar surface of the foot in static and dynamic movements and has been recently validated in running scenarios [45,46].Those studies [45,46] showed that the mean bias of ground contact time, impulse, peak force, and time to peak ranged between 0.6% and 3.4%, demonstrating high accuracy, while for these same parameters, the limits of agreement analysis showed that 95% of all measurement differences between insole and force plate measurements were less than 12%, demonstrating high precision.Moreover, the Loadsol system showed excellent between-day reliability (>0.76).
Participants were asked to attend a single session and run on a treadmill at different speeds (8, 10, and 12 km/h) for approximately 30 s per recording, as shown in [23,24].Each participant was fitted with two IMUs attached on the lateral side of the shanks with elastic bands and with a pair of shoes (same model) equipped with the pressure in-soles (Figure 14 left).IMU data were stored on the developed devices, while kinetics were stored on the tablet used to interact with the pressure in-soles.The IMUs were automatically synchronized with each other as described in Section 3.3.The data sets from the developed IMUs and the gold standard pressure in-soles used for validation were synchronized manually during the post-processing process through the use of a recognizable event (a vertical jump generating a spike in both foot pressure and acceleration signals) as a reference for alignment.A threshold of 20 N in the vertical component of the GRFs was also employed for the identification of the strides.Overall, 42 running trials of 30 s with 60-70 stances each were used for the analysis.
Following the running session, four subjects were asked to perform a series of countermovement and squat jumps on the Podium's force plates.A single IMU sensor was placed with an elastic band on the pelvis of each person approximately at the midpoint of the posterior superior iliac spine (Figure 14

Running Activity Results
Predicted and measured GRF waveforms were averaged and plotted for all the stances of the test set (Figure 15).The root mean square error (RMSE) was used as a metric of comparison between predicted and measured GRF as already performed in literature [19,20,23,24].As confirmed from the RMSE in Table 1, predictions of the vertical GRFs (dashed orange line) were highly precise for all running speeds.Additionally, it appears that estimates made by the ANNs were generally independent of running speed since RMSE were very low for all conditions and returned an average error of approximately 0.148 BW.Predictions were very precise when compared to similar estimates from other studies in the literature.For example, Wouda et al. [19] used inertial sensors at the lower legs and pelvis along with an ANN to estimate vertical GRFs with an RMSE less than 0.27 BW.Moreover, also GRF-related metrics, such as the peak force, were reliably estimated (relative error approx.5%), as shown in Table 2. Finally, the activity recognition algorithm detected 100% of the running trials carried out for validation purposes.

Running Activity Results
Predicted and measured GRF waveforms were averaged and plotted for all the stances of the test set (Figure 15).The root mean square error (RMSE) was used as a metric of comparison between predicted and measured GRF as already performed in literature [19,20,23,24].As confirmed from the RMSE in Table 1, predictions of the vertical GRFs (dashed orange line) were highly precise for all running speeds.Additionally, it appears that estimates made by the ANNs were generally independent of running speed since RMSE were very low for all conditions and returned an average error of approximately 0.148 BW.Predictions were very precise when compared to similar estimates from other studies in the literature.For example, Wouda et al. [19] used inertial sensors at the lower legs and pelvis along with an ANN to estimate vertical GRFs with an RMSE less than 0.27 BW.Moreover, also GRF-related metrics, such as the peak force, were reliably estimated (relative error approx.5%), as shown in Table 2. Finally, the activity recognition algorithm detected 100% of the running trials carried out for validation purposes.GRF: Ground reaction force.

Jumping Activity Results
Jumping metrics results are summarized in Table 3.The table presents the relative error between the estimations obtained with the implemented algorithm and the force platform metrics.A positive sign of the error indicates an underestimation by the proposed system, whereas a negative sign indicates the opposite.Some variables were estimated within an acceptable error range (±10%), while others presented only tolerable (±20%) errors.Those error thresholds were defined based on the suggestions in [47][48][49][50].Some metrics presented larger errors as this is due to the fact that accelerometers are good at measuring acceleration but poor at estimating position, because of problems when integrating data, therefore inevitably introducing errors when estimating the velocity and position curves from an acceleration signal [51].As a result, metrics calculated from the acceleration signal tend to be more accurate than metrics which, on the other hand, are estimated from the signal obtained following double integration over time.Therefore, it can be concluded that, even though the precision achieved may not be sufficient for some metrics, overall, the developed wearable system may satisfactorily predict some of the considered jumping metrics and provide an acceptable monitoring system for athletes' performance.Again, the recognition algorithm detected 100% of the jumps carried out during testing.
A limitation of the system arises from the global force curve being calculated as the product of the vertical local acceleration of the IMU and the mass of the subject; this may cause errors in specific jumping phases (e.g., while the subject is in air, the predicted force should be instead close to zero, Figure 10) since the local IMU and global vertical axes are not always aligned.Peak force at concentric: maximum force during the concentric phase in N; peak force at landing: maximum value of the force produced during landing in N; velocity at landing: velocity when the subject touches down the ground (landing) in m/s; flight time: amount of time the subject is in the air in s; jump height: maximum height reached by the subject during the jump in m; peak power: maximum power developed by the subject during the concentric phase in W; start to peak power: time between the start of the movement and the peak power in s.

Discussion
Despite the various technologies currently adopted for injury prevention, the injury rate in sport is increasing [67].This may be due to the current technology not yet providing key metrics to allow both the coach and athletes to make training and performance-related decisions (i.e., athlete wellness, musculoskeletal screening scores, training load, fitness, and fatigue) in real-time and on-the-field.Additionally, compared to specific orthopedic conditions for which clinical prediction rules exist, athletic training is lagging significantly behind in the area of clinical prediction modeling [68].
Wearables have been already used by athletes and sports teams for a number of years, in particular for tracking information associated with health and fitness.However, the development of tools for performance evaluation and prevention of running-related injuries is still in its infancy [68].
A number of works [69,70] have indeed considered the use of in-soles for pressure plantar monitoring and for the estimation of biomechanical loads associated with running injuries, and several companies have launched such products as shown in the review by Ramirez-Bautista et al. [71].However, most of the products on the market focus only on the pressure heat map/distribution and they are still accompanied with practical long-term issues related to reliability, short lifespan, rapid degradation, feebleness, and high cost.
IMU-based wearable products (i.e., RunScribe [56], GaitUp [58], Stryd [62], IMea-sureU [63], ViPerform [64]) are well-known already for providing biomechanical variables, such as contact time, swing time, cadence, stride time, stride length, speed, pronation angle, foot-strike type, distance covered, asymmetry, stiffness, and impact.However, current IMU-based wearable devices on the market provide loading parameters without specifying how they have been extrapolated or correlated to the GRF curve.Moreover, several devices fail to provide scientific evidence and validations on how accurate their outcomes are.Finally, those wearable devices often employ ambiguous terminology, such as "bone load", "limb load", "step intensity", "impact score", or "biomechanical load", which could be confusing and misleading for end-users [72].
As a result, biofeedback from existing wearable devices may be ambiguous, not validated and potentially harmful for users [72].Yet, the estimation of the full GRF waveforms from which well-known and standardized loading rate variables (i.e., impact peak, active peak, loading rate, and impulse) could be accurately extrapolated, may represent a viable solution to aid in the decision-making of coaches and sport scientists.In this direction, the system and prototypes developed and described in this paper, encompasses the design and integration of a performance-evaluation system able to reliably support coaches and athletes in their real-world practice in a number of sports, such as soccer, rugby, etc.The developed system meets the requirements set by the targeted task in terms of low-power, sampling rate (>200 Hz), wireless synchronization, activity detection, accuracy, number of metrics provided, and graphical visualization.Future work will investigate the possibility to adopt the developed system in agonistic settings, such as a real soccer match, and collect appropriate feedback on its usefulness from actual professional end-users.
The developed system, however, presents some limitations.The implemented activity and event recognition algorithms are specific for the considered case study, and may not be suitable for recognizing running and jumping from other activities (e.g., walking, sprinting).The adoption of machine learning-based human activity recognition approaches [73][74][75] will be considered for future developments, as well as possible improvements (such as the use of machine learning models) related to the estimation of specific jumping-related metrics (e.g., depth).Moreover, this study did not consider the impact that different running surfaces or running shoes may have on the gait of the athletes [76] and, consequently, on the system performance.Further field-testing is required to investigate the effect of the running surface, as well as runners' fatigue, on the developed system.Finally, the enhancement of the Device1-Device2 wireless link reliability via automatic adjustment of communication factors (i.e., packet size, sampling rate) [77] for a more robust synchronization will also be considered.Further investigations will be also carried out with regards to the industrial design of the system so as to ensure that sensor placement is always correct in terms of orientation and position, and to guarantee the absence of gradual changes which could affect the accuracy of the system.
It is also worth noting that, at the current stage, the developed system does not provide a measure of "correctness" (e.g., if a test subject is running or jumping "safely"), but it provides all the considered metrics to the coaches involved in the training and leave the ultimate decision on the exercise "correctness" to the human user.However, a fully automated evolution of the system will be also taken into consideration in future work through the implementation of a traffic-light alarm system which would indicate how "safely" the exercise is performed (for example, green may be interpreted as things should continue as per normal, amber suggests caution that if left unattended could pose a risk, while red raises an alarm and indicates action is required).Indeed, the concept of traffic-light systems is currently widespread in sport science thanks to its ease of use [78].However, the implementation of these traffic-light alarms would require the acquisition of massive datasets with the final aim of providing personalized red/amber/green feedbacks to the end-users based on baselines/benchmarks obtained from each athlete under testing.
Finally, it must be recognized that the literature lacks a consensus regarding the accuracy levels required by coaches to find the technology acceptable.While, for example, for consumer-level wearable activity trackers against gold-standards, some studies recommend that an acceptable measurement error for clinical or research purposes is within ±3%, and under free-living conditions is within ±10%, with other studies recommending that mean errors of less than 20% have acceptable validity for clinical purposes [47].Moreover, according to new United States technological standards, a device may have up to 10% error during walking, jogging, and running [48].However, a similar indication is not provided in the sport field for sport performance devices.Nevertheless, previous literature has suggested that test reliability standards should ultimately be judged by the individual researcher or practitioner based in accordance with their intended use, and that the most reliable variables may not necessarily be the most efficacious in athlete monitoring and performance testing regimens [49,50].Therefore, based on the previous indications, this investigation considers the validity criteria of 20% error threshold as tolerable and 10% error as acceptable for consumer-level technology.

Conclusions
In this paper, a novel wearable IMU-based system has been presented for athletic performance assessment during running and jumping tasks.The system consists of custom hardware platforms required to be developed so as to give the necessary system functionality, embedded firmware for allowing human-boards interaction, wireless synchronization between platforms, automatic recognition algorithms of running and jumping activities and specific event detection, biomechanical algorithms for the estimation of running-and jumping-related metrics, ANN-based vertical GRF waveform estimation, and a GUI for visualization purpose and for allowing the end-users to interact with the back-end analytics and the hardware platforms.This solution will facilitate the exercise science research by giving the possibility to collect a multitude of movement data and by identifying and providing useful insights based on the analysis of a substantial amount of data collected.
The developed system is low-power, sufficiently small for real-world scenarios, easy to use, and achieves the required communication range, with a high sampling rate, and high performance to meet the needs of sport scientists in their analysis of human performance.The system was also tested in terms of the accuracy of the activity recognition algorithms, the estimated running-and jumping-metrics, and the vertical GRF predictions with satisfying outcomes (i.e., RMSE vertical GRF: 0.148 BW, error < 10% for most jumping metrics, and accurate trial detection).As a result, the developed system may be suitably adopted as a performance evaluation tool able to support coaches and athletes in their real-world practice.

Figure 1 .
Figure 1.Devices placement on shanks and pelvis during running and jumping tasks.Figure 1. Devices placement on shanks and pelvis during running and jumping tasks.

Figure 1 .
Figure 1.Devices placement on shanks and pelvis during running and jumping tasks.Figure 1. Devices placement on shanks and pelvis during running and jumping tasks.

Figure 1 .
Figure 1.Devices placement on shanks and pelvis during running and jumping tasks.

Figure 2 .
Figure 2. Graphical depiction of the system adoption.After data collection for a specific task, the device(s) are plugged-into a computer via USB, where a GUI will use back-end algorithms to process the data gathered in the device(s) and visualize the results to the end-users.

Figure 7 .
Figure 7.The running activity recognition algorithm.The figure in the middle depicts the input signal; the top figure shows the calculated variance in each of the 0.5 s windows in which the signal is split; the bottom figure displays the part of the signal that is detected as running.It is worth underlining that the first bout of activity shown in the figure is not detected as running since its duration is lower than the 20 s threshold.

Figure 7 .
Figure 7.The running activity recognition algorithm.The figure in the middle depicts the input signal; the top figure shows the calculated variance in each of the 0.5 s windows in which the signal is split; the bottom figure displays the part of the signal that is detected as running.It is worth underlining that the first bout of activity shown in the figure is not detected as running since its duration is lower than the 20 s threshold.

Appl. Sci. 2021 , 23 
11, x FOR PEER REVIEW 10 of Peak force: average maximum force during stance, expressed in body weight (BW)  Mean force: average force during stance, expressed in BW  RMS force: average root mean square of the force during stance, expressed in BW 

Figure 9 .
Figure 9.The jumping activity recognition algorithm.On top, the vertical acceleration signal of a recording including three consecutive jumps; the bottom figure (in red) depicts the part of the signal that the algorithm has classified as separate jumps.

Figure 9 .
Figure 9.The jumping activity recognition algorithm.On top, the vertical acceleration signal of a recording including three consecutive jumps; the bottom figure (in red) depicts the part of the signal that the algorithm has classified as separate jumps.Appl.Sci.2021, 11, x FOR PEER REVIEW 12 of 23

Figure 10 .
Figure 10.Example of event detection from the accelerometer in a countermovement jump.Force (blue), velocity (red), and displacement (green) curves are plotted and manually scaled to be shown in the same graph.

Figure 10 .
Figure 10.Example of event detection from the accelerometer in a countermovement jump.Force (blue), velocity (red), and displacement (green) curves are plotted and manually scaled to be shown in the same graph.

Figure 11 .
Figure 11.Example of the comparison between the actual and the modeled force curves during a jump.

Figure 11 .
Figure 11.Example of the comparison between the actual and the modeled force curves during a jump.

Figure 12 .
Figure 12.View of a processed running trial showing GRF curves for each stride and running metrics for both legs.

23 Figure 12 .
Figure 12.View of a processed running trial showing GRF curves for each stride and running metrics for both legs.

Figure 13 .
Figure 13.View of a processed jump showing the jumping metrics and the accelerometer graph.

Figure 13 .
Figure 13.View of a processed jump showing the jumping metrics and the accelerometer graph.
, right).Acceleration signals from the IMU along with the kinetic data from the Podium were recorded for each jump and synchronized manually in post-processing.Overall, twenty jumps were considered for validation.The study was conducted according to the criteria set by the declaration of Helsinki and approved by the Clinical Research Ethics Committee (CREC) of the Cork Teaching Hospitals at the University College Cork (Reference Number: ECM 4 (u) 22 October 2019 and ECM 3 (ppp) 14 January 2020).the posterior superior iliac spine (Figure 14, right).Acceleration signals from the IMU along with the kinetic data from the Podium were recorded for each jump and synchronized manually in post-processing.Overall, twenty jumps were considered for validation.The study was conducted according to the criteria set by the declaration of Helsinki and approved by the Clinical Research Ethics Committee (CREC) of the Cork Teaching Hospitals at the University College Cork (Reference Number: ECM 4 (u) 22/10/2019 and ECM 3 (ppp) 14/01/2020).

Table 2 .
GRF peak force metric evaluation: measured and predicted.