Pauline Maurice
email: pauline.maurice@polytechnique.org

Adrien Malais

Cl Élie Amiot

Nicolas Paris

Guy-Junior Richard

Olivier Rochel

Serena Ivaldi

Keywords: Human motion dataset, Industrial activities, Optical motion capture, Inertial motion capture, Ergonomics, Posture and action annotation

Improving work conditions in industry is a major challenge that can be addressed with new emerging technologies such as collaborative robots. Machine learning techniques can improve the performance of those robots, by endowing them with a degree of awareness of the human state and ergonomics condition. The availability of appropriate datasets to learn models and test prediction and control algorithms however remains an issue. This paper presents a dataset of human motions in industry-like activities, fully labeled according to the ergonomics assessment worksheet EAWS, widely used in industries such as car manufacturing. Thirteen participants performed several series of activities, such as screwing and manipulating loads in different conditions, resulting in more than 5 hours of data. The dataset contains the participants' whole-body kinematics recorded both with wearable inertial sensors and marker-based optical motion capture, finger pressure force, video recordings, and annotations by 3 independent annotators of the performed action and the adopted posture following the EAWS postural grid. Sensor data are available in different formats to facilitate their reuse. The dataset is intended for use by researchers developing algorithms for classifying, predicting or evaluating human motion in industrial settings, as well as researchers developing collaborative robotics solutions that aim at improving the workers' ergonomics. The annotation of the whole dataset following an ergonomics standard makes it valuable for ergonomics-related applications, but we expect its use to be broader in the robotics, machine learning and human movement communities.

Introduction

Work-related musculoskeletal disorders (WMSDs) are among the first causes of occupational diseases in many countries worldwide. They represent a major health issue and an important cost for companies and society [START_REF] Schneider | Occupational Safety and Health in Figures: Work-related Musculoskeletal Disorders in the EU-Facts and Figures[END_REF]US Bureau of Labor Statistics 2016). WMSDs develop when biomechanical demands at work repeatedly exceed the worker's physical capacity, which happens due to force exertion but also extreme postures [START_REF] Punnett | Work-related musculoskeletal disorders: the epidemiologic evidence and the debate[END_REF]. Improving work conditions in industry is therefore a major challenge that can be addressed with new emerging technologies such as collaborative robots to assist workers [START_REF] Marin | Optimizing contextual ergonomics models in human-robot interaction[END_REF]Kim et al. 2018a;[START_REF] Gopinathan | Improved humanrobot interaction: A manipulability based approach[END_REF][START_REF] Busch | Planning ergonomic sequences of actions in human-robot interaction[END_REF][START_REF] Pearce | Optimizing makespan and ergonomics in integrating collaborative robots into manufacturing processes[END_REF][START_REF] El Makrini | Task allocation for improved ergonomics in human-robot collaborative assembly[END_REF], or wearable sensors and devices to monitor and warn of health-threatening situations [START_REF] Vignais | Innovative system for real-time ergonomic feedback in industrial manufacturing[END_REF][START_REF] Yan | Wearable imubased real-time motion warning system for construction workers' musculoskeletal disorders prevention[END_REF]Kim et al. 2018b).

Benefiting from machine learning techniques, the efficacy of such assistive and warning devices can be further improved by endowing them with a degree of awareness of the human state and ergonomics condition. For instance, [START_REF] Coupeté | Multi-users online recognition of technical gestures for natural human-robot collaboration in manufacturing[END_REF] and [START_REF] Unhelkar | Human-aware robotic assistant for collaborative assembly: Integrating human motion prediction with planning in time[END_REF] perform human motion recognition and prediction respectively to plan the behavior of a collaborative robot that enables efficient and safe interaction in industrial applications. [START_REF] Malaisé | Activity recognition for ergonomics assessment of industrial tasks with automatic feature selection[END_REF] focus on ergonomics and propose an activity recognition module that automatically identifies non-ergonomic gestures during industry-oriented activities. [START_REF] Marin | Optimizing contextual ergonomics models in human-robot interaction[END_REF] learn surrogate models to compute in realtime the most ergonomic posture for a drilling task and adapt the motion of a collaborative robot accordingly. [START_REF] Peternel | Online human muscle force estimation for fatigue management in human-robot co-manipulation[END_REF] also use surrogate models to estimate muscle fatigue in a collaborative human-robot polishing task.

Machine learning algorithms, however, often require training data whose acquisition is time-consuming and necessitates specific equipment. Alternatively, algorithms can be trained and tested using publicly available human motion datasets. But while numerous motion datasets are available, they largely focus on daily life activities or sport movements [START_REF] Mandery | The kit whole-body human motion database[END_REF]CMU 2019;[START_REF] Kuehne | HMDB: a large video database for human motion recognition[END_REF][START_REF] Xia | View invariant human action recognition using histograms of 3d joints[END_REF][START_REF] Guerra-Filho | The human motion database: A cognitive and parametric sampling of human motion[END_REF]Ruffieux et al. 2015). Those datasets are therefore not adequate for learning models of industrial tasks. [START_REF] Mandery | The kit whole-body human motion database[END_REF] and CMU (2019) created comprehensive motion capture datasets which include trials of industry-oriented activities (e.g., manipulating a screw driver or hammer, lifting loads). Those industry-oriented motions are however very few in both datasets, mostly performed by a single subject and not repeated. Hence movement and posture variability cannot be accounted for, which limits the generalization ability of models of motion [START_REF] Perez | Posture and motion variability in non-repetitive manual materials handling tasks[END_REF][START_REF] Gaudez | Intrinsic movement variability at work. how long is the path from motor control to design engineering[END_REF]. Recently, Shah and colleagues created a human motion dataset of industrial activities to test their algorithms for human-robot collaboration [START_REF] Hayes | Interpretable models for fast activity recognition and anomaly explanation during collaborative robotics tasks[END_REF][START_REF] Kubota | Activity recognition in manufacturing: The roles of motion capture and semg+ inertial wearables in detecting fine vs. gross motion[END_REF]. However, only arm motions were recorded. Demonstrations of whole-body tasks and postures typically observed on assembly lines and evaluated in standard ergonomics assessment tools are therefore not available [START_REF] David | Ergonomic methods for assessing exposure to risk factors for work-related musculoskeletal disorders[END_REF]. Furthermore, supervised learning -which represents a large part of machine learning techniquesrequires labeled training data. Most existing human motion datasets include annotations of the activity being performed, but to the best of our knowledge, none of them include ergonomics-oriented labels.

