Home

I spent this week working some on the physical holder for the dev boards/handle attachment. I worked on making a new design that is more user friendly. I made it have a better fit so that it doesn’t move around on the handle. This allowed us to collect data without needing to use tape to secure our dev boards to the racket. The dev boards are currently just hot glued onto the 3d printed part, this is working much better than the previous method which was sub-par double sided tape. Next I will begin working on a design that does not need to use hot glue and instead just has mounting holes and press fit solutions. I have begun testing this in parts (fit holds for the IMU dev board), but there is still additional work to be done on this. I expect to finish this next week. I also worked on making visualizations of the swing path. I wrote some code using matplot lib that visualized the IMU movement in a 3d graph. I also spent a bit of time getting the battery to work, I wrote some simple code that reads out the battery voltage level and also had to change the pins in the battery header as they were incorrect.

My progress is on schedule, but the data collection needs to be moving at a faster rate. We were able to collect some initial data, but need to spend more time collecting data so we can train our model.

Next week I hope to finish the physical holder for the dev boards and also start looking into bare component & PCB fab.

As of now our team sees no greatly significant risks to achieving our MVP. However we have compiled a few potential blockers or issues to tackle in the next couple weeks. Firstly is ensuring that our bluetooth transmission works effectively. We hit a blocker this week with getting bluetooth transmission to work when using SPI and interrupts. This shouldn’t be a long term issue. Secondly is the design of the case for our embedded system. We are currently iterating on different approaches for attaching our system to the handle of the racket without impeding on the user’s experience. This may or may not take longer than 3 weeks to get in an acceptable range. 3rd is designing the ML pipeline for this system. We have done substantial outside research to give us confidence that our design can succeed. However, we will undoubtedly need to make changes to some parameters as is reasonable with our own hardware and data flow.  

In order to mitigate risk 1: we will be building slowly up from sending simple messages via bluetooth to reaching the high performance transmission throughput we need. At some point in trying to integrate bluetooth with our overall system it stopped working completely. We will need to build, test, and validate incrementally this time around to be able to debug more effectively. 

In order to mitigate risk 2: we will be constantly iterating our design to minimize user impact. We will be reaching out to collegiate tennis players that we know in order to get feedback on our ideas and implementation as we go. 

In order to mitigate risk 3: we will be working on creating a baseline pipeline that works structurally the same but with less expected accuracy. We want to uncover unexpected issues as quickly as possible to make needed changes. We will additionally be doing testing and verification of our data flow to ensure data integrity as it goes through our ML pipeline. This will be pivotal in ensuring accurate results when testing the ML.

We made successful improvements to the application to make the user experience better. We also successfully recorded our first swing. We created a new attachment for the prototyping boards that fits the handle better and moves doesn’t move around at all and then hot glued the boards on for prototyping. We also wrote some code to visualize the swing path.

Over this week I focused on developing the prototyping hardware, I spent time doing the CAD of a simple attachment to hold the dev boards to the racket. I iterated through some designs to get the right tolerance so that the holder could slide over the butt of the tennis racket without too much difficulty and not move around too much. I did the CAD in SolidWorks and did the 3D printing on my personal 3D printer. Having my own 3d printer was super helpful for the development of the part because I could rapidly iterate the design. 

My progress is sort of on schedule, but I think I need to break up the tasks into smaller items on the gaant chart. For instance I have physical prototyping as a task that spans over multiple weeks, but I think I should break it up into smaller more specific tasks that I can accomplish part by part. Also last week I wrote that I wanted to be collecting some initial tennis swing data by now, but some unexpected travel plans got in the way of that. I should be able to completely catch up the first week back at school by finalizing the prototype hardware and then hooking up a small battery. 

The next week will be big, I have some CAD ready to go and want to finish the physical prototype and start collecting data. We are planning to start collecting initial data during the first week back from break and use that to start training our model for stroke classification and other data metrics. 

During the next week I also want to finalize bare component selection and place an order for a PCB. 

This week I brought up the IMU and microcontroller: I soldered on the pin headers and the jumpers on the IMU, got them all wired up and then tried to get them to talk to each other. Getting this all to work took a bit of debugging, but I was able to read data from the IMU onto the microcontroller. I have it working over USB, no bluetooth yet. It currently prints out the acceleration in x, y, and z as well as the gyroscope data in x, y, and z. I was very happy once I was able to actually see the IMU data printed out over serial.

I also spent time working on the prototype version of the buttcap attachment. It is currently just a prototype and much larger and bulkier than the final version will be, we just wanted to get something working with the dev boards so that we can start collecting data as quickly as possible. The size is heavily constrained by the dev boards vs having just the bare components. The most important design constraint to determine is how we actually attach our device to a tennis racket in the least intrusive way possible and also make it adaptable to a variety of tennis rackets. I plan to visit a tennis store to look at a bunch of rackets and hopefully talk to a worker there who can tell me some of their ideas.

My progress is currently on schedule but I foresee challenges adhering to the planned items this week. In our schedule I am supposed to finish the hardware design next week, but I think this will take multiple iterations and not be done until we have the bare components. Our team is meeting tomorrow to revise our schedule and adjust. I do not think we planned enough time for hardware design iterations. We have physical prototyping as a multiple week item and I think we can adhere to that but the final enclosure design task should be broken down into more tasks and better scheduled.

In the next week I hope to get a more polished version of the prototype hardware done, and start collecting some initial data from the IMU while it is attached to the tennis racket. Part of this involves ironing out the specifics of the data flow, which Mario is doing. It is important for me to sit down and go through the design process of our hardware design with higher fidelity next week. I want to have a clear actionable design that I can work on some over spring break, and do PCB board design, etc. other CAD as needed.