Patient Ntumba

Georgios Bouloukakis

Nikolaos Georgantas

Interconnecting and Monitoring Heterogeneous Things in IoT Applications

Keywords: Internet of things, Middleware Protocols, Interoperability Artifacts, Emergency Response

Internet of Things (IoT) applications incorporate heterogeneous devices that employ different middleware protocols (MQTT, CoAP, WebSocket, etc). In this paper we present an extension of our cross-integration platform which supports the interoperability of IoT devices. In particular, we introduce the VSB Web Console which enables the development and monitoring of applications with heterogeneous IoT devices. We showcase our approach using the Fire Detection scenario.

Introduction

Internet of Things (IoT) devices such as smart thermostats, activity trackers, drones, parking sensors, etc, enable developers to create new types of smart applications. Such devices (or Things) are introduced and deployed by major tech actors using their own proprietary APIs and protocols. This results in the deployment of highly heterogeneous devices in terms of both hardware and software resources. Additionally, the Things' diversity -i.e., resource-tiny, resourceconstrained and resource-rich, prevents the development of applications that rely on a single standard/protocol. Hence, enabling interactions in the IoT requires to deal with the heterogeneity issue.

Existing interoperability efforts are based on i) bridging communication protocols; [START_REF] Ponte | [END_REF][START_REF] Al-Fuqaha | Toward better horizontal integration among iot services[END_REF]; and ii) providing common API abstractions [START_REF] Cherrier | D-lite: Building internet of things choreographies[END_REF]. The former approach focuses only on the data and primitive conversion between a specific set of protocols. In the latter approach, developers have to build their application by relying on a single protocol or API. In the context of our work, we have developed the eVolution Service Bus (VSB) [START_REF] Bouloukakis | Integration of Heterogeneous Services and Things into Choreographies[END_REF] which enables the interconnection of Things employing different IoT protocols at the middleware layer (i.e., MQTT [4], CoAP [START_REF] Shelby | The Constrained Application Protocol (CoAP)[END_REF], WebSocket [START_REF] Fette | The WebSocket Protocol[END_REF], HTTP, etc). VSB follows the ESB paradigm where a common intermediate bus protocol is used to interact with multiple Things employing middleware-layer protocols or IP-based Gateways hosting IoT devices. To bridge heterogeneous Things with the intermediate bus

The work is supported by the research associate team ACHOR (inria.fr/en/associateteam/achor) and the EU-funded H2020 project FIESTA-IoT (fiesta-iot.eu) Fig. 1. VSB Web Console Architecture protocol, we automatically synthesize interoperability software artifacts, the so called Binding Components (BCs). BCs perform the mapping between data and primitives of the bridged protocols. VSB is utilized as core component of the H2020 CHOReVOLUTION [START_REF]CHOReVOLUTION EU project[END_REF] project and enables interactions in IoT choreographies with heterogeneous devices.

In this paper, we rely on VSB and we introduce the VSB Web Console. Our console provides a graphical interface which enables developers to register their services/Things employing middleware IoT protocols. Then, based on their use case scenario, interactions can be enabled between the registered (and possibly heterogeneous) Things. Finally, the resulting application can be monitored through our console. Monitoring options include: message passing and management of the deployed artifacts. To demonstrate our work, we design a use case for fire detection inside a forest. Hence, we register real sensors (temperature sensors), devices (a drone) and services (an estimation service) to our console. Then, to enable the interconnection of heterogeneous devices, we automatically synthesize and deploy interoperability artifacts. Finally, the forest fire detection interactions can be monitored using our console.

In the following section, we provide an architectural overview of our console, as well as details about its implementation. Then, we provide an overview of the forest fire detection scenario. Finally, we demonstrate its implementation in the VSB Web Console -this includes a video representation.

System Overview

As depicted in Fig. 1, our console is implemented based on MVC standard. Below we describe its main components which are used to interconnect heterogeneous Things and monitor IoT applications: User Interface (UI): is a Web interface used by an IoT developer for registering services/Things by providing information such as the: i) role (provider, consumer), ii) host address, iii) employed middleware protocol, iv) supported operations and their input/output data. This process results to the creation of the corresponding Generic Interface Description Language (GIDL) model. We provide the GIDL models of our use case scenario at https://goo.gl/Lnzziz. The UI is also used for interconnecting the registered services/Things using drag and drop actions and automated code generation. Finally, is used to manage and monitor the overall IoT application.