This paper describes the creation of a dataset that contains industry-oriented motions with labels relevant for ergonomics studies, human movement studies, and model learning for collaborative robotics. Aside from its unique activities and labels, our dataset contains kinematic data from both wearable and external motion capture sensors, as well as videos, in order to facilitate the reuse of the data by various communities and for various applications. We created this dataset to advance our research in ergonomicsaware control of collaborative robots and prediction of whole-body movements, in the context of the European Project An.Dy [START_REF] Ivaldi | Anticipatory models of human movements and dynamics: the roadmap of the andy project[END_REF], where we envision collaborative robots and wearable sensors to improve the ergonomic conditions of workers in factories. But due to the growing interest in the latter topic on one hand, and the time and effort needed to create and annotate a dataset on the other hand, we envision that our human motion dataset will be of great interest for the broader research community.

The paper is organized as follows. Section 2 describes the data collection campaign, i.e., the activities recorded, the sensors used and the data collected, and the annotation process. Section 3 presents the organization of the dataset and evaluates the quality of the data. Finally, Section 4 concludes with closing remarks and future directions.

Methods

Awkward postures represent one of the major WMSDs risk factor [START_REF] Punnett | Work-related musculoskeletal disorders: the epidemiologic evidence and the debate[END_REF]. Consequently, most standard ergonomics assessment methods used in industry focus on postural evaluation [START_REF] David | Ergonomic methods for assessing exposure to risk factors for work-related musculoskeletal disorders[END_REF]) (e.g., the Ergonomic Assessment Worksheet (EAWS) [START_REF] Schaub | The european assembly worksheet[END_REF], the Rapid Upper Limb Assessment (RULA) [START_REF] Mcatamney | Rula: a survey method for the investigation of work-related upper limb disorders[END_REF], the Rapid Entire Body Assessment (REBA) [START_REF] Hignett | Rapid entire body assessment (reba)[END_REF], the Owako Working Posture Analysis System (OWAS) [START_REF] Karhu | Correcting working postures in industry: a practical method for analysis[END_REF]). Our dataset focuses on industry-oriented activities in which participants adopt a variety of postures typically evaluated in the aforementioned ergonomics worksheets. Note that the data were collected in a lab environment, and not in a real factory. Lab recording allows a ground truth measurement of the human kinematics with a marker-based optical motion capture system, which can hardly be used in a cluttered industrial setting. This section describes the process for data collection and annotation.

Participants

13 healthy adults participated in the data collection (9 males, 4 females). Their average age was 25.7 yrs (SD = 5.0 yrs), their average stature was 175.4 cm (SD = 7.9 cm), and their average body mass was 72.3 kg (SD = 14.4 kg). Participants were students and researchers with no or limited experience of industrial work. The data collection was approved by INRIA's ethical committee (COERLE). All participants gave written informed consent before starting the data collection. Participants were assigned a numerical ID (random number between 0 and 10000) which served to anonymize the data.

Experimental Set-up

The dataset targets postures and actions that are commonly observed in industrial settings such as assembly lines, and that are evaluated in standard ergonomics assessments (e.g., load manipulation, overhead work). Participants performed a series of 6 industry-oriented activities (Fig. 1), designed with the help of an industrial ergonomist and inspired by a car manufacturing use case:

• Screw high (SH): Take a screw and a bolt on a 75 cm-high table, walk to the shelf, screw at a height of 175 cm (performed with bare hands, i.e., no screwdriver). • Screw middle (SM): Take a screw and a bolt on a 75 cm-high table, walk to the shelf, screw at a height of 115 cm. • Screw low (SL): Take a screw and a bolt on a 75 cmhigh table, walk to the shelf, screw at a height of 25 cm (6 participants) or 60 cm (7 participants). • Untie knot (UK): Untie a knot placed on a 45 cm-high table.

• Carry 5 kg (C5): Take a 5 kg load on a 55 cm-high table, walk to the shelf, put the load on a 20 cm-high shelf. • Carry 10 kg (C10): Take a 10 kg load on a 55 cm-high table, walk to the shelf, put the load on a 110 cm-high shelf.

Items used in the activities were positioned to encourage the adoption of specific postures (e.g., raised arms, bent torso, crouching). Participants were however not given any instructions regarding the way to perform each activity, i.e., they were not verbally constrained to adopt a specific posture.

One trial consisted in performing all 6 activities successively in a given order, selected among 6 predefined sequences (Seq. 1: SL-SM-SH-UK-C10-C5; Seq. 2: SH-SM-SL-UK-C10-C5; Seq. 3: SL-SM-UK-C10-SH-C5; Seq. 4: SL-UK-C10-SM-C5-SH; Seq. 5: UK-C10-SH-SM-C5-SL; Seq. 6: UK-C10-C5-SH-SM-SL). Each participant performed 3 different sequences randomly chosen among the 6 possible ones, with 5 consecutive trials for each sequence, resulting in a total of 15 trials per participant. Each trial lasted approximately 90 s, and a break of about 2 min was allowed between each trial to limit fatigue. Before starting the data collection, participants practiced each activity a couple of times. Participants performed their trials using one of the 2 spatial organizations depicted in Fig. 2 (6 participants for organization A and 7 for organization B).

