In sports science, motion data collected from athletes is

used to derive key performance characteristics, such as stride length

and stride frequency, that are vital coaching support information. The

sensors for use must be more accurate, must capture more vigorous

events, and have strict weight and size requirements, since they must

not themselves affect performance. These requirements mean each

wireless sensor device is necessarily resource poor and yet must be

capable of communicating a considerable amount of data, contending

for the bandwidth with other sensors on the body. This paper analyses

the results of a set of network traffic experiments that were designed

to investigate the suitability of conventional wireless motion sensing

system design � which generally assumes in-network processing - as

an efficient and scalable design for use in sports training

Cheng, L.

Cheng, Z.

Fan, F.

Hailes, S.

Leung, D.

Yang, Y.

English

UCL Discovery

Poster Abstract: An Experimental Study on a Motion Sensing System for Sports Training Lawrence Cheng, Steve Hailes, Denis Leung, Fu-Yi Fan, Yang Yang, Zhen Cheng Department of Computer Science, University College London, Malet Place, London, WC1E 6BT, UK. {l.cheng, s.hailes}@cs.ucl.ac.uk Abstract￿In sports science, motion data collected from athletes is used to derive key performance characteristics, such as stride length and stride frequency, that are vital coaching support information. The sensors for use must be more accurate, must capture more vigorous events, and have strict weight and size requirements, since they must not themselves affect performance. These requirements mean each wireless sensor device is necessarily resource poor and yet must be capable of communicating a considerable amount of data, contending for the bandwidth with other sensors on the body. This paper analyses the results of a set of network traffic experiments that were designed to investigate the suitability of conventional wireless motion sensing system design ￿ which generally assumes in-network processing - as an efficient and scalable design for use in sports training.  Keywords￿In-network data processing; motion sensors; on-body server; sport￿s training; wireless sensor networks. I.   INTRODUCTION Motion data sensors (e.g. accelerometers, gyros, etc.), or motion data  sensing units (SUs)1, are devices that collect kinematics data - such as acceleration, magnetometer readings, and rate of turn (i.e. gyro) information - of specific parts of a (human) body. These devices are wearable [4], i.e. they are small in size (e.g. the size of a coin), lightweight (e.g. 10-15g), and battery-powered. Motion data, such as the acceleration of an athlete￿s foot and Centre of Mass (CoM), permit us to deduce the stride length and stride frequency of an athlete, as well as stance time, sway and a host of other measures that are useful in training [2].  In the SEnsing for Sport And Managed Exercise (SESAME) project [1], we have been developing a wireless motion sensing system that collects motion data from different moving body segments during sprint training sessions, with the intention of processing the data and reporting derived measures to coaches in either true or near real-time. As in many of the existing motion sensing systems [3][4], the architecture of SESAME has been based on an assumption of in-network data processing. In-network processing means raw data collected by (a set) of individual on-body SUs are initially processed (i.e. filtered, compressed, and more) by an on-board Processing Unit (PU) or an on-body server (such as a PDA). The processed data is then delivered to a remote repository where more computational intensive operations on the data will be carried out. In-network processing is generally considered as beneficial in many on-body wireless sensor network scenarios because bandwidth is limited. However, on-body wireless motion sensing systems for sport￿s training face a different set of design challenges. This paper investigates whether the design of conventional sensing systems, i.e. the assumption of in-network processing, do in reality represent suitable candidates for a sports training motion data sensing system.                                                           1 In this paper, we distinguish a device that samples (raw) data to be a ￿Sensing Unit￿; whereas we define a device that processes the collected sample data to be a ￿Processing Unit￿. Both units may be on the same physical device (i.e. a ￿sensor￿). II. DESIGN CHALLENGES A typical deployment of motion sensing will be expected to have multiple such sensors placed both on different limb segments and on the torso, to record a full picture of motion. Such sensors clearly compete for the wireless medium ￿ directly in the case of the CSMA/CA protocols in use in commonly used 802.15.4- and 802.11-based radio systems. Moreover, different sensors are in substantially different radio environments ￿ bit error rate (BER) (and, consequently, packet error rate (PER)) is affected by a range of effects, including relative antenna orientation, distance, shadowing and so forth. In the case of a sensor placed on the foot and one placed in the CoM, these factors will change throughout a stride, and in a way that is different to the changes expected for a sensor placed on the arm.  Our first design challenge was that an approach to sensing based on the combination of COTs products for SUs and PUs has substantial physical limitations. For example, an accelerometer weights only 10-15g. A simple PU, say the widely-used Telos mote, itself weighs 23g. Both require battery power. Thus, the combined weight of SU and PU can easily be of the order of 70g ￿ which is unacceptable when one considers that an average professional athlete running shoe weighs just over 200g and that multiple sensors will be needed. As a consequence, a choice has to be made ￿ design bespoke sensors and/or trade off weight allocated to the PU against the higher data rate of unprocessed data (and the consequent effect on contention for the medium, PER, etc.). This design requirement effectively rules out the possibility of attaching a PU to each individual SU. Using a commercially-available motion sensing system, i.e. the MTx system developed by xSens, as a reference2: the device is configured to sample at 120Hz by default, but can be configured to sample at (up to a maximum of) 500Hz. Sample size may vary from 20 bytes to 60 bytes, depending on what type of data being collected. Assuming 13 sensors per athlete3, a 200Hz sampling rate and 60-byte samples, the aggregated data rate is in the order of 1.25Mbps. If one assumes multiple athletes within the same space, this number is further multiplied.  Note that, in reality, accelerometers report data that are noisy, partly, as a result of the transfer function between the accelerometer and the limb segment that results from a non-rigid form of attachment. The nature of such noise remains to be explored ￿ the simple low-pass filters currently in place are not in themselves adequate. To design better filters, there is a need to capture data. In order to explore this design space, there is a                                                          2 We chose MTx as a reference because of its completeness: an MTx sample represents all essential (6 Degree of Freedom) motion-related data including acceleration, magnetometer readings, gyros readings, timestamp, etc.  3 One on each foot, shin, thigh, forearm, upper arm; and one for CoM, upper back and head. need to carry out a set of experiments, to establish a baseline on the actual capacity of the system in different configurations.  III. EXPERIMENT RESULTS & ANALYSIS The conventional approach to in-network data processing requires data to be aggregated at an on-body server (the on-body server is referred to as the On-Athlete Sensor Integration System (OASIS) in this paper); we are interested in what would be the packet loss rate of such system when data rate is high. The key questions are: what would be the network behaviour when in-network processing is deployed in the system? What would be the effect of sensor position on wireless on-body transmission?  In our experiments, data is sent from three on-body sensors (i.e. one on the foot, knee and arm) to the OASIS on the lower-back, then off to the remote repository. The OASIS, in conventional system design, is the on-body server where in-network processing, such as data fusion on data from multiple sources, is carried out. Packet loss rate is measured. We elected to use Gumstix as the all on-body devices (i.e. for both sensors and OASIS) because it is small in size yet it enables us to send packets of different sizes, and provides the facility for data logging, which are the essential functions for data analysis. Our experiments focus on 60m sprinting (which involves the most rapid body movement). 802.11b is chosen as the wireless technology in our system because: a) it is the most common standard and indeed the only standard that is supported across all the wireless interfaces on the embedded devices that we are using; and b) 802.11b supports an (advertised) maximum data rate of 11Mbps, which is sufficient for our experiments. UDP is used because we are interested in the end-to-end packet loss rate in a running system. Our experiments are conducted in-door so that it is possible to use video-based systems as a comparative gold standard when accessing the accuracy of the inertial data. An access point was placed on a table (at a height of 1m from the floor) in the middle of the two ends of a 60m track (i.e. 30m from each end).   Figure 1b shows the loss rate at the OASIS is high (~35% when the on-body sensors are 20m away from the access point). This means that many packets are lost at the first lag of the transmission. The overall, end-to-end packet loss rate at 20m is ~45%. The packet loss rate is worst when the on-body sensors are further away from the access point (with an end-to-end loss rate at ~80% at 40m, Figure 1a). This suggests that using embedded devices ￿ that have small(er) buffer sizes, (relatively) low(er) processing power, or a specific way of the 802.11 protocol stack is implemented - creates a bottle-neck in the system should data rate is high. One possible way to address this issue, is to configure the on-body network (i.e. the one between the sensors and the OASIS) and the repository network (i.e. the one between the OASIS and the remote repository) to use non-overlapping channels. A common alternative way is to packetise the samples, i.e. buffer multiple samples, prior to transmission in order to reduce overhead. The results of our second experiment show that the packet loss is least when a packet size of ~1,200 bytes was used. The feasibility of this solution, however, would depend on whether a suitable hardware candidate for in-network processing can be identified (i.e. one that is small and lightweight enough). Our other experiment results show that, the packet loss rate is different for sensors placed on different parts of the body (8% for foot, 2% for knee, >1% for arm). The reason for this is likely to be the height dependency of reception ￿ changing Fresnel zones and ground reflection effects [5]. Figure 2 shows our first sensor prototype: the MTx sensor connects to a connectBlue (CB) WiFi module through a RS232 interface.  Figure 2 ￿ A wireless MTx+CB IV. CONCLUSION Wireless motion sensing systems for sports applications, particularly those for use in sprint training, have strict size and weight limitations. In engineering such systems, it is necessary to trade off the processing performed in-network against the need for high sampling rates, extreme portability, low data losses, and real time data delivery all from multiple sensors, many of which are in rapid motion and experiencing high accelerations. The conventional approach in which on-body data aggregators are used to capture information from individual sensors is problematic when sampling rates are high and weight restrictions mean that the aggregators themselves have limited capabilities. In such circumstances, where radio range permits, our results suggest that it may be very significantly better to transmit information directly to an access point than to indirect through an aggregator. This requirement is justifiable for sprinting training in which body movements are within pre-determinable and restricted area (i.e. most sprinting exercises take place on a 100m track). REFERENCES [1]  The SEnsing for Sport And Managed Exercise project, http://www.sesame.ucl.ac.uk [2]  J. Farrell, ￿Training Implications of Stride Length Analysis￿, http://www.coachr.org/stridelength.htm [3]  D. Jea, M. Srivastava, ￿Packet Delivery Performance for On-Body Mica2dot Wireless Sensor Networks￿, in Proceedings of the 2nd IEEE Sensor and Ad Hoc Communications and Networks (SECON), 26-29 Sep, 2005. [4]  A. Christian, J. Healey, ￿Gathering Motion Data Using Featherweight Sensors and TCP/IP over 802.15.4￿, HP Technical Report, HPL-2005-188, Oct 2005. [5]  M. Otmani, M. Lecours, ￿Indoor Radio Measurements and Simulations with Polarisation Diversity￿, in Journal of Wireless Personal Communications, Springer, ISSN: 0929-6212, Vol. 3, No. 3, Nov 2004, pp. 243-256. 

An experimental study on a motion sensing system for sports training

Abstract

Similar works

Full text

Available Versions

UCL Discovery