Team Status Report for Apr 27, 2024

  • What are the most significant risks that could jeopardize the success of theproject? How are these risks being managed? What contingency plans are ready?
    There are two significant risks: 1. The jamming of the slider is still an issue, this prevents the motor from identifying the exact position it is in at any given moment. We have already identified the issue, and although mitigation efforts were made (referring to Ziyu’s status report), this problem is still not solved 100%. 2. The actuation speed of the motor is still way behind our initial design requirement. Samay is working on improving the motor driver’s code to get smoother actuation, but this proved to be a difficult process. As of now, no better solutions can be given besides pouring more hours into it before the final demo.

 

  • Were any changes made to the existing design of the system?
    We made our final changes last week, and they are documented in last weekly report and this week’s final presentation. No further adjastaments were made this week.

 

  • Provide an updated schedule if changes have occurred.
    No schedule changes.

 

  • List all unit tests and overall system test carried out for experimentation of the system. List any findings and design changes made from your analysis of test results and other data obtained from the experimentation.

Software Unit testing:

  • Web App user-testing:
  • 1st iteration feedback: low usability due to txt.file support only
  • 2nd iteration feedback after change: 8.75/10 for usability and user-friendliness
  • Braille algorithm testing:
    • 100% accuracy on 100 randomly generated words (Grade 1 + Grade 2)

Due to the braille translation algorithm successfully fulfilling the user-case requirement right off the first iteration of the test, we did not have to change our backend software design. However, after the first iteration of user-testing on our web app, we got a low score of 6.5/10 on usability due to the fact that our website only accepted .txt files users and did not deal with the errors that were generated from corrupted txt files. Therefore, we fundamentally changed our web app design to take in direct user-inputs from the keyboard through a clean prompt window generated from our website and decided to display every word typed and successfully added to our braille pad database.

Hardware:

  • Unit: Average time per cell actuation: Uploaded final Arduino code, ran Python translation script for >15 characters, and recorded total time taken. Results: 0.73-0.82sThis finding has led me to try and optimize speed as we are aiming for 0.5s per cell. I have to try different motor operating modes and continue experimenting. We will also try to reduce jamming of pins by making them thicker, since the pins “lagging” causes the slider to click with friction and thus slow down.
  • System: Homing precision and reliability: Ran testing of the slider initiation sequence upon first starting our whole system. Expected a quick back-and-forth until the motor “found” home position to then start accurate positioning of braille cells. Results: failed to get repeated trial successes. The motor often failed to detect a jam and other times just did not respond. This must be immediately investigated and start fallback plan of a physical limit switch.

Team Status Report for Apr 20, 2024

What are the most significant risks that could jeopardize the success of theproject? How are these risks being managed? What contingency plans are ready?

The most significant risks right now include the jamming issue on the braille pad. Due to the flimsiness of the braille pins, there are cases where the braille pins are stuck while the slider slides to the correct position. To manage such failure, we are working on a reliable jamming solution where we used the builtin jam detection on the motor to actuate the slider back and forth around the target location in order to reach the target. We also faced various communication issues with wifi communication between the webapp and the arduino. To resolve this issue we are going back to our serial communication system that is more reliable and able to transfer data faster.

Were any changes made to the existing design of the system (requirements,block diagram, system spec, etc)? Why was this change necessary, what costsdoes the change incur, and how will these costs be mitigated going forward?

We decided to change the data input method on the web app from importing a txt file to manually typing the word on the web app. We decided to do so because a peer commented that txt file import reduces flexibility and requires the user to be well-knowledged in creating a txt file. This does not change the cost in anyway.

Provide an updated schedule if changes have occurred. 

No schedule changes since our last demo.

 

 

Team Status Report for March 23rd, 2024

What are the most significant risks that could jeopardize the success of theproject? How are these risks being managed? What contingency plans are ready?

One of the biggest risks as we get close to finalize the 3D printing is ways to prevent jams and smooth transition between different braille patterns. To mitigate these possibilities, we are experimenting with different sizes of braille fonts as Ziyu is testing with different dimensions of the braille caps and sliders on his 3D printer and to complement that, Samay is looking into more motors and ordered a variety of them with different stepping levels and ranges. In terms of the software, the testing has reached 100% with grade 2 braille and is ready to be implemented to the whole as soon as the hardware is finalized.

