Carnegie Mellon ECE Capstone, Spring 2026 – Todd Achuff, DJ Lloyd, David Zoota
This week I worked with David to finish assembling the glasses. This involved mostly getting our battery packs set up and getting the microphones fully attached.
Later in the week I also worked with the rest of the group to run some final tests of our system and constructs some graphs for use in our poster and report.
The project is pretty much finished at this point so we are very on schedule and there isn’t really anything left to complete next week.
Personal Accomplishments this Week
The main thing this week was doing my final presentation and doing final testing and video making with David and DJ. Since our product is complete, we wanted to get a head start on some of the things we need for later next week.
On Schedule?
Everything is still on schedule, and I plan on getting the poster done by Monday night to get ready for the TechSpark expo.
Deliverables?
The product is done and all that is left is to complete the report, poster, and video as well as get ready for the demo. I am mostly responsible for the poster.
What did you personally accomplish this week on the project?
Finished mounting. Attached microphone and battery components. Working on final deliverables.
Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?
We are on schedule and done other than write up related documents.
What deliverables do you hope to complete in the next week?
Final project done. Both glasses.
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
Our project is working now. There are no major risks other than some part breaking in the last moment. There is no obvious thing that would break but with 10-20 parts any individual part has a small chance of failure. To mitigate for demo (and contingency), we have some backups parts that could theoretically be swapped.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
No design changes other than making glasses into a glasses mask because we couldn’t get the hinges etc.. required to make glasses one size fit all.
Provide an updated schedule if changes have occurred
No changes have been made to schedule.
Testing
Unit tests: distance, angle, speed.
System tests: latency, usability, sensitivity, accuracy
Our overall finding from our tests is that the portions of the system that we developed perform very well and are very accurate. Most of our system limitations are due to the vosk V2t. For instance, our system losses in accuracy are fully from vosk as once a word is translated, our transmission and receiving process has perfect accuracy. Training our own V2T is incredibly difficult and would likely be worse than vosk anyways so there is not much we can do in regards to this. However, Vosk is still decently accurate and even when it makes mistakes, its mistakes are to similar sounding words that a user can often tell what was supposed to be said. In terms of our speed test, we have known for a while that our system was sufficiently fast (and that the limitations on speed were due to Vosk). As a result, we knew we could maintain hamming correction even though our accuracy is ~100% in transmission. For usability tests, switching to glasses seemed to make our device more usable and easy. People can now hold it up and take it down when they dont want to deal with it which is probably good for demo purposes. We had some friends try it and score it and they agreed. Finally, with system sensitivity, we discovered that our system is most suceptale to strong background noises. This is a vosk issues and the best thing we can do to mitigate it is to be careful with microphone placement. We made our microphone set up in a way that users can put it quite close to them which seems to be the best mitigation of sound sensitivity.
What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?
The main risk to our project at the moment is the failure of the electronics in the mounting of our design. However, since we have successfully mounted one of the glasses, we are confident that the other should go even smoother. One other things that could prove difficult is making sure that everything is clean and readily available for a user to use that may not be as familiar with the project as we are. This involved cleaning up wiring and making sure that nothing will break. We already have plans in place to remedy this as well as contingency plants to simplify the glasses design so that anyone can sue them without much issue. This could be not mounting all of the parts of the glasses because they may not fit everyone’s face.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
The only thing that may have changed I have described above, where we may simplify the design for the demo for easy of use, while having one complete system to display what the completed product will look like. This does not have a large cost to the project other than not having a totally completed product like we envisioned for the demo, but makes the demo much ore accessible without having to change the physical design.
Provide an updated schedule if changes have occurred
No changes have been made to the design or our schedule.
Personal Accomplishments this week
For this week, the main thing that was completed was the mounting of one of the devices on the 3D printed glasses and testing that it worked with one of the breadboard setups. This went very smoothly (other than glue issues) so we can move on to mounting the second device to have available to show at teh final presentation. Other than that, I have been preparing of my presentation last week.
On Schedule?
We are still mostly on schedule and plan to finish mounting our device before presentations start. We got over the small hurdle of making sure all of the component s worked off the breadboard so now the rest of mounting and integration should go smoothly.
Deliverables for next Week
The final presentation is the main deliverable for next week, but other than that I want to make sure that our system for mounting the microphone and providing some noise isolation works.
As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?
In this project, there are a couple main things that I have learned in order to complete this project. The first thing is the researching oof different components that work well in a distinct system without incorporating them onto my own PCB. This involved making sure that the PICO, Pi5, Mic board, LEDs and Receivers all worked together while having their own PCBs and communication protocols. This involved poring over the data sheets of these products as well as looking at the extensive documentation that exists for things like the Raspberry Pis. The other main tool and knowledge that I learned was 3D CAD design for 3D printing. While I have experience with CAD for PCBs and simple shaped, designing somethin to be 3D printed was not something I have done before. I mainly used tutorials, either on a website or video to do this but it also involved a lot of experimentation and trial and error on the program itself to find the workflow that worked best for me.
This week my main focus was mounting our system onto our printed glasses. I worked with Todd this week to move one set of hardware onto our printed glasses and testing its functionality. This involved attaching the LED, Receiver, LCD, and lens to the glasses as well as attaching and organizing all the respective wiring. We also attached and hooked up the Pico and the two arms of the glasses to the frame. Finally we confirmed that the system does work by testing it with our other half still on the breadboard, and we confirmed that our lens does allow for good readability of the screen.
Because of the limited flexibility of our glasses arms, we also decided to shift to a single handle attached to the frame for our second pair of glasses to allow for easier compatibility with multiple users at the final demo.
We are still on schedule.
Next week we intend to finish mounting the second half of the system onto the other pair of glasses, and we plan on continuing our tests for our use case and other requirements.
For this project I had to learn a lot of things related to working with the Raspberry Pi and Pico. This includes learning to interface with the GPIO pins and deciding how to transmit data over USB between the two components. This involved reading through a lot of documentation for different libraries to determine if they would meet our speed and accuracy requirements, as well as looking through forum posts to see other people’s feedbacks on libraries performances.
I also had to learn about serial communication and transmission protocols when I was designing that aspect of our system. To do this, I read through several sites and articles talking about IR communication in general and specific protocols like NEC to pick the best aspects to incorporate into our protocol.
What did you personally accomplish this week on the project?
I worked a lot on mounting and making the slide deck. I spent a few hours working on prepping slides for our final presentation and have mounted the first pair of glasses for our demo. With this, we also did much of the testing needed for our final presentation / report(s).
Is your progress on schedule or behind? If you are behind, what actions will be taken to catch up to the project schedule?
We are on schedule. All we need now is to finish up the final pair of glasses and do a tiny bit more testing.
What deliverables do you hope to complete in the next week?
Final project done. Both glasses.
As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?
In terms of technology tools, this was my first time using Rpi / Rpi Pico. To learn how to work with these I was able to use online resources and the Rpi documentation available online. This is a pretty good strategy for learning new technologies because there is often a lot of documentation available that is accurate and consistently formatted. I also had to learn a lot about data sending algorithms (NEC protocol and alternatives). To acquire this new knowledge, I found youtube videos quite helpful. The images in these videos were good at explaining single protocols. I also learned (or remembered from a while ago) how to read data sheets on specific circuit parts. To do this, I was able to look online for graphs or words I didnt understand and use this to figure out more complicated parts of the data sheets.
Personal Accomplishments this week
This week was spent in preparation for our interim demo of our project. For myself, this involved completing our initial CAD design and printing it to show to our professors and TAs. Other than that, we discussed possible improvements to the physical design and additions that may need to be made.
On Schedule?
We are very much on schedule and are ready to begin mounting the device to the 3D printed parts.
Next week deliverables
For next week, we want to have our device completely so that we can test our technology in our intended form factor. Also, if needed, make adjustments to the CAD and do additional prints.
The biggest risk to the project is still all of the logistics that come with mounting our system to the glasses. We need to ensure that everything is mounted securely while still keeping a minimal footprint with all of our wiring, and ensuring that our LCD will be readable. This risk is being managed mainly with our being ahead of schedule leaving us plenty of time to work out any difficulties that come with mounting. We are also continuing to keep in mind the suggestion of pivoting to a handheld system as a last resort.
No changes have been made to the design or our schedule.
Both our verification and validation will be described following, because our subsystems basically fully integrated and so all of our forms of testing will be collaborative within in the team in some way.
In terms of verification, the main metrics we need to test are end-to-end accuracy and latency, as well as connection angle and distance. Based on some initial testing, we don’t believe angle and distance will have a significant impact on accuracy and latency, it appears to be an all or nothing connection, so our tests for those will be separate.
For our accuracy and latency, we will be using around 5-10 spoken and computer generated passages of vary accents and speeds to measure both metrics. Each passage will be repeated around 3 times with averages of different wpm and overall averages taken for our reporting. During this, we will also perform stress tests involving disrupting the line of sight to ensure full functionality. These reported metrics will map directly back to the matching use case and design requirements.
For our angle and distance, we will be transmitting simpler passages compared to above to simply check for a connection. We will do this ranging from 3-15 ft and a 40 degree range and constructing a graph of where connection is possible. This will allow us to provide a visual representation of where our system is usable.
For validation we will be utilizing our friends and hopefully volunteers who are hard of hearing or deaf to provide feedback on the usability of our system. We will be creating a survey that captures our more qualitative requirements, such as how it feels to wear and how obstructive it is.