Contributors List
4. General Motion Analysis
A LOW COST SELF CONTAINED PLATFORM FOR HUMAN MOTION ANALYSIS
N. DAVEY,1,3A. WIXTED,1Y. OHGI2& D.A. JAMES1,3
1Centre for Wireless Technology Griffith University, Brisbane, Queensland, Australia
2Graduate School of Media and Governance, Keio University, Kanagawa, Japan
3Centre of Excellence for Applied Sport Science Research, Queensland Academy of Sport, Brisbane, Queensland, Australia
In this paper we describe a low cost sensor platform for use in human motion investiga- tions. The platform is based on a readily available low cost microprocessor and features on-board memory, inertial sensors, USB communications and provision for additional sensors. Using a custom designed operating system it is easily customised by someone who has only limited programming experience. In the second part of our paper we present some simple applications for investigating human motion using the on-board sensors.
These applications show the user how to collect and download data and then introduces basic data processing techniques to process and analyze the data for key signatures and markers using readily available tools such as Matlab and Mathematica or their freeware equivalents.
1 Introduction
Athletic and clinical testing for performance analysis and enhancement has traditionally been performed in the laboratory where the required instrumentation is available and envi- ronmental conditions can be easily controlled. Today however we see the emergence of small, portable technologies being applied to the sporting environment. One such technology that has seen rapid development in recent years is in the area of inertial sensors. These sensors respond to minute changes in inertia in the linear and radial directions. Such sensors have been utilised in a variety of sports related monitoring projects such as monitoring elite swimmers (Ohgi, 2002; Davey et al., 2004), monitoring rowing (Lai et al.,2005), athlete gait analysis (Billing et al.,2003, Channells et al.,2006) and a variety of other uses includ- ing estimating athlete energy expenditure (Wixted et al. 2006), assessing limb segment acceleration (Kavanagh et al.,2006), studying swordsmanship and multi-limb motion mon- itoring (James et al.,2005), combative sports (Partridge et al.,2005), and others. Both the architecture and implementation of an operating system suitable for use in such sensor sys- tems has been utilised as a teaching tool at University and by other organisations.
To a certain extent however the use of these sensors has been constrained to research teams with access to engineering and sport science expertise. Concurrent with the emer- gence of Sports Engineering as a discipline in its own right has seen the availability of such instrumentation become more common amongst research teams and in the commercial world. Commercial devices are now becoming available albeit at significant capital cost.
These devices often combine inertial sensors with foot pressure sensors, GPS for position- ing and other specialist sensors such as strain gauges for rowing.
101
This paper presents a “no frills” sensor system at low component cost of approxi- mately $AUD100 for researchers to experiment without committing huge resources to the endeavor. It has been designed to make speculative data collection activities as simple as possible with little or no programming knowledge required. Example data analysis rou- tines are presented to show the reader what is possible, but without being prescriptive in nature.
2 Sensor Platform
A data acquisition platform, designed for data acquisition in sporting applications must of necessity, be of a small size and lightweight, yet capable of extended operational periods.
Development of such a data acquisition platform should utilise existing technologies to min- imise implementation costs, provide easy upgrade paths and ensure parts are readily avail- able. Where possible, tools developed for such an acquisition platform should be portable, low cost and be widely adopted so that specialist expertise is not required. Data formats should be non-proprietary and easily read into popular data analysis platforms such as spreadsheets, graphing packages and mathematical tools such as Matlab, Mathematica or freeware equivalents like Scilab.
2.1. Hardware
At the core of the sensor platform is an RISC based Atmel ATmega324P microprocessor, a very popular processor used for embedded applications all over the world. The Atmel product series provides a comprehensive range of microprocessors with varying features and processing power, many of the product family is pin compatible allowing for easy migration should specific applications require it. The microprocessor features 8 channels for analogue input (for sensors) and 32 Kbytes Flash memory for programming together with 1 KByte EEPROM and many digital I/O lines (32) and SPI bus for communicating with peripheral devices. Additionally the processor can operate at variable clock rates from KHz up to 20 MHz allowing for extremely low power operation or high performance operation (up to 10 MIPS processing throughput).
The platform contains 2 Mbytes of on board memory for data storage, this equates to over an hour of triaxial accelerometer data at 100 samples per second in storage mode or more if compression techniques are applied. The platform includes a Freescale tri-axial accelerometer, which features programmable gain with up to 6 g range so that an appro- priate range for specific activities of interest can be investigated with good resolution. An on-board USB chip and connection socket allow for easy communications with a PC, RF communications can also be added. External analogue and digital connection sockets for additional sensors and peripherals help allow the platform to be more easily customizable for specific applications. Currently the platform is powered by 2 AA battery cells for con- venience though higher density solutions such as Lithium-ion replacements could also be used where size restraints exist. Figure 1 shows the board layout for the platform.
Implementation of the data acquisition, storage and communications must be carefully implemented to ensure sample time is accurate, we chose to implement a basic operating system from which appropriate system calls and user procedures could be used.
2.2. Operating System and Configuration
The design of a data acquisition platform requires a system capable of performing sensing, data acquisition, signal processing, communications and wireless network management on a limited power budget. This degree of system complexity favors implementation of a loosely-coupled, low-power, embedded, Real Time Operating System (RTOS) on the data acquisition platform (Wixted et al.,2002). The RTOS is loosely coupled to the hardware by providing appropriate hardware abstraction thereby minimising dependencies on specific hardware and allowing for periodic technology updates. The RTOS minimises its own power consumption and at the same time assists application developers in minimising application power use. The operating system is by nature embedded, since the required small size precludes anything more sophisticated. Finally, the RTOS must have real-time components and processes since the data acquisition platform is monitoring real-time events and may be required to operate within a data network.
The operating system (OS) presented here is designed to exploit the power efficiency of the processor. The OS is a simple implementation using two schedulers and some inde- pendent threads managing specific tasks. The schedulers operate background, low priority tasks and foreground real time tasks. Tasks in the Real-Time Schedule (RTS) are typically repetitive tasks managing any synchronized function such as data acquisition. RTS tasks are typically atomic or near atomic style tasks. For non atomic real time tasks the RTS can start an independent thread of control. Tasks in the RTS can add tasks to the Background Schedule (BGS) such as data processing, packing and storage.
2.2.1. Independent Threads of Control
Depending on implementation, background tasks run either on a round-robin cooperative scheduler or on a scheduler designed to run a task to completion and then remove it from the list. The RTS runs independent of the BGS. Long running tasks are run via the BGS or run on an independent thread of control. Typical independent threads include serial com- munications where a communications thread is initiated by a scheduled task and is then A Low Cost Self Contained Platform for Human Motion Analysis 103
USB connector Microprocessor Memory Inertial Sensors Power Switch I/O headers
Figure 1. Sensor platform board layout showing key components.
allocated time by the serial port interrupt. Other independent threads may be initiated by a particular application event such as: a data logger buffer is filled and the data needs to be transferred via the I2C bus to EEPROM. Figure 2 shows the architecture of the RTOS.
2.2.2. Memory Requirements and Processing Load – Basic System
The RTOS along with a simple 3-channel 50 Hz sampling system was implemented and analysed. Sampled data was output serially at 38.4 kbps, in a single block, once per second.
Memory requirements are identified in Table 1 and the processor load for two different processor operating speeds and RTOS clock-ticks graphed in Figure 3. The load is broken down by processing layer where application refers to the sensor sampling task.
System Clock Tick Interrupt
Update current interval count
Interval with next scheduled task.
Tasks in schedule for this
interval?
Real Time Scheduler
YES NO
After iteration through schedule update next interval value.
Iterate through schedule items (process list) looking for task to execute this interval.
Atomic or near atomic tasks pointed to by schedule items.
One or more tasks scheduled for execution this interval.
Return from Clock- Tick Interrupt
Background Scheduler
SLEEP
Co-Operative Background Processing Tasks.
Tasks with no processing to do return immediately, others perform a limited amount of processing.
Iterate through schedule items (process list), allow each task the opportunity to execute.
Any RTI
COMPARE
Task Item
Task Item
Task Item Task
Item
Task
Item
Task Item
Figure 2. Architecture of scheduling services.
2.2.3. Using the RTOS
The primary interval timer is the heart beat of the OS. It determines when the timing inter- rupt is triggered to execute the task schedulers. The frequency of the interrupt is set by two values, a clock divider and a compare register and is set in a configuration file for the oper- ating system.
The system maintains two lists of tasks. The RTS is executed based on primary inter- val while the BGS is executed in the system idle time. The RTS is for tasks that are either small simple tasks, such as toggling an I/O line, or setup and initialisation routines that con- figure a separate interrupt routine. A task should only be in the RTS if it needs to occur at a specific time and/or rate. The BGS should be used for long running tasks (such data pack- ing and storage) or tasks that are not time critical.
A Low Cost Self Contained Platform for Human Motion Analysis 105
Component Memory requirement
Program 1748 bytes (ROM)
Global variables 99 bytes (RAM)
Constants 40 bytes (ROM)
Stack depth 128 bytes (max)
Stack size 256 bytes
Heap size 512 bytes
Total ROM 1788 bytes
Total RAM 995 bytes
Table 1. Basic system memory requirements.
0%
5%
10%
15%
20%
25%
30%
35%
40%
1 ms
Interval & Clock Speed
Percentage of Available Cycles
SLEEP APPLICATION COMMS OS
9.8304 MHz
10 ms 1 ms 10 ms 1.2288 MHz
Figure 3. Processor load in a 50 Hz 3 channel implementation of the RTOS, for two crystal frequen- cies and two primary interval timings.
Configuration of the platform is by adding tasks to the schedulers. The system operates two task schedules, a Real Time Scheduler and a Background Scheduler. Tasks are added to either the RTS or BGS using the addScheduleItem function. The addScheduleItem func- tion has the following syntax:
addScheduleItem (sch,nextival,ivalsize,func,priority, misc,rcount);
where:
sch Schedule to add task to, either RTSHED or BGSHED nextival The interval on which the task is executed
ivalsize The interval to wait before repeating execution (0 to execute once) func Function to be executed
priority Execution priority of function, 0 being highest and 255 lowest.
misc Provision for used defined data.
rcount The number of repetitions to execute the function for. (1 repeat forever) Where items could be scheduled to occur at the same instant, the priority flag is used to ensure the correct sequencing. The Background Scheduler is a simpler version of the Real Time Scheduler. Items added to the BGS are executed in the order they appear in the sched- ule list, the ordering is controlled by the priority flag.
A simple example task is to turn on a signal light (LED) at a specific time.
addScheduleItem (RTSHED,1000,0,Toggle_Led, 30, 1,1);
This command will add task to RTS, executed on interval 1000 once only, calling a built in function called “Toggle_Led” at priority 30.
The application programmer must also write any specialized processing modules or hardware drivers required by the application. The interrupt handlers and schedulers call the functions by function pointers therefore all functions called by interrupt handlers or sched- ulers are of the form: void function_name (void).
3 Data Collection and Analysis
Sensor data once collected by the platform is stored on flash memory and downloaded for subsequent analysis. There are many commercial and freeware software packages available for analysis of this kind of time series data sets. In general, collected data sets are large by conventional spreadsheet standards, typically generating many thousands of lines of data per minute of recording. Thus spreadsheet applications are less suitable, instead more pow- erful algebraic, numeric, statistical analysis software suites are preferred. Table 2 shows some typical commercial and license free software commonly available that the authors feel is suitable for such motion analysis research.
In the accompanying workshop, we will use Scilab a freeware application similar in functionality to the well known Matlab programming and analysis environment. Inertial sensor (tri-axial accelerometer) data is first obtained from the sensor platform as comma separated Variable (CSV) file and then imported into Scilab. Typical data analysis for inertial sensor data can be classified broadly into two categories, time domain analysis and frequency domain analysis. Normally an investigation begins with the data visualisation or “eyeballing” of the acquired acceleration in the time domain visual validation. Figure 4 illustrates typical vertical
(z-axis) acceleration during walking at four different speeds. This data was collected using accelerometers attached at the subject’s lower back (L5) with the z-axis aligned with the spine.
It is important to note that in general the z-axis acceleration will not equal the vertical accel- eration with respect to the global co-ordinate system due to variations in subjects gait.
3.1. Filtering Techniques
Acquired acceleration combines many signals other than those of principal interest which are often attributed to artifacts related to movement and a variety of other noise sources. By removing the high frequency component many such noise sources are eliminated, a digital low pass filter is a simple way to do this. A moving average is a simple digital filter for such smoothing. First and second ordered moving average methods have proven to be popular and are low numerical “cost” to implement. For example in the Eq. (1), a second order five point moving average filter requires only two pre and post datapoints (xj) to produce smoothed acceleration (yi), where (m) and (n) are the order of the filter and number of data length.
A Low Cost Self Contained Platform for Human Motion Analysis 107
Software Latest version Licence URL
Matlab 6.3 Commercial http://www.mathworks.com/
Scilab 4.1 Freeware http://www.scilab.org/
FreeMat 3.0 Freeware http://freemat.sourceforge.net/
Octave 2.9.10 Freeware http://www.gnu.org/software/octave/
Mathematica 5.2 Commercial http://www.wri.com/
Maxima 5.11.0 Freeware http://maxima.sourceforge.net/
S-PLUS 7 Commercial http://www.insightful.com/
R 2.5.0 Freeware http://www.r-project.org/
Igor Pro 6 Commercial http://www.wavemetrics.com/
Table 2. Available software for time series data analysis.
60m/min 80m/min
100m/min 120m/min
0 10 20
0 10 20
0 10 20
0 10 20
Time (s) Acceleration (m/s2)
1 2 3
Time (s)
1 2 3
Figure 4. Vertical accelerations collected from a subject walking at four different speeds.
(1)
A simple moving average is one the simplest class of filters referred known as Finite Impulse Response (FIR) filters and works well for the statistical analysis. However its fre- quency characteristics need to be considered so that important information is not lost. For instance the optimum cut off frequency is critical for preserving and enhancing the quality of our experimental data. The relationship between sampling rate (fs), cut off frequency (fc) and order of the moving average (m) is shown the equation as follows.
(2)
Manipulating these variables can help optimize for order, sampling frequency and cut- off frequency for your experimental requirements. Simple moving average methods have identically weighted coefficients for each filter element. A weighed moving average method is an improved version of the simple moving average method. Definition of the general weighed moving average is as follows.
Wis called the coefficient of normalization and contains the time-weighted values for each element of the filter. The coefficient of weight vectors and the normalisation are pre- sented in Table 3. The table shows from second to sixth ordered weighed average smooth- ing method based on a polynomial approximation. This approximation is named Savitzky &
Golay (1964) method though there are other weighting methods as well.
y W w j x i j
i m m n m
W w j
i
j m
m
j
1
1 2
( ) ( )
, , ,
( )
∑
…
m
∑
mm fs
0 443. fc
y n x i j
i m m n m
i
j m
m
1
1 2
( )
, , ,
∑
…
(3)
m\W 6 5 4 3 2 1 0 1 2 3 4 5 6
2 3 12 17 12 3
3 2 3 6 7 6 3 2
4 21 14 39 54 59 54 39 14 21
5 36 9 44 69 84 89 84 69 44 9 36
6 11 0 9 16 21 24 25 24 21 16 9 0 11
Table 3. Coefficients (W) of Savitzky-Golay moving average smoothing for different filter orders (m).
For more higher ordered smoothing the following equations allows us to obtain these coefficients (W) and their normalised weight value (k):
(4)
The Infinite Impulse Response (IIR) digital filter is also commonly used, it has some advantages in gain and phase performance when examining certain signals. In the field of biomechanics the Butterworth IIR digital filter has been a popular choice (Winter, 1990).
3.2. Feature Analysis
Impact motion during the walking, running or jump-like movements causes large ampli- tude shifts in acceleration that can be used for detecting and synchronizing activity signa- tures. Thus we can extract single gait cycle data and identify individual subject’s steps using basic peak detection techniques. These include the thresholding methods, local max-min identification methods and differential smoothing methods. The differential smoothing method has some unique characteristics with its output data. That is the smoothed data is also dif- ferentiated by the filter. Unlike threshold methods, the differential smoothing method requires no maximum and minimum thresholds for the single cycle extraction, which is advantageous for widely varying signals. This is the principle advantage of the differential smoothing filter as it is able to identify the transitional change of the acceleration at the impact moment by using its differentiated value. Equation(5) allows us to determine the coefficients of an arbitrary ordered differential smoothing function.
(5) For example, a five point (j1..5) coefficient vector for a second ordered (m2) differential smoothing function would be:
k{1/5,1/10, 0,1/10,1/5} (6)
3.3. Frequency Domain Analysis
In addition to the data smoothing and feature analysis methods, there are many other consid- erations for inertial sensor analysis in the time domain. For example, auto-correlation (self- correlation) and cross correlation functions are typical methods in comparing or overlaying different time series data inter and intra subject to compare differences in gait, anthropomor- phic fatigue injury and even technique. All of the time domain techniques have their equiva- lent methods that can be employed in the frequency domain by Fast Fourier Transforms (FFT).
Many analysis techniques can perform faster with simpler implementation in the frequency domain. Together time domain and frequency domain techniques can be used to extract per- formance characteristics and when combined can produce powerful tools for analysis.
k m j j
m m m
( , )
( )( )
3
2 1 1
W m m m
k m j m m j
W m
( ) ( )( )
( , ) ( )
( )
4 1 2 3
3
3 1 1 5
2
2
A Low Cost Self Contained Platform for Human Motion Analysis 109