Participants started and ended each trial in a fixed position: standing arms along the body, the rear of the right foot on the origin of the motion capture world frame, with X axis facing forward (see Fig. 2).

The dataset therefore includes a diversity of participants, as well as several series of activities performed in different orders and with different set-ups, plus several repetitions of a same series for each participant, in order to account for inter and intra-individual movement variability.

Instrumentation

In human movement science, movement kinematics is traditionally recorded with specific motion capture systems. Among all existing modalities, marker-based optical motion capture remains the gold standard method to record human kinematics, mostly because of its accuracy. But recently, inertial motion capture using wearable sensors (IMU-based) has received a lot of attention. Wearable sensors are specifically interesting in cluttered environments -such as factories-where optical motion capture markers are easily occluded and reflective surfaces may perturb the measures. Image-based motion analysis is also undergoing a rapid development, and librairies such as OpenPose now enable reliable human pose detection from regular videos [START_REF] Cao | OpenPose: realtime multi-person 2D pose estimation using Part Affinity Fields[END_REF]. Though less accurate than marker-based motion capture and equally affected by occlusions, video recording has the advantage of being cheaper and less invasive than systems requiring wearable sensors or markers * . Since those 3 modalities -optical motion capture, inertial motion capture, and video-are in use in the human-robot interaction community, they were all included in the dataset. In addition to whole-body kinematic data, we captured finger forces and motions using a sensorized glove.

Inertial motion capture:

Participants were equipped with the Xsens MVN Link system † (Xsens, Enschede, The Netherlands) to record whole-body kinematics. The MVN Link system consists of 17 IMUs placed all over the body to measure the orientation of the body segments: 1 sensor on the head, 1 on the sternum, 1 on the pelvis, 1 on each scapula, 1 on each upper arm, 1 on each forearm, 1 on each hand, 1 on each thigh, 1 on each shank and 1 on each foot. Xsens MVN whole-body lycra suits of different sizes (M to XXL) were used to ensure correct positioning of all sensors.

The Xsens system was calibrated with the "N-pose and walk" calibration procedure every 5 trials, for each participant. The Xsens world frame was reinitialized at the beginning of each trial to match the Qualisys world frame. Xsens data were recorded at 240 Hz (recommended MVN Link capture rate) using the Xsens MVN Analyze software (version 2018.0.0).

Optical motion capture:

A Qualisys motion capture system ‡ (Qualisys, Göteborg, Sweden) was used to record whole-body kinematics. 12 Oqus cameras were positioned all over the workspace. Participants were equipped with 43 spherical reflective markers of diameter 12.5 mm. 39 markers were positioned on the body according to the Vicon Plug-In Gait Marker Placement recommendations (the sacral marker was not used) [START_REF] Vicon | Plug-in-Gait Reference Guide[END_REF]. Two additional markers were placed on each foot: one on the 1 st metatarsal head, on the midfoot side of the equinus break between forefoot and midfoot (labeled LTOA and RTOA for the left and right foot respectively), and one on the 5 th metatarsal head, on the midfoot side of the equinus break between forefoot and midfoot (labeled LTOB and RTOB). A calibration of the Qualisys system was performed at the beginning of the recording session for each participant. Qualisys data were recorded at 120 Hz (sub-multiple of Xsens capture rate) with the Qualisys Track Manager software (version 2.16). After the recording, markers were manually labeled by one of the experimenter in the QTM software, and the labeling was double-checked by a second experimenter.

Hand contact and finger flexion:

Participants were equipped with a prototype e-glove from Emphasis Telematics § (Emphasis Telematics, Athens, Greece) on their right hand (regardless of their handedness). The glove embeds 3 flexion sensors -on the thumb, index, and middle finger-and 4 pressure sensors -on the palm and on the fingertip of the thumb, index and middle finger. The flexion sensors measure the angle between the orientation of the palm and of the last phalange of the finger. The e-glove communicates with its server running on a computer via Wi-Fi. The e-glove internal time was synchronized with the computer Unix time before each recording session, using a synchronization function of the e-glove software. Data of the e-glove were recorded at 50 Hz with a proprietary software.

Video recording:

The data collection was recorded with 2 video cameras. Approximate positions of the cameras are displayed in Fig. 2. The positions of the cameras were not calibrated with the Qualisys motion capture system, however the grid formed by the floor tiles could be used to calibrate the cameras post-hoc (tiles dimension: 60 cm). Videos were recorded at 25 fps. A custom-written script based on the OpenPose library [START_REF] Cao | OpenPose: realtime multi-person 2D pose estimation using Part Affinity Fields[END_REF]) was used in a postprocessing phase to blur participants' faces and anonymize the videos.

Synchronization:

A custom-written script was used to launch and stop the recording of all sensors (all acquisition software were running on the same machine). Proper synchronization was achieved by time-stamping the data of all sensors, except the video cameras. Xsens and eglove software use Unix timestamps, while Qualisys uses machine-specific timestamps. The correspondence between the Unix time and the machine time was therefore logged at the beginning of each trial, and Qualisys timestamps were converted into Unix timestamps in a post-processing phase.

Conversely, video cameras were used separately and could not be automatically sychronized with the other sensors.

Annotations

After the data collection, 3 independent human annotators manually labeled the motions in all trials, using a taxonomy of actions and postures that we defined beforehand (Table 1).

For each trial, the 3 annotators were randomly selected among a pool of 4 annotators. We based the labels of our taxonomy on the EAWS worksheet, that we selected among all ergonomics assessment worksheets, because it is widely used in industry [START_REF] Schaub | The european assembly worksheet[END_REF]). The taxonomy contains 3 levels of annotations: general posture, detailed posture, and current action, detailed in Table 1. The general posture level describes the whole-body posture, mainly following the categories of postures listed in the EAWS worksheet (e.g., standing, kneeling, lying). Note that lying and sitting are not present in the dataset, but are included in the taxonomy for comprehensiveness with respect to the EAWS worksheet.

