Home

Team Status Report for 02/21/2026

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 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. Secondly 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 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 2: 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 do not have an updated schedule as of right now, but plan to make some changes to the schedule moving forward, which will be reflected in the next status report. Most importantly we believe we need to break down some of our tasks further and allow for time to iterate the hardware design.

Photos:  

 

Mario’s Status Report February 21

This week I prepared for our teams design presentation and presented it. I also started to do work on devising a scheme for organizing and batching IMU data in the embedded system.

I am on schedule.

Next week I will receive the parts to be able to start implementing some of the protocols and give Geronimo some foundation to start coding the receiving end of the IOS application. I have been slightly blocked this week but we have accounted for this in the GANTT chart. Next week I will implement my data batching scheme and output data via bluetooth. I will also work on completing a test suite that will show metrics of the working system.

Geronimo’s Status Report February 21

This week I made some great progress on the UI of the app. I worked on setting up the different data separation for Rally and Serving. Demonstrating how the resulting data would show up after processing. I also updated the 2d grid into a 3d grid to demonstrate the swing paths.

Progress is currently on schedule and I do not have any blockers.

This coming week I hope to keep updating the UI as needed and start working on creating calculations that will be used with the incoming data to make predictions on some of the statistics.

Geronimo’s Status Report February 14

This week I made some progress on the UI of the app. I also read through two research papers of similar projects that professor Quinn provided us. I mainly focused on the serve path part of the UI and getting more adept and understanding how to use the JS and React frameworks. I found a great resource that provides a lot of help and guidance for creating the app.

(I had a video going through the UI but the file was too large)

My progress is currently on schedule

Next week I hope to have finalized the base UI set up with some false data as well so I can start to test out how it will look properly once we have data being streamed in.

Team Status Report for 02/14/2026

We still believe that the most significant risk would be having to do with part incompatibility or taking too long to get our hands on the parts. We are mitigating this by choosing parts that are in stock on DigiKey, and also finding alternatives on Amazon where applicable. If we run into serious issues here, we can always choose different hardware components to prototype with and then switch over to the actual components we want to use for our final product later on. It is important to get data flowing as soon as possible so we can begin some initial testing, data characterization, and data analysis. An additional risk is the player experience being affected too much by our product. As of now, our team is ideating the best way to design the case so that it meets our technical requirements, while also remaining relatively discreet for the player. Some factors that lead to our concern are the necessity to keep the part light, thin, and water proof. Our current plan to mitigate this is to prototype quickly with simple, unsophisticated designs and rule out certain approaches to maximize user experience quickly. 

No changes were made to existing design of the system. At least to the hardware. We are still in the process of ironing out ML algorithms and methods that fit our use case the best. Thanks to a few papers and additional research, we have been able to select the algorithms and methods that will allow us to achieve some specific requirements, such as swing type classification and performance analysis accuracies. Specifically, we will be using Support Vector Machines to do classification, we will segment and extract features of the IMU readings before and after the impact stage to capture events, and also use a similar performance scoring system of using power and timing of different strokes. Additionally, we are focused on exploring physical prototyping for our case. But we did not have exact answers for these before so it is not a significant change. These costs are minimal.

Some of the research we analyzed to get a better idea of ML to use: paper1 , paper2

 

Mario’s Status Report for Feb 14

I personally worked on completing the design proposal slide deck that I will be presenting on Monday, Feb 16. For the proposal slide deck, I did additional research in order to garner more accurate quantitative measures for our project. For example, I calculated an approximate guess of our size of market based on comparing similar products in the golf industry. I also read and analyzed two research papers of similar projects: paper1 and paper2 which had much relevant information for us. Thanks to these papers and additional research, I have been able to select the algorithms and methods that will allow us to achieve some specific requirements, such as swing type classification accuracy and performance analysis accuracy. Specifically, we will be using Support Vector Machines to do classification, we will segment and extract features of the IMU readings before and after the impact stage to capture events, and also use a similar performance scoring system of using power and timing of strokes/serves. 

 

My progress is on schedule.

Next week, I hope to give a fantastic product design presentation. I hope to start programming the embedded device that should be arriving. I would like to test the IMU, and start receiving, processing, and transmitting data from it. Finally, I want to complete a test suite that will show metrics of the working system.

David Status report 2/13

This week I finalized our (prototyping) component selection, I ordered an IMU and a microcontroller. I did some work to make sure these would be compatible, and that initial prototyping would be viable with these components. I ordered dev boards for easy set up and prototyping ease and I made sure that we could also get just the bare  components as well. It was a bit of work to narrow my list of components down to options that had both dev boards and bare components available. I looked for parts with significant quantities available on digikey to ensure that once we had the prototype working, we could order a bare component of the same device. Although the dev boards may be too large and heavy to fit some of our weight and size constraints we set for our final product, they will allow us to set up prototyping and data collection quickly which is the most important thing for us in our stage of the project right now. I have begun doing CAD for 3d printing a test rig that will attach the two boards to the tennis racket for initial data flow and testing 

 

Our progress is still on schedule; I submitted in the order to pay for two day shipping for the parts I ordered so that we would get them in time to use them over the weekend but unfortunately I was not notified to pick them up yet which is unfortunate. This has slowed our expected progress a bit but it is okay, we are not behind our planned schedule. 

 

If the parts aren’t available for pickup on monday we may have to think of other ideas to simulate our data flow to keep progress moving. This coming week I hope to have a physical prototype to test our data flow and data collection process.

David status report for 2/7/26

This week I practiced and gave our initial presentation, and then the rest of the work I did was on selecting hardware components to use. I looked into IMUs and microprocessors that we could use. I also did a bit of research into how we could make the whole part waterproof, we could use a pogo push pin connector for charging and then put the rest of the electronics in an epoxy. 

 

I am making it a priority to select and order parts on Monday so that we can start prototyping as soon as possible. I am still on schedule for now. I plan to order parts on Monday and hopefully be able to get a working rough prototype by the end of this week or early next week (somewhat depending on part lead times and ordering process).

 

I think the STMicroelectronics LSM6DSV is the IMU we will use, but I am working to confirm that we can get both a good dev board for prototyping and an individual component later on for connection to our PCB we design.

Team Status Report for 02/07/2026

We think that one of the most significant risks would be if parts have long lead times or if the ordering process takes a super long time. We are mitigating this by choosing parts that are in stock on DigiKey, and also finding alternatives on Amazon where applicable. If we run into serious issues here, we can always choose different hardware components to prototype with and then switch over to the actual components we want to use for our final product later on. It is important to get data flowing asap so we can begin some initial testing, data characterization, and data analysis. We plan to order parts early this coming week, hopefully get them in by the end of the week or early next week, and have a working hardware setup by the end of next week.

 

Some metrics could not be as easy to read as we might think, and could lead to metric calculations being poor. These risks are being managed by having the base idea for the metrics be more general or by having range values instead of giving specific values. As a contingency, we have a few other metrics that we could try to calculate instead.

No significant changes have been made, we are still working on choosing the specific hardware components, but no major changes, just part selection. 

 

No schedule updates at the moment. Still following the original schedule.

Basic UI setup has started: