Tag: Team Status Report

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.

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

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: