NeuroGait: Mobile recording of gait in patients with neurological diseases

NEUROGAIT MOBILE RECORDING OF GAIT IN PATIENTS WITH NEUROLOGICAL DISEASES PEDRO MANUEL VAZ DUA RTE OLIVEIRA E SÁ DISSERTAÇÃO DE MESTRADO APRESENTADA À FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO EM ENGENHARIA ELECTROTÉCNICA E DE COMPUTADORES M 2014 FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO NeuroGait: Mobile Recording of Gait in Patients with Neurological Diseases Pedro Sá Mestrado Integrado em Engenharia Eletrotécnica e de Computadores Supervisor: João Paulo da Silva Cunha (Prof. Dr.) Co-supervisor: Kai Bötzel (Prof. Dr.) October 29, 2014 © Pedro Sá, 2014 Resumo Esta dissertação foca-se no desenvolvimento de um sistema de quantificação de marcha sem fios que utiliza sensores inerciais (IMUs) denominados de Motion Motes (ou MoMos) emparelhados com um dispositivo Android. Este sistema recolhe dados sincronamente de até quatro MoMos e tem também a capacidade de gravar vídeo em alta-definição simultaneamente. O objetivo principal deste trabalho foi desenvolver uma plataforma que pudesse auxiliar ao diagnóstico da Doença de Parkinson e avaliação do estado dos pacientes que fosse barato, fácil de usar, não-obtrusivo e que pudesse ser usado em contexto ambulatório. Apesar de ter sido desenvolvido para a Doença de Parkinson, a plataforma também é potencialmente útil em outras aplicações. De forma a validar este sistema, quatro MoMos foram colocados em cada coxa e canela de 10 voluntários saudáveis a quem foi pedido para andar num tapete rolante a velocidades diferentes. Um sistema de captura de movimento Oqus da Qualisys foi usado como referência. Testes meticulosos à perfomance do sistema, como a medição de atrasos entre o início da gravação dos MoMos e do vídeo foram também realizados e analisados em detalhe. As características deste sistema - a capacidade de reunir dados sincronamente de quatro IMUs num disposito Android e simultaneamente gravar vídeo - tornam-no num sistema único dentro dos instrumentos de avaliação de marcha existentes. i ii Abstract This dissertation focuses on the development of a wireless gait quantification system using Bluetoothenabled inertial measurement units (IMUs) called Motion Motes, or MoMos, connected to an Android phone. This system synchronously gathers data from up to four MoMos and also has the ability to record HD video simultaneously. The goal was to design a platform to assist clinicians on Parkinson’s Disease patients diagnosis and state assessment that is inexpensive, easy to use, unobtrusive and can inherently be used in an ambulatory setting. Although designed with PD evaluation in mind, the platform is potentially useful for other applications as well. To validate this system, 4 MoMos were placed on each thigh and shank of 10 healthy male subjects who were asked to walked on a treadmill at different speeds. A Qualisys Oqus camera motion capture system was used as ground truth. Extensive tests on the system’s performance, such as the evaluation of recording delays between IMUs and video were also performed and thoroughly analyzed. This system’s features - the capability of synchronously gathering data from four IMUs onto Android device and simultaneously record video - make it an unique system within the gait assessment instruments already in existence. iii iv Acknowledgements I’d like to express my deep gratitude towards my family, who provided me with an unsurmountable amount of support throughout my degree and granted me the gift of education. To my girlfriend, who provided me with love, care and expertise throughout this thesis. I’d also like to thank my supervisor Prof. Dr. João Paulo da Silva Cunha for his guidance, availability and for providing all the means I could ever need to successfully complete this work. I also wish to thank my co-supervisor Prof. Dr. Kai Bötzel who allowed me to observe first hand the effects of Parkinson’s Disease and introduced me to who this work is intended to help, which served as an amazing motivator; and for providing all the means and resources to evaluate this system. To my friends at BRAIN Lab who worked besides me everyday and offered precious inputs, thank you. To my friends and colleagues who accompanied me in this journey, thank you all. And to Ricardo Ferreira, who thoroughly proof read this thesis, thank you. To all, my sincerest and deepest gratitude! Pedro Sá v xii LIST OF FIGURES 8.10 Swing lengths comparison (horizontal axis in steps and vertical axis in meters) . 53 List of Tables 4.1 Rawdatapacketstructure.............................. 15 4.2 FrequenciesforeachMoMo ............................ 17 6.1 Calculated time between start of MoMos and video recording (in seconds) . . . . 36 6.2 GoPro video measurements for the recording delay tests . . . . . . . . . . . . . 37 6.3 Recording delay results and analysis between tests for each MoMo . . . . . . . . 38 6.4 Statistical analysis for each test (in seconds) . . . . . . . . . . . . . . . . . . . . 38 8.1 Subjectmeasurements ............................... 46 8.2 Results of right lower shank C3D data . . . . . . . . . . . . . . . . . . . . . . . 51 8.3 Results of the gyroscope data of the right shank MoMo . . . . . . . . . . . . . . 52 8.4 MoMo swing time relative error vs. ground truth . . . . . . . . . . . . . . . . . 52 xiii xiv LIST OF TABLES Abbreviations Abreviaturas e Símbolos ADT Android Developer Tools Acc Accelerometer App Application FoG Freezing of Gait g Acceleration of the Earth’s gravity (9,81 ms−2) Gyr Gyroscope IMU Inertial Measurement Unit MAC Medium Access Control Mag Magnetometer Mocap Motion capture MoMo Motion Mote PD Parkinson’s Disease STN-DBS Subthalamic nucleus deep brain stimulation UI User Interface xv Chapter 1 Introduction In this chapter, an introduction to the work performed throughout this dissertation is presented. Its content is briefly presented and its structure is detailed. 1.1 Motivation Parkinson’s Disease is one of the most prevalent pathologies in the elderly population. It causes several motor disturbances that can lead to a severely impaired quality of life and increased morbidity. The lack of quantitative diagnosis and evaluation tools poses a problem in the assessment of a patient’s condition, which is fundamental in determining a correct course of treatment. Current methods are largely based on the clinician’s analysis and suffer from inter-rater reliability issues. One of the most important factors in the assessment of PD’s is the patient’s gait. Current quantitative methods for gait assessment are often costly and can only be operated under laboratorial conditions. Over the past decade, gait analysis systems based on inertial sensors have arisen and are being shown to be reliable gait assessment tools, which have the potential to aid clinicians perform better decisions regarding patient treatment. The development of low-cost and unobtrusive solutions that patients can wear is warranted. The integration of inertial sensors with a mobile device seems to be an ideal approach to longterm ambulatory gait quantification systems. 1.2 Objectives The main objective of this dissertation is to build a synchronous gait capture system using a set of inertial-measurement units (IMUs) connected to an Android device that serves as means to capture the gait data streamed by the IMUs. The system also features simultaneous high-definition video capture, enabling image review of gait events along with IMU data. 1 2Introduction These characteristics make the system unique and potentially helpful to clinicians and patients, as it is capable of easily and inexpensively provide valuable insights into a patient’s condition. The synchronous video recording combined with the data from the MoMos have the potential to yield unique quantifiable results extracted from human gait. The work of this thesis focuses on the development of the mobile application that enables the use of IMUs, with an easy user experience. The general goals for this dissertation are: • Review of existing solutions of quantitative gait analysis • Development of a mobile application that integrates with existing IMUs • Testing of developed application • System testing with gait data against a ground truth system • Analysis of obtained results 1.3 Document Outline In this thesis, the development of the proposed gait analysis system is presented. Firstly in Chapter 2, a state of the art review is presented, focusing on describing Parkinson’s Disease and the current methods available for PD assessment. In Chapter 3an overview of the proposed system and details of its architecture is presented. Chapter 4contains an in-depth analysis on the supplied hardware, the IMUs, called MoMos that are utilized to capture human gait data. In Chapter 5, a thorough description and explanation of the mobile application and its development stages are provided. In Chapter 6the results for a wide array of tests that assess the application’s performance regarding data synchronicity and delays are presented. In Chapter 7, an analysis on gait highlighting the swing and support phases using the provided equipment is detailed and its results are presented. In Chapter 8, an overview of the experiments performed at the University Clinic Großhadern in Munich’s Ludwig-Maximilians-University to evaluate the NeuroGait system with various subjects is presented. Some results from those experiments are also shown. Lastly, in Chapter 9, the conclusions for this dissertation are presented - the detailing of the goals achieved and suggested future work. Chapter 2 State of the Art This state of the art review focuses firstly on the portrayal of Parkinson’s Disease - its prevalence, symptoms, treatment and other topics, and then on the quantitative methods for PD’s assessment. It focuses primarily on understanding gait and the gait disturbances caused by PD. 2.1 Parkinson’s Disease Parkinson’s Disease is a chronic neurodegenerative disease first identified in 1817 by James Parkinson [1]. Its prevalence increases with age, for both men and women. It affects about 5% of adults over the age of 80 [2]. There is no cure available and the causes for PD are unknown, as its believed to be a multifactorial disease which may be caused by both genetic and environmental factors [3]. It presents several motor disturbances such as bradykinesia, which is the slowness of movement, hypokinesia, or reduced movements, tremors, freezing of gait and postural instability [4]. One of the most severe impairments with PD are the disturbances in gait, as they severely impact the mobility of patients, reducing quality of life and increasing morbidity, as the risk of falling episodes greatly increase as the disease progresses [5]. It is also a costly disease, as a study conducted in six countries showed that the costs, pertaining medication, patient care and indirect costs for a period of six months ranged from C2620 in Russia to C9820 in Austria [6]. 2.1.1 Diagnosis and Assessment PD is usually assessed using rating scales that evaluate the symptoms and the degree of impairment caused by the disease. Three rating scales - CURS, NUDS, and UPDRS, were found to be the most reliable [7]. However, these evaluations are often somewhat subjective, suffering from interobserver reliability which was found to range from good to moderate depending on the scales used [7,8]. Accurate evaluations are critical for patient outcomes, as the course of treatment is defined by these evaluations. Therefore, there is a necessity for assessment methods that provide more 3 4State of the Art objective and reliable inferences on a patient’s condition [9,10]. The main goal of this thesis is to contribute to the creation of such an instrument, which can reliably and accurately extract features of a patient’s gait and aid the clinicians in the assessment of PD. 2.1.2 Treatment While there is no cure for PD, pharmacological and surgical treatments that alleviate and manage symptoms exist. The drug levodopa was shown to reduce the disease’s symptoms [11]. In more severe cases a subthalamic nucleus deep brain stimulation (STN-DBS) implantation is often used and was shown to significant ameliorate a set of symptoms, particularly some gait disturbances [10]. 2.1.3 Gait Disturbances As mentioned, this thesis focuses on the gait disturbances cause by PD. These disturbances can be either episodic - where symptoms appear randomly and intermittently and can include start hesitation and freezing of gait, or continuous - which include gait variability, reduced postural control and slow ambulation, caused by bradykinesia and reduced stride length [5]. Figure 2.1: Cycle of gait disturbances’ impact on a PD patient [5] Figure 2.1 shows how gait disturbances in PD can greatly impact patients lives, by increasing the risk of falling. The occurrence of falls leads, in turn, to injuries which can provoke immobilization in the patient, which causes further gait impairments. This prompts a decrease in the patient’s general well being and can ultimately precipitate death. 2.2 Gait Definition 5 2.2 Gait Definition Human gait is divided into several phases, as described in Figure 2.2 Figure 2.2: Phases of a gait cycle [12] The two main phases are the swing and stance phase. The swing phase relates to when the foot is not in contact with the ground, while when in the stance phase it is - they are mutually exclusive. They are separated by the toe off event, when the swing is initiated, and the initial contact - or heel strike, when the foot strikes the ground again. This is quite clearly visible in Figure 2.3, where the right leg position is illustrated for each gait event. The stance phase is usually longer, taking about 60% of a gait cycle. It is also denominated as the support phase, which is how it will be referred throughout this thesis. The double support phases relate to when both feet are in contact with the ground while the single support signifies that only one is. Figure 2.3: Positions of the right leg (in gray) during a full gait cycle [12] 12 Hardware Analysis Figure 4.2: Representation of the MoMo’s architecture The sensors used in the MoMos are the following: • Gyroscope: Invensense’s ITG-3200 gyroscope samples data at a 16 bit resolution with a range of ±2000º/s and has a 6.5 mA operating current [22]. • Accelerometer: The KXTF9-1026 by Kionix has user-selectable ranges of 2 g, 4 gand 8 g, can sample with an 8-bit or 12-bit resolution, and draws between 600-800 µA depending on the selected resolution [23]. • Magnetometer: Honeywell’s HMC5883L has a minimum range of ±1,0×10−4Tand a maximum of ±8×10−4T. With a 12-bit resolution, it is capable of a compass heading accuracy of 1º to 2º. It has a power consumption of 100 µA [24]. These devices are also relatively small-sized, as can be seen on Figure 4.1, so the disturbance to the gait when worn by a subject is minimum. 4.1.1 Axis Orientation Figure 4.3 details the orientation of the MoMos axes for each of the three sensors. Throughout this thesis, all the trials were performed with the accelerometer’s y-axis facing upwards. Figure 4.4 shows the accelerometer’s axes overlaying the device. 4.2 Operation 4.2.1 Operation Modes The MoMo has three different operating modes, two for streaming data either in quaternions or raw sensor data and one for calibrating the sensors. Every time it is turned on, one of the modes must be selected by the paired device. 4.2 Operation 13 (a) Accelerometer axes (b) Gyroscope axes (c) Magnetometer axis Figure 4.3: Orientation of the sensors’ axes [25] Figure 4.4: Photograph of MoMo with accelerometer axes represented If the one of the streaming data modes is selected, the device will start to broadcast data in a few seconds and a yellow LED will blink. If the calibration mode is selected, the paired device will receive a message announcing when the calibration has begun and once the procedure is finished it will return offset data. 4.2.2 Workflow In this section, the typical usage of the MoMos is described. Figure 4.5 details how the MoMo functions. Following, each action from the activity diagram will be detailed. 14 Hardware Analysis Figure 4.5: Activity diagram for the MoMo’s workflow • Switch On: the MoMo has a physical on/off switch, which must be flipped on in order to start the device. • Connection Request: a Bluetooth-enabled device, which will receive the data, must discover the MoMo’s network and attempt to connect to it. • Pair Device: If the MoMo hasn’t connected with the device before, it must be paired using ’0000’ as the code. • Connect to Receiver: upon a connection request, the MoMo establishes a link with the device. • Awaiting Setting: once the connection is established, the MoMo waits for a message from the device which will define its mode of operation. • Receive Setting: the MoMo receives from the device one of three characters. Either ’r’ for raw data, ’q’ for quaternion data or ’p’ to calibrate the device. • Broadcast Raw Data: the MoMo continuously streams raw data from all three sensors. • Broadcast Quaternion Data: the MoMo computes quaternions from the sensors and broadcasts the data. • Calibration Mode: the MoMo initiates a calibration procedure. 4.3 Data Packets 15 Once one of the broadcast modes is selected the device will only stop streaming data if it is switched off or runs out of battery. 4.3 Data Packets As described above, MoMos are able to stream raw sensor or quaternions data. This section details how they package the data and how the sensors are set up. 4.3.1 Range and Resolution Setup The MoMo’s firmware configures the sensors’ output. The set of four MoMos used during the development of this thesis were configured by IEETA’s team as follows: • Gyroscope: it is set to a 16-bit resolution with a range of ±2000º/s, meaning it outputs values between -32768 and 32767. • Accelerometer: this sensor is configured to have an 8-bit resolution ranging from -2.000 g to +1.984 g[23]. It produces values between -128 and 127. • Magnetometer: the range is configured ±1,0×10−4T. Its fixed 12-bit resolution outputs values between -2048 and 2047. The resolution on each sensor details how many steps there are between their range limits. 4.3.2 Packet Structure Table 4.1 details the structure of raw data MoMos build using the sensor readings. The first row labels each field. The second row relates the triaxial coordinates to the corresponding sensor. The third row indicates the output resolution from each sensor and the last line specifies the range for each sensor and the sequence number. ID x y z x y z x y z SEQ Gyro Acc Mag 16 bits 8 bits 12 bits ±2000º/s ±2 g±1,0×10−4T0-999 Table 4.1: Raw data packet structure The device starts its packets by sending an identifier, usually a letter and a number (e.g. Q1). It then writes the raw data of each axis of each sensor, as detailed in Table 4.1. The packet finishes with a sequence number. The sequence number is a number between 0 and 999 and is incremented by one with each sent packet. The sequence number as not initially a feature in the MoMos; however after some discussion with IEETA’s development team, it was requested that it was added in order to help 16 Hardware Analysis determine if a transmission error had occurred. The reasoning for this was that it would be simple to programmatically detect if a package didn’t arrive successfully as it would cause an evident gap between one packet and another. It would also help to reorder the packets if some did not arrive sequentially. All fields in each packet are separated by a comma, as presented in Listing 4.1. 1Q6, −98 , −3445,−111,132,64,127,−232,140,363,581 Listing 4.1: Packet example 4.3.3 Value Conversion MoMos return numerical values from the sensor readings as detailed in 4.3.1. In order to convert them to physical units, simple mathematical operations must be performed. For the acceleration a, the value xis divided by 127 and multiplied by the earth’s gravity g, as described in 4.1. a=x−127 64 g(m s−2)(4.1) The angular velocity ωis similarly obtained: ω=x 327672000 (° s−1)(4.2) and the magnetic flux density Bfrom the magnetometer: B=x 204710−4(T)(4.3) 4.4 MoMos Frequency Assessment In order to accurately determine the packet output frequency of each one of the MoMos provided, a test was devised. Four MoMos were placed on a table and their data stream along with video was recorded using the Android application. While recording, the table was knocked periodically in order to cause a visible change in the data stream. To time each event, a GoPro Hero3+ camera was set to record at 100 frames per second. This allows the MoMos’ signal, which were known to be below 50 Hz, to be oversampled. Avidemux 2.62was then used to perform a frame-by-frame video analysis. To calculate the MoMos output frequency, the number of packets received for each MoMo within two knocks separated by 64,89 seconds was counted. Table 4.2 shows the number of packets between each knock and the calculated frequency for each MoMo. They are identified by their packet identifier (see Section 4.3.2). 2Avidemux is a video editor available under GNU GPL license. More on http://fixounet.free.fr/ avidemux/ 4.5 Conclusions 17 MoMo ID Packets Frequency (Hz) Q1 2759 42.52 Q2 2818 43.43 Q5 2759 42.52 Q6 2822 43.49 Table 4.2: Frequencies for each MoMo The MoMos Q1 and Q5 output the same frequency. However, Q2 and Q6 have different frequencies, which disallows packet by packet comparison between MoMos for datasets larger than a few seconds. A second set of tests were performed, using the same procedure although using a much larger time period - 10 and 11 minutes. Although these showed similar values to the ones measured previously, the calculated values for each MoMo were significantly different from each other, suggesting that these devices may slightly vary their sampling frequency, possibly due to temperature variations between tests within its components. 4.5 Conclusions The MoMos are a key component in the proposed system. They are lightweight durable devices that can easily be fitted in any position in the body and have a long battery life which makes them suitable for long periods of use in an ambulatory setting. They were found to be quite reliable, although testing revealed, besides differences in sampling frequencies between the four supplied devices, some slight variation in its sampling frequency between tests. Their simple usage and Bluetooth connection make them ideal to link to a mobile device. 18 Hardware Analysis Chapter 5 Mobile Application A mobile application (or app) for Android was developed in order to simultaneously gather data from multiple sensors, record video and store those data for later relaying to a computer. In this chapter, the application’s features, functions and usage is thoroughly detailed. 5.1 Requirements The app was designed several key requirements in mind, namely: •Synchronous data collection: MoMos’ data are stored synchronously, i.e., by pressing the Record button, the app will simultaneously start recording data from all the connected MoMos. •Video recording: the user may choose to record video at a resolution of 720x1280 pixels at 25 frames per second. It records the video vertically as it was deemed more suitable to capture gait when compared to recording horizontally. The video is also synchronized with the MoMos’ data, meaning the app starts recording both video and MoMo data simultaneously. •Data storage: the app is able to store the data received from the MoMos. For each recording, a folder is created and named with the current date and time. For each MoMo, the app creates a single text file that contains all the data stream. •Data retrieval: stored data can be retrieved by connecting a USB cable to a computer. •Body location: the user can associate a connected MoMo to a location in the subject’s body, e.g., the lower right leg. This location will be present in the data recording filename. •Simple usage: the app may be easily and intuitively utilized, with as few steps as possible. It contains a simple user interface that depicts the human body and has buttons for each body position where the MoMos can be applied. Figure 5.1 shows the use cases for the application and its interaction with users and MoMos. 19 20 Mobile Application Figure 5.1: Use case diagram for the mobile application 5.2 Application Workflow In this section the typical workflow of the mobile application is described, from the initial setup and connection to the MoMos to the actual data recording. The activity diagram of Figure 5.2 represents the activities performed in a normal usage of the application. This diagram focuses on the general actions that are triggered by the user and which generate feedback within the user interface. It does not go into detail on what occurs programatically. This will be discussed in a further section. Following, the app usage will be described through an example of the typical utilization with the aid of screenshots of the app’s UI. Each of the actions described in the activity diagram will be mentioned as the usage is delineated. Naturally, the user starts by pressing the app icon in the Android’s interface (Start App). On the main screen, a depiction of a human body is presented along with buttons that represent each of a possible body location, as can be seen on Figure 5.3 (Select Body Location). The placement of these buttons was partly selected based on Figure 2.4. If a MoMo had already been connected and associated to that body location, the app would terminate the connection with that device (Disconnect from MoMo) and free that location, returning the button to an ’off’ state, i.e., not highlighted (Free Body Location). The user then proceeds to select a body position where a chosen MoMo has been or will be placed. Here, the user selects the right lower arm. The app then presents a list of previously synced Bluetooth devices and actively searches for new ones. Raw data mode operation is selected by default but the user may opt to choose another 5.2 Application Workflow 21 Figure 5.2: Application Main Workflow Activity Diagram 28 Mobile Application 5videoTimer.setBase(SystemClock.elapsedRealtime()); 6videoTimer.start(); 7 8if(videoSwitch.isChecked()){ 9if (prepareVideoRecorder()) { 10 // Camera is available and unlocked, MediaRecorder is prepared, 11 // now you can start recording 12 mMediaRecorder.start(); 13 } 14 } Listing 5.5: Start of recording As the code on Listing 5.5 shows, when the button is pressed in order to initiate a recording, the app first sets a boolean flag named recording to True. This is critical, as it indicates the handler threads managing the Bluetooth communications that a recording has initiated or is in progress and that the data stream they are receiving must be saved. Next, a timer is initiated in order to show the user the elapsed time during the recording. Then, the camera switch is checked. If it is on and the camera is correctly set up, it immediately starts saving the video feed. 1if(!isChecked){ 2stop = true; 3recordButton.setBackgroundColor(Color.LTGRAY); 4recording = false; 5 6if(videoSwitch.isChecked()){ 7mMediaRecorder.stop(); // stop the recording 8releaseMediaRecorder(); // release the MediaRecorder object 9mCamera.lock(); // take camera access back from MediaRecorder 10 } 11 videoTimer.stop(); 12 } Listing 5.6: Stopping the recording When the record button is pressed while a recording is in progress, the code in Listing 5.6 is executed. It sets the stop boolean flag to True and recording to False to signal that not only the recording is not in progress but it also has been effectively stopped. If the video had been on, it would have proceeded to stop the recording and release the camera. This part of the procedure was also based on the previously mentioned Camera API Guide. handleMessage(Message) Each instance of the BluetoothCommService class has an instance of a Handler7. 7Android Handlers are further described at https://developer.android.com/reference/android/ os/Handler.html 5.3 Application Implementation 29 Each Handler instance is associated with a connection to a Bluetooth device. It is responsible to receive the messages sent by the corresponding BluetoothCommService objects. The handleMessage method receives all the state changes and messages back from the thread that handles each MoMo connection and sends messages on command. It implements how each MoMo instance manages the received messages and how it passes operation mode commands back to the MoMos. This method was based on the one with the same name implemented on BluetoothChat example but was heavily adapted in order to fit the designed specifications. It mainly consists of a switch statement that handles each call from the device. 1public void handleMessage(Message msg) { 2switch (msg.what) { 3case MESSAGE_STATE_CHANGE: 4if(DEBUG) Log.i(TAG, "MESSAGE_STATE_CHANGE: " + msg.arg1); 5switch (msg.arg1) { 6case BluetoothCommService.STATE_CONNECTED: 7Toast.makeText(getApplicationContext(), "Connected", Toast. LENGTH_SHORT); 8operationModeSelector(commService1, commService1.operationMode) ; 9break; 10 case BluetoothCommService.STATE_CONNECTING: 11 Toast.makeText(getApplicationContext(), "Connecting...", Toast. LENGTH_SHORT); 12 break; 13 case BluetoothCommService.STATE_LISTEN: 14 case BluetoothCommService.STATE_NONE: 15 break; 16 case BluetoothCommService.STATE_DISCONNECTED: 17 controlToggleButton(false, commService1.bodyPositionCode); // Tells the function to turn the light off at the TB 18 commService1 = null;// Kills the commService so it can be reused 19 break; 20 } 21 break; Listing 5.7: handleMessage implementation of Bluetooth state changes Listing 5.7 details how the method handles the MESSAGE_STATE_CHANGE case, which in turn executes an action depending on which state the Bluetooth communication has changed to. Specifically, it can: let the application know if the MoMo has just been connected using the BluetoothCommService.STATE_CONNECTED flag, in which case it lets the user know with a Toast message8that it has been connected and calls out operationModeSelector in order to initiate the process that selects the MoMo’s operation mode; BluetoothCommService.STATE_CONNECTING lets the user know that 8More on Toasts at https://developer.android.com/guide/topics/ui/notifiers/toasts.html 30 Mobile Application the app has initiated the process of connecting to a device; and BluetoothCommService.STATE_DISCONNECTED informs the MainActivity that the connection to the device has been lost, switches off the Toggle Button linked to that device and nulls that BluetoothCommService instance so it can be reused. 1case MESSAGE_READ: 2byte[] readBuf = (byte[]) msg.obj; 3// construct a string from the valid bytes in the buffer 4String readMessage = new String(readBuf, 0, msg.arg1); 5if(recording){ // if the flag is True the app may record 6if(!file1Created ){ // if the file hasn’t been created, it will be now 7comm1Stream = writeToExternalStorage(commService1, false); 8file1Created = true; 9if(DEBUG)Log.i(TAG, "file 1 created"); 10 } 11 12 try { 13 comm1Stream.write(readMessage.getBytes()); 14 }catch (IOException e) { 15 e.printStackTrace(); 16 } 17 } 18 19 if(stop && !recording){ 20 try { 21 comm1Stream.close(); 22 file1Created = false; 23 }catch (IOException e) { 24 e.printStackTrace(); 25 } 26 } 27 break; Listing 5.8: handleMessage handling of received messages The next case relates to the handling of received messages from the Bluetooth device and it is shown in Listing 5.8. This is a critical case as it is responsible for handling all the data received from the MoMos. In the event of a MESSAGE_READ case, messageHandle first saves the buffer to a byte array. It then checks if it should be recording. If so, it checks if a file for that recording (in this case using the file1Created boolean flag) has already been created. If not, it calls out writeToExternalStorage which in turn creates a new FileOutputStream9instance which outputs the data stream to a file, in this case comm1Stream. Each time the method is called out, it updates comm1Stream with the latest received data buffer. As soon as the recording is stopped, by checking the stop and 9More about the FileOutputStream class at https://developer.android.com/reference/java/io/ FileOutputStream.html 5.3 Application Implementation 31 recording flags it immediately closes the stream (i.e. closes the created file) and sets the file1Created flag to False. 1case MESSAGE_DEVICE_NAME: 2// save the connected device’s name 3mConnectedDeviceName = msg.getData().getString(DEVICE_NAME); 4Toast.makeText(getApplicationContext(), "Connected to " 5+ mConnectedDeviceName, Toast.LENGTH_SHORT).show(); 6break; 7case MESSAGE_TOAST: 8Toast.makeText(getApplicationContext(), msg.getData().getString(TOAST), 9Toast.LENGTH_SHORT).show(); 10 break; Listing 5.9: handleMessage device name and Toast messages Listing 5.9 shows the DEVICE_NAME case, that sends a Toast notification with the selected device name as soon as it is connected. MESSAGE_TOAST enables the BluetoothCommService object to send Toast notifications. handleMessage also receives and effectively echoes the messages that are sent out to the Bluetooth devices but the app does not actually make use of that feature. operationModeSelector(BluetoothCommService) This method receives an object from the BluetoothCommService and the selected operation mode from SensorListActivity. 1public void operationModeSelector(BluetoothCommService commService, int operationMode){ 2 3switch (operationMode) { 4case SensorListActivity.SELECT_RAW_DATA: 5sendMessageToMomo("r\r\n", commService); 6break; 7case SensorListActivity.SELECT_QUATERNIONS: 8sendMessageToMomo("q\r\n", commService); 9break; 10 case SensorListActivity.SELECT_CALIBRATION: 11 sendMessageToMomo("p\r\n", commService); 12 break; 13 default: 14 break; 15 } 16 } Listing 5.10: operationModeSelector() method As detailed in Listing 5.10, it calls the sendMessageToMoMo method with a String that the MoMo expects to receive in order to be set to the operation method chosen by the user and forwards the BluetoothCommService object. It sends a string with the letters ’r’, ’q’ or ’p’ appended with the necessary escape characters ’\r\n’. 32 Mobile Application sendMessageToMoMo(String, BluetoothCommService) This method was adapted from BluetoothChat example. It is responsible for calling out BluetoothCommService.write() method with the message it receives in order to send it out to the MoMo. It is only used by the operationModeSelector() method. writeToExternalStorage(BluetoothCommService, boolean) This method creates a file for each MoMo data stream when a recording is initiated. It is called out by the MoMo’s connection handler when it reads a message from the MoMo for the first time after the recording is started. 1String bodyPosition = getBodyPosition(commService); 2File root = android.os.Environment.getExternalStorageDirectory(); 3FileOutputStream f = null; 4// See 5// http://stackoverflow.com/questions/3551821/android-write-to-sd-cardfolder 6File dir = new File(root.getAbsolutePath() + "/NeuroGait/"+ getDayAndTime () +"/"); 7File file; 8dir.mkdirs(); 9file = new File(dir, bodyPosition + ""+ System.currentTimeMillis()+". txt"); Listing 5.11: Excerpt of writeToExternalStorage() method It extracts a String from the received BluetoothCommService object which contains the body position associated to that object. It then gets the device’s root folder path, appends NeuroGait and the current date and time and creates a new directory with those elements, except if one has already been created with the same date and time by another BluetoothCommService instance. Next, it creates a new text file named with the body position and the current system time in milliseconds, when calling System.currentTimeMillis()10. This time allows to account for differences in the start of creating files when multiple MoMos are connected, and can help account for some of the Android device’s processing time between creating files. The createVideoFile() method is quite similar to this one, except it creates a file with an ’mp4’ video extension and obviously does not associate any body position to its filename. Some methods were not described as they were not deemed relevant enough to be detailed or their implementation was based on extracted examples, such as the getCameraInstance() or releaseMediaRecorder() methods which were taken from the Android’s Camera API guide. 10This method returns the current time in milliseconds since January 1, 1970 00:00:00.0 UTC. More at https: //developer.android.com/reference/java/lang/System.html#currentTimeMillis() 5.3 Application Implementation 33 5.3.2.2 BluetoothCommService class The BluetoothCommService class is responsible for creating the objects that effectively handle the Bluetooth connections with the MoMos. It is largely based on the BluetoothChatService class from the Bluetooth Chat example, which was modified with the necessary steps to accommodate the MoMos’ specifications. Initially, the class’s constructor was modified, as seen in Listing 5.12 1//Constructor; sets up a new sensor. Added a String as an argument to identify each body part) 2public BluetoothCommService(Context context, Handler handler, int bodyPositionCode, int operationMode) { 3mAdapter = BluetoothAdapter.getDefaultAdapter(); 4mState = STATE_NONE; 5mHandler = handler; 6this.bodyPositionCode = bodyPositionCode; // Relates the connected MoMo to the body position through the requestCode 7this.operationMode = operationMode; // In preparation for the operation mode 8// choosing string to be sent. 9} Listing 5.12: BluetoothCommService constructor Two attributes were added to the constructor in order to enable each instance of BluetoothCommService to carry through the selected body position and MoMo operation mode. This class also implements three other subclasses in a similar manner to BluetoothChat example, namely ConnectThread,AcceptThread and ConnectedThread. These classes extend on Android’s Thread class and they initiate threads for each of the Bluetooth connection phases - connecting, accepting and staying connected, respectively. There was one key modification that was made to the ConnectedThread. As discussed in Section 6.1.1, after observing a high error rate in the received packets a workaround11 was implemented. 1while (true) { 2try { 3if (mmInStream.available() > 0){ 4try { 5// Read from the InputStream 6bytes = mmInStream.read(buffer); 7mHandler.obtainMessage(MainActivity.MESSAGE_READ, bytes, -1, buffer ) 8.sendToTarget(); 9}catch (IOException e) { 10 Log.e(TAG, "disconnected", e); 11 connectionLost(); 12 // Start the service over to restart listening mode 13 BluetoothCommService.this.start(); 14 break; 11Suggested by a Stack Overflow user at http://stackoverflow.com/q/12294705/3066185 34 Mobile Application 15 } 16 } 17 else { 18 //if(DEBUG) Log.e(TAG, "sleeping for 200ms" + this); 19 SystemClock.sleep(200); 20 } 21 }catch (IOException e) { 22 e.printStackTrace(); 23 } 24 } Listing 5.13: ConnectedThread while cycle Listing 5.13 shows the while cycle that is continuously run during the execution of the ConnectedThread instance. It reads the InputStream12 buffer and sends it back to the connection’s handler in MainActivity. As a relatively high error rate was found specially when video recording was enabled, it was concluded that the Android device did not process (i.e., write it into its corresponding text file) the buffer quickly enough. As the cycle was continuously running and checking for new data on the InputStream, it overwrote the data buffer the handler was receiving. The sleep(200) method suspends the thread for 200 ms. Hence, in one cycle, the app reads the InputStream data and sends it to the handler. On the next cycle, as it is very unlikely that new data is in the buffer (MoMos stream at a rate of 42 Hz), the cycle executes the sleep method and holds the thread there. This period allows for the device to save the received buffer into a file and prevents the cycle from reading the buffer before that period is over. The InputStream buffer builds up during the 200 ms and is sent to the handler all at once. 5.4 Conclusion The developed application is thought to successfully meet its proposed requirements. The development of the app presented with several challenges - as mentioned, the use of simultaneous Bluetooth data streams was not found to be a common usage of this communication protocol. In sum, the application is considered to meet its primary objectives of recording gait data from the MoMos and from device’s video camera. It features a very simple usage and connects easily with the MoMos, enabling clinicians and patients to use it, both in clinical and ambulatory settings. As it was developed on the Android platform, it is capable of functioning in a very wide array of devices, contributing to keeping this system’s cost very low when compared to other gait analysis systems. At this point, the app’s operation was not yet assessed - a thorough analysis on its performance was carried out and is presented in Chapter 6. 12More about the InputStream class at https://developer.android.com/reference/java/io/ InputStream.html Chapter 6 System Analysis 6.1 Application Performance In order to evaluate the performance of the developed Android application, several tests were performed. In these sections, these tests are described and their results are presented. 6.1.1 Data Reception Reliability The first aspect that was accessed within the application was the reliability of the communication between the MoMos and the Android device. For that purposed, four MoMos were connected to the Android device using the NeuroGait app. They were placed at a distance of 3 meters and were simultaneously recorded for 300 seconds. One of the MoMo’s data stream was manually analyzed for errors - these were easily detectable as typically a bad packet presented a clear visual disruption. The errors for each thousand packets were also counted in order to observe the variability throughout the test. The test yielded 12746 packets, 231 of which failed, resulting in a packet failure rate of 1.8%. Figure 6.1 shows the number of failed packets per 1000 received. There is some variation throughFigure 6.1: Plot of the y-axis accelerometer of the shank’s MoMo 35 36 System Analysis out the test but it was not deemed very significant. Another aspect that was observed was that often several packet failures occurred consecutively, usually 2 to 4 at a time. These results were not very satisfactory and therefore a solution was warranted. Eventually this led to implement the workaround described in Section 5.3.2.1. The error rate was drastically reduced to 1 to 2 failed packets per 1000, even with four simultaneous MoMos and video recording. 6.1.2 Temporal Analysis of Recordings Several recordings were made using the application in order to evaluate other aspects of its performance. Similarly to the tests described in Section 4.4, the MoMos were placed on a table. The table was knocked one time, a few seconds after the record button was pushed. By analyzing the data, the number of packets between the first one recorded and the packet which occurred when the table was knocked were determined. Then, to obtain the time interval between the first packet and the knock, the determined number of packets was multiplied by the values of frequency calculated in Section 4.4. Video was also taped using the GoPro camera and analyzed using Avidemux. 6.1.2.1 Interval between video and data recording Q1 Q2 Q5 Q6 Test 1 (s) 0,79 - 0,91 0,95 Test 2 (s) 0,92 0,83 0,91 0,82 Table 6.1: Calculated time between start of MoMos and video recording (in seconds) In order to assess if there were delays between the start of the recording of the MoMos’ data streams and the start of the video recording, two tests were performed. A short recording with video and the data streams of four MoMos using the app was made. Using Avidemux, the time between the start of the video and the first visible knock was measured. Then, the number of packets between the first recorded packet and the first knock was determined, and the time between those events was calculated using the known frequencies for each MoMo. After, the differences between these two sets of values were measured, to determine if there were significant differences between both processes. Table 6.1 shows the results of these tests. For both, there is a clear delay, oscillating between 0,8 and 0,9 seconds. 6.1.2.2 Recording delay Another aspect that was tested was how long it took between pressing the Record button within the app and the data recording actually starting. 6.2 Results and Discussion 37 Test (n) 1 2 3 4 5 Knock (s) 9,52 8,23 10,18 7,95 8,58 GPy(s) 4,72 3,93 6,63 6,43 5,66 GPr(s) 4,28 3,50 6,16 6,00 5,23 Table 6.2: GoPro video measurements for the recording delay tests Five tests were performed according to what was described in the beginning of this Section. The GoPro camera was also used. In the videos, it was observed that when the button was pressed it would first turn yellow, immediately after it was pressed, and then changed to red. Bearing this in mind, it was first calculated the MoMo sample period (Msp), which was the time between the start of each MoMo data stream recording and the knock. In order to do this, for each MoMo the number of packets from the start of the data stream to the first knock was counted and divided by the obtained frequency for that MoMo. Using the GoPro video, the time period between the Record button changing colors (to yellow and then red) and to the knock was measured. After, these values were compared to the calculated times for the MoMos data streams, by subtracting each MoMo sample period to the times measured by the GoPro. 6.2 Results and Discussion Table 6.2 shows the measurements obtained from the GoPro camera and Table 6.3 shows the results for each MoMo. GPyand GPrare the GoPro measured times between the knock (the time in the video where the knock on the table occurred) and the appearance of the yellow button and the red button, respectively. Table 6.3 evidences the differences between these values. A GP−Msp value being positive indicates that the event occurred before the app started recording the MoMos data stream, while a negative signals that it happened after. The mean, maximum, minimum and standard deviation calculations between tests for each MoMo are also presented. From these results, it can be concluded that the device starts recording the MoMos’ data stream shortly after the Record button is pressed and before the Record button turns red. Table 6.4 shows the same statistical analysis as in the previous tables but for each test (between MoMos). An important conclusion that can be drawn from these results, specially for the standard deviation values observed in Table 6.4 is that the device does not always start recording the MoMos simultaneously. This can be in partly explained by the MoMos sampling frequency, which admitting it is around 42 Hz, could result in a maximum discrepancy of two MoMo measurements that the Android device fails to register, or 2 f≃48 ms. While this value is larger than the calculated standard deviations, it does not account for all the discrepancies between MoMos, which indicates that the processes within the execution of the app are causing the streams to be recorded asynchronously. The application records the MoMos data stream reliably, without any significant packet losses. However, delays between the time the button is pressed and the time the data are actually recorded 44 Experimental Trials Figure 8.1: Overview of LMU’s laboratory equipped with an Oqus camera system 8.2 Methodology In this section, the methods and processes used to gather data, the study population and tools utilized are described. 8.2.1 Materials Several instruments were used in these experiments. Next, the main materials are described. 8.2.1.1 Oqus Motion Capture System Qualysis produces high-end motion capture (mocap) systems, which are, among other purposes, used for gait analysis1. In these trials, Oqus cameras were used to capture the subjects’ gait, outputting three dimensional marker coordinates for each test. The markers used were passive reflective spheres2. 1More information at http://www.qualisys.com/applications/biomechanics/ gait-analysis-and-rehabilitation/ 2Available from Qualisys (http://www.qualisys.com/products/accessories/passive-markers/ lightweight/) 8.2 Methodology 45 Figure 8.2: Oqus Camera3 The room where the experiments were conducted was equipped with a set of eight Oqus Cameras linked to a computer with Qualisys Track Manager installed. Some of these can be seen on Figure 8.1, between the ceiling and the furthest wall. 8.2.1.2 Treadmill A Woodway S1V treadmill was used to perform these tests. This treadmill had an external controller, which was used to visualize and regulate the speed. Its handles were detached from the body, in order to prevent reflection and occlusion to the Oqus cameras. 8.2.1.3 NeuroGait System The four MoMos that were used before were also used in these trials. The NeuroGait app was installed in a Samsung Galaxy Note-II with Android 4.3 installed. The MoMos were fitted on the subjects while inside wrist bands, which were wrapped around a set of elastic bands with hook-and-eye clasps, as seen in Figure 8.3a. 8.2.2 Population Ten adult healthy males took part in this study. Table 8.1 details the subjects’ height and leg measurements. 8.2.3 Data collection In the following sections, the methods and steps for equipping the subjects and gathering data are described. 3Image obtained from http://www.thoma.de/en/produkte/walkfinder_camera6.html 46 Experimental Trials Subject Height (cm) Total Leg Length (cm) Lower Leg Length (cm) 1 193 104 - 2 183 95 55 3 182 93 57 4 173 89 51 5 183 92 54 6 190 94 53 7 196 106 62 8 178 88 51 9 185 88 58 10 187 98 58 Average 185 94,7 55,4 St Dev 6,9 6,3 13,0 Max 196 106 95 Min 173 88 51 Table 8.1: Subject measurements 8.2.3.1 Materials Placement Each subject was fitted with four MoMos - two on each leg, one in the front side of the thigh and another in the front side of the shank. MoMos were placed facing forwards, with the accelerometer y-axis pointing up and the z-axis pointing forwards. (a) Placement of reflective markers and MoMos on a subject’s legs (b) 3d plot of reflective markers Figure 8.3: Placement of MoMos and 3d representation generated by Mokka 8.2 Methodology 47 Subjects were also equipped with reflective markers to enable three dimensional motion capture by the Oqus camera system. For this purpose, the lower body was divided into five sections - hip, right and left thigh and right and left shank. In each section, three reflective markers were placed - two in the front and one in the back, effectively forming a triangle. Figure 8.3 shows these markers on the subjects legs (Figure 8.3a) and their corresponding three dimensional plot (Figure 8.3b). While the hip markers were placed horizontally in relation to the ground, the remaining markers formed vertical shapes. Figure 8.4: Representation of the Oqus coordinate axes on the treadmill The Oqus camera system was calibrated using the surface of the treadmill as the base for the xy plane. The subjects would walk on the opposite direction of the x-axis, as shown on Figure 8.4. 8.2.3.2 Procedures Each subject was asked to walk on a treadmill three times, each at different fixed speeds - 2 km/h, 4 km/h and 6 km/h, for a period of about a minute. The trials started at a null speed. Before subjects started walking, they were asked to stomp on the treadmill, one foot at a time, to imprint a distinguishable marker in the collected data. The treadmill was then slowly accelerated to a fixed speed and at that point the subject walked for a period of 40 to 50 seconds. Afterwards the treadmill would slowly be decelerated back to zero speed. The NeuroGait and the Qualisys systems captured data for roughly the same period. The NeuroGait app collected the data stream from the four MoMos and also recorded video. The Qualisys system gathered the markers’ coordinates, set at a frequency of 200 Hz. The treadmill controller was used to set and record the speed throughout the trials. Figure 8.1 depicts one of the trials while it was in progress - the subject is walking on the treadmill while fully equipped with passive markers, the MoMos and the GaitWatch system. 48 Experimental Trials 8.3 Data Analysis The goal of the analysis on this experiment’s data was to extract important gait parameters and compare the NeuroGait system to an accurate ground truth system. First, the data generated by the mocap system was analysed. 8.3.1 Mocap Data The Qualysis Track Manager outputted data in C3D file format4. Mokka, or Motion kinematic and kinetic analyzer5, is an open-source application capable of analyzing C3D data files. The software displays each marker in a three-dimensional space and allows spatial data from each marker to be extracted. It can also animate those markers in a three-dimensional view. Also, it has the ability to mark gait events, such as heel strike and toe-off for each foot. Another feature is the insertion of video side-by-side within the application window. It also allows the synchronization between the video and the three-dimensional markers playback by adjusting a time value for the delay the video should have. 8.3.1.1 Marker Coordinates Analysis In order to determine how gait parameters could be extracted from C3D data, one of the 4 km/h tests was loaded into Mokka. Figure 8.5: Screenshot of Mokka with three-dimensional data loaded and segments traced 4C3D is a public domain file format for 3D data. More information at: http://www.c3d.org 5More at http://b-tk.googlecode.com/svn/web/mokka/index.html 8.3 Data Analysis 49 Firstly, the recorded video was synchronized to the 3D markers playback, using the right foot stomp performed by the subject, that was clearly visible in both the video recording and the markers playback. Both were shown side-by-side and the video delay was then adjusted according to the difference in time between the video and the markers playback of that event. Figure 8.6: Plot of the right and left foot lower shank markers in the x-axis After, a section of a few steps, where the speed had stabilized at 4 km/h, was chosen and zoomed into in the time bar. Using the synchronized video recording, the heel strike and toe-off events for three gait cycles for each foot were pinpointed. This can be observed on the bottom part of Figure 8.6. The identification of these events was aided and validated by a physical therapist. Next, the marked events were compared to the x-axis plot of the right and left lower shank markers. Mokka marks heel strike events as squares on the time bar and vertical dashed lines on the graph plot; it also marks toe-off events as triangles on the time bar and dashed and dotted lines on the graph plot. The right foot events and plot are drawn in green, while the left foot are in red. At this point, an important observation could be drawn from the plot: nearly all of the toe-off and heel strike events occur at each local maximum and local minimum, respectively. From this, it was concluded that these events could be extracted by analyzing the local extrema of the lower shank markers plots. 8.3.1.2 Marker coordinates feature extraction Using Mokka, the C3D data from the right and left lower shank markers were exported into a text file. The data were then imported to Matlab. 50 Experimental Trials Using the PeakFinder function6, the local extrema for the x-axis data were plotted. PeakFinder is able to extract the values of the local extrema and their position (or frame number). Figure 8.7: Plot of the right foot lower shank marker in the x-axis with local maxima outlined Figure 8.7 shows the PeakFinder output plot with the local maxima, i.e., the toe-off events marked with red dots. The plot is limited to when the subject was walking. After extracting the local extrema and its corresponding positions for both the left and right shank plots, these data were pasted into Microsoft Excel. The positions were converted into time by dividing them by the mocap sampling frequency (200 Hz) The extrema pertaining to the 20th to 29th steps were selected, as the treadmill’s speed during those step was known to be stabilized at 4 km/h. From there several parameters were calculated, namely the swing length, swing time and swing velocity. The swing length was calculated as the modulus of the difference between the heel strike and the toe-off position for a given step; the swing time was the difference between the heel strike and the toe-off time for a given step; and the swing velocity as the quotient between swing length and swing time. The results are shown in Table 8.2, which also includes the mean, maximum, minimum and standard deviation calculations, for each measurement and result. 8.3.2 MoMos Data The data from the gyroscope of right shank MoMo from the same trial were imported into Matlab and ran through PeakFinder. Unlike the C3D data, where the local maxima and minima relate to toe-off and heel strike events, in the gyroscope case, only the local maxima obtained at the beginning and the end of the swing phase respectively indicate toe-off and heel strike events. 6More on this function at: http://www.mathworks.com/matlabcentral/fileexchange/ 25500-peakfinder 8.3 Data Analysis 51 Step Toe-off (mm) Heel strike (mm) Swing Length (mm) Toe-off Time (s) Heel-strike Time (s) Swing Time (s) Swing Velocity (m/s) 1 607,41 101,19 506,22 29,64 30,17 0,53 0,96 2 589,56 92,29 497,27 30,86 31,38 0,52 0,96 3 588,49 105,44 483,05 32,07 32,59 0,52 0,93 4 610,34 137,98 472,36 33,31 33,82 0,52 0,92 5 629,91 94,86 535,05 34,52 35,05 0,54 1,00 6 576,14 82,18 493,96 35,75 36,25 0,51 0,98 7 501,94 63,58 438,34 36,88 37,35 0,48 0,92 8 590,13 83,66 506,47 38,05 38,55 0,50 1,01 9 564,65 79,37 485,28 39,22 39,72 0,50 0,97 10 573,68 109,59 464,09 40,40 40,91 0,51 0,92 Mean 583,23 95,014 488,211 35,067 35,576 0,511 0,956 Max 629,91 137,98 535,05 40,40 40,91 0,54 1,01 Min 501,94 63,58 438,36 29,64 30,17 0,48 0,92 StDev 34,49 20,38 26,50 3,612 3,607 0,017 0,034 Table 8.2: Results of right lower shank C3D data The input parameters of PeakFinder were iteratively adjusted and ultimately set to sel = 500 and threshold = 600 which resulted in the plot of Figure 8.8, which features the right leg stomp and the first step. They were set to sel = 500 and threshold = 600. It can be noticed that it misses the first swing local maxima as the swing velocity was too slow to generate peaks within the selected PeakFinder thresholds and it incorrectly registers (i.e., it is not a gait event) the first maxima, which corresponds to the stomp prior to the start of the gait. This was taken into account when determining the steps to be analyzed. Figure 8.8: Right shank MoMo gyroscope y-axis data plot with local maxima outlined of right foot stomp and first steps 52 Experimental Trials Similarly to Section 8.3.1, the PeakFinder output data was imported into Excel and analyzed. In order to select the 20th to 29th toe-off and heel strike events from the local maxima, firstly, the toe-off corresponding to start of the 20th gait cycle was found. The next maximum would correspond to the right foot’s heel strike event of the 20th gait cycle. The next 9 steps were then recursively selected. Step Number of frames Swing Time (s) Extrapolated Distance (m) Treadmill speed distance (m) 1 23 0,54 0,52 0,60 2 23 0,54 0,52 0,60 3 20 0,47 0,44 0,52 4 22 0,52 0,48 0,58 5 25 0,59 0,59 0,65 6 22 0,52 0,51 0,58 7 20 0,47 0,43 0,52 8 21 0,49 0,50 0,55 9 22 0,52 0,50 0,58 10 21 0,49 0,45 0,54 Mean 21,9 0,52 0,493 0,572 Maximum 25 0,59 0,59 0,65 Minimum 20 0,47 0,43 0,52 St dev 1,52 0,036 0,046 0,040 Table 8.3: Results of the gyroscope data of the right shank MoMo From there, the swing time for each step was calculated, using the known value of frequency for the MoMo with the Q5 id - 42,51 Hz. The swing length was then extrapolated multiplying the obtained time with the C3D calculated velocities shown in Table 8.2. This parameter was also estimated using the treadmill speed even though it is realized the speed at which the treadmill was rolling will likely differ from the actual speed at which the subject swings his leg. 8.4 Results and Discussion Based on the the obtained results, comparisons between the data obtained from the Qualisys and the NeuroGait systems were performed. Step 1 2 3 4 5 6 7 8 9 10 Relative Error (%) 2,08 4,05 9,52 0,49 9,92 2,48 0,95 1,20 3,51 2,18 Max Min Mean StDev 9,92 0,49 3,64 3,39 (%) Table 8.4: MoMo swing time relative error vs. ground truth 8.4 Results and Discussion 53 12345 6 7 8 9 10 0.5 0.55 C3D time (s) MoMo calculated time (s) Figure 8.9: Swing times comparison (horizontal axis in steps and vertical axis in seconds) Firstly, the time for each swing was compared. Figure 8.9 shows the time in seconds (on the vertical axis) for each swing. The plot reveals that the times calculated by the MoMo’s data follow closely most of the values found in the Qualisys data. Bearing in mind that the MoMo samples have a resolution of 1/f=24ms, it can be observed that the error for all the steps except the third and fifth steps fall under the sampling period of the MoMos. The time differences in steps 3 and 5 also fall under the period of two MoMo samples and seem to offset each other, as the differences between the ground truth time and the MoMo calculated time in steps 3 and 5 are nearly symmetrical. Table 8.4 shows the calculated relative error for each step for the MoMo data against the Qualisys data. While the maximum error seems relatively high, the average relative error 3,64% seems to indicate that the NeuroGait system performs fairly well when assessing swing times. These data suggest that, even though the MoMos provide accurate results when determining swing times, at the set frequency the period of two samples - 48 ms - take up almost 10% of the duration of a normal swing, which was calculated to be 0,51 s on average. Therefore, this particular application could benefit from an increase in the MoMo’s sampling frequency, as it would narrow the window for the maximum relative error. Next, the swing lengths were compared. Figure 8.10 shows a comparison between the Qualisys measured swing lengths and the lengths obtained by multiplying the MoMo swing times and the treadmill speed. The error between both sets of values is evidently high. However, the relation between both 1234567 8 9 10 0.5 0.6 Ground Truth (m) Treadmill calculations (m) Figure 8.10: Swing lengths comparison (horizontal axis in steps and vertical axis in meters) 60 BIBLIOGRAPHY