Since last status report, I have gotten more data for swing categorization and gotten feedback from professional tennis coaches to get better insights into what feedback we can give to players. I also worked on creating two different versions of micro controller code. One that activates data detection after a swing without contact with the ball and one that does with the ball, for live play. I have not worked much on visualization yet but I will finish off this last week by focusing on visualization, and continuing to get more swing data.
Progress was a bit more stalled this week. Final projects and presentations have staggered my ability to work this past week.
My goal for this coming week is to get visualization to be more accurate and collect more data for swing categorization.
Since the last status report I have made a new prototype for us that is much smaller than the previous version. Previously both of the dev boards were just hot glued to an attachment that stuck out from the bottom of the racket, both boards had header pins and wires connecting those. There was also no battery. In the new design each component (battery, IMU, microcontroller) has its own “compartment”. This took a lot of iteration to get all of the things to fit together well, and then even after I thought I had finished and I went to solder the boards together with wires and then it messed up the fit of the components in the 3d printed parts so I had to iterate further, The current design also has wires that are longer than necessary, I did this as an intermediate step so that if/when I need to iterate I don’t need to fully get new wires I can just trim the current ones and re solder them. I have already learned some ways I can make the design better and I should have a final version by the design presentation on Monday.
I also spent a ton of time this week working on our project as a startup, we have submitted to two pitch competitions and will be presenting on Wednesday at one of them. I have done stuff like making a final BOM and calculating all the parts in that down to the material and printing cost of the user guide that would be placed in the box the product comes in. I also looked at unit economics, did lots of market research, logo design work, and tons of work on the script for the competition.
I am behind on the PCB design which is bad, I wish I had that more under way and ready for fab. I am going to try and make that happen by the design presentation, but I have a lot on my plate preparing for the competition on Wednesday, so I am not sure I will be able to finish it. I do want it done by the time the final poster board demo happens though.
I have really been enjoying the project this week, we have met up every day for at least a few hours to work which has been great.
In the next week my main focus will be preparing for the competition, and working on final hardware design.
old design:

new design:
there is a video that makes the new design much clearer but I can’t upload a video here. I showed it in person to Qing during our mtg on Monday
This week I supported our efforts on getting the demo running. I worked on calibration and filtering. I made a script to run calibration of the accelerometer, but ultimately determined that the bias set from calibration at the factory was actually good enough for us. So I didn’t end up using the data I got from this work, which was a little frustrating I suppose, but still good learning. I did implement a real time gyro visualization which showed us that we needed to add filtering. Previously we had a visualization with matplotlib which was good, but it had a lot of delay so it was hard to really tell how accurate the visualization was to the actual movement of the IMU. I made a new visualization using pyqtgraph which had much much less delay, which was super helpful. It showed us that the gyro needed some filtering: we noticed some issues such as after moving the IMU quickly the following data would be inaccurate and it would fail to return to the same position (after holding it in one place, then moving it a bunch, then putting it back to original position, the visualization would show that it was off from the original orientation). I implemented this simple Mahony filter I got from a library, and it worked great. This was a huge step for us in helping us get more accurate data.
I also spent some time this week working on the physical prototype. It took me longer than expected to get the right dimensions and tolerances for making press fit holds for each part, each one took multiple iterations. I now have the right dimensions for each individual component (battery, IMU, and microcontroller). I don’t have access to the right size screws unfortunately since the techspark machine shop is closed on weekends, so I will need to wait until Monday to put it all together.
I am still lacking on the PCB design, it seems I may not be able to get the finished PCB in hand by demo day, but I will have the design for it finished and a model to show for it. I am hoping to have the final design done by EOD Tuesday.




This week was a bit of a mess in terms of progress, I should have gotten more done on the hardware side but instead was drawn into working with Mario on the calibration. We have been having some issues with getting the calibration and motion tracking down. I said last week that my goal for this week was to do the PCB work (I wanted to place an order), but I am far from being ready to do that unfortunately. I have been focusing my efforts on IMU calibration work.
We are fighting issues with bias and drift of the IMU. I made a script to visualize the movement of the IMU, but the path it drew was a bit weird and so that led us to investigate the gyroscope and accelerometer data individually. We have a working live visualization of the gyroscope and are working on setting up the same thing but for the accelerometer. We want to then record on our phone the IMU moving 10cm and then track that against what our code predicts and use that to calibrate the IMU. This was something we did not foresee being a big challenge, but it has ended up being a good bit of work.
I am falling behind on the PCB development. The plan is to focus on getting the calibration and motion tracking working well for the demo on monday and then once that is going well I will leave Mario to carry that on and do more of the other metrics we wanted to track and I can go back to working on the PCB.
I don’t have any blockers right now apart from dealing with the IMU calibration issues.
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.
