Posted on

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.
Posted on

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.

 

 

Posted on

Team Status Report for April 6th, 2024

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?

Currently, on of the major risks still lies in mechanical integration of the braille cell and motor subsystems. We have begun designing the motor housing and accordingly adjusted the slider design as well after learning of new complications. We expect further minor bumps in the next week as we finalize printing and assembling the linear actuator to the motor. We plan to continue adapting to these potential physical issues.

As mentioned before, there was a slight modification in the motor location since we have decided to move the linear rack to the top of the slider due to concerns over extra load and jamming. There are very minimal extra costs involved in this modification.

The tests that we need to run as a team involve the integration and inter-functionality of the different subsystems. It also involves testing of physical design to fit all of our components. We need to validate that the translation program outputs the appropriate encodings, which need to be properly communicated over serial to our Arduino. We also need to measure any additional power consumption by the whole system, not just operating the motors from subsystem testing.

Posted on

Team Status Report for March 30st, 2024

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 most significant risk is on the integration between our slider actuator and Arduino controlled motors. Currently we do not know whether they will coordinate well, so test will be done next week. We already have a fall back plan, that is another type of off the shelf motor that comes with with linear gear. The motor is relatively slow compared to other solutions, but we know it can be easily used.

Were any changes made to the existing design of the system

Depending on the result of the hardware-software integration, we will decide whether to scale down the project or not next week.

No Schedule update at this time

Posted on

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.

Posted on

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:

 

 

Posted on

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

Posted on

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.

Posted on

Team Status Report for Feb 17th, 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 are the components we are able to find and afford in terms of size and power. Our main issue is the small spacing of each braille cell from each other. However, we have found at least two backup plans of actuators we can assemble ourselves in case the sliders don’t work.

• 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?

There were changes made to the block design and implementation approach as referenced above. We have shifted to a more elegant and simpler design approach which address our power and size concerns for now. The 3D printed sliders will have engravings that at different positions engage each unique combination of 3 pins per each braille column. This eliminates the need for small actuators for every single pins.

• Provide an updated schedule if changes have occurred

There have been no changes to the schedule so far, since we shifted and caught up this week. We will observe our progress this following week and adjust the schedule then, if necessary.

Posted on

Team Status Report for Feb 10th, 2024

As we are approaching the start of the designing phase of our project, we realized there are some significant risks to consider. To begin with, the minuscule gap between dots in a braille might pose some difficulties in designing the grid with the balls and require extremely high precisions when it comes to actuating them into readable brailles. As a counter measure we have a plan B being planned currently that deals with 3D printing the grid instead of looking for pre-existing hardware components.

In terms of the software aspect, it is to be noted that braille dictionary data requires a lot of memory due to the fact that the braille patterns are stored in matrix like data structure. Thus, we are planning to do the translation on the web application and then to transfer only the necessary data into the braille pad and find ways to store the data in binary structure instead of a matrix with 1’s representing the dots.

As we have not completely finalized on the components needed for the product, it is inevitable that we are prone to changes to the design. By next week we are to be fully decided on which hardware components to order as well as an analysis on the cost and scale of the order. Currently we have begun to list all the possible components that could be viable. We are going to have a finalized list by early next week and make orders by the end.  This is the initial schedule that we have proposed so far