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.

April 4th

Tomorrow will be our second meeting with Kjartan and Humberto, for another project evaluation. Currently, we believe that we are in a good place in our project. We have successfully connected the Arduino via Bluetooth to the computer, and we have tested data transmission from to IMU to Matlab. Thus, we have completed the section of our project concerning data flow. We still have our basic animation, but we are putting off the final animation until last. We have our prototype setup for our Arduino-tennis racket connection and we will be ready to start collecting data. This will be the next step for us - after that, we're going to figure out what we want to do with the data. Since we'll have collected everything and transmitted it into Matlab, it will now be about filtering, processing, and manipulating that data.

April 11th

With just a few weeks left, we have completed our second evaluation with Humberto and are pleased with the progress we have made thus far. We now have a few things left on our docket that we need to complete to finish this project. We begin with data collection. Because of poor weather, we have postponed collection until we find a good day for about an hour to collect data. Once we have done that and verified that the data is sound, then we will be able to manipulate the data that we have collected.

In our meeting, we discussed two things. One was the kind of filter that we wanted to implement, and the second was what exactly we wanted to do with the data. For the filter design, Humberto suggested that after collected the data, we use a Fourier transform to look at the frequency response of the data, which would then allow us to figure out what kind of filter we would want to implement. Once we collect our data, we will take hard look at that.

With regards to what we wanted to do with the data, we have compiled a short list of the things current tennis racket sensors offer, and we have decided to focus on the following: a shot counter and racket head speed. Once we have the data in hand and implement our filters, we will be able to ideally read these results. In addition, we are going to look at creating a Matlab GUI for easy reading.

Finally, we need to find a more consistent solution to keep our IMU from falling out of the bottom of the tennis racket. At present, duct tape should suffice, but we will be hoping to find a sturdier solution in the future.

April 21st

Apologies for a late entry, one of our members has been traveling a lot since March. We have found that a part of our code was significantly slowing down our data collection, so we removed the 'drawnow' part of the loop and it's sampling much faster. We had collected data previously, but now we will need to collect data again, which will not take long. Hopefully, this will also allow us to use the FFT in Matlab. That way, we can figure out how we can set up our shot counter.

We are closing in on the final week and demos. What we have left is to write our paper and make our poster, and to clean up our Matlab GUI.

April 28th

This is our final weekly log entry. This has been a very educational semester. Looking back, we had set off with pretty lofty ambitions, but thankfully, we had Humberto and Kjartan help us narrow our focus and scale back. Our demo went well today, showing good accuracy for both the shot counter and the swing speed. In potential future work, we had a few ideas for improvement. One was to include a memory buffer to the Arduino, allowing the collecting of all data before transmitting to Matlab. This would ensure that no data is lost during Bluetooth transfer. Ideally, we'd also be able to make the entire system more compact with less wires interfering. They did not get in the way of the swinging, but in a live tennis scenario, it is possible that the Arduino and the IMU would become disconnected.

We would both like to say a huge thank you to Professor Gonzalez and Kjartan for a great semester, and we're more than happy to recommend ESE205 to future engineers at WashU.