The detailed posture level combines the general posture with the position of the trunk and arms, following EAWS subcategories (e.g., bent forward, hand above head level). The current action level corresponds to goal-oriented actions, e.g., carrying a load, screwing, reaching. While the general posture and detailed posture labels can cover any motion, the list of current action labels contains only actions that are part of the activities performed in the dataset. Annotations were performed with the Anvil software ¶ , on the videos of the Xsens avatar replaying the participants' motions, exported from the MVN Analyze software. Each frame of the video was given 3 different labels, one for each level of the taxonomy (video framerate: 24 fps). Annotators could also consult the videos from the 2 cameras to help resolve potential labeling ambiguity in the Xsens generated videos (videos from the cameras include helpful contextual information, whereas Xsens videos only display the avatar's motion).

Dataset

The dataset containing the data from all the sensors and in several formats is available on Zenodo: https:// zenodo.org/record/3254403. The amount of data corresponds to approximately 5 hours of recording (13 participants, 15 trials per participant, about 90 s per trial). This section describes the organization of the dataset, and evaluates the quality and reliability of the data. Table 1. Taxonomy of postures and actions used for the annotation of the data. For the sake of clarity, the detailed posture labels presented in the table correspond to the subcategories of the EAWS worksheet only (arms and torso configuration). A full detailed posture label as used in the dataset is obtained by adding the label of the corresponding general posture as prefix, e.g., St U for standing upright, or Kn OH for kneeling with hands above head level.

File formats and organization

The dataset includes raw sensor data, videos, annotations of the postures and actions, and a description of the participants' features. the corresponding Xsens data, whereas it is not the case for the videos of the cameras. Annotations are stored in csv format, with labels of the 3 annotators and the 3 levels of the taxonomy within a same file. Table 2 summarizes the file formats available for each data type. Sensor data contain the following information:

• Qualisys -3D positions of the 43 markers placed on the body of participants. All csv files start with a header describing the nature of the data in each column and the corresponding units. Unix timestamps are used in all files, except in the Qualisys raw and motion analysis files which use machine specific timestamps and could not be converted (qtm and c3d format). Annotations files contain 2 timestamps: Unix timestamps that serve to align the annotations with sensor data, and Xsens video timestamps.

