Category: Team Status Reports

team status report 4/25

Our team did a lot of work on our project since our last check in, across various areas of the project. We made progress in our app, mainly on adding stuff to improve the user experience:  gamifying components that include, challenges, progress trackers, and some comparisons between users (i.e. competition with friends/club). We began working on incorporating an LLM to give specific feedback of player’s swings. We also improved our ML model to classify different levels of players. We also improved our hardware design a lot so now it won’t come off at all and we can start recording data with ball impacts, which we previously could not do because our device could come off if you swang the racket fast enough or just pulled it off. We worked on some microcontroller code to collect different windows (used to be time based) so that now it detects ball impacts. 

 

Our biggest effort for the remainder of this project is to collect a ton of data and use it to train our models and improve our swing path visualization. We haven’t made any significant changes to our product or schedule. 

 

We have no blockers apart from some rain in the forecast which prevents us from collecting data (if the courts are wet).

Team Status Report 4/18

Our team made strong progress this week in many aspects of the project. First, we improved the hardware design for the racket attachment. The new prototype is smaller and fits the key components better than the old version. We still need to make more progress on the PCB, so that’s one thing we are working on. Second, we made great progress on data collection and the ML pipeline. We collected a large amount of swing data from many players, improved the bluetooth flow to make collection more reliable, and built a model that can classify stroke types with high accuracy. We also continued working on swing visualization, and we still need to improve its accuracy. Third, we improved the app experience by adding an AI coach and a profile section that gives users summaries and feedback on their progress.

In order to mitigate risk 1, we will keep iterating on the hardware design so it fits well on the racket and does not negatively effect the user experience. We will also keep working on a final version of the PCB and overall attachment design.

In order to mitigate risk 2, we will continue collecting more data, improving the model, and testing the accuracy. This will help us incorporate more swing types and improve consistency across users.

In order to mitigate risk 3, we will keep working on the swing visualization and continue checking the reliability of our firmware, bluetooth transmission, and sensor data. We want the full system to stay stable during real use.

We also made progress outside the core prototype. We prepared for an upcoming pitch competition by working on the BOM, user guide, market research, unit economics, logo design, and presentation script. Overall, the team had a productive week and we do not have any large blockers right now, but our main focus next week will be final hardware design, better visualization, more data collection, and further improvement of the ML model and AI coach.

Team Status Report April 4

Our team is making steady progress on all fronts with regards to calibration testing of the IMU, the design to hold the IMU, and visualization of data. Our biggest priority now is data collection for fine tuning a model that will categorize different swings. This will allow us to make large strides in our project.

To accomplish this goal properly we need to both collect enough data and collect data from a variety of player levels. Once this is done we will be able to then fine tune the model and test its accuracy.

After this is complete we will also be testing the device during a proper session to see how it holds up and making sure the data for sessions is being organized and displayed properly.

Team Status Report 03/28

As of now our team sees a few potential risks/blockers for achieving MVP. 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. Lastly and newly, we are a bit concerned with how often we may need to be calibrating our IMU to have it work consistently for as long as possible. 

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.

In order to mitigate risk 3: we will be working with filters and doing our best to calibrate the IMU to the fullest before making decisions as to integrate more sensors or change up our approach.

We have made successful transition from collecting data to the computer via bluetooth to actually being able to use the IOS application to collect data. This is great for the demo and great for our future progress. We have also made improvements to the IMU gyroscope and accelerometer readings by applying filtering to the sample data.

Team Status Report 03/07

Our team continues to make steady progress toward our MVP and currently sees no major risks to completion. This week we continued progress on hardware development, embedded systems, and the application. We had a couple iterations on the hardware attachment that attaches the device to the tennis racket. On the embedded side, we updated the controller code to use SPI instead of I2C and successfully read IMU data packets at 500 Hz while transmitting data via BLE. On the software side, we began integrating the IMU data stream into the app and started implementing calculations to approximate ball velocity.

One potential challenge that carried on from last week is finalizing the physical hardware design. The attachment must be securely mounted to the racket while avoiding movement during play. When we begin collecting real swing data, we may also need to adjust parts of the data pipeline or processing steps to ensure the data is reliable and can be used for our specific use cases consistently.

To mitigate hardware risk, we will continue iterating on the attachment design and finalize the prototype so we can begin collecting swing data. We will also finalize component selection and place an order for a PCB.

To mitigate data and ML risks, we first need to establish a working end-to-end pipeline before focusing on model accuracy. We will collect sensor data via BLE, run basic analytics on the laptop, and begin preparing the dataset for model training. We will also continue adapting the app so it can interpret the incoming IMU data and compute metrics accordingly.

We do not have an updated schedule.

Our focus next week will be continuing to work on the physical prototype, collecting initial swing data, integrating the IMU data pipeline into the app, and beginning early model training for stroke classification.

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:  

 

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

 

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: