You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -235,7 +235,7 @@ An additional preprocessing step is required as part of the synchronization betw
235
235
236
236
```{r}
237
237
#| label: tbl-raw-gaitrite-data
238
-
#| tbl-cap: "Example (33rd session) of an extraction of the occurence of the key gait events from the GAITRite data *before* suppressing uncorrectly labelled events."
238
+
#| tbl-cap: "Extraction of the occurence of the key gait events from the GAITRite data *before* suppressing uncorrectly labelled events (33rd session)."
239
239
#| tbl-subcap: ["First half", "Second half"]
240
240
#| tbl-pos: "H"
241
241
#| layout-ncol: 2
@@ -333,7 +333,7 @@ gaitrite_data[[33]] |>
333
333
334
334
```{r}
335
335
#| label: tbl-preprocessed-gaitrite-data
336
-
#| tbl-cap: "Example (33rd session) of an extraction of the occurence of the key gait events from the GAITRite data *after* suppressing uncorrectly labelled events."
336
+
#| tbl-cap: "Extraction of the occurence of the key gait events from the GAITRite data *after* suppressing uncorrectly labelled events (33rd session)."
337
337
#| tbl-subcap: ["First half", "Second half"]
338
338
#| tbl-pos: "H"
339
339
#| layout-ncol: 2
@@ -397,11 +397,12 @@ gaitrite_data[[33]] |>
397
397
398
398
## Labelled IMU data {#sec-labelled-imu-data}
399
399
400
-
@sec-sec-imu-data presented the preprocessed IMU data from which we aim at identifying the four key gait events (RHS, LTO, LHS, RTO) and @sec-gaitrite-data presented the preprocessed GAITRite data which provides the ground truth labels for each timepoint. We can now perform a table join use the timepoints as key variable to create the labelled IMU data that will serve as the basis for building the feature space for training supervised classification models.
401
-
402
-
Before doing this join, we observe that as the obervations are ordered timepoints, we can think of including data from the past as features in addition to data from a given timepoint. This means that there is no need to keep IMU data collected *after* the last event detected in the GAITRite data. Similarly, we only keep the IMU data collected starting $10$ timepoints *before* the first event detected in the GAITRite data, which provides a lower bound to the lag interval that we will explore when training and tuning the classification models later on. The following piece of code
400
+
@sec-imu-data presented the preprocessed IMU data from which we aim at identifying the four key gait events (RHS, LTO, LHS, RTO) and @sec-gaitrite-data presented the preprocessed GAITRite data which provides the ground truth labels for each timepoint. We can now perform a table join use the timepoints as key variable to create the labelled IMU data that will serve as the basis for building the feature space for training supervised classification models. First, we observe that, as the obervations are ordered timepoints, it makes sense to include data *anterior* to the considered timepoint as features in addition to data from the considered timepoint but we cannot include data recorded *posterior* to the considered timepoint. This means that there is no need to keep IMU data collected *after* the last event detected in the GAITRite data. Similarly, we only keep the IMU data collected starting $10$ timepoints *before* the first event detected in the GAITRite data. This choice prescribes a lower bound to the lag interval that we will explore when training and tuning the classification models later on. Once this filtering step is achieved, we can perform the table join to add the event labels to the timepoints in the IMU data. @fig-labelled-imu-data produced by the code below shows the filtered IMU data with events of interest clearly identified by joining the GAITRite data.
403
401
404
402
```{r}
403
+
#| label: fig-labelled-imu-data
404
+
#| fig-cap: "Filtered IMU data (33rd session) with key gait events superimposed with colored points."
In this work, the objective is to identify which timepoints of unit QTS correspond to the RHS, LTO, LHS and RTO events. For this purpose, we consider the timepoints as statistical units (observations) and we aim at labelling them by means of supervised classification models. We therefore need to define a so-called *feature space* which consists of a data table listing the timepoints by row and collecting a number of features for each of them. A first important feature is the actual label that we want to predict with the trained model. @sec-labelled-gait-data details the elaboration of what
444
-
445
-
### Labelled gait data {#sec-labelled-gait-data}
446
-
447
-
In this view, we can first create the data set that we will use for training. The following code achieves this task by binding together all timepoints from all walking sessions while attaching to each timepoint:
448
-
449
-
- an `event_type` which affects it to one of the five gait events defined in @sec-gaitrite-data;
450
-
- a `phase_type` which affects it one of the four gait pahses defined in @sec-gaitrite-data.
The feature space is an important piece of machine learning models as it defines the data that will be used to train them. In our application, we constructed a feature space from the raw QTS data recorded by the IMU sensor. First, we need to define what is an observation in our context. An observation corresponds to the data recorded at a given time point $t_j$. Since QTS are ordered sets of unit quaternions, for the $j$-*th* observation (row) of the feature space, we can then use features computed from the data observed at time $t_j$ or any other time points preceding $t_j$. One feature is of course the label of the observation that we get from the gold standard. This variable is available for the train/test process but will not be available at prediction time since it corresponds to the events that we want to predict. The other features are predictors that we compute from the sensor data. The ultimate goal is to design a feature space to label each observation $t_j$ with the gait event happening at that time (if any) using only the predictors computed from the QTS at time points $t_k \le t_j$, with $1 \le k \le j$. In the remainder of this section, we describe the predictors that we computed to build our feature space.
513
-
514
-
Angular velocity and acceleration vectors
515
-
516
-
: If we can have access to the first and second time derivatives of a QTS, we can compute the *angular velocity vector* $\pmb{\Omega}$ and *angular acceleration vector* $\dot{\pmb{\Omega}}$ [@narayan2017]. These vectors are aligned with the axis of rotation and carry in their norm the angular velocity and acceleration respectively. The angular velocity vector is computed as follows:
Recall that $\mathbf{q} = \exp \mathbf{v}$ where $\mathbf{v}$ is the logarithm of $\mathbf{q}$ introduced in @eq-smoothed-qts. Then, we have after simple mathematical computations that $\dot{\mathbf{q}} = \mathbf{q} \dot{\mathbf{v}}$. Therefore, the angular velocity vector is nothing but twice the vector part of the temporal derivative $\dot{\mathbf{v}}$ of the log-QTS. This is implemented in the `squat::qts2avvts()` function, which returns a tibble with columns `time`, `x`, `y` and `z` storing the coordinates of the angular velocity vector at each time point as illustrated by @fig-avvts:
530
-
531
-
```{r}
532
-
#| label: fig-avvts
533
-
#| fig-cap: "An illustration (33rd session) of the angular velocity vector time series representation."
From $\dot{\mathbf{q}} = \mathbf{q} \dot{\mathbf{v}}$, we can write the second temporal derivative of $\mathbf{q}$ as $\ddot{\mathbf{q}} = \mathbf{q} \left( \dot{\mathbf{v}} \dot{\mathbf{v}} + \ddot{\mathbf{v}} \right)$. Therefore, the angular acceleration vector is nothing but twice the vector part of the second temporal derivative $\ddot{\mathbf{v}}$ of the log-QTS. This is implemented in the `squat::qts2aavts()` function, which returns a tibble with columns `time`, `x`, `y` and `z` storing the coordinates of the angular acceleration vector at each time point as illustrated by @fig-aavts:
567
-
568
-
```{r}
569
-
#| label: fig-aavts
570
-
#| fig-cap: "An illustration (33rd session) of the angular acceleration vector time series representation."
labs(title = "", x = "Time (seconds)", y = "Angular acceleration (rad/s²)")
585
-
```
586
-
587
-
Euler angles
588
-
589
-
: The angles named *Roll*, *Pitch* and *Yaw* represent rotations around the three principal axes. They are computed from a unit quaternion $\mathbf{q} = (q_w, q_x, q_y, q_z)$ using the following formulas:
424
+
labelled_imu_data <- purrr::map2(
425
+
imu_data,
426
+
gaitrite_data,
427
+
\(.imu, .gaitrite) {
428
+
out <- .imu |>
429
+
dplyr::left_join(.gaitrite, by = c("time" = "event_time")) |>
where $\arctan\!2(y, x)$ computes the angle $\theta$ (in radians) between the positive $x$-axis and the ray from the origin to the point $(x, y)$ in the Cartesian plane. This is implemented in the `squat::qts2rpyts()` function, which returns a tibble with columns `time`, `roll`, `pitch` and `yaw` storing the roll, pitch and yaw angles at each time point as illustrated by @fig-rpyts:
labs(title = "", x = "Time (seconds)", y = "Angle (rad)")
624
-
```
625
-
626
-
Walking speed
627
-
628
-
: It is likely that the shape of the QTS can be quite different according to the walking speed. We therefore included this information in the feature space from the GAITRite® mat output. Since this predictor comes from the gold standard, it is not available when predicting on new time series where patients only used the wearable sensor. To counter this issue, we can estimate the walking speed from the mean angular velocity with a simple linear regression.
629
-
630
-
Hyper-parameters
631
-
632
-
: The feature space depends on a number of hyper-parameters. The first one is a smoothness parameter called *spar* that represents the amount of smoothing that we seek to achieve when fitting cubic splines to the original QTS. Since time derivatives are used to compute some predictors, it is indeed useful to smooth the QTS sufficiently so the derivative values remain stable and not dominated by noise. The *spar* parameter takes its values in the interval $]0,1]$. The second hyper-parameter is the *lag* parameter. To keep information from the past as we predict at a given time point $t_j$, we include features computed at $t_j$ as well as the same features computed at time points $t_{j-1}, \dots, t_{j-\mathrm{lag}}$. The size of the feature space therefore depends on the *lag* parameter as it contains $10 + 9 \times \mathrm{lag}$ predictors. The ten first predictors are the three-component angular speed vector, the three-component angular acceleration vector, the three angles Roll, Pitch and Yaw and the walking speed. We then add nine predictors per *lag*: the angular speed and acceleration and the Roll-Pitch-Yaw angles from the previous time.
633
-
634
-
Finally, a last hyper-parameter is used when we label the observations with the gait event times from the gold standard. It is called *k* and controls the number of points around a gait event that we label as part of the event. In @sec-classification-strategies, we elicit two strategies for building segmentation models, one of which does not use this parameter. Therefore, we differ other details about this parameter in the dedicated section.
454
+
labs(x = "Time (s)", y = "", color = "Event type") +
0 commit comments