Author: dzoota

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? 

Our most significant risks now come from debugging bidirectional communication. Our bi directional works well in a normal conversation flow, but if two people talk relatively slowly and overlapping, the system has trouble determining who to transmit and gets stuck. This risk is being managed by coming up with code debugging and testing strategies to try and determine what is specifically happening on the backend. We are also coming up with contingency plans to just hardcode a ‘priority’ that can guarantee only one person is sending/receiving. There are a few other contingency plans we have including using a reserved EOP character to signal a switch in priority. Other than that, our only other main thing left is mounting. We dont foresee this causing many risks however we could just end up with some messy wires. We will try to avoid this but also only have so much time to iterate our mount design.

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?

We have some small changes to our mounting plan. We now have a lens on one eye so that you can focus onto the screen. However, this lens is only on the bottom of the eye-hole so that you can still focus your eye on the background. This change was necessary as if your eyes are only looking through lens for too long then can become strained. There is not too much of a cost associated with this, aside from potential for eye straining which we mitigated by allowing you to focus on and off the lens. As mentioned earlier, no changes yet for bidirectional protocol but we are considering contingency changes.

Provide an updated schedule if changes have occurred

There are no changes to our schedule as we are all either on schedule or ahead.

We have some pictures and videos similar to last week but for 2-way communication. We will show them at demo if needed 🙂 (hopefully not )

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? At this point, the one main risk for our project success is the ability to get the NEC IR modulation scheme working on a pico. While seemingly (easily) possible as there are many videos and documents about how to do similar things, this is a very important part of our system. This risk is being managed by starting early and giving ourselves a lot of time in schedule + slack to work through any issues. Now that we have picked up the pico, we will be mainly focused on this portion of our system for a while. We have already drafted out code which seems plausible and are hoping that HW timed pwm + SW timed pulsing is accurate enough for our needs (which I think it probably is fingers crossed). If this absolutely cannot work, we can switch our transmission scheme timing requirements and make it a little slower (not terribly slow, just a bit slower) to get within the accuracy range for SW timing. This would hopefully make our system work.

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 changes were made to the design of the system this week. We are still working through implementing our change from last week (switching GPIO to a pico instead of directly on a Pi5). 

Provide an updated schedule if changes have occurred. No schedule updated. One might come in a week if we are having large pico difficulties.

A was written by David, B was written by Todd and C was written by DJ.

Part A: … with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc.

Deafness and hard of hearing are not disabilities constrained to the United States. In many regions of the world, these conditions can have even greater social and economic impact due to limited access to first world healthcare, disability services, hearing aids, or cochlear implants. In lower income countries, assistive technologies are often entirely unavailable, and public accommodations such as interpreters may not exist. As a result, accessibility needs for deaf and hard of hearing individuals vary significantly across countries and economic conditions. By enabling fully on-device speech-to-text processing without requiring cloud services / Wi-Fi connectivity, eyeR supports communication in environments with limited technological infrastructure. This makes the system relevant not only in technologically advanced regions, but also in underdeveloped, rural, or low infrastructure communities worldwide. Our design also reduces dependence on stable internet access, ensuring reliable functionality in areas where connectivity may be unstable or entirely unavailable.

In addition, technological literacy varies significantly across the world. Not all users are familiar with setting up software, working with the cloud, or troubleshooting devices. EyeR addresses this by prioritizing simplicity; the system is designed to function with no real setup, allowing users to simply wear the glasses and begin speaking (plug and play). The discreet glasses-based form factor integrates naturally into everyday life, making it socially acceptable across the globe. Furthermore, by relying on low-cost, widely available hardware and open-source software, the design is cheap and can be more easily distributed in reduced economic regions. Our approach ensures that eyeR is not limited to highly developed American markets, but instead remains accessible and scalable across a global population.

Part B: … with consideration of cultural factors. Cultural factors encompass the set of beliefs, moral values, traditions, language, and laws (or rules of behavior) held in common by a nation, a community, or other defined group of people.

Our device addresses the needs of the hearing impaired and hard of hearing community, and offers an alternative to bridge the gap between those who can hear and those who cannot. Sign language is not universal to the entire HoH community across many cultures and especially not within the hearing population. EyeR facilitates real-time, seamless communication that is accessible to all communities without severely altering modes of natural language. EyeR also facilitates eye contact and face-to-face communication, which is a universal mode of connection across cultures. In addition, with a transparent screen, natural conversational pacing and social interaction can be maintained without the use of a phone or other device.

EyeR is also designed with privacy in mind. Privacy is very important to many people and, across cultures and society at large, 1 on 1 conversations are meant to be private. By offering a mode of communication (infrared) that cannot be easily intercepted, eyeR allows privacy to be maintained. All data processing of the conversation, like the voice to text model, is done locally, with nothing stored in the cloud or put on the internet, keeping conversations private and secure between those that are communicating. This upholds the ethical standard of keeping conversations private when desired, and making sure that users feel safe to discuss personal and private matters without fear. This device offers a way for those in the HoH community to have an accessible and functional method that strengthens natural human interaction without totally replacing it.

Part C: … with consideration of environmental factors. Environmental factors are concerned with the environment as it relates to living organisms and natural resources.

Our first consideration with regards to environmental factors is that we don’t want our solution to require a lot of resources to make, or to be wasteful. This aligns well with our use case requirement that our solution should be lightweight and low profile as well as low cost. With our use of IR light for our serial communication, we’re able to keep the amount of hardware we need for our solution fairly minimal. In addition to this, we’re using industry standard LEDs and sensors similar to those used in TV remotes, so they have good longevity. Finally, with our use of a rechargeable battery pack to power our whole system, we will have no waste in terms of single use items like batteries.

Secondly, an important aspect of our solution is that it is meant for use outdoors for all types of social outings. Because of this, we need to consider how our technology could impact wildlife. The only disturbances that our technology would introduce to the environment is based on our IR serial communication. As we don’t anticipate our glasses being used in super close proximity to animals ( < 10 ft) the safety concerns associated with our users should be a nonissue in terms of wildlife. The main concern with the impact to wildlife would be the IR light itself, since some animals are able to see IR light we have to consider if our product would present any negative visual stimuli. In terms of the intensity of our IR light, it is less powerful than the ambient IR light due to the sunlight. We believe that it is unlikely that our 38kHz carrier frequency would make it discernable to animals in anyway, but either way our LED only has a range of 10-20 ft straight ahead and isn’t powered on unless the user is actively in conversation with another user, meaning there is for all purposes no impact on the wildlife.