Ricky’s Status Report for 4/27/2024

This week, I did some brief work in finalizing some metrics for the ML model. This included some rigorous testing into the real-time performance and the test-time performance. I was also able to develop confusion matrices on some data to get a better picture for how the model is working. I am also pretty confident in my final ML model design with the addition of some more words into the second model to allow for more refined predictions. I also briefly tested the model with the PCB as made by Ria. However, the performance of the model is inconsistent, which I believe is due to the fact that the PCB is currently being secured by tape. I will hope to continue testing once the PCB is more reliably secured, but we always have the original protoboard as a backup plan which I will propose if needed. I also spent a decent chunk of time working on the poster. This tied nicely with the metrics that I found. I also wrote out the start of the final report which will hopefully have us finishing before demo day.

My progress is on schedule with the slight caveat that I am waiting for the PCB design to be finalized. I foresee that minimal adjustments will need to be made once that is attached but we will have to wait and see.

Next week, I hope to quickly finalize our demo day product. Finish the report and video and present on demo day.

Ricky’s Status Report for 4/20/2024

This week, my main task was debugging our issues with the machine learning model. During the carnival, I trained some preliminary models, but their performance was not that good in real time. To compensate for this issue, I tested a variety of architectures as well as new activation functions. I also manually selected the new words that I determined were more easily mixed up and created a smaller simpler model for just those words. This allowed me to develop a two-model approach to classification that leveraged the original model’s strength at half of the vocab and the more narrow model’s strength for the rest. I also developed a model that handled time series data by stitching in the previous five frames of data as one input into the NN model. Armed with the variety of models, I entered this weekend with the plan of testing them all. I was able to determine that the two-model approach performed the best, being able to determine 10/11 of the words consistently. This was not a 100% rigorous set of tests, but it gave me enough metrics to assist with our final presentation slides, so I was content with that performance as of now.

My progress is on schedule.

Next week, I will narrow down which model I will use for our final demo with a more rigorous and formal testing of the two approaches. I will also assist in the development of the poster by adding additional pictures from the ML side. I will also assist with the video and the report.

Addressing the additional question, I definitely needed to relearn how to work with ARDUINOs and learn about how to interface between ARDUINO and Python. Since I handled the bulk of the Bluetooth and the machine learning side, I did need to handle a lot of the communication between the two platforms. This meant that I had to consult many pages of ARDUINO documentation as well as perform extensive research into compatible Python libraries. For learning strategies, most of it was on reading documentation and reading StackOverflow. I did watch a few videos of other example projects for assistance as well.

Ricky’s Status report for 4/6/2024

Most of the week, I was focused on collecting data and everything data-related. At the start of the week, we initially tried to start collecting data. However, there were some issues with the left glove. This ranged from some of the wire connections being loose to various parts of the flex sensor being caught in the string. I assisted in hashing those out and added my opinion about additional changes. While this happened, I adjusted the scripts to handle the two streams of data from the gloves. Then, once everything was set, we collected data for both me and Somya. We collected for the whole BSL alphabet which included 26 letters and an additional sign for the resting state. With around 1200 points for each letter, we were able to collect a total dataset of size 64800. I also handled cleaning up the data and visualizing it before we train a model with it next week.

Ideally, we would’ve also collected data for Ria, but due to time constraints, we were unable to. I believe that the best course of action is to proceed with this slightly smaller dataset and collect more if the performance is not good enough. With that in mind, I am on schedule.

Next week, I will develop a new ML model with the data we collected, evaluate performance, and make any additional changes as needed. I do foresee potential classification issues with several letters of the BSL alphabet, but I will hopefully discuss that with my partners on Monday. We might need to curate our vocabulary more rigorously or find another solution if the ML model does not reach our desired accuracy metrics. I will hopefully be performing verification tests next week to ensure both the accuracy and speed of the ML model and the overall classification system.

Team Status Report for 4/6/2024

