Introduction

This project stems from the need to integrate motion data acquired through inertial sensors into the OpenSim biomechanical simulation environment, with the goal of achieving a reliable reconstruction of the pedaling motion. In the early stages of the work, no consolidated operational protocols or standardized procedures were available for data conversion and processing, making it necessary to develop a dedicated workflow.

The first import attempts revealed significant issues related to the incompatibility between the format of the acquired data and the structural requirements demanded by OpenSim. In particular, the misalignment between the reference systems used by the sensors and the one adopted by the simulation software resulted in an incorrect spatial configuration of the biomechanical model, compromising the correct reproduction of the cyclist's posture on the bicycle.

At the same time, anomalies in the reading and interpretation of the raw data generated discontinuous movements lacking the necessary kinematic coherence, limiting the possibility of performing reliable biomechanical analyses.

In light of these issues, the project focused on defining a processing pipeline capable of converting, correcting, and optimizing the acquired data, ensuring compatibility with OpenSim and the quality of subsequent motion analyses.

Objective

The activity carried out had the general goal of creating a reliable procedure for importing and analyzing kinematic data within OpenSim, applied to the study of the pedaling motion. To this end, the work focused on achieving three specific objectives.

First, a customized scaling procedure for the biomechanical model was developed, aimed at accurately reproducing the anthropometric characteristics of the analyzed subject, overcoming the use of generic models and allowing a more realistic representation of the cyclist's body configuration.

Next, the problem of misalignment between the sensors' reference systems and OpenSim's was addressed, through the definition of a spatial correction and alignment strategy that would allow the correct reconstruction of the riding position within the virtual environment.

Finally, signal processing techniques were implemented to reduce the noise present in the instrumental acquisitions and to minimize kinematic discontinuities. The final goal of this phase was to obtain a smooth and biomechanically coherent animation, free of artifacts, suitable for subsequent quantitative motion analyses.

Project Development

a. MATLAB Script for File Conversion

Development of the .mvn to .mot Algorithm

To overcome the incompatibility of the native files generated by inertial Motion Capture systems and enable the animation of the virtual skeleton, a MATLAB script originally developed for converting Xsens kinematic data into .mot files compatible with OpenSim was used and adapted. This script acts as a genuine technological bridge, automating the translation of raw kinematic data (.mvn or .mvnx format exported from the Xsens software) into the native format required by the OpenSim simulation environment (motion files with a .mot extension).

The primary goal of the algorithm is to mathematically convert and map the angles defined in the Xsens software so that they are consistent with the degrees of freedom and geometric conventions of OpenSim's musculoskeletal models.

Structural and Geometric Analysis of the Formats

The need to develop a dedicated converter lies in the deep structural and physical differences between the two file formats:

• Source File (.mvn/.mvnx): Contains the raw data recorded by the inertial sensors (IMUs) placed on the subject's body. This information describes the trajectories, accelerations, and spatial rotations relative to individual, isolated body segments.
• Output File (.mot): This is a motion file characterized by an extremely rigid matrix structure. It does not express data for individual loose segments, but rather describes the angular degrees of freedom of the model's kinematic joints as a function of time. OpenSim requires a strict file structure, with a correctly formatted header, a consistent number of rows and columns, and coordinate naming that conforms to the model used.

Logical Phases of Script Processing

To successfully convert the movement and populate its structure, the algorithm follows a logical sequence divided into three macro-operations:

• Data Structure Extraction and Initialization: The script relies on low-level functions (such as load_mvnx_v2) to transform the XML tree of the inertial file into a manipulable MATLAB structure (tree). A scanning loop is executed to collect the joint labels (joint_names), creating a mapping that allows the necessary columns to be identified programmatically and redundant data to be excluded.
• Fail-Safe Logic: If a given joint was not recorded by the sensors or contains corrupted data, the algorithm does not stop execution; instead, it allocates a vector of zeros with a length equal to the total number of frames (nSamples). This safeguard operation is vital, since OpenSim rejects the import or crashes if it encounters a column missing relative to those declared in the header.
• Pelvis Realignment and Angular Transformation: The global orientation of the pelvis is derived from the quaternions recorded by Xsens and converted into Euler angles. The pelvis acts as the "anchor" and center of mass for the entire virtual skeleton (6 degrees of freedom of the root). The script extracts the pelvis orientation by converting the raw quaternions into Euler angles (via the q_to_euler function) to obtain the list, tilt, and rotation parameters. Simultaneously, for the position in space (pelvis_tx, pelvis_ty, pelvis_tz), a manual realignment of the Cartesian axes is performed, associating, for example, OpenSim's vertical coordinate (Y) with the correct Xsens sampling column, resolving the initial geometric error of the mannequin appearing upside down or lying flat.
• Sign Convention (Polarity) Mapping: Since each software arbitrarily adopts its own positive or negative direction for anatomical rotations (while still following the right-hand rule), the script implements a correction matrix called signs. Without this step, serious dynamic anomalies and unnatural movements would occur (such as the knee bending forward or the arms passing through the torso).

