Team Status Report for 2/17/2024

The most significant risk right now is waiting for parts to arrive promptly as well as the potential risks of relying on Bluetooth for communication. We can’t do anything about the parts, so we will proceed by working on as many software components as possible. To mitigate the dependence on Bluetooth we bought an additional chip that allows for wifi connectivity which will serve as an alternative if Bluetooth doesn’t work out.

There were several changes to the requirements. In our design, we decided to use a laptop to handle the machine learning prediction and speaker output. We moved away from using a smaller computing unit because we believed that the main goal of our project should be on the wireless and doubly nature of our gloves. We also have decided to use the British sign language alphabet as our goal set. This is because it provides a standardized set of 26 double-handed gestures that can be used with each other. We also reduced accuracy goals to 85%. This is to reflect the increased complexity of the double-gloved design as well as past projects’ results (Gesture Glove achieved 75% real-time accuracy with a single glove). We also are looking into reducing latency requirements due to the potential slowdown caused by Bluetooth transmission. We haven’t nailed down an exact number right now but are doing research into it. No major cost updates as we order our initial parts.

We are on schedule. No major changes to schedule.

Part A (by Somya)

Our product will enhance the welfare and safety of the deaf community because of its usability quotient. By having a discrete pair of gloves that can translate sign language to speech, they will facilitate communication between the deaf and non-deaf population. As such, the product will minimize the need for separate structures to be established for deaf people so that they can go about their day-to-day tasks in a more convenient manner. The better the communication between the deaf and the non-deaf community is, the more integrated and less alienated the former population will be. In terms of safety, our product could be really useful for the deaf to communicate in an emergency situation that could arise in any location where there may not be anyone that understands sign language. In such situations, timely communication is of utmost importance, and our product will be designed with this use case in mind. 

Part B (by Ria) 

Our product will be impactful for the deaf community and potentially those who are hard of hearing. Current society is progressing towards providing various disabled communities with tools that they can use to seamlessly navigate daily life. Our goal is to extend this mission to users who speak sign language wanting to communicate with people who don’t. This is a step towards establishing better conversions between the deaf community and those who can hear. 

Not only does this product attempt to solve a complex problem, but it also raises awareness about the nuanced challenges that the deaf communities face every day. By learning more about their needs and struggles, we are aiming to spark conversations – pun intended – about how we can go even further. This product can be useful in education, video games, and even during emergency situations. We hope that this project adds a few cobblestones to the road being paved towards a more inclusive society. 

Part C (by Ricky)

Our product is not meant to be marketed as something to be developed for significant profit. I claim that there are not a lot of economic factors that concern us because our main purpose isn’t to make a product cheaper or easier to produce. We would urge potential investors against trying to profit from our product because it is meant to bridge the communication gap between deaf individuals and non-deaf individuals. Inevitably, there will be a cost associated with purchasing our product but we hope that it will remain limited to the cost of parts. Due to its lightweight design we hope that the distribution of the product will be relatively seamless and costless. Basically, our product is not intended to be profitable. Instead, it is meant to help a disadvantaged community.

Team Status Report for 2/10/2024

The major risk that we are facing right now is concerning quickly finalizing our design. Over the week, we hashed out exact details about what our product will look like including specific parts we are interested in ordering. This is a small risk because we are close to finalizing our design and intermediate prototypes. The risk will continue to be managed as we enter design week and 100% finalize design ideas and part ordering. There are minimal contingency plans as the plan is just to finalize our design. 

 

Instead of having the data processing unit be in a separate unit, we have decided to run our processing algorithms on a PC. The rationale behind this change is that having our device work in a self-contained manner (i.e. without the user needing to carry around their computer) is not a top priority of ours—our main goal is to show proof of concept of the gloves working. 

 

We also made some soft deadlines that we want to finalize by next week for the prototypes we have planned. Each prototype should be standalone and work, and each one builds on the last. Below are the details of each rapid prototype as well as when we anticipate finishing them.

 

  • RP 1 due March 20:
    • Phase1:
      • Create one glove, sensor detection is reliable, IMU data is gathered
      • Wired connection to laptop, data send directly to laptop where we can monitor sensor data
      • No speaker, no bluetooth
    • Phase 2:
      • Test Bluetooth capabilities and add battery, and create a glove that can transmit data through bluetooth
      • Maintain same performance as phase 1 glove if possible
    • Phase 3:
      • Train the ML model and finish the product 
      • Add speaker and haptic feedback
  • RP 2 due April 3:
    • Phase 1a:
      • Duplicate glove into second glove 
      • Figure out how to send both gloves information to laptop via bluetooth
    • Phase 1b:
      • Make PCB only if we are somewhat ahead of schedule
    • Phase 2:
      • More gathering of data and training
  • RP 3 due April 14:
    • Phase 1a:
      • Expand vocabulary
    • Phase 1b:
      • Experiment with making this a distributed system using some form of communication protocol (need to iron this out)