This week I have been working on the visualization and validation of our IMU data.
Progress was okay this week. We are getting good visualizations but not very consistent. I have been very busy elsewhere this week so progress hasn’t been as much as I would have liked. But it should pick back up soon.
My goal for this coming week is do to start accumulating data for model training and assisting in visualization technology.
This past week I worked closely with Mario to improve the swing path generation. We made great progress and the swings to be generating consistently with some reoccurring issues that are being debugged. I also did some research on how we would be planning on training the model for the project and found a pre-trained model we can use that interprets IMU data. All we need to feed it is labeled data from out IMU
Progress this week was good but we unfortunately were not able to record some data. We worked on making sure the data incoming from the IMU was accurate to make sure the data we were going to feed the model is correct.
We’re a few days behind on data collection because varsity tennis reserved the courts this weekend for a weekend tournament they had.
For this coming week I am looking to collect some data and start the training process of categorizing swings
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.
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.
This week I worked on connecting the IMU to the app through bluetooth. The first step was to upload the app on my phone and not work on xcode anymore. After that I had to work with Mario to connect the IMU via bluetooth and be able to read the data. Currently we have base functionality when connecting and reading data.
Progress this week was steady and we focused on preparing for the demo.
My goal for this upcoming week is to keep working on the device reading of sessions and also some work with the type of swing reading.
I haven’t started the training for determining types of swings yet which puts me a bit behind, but I am sure I will be able to catch up on this.
This week I have been working on integrating bluetooth communication between the iphone and the microcontroller with Geronimo. I also worked on calibrating the Gyro scope and Accelerometer with David before he took that over.
Progress was good this week. We have been preparing for the demo and we believe to have hit our target goals.
My goal for this coming week is do a successful demo and continue to clean up IMU data using filtering and other techniques so that we can start to collect data for our models.
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.
As of now our team sees no greatly significant risks to achieving our MVP, having not really changed since last week. We still have a couple potential blockers or issues to tackle in the next 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 made successful improvements to the application to make the user experience better. This weeks work largely involved continuing to improve the things we started last week. We further streamlined data capture this week for example. Next week we will be connecting all parts of the system including the application to be ready for interim demo. We should have surface level data analytics ready and swing path visualization for the demo, including our 3rd iteration of the physical attachment.
This week I spent some time talking to users about the product we are building, which was super useful. We did this some when we were initially getting started, but now I am doing more of it and finding it very useful as I start to think about this as a product and not just an engineering project. I also spent a good chunk of time looking into other similar products/projects on the market. I looked into products in the tennis space, pickle ball, and also golf. Golf is the most developed of the three, and although it is a bit different I was still able to learn some valuable things from looking into golf trackers/sensors. One anecdotal takeaway I had from this was potentially designing our sensor to screw into the tennis rackets instead of just press fit (this was taken from Arccos golf product).
On the engineering side, I spent some time looking into IMU calibration with mario, and also started taking some steps to work on the bare component design. I have found bare components for the IMU and the microcontroller and I have started making a schematic to connect the two. I have also identified two manufacturing houses we could use for PCB assembly. I am not behind yet, but next week it is crucial that I place the order to manufacturer PCBs.
My main goal next week is to place that PCB order which involved finishing the layout etc. I think I can complete this next week as well as help with data collection and adhere to the planned schedule. I do not think there should be anything that will impede my progress.
This week I was able to integrate the data being collected from the IMU to the app and have it produce a swing path. This still needs further testing and refining but the ingestion of data seems to be working.
For the coming week I hope to continue testing the swing path interpretation and start work on the other aspects: predicted speed path, type of serve, swing path labeling, etc.
No blockers for this week