Get A Handle Weekly Log

February 12th

This week, we created our Wiki and Google Drive accounts. We settled on the project idea of tracking a tennis swing. Once we were able to decide that, we sat down to decide what kind of components we would need. We completed an initial project proposal and selected a name for our project, as well as an initial budget.

February 19th

This week, we received feedback from Professor Gonzalez and our TA. With that feedback in hand, we went into our wiki page and more specifically addressed our objectives and challenges. We also updated our budget and our Gantt charts.

February 26th

This week, we got our budget approved for purchases for the Bluetooth Shield and the IMU. We got the Arduino Uno from the 015 lab and will begin preliminary coding this week. We also read the papers written by other teams that were recommended to us by our TA.

March 3rd

We were alerted to the fact that we were falling behind on several aspects of our project. We have several main parts of programming that need to be completed: the collection of raw data, the processing of the raw data, creating the data flow from the IMU to the computer, and (possibly) the animation of the data. At this point, our project may have to be scaled back to be a little less ambitious. A few things that we are considering cutting out are the use of a Bluetooth connection directly to the computer, and a potential animation of the racket swing. Additionally, instead of attempting to process the data in real time, we will first collect the data and process afterwards.

Our first step this week is to complete a program within Matlab that will accept data from a serial connection to the Arduino. A basic skeleton of this program has been written, saving a written loop's values. Now, the important part will be for us to write out each degree of freedom's values through the serial port to be saved into Matlab. We currently have a library that is able to transmit several different IMU values, from Euler values to quaternion values. We will be researching the most appropriate values to send from the IMU, and then we are going to want to collect that data into Matlab and save it to the workspace so that we can begin analyzing the data.

Our next step is to process this data. We will be using inspiration from a few of the papers that we have read, and in particular, the rotation matrices used in a golf putt analysis Link. While we will have to refine the matrices due to our different definitions of our "zero" positions, how many links we have, and the position of rigidity, this is nevertheless a good starting point.

Finally, instead of connecting the Arduino via Bluetooth directly to the laptop, we will most likely use a second Arduino with a Bluetooth connection that is connected to the laptop. This, according to Kjartan, will allow us to maintain the same basic code for data collection as if the original Arduino were connected via serial port to the computer. This will help us avoid the need for writing in Objective-C, which we had not realized we would need to do (and with which we have no experience). Once we have prepared the script in Matlab to collect all data points correctly and we are able to process the data, we will then begin to prepare the data transmission from one Arduino to another.

We would ideally like to create a visualization of our swing, but this may be a long shot. Currently, we have a library using Processing.app that animates in real-time, but it only reads accelerometer values. If we are to modify this, we are going to need to read other values as well to recognize movement of the IMU. Luckily, it removes a real need to use OpenGL and allows us to work within Processing.app itself. However, this is our final step and we will not worry about this until we know we absolutely know we have the time to dedicate.