The dataset is structured as follows: first one folder for each sensor and data format (named sensor format), then one folder per participant (named after the participant's ID), and finally one file per trial. Each file is named after the participant's ID, set-up reference, sequence reference, and trial number within the sequence (1 to 5). The suffix of the file is .sensor.format to be easily identifiable. For instance, an Xsens csv file is named Participant 1 Setup A Seq 1 Trial 1.xsens.csv. https://tutorial.xsens.com/video/ body-measurements * * https://docs.vicon.com/display/Nexus25/Take+ subject+measurements+for+Plug-in+Gait † † Those data are not raw data as an Xsens internal post-processing step is automatically applied during the export. 3. Consistency of labels across the 3 annotators, in percentage of time frames. Agreement means that all 3 annotators gave the same label. Transition corresponds to time frames where only 2 annotators agree, due to a variation of the transitioning instant between 2 labels. Disagreement corresponds to insertion or deletion of a label, or a difference in posture/action interpretation. The only situation where no majority exists is a disagreement where all 3 annotators assigned a different label (disagreement no majority).

Evaluation

3.2.1 Label reliability: Posture and action labels were manually assigned by human annotators. As in any human annotation, the labels are therefore prone to subjective bias. Hence 3 independent annotators labeled the data to reduce the effect of this bias. We computed Fleiss' κ to assess interrater reliability [START_REF] Fleiss | Measuring nominal scale agreement among many raters[END_REF]. We excluded from the analysis the beginning and end of each trial, in which participants are immobile and annotation is straightforward (i.e., we excluded the time frames at the beginning and end where all 3 annotators labeled the posture as Standing Upright and the action as Idle; this immobile period corresponds to the starting and stopping process of all sensors and takes up to a dozen of seconds). The results indicate that labels are consistent across annotators for all 3 levels of annotations: κ = 0.91 for the general posture level, κ = 0.84 for detailed posture, and κ = 0.85 for current action. In addition, Table 3 presents the percentages of agreement and different disagreement types for the 3 levels of annotations. Importantly, total disagreement -where no majority is reached and a ground truth label cannot be decided-happens in only 1 % of the frames.

A significant portion of the frames where full agreement is not reached correspond to transitions, i.e., disagreement on the exact frame in which the participant moved from one posture/action to the next. The median duration of a transition is 80 ms (2 frames) for the general posture annotation level (90 th percentile: 440 ms), 80 ms for detailed posture (90 th percentile: 400 ms), and 120 ms (3 frames) for current action (90 th percentile: 320 ms). Though common in occurences, those transition disagreements therefore remain limited to a few frames each.

Completeness of optical motion capture data:

The positions of the Qualisys cameras were adapted for each of the 2 setups specifically, in order to track all markers as exhaustively as possible. The wide range of postures adopted by the participants as well as the objects they manipulated however made occlusions of some markers inevitable. Table 4 presents, for each marker, the percentage of frames in which the marker is tracked, summarized across all trials. The median of the tracking value is greater or equal to 95 % of a trial duration for 35 markers out of 43. The leg markers were especially well tracked (given the complexity of the setup), with a median value above 97.9 % for all markers, and a 5th percentile value above 90 % for 11 out of 16 markers. The RBHD head marker was not visible at all in most trials of one participant, which explains its low 5th percentile value (33.9 %). Conversely, the low tracking scores of the markers placed at the front of the torso (CLAV, STRN, and to a lesser extent RASI and LASI) result from occlusions of those markers during bent postures in all participants. Eventually, the arm markers were tracked with a median above 95 %, exept for the markers placed on the ulna styloid process (external wrist markers: RWRB and LWRB), which were easily occluded during object manipulation. Those occlusions are more prominent for the right wrist, possibly due to the e-glove structure partly hiding the marker in certain hand configurations (median of RWRB: 70.3 %, 5th percentile: 10.3 %). Note that in a few trials, a marker fell during the recording: in such situations, the tracking of the fallen marker stops when it detaches from the participant's body. Overall, the redundancy of markers ensures that the participants' whole-body posture can be reconstructed for most frames, even though some makers are not tracked. The reconstruction of the hand and forearm orientation should however be considered carefully when wrist markers are lost. The difficulty to fully track all markers even in a simplified lab setting highlights the advantage of wearable sensors, such as IMUs, for human whole-body motion capture in cluttered environments, such as factories.

Applications

We envision that the dataset presented in this paper will be used by researchers developing algorithms for classifying, predicting or evaluating human motions in industrial settings, as well as researchers developing collaborative robotics solutions that aim at improving the workers' ergonomics. Currently, the dataset has already been used in our team for automatic activity recognition [START_REF] Malaisé | Activity recognition for ergonomics assessment of industrial tasks with automatic feature selection[END_REF], and is currently used to develop algorithms for automatic ergonomics assessment. We used Xsens and e-glove data along with the postures and actions annotations to train recognition models based on Hidden Markov Models. The outcome is a module that successfully recognizes the current human activity and automatically identifies non-ergonomic movements on-line ‡ ‡ .

The numerous demonstrations of the industry-inspired activities, performed by people with different anthropometric features, make our dataset ideal to conduct research in probabilistic movement primitives for action representation, and more generally to learn models of human actions at whole-body level.

This dataset could also be used by the computer vision community, to test algorithms for human posture and pose tracking in a cluttered environment. The dataset notably includes challenging postures, such as being strongly bent ‡ ‡ See video here: https://youtu.be/CSTsM2xJjxg and crouched, and occlusions due to the environment. It could therefore be of interest for benchmarking algorithms for visual estimation of human posture [START_REF] Sun | Deep high-resolution representation learning for human pose estimation[END_REF], and for learning predictive visual models of human motion from the camera pixels directly, as recently done for manipulators [START_REF] Xie | Improvisation through physical understanding: Using novel objects as tools with visual foresight[END_REF]. Remarkably, each time frame of the recorded activities is annotated. This enables to track human postures in the time dimension as well (i.e., track on a sequence of images), and not only in fixed images as in many popular human posture datasets such as [START_REF] Andriluka | 2d human pose estimation: New benchmark and state of the art analysis[END_REF]. Finally, our dataset is expected to be useful to the robotics community to simulate human activities in industrial settings. Simulating human activities and estimating the human ergonomics can serve to synthesize efficient collaborative robots' behaviors, for instance by addressing the issues of human-aware navigation [START_REF] Khambhaita | Assessing the social criteria for human-robot collaborative navigation: A comparison of human-aware navigation planners[END_REF] and of human-robot task allocation and coordination [START_REF] Shah | Improved human-robot team performance using chaski, a human-inspired plan execution system[END_REF].

Conclusion

This paper presents the creation and organization of a publicly available human motion dataset containing industryoriented activities and annotated with ergonomic labels. The dataset includes 5 hours of whole-body motion capture data both from a wearable inertial system (Xsens) and from an external optical system (Qualisys), video data from 2 cameras, and finger pressure force data measured with a sensorized glove. The dataset also includes annotations of the actions and postures of the participants according to the EAWS ergonomic worksheet, which makes it unique and especially relevant for studies and data-driven developments with a focus on ergonomics. Importantly, the dataset includes a diversity of participants and several repetitions of each task per participant to account for inter as well as intraindividual movement variability. All data are available in several formats, both proprietary and non-proprietary, to facilitate their reuse by various communities and for various applications. Due to the growing interest in improving ergonomics conditions at work, specifically with robotics and wearable assistance, on one hand, and the time and effort needed to create and annotate a dataset on the other hand, we believe that our human motion dataset will be of great interest for the broader research community.

( a )Figure 1 .

 a1 Figure 1. Picture and Xsens avatar view of a participant performing the 6 activities included in the data collection.

Figure 2 .

 2 Figure 2. Spatial organization of the items used during the data collection. 6 participants used set-up A and 7 used set-up B. The blue frame corresponds to the motion capture world frame (Qualisys and Xsens). The grey feet silhouettes represent the participant's initial and final position in each trial. The positions of the tables and shelves are exact, whereas the positions of the 2 cameras are approximative.

  • Xsens -Magnetic field, 3D linear acceleration, and orientation (quaternion) of the 17 sensors † † . -3D position, orientation (quaternion), linear and angular velocity, and linear and angular acceleration of the origin of the 23 body segments of the Xsens avatar. -Angles of the 22 joints (3 DoFs each) of the Xsens avatar. -3D position of the Xsens avatar's center of mass. • E-glove -Flexion angle of the first 3 fingers of the right hand. -Pressure force on the right palm and fingertip of the first 3 fingers of the right hand.

Table 2 .

 2 The latter are stored in a csv file which contains : ID, age, gender, handedness, body mass, body dimensions required to create the Xsens avatar || , additional Plug-In Gait measurements ** , reference of the set-up used File formats available for each type of data.

	Data	Format
	Participants' features csv
	Xsens	mvn; mvnx; c3d; bvh; csv
	Qualisys	qtm; c3d; csv
	E-glove	csv
	Videos	mp4
	Annotations	csv

(Fig.

2

), and reference number of the 3 sequences of activities performed. Sensor data are available in csv format and, when existing, in proprietary format and in standard motion analysis format (c3d and bvh). Videos of both cameras and videos of the Xsens avatar used for the annotations are available in mp4 format. Note that the start and end of the Xsens videos are exactly aligned with the start and end of

Table 4 .

 4 Percentage of frames in which the Qualisys markers are tracked by the motion capture system. Median and 5th percentile are computed across all trials of all participants. Marker names follow the Plug-in Gait Marker Placement naming[START_REF] Vicon | Plug-in-Gait Reference Guide[END_REF]).

	Prepared using sagej.cls