Controller: it processes all actions performed at the UI, which are forwarded to the Thing Management component and the corresponding module: i) registration, ii) generation, iii) monitoring and iv) orchestration.

To interconnect and monitor two heterogeneous Things, e.g., a drone that sends/receives notifications using the UDP/MQTT protocols; and a media device that receives notifications using the WebSocket protocol, our console operates as follows: the generation module binds the drone's and the media device's GIDL models to automatically generate the BC that is responsible to map data and primitives described in their GIDL models. Then, the orchestration module interconnects these devices by deploying the BC in the console host node. To monitor the devices and the deployed BC, our console (monitoring module) implements a listener API which receives published data from the IoT app on a specific port.

Implementation. The VSB Web Console has been implemented using Java 8 and the GIDL interface is a metamodel developed using the Eclipse Modeling Framework. Our console can be downloaded through: https://gitlab.inria. fr/pntumba/vsb-web-console/wikis. We also provide 2 videos for demonstrating the usage of our console: the 1st one: https://youtu.be/v7ucoSgbZCI, demonstrates the process of installing the console. Additionally, we show how a developer can register, interconnect and monitor (heterogeneous or not) Things.

Forest Fire Detection Scenario

Continuous monitoring of forests for early fire detection is of primary importance. In 2007, there were more than 80 human losses in Greece and 670,000 acres burned because of fires [START_REF]Greek forest fires[END_REF]. In this section, we use our console to showcase the implementation, deployment and monitoring of a fire detection inside a forest. Implementing such a scenario requires the following sensors and devices: Temperature or smoke sensors: these can be deployed inside a forest in order to monitor the forest conditions and push warning notifications. In the context of our demo, we deploy these sensors into a Raspberry Pi and we employ the CoAP protocol to push notifications. Estimator service: it can be deployed inside a fire department for receiving forest-related notifications. We assume that the estimator service employs the HTTP protocol to receive notifications. Drone: a PARROT AR DRONE 2.0 located at the fire department -used to inspect the forest-area upon a warning notification. Such a device deploys specific protocols to: i) accept pilot-commands through the UDP protocol and ii) transmit video stream, location and drone speed to an MQTT broker. Drone handler: a device handling the drone. We have deployed this device into a BeagleBone Black [1] platform. This platform employs the HTTP protocol to receive commands from the estimator service and locate the corresponding drone into the forest. Media streaming devices: such devices receive video streaming data by the drone. We separate them in two categories: i) a device that employs an MQTT subscription mechanism; and ii) a smartphone that employs the WebSocket protocol.

Creating an IoT application with the above heterogeneous devices is not a trivial task. Initially, the developer has to deploy the services/things, select the proper protocol supporting the constrained sensors/devices or use the already employed protocol by the device (e.g., drone). Hence, the developer has to be aware of multiple APIs and protocols for interconnecting its heterogeneous services/things and create the application.

In this work, we enable developers to register services/Things into the VSB Web Console which can be installed in their private or public machine (see Section 2). Then, IoT applications can be created through simple drag and drop actions. Heterogeneous interconnections are solved by generating automatically BCs. Finally, our console provides a monitoring interface to manage BCs (start/stop actions) and message passing detection.

In the 2nd video we show the complete implementation and monitoring of the Fire Detection scenario: https://youtu.be/SJeiqJkBhls.

Conclusion

To facilitate the development of IoT applications, we have developed the VSB Web Console. Using our console, developers are able to register services/Things, create IoT apps through drag and drop actions, interconnect heterogeneous Things in an automated manner, and finally monitor the resulting applications.

In future, we intend to provide an API to enable developers accessing the Controller directly (not only through the UI). Furthermore, we aim to enable a distributed deployment of BCs.


Jing Chang

Damien Chablat

Fouad Bennis
email: fouad.bennis@ls2n.frliangma@tsinghua.edu.cn

Liang Ma

Using 3D Scan to Determine Human Body Segment Mass in OpenSim Model

Keywords: Musculoskeletal disorders, biomechanical analysis, virtual human model, Open-Sim, body segment mass

Biomechanical motion simulation and dynamic analysis of human joint moments will provide insights into Musculoskeletal Disorders. As one of the mainstream simulation tools, OpenSim uses proportional scaling to specify model segment masses to the simulated subject, which may bring about errors. This study aims at estimating the errors caused by the specifying method used in OpenSim as well as the influence of these errors on dynamic analysis. A 3D scan is used to construct subject's 3D geometric model, according to which segment masses are determined. The determined segment masses data is taken as the yardstick to assess the errors of OpenSim scaled model. Then influence of these errors on the dynamic calculation is evaluated in the simulation of a motion in which the subject walks in an ordinary gait. Result shows that the mass error in one segment can be as large as 5.31% of overall body weight. The mean influence on calculated joint moment varies from 0.68% to 12.68% in 18 joints. In conclusion, a careful specification of segment masses will increase the accuracy of the dynamic simulation. As far as estimating human segment masses, the use of segment volume and density data can be an economical choice apart from referring to population mass distribution data.

