Midway Design Report: Motion Analyzer for Physical Therapy Constantina Tyes, James Rutter, Sean Klaiber, and Arjuna Baratham Abstract—Physical therapy is a regular part of life for millions In addition, electro-mechanical devices that measure physical of people recovering from injuries. Currently, reliable therapy related quantities such as the maximum angle of quantitative data can only be collected with a one-on-one patient- motion are bulky, expensive, and impractical from a usability physical therapist interaction. This results in a costly, time- consuming process for both the patient and the physical therapist standpoint. (PT). Here, we propose a simple, reliable, and portable device Our design aims to solve these problems by creating a that will capture and analyze physical therapy-related motion, all minimally intrusive system that is affordable and usable by all within the confines of the patient’s home. Removable memory potential users. The user-side system will consist of a will allow easy transportation of the recorded motion data for wearable sensor apparatus and a portable storage and feedback further analysis by the PT back in the office, thus saving time device (PSFD). The wearable sensor will likely be a leg band and money for the patient. For this paper, a prototype was developed consisting of the wearable motion sensors or strap that securely holds the sensor in place while the communicating wirelessly to an embedded processor (Arduino), patient performs a particular strengthening or range of motion where a simple graph was drawn to demonstrate correct and exercise. The PSFD will serve two pain purposes; first, to useful data. record aforementioned motion data to a removable memory device and second, to provide the user with a simple interface in addition to feedback regarding the proper motion compared I. INTRODUCTION to the patient’s actual motion. We will show that the data is highly reliable and accurate by comparing device-recorded T HE field of physical therapy has remained largely unchanged by technology in the past decade. Most measurements are still done by hand, using protractor-like data with traditional PT-recorded data. The final piece to the project is the software running on the PT’s computer. This will analyze the motion data in depth, allowing the therapist to see devices to measure ranges of motion, which proves tedious for exactly what the patient has been doing and to assess the both the patient and the physical therapist. In addition, most patient’s progress. exercises require that a physical therapist (PT) be with the Figure 1 summarizes the flow of data in the motion analyzer patient in order to ensure that the exercise is done correctly: an system. The motion sensor device on the patient’s body will incorrectly performed exercise can be useless and even wirelessly send motion data to some portable device all in the detrimental to a patient’s recovery curve. This leads to user’s home. Then, the memory unit will be physically multiple visits to the PT office, costing everyone time and transported to the PT’s office, where further analysis will be money. done using special software on the PT’s computer. This The methods of data recording and storage are also information will then be used to help the PT modify and/or relatively old-fashioned, with the PT simply recording all correct the patient’s exercise movements and regimen. measurements with pencil and paper. The idea of a patient who performs exercises on his or her own without the supervision of the PT has been explored, but has not taken effect due to the skepticism of the reliability of the data recorded. Figure 1: System Flow Diagram II. DESIGN sensor on each ‘stick’ limb, with all sensors attached together in one wearable strap. For example, for a knee joint range of motion exercise, the wearable device will consist of A. System Overview two sensors, one on the lower leg near the shin and one on The design consists of three main blocks, as seen in Figure the upper leg near the thigh. This will give us all the 2. The wireless sensor device consists of the accelerometers information necessary to calculate the angle between sensor Figure 2: System Block Diagram and the wireless transmitter. This sensor device must be 1 and sensor 2. The accelerometers will be the 3-axis 5g lightweight and unobtrusive to the user. This is to ensure that ADXL335 accelerometer, meaning that they measure the device will not affect or hinder the patient’s range of acceleration in the three directions x, y, and z, and they have motion, which would render the entire product useless. The a maximum reading of 5g. This will be more than enough wireless transmitter will send this data to its receiver range for our application, in which users move in slow counterpart on the PSFD. The PSFD will be the main motions with very few fast jerks. It can be assumed that user interface, consisting of the main CPU and feedback throughout the use of the sensors, the maximum acceleration peripherals in addition to the memory storage device. It will they will experience will be within -1g and +1g, since this is allow the user to choose the exercise to be performed, and will the maximum effect of gravity. The exact algorithm for give feedback to the user based on how well (or how poorly) calculating the necessary angles is discussed in section III.B. they perform the exercise. The final block of the design is the The wireless communication from the accelerometer to the software in the PT’s office, allowing for more detailed PSFD will be done by XBee Series 2 radios, which analysis of the patient’s recorded motion data. implement the Zigbee protocol stack. XBee provides a simple way to convert analog signals, such as those coming from the accelerometers, to digital ones B. Detailed System Specification suitable for transmission through the wireless channel. This 1) Wireless Sensor is done by the 3 embedded A/D converters included on the The wireless sensor is the only part of the system that the XBee module itself. Therefore the analog signals can be user will wear on his or her body. There will be one wireless directly wired to the XBee device. The transmitter will send data to the receiver on the PSFD, simple file storage, organization, and retrieval. The with a raw data rate of 250 kbps. With a range of up to 30 m, software will be open source for any persons who feel the these modules were ideal for this application since the user need to modify the software in any way. can be assumed to be within eyesight of the PSFD. The short range of these radios enables a very low power consumption 4) Design Alternatives – only 1 mA when transmitting. In addition, these modules A number of component choices and other design cost less than the XBee Pro modules, which consume more alternatives were discussed in developing the motion power but offer a greater range. analyzer project. One was to sense more than just kinematics, and to extend the sensor device to include temperature sensors, gyroscopes, and/or optical rotary 2) Portable Storage and Feedback Device (PSFD) encoders. Research into each of these possibilities was The PSFD will have an identical XBee module as the done, and it was concluded that they would be unnecessary wireless sensor. This radio will serve as the endpoint of and impractical for our application. For example, optical data communication from the user, and will pass the data rotary encoders seemed to be bulky, heavy, and often to the CPU, which will be a Beagle Board equipped with expensive. In addition, these sensors would require a an OMAP processor capable of running an embedded mechanical device that retained contact with the sensor at Linux operating system. This will allow us to handle data all times. This would most likely get in the way of a user in files (possibly one file per day or per exercise session) trying to perform an exercise, resulting in an imprecise and resulting in much better organization and ease of design. possibly unsafe situation. The operating system will be booted from one SD card Another major decision we made was to forego the which cannot be used for any other data storage. internet-based data transportation from the user to the PT Also, the Beagle Board comes equipped with many (via e-mail or other wireless protocol). This would add too external ports that allow for peripherals to be connected to much complexity to the user box since it would require the the board, peripherals which we will use to provide user to own and operate a computer. This greatly reduces feedback to the user. The way such feedback will be the number of potential users, so we decided to make the generated involves real-time motion data comparison to a PSFD the only thing that the user has to operate. In small number of static variables. If the workable addition, the issue of security would be introduced if such assumption that all exercises are designed to be performed a method was used, with users’ sensitive personal data in one plane is used, then some variables include the traveling through unsecured wireless channels. amount of sensor deviation from this plane, expected Finally, a major alternative we considered was regarding max/min pitch values, and max amount of accepted sensor the software in the PT’s computer. At first we wanted to jitter or shakiness. If the user is found to have strayed from use a signal processing language that was familiar to us, any of these static variables, an alert in the form of an such as MATLAB, but since this is proprietary software, it audio message or an LCD message may be displayed. would require that the PT buy such software which would The last function of the PSFD is to write the motion data again reduce the likelihood that our product be used in real to the removable memory device, a second, portable SD situations. Therefore, we decided to go with Octave, which card. This will be then transported to the PT’s office for appears to give us all the processing capabilities that further analysis. MATLAB does, but at no cost to the user. 3) PT Software III. MDR PROTOTYPE IMPLEMENTATION The software running on the physical therapist’s computer will be written in the open-source numerical computing environment GNU Octave. The interface will A. Overview be a Java GUI that allows the PT to view detailed graphs The prototype developed for the Midway Design Review and statistics about the user’s performance on each (MDR) consists of a wireless sensor and a primitive PSFD exercise. Since the PT will have the raw accelerometer that actually has an Arduino instead of a Beagle Board. At data as received by the PSFD, there is no foreseeable limit this point the system demonstrates that useful data can be to the information accessible by the PT. sent from the wireless sensor to the portable Arduino board The Java GUI will provide a simple interface for the PT and displayed in Octave. As stated earlier, the ADXL335 to plot motion and related data including error plots, analog accelerometers were used as they provide the three- improvements plots, etc. The interface will also allow for axis measurement capabilities at the resolution we need. Also, the XBee series 2 wireless radio modules were used, as they are the low power, low cost devices that we need for such an application as our motion analyzer. The power is supplied by a 9 V battery which is fed into a voltage regulator that outputs 3.3 V. This voltage is sufficient to power both the accelerometer and the XBee radio. The Arduino processes the Zigbee packets and extracts the data, which it then passes to Gobetwino. Finally, the data is passed to Octave, in which graphs are drawn, displaying pitch versus time. B. Data Flow and Algorithm Figure 3: Derivation of Pitch Formula The sensor is calibrated once according to a simple method that reads the acceleration when the device is laying flat on some surface. This corresponds (ideally) to 0g acceleration in the x and y directions and 1g acceleration in the z C. Testing and Results direction. Since only the x- and y-axes are used in the tilt We performed two basic test types to test the reliability calculation, only the x- and y-axes are calibrated. The actual of our prototype: angle accuracy and timing accuracy tests. calibration is done by taking 10 consecutive readings of x We focus more on angle accuracy tests since at this point our and y acceleration and averaging them, yielding the average prototype introduces many delays that will not be present in deviation from 0g. This offset is later used in the pitch the final version using the Beagle Board. calculation when it is subtracted from the acceleration In order to test the reliability in the angle measurements readings before the inverse tangent is taken. Specifically, to of our device, we used the physical therapy device called the find pitch of the x-axis when moving in the xy-plane we use: goniometer, which is a protractor-like apparatus that measures angles. We attached the wireless sensor to the movable arm of the goniometer, and keeping the baseline arm steady, were = , able to vary the angle at which the wireless sensor was situated. Then, with the receiver and sensor turned on, we varied the angle from 20° to 30°, stopping there for a few Figure 3 illustrates how this formula was derived. Where seconds, and then moving it back to 20°. Then it was moved is the acceleration measured in the x direction, up to 40° and this continued in 10 degree increments, always is the zero offset in the x direction, and is a returning back to 20° each time. When viewing the resulting plot, it was clear that at each 10 degree increment, the line scaling factor used to convert from radians to degrees. This leveled out, and stayed relatively steady. At each 20° return dual axis calculation results in a greater resolution or point, the plot correctly indicated that 20° was the reading sensitivity than if only one axis was to be used, especially from the sensor. In addition to the accuracy of the device, this around the 0 +/- 10 degree position. From this tilt value, experiment showed that there was no accumulation of drift: at relative position can be calculated assuming that the each 20° stop, the graph correctly showed a line at 20° and did positions of the accelerometers are stationary. Since no not drift away in one direction. The ripples at each 10° integration or summations are done in calculating the tilt, the multiple represent the error or noise in our measurements. One device does not need to be calibrated more than once per of our immediate goals is to flatten out these plateaus by using session. The only remaining source of error is the rounding some sort of averaging or low-pass filtering. The exact details error coming from the analog-to-digital converter. Since we of this SNR optimization have yet to be derived. are using an 10-bit AD-converter, this rounding error is In terms of the timing calculations, only very rough relatively insignificant. The resolution we achieve has been experiments were carried out. These involved performing calculated to be 1 step/degree, meaning that for every step in some motion (a rapid increase of 10°, for example) at clearly the A/D digital output (from 0-2023), we get 1 degree of defined time intervals, say every 5 seconds. The result was a change in the angle measurement. plot that had nearly vertical steps every 5 seconds. Again, the 5 second intervals did not get longer over time, indicating that the accumulation of error is not a factor in the system. More precise timing measurements will be performed after the Beagle Board is integrated into the project. Wireless transmission data rate was also tested and compared to an expected, calculated theoretical data rate. To do this, we calculated the average time for one packet (30 bytes) to travel from transmitter to received. The parameters we used were the A/D sample rate (1ms), number of samples before transmission (3), raw data rate (250 kbps), UART baud rate (96500 bps), and static delays introduced in the receiver’s Arduino code. The last delay proved to contribute most to the timing calculation, accounting for 92% of the total delay. The calculated, expected amount of delay was 98.2 ms per packet, while the observed delay was steady at 116 ms. IV. PROJECT MANAGEMENT A. Team Roles • Wireless Sensor: Constantina • Wireless Send/Receive: Arjuna • PSFD Data Input: James • PSFD Output: Sean V. APPENDIX the Beagle Board, the main source of time delay will be greatly reduced and we will achieve far greater than the A. Application of Mathematics, Science, and Engineering roughly 10 Hz (100 ms) end-to-end latency that we observe In developing the prototype, we used material from at now. This will be suitable for slow motions such as the least three science or engineering courses: movement of a leg in a range of motion PT exercise. 1. Physics 151: Using effective forces and gravity B. Design and Performance of Experiments, Data Analysis, relationships in order to calculate the pitch of an and Interpretation object from its acceleration in different directions. 2. ECE 323: We had to build a circuit on the wireless In order to test the reliability in the angle sensor that took into account power/voltage issues. measurements of our device, we used the physical therapy 3. ECE 374: Using data rates and packet sizes, an device called the goniometer, which is a protractor-like overall data rate was calculated and compared to apparatus that measures angles. We attached the wireless actual, measured rates. sensor to the movable arm of the goniometer, and keeping the baseline arm steady, were able to vary the angle at which the Detailed Example wireless sensor was situated. Then, with the receiver and When wireless communication was first established, sensor turned on, we varied the angle from 20° to 30°, the data rate was far too slow, with on average one packet stopping there for a few seconds, and then moving it back to being received every 25 ms or so. Wireless transmission data 20°. Then it was moved up to 40° and this continued in 10 rate was tested and compared to an expected, calculated degree increments, always returning back to 20° each time. theoretical data rate. To do this, we calculated the average When viewing the resulting plot, it was clear that at each 10 time for one packet (30 bytes) to travel from transmitter to degree increment, the line leveled out, and stayed relatively receiver. The parameters we used were the A/D sample rate (1ms), number of samples before transmission (3), raw data steady. At each 20° return point, the plot correctly indicated rate (250 kbps), UART baud rate (96500 bps), and static that 20° was the reading from the sensor. In addition to the delays introduced in the receiver’s Arduino code. The last accuracy of the device, this experiment showed that there was delay proved to contribute most to the timing calculation, no accumulation of drift: at each 20° stop, the graph correctly accounting for 92% of the total delay. showed a line at 20° and did not drift away in one direction. The calculated, expected amount of delay was 98.2 The ripples at each 10° multiple represent the error or ms per packet, while the observed delay was steady at 116 ms. noise in our measurements. This ripple, which also is affected The delay due to the sampling was simple to calculate: 3 by human error (trembling, viewing the goniometer angles by samples/packet occurring every 1ms, corresponding to a time eye), seems to stay within +/- 1 degree when held absolutely of 3 ms per packet. The raw data rate of 250 kbps or 250*1024 still. This is assumed to be mostly (outside of human error) bps was used to transmit 30 bytes (240 bits) per packet. Thus, due to the inherent noise in the accelerometer, which at the the data rate delay was 240/(250*1024) s = 1.0 ms per packet. voltages we use should be within +/- 0.1 degree. Since a 10-bit The baud rate of 57600 bps transmitted 240 bits again, resulting in a delay of 240/57600 s = 4.2 ms. Finally, the static A/D converter is being used, this +/- 0.1 degree variance could delay in the program of 3ms/byte results in a total static delay force the A/D over a boundary, outputting an entire degree of 3*30 ms = 90 ms per packet. Summing these four values we higher than the actual angle (since the A/D resolution was obtained a value of 90 + 4.2 + 1.0 + 3.0 ms = 98.2 ms. The calculated to be 1 degree). One of our immediate goals is to delay from the Arduino program accounted for 90/98.2 = 92% flatten out these plateaus by using some sort of averaging or of the entire delay. low-pass filtering. The exact details of this SNR optimization In order to optimize this data rate as best as we could have yet to be derived. Octave was used to graph the results, for the prototype, we tested lowering the static delays to 2.5, 2, which is show below in Figure 4. and 1 ms, but all of these resulted in an unstable receiver. We did similar configurations on the baud rate, increasing it up to 115200 bps, but the benefit from such an increase was negligible compared to the instability that this gave the receiver. The samples per packet variable was experimented with and it appears that 3 samples before transmit was suitable for our system. We assume that when we transfer operations to Figure 4: Pitch vs. Time Sensor Graph 7 D. Multi-disciplinary Team Functions C. Design of System, Component, or Process to Meet Arjuna Baratham, CSE: Worked to enable wireless Desired Needs within Realistic Constraints communication, transmission/extraction of sensor The system requirements consist of requirements of data. Worked on configurations to optimize wireless the wireless sensor and the requirements of the data transmission latency with James. processing. The sensor must be comfortable and minimally intrusive to the user in order that they can perform the exercise Sean Klaiber, EE: Wrote Octave and Gobetwino fully and produce meaningful data. The wireless sensor must scripts that take sensor data and plots it against time. be lightweight so as not to hinder the range of motion, and Sean also set up the team’s website and is in charge must also be completely wireless. These could be considered of posting documents onto it. health and safety constraints since they also directly affect the safety of the patient. Our wireless sensor is completely James Rutter, EE: Worked on developing the angle wireless, using the Zigbee protocol to communicate to the calculation for the sensor data in Arduino. Also receiver. However, as it stands right now, our prototype is worked to optimize wireless transmission latency slightly bulky and heavy (due to the prototyping board and big with Arjuna. 9 volt battery). This will be addressed in future prototypes and the final design, in which a PCB will be used and the 9 volt Constantina Tyes, EE: Designed prototype wearable battery replaced by a lightweight coin battery. sensor. In charge of planning the future power supply The other main category of real-world constraints in and final sensor design. our design is the sustainability of our system. Our prototype doesn’t have any power-indication, but as we progress, some E. Identification, Formulation, and Solution of Engineering sort of “low battery” light will be introduced. In addition, Problems rechargeable batteries, possibly rechargeable coin cells will be used in order to provide a long lifetime and little need to As previously stated, one of the main obstacles we replace batteries. overcame was the poor data rate of the wireless transmission. To solve this we utilized techniques learned in previous courses in addition to the configuration options of the XBee radios in order to mitigate the per-packet delay. By observing 8 that the vast majority of the time delay (over 90%) was due to Our project will have positive societal impacts by the delay line in our code, we decided that Arduino would be allowing persons with physical injuries or disabilities to unsuitable for the final design and that Beagle Board would be perform recovery routines that would normally have to be a much better option. The parameters that we could change, done at a distant location within the convenient spot of their however, were optimized, and the result was a workable homes. Since the people who will be using out product are prototype in which the actual data rate was around 10 Hz. already injured in some way, in most cases they shouldn’t be driving to a physical therapy clinic for safety reasons. Allowing the recovery routines to be performed at the F. Understanding of Professional and Ethical patient’s home will also increase the amount of time the Responsibility patient has for other activities and the amount of time the An issue of professional responsibility that arose with physical therapist could be more actively analyzing a patient’s our project involved dealing with the people who are targeted data or handling other patients entirely. by our project. Since none of the team members have had Providing the ability for useful therapy related significant involvement with the physical therapy process, recovery exercises to be performed in ones home will either assumptions had to be made or a professional hopefully also increase the speed of patient recovery. People contacted. Professionally, it only made sense that we would are often removed from obligations such as work while be in frequent contact with a physical therapist. We quickly involved in therapy and our product may allow them to attend met with Joe Mathers, a physical therapist at University to these obligations in a timelier manner. Health Services and established a professional relationship. During the idea development stage of our project we met with Joe on four occasions to confirm the projects I. Application of Material Acquired Outside of Coursework usefulness and question where it was lacking. In an Three examples of sources used outside of intermediate product testing stage and for MDR, Joe was coursework are: helpful enough to lend us a Goniometer, the physical therapy tool used to measure the pitch of a patients knee, for 1. Product user manuals and data sheets, including comparison to our found values. , , and Beagle Board documentation. These helped us get started with each component or device, in addition to being valuable G. Team Communication troubleshooting resources. In this section we describe the various means the 2. Previous projects posted on the internet such as team are using to communicate as a team.  and . These provided us with specific Team communication has been done at weekly team and solutions to problems we were having late in the faculty meetings as well as less formal meeting times that implementation phase of our prototype. have been establishing themselves. The weekly faculty 3. [Detailed example] Application-specific meeting is scheduled for Mondays at 2:20 and the weekly technical papers such as  and . These team meetings on Wednesday at 2:20 with the occasional papers on accelerometer calculations and (about three times) team follow-up meeting Friday at 2:20. calibration served to guide us in our design. We During the faculty meeting, individual progress is discussed based our calibration scheme and sensitivity along with the most challenging technical problems that calculations on  although our sensitivity individuals or the group have encountered. At weekly team calculation is slightly less precise than Tuck’s. In meetings, the focus is generally on group work integration and  we used the various formulas for angle planning for future steps. calculations. We have also been fortunate in that an unplanned schedule has been formed in that the entire team will usually (about 75%) occupy the same areas in the M5 project space J. Knowledge of Contemporary Issues between 2:30-4:40 Tues-Thurs. Although team members work The field of physical therapy has a vast amount of during these times are not always SDP oriented, the proximity tools used for measurement and diagnosis for injuries. These has resulted in SDP related concerns almost always being tools can be incredibly accurate but are also far too large or discussed. expensive to be taken home by the user and can only be used Written and stored communication has been done in a clinic. In our research, we found tools such as the through e-mails and individual notebooks of which pages are expensive but accurate arthrometer. These tools perform often shared among team members. similar pitch measurements to ours but none that the patient Constantina Tyes has also served as the primary could take home and get similar or better accuracy than can faculty contact in charge of setting up any necessary faculty be done at the therapy clinic. So there is currently no method meetings and design review places and times. for a patient to get accurate results and data beneficial to the physical therapist outside of the clinic. The function of our project would be to act as a proxy physical therapist, H. Understanding of the impact of engineering solutions in providing real-time feedback for certain exercises, as well as a global, economic, environmental and societal context. a data logger providing the therapist with enough information 9 to make decisions without the patient present. This can all be done within the comfort of the patient’s home. K. Use of Modern Engineering Techniques and Tools Three engineering tools we used were: 1. X-CTU software which provided us with a GUI to make programming the XBee simple and fast. Also used to verify that the module was receiving correct data. This consisted of a command-line type terminal that accepted direct serial input and also printed out serial responses from the XBee. 2. The Arduino embedded system platform was used to develop the data receiving and processing software. It allows for easy programming and interfacing to the ATMega328 AVR microprocessor. 3. The open source software Gobetwino was used to read data sent out by the Arduino on a serial port and interpret this data as we specified. Arduino sent timestamp and pitch messages that Gobetwino stored in a text file in a format specified by a team effort of Gobetwino and Arduino code. Other serial port messages were used to overwrite this text file with a blank file at the command of a toggle switch connected to the Arduino. Gobetwino allowed us to store data that would otherwise be read and discarded by the Arduino. References  Tuck, Kimberly. “Implementing Auto-Zero Calibration Technique for Accelerometers”. Freescale Semiconductor, March 2007.  Tuck, Kimberly. “Tilt Sensing Using Linear Accelerometers”. Freescale Semiconductor. June 2007.  XBee Product Manual v1.xAx – 802.15.4 Protocol. PDF. IEEE 802.15.4 OEM RF Modules by MaxStream, Inc. October 2006.  ADXL330 datasheet. PDF. Analog Devices. 2006.  Faludi, Rob. “XBee Firmware Upgrade”. http://www.faludi.com/itp_coursework/meshnetworking/ XBee/XBee_firmware_upgrade.html. Web.  Faludi, Rob. “Common XBee Mistakes”. http://www.faludi.com/projects/common-xbee-mistakes/. Web.
Pages to are hidden for
"Midway Design Report Motion Analyzer for Physical Therapy"Please download to view full document