One of the most significant risks is the performance of the ML model given the set of sensors. While collecting data this week, we were concerned about the large set of letters in the BSL alphabet that have extremely similar hand positions to each other but vary based on touch which our gloves cannot detect. We have not performed the development of the model so we are unsure if this will be a problem. If it is, we will look to test a variety of ML models to see if we can boost performance. Worst case, we will look to shrink the set of letters we hope to detect to something that our gloves can more feasibly distinguish.

As mentioned above, we will evaluate the performance of the ML model into next week and make changes to the vocabulary requirement based on feasible performance. We also added a calibration phase into the software before the ML model to help with adaptability to different users. In addition, we are in the process of ordering a PCB for the circuitry component. We will integrate that if possible during the last week.

Please look here for updated Gantt Chart: Gantt

In terms of verification of the sensor integration, we have added a calibration phase at the start of the data collection for each letter. What this entails is the user having their hands at their most flexed state and most relaxed state for five seconds. We then calculate the maximum and minimum data points from the sensor values collected during this phase, and check that they appear as expected. This forms a delta that is then used to normalize future data to be in the range of 0-1, normalized by the calibrated delta. In terms of verification of the ML model, we will look into the performance of ML models on various test data in offline settings. We will be able to collect relevant data on accuracy and speed of inference. In terms of verification of the circuit that integrates the sensors together with the compute unit, we take a look at the sensor/IMU data that is collected as the person is signing, and sometimes we will notice discrepancies that cause us to reexamine the connections on our circuit. For example, one time we had to change the pin one of the V_out wires was in because it was rather loose and affecting the data we were getting. 

With regard to overall validation, we will look to test real-time performance of the glove. For accuracy, we will have the user sign out a comprehensive list of the letters and evaluate the performance based on accuracy. We will also measure the time from signing to speaker output using Python’s timing modules.

We also plan on conducting user testing. We will have several other people wear the gloves and then complete a survey that evaluates their comfort, the visual appeal, and the weight of the gloves. They will also be allowed to make any additional comments about the design of it as well.

Team Status Report for 3/30/2024

The most significant risk that we face right now is the timeline for collecting the data and the robustness of the ML model. We hope to start collecting data next week which gives us ample time to collect more data if the initial dataset needs to be increased. Ricky also has plans for testing multiple different architectures and hyperparameters if the performance is insufficient. The other risk involves just keeping the readings consistent. This risk is being mitigated through some newly implemented calibration techniques and the introduction of a PCB.

The major change to the design is that we will as of now stick to the laptop as the main speaker component. This is due to our choice of ARDUINO which limits the speaker capability from the Arduino chip. We will circle back to this idea if time permits after testing and model tuning.

We will be proceeding with the original schedule. Ricky has adjusted a bit of his timeline to reflect some of the delays in Bluetooth integration and Ria has added the PCB creation timeline but it is relatively similar to the original schedule.

Ricky’s Status Report for 3/30/2024

This week I did a whole restructuring of our codebase. Originally, we had the Bluetooth and USB scripts written in the same file. But for ease of use, I decided to refactor the code so that the pattern in many parts of the code was separated. I also spent the bulk of the week fixing our Bluetooth system. When running the bleak package, I realized that its performance was very inconsistent for my Windows laptop. Further research identified that Bleak was not fully developed for Windows. As a result, I was forced to look into other Bluetooth packages. I eventually found the simplepyble package. I was able to integrate it and test that it properly connects to our gloves and ARDUINO. However, further tests showed that it was incompatible with the pyttsx3 package. This was because the prior demands a multi-threaded setting while the latter demands a single-threaded setting. I eventually found another speech package “win32com.client” using the Dispatch object. This worked! I integrated the Bluetooth, Speaker, and ML systems and did some benchmarking for performance. Quick tests identified that the time from sign to speech for USB is around 0.6 seconds and Bluetooth is 0.82 seconds. There are some quick hyperparameter checks that we can change to improve time performance at the risk of accuracy which we will look into later. I also helped assemble the circuit for the second glove. Please look below for our public repository for the codebase or future reference: TStar111/EchoSign (github.com)

The schedule is right on schedule.