Introduction

Musculoskeletal Disorders (MSDs) makes up the vast proposition of the occupational diseases [START_REF]Eurogip: Déclaration des maladies professionnelles : problématique et bonnes pratiques dans cinq pays européens[END_REF]. Inappropriate physical load is viewed as a risk factor of MSD [START_REF] Chaffin | Occupational Biomechanics[END_REF]. Biomechanical analysis of joint moments and muscle loads will provide insight into MSDs.

Over the past decades, many tools have been developed for biomechanical simulation and analysis. OpenSim [START_REF] Delp | Opensim: open-source software to create and analyze dynamic simulations of movement[END_REF] is a virtual human modeling software that has been widely used for motion simulation and body/muscle dynamic analysis [START_REF] Thelen | Using computed muscle control to generate forward dynamic simulations of human walking from experimental data[END_REF][START_REF] Kim | Estimation of lumbar spinal loading and trunk muscle forces during asymmetric lifting tasks: application of whole-body musculoskeletal modelling in opensim[END_REF]. The simulation in OpenSim should be based on a generic virtual human that consists of bodies, muscles, joint constraints, etc., as shown in Figure 1.

A simulation is generally started by scaling the generic model specifically to the subjects geometric and mass data. The subjects body geometric data is obtained using a motion capture system, which records the spatial positions of flash reflecting markers that attached to the specific locations of the subject; then the generic OpenSim model is adjusted geometrically with attempts to minimize the position deviations between virtual markers and corresponding real markers. This makes a subject-specific model out of the generic model.

The geometrical adjustment increases the accuracy of posture simulation and kinematic analysis that follow. For accurate dynamic analysis, the body segment inertial parameters, such as segment masses, should also be adjusted specifically to each subject. In OpenSim, this adjustment is carried out by scaling the mass of each segment of the generic model proportionately with respect to the whole body mass of the subject. This method of determining segment mass is based on the assumption that the mass distribution among body segments is similar among humans, which is not always the case. For example, the mean mass proportion of the thigh has been reported to be 10.27% [START_REF] Clauser | Weight, volume, and center of mass of segments of the human body[END_REF], 14.47% [START_REF] De Leva | Adjustments to zatsiorsky-seluyanov's segment inertia parameters[END_REF], 9.2% [START_REF] Okada | Body segment inertia properties of japanese elderly[END_REF], and 12.72% [START_REF] Durkin | Analysis of body segment parameter differences between four human populations and the estimation errors of four popular mathematical models[END_REF], which indicates significant individual difference. Therefore, the scaling method used by OpenSim is likely to cause errors in the following dynamic analysis. There is a necessity to estimate the errors.

This paper aims at estimating the errors caused by the scaling method used in OpenSim. Firstly, subject's segment masses are determined based on the accordingly 3D geometric model constructed with the help of 3D scan. The determined data is taken as an approximation to the true value of the subject's segment mass. Secondly, this set of data, as well as the proportionately scaled segment mass data, is used to specify a generic OpenSim model. Errors caused by proportionately scaling are calculated. Finally, influence of the errors on dynamics analysis is checked on a simulation of a walking task.

The method to approximate subject's segment masses, model specification and dynamic simulation are described in chapter 2. Results are presented in chapter 3. These results are then discussed in chapter 4, followed by a conclusion in Chapter 5.

Methodology

Approximating segment masses with 3D scan

A whole-body 3D scan was conducted to a male subject (31 years old, 77.0 kg, 1.77 m) with a low-cost 3D scanner (Sense T M 3D scanner). Before scanning, reflecting markers were placed on the subject to notify the location of each joint plate as shown in Figure 2. The locations of the joint plates were set according to [START_REF] Drillis | Body segment parameters[END_REF] [START_REF] Drillis | Body segment parameters[END_REF], which meant to facility the dismemberment of the 3D model. During scanning, careful caution was taken to make sure that no extra contact between limbs and the torso. The scanned 3D model was stored in a stl mesh file, as shown in Figure 3. Then the 3D model was dismembered into 15 parts in the way that described by Drillis (1969) [START_REF] Drillis | Body segment parameters[END_REF]. Body markers and body parts lengths are referred. An example of the dismembered body part (Pelvis) is shown in Figure 4. Then, the volume of each body part was calculated.

