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.

March 14th

It is currently the week of spring break. When we last met with Kjartan, we worked on the way that we were going to get data from the Arduino to Matlab. Currently, the code loaded onto the Arduino uses a custom data type called VectorInt16 to send the acceleration values, which is a signed 16 bit integer. What we have to solve is how to send this to Matlab, which only reads 32 bit integers. Currently, we are working to find a solution to this. What we are currently working on is converting the integer to 4 bytes, and using Serial.write to send each of those individually to Matlab. Then, within Matlab, we would reconstruct each byte and read them as x,y, and z coordinates. What we want to have by the next time we meet with Kjartan (Tuesday, March 22nd) is a way to send the data in a reliable way to Matlab.

Once we are able to have our raw values in Matlab, our next goal is to be working on our translational matrices. This will likely require some mathematical work, but we believe that we will be able to work this out a week from that meeting.

March 28th

After spring break, we met with Kjartan on Tuesday and we were able to successfully save data into Matlab for as long as we wished. Currently, we are saving roll, pitch, yaw, as well as x, y, and z acceleration coordinates. This is exciting for us because we have found a way to transfer all of the data being collected by the IMU and collect it into a program that we are familiar with. Over the past week, Jonathan was gone for work-related resasons, so the focus was for Ryan to complete the physical implementation of the setup. We are in the final stages of completing this - our last part is the ribbon cable and making sure it is long enough to avoid accidental removal from the Arduino or IMU.

There are now a few steps we will attempt to tackle this week. The first is completing the data transfer over Bluetooth. Currently, we have been making sure that we have a solid data flow via serial port. After some research with Kjartan's guidance, we found that connecting the Bluetooth Shield on the Arduino to an external USB Bluetooth module connected to the laptop would allow us to avoid writing an entirely separate program to allow the shield to interface with the computer's internal Bluetooth. Moreover, Matlab has built-in capability such that it will only require a few extra lines of code to accept the Bluetooth connection, and the incoming data will be "seen" the same as if the data were sent over serial port. This is crucial because our data collection so far has been predicated on a hard connection, so once we are able to transmit via Bluetooth, we will be making strides forward. The other task that we would like to get a start on is the translational matrix section. This is more of a mathematical aspect, and we will need to read over previous papers to make sure our understanding is correct. According to Kjartan, this should not require too much time as long as we focus for a few hours. We will want to be able to implement these matrices by two weeks' end. Finally, we will want to implement some sort of filtering to make sure that all of the data points we receive are not skewed. Looking at the live output, it does not look like there is much data that will be removed - there are only a few outliers, and the most important thing that we will need to address is the drift.

We feel we have made decent strides since our first project meeting. While we may have sheepishly overestimated our abilities to finish an entire project this semester, I believe that our project, with our readjusted goals, is now more realistic. We have gotten a basic animation running (only using roll/pitch/yaw but will soon include x/y/z acceleration), and this will be the final part of our project, but it's been helpful for visualization of our work and helps us frame what we want to see.