Through conditional logic (if-elseif strcmp), the signs vector (initially composed only of 1 values) is modified by inserting a -1 value at the critical indices, in order to surgically invert the kinematic polarity based on the selected OpenSim model:

The final mathematical operation translates into an element-by-element multiplication (MATLAB's .* matrix operator) between the sign vector and the global motion matrix, to which the time column, converted into seconds, is subsequently appended:

Angles_Matrix = signs .* (Angles_Matrix)

The final .mot file is then physically written by printing, row by row, the strict text header, making the data ready, clean, and digestible for OpenSim's inverse kinematics solver.

b. Signal Analysis and Filtering

After converting the file from the native .mvn format to .mot following the described procedure, the motion data was filtered using a MATLAB script. Before proceeding with filtering, a study of the signal in the frequency domain was carried out: by applying the Fast Fourier Transform (FFT) to a kinematic component, the harmonic components of the pedaling motion were identified in order to isolate them from the background noise.

As can be seen from the graph, at very low frequencies there is a high-amplitude peak. This peak represents the DC component (the average offset of the signal over time), which, in our specific setup, holds the fundamental biomechanical information about the subject's initial reclined geometric position.

During the data conversion for OpenSim, a further problem was encountered: a visual artifact consisting of an instantaneous 360° rotation of the model. This phenomenon is related to the wrapping of the Euler angles, whose values are mathematically bounded within the [-180°, +180°] range, generating artificial discontinuities when the actual movement exceeds this threshold. To resolve this numerical error, the unwrap function was applied to the kinematic signal before importing it into OpenSim. The algorithm identified the jumps near ±180° and algebraically added multiples of 360° (2π rad) to them. This intervention removed the fictitious angular velocity spikes, ensuring trajectory continuity and a coherent simulation.

Regarding data cleaning, a low-pass filter was preferred over a band-pass filter. Voluntary human body movements are in fact low-frequency phenomena, whose informative content is generally below 6-10 Hz, while measurement noise is concentrated at high frequencies; the low-pass filter therefore allows the disturbance to be eliminated while preserving the useful signal. The choice of a band-pass filter was discarded because introducing a lower cutoff frequency would have eliminated precisely the very low frequencies, zeroing out the initial postural offset and compromising the subsequent inverse dynamics calculations in OpenSim.

Critical Issues

The critical issues encountered were as follows:

• Input file formatting: OpenSim requires an extremely rigorous structure for .mot and .trc files. Even minor inconsistencies in formatting, such as errors in joint coordinate names, discrepancies between the declared and actual number of columns, or unwanted spaces in the header, can prevent data import or cause processing to fail.
• Reference system management: One of the main difficulties concerned the correct conversion of kinematic data between the reference system used by Xsens and the one required by OpenSim. Specifically, OpenSim adopts a right-handed coordinate system in which the Y axis points vertically upward, the X axis represents the subject's forward direction, and the Z axis represents the lateral direction. The data exported by Xsens, on the other hand, is expressed in a different global reference system, with axis and rotation conventions that do not directly match those of OpenSim. As a result, it was necessary to apply appropriate geometric transformations and axis rotations to ensure correct correspondence between the two reference systems. In the early stages of development, errors in defining these transformations caused incorrect orientations of the biomechanical model, with the mannequin appearing lying down, upside down, or with movement directions incompatible with those recorded during acquisition.
• Joint coordinate conversion: Transforming the data obtained from the MATLAB script into joint coordinates compatible with OpenSim required several validation phases. It was necessary to verify that the kinematic information respected the model's biomechanical constraints without introducing unrealistic or redundant degrees of freedom.
• Debugging and error identification: Identifying the causes of errors was made complex by the limited diagnostics provided by OpenSim. In many cases, it was necessary to carry out iterative checks on the generated files and on the transformations applied to the data in order to identify and correct the anomalies present in the processing workflow.

Conclusions and Future Developments

Through the work carried out, it was possible to obtain a stable biomechanical animation consistent with the real pedaling motion, a smoother and more realistic model movement within OpenSim, improving both animation quality and the robustness of subsequent analyses.

Looking ahead, the workflow could be further improved by automating the conversion and filtering procedures, making the pipeline faster, standardized, and easily replicable for different acquisitions.

The availability of reliable kinematic data in OpenSim also paves the way for advanced biomechanical analyses, such as Inverse Dynamics, muscle force estimation via Static Optimization, joint load analysis, and the study of posture's influence on cyclist performance. These tools could support the ergonomic optimization of the vehicle and future design activities integrated with multidisciplinary simulations.