To analyze the results obtained, the water displacements of eight distal body parts (hands, lower arms, feet, lower legs) were also measured, as described by Drilis (1966) [START_REF] Drillis | Body segment parameters[END_REF].

Specification of OpenSim models to the subject

In this step, a generic OpenSim model is specified to our subject in aspect of body segment mass. The model is developed by Delp S.L. et al (1990) [START_REF] Delp | An interactive graphicsbased model of the lower extremity to study orthopaedic surgical procedures[END_REF] (http://simtk-confluence.stanford.edu:8080/display/OpenSim/Gait+2392+an 2354+Models). It consists of 12 bodies, 23 degrees of freedom, and 52 muscles. The unscaled version of the model represents a subject that is about 1.8 m tall and has a mass of 75.16 kg. The approximating body segment mass data obtained from the process in chapter 2.1 as well as the proportionately weight-scaled body segment mass data is used to specific the generic model. The former is considered as the yardstick to estimate the error of the latter.

Dynamic simulation in OpenSim

An simulation is conducted on the two specific models. Simulation data comes from previous researches [START_REF] John | Contributions of muscles to mediolateral ground reaction force over a range of walking speeds[END_REF]. The subject walks two steps in 1.2 s in an ordinary gait. Data of Spatial posture is collected at a frequency of 60 Hz and the and ground reaction forces at a frequency of 600 Hz. Inverse dynamic analysis is conducted on both models. Joint moments are calculated and compared between the two models.

Results

The estimation of body segment masses

Significant difference was found between volumes calculated from the 3D scanned geometric model and that measured by water displacement. For lower leg, the difference is as large as 27% (4.5 l vs. 3.3 l). To approximate the real segment masses, assumption is made that the volume distribution of the 3D model merged by 3D scan among head, torso, pelvis, and upper limbs is the same as that of the real subject. Density data of the body parts [START_REF] Wei | The application of segment axial density profiles to a human body inertia model[END_REF] were used to calculate the whole-body density of the subject, which, as well as body weight, gives estimation of whole-body volume. Then the overall volume was distributed to each segment with respect to the relative volume ratio of the 3D geometric model. In this way, segment volumes and masses are approximated.

Relative data is shown in Figure 6. The whole-body volume calculated from the 3D geometric model is 7.31% larger than the estimated whole-body volume (81.81 l to 76.24 l). The whole body density is estimated to be 1.01 g/ml. Mass proportion of the thigh is about 11.30%, which is between that reported by Clauser et al., (1969) (10.27%) [START_REF] Clauser | Weight, volume, and center of mass of segments of the human body[END_REF], Okada (1996) (9.2%) [START_REF] Okada | Body segment inertia properties of japanese elderly[END_REF] and by De Leva (1996) (14.47%) [START_REF] De Leva | Adjustments to zatsiorsky-seluyanov's segment inertia parameters[END_REF], Durkin & Dowling (2003) (12.72%) [START_REF] Durkin | Analysis of body segment parameter differences between four human populations and the estimation errors of four popular mathematical models[END_REF].

Errors analysis of the OpenSim scaled model specific to the subject

Segment masses generated by proportionately scale and 3D modeling are used to specify the Open-Sim generic model, which bring about two specific models (noted as scaled model and approximate model). Figure 7 shows the segment mass data of the two models. Errors of the scaled model segment mass are between 4.06% and 47.42%. The most significant error merges from foot data which, however, represents only a small part of the overall body mass.

Motion simulation and dynamic analysis

Both the proportionately scaled segment mass data and approximate segment mass data are used to specify the OpenSim generic model, bringing about two specific models (noted as scaled model and approximate model).

Motion simulation is conducted on the two models. The simulated motion includes two steps of walking, lasting for 1.2 s. Since the two models differ in only segment mass, no difference in kinematic analysis is shown. As an example, the angles, velocity and acceleration of right hip flexion is shown in Figure 8. Inverse dynamic analysis on the two models generates different results. Figure 9 shows the right hip flexion moments calculated from the two models. With the approximate model as yardstick, the error of the calculated right hip flexion moment of the scaled model has a mean of 1.89 Nm, which is 10.11% of its mean absolute value. A total of 18 joint moments was calculated. The means of error percentage vary from 0.65% to 12.68%, with an average of 5.01%. Relative data are shown in Table 1.

Discussions

The use of 3D scan in the estimation of body segment masses

In previous researches, the inertial parameters of human body segment are usually determined by two means: (i) Applying predictive equations generated from database [START_REF] De Leva | Adjustments to zatsiorsky-seluyanov's segment inertia parameters[END_REF], (ii) Medical scanning of live subjects [START_REF] Lee | Measurement of body segment parameters using dual energy x-ray absorptiometry and three-dimensional geometry: An application in gait analysis[END_REF], and (ii) Segments geometric modelling [START_REF] Davidson | Estimating subject-specific body segment parameters using a 3-dimensional modeller program[END_REF]. The use of the first one, as stated by [START_REF] Durkin | Analysis of body segment parameter differences between four human populations and the estimation errors of four popular mathematical models[END_REF] [START_REF] Durkin | Analysis of body segment parameter differences between four human populations and the estimation errors of four popular mathematical models[END_REF], is limited by its sample population. Furthermore, the difference in segmentation methods makes it difficult to combine various equations [START_REF] Pearsall | The study of human body segment parameters in biomechanics[END_REF]. The second method, medical scanning, such as dual energy X-ray absorptiometry is more accurate in obtaining body segment inertial parameters [START_REF] Durkin | The measurement of body segment inertial parameters using dual energy x-ray absorptiometry[END_REF]. But it is more expensive and time-consuming.

In this study, body segment masses are estimated by segment density data and segment volume. 3D scan is used to estimate body segment volume. In this process, errors may merge from two aspects.

First, it is assumed that density data of each segment is constant among humans. This assumption may bring errors. Traditional body composition method defines two distinct body compartments: fat and lean body (fat-free). Fat has a density of 0.90 g/ml, while lean body has a density of 1.10 g/ml [START_REF] Lukaski | Methods for the assessment of human body composition: traditional and new[END_REF]. Subjects body fat rate may influence the segment density. However, the range of density variation is smaller than that of the mass distribution. Therefore, the use of density and volume may reduce the estimation error of segment mass. For example, in the current study, the thigh, with a volume of 8.35 l, holds a mass proportion that would vary from 9.74% (all fat, density = 0.90 g/ml) to 11.90% (fat-free, density = 1.10 g/ml). This range is much narrower than that found in previous research (from 9.2% [START_REF] Okada | Body segment inertia properties of japanese elderly[END_REF] to 14.47% [START_REF] De Leva | Adjustments to zatsiorsky-seluyanov's segment inertia parameters[END_REF]).

Second, 3D scan is used to build up 3D geometric model and calculate segment volumes. Significant difference exists between volumes calculated and volumes measured by water displacement. To approximate the real volume, assumption is made that the 3D geometric model has the same volume distribution with that of the subject, which may bring error.

In summary, as a simple and low-cost method of segment mass determination, the use of density data and 3D geometric model is more likely to reduce the estimation error. 3D scan is an easy way to construct a 3D geometric model, but attention should be payed to the model's volume errors. The method used in this study to approximate the real segment volumes with 3D scanned model needs to be examined in future researches.

The error and error significance of the proportionately scaled model

Proportional scaling is efficient to specific a generic model. In this study, relative errors of segment masses of the scaled model are between 4.06% to 47.42%. The error of torso mass is 4.09 kg, which takes up to 5.30% of the overall body weight. In the following motion simulation, these errors bring about difference in the calculated joint moment. Means of the difference of calculated joint moments are from 3.65% to 12.68%. This suggests that a careful specification of segment masses will increase the accuracy of the dynamic simulation.

Conclusions

This study aims at estimating the errors and their influences on dynamic analysis caused by the scaling method used in OpenSim. A 3D scan is used to construct subject's 3D geometric model, according to which segment masses are determined. The determined segment masses data is taken as the yardstick to assess OpenSim proportionately scaled model: errors are calculated, and influence of the errors on dynamics analysis is examined.

As a result, the segment mass error reaches up to 5.31% of the overall body weight (torso). Influence on the dynamic calculation has been found, with a average difference from 3.65% to 12.68% in the joint moments.

Conclusions could be drawn that (i) the use of segment volume and density data may be more accurate than mass distribution reference data in the estimation of body segment masses and (ii) a careful specification of segment masses will increase the accuracy of the dynamic simulation significantly. This current work is a study to determine inertial parameters of the human body segment in biomechanical simulation. It explores new, more precise and simpler ways to implement biomechanical analysis. This work is a step towards characterizing muscular capacities for the analysis of work tasks and predicting muscle fatigue.

Fig. 1 .

 1 Fig. 1. A generic OpenSim model.

Fig. 2 .

 2 Fig. 2. Body markers that indicate the location of joint plates.

Fig. 3 .

 3 Fig. 3. The 3D geometric model of the subject generated by 3D scan.

Fig. 4 .

 4 Fig. 4. The mesh of pelvis dismembered from the whole-body 3D model.

Fig. 5 .

 5 Fig. 5. The OpenSim model used for error analysis.

Fig. 6 .

 6 Fig. 6. Coordinate (q), velocity (ω), acceleration (dω/dt) of right hip flexion in the motion.

Fig. 7 .

 7 Fig. 7. Right hip flexion moments calculated from the two models.

Table 1 .

 1 Volume, density and mass of the whole body and segments.

	Foot-l Foot-r Hand-l Hand-r		1.06 0.89 0.49 0.58		1.00 1.00 0.46 0.46		1.00 1.00 0.46 0.46	1.08 1.08 1.11 1.11	1.08 1.08 0.51 0.51
	Lower	leg-r	4.53		3.35		3.35	1.08	3.62
	Lower	leg-l	4.42		3.25		3.25	1.08	3.51
	Upper	leg-r	8.65				8.29	1.04	8.62
	Upper	leg-l	8.74				8.37	1.04	8.71
	Lower	arm-r	1.34		1.12		1.12	1.10	1.23
	Lower	arm-l	1.38		1.01		1.01	1.10	1.11
	Upper	arm-r	1.72				1.65	1.06	1.75
	Overall Pelvis Head Torso Upper	arm-l	81.81 11.29 5.65 29.90 1.63				76.24 10.81 5.41 28.64 1.56	1.01 1.01 1.07 0.92 1.06	10.92 5.79 26.35 1.66
			Volume(l)-3D scanned	model	dis-Volume(l)-water	placement	Volume(l)-estimated	Density(kg/l)[13]	Estimated mass(kg)

Table 2 .

 2 Errors of proportionally scaled segment masses with respect to the approximate masses.

	Calcaneus	0.87	1.28	0.41	0.53%	47.42%
	Upper leg-l Upper leg-r Lower leg-l Lower leg-r Talus	8.71 8.62 3.51 3.62 0.07	9.46 9.46 3.76 3.76 0.10	0.75 0.84 0.25 0.15 0.03	0.98% 1.10% 0.33% 0.19% 0.04%	8.67% 9.80% 7.26% 4.06% 47.42%
	Torso	38.91	34.82	-4.08	-5.30%	-10.49%
	Pelvis	10.92	11.98	1.06	1.37%	9.66%
		Approximate mass(kg)	Proportionally scaled mass	(kg)	Absolute error (kg)	Percentage of absolute error	in overall body weight	Relate error

Table 3 .

 3 Errors of the joint moments calculated from the scaled model, with respect to that from the approximate model

		Mean of error	Mean of instant	Mean of error per-
		(Nm)	moment (Nm)	centage
	Pelvis tilt	6.73	64.12	10.50%
	Pelvis list	4.06	37.78	10.75%
	Pelvis rotation	1.02	17.78	5.74%
	Right hip flexion	1.89	18.73	10.11 %
	Right hip adduction	0.48	18.57	2.60 %
	Right hip rotation	0.07	3.47	2.13 %
	Right knee angle	0.65	19.21	3.40 %
	Right ankle angle	0.31	38.68	0.80 %
	Right subtalar angle	0.06	9.02	0.65 %
	Left hip flexion	2.27	17.90	12.68 %
	Left hip adduction	0.80	24.99	3.18 %
	Left hip rotation	0.10	4.28	2.23 %
	Left knee angle	0.83	19.37	4.28 %
	Left ankle angle	0.36	30.18	1.19 %
	Left subtalar angle	0.07	7.65	0.91 %
	Lumbar extension	5.47	60.85	9.00 %
	Lumbar bending	3.05	37.37	8.17 %
	Lumbar rotation	0.33	17.98	1.85 %

Acknowledge

This work was supported by INTERWEAVE Project (Erasmus Mundus Partnership Asia-Europe) under Grants number IW14AC0456 and IW14AC0148, and by the National Natural Science Foundation of China under Grant numbers 71471095 and by Chinese State Scholarship Fund. The authors also thank D.Zhang Yang for his support.