Were any changes made to the existing design of the system (requirements,block diagram, system spec, etc)? Why was this change necessary, what costsdoes the change incur, and how will these costs be mitigated going forward?

Even though we are switching through motors, the price changes were minimal and not causing any changes to our planned budget. The schedule remains the same from last week where we had made changes to expedite software testing and 3D printing process. We are sticking to this schedule and it is our current priority to have the braille actuators and 3D design run smoothly by the start of the next week  so we can put it together with the software.

Team Status Report for March 16th, 2024

What are the most significant risks that could jeopardize the success of theproject? How are these risks being managed? What contingency plans are ready?

Currently, the most significant risk is the mechanical functionality and reliability of our sliding actuator system. Specifically, as we finalize our CAD design this week and last, we need to add components to mitigate the slider slipping when users physically run their fingers over the braille pins. We are also ready to mitigate issues with the motor in incorrect positions with a homing sequence. We plan on having a physical button/sensor at the end of the linear gear such that our code will be able to simply direct the motor to spin in that direction until the sensor is activate, which can then a reference “home.” Finally, there were not many changes to the system except for a decision between two different motor models that were ordered.

Here is an updated schedule for our team, given that our progress was behind the previous iteration:

 

 

Team Status Report for March 9th, 2024

What are the most significant risks that could jeopardize the success of the project?

This remains the same as last week. As we carry out our fabrication test next week, we will have more detailed insights to this question.

Were any changes made to the existing design of the system?

Same as above.

A: Global Factors

The development of an open-source, DIY-able refreshable braille display represents a significant advancement in making reading and digital communication more accessible to visually impaired individuals globally. By prioritizing affordability and ease of construction, this project addresses a crucial gap in the market, where existing devices are often prohibitively expensive, thus limiting access for many around the world. This initiative not only empowers individuals with visual impairments by providing them with the tools to build their own reading devices but also fosters a sense of community and innovation through shared knowledge and resources.

B: Culture Factors

The integration of cultural factors is essential for ensuring its accessibility and usability across diverse communities. Through our open source software, user can easily import customized characters set and text2braille converter, allowing the access to braille education to a diverse community of the visually impaired population. Our project’s braille converter mechanism and translation software also utilizes the unified standard grade 2 braille structure, making sure all the blind communities are benefited. One of the goals of our product is to address the comparatively low literacy level among the blind population.  As our project attempts to bridge the gap in literacy level between those who are blind and those who are not by teaching braille through technology, it allows the blind community to have access to language as much as the others. To add on, it is to be noted that culture for the blind, especially those who are innately blind, is under represented due to their lack of access to written verbiage. By providing them a tool to develop their command of written language, it strengthens their cultural interactions and representations to the world.

C: Environmental Factors

The environmental impact of creating a DIY refreshable braille display is significantly mitigated by its open-source and locally producible design. This approach reduces the carbon footprint associated with manufacturing and global distribution of commercial devices, since materials can be sourced locally and devices are built on-demand, minimizing waste. Furthermore, this product will allow for users to input any text file and subsequently be able to read the braille translation, as compared to depending on physical, paper print. This will reduce the dependence on paper for the visually impaired population and further contribute to mitigating environmental waste.

A: Written by Ziyu

B: Written by Yujun

C: Written by Samay

Team Status Report for Feb 24th, 2024

What are the most significant risks that could jeopardize the success of the project?

Since we have switched to a slider based actuator, the biggest worries are 1. the durability of the actuator, which despite optimization in the design iteration, might still be limited by the nature of the slider mechanic. 2. How do we recover consistently from a slider jam?

How are these risks being managed? What contingency plans are ready?

For our existing slider actuator, we will rapidly iterate over the course of next two weeks to try out different motors, slider slope, material, lubricate method, form factor of actuator, sliding speed, etc., to try and find the best combination that can result in the fastest and most consistent actuation of the braille dot patterns. We are cautiously optimistic that this plan will work, but if not, we have back up plans where a group of push-pull solenoid will activate individual ball-pen-like latches.

Were any changes made to the existing design of the system? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

As reference in our design presentation slide, we significantly changed our block diagram to accommodate for the new actuator design. This change is motivated by our quest to find the cheapest and easiest way of actuate a large amount of bi-directional dots.

There are no scheduling changes. For an updated visualization of the actuator, please refer to Ziyu’s status report for this week.