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
This week I have been working on allowing for data capture completely through bluetooth transmission and ensuring that we can do so within the appropriate time constraints. Last week I had an issue acquiring data via bluetooth at a reasonable speed. Leveraging some bluefruit library functionality and using troubleshooting tests to analyze the issue, I was able to get past some initial handshake issues. Now we can successfully trigger and read 3 seconds of data collection from the IMU via bluetooth.
Progress was good this week. We have begun preliminary data collection as we intended.
My goal for this coming week is to get a full bluetooth testing suite to know what our capabilities are. Additionally, I want to get the IMU calibrated and add an option to trigger gyroscope calibration via bluetooth. Accelerometer calibration is only needed once and not again, while gyroscope calibration may be needed multiple times a session. So I will do the accelerometer calibration myself and write code to support gyroscope calibration.
I spent this week continuing general work on the UI of the app and some general clean up so that the data we receive will be better organized and easy to work with. Towards the end of the week we got a JSON of some fake data so I started integrating that into the app so that it can read the JSON’s properly.
I am currently on schedule, but I want to start really pushing fro data collection to be a priority
For next week I hope to do at least one session of live testing after integrating the app.
This week I have been working on integrating bluetooth with the existing code and organizing data flowing serially into json formatted data compatible for ML use. I have written code that communicates with the embedded controller to signal the start of a 3 second window for data capture, prompting it to start sampling the IMU. It then formats the data it receives into json.
Progress was slower this week due to issues using bluetooth. It seemed that connecting to a central device via bluetooth would cause the device to reboot or something. Our priority is collecting data as soon as possible so I decided to pivot to ensuring that we could collect data and we were successful in doing so.
My goal for this coming week is to get bluetooth transmission working at full capacity and reliably. I additionally want to implement code that will allow us to trigger a data transmission event by relying on accelerometer values that should correlate to a swing.
This week I have adapted our existing embedded controller code to use SPI instead of the slower I2C. I additionally created and tested code that allowed for BLE transfer of data from the controller to the laptop. I tested and confirmed that we were able to read a data packet from the IMU at 500 hz.
Progress is continuing smoothly.
My goal for this coming week is to implement code to collect data packets via bluetooth on the laptop to begin basic data analytics and machine learning. I want to clean up our existing code. Lastly, I want to make a test suite for bluetooth transmission to determine our maximum rates of sending data.
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:
This week I prepared for our teams design presentation and presented it. I also started to do work on devising a scheme for organizing and batching IMU data in the embedded system.
I am on schedule.
Next week I will receive the parts to be able to start implementing some of the protocols and give Geronimo some foundation to start coding the receiving end of the IOS application. I have been slightly blocked this week but we have accounted for this in the GANTT chart. Next week I will implement my data batching scheme and output data via bluetooth. I will also work on completing a test suite that will show metrics of the working system.