Tag: status report

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: