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.