Next week, the bulk of the time will be spent on collecting data. If time permits, I will start training and benchmarking the ML model.

 

Ricky’s Status Report for 3/23/2024

At the start of the week, I handled the training of the model with the dataset that we collected from the previous week. I was able to train a simple NN architecture to a high level of test accuracy. (See below for training visualization). Afterward, I was able to go back and test real-time performance. I didn’t test to a rigorous degree but I was able to replicate a high degree of performance on the glove as well. I was also able to quickly check the speed of the ML classification step. This step identified that the inference step takes an infinitesimal amount of time. This allows me to meet my design requirements of an accuracy above 90% and inference time of less than 25ms. I also took some time to add an additional classification heuristic on top of the ML model. This was implemented using an additional wrapper on the ML model, which checks for repeated occurrences of the same letter before firm prediction. I also added speaker capabilities from the pyttsx3 library in Python. I also spent a significant portion of the week debugging Bluetooth capabilities. We faced specific limitations due to our laptop not being Linux, but we were eventually able to identify the Bleak library as a reliable source for Bluetooth capability.

My progress is on schedule, though I anticipate that I will have less time next week due to upcoming exams.

Next week, I hope to assist with the development of the second glove as needed. I hope to also establish Bluetooth communication between the two gloves and the laptop at the same time. I will also hope to figure out what we plan on doing with the speaker. If time permits, I hope to start collecting data from the two-glove setup next week.

Team Status Report for 3/23/2024

One significant risk that we face right now is the development of the synchronization algorithm/heuristic. We were able to establish a Bluetooth connection from a laptop to the gloves via the Bleak library in Python. We are currently doing some preliminary research into connecting two Bluetooth connections at once to the laptop. We have a contingency plan of connecting the gloves and sending one stream of data to the laptop if our original plan seems infeasible. We are also exploring different strategies in generating audio output from the glove itself. We seem to be slightly blocked by our choice of ARDUINO so our contingency plan is maintaining speaker functionality from the laptop. 

There have been no major updates to the design as of right now. We will closely monitor the situation with the speaker and Bluetooth in the upcoming week to see if any adjustments need to be made.

We are on schedule as we have started working on the construction of the second glove. We have essentially finished prototype 1 as well, making it ready for presentation during the interim demo.

Somya’s Status Report for 3/16/2024

What did you personally accomplish this week on the project? Give files or

photos that demonstrate your progress. Prove to the reader that you put sufficient

effort into the project over the course of the week (12+ hours).

This week I attached all the sensors onto the glove and worked on implementing/testing the circuit. After performing unit tests and discussing an expanded range in our weekly meeting, we determined that op-amp use would be the way to go, and through use of op-amps we managed to expand the voltage output from 0.8V to 2V. 

 

Is your progress on schedule or behind? If you are behind, what actions will be

taken to catch up to the project schedule?

My progress is on  schedule. 

 

What deliverables do you hope to complete in the next week? 

 

Now that we are in the data collection phase, I want to do some more research into how we can clean up the data with noise reduction algorithms. In addition, I would like do some more research on the Bluetooth data transmission so we can more on that in parallel along with the data collection, as well as fabrication of glove 2

Ricky’s Status Report for 3/16/2024

This week, I had a hand in multiple elements of our project. I was primarily responsible for the software end things. I finalized the data collection script on the ARDUINO side. I also wrote several scripts to clean up our dataset once we were able to collect the data. I wrote some scripts that allowed for the plotting of the dataset for us to understand how the signings are different from each other. I was also able to test and revise my python scripts that received the ARDUINO data which allowed for successful data collection. I also assisted in glove fabrication. I helped debug issues with the ARDUINO including high source voltage and verifying the ADC. I also assisted Somya in attaching the sensors to the glove. Then, once the glove was ready we spent a decent chunk of time collecting around 30,000 datapoints across the three of us.

My progress is on schedule given the overall pushback of the project.

Over the weekend, I hope to train both NN and SVM using the collected data over the weekend. The plan is to have them trained by Tuesday/Wednesday and present the results to my teammates.