Prepared using sagej.cls

* It is, however, often difficult to track the entire human body in factories using only video cameras, because of the high number of required cameras and the occlusions due to the working environment. Cameras may therefore be effective for tracking human movements across the workspace, but not for a precise estimation of the body posture -which is necessary for an accurate ergonomics evaluation. † https://www.xsens.com Prepared using sagej.cls

Acknowledgements

This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 731540 (An.Dy). The equipment used to create the database was partly funded by the CPER IT2MP of Région Grand-Est, France. The authors would like to thank Lars Fritzsche from IMK Automotive, for his help with selecting relevant activities for the dataset, and Xsens Technologies and Emphasis Telematics for the loan of their equipment used in the data collection.

Declaration of conflicting interests

The Authors declare that there is no conflict of interest.


Nicolas Desnos
email: nicolas.desnos@site-eerie.ema.fr

Sylvain Vauttier
email: sylvain.vauttier@site-eerie.ema.fr

Christelle Urtado
email: christelle.urtado@site-eerie.ema.fr

Marianne Huchard
email: huchard@lirmm.fr

Automating the Building of Software Component Architectures

Assembling software components into an architecture is a difficult task because of its combinatorial complexity. There is thus a need for automating this building process, either to assist architects at design time or to manage the self-assembly of components at runtime. This paper proposes an automatic architecture building process that uses ports, and more precisely composite ports, to manage the connection of components. Our solution extends the Fractal component model. It has been implemented and experiments have been run to verify its good time performance, thanks to several optimization heuristics and strategies.

Introduction and Motivation

Software engineering aims at optimizing the cost of design and maintenance while preserving both the quality and reliability of the produced software. Componentbased development techniques try to enhance reuse [START_REF] Crnkovic | Component-based software engineering -new challenges in software development[END_REF][START_REF] Garlan | Software Architecture: a Roadmap[END_REF][START_REF] Brown | The current state of CBSE[END_REF]. The design process of an application is led by an architect and decomposes into three steps: he selects components, defines an architecture by assembling them 3 and then uses a tool to control the consistency of the assembly to determine if the assembled components are compatible. Components are generally described as a set of interfaces that define what a component can provide and must require. Component assemblies are then built by connecting component interfaces together [4][START_REF]OMG: Corba components, version 3.0[END_REF][START_REF] Traverson | Abstract model of contract-based component assembly (2003) AC-CORD RNTL project number 4 deliverable[END_REF][START_REF] Bruneton | Fractal specification -v 2.0.3[END_REF][START_REF] Plásil | SOFA/DCUP: Architecture for component trading and dynamic updating[END_REF].

Most existing works do not provide architects with any guidance during the selection and assembly steps. They rather focus on checking the validity of a previously built architecture [START_REF] Traverson | Abstract model of contract-based component assembly (2003) AC-CORD RNTL project number 4 deliverable[END_REF][START_REF] Plásil | Behavior protocols for software components[END_REF][START_REF] Hacklinger | Java/A -Taking Components into Java[END_REF][START_REF] Farías | On components with explicit protocols satisfying a notion of correctness by construction[END_REF][START_REF] De Boer | The OMEGA component model[END_REF]. The consistency check techniques cannot be used in an iterative building process because of the combinatorial complexity [START_REF] Inverardi | Static checking of system behaviors using derived component assumptions[END_REF]. To guide the architect, we propose an efficient approach to automatically build potentially valid architectures. It produces a reduced set of preselected component assemblies on which it is relevant to perform checks to find valid architectures. It relies on the use of ports, and more precisely of composite ports, to describe known usages of components. A construction algorithm has been successfully implemented and experimented in the Fractal component model [START_REF] Bruneton | Fractal specification -v 2.0.3[END_REF].

The remainder of this paper is organized as follows. Section 2 discusses the issues raised by the building of valid architectures and introduces a component model which features primitive and composite ports. Section 3 describes a basic algorithm to automatically build architectures along with its optimizations. Section 4 concludes and draws perspectives.

Building Valid Architectures

An Augmented Component Model to Ease Construction

Not to start from scratch, we choose to extend an existing component model named Fractal [START_REF] Bruneton | Fractal specification -v 2.0.3[END_REF] 4 . Classically, a Fractal component is described as a black box that defines the services the component provides and requires through server and client interfaces and a content (called the architecture) that allows a component to be recursively described. Fractal components are assembled into architectures by connecting client interfaces to server interfaces. This allows components to collaborate by exchanging messages along these connections.

