Eurobench Data Format 1. Motivation 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. 2. Data files and format 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). Figure 1. Main elements of the data processing chain 2.1. Terminology 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. 2.2. Filename format, and generalities Generally speaking pre-processed data should follow the following contextualized pattern: subject_X_cond_Y_run_Z_[type].csv The 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). Table 1. Pre-processed files format (list to be updated) 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_3 For 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. 2.2.1. incomplete data 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 ..... 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. 2.2.2. Protocol with multiple but similar sensors 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: 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.csv for the force sensor labelled tag1 subject_N_run_R_wrench_tag2.csv for the force sensor labelled tag2 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 … … … … … … … … … … … … … This option is only accepted if the data logged is using the same timestamp. 2.3. Global reference frame 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]: x axis aligned with the gait direction y axis 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. 3. Bipedal system specification files 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. 3.1. Unified Robot Description Format (URDF) file 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. 3.2. WR segments description (URDF) file 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. 3.3. Human information file 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 3.4. Humanoid anthropometric measures file 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. 4. Testbed configuration file 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: 2 The exact content of the file is defined by the protocol itself. All controlled variables, as defined in the template spec should be defined in that file. 5. Raw Data Files 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. 6. Pre-Processed Data 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. 6.1. Joint angles file 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: Table 2. Joint angle file structure and unit time r_hip_y r_hip_x r_hip_z r_knee_y r_knee_x r_knee_z … … … sec deg deg deg deg deg deg … … … Joint labels should refer to the names provided within the human model document. 6.2. Joint torques file Description: This file shall contain all the measured joint torques. filename root: jointTorques File format: .csv File structure: Table 3. Joint torque file structure and unit time r_hip_x r_hip_y r_hip_z r_knee_x r_knee_y r_knee_z … … … sec N.m N.m N.m N.m N.m N.m … … … Joint labels should refer to the names provided within the human model document. 6.3. Joint center 3D trajectory Description: This file shall contain all the measured trajectories of the joints. Filename root: jointTrajectories. File format: .csv File structure: Table 4. 3D joint center file structure and unit time r_ankle_x r_ankle_y r_ankle_z r_knee_x r_knee_y r_knee_z … sec m m m m m m … Joint labels should refer to the names provided within the human model document. 6.4. Landmark 3D trajectory Description: Contain the 3D position of particular landmarks that are tracked during the experimentation. Filename root: landmarkTrajectories. File format: .csv File structure: Table 5. 3D landmark file structure and unit time landmark_1_x landmark_1_y landmark_1_z landmark_2_x landmark_2_y landmark_2_z … sec m m m m m m … 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. 6.5. Body Center of Mass 3D trajectory 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: Table 6. COM position file structure and unit (velocity and acceleration are only added if measured) time x y z vel_x vel_y vel_z acc_x acc_y acc_z sec m m m ms-1 ms-1 ms-1 ms-2 ms-2 ms-2 6.6. Joint States Description: contains the state of a set of joints along time. Filename root : jointStates File format: .csv File structure: Table 7. Joint states file structure and unit (velocity and acceleration are only used if measured) time label_1_pos label_1_vel label_1_acc label_2_pos … sec rad rad.s-1 rad. s-2 rad … where label_i should be replaced by the name of the joint, as specified in the protocol documentation. A jointState file can refer to joint(s) of a robotic device, or to joint(s) of an element of the testbed. 6.7. Angular Momentum around the Center of Mass 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: Table 8. Angular Momentum file structure and unit time x y z sec Js Js Js where Js stands for Joule second (equivalent to kgm2s⁻1). bibliography: []: B.C Bennett, S.D. Russell, P. Sheth, M. F. Abel. Angular momentum of walking at different speeds. Human Movement Science, Colume 29, Issue 1, 2010 (link) [] H. Herr, M. Popovic. Angular momentum in human walking. Journal of Experimental Biology, Volume 211, Issue 4, (2008) - (link 6.8. Inertia Tensor 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: Table 9. Inertia tensor file structure and unit time xx xy xz yx yy yz zx zy zz sec kgm² kgm² kgm² kgm² kgm² kgm² kgm² kgm² kgm² 6.9. Wrench file Description: This file shall contain wrench (force and torque) measured by a force sensor. Filename root: wrench File format: .csv File structure: Table 10. Wrench file structure and unit time force_x force_y force_z torque_x torque_y torque_z sec N N N N.m N.m N.m 6.10. Ground Reaction Forces file Description: This file shall contain forces measured by force platforms. Filename root: grf File format: .csv File structure: Table 11. Ground Reaction Forces file structure and unit time f_x f_y f_z p_x p_y p_z t_x t_y t_z sec N N N m m m N.m N.m N.m where f stands for force, p for the center of pressure, and t for torques. 6.11. Electromyography file Description: This file shall contain all the recorded EMG signals from the human subject. Filename root: emg File format: .csv Table 12. EMG file structure and unit time label_1 … label_i … s mV mV mV mV 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.. Table 13. List of EMG muscles and labels considered. Suffixes _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 6.12. Gait events file 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. Table 14. 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 6.13. Gait Parameter file 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. Table 15. List of gait events and its considered labelling and units Gait Event Label type unit Left Cadence cadence_left scalar step/min Left Walking Speed walking_speed_left scalar m/s Left Stride Time stride_time_left scalar s Left Step Time step_time_left scalar s Left Stride Length stride_length_left scalar m Left Step Length step_length_left scalar m Left Step Width step_width_left scalar m Left Single Support single_suport_left scalar s Right Cadence cadence_right scalar step/min Right Walking Speed walking_speed_right scalar m/s Right Stride Time stride_time_right scalar s Right Step Time step_time_right scalar s Right Stride Length stride_length_right scalar m Right Step Length step_length_right scalar m Right Step Width step_width_right scalar m Right Single Support single_suport_right scalar s Double Support double_support scalar s 6.14. Physiological data 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: Table 16. Physiological file structure time hr hrv rr gsr ecg sec bpm sec bpm mS mV 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). 6.15. Testbed / Platform specific data recorded 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. 6.16. Human Factor metrics 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. 6.16.1. Factor Meta Data File 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: Table 17. Meta Data File structure sample 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. 6.16.2. Factor Data File 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: Table 18. Meta Data File structure sample 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, …. 7. Examples 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 files subject_01_jointAngles.csv, subject_02_jointAngles.csv and subject_03_jointAngles.csv. Name subject_{01_03}_run_{01-02}_jointAngles.csv refers 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 7.1. Example 1 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. 7.2. Example 2 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. 7.3. Example 3 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 7.4. Example 4 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. 8. References David A. Winter. Biomechanics and Motor Control of Human Movement, 4th Edition. Willey (2009) Vicon Documentation: Plug-in Gait kinematics variables Vison Documentation: About the Plug-in Gait model 1. Each repetition of an experiment. Synonym of trial (e.g. One experiment has 10 subjects and each subject executes 5 runs).