The experimental datasets expected to populate the EUROBENCH database will engage data coming from a lot of different sensing devices, from different laboratories and will be designed for different benchmarking scenarios and algorithms. In order to store these experiments in a consistent way, a common, comprehensive and flexible data format is necessary. Other motivations for the specification of a unique data format and conventions are:
-
Ensuring automatic computation of Performance Indicators (PIs) based on recorded data.
-
Maximizing compatibility between PIs that are common to several protocols (e.g. step length can be calculated in many ways and under many different conditions).
-
Allowing data collection and PI computation to happen independently in different times and location (e.g. enabling any remote user to benchmark an experiment performed in a specific laboratory setting).
Any request to extend / change format described here should be done following the contribution policy.
In this section we propose a common format for the set of files collected during an experiment. An experiment should correspond to a set of files per run [1]. This set of files will be taken as input by a benchmarking routine that, after processing these data, will return a set of benchmarking score(s) (see Figure 1).
Generally speaking, we consider 4 different classes of files related to an experiment:
-
Bipedal system specification: file providing specification of the dimension of any bipedal system. It can be describing a human subject, a humanoid, a prosthesis, an exoskeleton.
-
Testbed configuration file: provide values for any configuration parameter needed to reproduce the conditions of an experimentation, or a subset of an experimentation.
-
Raw Data: Data directly collected by the sensors (e.g. marker trajectory).
-
Pre-processed Data: Sensor-actuator agnostic data acquired during the experimentation. The structure of such file is to be compliant with the format agreed in this document.
In the following sections, each of these types of data will be defined and detailed.
An experiment consists in recording datafiles while the subject (human / robot / both) is performing a given task. The activity can be repeated as follows:
-
to get different runs: a set of runs consists in repeating the same actions (and recording) in the same conditions (for enabling statistics for instance). We would thus acquire several times the same set of information, but the data will be split in different datafiles.
-
to consider different conditions: in that case, a setting is changed. It can be a configuration of the testbed or environmental settings (augment the slope angle), a configuration of the robotic system (support level of the exoskeleton), or an indication to the user (redo the operation with eyes closed). The parameter being changed must be mentioned as a controlled variable, and must be listed in the testbed configuration file. For each condition, we can have a set of runs.
-
to involve several subjects: this is particularly relevant for experiments involving humans. In that case, we can considering having for each subject the execution of the same protocol, i.e involving potentially several conditions, and for each condition several repetitions or runs.
Generally speaking pre-processed data should follow the following contextualized pattern:
subject_X_cond_Y_run_Z_[type].csvThe rationale behind this filename format is described in The Experimental data page.
Unless specified if different, all datafile recorded will have a name using this pattern. Each data file is now described, focusing on the type of information stored (extensions subject, cond and run are skipped for now).
| File name | Format | Content |
|---|---|---|
jointAngles |
csv |
Joint Angles |
jointTorques |
csv |
Joint Torques |
jointTrajectories |
csv |
Joint Trajectories |
grf |
csv |
Ground reaction Forces |
emg |
csv |
Electromyography |
wr_N_config_M_segments (unclear) |
yaml |
Segments descriptions files |
subject_N_info |
yaml |
subject description (metric and/or other) |
humanoid_N_info |
yaml |
Humanoid description |
gaitEvents |
yaml |
Gait Events |
subject_N_run_R_testbedLabel |
yaml |
testbed specifics |
Generally speaking, all csv files follow the Comma-separated values format, using semicolon as separator.
In the following documentation, we will use tables for describing file content. As an example, the following table:
| label_1 | label_2 | label_3 |
|---|---|---|
value_1 |
value_2 |
value_3 |
would correspond to a file containing the 2 lines:
label_1; label_2; label_3
value_1; value_2; value_3For all csv-based data file type, we will present in the following document a table with:
-
the first line indicating the column labels to use
-
the second line indicating the unit of each column
If we can accept that all column may not be present in the file (see next section), we assume that the first row should always contain the labels of all columns present in the file.
If a field or a column cannot be filled (the force sensor only provides force measurement, no torque, or all human joint angles are not tracked), the label should be discarded from the file (i.e no empty column). This way, the wrench file corresponding to a 6D force sensor (OnRobot HEX-E QC, for example) would look as follows:
time; force_x; force_y; force_z; torque_x; torque_y; torque_z 0; 1.67; 2.34; 0.83; 0.21; 0.53; 0.07 0.001; 1.62; 2.12; 0.75; 0.29; 0.47; 0.1 0.002; 1.63; 2.41; 0.81; 0.19; 0.56; 0.8 .....
while the wrench file for a 1D force sensor (FlexiForce A101 Sensor, for example) would have the following appearance:
time; force_x 0; 1.67 0.001; 1.62 0.002; 1.63 .....
|
Warning
|
Note that, depending on the benchmarking algorithm requirements, this may prevent the Performance Indicator computation, if a column is expected by the algorithm, but not present in the data file. |
Some protocols can require the use of various but similar sensors (like a force sensor on each of the crutches). In that case two options are proposed:
|
Warning
|
The protocol should indicate the appropriate option to use. |
Option 1: one file per device
The two files will share the same structure (based on the information stored in it), but will only differ by their name:
-
subject_N_run_R_wrench_tag1.csvfor the force sensor labelledtag1 -
subject_N_run_R_wrench_tag2.csvfor the force sensor labelledtag2
The label string (tag1, tag2) to use is defined by the protocol.
Both files will contain data following the regular wrench file pattern, i.e.:
| time | force_x | force_y | force_z | torque_x | torque_y | torque_z |
|---|---|---|---|---|---|---|
0 |
1.67 |
2.34 |
0.83 |
0.21 |
0.53 |
0.07 |
0.001 |
1.62 |
2.12 |
0.75 |
0.29 |
0.47 |
0.1 |
0.002 |
1.63 |
2.41 |
0.81 |
0.19 |
0.56 |
0.8 |
Option 2: one file gathering the two devices
A single file is provided, and use the generic format subject_N_run_R_wrench.csv.
The file content is a concatenation of the two readings, with the labels adjusted to distinguish the two devices:
| time | tag1_force_x | tag1_force_y | tag1_force_z | tag1_torque_x | tag1_torque_y | tag1_torque_z | tag2_force_x | tag2_force_y | tag2_force_z | tag2_torque_x | tag2_torque_y | tag2_torque_z |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 |
1.67 |
2.34 |
0.83 |
0.21 |
0.53 |
0.07 |
1.67 |
2.34 |
0.83 |
0.21 |
0.53 |
0.07 |
0.001 |
1.62 |
2.12 |
0.75 |
0.29 |
0.47 |
0.1 |
1.62 |
2.12 |
0.75 |
0.29 |
0.47 |
0.1 |
0.002 |
1.63 |
2.41 |
0.81 |
0.19 |
0.56 |
0.8 |
1.63 |
2.41 |
0.81 |
0.19 |
0.56 |
0.8 |
… |
… |
… |
… |
… |
… |
… |
… |
… |
… |
… |
… |
… |
|
Warning
|
This option is only accepted if the data logged is using the same timestamp. |
Even though data collected should always be aligned with the specification of the protocol that could supersede the general description provided here, in any measurement involving a global Cartesian reference frame, such reference frame should be placed as proposed in the ISB recommendations, with [Wu1995]:
-
xaxis aligned with the gait direction -
yaxis vertical and pointing upwards
[Wu1995]: G. Wu and P. R. Cavanagh. ISB recommendations for standardization in the reporting of kinematic data. Journal of Biomechanics, 28(10), 1995. pdf.
Any bipedal system involved in an experiment is to be described by a specification file. We are promoting the use of the Unified Robot Description Format, URDF, both for robotic systems and human subjects.
Note that if an experiment involves a human subject and a wearable device, we expect to get two specification files, one for the human, and another for the wearable.
Description: It is the standard file (written in XML) used in ROS to describe a robot’s model (kinematics, dynamics and sensors). This file must be provided if the experiments enroll a humanoid robot. From this file, the number of joints, its labels and the degrees of freedom can be extracted in order to construct the pre-processed joint angles file, and for the definition of the anthropometric file in humanoids.
Number of files: all necessary files to describe the complete robotic structure.
Name of the file: The main urdf file which includes the rest of urdf files should be named as robot_N_info, where N is the humanoid number.
File format: .urdf.
The use of .urdf files also has shortcomings such as the lack of friction (important for e.g. walking steeper slope angles).
In order to resolve these issues, EUROBENCH will use Gazebo as a simulator.
This allows to enhance the .urdf with <gazebo/> tags, permitting the injection of features from the gazebo file format (.sdf) while retaining the most common file format, .urdf.
Description: Standard file used in robotics in XML format to describe the dimensions, the physics properties (COM, mass, friction) and inertial properties of each one of the segments of the worn robot. All these segments are linked by joints (fixed, prismatic, rotational) forming a single tree. Moreover, it allows to use a wide variety of simulators commonly used in robotics such as Gazebo.
Number of files: Usually each segment, sensor, or set of segments such as a leg are described in a single file. Finally the whole robot includes all these files in a single file which is the one loaded.
Name of the file: wr_N_config_M_segments, where N is the WR number and M is the configuration number (for resizable robots this could be useful).
File Format: .urdf. This format file allows to include Gazebo simulation tags, such as friction properties, or visualization properties that allow to simulate more realistic behaviors. This file shall contain the dimensions and inertial properties of each segment of the worn robot with respect to the reference system of the human body segment connected to it. This is needed to enable dynamic simulators to model the human-WR system.
Description: This file shall contain all information related to the subject, such as the anthropometric measurements of the human body segment (as detailed in the model document), gender, age, … .
Name of the file: subject_N_info, where N = subject’s number.
Use appropriate leading zeros for R and N to ensure proper ordering of files.
File format: .yaml
File structure: Set of lines containing key: value. For anthropometric measures, the keys should be the ones presented in body segment table. In any case, the entries provided should follow the protocol requirement.
Units: Various
Description: This file shall contain all the anthropometric measurements from the humanoid robot mapped to the above proposed human segments (see Table 2 and Figure 3).
Name of the file: robot_N_info, where N = humanoid’s identifier.
File format: .yaml
File structure: Set of lines containing key: value where the key must contain the corresponding robot segment name.
Units: Meters.
Description: This file shall contain all relevant information for reproducing the experiment in similar conditions. It can contain values of configuration of the used testbed (e.g. for slope: slope angle; for stairs: step height; etc…). It can also contain configuration parameters that may be needed by the algorithms for computing the performance indicators. It can also contain subject behavior constraints set by the experimenter (ask the human to perform the action eyes closed, or use different tuning parameter set for the humanoid, or a different support level for the exoskeleton…).
File format: .yaml
File name: condition.yaml
File structure: Set of lines containing key: values. Where each key is one testbed-related data. keys must be self-explicative. Different words on the same key must be separated by underscore. keys must be written in lower case style.
If a protocol involves several equipment, then all configuration information should be placed in the same file, using the pattern device_name_param_name to describe each of the device.
For instance, if a protocol involves a push stick and an instrumented garment, we would consider the following configuration file:
push_tick_param_1: 3.14
push_tick_param_2: 0
garment_param_i : [15, 46]
garment_param_j: 2The exact content of the file is defined by the protocol itself.
|
Warning
|
All controlled variables, as defined in the template spec should be defined in that file. |
Description: This set of files should contain all data collected directly from the sensory system/s present in the benchmarking scenario (i.e. 3D marker positions, IMUs signals, forces from platforms, etc…).
Number of files: One file per run and sensory system should be provided.
File format: These files are not supposed to be processed automatically by the EUROBENCH Benchmarking routines, so that a specific format is not defined.
Data can be provided as the device drivers provide them (e.g. c3d, rosbag, .txt, .csv, …). However, a description of the file content and acquisition frequency should be provided (like Readme.md or Readme.txt) to help the user opening and understanding these files.
This set of files should contain all the data processed from the raw data and needed for running a specific benchmarking routine. As described in each of the following sub-sections, we envision one format per type of information. These files should be preferably agnostic of the specific sensor used to capture it, so that the benchmarking routines can be launched independently of the acquisition devices. All time-series files should contain time-stamped information, since timestamp reference will be shared by all files describing a same experiment run.
An experiment can provide one or more of the following file types. If a testbed or a benchmarking routine requires a data type not included in this document, please contact the EUROBENCH Team. We will work together with you to create the required data file type.
Description: This file shall contain the time-series of all measured joint angles, expressed in YXZ Cardan Angles, as defined in the Angle Definition section.
filename root: jointAngles where N = subject’s number and R = run number.
Use appropriate leading zeros for R and N to ensure proper ordering of files.
File format: .csv
File structure:
| time | r_hip_y | r_hip_x | r_hip_z | r_knee_y | r_knee_x | r_knee_z | … | … | … |
|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
… |
… |
… |
Joint labels should refer to the names provided within the human model document.
Description: This file shall contain all the measured joint torques.
filename root: jointTorques
File format: .csv
File structure:
| time | r_hip_x | r_hip_y | r_hip_z | r_knee_x | r_knee_y | r_knee_z | … | … | … |
|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
… |
… |
… |
Joint labels should refer to the names provided within the human model document.
Description: This file shall contain all the measured trajectories of the joints.
Filename root: jointTrajectories.
File format: .csv
File structure:
| time | r_ankle_x | r_ankle_y | r_ankle_z | r_knee_x | r_knee_y | r_knee_z | … |
|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
… |
Joint labels should refer to the names provided within the human model document.
Description: Contain the 3D position of particular landmarks that are tracked during the experimentation.
Filename root: landmarkTrajectories.
File format: .csv
File structure:
| time | landmark_1_x |
landmark_1_y |
landmark_1_z |
landmark_2_x |
landmark_2_y |
landmark_2_z |
… |
|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
… |
landmark_1, landmark_2, …, landmark_N should be the name of the landmark tracked.
NOTE:
In the particular case where the experiment tracks both landmarks and specific joint positions as described in Joint center 3D trajectory, it is accepted to place these landmarks positions within the jointTrajectories file.
It is assumed that the protocol documentation provides the landmark label, and a clear description of the landmark position on the subject body.
The body Center of Mass (COM) is frequently considered in biomechanics, as it reflects the motion of the whole body. It is usually defined as the unique point where the weighted relative position of the distributed mass sums to zero (wikipedia).
Description: This file shall contain the estimated COM position along time.
Filename root: com.
File format: .csv
File structure:
| time | x |
y |
z |
vel_x |
vel_y |
vel_z |
acc_x |
acc_y |
acc_z |
|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
Description: contains the state of a set of joints along time.
Filename root : jointStates
File format: .csv
File structure:
| time | label_1_pos |
label_1_vel |
label_1_acc |
label_2_pos |
… |
|---|---|---|---|---|---|
|
|
|
|
|
… |
where label_i should be replaced by the name of the joint, as specified in the protocol documentation.
|
Note
|
A jointState file can refer to joint(s) of a robotic device, or to joint(s) of an element of the testbed. |
The angular momentum of a body is a vector quantity that represents the magnitude and the direction in which the body rotates about a reference point [Bennett2010].
We refer here to the total body angular momentum, around the total body Center of Mass (CoM), expressed in global coordinates.
That is, the sum of the angular momenta of different segments around the total body CoM (see eq. (16) in [Herr2008] or the methods section in [Bennett2010]).
Description: This file shall contain the estimated angular momentum around the COM along time.
Filename root: angularMomentum.
File format: .csv
File structure:
| time | x | y | z |
|---|---|---|---|
|
|
|
|
where Js stands for Joule second (equivalent to kgm2s⁻1).
bibliography:
Description: The inertia tensor describes the body´s resistance to rotational motion in response to a torque.
Filename root: inertiaTensor.
File format: .csv
File structure:
| time | xx | xy | xz | yx | yy | yz | zx | zy | zz |
|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
Description: This file shall contain wrench (force and torque) measured by a force sensor.
Filename root: wrench
File format: .csv
File structure:
| time | force_x | force_y | force_z | torque_x | torque_y | torque_z |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
Description: This file shall contain forces measured by force platforms.
Filename root: grf
File format: .csv
File structure:
| time | f_x | f_y | f_z | p_x | p_y | p_z | t_x | t_y | t_z |
|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
where f stands for force, p for the center of pressure, and t for torques.
Description: This file shall contain all the recorded EMG signals from the human subject.
Filename root: emg
File format: .csv
| time | label_1 | … | label_i | … |
|---|---|---|---|---|
|
|
|
|
|
where label_i is to be a tag described in List of EMG muscles and labels considered. Suffixes _l and _r may be added to differentiate left and right limb, when needed..
_l and _r may be added to differentiate left and right limb, when needed.
| Muscle | Label |
|---|---|
Abductor Longus |
AbLo |
Biceps Femoris |
BiFe |
Gastrocnemious Lateralis |
GaLa |
Gastrocnemious Medialis |
GaMe |
Gluteus Maximus |
GlMa |
Gluteus Medialis |
GlMe |
Gracilis |
Gra |
Peroneus Longus |
PeLo |
Rectus Femoris |
ReFe |
Sartorius |
Sar |
Semimembranosus |
SeMe |
Semitendinosus |
SeTe |
Serratus Anterior |
SeAn |
Soleus |
Sol |
Tensor Fascia Latae |
TeFa |
Tibialis Anterior |
TiAn |
Extensor Digitorum |
ExDi |
Vastus Lateralis |
VaLa |
Vastus Medialis |
VaMe |
Description: This file shall include all detected (or calculated) heel strike and toe off gait events.
Filename root: gaitEvents
File format: .yaml
File structure:Set of lines containing key: [vector, of, values].
Possible keys are provided on the last column of List of gait events and its considered labelling.
File content: See List of gait events and its considered labelling.
| Gait Event | Label |
|---|---|
Right Heel Strike |
r_heel_strike |
Left Heel Strike |
l_heel_strike |
Right Toe Off |
r_toe_off |
Left Toe Off |
l_toe_off |
Units: Seconds
Description: This file shall include characteristics of the gait, if it is considered as input parameters detected (or calculated).
Filename root: gaitParameters
File format: .yaml
File structure: Set of lines containing label: [vector, of, values]. Possible labels are provided on the last column of List of gait events and its considered labelling and units, together with the units.
File content: See List of gait events and its considered labelling and units.
| Gait Event | Label | type | unit |
|---|---|---|---|
Left Cadence |
|
scalar |
step/min |
Left Walking Speed |
|
scalar |
m/s |
Left Stride Time |
|
scalar |
s |
Left Step Time |
|
scalar |
s |
Left Stride Length |
|
scalar |
m |
Left Step Length |
|
scalar |
m |
Left Step Width |
|
scalar |
m |
Left Single Support |
|
scalar |
s |
Right Cadence |
|
scalar |
step/min |
Right Walking Speed |
|
scalar |
m/s |
Right Stride Time |
|
scalar |
s |
Right Step Time |
|
scalar |
s |
Right Stride Length |
|
scalar |
m |
Right Step Length |
|
scalar |
m |
Right Step Width |
|
scalar |
m |
Right Single Support |
|
scalar |
s |
Double Support |
|
scalar |
s |
Description: We gather in that concept measurements of the heart/breathing system activity and skin response:
-
Heart rate: speed of the heartbeat measured by the number of contractions (beats) of the heart per minute (bpm) (link). Label:
hr -
Heart rate variability (HRV): is the physiological phenomenon of variation in the time interval between heartbeats. It is measured by the variation in the beat-to-beat interval (link). Unit is set to
sec(second). Label:hrv -
Respiration rate: rate at which breathing occurs (link). Unit is
bpm(breaths per minute). Label :rr -
Galvanic skin response: refers to changes in sweat gland activity that are reflective of the intensity of our emotional state (link). Unit is
mS(milliSiemens). Label:gsr -
Electrocardiogram (ECG): electrical activity of the heart as perceived by electrodes placed on the skin (link). Unit is
mV(milliVolt). Label:ecg
Filename root: physiological
File format: .csv
File structure:
| time | hr | hrv | rr | gsr | ecg |
|---|---|---|---|---|---|
|
|
|
|
|
|
Note that recording all these dimensions may not be required by all protocols. Unmeasured dimensions should be discarded by removing the related label from the file.
Also, if different acquisition devices are used, and if the acquisition frequency is different, then more specific data file could be generated (like physiological_ecg if ecg presents a different frequency).
Description: In some protocol, an instrumented device may have been designed to collect a set of sensor data. We consider the possibility of gathering sensed data in a common file under the following conditions:
-
all data recorded should share the same timestamp.
-
the file contains labelled column
-
as mush as possible, the column labels should be following the data format proposed in the data types previously described in this document.
Filename root: platformData
File format: .csv
File structure: specific to the testbed. Label row mandatory.
We propose a common format for the set of files containing data regarding the user subjective evaluations of the experience of using an exoskeleton. We describe here all questionnaire-like output of an experimentation. These questionnaires can be filled by an operator observing the experimentation, or by the human subject taking part of the experimentation. This is defined by the related protocol. Here we focus on the representation of the questionnaires and related answers.
The representation of any questionnaire is divided into two components:
-
The description of the questionnaire itself: Factor Meta Data File
-
The representation of the questionnaire answer: Factor Data File
We propose using csv format for both.
Description: This file contains the specification of each question of the questionnaire. That file should be part of the protocol itself. It should not vary from an experimentation to another.
Name of the file: questionnaire_name.csv, where name should be a unique identifier given to that questionnaire model.
File format: .csv
File structure: a table-like structure with the following content:
| itemID | type | options | text | answer_unit |
|---|---|---|---|---|
0 |
This is the title of the questionnaire? |
|||
1 |
value |
float > 0 |
Time required to donning the exoskeleton |
sec |
2 |
value |
int>0 |
Number of steps climbed and down |
number |
3 |
boolean |
Did the user stumble when ascending stairs |
boolean |
|
X |
likert |
[[1, "I strongly disagree”, [2, "I disagree”], [3, "I slightly disagree”], [4, "Neutral”], [5, "I slightly agree”], [6. "I agree”], [7, "I strongly agree”]] |
The use of the device was very easy. |
|
Y |
text |
How is perceived the system by the user |
||
Z |
multiselect |
[“Left knee”, “left ankle”, “right knee”, “right ankle”, “none”] |
Were you perceiving unexpected pressure on some limbs? |
|
W |
select |
[“Left knee”, “left ankle”, “right knee”, “right ankle”, “none”] |
Which limb was receiving most pressure? |
With:
-
itemID: unique identifier (in the file) of the item. It can be a string, and contain any complex structure. The only constraint is that it has to be unique for the given questionnaire. -
type: definition of the type of answer expected-
Possible values:
value,text,boolean,likert,reverse_likert,select,multi_select
-
-
options: additional information to represent the answer options (if needed) -
text: item text -
unit: answer unit indication (if any)
Note that the 5 columns previously detailed are the minimum ones. A questionnaire definition may include more columns if this is needed for special computations.
Description: This file only contains the answers to each of the question asked.
Filename : subject_N_questionnaire_name.csv, where name refers to the Factor Meta Data File this questionnaire answer is related to.
File format: .csv
File structure: a table structure with the following content:
| itemID | answer |
|---|---|
2 |
4 |
1 |
4.8 |
Y |
"The installation was complex" |
X |
2 |
3 |
True |
Z |
[0, 3] |
W |
3 |
With:
-
itemID: the ID of the question answered, in relation with the questionnaire description file -
answer: the response of the person interviewed -
The administration order being implicitly encoded in the row order (i.e first question: 2, 2nd: 1, 3rd: Y, ….
This section is still under construction. Our intention is to provide a complete set of examples for three fields: human, humanoids, and wearable robots locomotion dataset.
In the following we use {} to factorize filenames:
-
Name
subject_{01_03}_jointAngles.csv, is used to name the three filessubject_01_jointAngles.csv,subject_02_jointAngles.csvandsubject_03_jointAngles.csv. -
Name
subject_{01_03}_run_{01-02}_jointAngles.csvrefers to files:subject_01_run_01_jointAngles.csv,subject_01_run_02_jointAngles.csv,subject_02_run_01_jointAngles.csv,subject_02_run_02_jointAngles.csv,subject_03_run_01_jointAngles.csv,subject_03_run_02_jointAngles.csv
The Laboratory HumanLab has done a study on Parkinson’s patients and recorded two subjects during overground walking, with inertial sensors. Three runs were recorded per subject. These are the files that they have produced to be compatible with the EUROBENCH Database.
-
Raw Files (format suggested, not mandatory)
-
raw_data.txt -
subject_{01-02}_run_{01-03}_imu_raw.cappa
-
-
Anthropometric Files
-
subject_01_info.yaml -
subject_02_info.yaml
-
-
Electromyography Files
-
subject_{01-02}_run_{01-03}_emg.csv
-
-
Gait Events Files
-
subject_{01-03}_run_{01-03}_gaitEvents.csv
-
-
Testbed configuration related data file
-
condition.yaml
-
There is only a unique testbed configuration file, as all runs are repetitions of the same experimental conditions.
The Laboratory ExoLab has done a study on healthy people wearing an H2 exoskeleton and recorded one subject during slope ascending, with optical markers. Three runs were recorded. The experiment was then repeated changing the support level of the exoskeleton
-
Raw Files (format suggested, not mandatory)
-
raw_data.txt -
cond_{01-02}_run_{01-03}_markers_raw.cappa
-
-
Anthropometric Files
-
info.yaml
-
-
Gait Events Files
-
cond_{01-02}_run_{01-03}_gaitEvents.csv
-
-
Testbed related data file
-
condition_{01-02}.yaml
-
label subject is discarded as a unique subject is considered.
The level of exoskeleton support is specified through a variable in condition_01.yaml and condition_02.yaml files.
The Laboratory HumanoidLab has done a study on the new walking pattern generator and recorded the robot during flat ground walking. Two runs were recorded. These are the files that they submit to be compatible with the EUROBENCH Database.
-
Raw Files (format suggested, not mandatory)
-
rosbag_{01-02}.bag(containing /tf topic) -
humanoid_markers_raw_{01-02}.cappa
-
-
.urdf File
-
robot_info.urdf
-
-
Gait Events Files
-
run_01_gaitEvents.csv -
run_02_gaitEvents.csv
-
-
Testbed related data file
-
condition.yaml
-
A laboratory studied human behavior during sit-to-stand activity. Two subjects were involved. Each subject were asked to perform 5 sit-to-stand, and data collection was stopped once the person was standing up. Then the operation was repeated with eyes closed, to see the importance of the visual clue. An instrumented chair was used, which is collecting a set of measures, in a format specified by the protocol.
-
Anthropometric Files
-
subject_{01-02}_anthropometry.yaml
-
-
Gait Events Files
-
subject_{01-02}_cond_{01-02}_run_{01-05}_jointAngle.csv
-
-
Chair sensors data
-
subject_{01-02}_cond_{01-02}_run_{01-05}_platformData.csv
-
-
Testbed related data file
-
condition_{01-02}.yaml
-
The eyes status (open/closed) is set through a parameter in files condition_01.yaml and condition_02.yaml.
-
David A. Winter. Biomechanics and Motor Control of Human Movement, 4th Edition. Willey (2009)