Posted on

Yujun’s Status Report for Feb 17th, 2024

This week, I mainly worked on researching the hardware side of the project despite being in charge of the software due to the fact that the hardware implementation of the braille grid was more complex than we assumed.

We were behind the schedule in the beginning of the week, yet we caught up by having an extra meeting on Friday morning where we researched together and finalized our design. The only issue is that we  couldn’t order any components we thought of last week as our hardware design changed significantly.

The original design which used solenoids to push brailles turned out to be too costly in terms of power input. The amount of power it needed to hold all of the solenoids could also generate a lot of heat in the process. Thus, I presented an idea I found on the web which used a  a stepper motor which would slide a long block that contained all the braille push patterns on it.  Thus, we now only need two motors per braille cell.

In terms of the software, I pseudocode of the translation was made which takes a braille to alphabet data and translates each alphabet to 2 numbers. For each column, there are 6 braille patterns possible and for each one of them a number was assigned.

By next week, I need to finalize the translation part of the code which is only possible when we as a team finalize whether we are going to use a raspberry pi or an arduino based on the complexity of our implementation.

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

Posted on

Yujun Lee’s Status Report for Feb 10, 2024

This week I was able to talk to the CMU librarian about existing support for the visually impaired. Coupled with additional research done on the braille language, I was able to become familiar with the general structure and the standards for braille and also realized that our product is indeed needed for the blind population.

The progress of myself as well as the team is on track and to make sure we are on schedule in the future we are going to meet at least once outside of the class time provided to us every week. We also have been communicating regularly over slack and messages to ensure we are on track.

By next week I plan to have the braille database ready to use for the software, and find ways to encode the braille patterns into a matrix or find a more data-efficient way of storing the patterns to reduce memory usage.