The Fractal model is first extended with ports. As in UML2 [4], ports are used to group together the client and server interfaces that are used by a component in a given collaboration. Ports are thus used to specify various usage contexts for components. We define two kinds of ports. Primitive ports are composed of interfaces, as in many other component models [4,[START_REF] Traverson | Abstract model of contract-based component assembly (2003) AC-CORD RNTL project number 4 deliverable[END_REF][START_REF] Hacklinger | Java/A -Taking Components into Java[END_REF][START_REF] De Boer | The OMEGA component model[END_REF][START_REF] Aldrich | Archjava: connecting software architecture to implementation[END_REF]. Composite ports are composed of other ports. Composite ports are introduced to structurally represent complex collaborations. Figure 1 shows an architecture where ATM is an example of component, Question one of its provided interfaces, Transaction one of its required interfaces and Money Withdraw its composite port which is composed of the two Money Dialogue and Money Transaction primitive ports. Two primitive ports are connected together when all the interfaces of the first port are connected to interfaces of the second port (and reciprocally). A composite port is connected when all the primitive ports it is composed of (directly or indirectly) are connected. Component architectures can then be built by connecting together component ports (what entails interface connections). Next section details how ports, and more precisely composite ports, make the building of architectures easier.

Validity of an Architecture

An architecture is said to be valid if it is both correct and complete.

Correctness. Stating the correctness of an architecture relies on techniques that verify the coherence of connections, to check whether they correspond to possible collaborations between the linked components. These verifications use various kinds of meta-information (types, protocols, assertions, etc.) associated with various structures (interfaces, contracts, ports, etc.).

A first level of correctness, called syntactic correctness, can be verified by comparing the types of the connected interfaces [START_REF]OMG: Corba components, version 3.0[END_REF][START_REF] Bruneton | Fractal specification -v 2.0.3[END_REF]. This ensures that components can "interact" because the signatures of the functionalities to be called through the required interface match the signatures of the functionalities of the provided interface. A second level of correctness, called semantic correctness [START_REF] Dijkman | Verifying the correctness of component-based applications that support business processes[END_REF][START_REF] Plásil | Behavior protocols for software components[END_REF], can then be verified to determine if the connected components can "collaborate" i.e. exchange sequences of messages that are coherent with each other's behavior. Semantic verifications require that protocols -valid sequences of messages -be defined. The semantic correctness of the connection between two ports is handled as a classic comparison of their associated protocols. This is a time-consuming process because of the highly combinatorial complexity of the algorithms used to compare all the possible message sequences [START_REF] Inverardi | Static checking of system behaviors using derived component assumptions[END_REF].

Completeness. A component architecture is built to achieve some functional objectives [START_REF] Crnkovic | Component-based software engineering -new challenges in software development[END_REF][START_REF] Dijkman | Verifying the correctness of component-based applications that support business processes[END_REF][START_REF] Inverardi | Software Architecture for Correct Components Assembly[END_REF]. Functional objectives are defined as a set of functionalities to be executed on selected components. The set of connections in the architecture must be sufficient to allow the execution of collaborations that reach (include) all the functional objectives. Such an architecture is said to be complete.

Starting from a set of components corresponding to the functional objectives, a naive algorithm can be to try to build an architecture where all the interfaces of all the components are connected, so that all the execution scenarios may be executed. When no solution exists in the current architecture to connect an interface, the repository is searched for a component that has a compatible interface. If one exists, it is added to the architecture and the interfaces are connected. If several connections are possible, they represent alternative building paths to be explored. In case a dead end is reached, the construction is backtracked to a previous configuration, in order to try alternative connection combinations. The problem with this building process is the size of the solution space to be explored. It is amplified by the cost of the semantic verifications that must be calculated for any candidate connection between two components. Therefore, the automatic construction of valid architectures still is an open problem. We then have studied different ways to reduce the complexity of the building process.

3 Taming the Complexity of Automation

Using Composite Ports to Connect Components

To reduce the complexity, the building process can try to connect only the interfaces that are useful to reach the functional objectives. However, the proper use of a functionality of a component is not independent from other functionalities. The behavior protocol of a component specifies the different valid execution scenarios where a functionality is called. The execution of a scenario requires the connection of all the interfaces that it uses: regarding the scenario, these interfaces are said to be dependent. Thus, a given functional objective can be reached only when precise sets of (dependent) interfaces, corresponding to valid scenarios, are connected. An analysis of the behavior protocol of a component could be used to determine those scenarios but a means is required to capture and to express this information in an explicit and simple way, in order to ease the connection process. Ports are introduced as a kind of structural metainformation, complementary to interfaces, that group together the interfaces of a component corresponding to a given valid scenario. Ports could be produced automatically, by the analysis of behavior protocols or be manually added by the designer in order to document a given usage of the component.

Port connections make the building process more abstract (port-to-port connections) and more efficient (no useless connections). Considering a port that needs to be connected, the availability of a compatible port is an important issue. The more numerous interfaces are in a given port, the more specific the port type is and the less chances exist to find compatible ports. Composite ports are used to solve this issue: they allow short scenarios, composed of few interfaces, to be described as small primitive ports that are then composed together to describe more complex scenarios. Large flat primitive ports can then be replaced by small primitive ports hierarchically structured into larger composite ports. The result is that smaller ports are less specialized and thus provide more connection possibilities. From a different point of view, a primitive port can be considered as the expression of a constraint to connect a set of interfaces both at the same time and to a unique component. A composite port is the expression of a constraint to connect a set of interfaces at the same time but possibly to different components. As they relax constraints, composite ports increase the amount of possible connection combinations. Moreover, composite ports provide a means to precisely specify how interfaces must be connected: to a unique componentfor functionality calls to produce cumulative effects -or to distinct components.

Building Quasi-valid Architectures

Semantic verifications are very expensive. Our approach keeps semantic verifications separated from the building process so as not to waste time verifying the semantics of connections as long as the completeness of the architecture cannot be guaranteed. To achieve this, a quasi-valid architecture is first built. A quasi-valid architecture is a syntactically correct and complete architecture. The connection of a port enforces the completeness of an architecture, regarding the execution of a scenario. Once all the ports corresponding to the functional objectives are connected, an architecture is quasi-valid. Quasi-validity is a precondition for an architecture to be valid.

We wrote an algorithm that automatically builds quasi-valid architectures. The building process uses a set containing the ports that still have to be connected -the functional objective set (FO-set). The FO-set contains only primitive ports: composite ports are systematically decomposed into the set of primitive ports they are directly or indirectly composed of. The FO-set is initialized with the ports that correspond to the functional objectives. One of the primitive ports is picked up from the FO-set and a compatible port is searched for. If a compatible unconnected port is found, the ports are connected together. If the compatible port belongs to a component that does not yet belong to the architecture, the component is added to the architecture. If the chosen compatible port belongs to a composite port, all the other primitive ports that composed the composite port are added to the FO-set. This way, no port dependencies -and therefore no interface dependencies -are left unsatisfied. The building process is iterated until the FO-set is empty. All the initial primitive ports that represent functional objectives are then connected along with all ports they are recursively dependent upon: the resulting architecture is quasi-valid. Several special situations can occur during this process. When several free compatible ports are candidate for connection, they correspond to alternate solutions that are to be explored. Conversely, when no free compatible port is found the building algorithm has reached a dead end. The construction is then backtracked to a previous situation where unexplored connection possibilities exist. Our algorithm is implemented as the searching of a construction tree using a depth-first policy. Breadth search is used to explore all the alternate construction paths. This complete exploration of the construction tree is used to guarantee that any possible solution is always found.

Strategies, Heuristics and Experiments

The performance of the building algorithm has been measured. For this purpose, we have implemented a small environment that generates random component sets which provide different building contexts, in size and complexity. Once a component set is generated, an arbitrary number of ports can be chosen as functional objectives and the building algorithm be launched. Our experiments show that the combinatorial complexity of the building process is very high. To be able to use our approach in demanding situations, such as the deployment and configuration of components at runtime, we have studied various heuristics that speed up the building process.

Building Minimal Architectures. A first strategy is to try to find not all the possible architectures but only the most interesting ones. Minimality is an interesting metrics for the quality of an architecture [START_REF]Component-Based Software Quality: Methods and Techniques[END_REF]. We apply this minimality criterion to the number of connection. Less connections entail less semantic verifications, less interactions and therefore less conflict risks. Less connections also entail more evolution capabilities (free ports). To efficiently search for minimal architectures, we have added a branch-and-bound strategy to our building algorithm. The bound is the maximum number of connections allowed for the construction of the architecture. When this maximum is reached when exploring a branch of the construction tree, the rest of the branch can be discarded as any new solution will be less optimal than the previously found (pruning).

Min Domain Heuristic. This heuristic is used to efficiently choose ports from the FO-set. The port for which a minimum of free compatible ports exists is chosen first. This minimizes the effort to try all the connection possibilities: in case of repeated failures, this allows impossible constructions to be detected sooner.

Minimum Effort Heuristic. In the branch-and-bound strategy, every time the bound is lowered, the traversal of the tree is speeded up. To connect a primitive port, the algorithm first chooses the free compatible primitive port that belongs to the "smallest" composite port. It corresponds to the choice of the less dependent ports, that minimize future efforts to connect them.

No New Dependency Heuristic. When a compatible port can be found in the FO-set its connection will add no new dependency, and furthermore, satisfy two dependencies at once. Indeed, when a port belongs to the FO-set, the other primitive ports it depends on are already in the FO-set.

Look-ahead Strategy. Calculi can be used to predict if the traversal of the current construction branch can lead to a minimal solution. They are based on an estimate of the minimum number of connections required to complete the building. A soon as the sum of the existing connections with this estimate is greater than the bound, the current branch can be pruned. A simple example of this estimate is the number of ports in the FO-set divided by two.

Experimental Results: an Outline. Experiments show that performance mainly depends on the number of initial functional objectives. This is logical since more functional objectives implies not only a larger search space but also more constraints, thus more failures and backtracks. For example, series of experiments have been run with a library of 38 generated components. Each component had at most 4 primitive ports and at most 2 composite ports. Each primitive port had at most 5 interfaces. Starting with 5 initial functional objectives, the following typical results are obtained. A basic construction algorithm, implemented in Java and executed on a standard computer, without any of the above optimizations, is able to find 325 000 quasi-valid architectures, when stopped after 15 hours. This gives an idea of the gigantic size of the search space. Among those quasi-valid architectures, the largest ones are composed of 48 connections. The smallest architecture found is composed of 18 connections. As a comparison, the optimized construction algorithm finds the only minimal architecture composed of 7 connections in less than a second. This motivates our proposal for an efficient building approach. It is difficult to build quasi-valid architectures, because the more frequent ones are rather large (around 40 connections in the above example). It is even more difficult to build minimal ones, because they are scarce in a large search space.

Conclusion and Perspectives

While other works focus on the validation of complete architectures, our work studies the building process of architectures and proposes a practical solution to automate it. It enables the candidate architectures, on which validation algorithms are to be applied, to be systematically searched for. Besides the many optimization strategies and heuristics used for the traversal of the construction space, the use of ports, and particularly of composite ports, is prominent in our approach. As they express the dependencies that exist between interfaces, ports provide a simple means to evaluate the completeness of an architecture. Finally, being composed of interfaces, they provide means to abstract the many connections of interfaces to single connections and thus reducing the combinatorial complexity of the building.

A perspective for this work is to integrate it to a component-based development framework, for example as part of a trading service, to provide a means to manage the self-assembling of components in open, dynamic systems (autonomic computing).

Figure 1

 1 Figure 1 shows the example of an architecture built by our algorithm. It starts with a FO-set that contains the Money Withdraw primitive port of the Client component. This port is taken out of the FO-set and a connection is searched for. It is connected to the compatible Money Dialogue primitive port of the ATM component. As this latter port belongs to the Money Withdraw composite port, it depends on the Money Transaction primitive port which is thus added to the FO-set before the building process iterates. The Money Transaction primitive port of the ATM component is now considered for connection. It is compatible with the Money Transaction primitive port of the Bank component which belongs to the composite port Money Withdraw. After connection, the other primitive port of this composite port, Request Data, is in turn added to the FO-set. At the next iteration, the Request Data primitive port of the Bank component is connected with the compatible primitive port Provide Data of the Database component. As this primitive port does not belong to a composite port, no primitive port is to be added to the FO-set. The FO-set is now empty: the architecture of Fig.1 is quasi-valid.

Fig. 1 .

 1 Fig. 1. A quasi-valid architecture built with the support of composite ports

In these works, we will consider that the selected components need no adaptation (or might have already been adapted).

We choose Fractal mainly because it is a hierarchical composition model that supports component sharing, its structure is simple but extensible and respects the separation of concerns principle and an open-source implementation exists.