Difference between revisions of "Get A Handle On Your Game"

From ESE205 Wiki
Jump to: navigation, search
(Design and Solutions)
Line 94: Line 94:
''''Display of YPR, X/Y/Z Accelerations''''
'''Display of YPR, X/Y/Z Accelerations'''

Revision as of 15:28, 5 May 2016


Project Overview

This semester, our project is to design a system that will allow a user to track basic tennis swing movements. Currently, there are are a few companies that provide this kind of tracking; however, the most established of them require that the player purchase a specific racket. Others are not as accurate or have a lot of reviews where the sensor flies off of the racket. What we hope to accomplish with this project is to have a detachable device that will be able to provide raw data from a 6-DOF IMU sensor attached to the racket, and have that data sent to a computer for processing. From this data, we hope to provide simple feedback, such as swing count, consistency, and swing speed.

For our project, we will be collecting data by using a combined accelerometer and gyroscope to track swing movements. By the end of the semester, we will be able to show data collected from a tennis racket being swung. As two former college tennis players, we will be able to look at the swing and provide some feedback on how to improve it.

Team Members

  • Ryan Gleue
  • Jonathan Ng
  • Kjartan Brownell (TA)

Project Objectives

  • Creating a detachable device that collects kinematic data on the swing of a tennis racket
  • Be able to extract raw data from the onboard IMU and send to a computer for processing
  • Use collected data to calculate swing speed
  • Use data collected to implement a shot counter
  • Implement a filter to compensate for drift and reduce error in raw data

Project Challenges

  • Setting up an Arduino with proper modules
  • Being able to process data from the IMU to the computer in real time
  • Using kinematics and understanding of translational frames to interpret IMU data
  • Writing script in Matlab that will allow easy interpretation of raw data


  • Parts Purchased Online
    • Arduino Uno Rev3 ($24.95 + $8.15 shipping) Link
    • MPU6050 Module, Accelerometer and Gyroscope ($6.59) Link
    • Bluetooth Bluefruit EZ-Link Shield ($24.95 + $9.25 shipping) Link
    • Ribbon cable ($0.95 + $7.56 shipping) Link
    • Ohio Tech iPod Armband ($8.99) Link
    • Kinivo Bluetooth Dongle ($9.99) Link
  • Hardware Store Purchases
    • 9V Battery ($1.25)
    • 9V battery connector ($1.49)
      • Note: According to department sources, we will have access to ribbon cables and an Arduino Uno. However, they have been included in the budget for completeness.

Total: $100.12

Gantt Chart

Gantt Resources Get A Handle On Your Game.png

Gantt Tasks Get A Handle On Your Game.png

Pictures of our Device

Arduino and bluetooth shield connected to the 9V battery inside the armband

Arduino battery in armband.jpg

IMU inside the tennis handle

IMU in tennis handle.jpg

IMU connected to the Arduino inside the armband

IMU connected to arduino.jpg

Our entire tennis sensor device connected together

Entire device connected.jpg

Design and Solutions

1. Connection between Arduino and computer For this project, we used a Bluetooth connection between the Arduino and the computer. To do so, we attached a Bluetooth Shield to the Arduino, and connected it to the bluetooth dongle on the computer. This process can be seen in our Bluetooth Connection How-To.

2. Data Interpretation from Arduino to Matlab For sending data, we decided to send float values from the Arduino, and read them in on the Matlab side. They were sent in the following order: yaw, pitch, roll, x accel, y accel, z accel. We read in 1000 values from the Arduino at 20 Hz, and simultaneously timestamped the data every time our array filled a new set of values. This code can be seen in the following screenshot.

Matlab Data Collection

3. Shot counting and swing speed measurement We chose two final features to show with our project: a shot counter, and a swing speed measurement. For a shot counter, we first created a 40-index window, because we found that this gave us the most reliable results. Then, if the x, y, or z accelerations reached a certain threshold inside a window, our shot counter would increase by one.

Our swing speed measurement was a little more complicated. We used the same 40-index window, and we used the corresponding time stamps (these were stored in a separate array). We found individual velocities by using the cumtrapz() command over the time interval and particular window of data. Then, to find the max velocity of each shot, we took the norm of the x, y, and z velocities (taking the max of the square root of the sum of the velocities squared). The maximum velocity of the entire hitting session was captured by taking the maximum of the previous array. The code described can be seen in the screenshot below.

Counting Shots and Finding Max Velocity


Display of YPR, X/Y/Z Accelerations

For our project, we were able to complete a fairly successful project. During our demo and private testing, we found that our shot counter was very accurate, and occasionally off by only one shot. While we were unable to completely verify the maximum swing speed, the values that we were obtaining were in the correct neighbourhood of what one would expect.

Over the course of the semester, we found our objectives becoming narrowed down and focused. We started with very lofty expectations before realizing that we would not be able to accomplish everything we wanted to do. We were not able to compare swings to current pros, which would have involved manipulating the accelerometer data into position data, which would have introduced too much error due to drift. We would have had to incorporate another sensor or another method of tracking the swing, such as using video recording.

One of the decisions that we made that potentially prevented better results was just using raw threshold values. Since we did not find much high frequency noise when taking the FFT, we decided not to implement an LPF or use the frequency domain to utilise our shot counter. Therefore, our window size and threshold were experimentally found and arbitrary, and are thus not very robust outside of a controlled environment. Another source of error could be the actual placement of the IMU. We placed it at the bottom of the tennis racket, and while this is a good position, it wasn't completely secure. We were not able to find a completely secure casing for the sensor at the bottom of the racket, so we sealed it inside the base of the racket. However, since it wasn't completely immobile, it may have shifted slightly and produced slightly skewed data.

We would like to thank Kjartan for all of his guidance - there is no way we would have been able to get wrapped around our project without him. We also want to thank Humberto for letting us know right away when we were falling behind, and suggesting different approaches to the problems that we were facing.