Category: Team Status Reports

Weekly Status Report Question (Team):

ABET #6 discusses develop and conduct appropriate experimentation, analyze and interpret data, and use engineering judgment to draw conclusions …
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.

Back-end Tests

• Uncontracted and contracted braille function test: Trying 100 randomly generated strings and comparing it with the output of Braille Blaster app (state of the art translation software)
  • Result: 100% accuracy
• Testing to see how many responses were in database according to https://progressivegrocer.com/100-iconic-brands-changed-grocery
  • Result: 97% hit rate, 100% relevancy
• Timing test to create the database:  converting it from a csv to the database multiple times and averaging that time as well
  • Result: 36.7 s
• Timing database lookup time
  • Result: .132 second
• Timing how long it took to query for each above test
  • Result 5.32 s
• Solenoid instruction testing:  creating a sample input with unique numbers instead of just 0s and 1s and compared it to the expected output.
• Based on the results of these tests, we determined that the database was the faster option for our product. In addition, we determined that our webscraping algorithm was satisfactory.

Front-end Tests

• User testing: ran user testing session with 4 users to test user satisfaction with front-end interface and embosser device on a satisfaction scale from one to ten
  • Questions asked?
    • How easy was it for you to navigate the web-app?
    • Based on your experience, how likely are you to continue using this web app for your needs?
    • Did you receive sufficient and timely feedback when you entered a product name or typed notes?
    • How satisfied are you with the overall usability and functionality of the web app?
    • How efficient was the search functionality in retrieving relevant instructions or information based on the product name you entered?
    • Based on your experience, how likely are you to continue using this web app for your needs?
    • How well did the web app handle errors, such as incorrect product names or failed searches?
    • How effective were the accessibility features (such as screen reader compatibility) in making the web app usable for you?
    • How clear and understandable were the instructions provided by the web app?
    • How easy was it for you to use the embossing device?
    • How effective were the tactile cues on the box (including surface textures and braille instructions)?
    • How would you rate the paper registration experience?
    • How would you rate the portability of the device (weight, size, etc.)?
  • Results: 4.55/5 user satisfaction
  • User feedback: different button names, placement of buttons

Hardware Tests

• Tested quality of embossed braille (size and location) by inputing random combinations of solenoids into arduino code
  • Design changes: downsized from 4 to 2 solenoids to gain more control over the tensioning of the paper and distances between the solenoids. Changed various spacing settings within the arduino code
  • Design changes: change in stepper motor driver to achieve better precision with the stepper motor
• Photo-resistor testing: Varied values given to the photo resistor to test light sensitivity for paper registration.
  • Design changes: swapped from a 10k to a 4.7 k resistor to get more dynamic range on the ldr when we closed the top of the embosser, added an LED to pair with the ldr because when the lid is closed there is virtually no light in the embosser

Integration Tests

• Tested communication between the RPi and Arduino using LEDs to represent solenoids: sent 30+ sample inputs to the RPi from the web-app and tested for accuracy in solenoid representation. Test results influenced how serial communication was set up in the Arduino code.
• Tested full pipeline on various notes input combinations such as “abcd”, “llll”, “dfdfdf” that have distinct braille shapes to test quality of output.

As a team, we focused on user testing, testing the accuracy and speed of our web app, and assembly of the embosser device. This includes debugging the stepper motor and arduino circuit, assembling the electrical and mechanical components of the board. We have also had a user testing session to test the quality of the braille, the embosser device, and the web app. Looking to next week, we are focusing on completing assembly of the device and working on our final presentations

Other notable team events include:

• PCB’s arriving and not working
• A4988 motor controller issues making it hard to control direction. switched to l298n and had no problem with stepper motor control
• Got necessary step measurements for printing braille
• Got feedback on both our physical device and software at the Library of Accesible Media for Pennsylvanian’s blind user focus group.
• Ran database tests

Explain how you have grown as a team, and detail some of the strategies you have used to establish goals and plan tasks so far this semester.

Throughout the semester, we have greatly improved our communication and collaboration as a team. At the beginning of the semester, we had difficulty agreeing on a project idea and communicating our thoughts. We were making slow progress and had difficulty moving forward on some aspects of our project early on. Over the course of the semester, we have greatly improved in our ability communicate our ideas and work together. Some strategies we employ as a team to ensure strong communication and collaboration between team members include frequent checkins, updates every day about progress and encouraging team member progress, and collaborating on problems across sub-systems. For example, everybody is involved in discussions about the optimal way to design the front end and discussions about design choices on the electromechanical embosser. We have weekly meetings every Friday to discuss weekly progress and goals for the next week. These meetings allow team members to understand what other team members have been working and help us understand what needs to be done for the next week. We also establish goals and plan tasks by considering what has been accomplished in a week and gauging what gaps still need to be filled, which in part is also guided by our Gantt chart. At this point in the semester, our goals are also guided by testing we have coming up. For example, we had a goal to have the front-end completed by this Tuesday for a demo. We have another goal of having the entire electromechanical embosser pipeline complete for an upcoming demo after Thanksgiving.

Some weekly progress updates from our team: Joshna and Zeynep went to the LAMP Library on Tuesday to perform some user testing on the UI, and Zeynep is currently working on integrating some of the feedback. Overall, the users were happy with our interface and were able to navigate it with ease. We have also been working on completing the mechanics of the device, which includes laser printing the box, establishing the tension system, and integrating the hardware and software. As of right now we have established the web-app to solenoid pipeline and are currently working on integrating the stepper motors.  In the upcoming weeks, our primary focus will be integrating all of the sub-systems and testing our embosser.

This week we focused on making sure our demo ran smoothly and began preparing for our user testing session next week. For the demo, we displayed a completed web-app integrated with the back-end and a working solenoid system with serial communication, which is how we will be communicating between hardware and software once we have integrated our system.

We are currently working on improving the front-end to ensure it is easy to use for completely blind users and clear for partially blind users. This process includes ensuring proper spacing between all of our buttons, testing our web-app’s features using text-to-speech to assess  the clarity of our buttons, ensuring large text, and limiting the amount of text on a page while making sure our users understand the flow of our site. We currently have it running on a phone using a local-host and are looking into hosting it publicly for our demo.

We successfully integrated our front-end and back-end components, and we are currently in the process of integrating our software with our hardware. We have completed writing the American English text to braille algorithms and have converted our braille representation in software to signals that can be sent to the solenoids to emboss onto paper.  We made slight modifications to the size of our solenoid encasing on our electromechanical embosser. This modification was to make the spacing between each solenoid 4 braille characters, which is a cleaner way to represent the braille in software. We also sent out our updated PCB to include our RPI->arduino modification. We are currently working on establishing communication between the RPI and the arduino and assembling the electromechanical embosser system.

This week, we primarily focused on preparing for our interim demo. Because focused on breadboarding the electrical subsystem for the stepper motor, Becky adjusted the design of the loading system, and had parts fabricated. We have decided to separate the software side from the hardware side, so the RPi handles the software and communicates with the arduino via uart, which handles the hardware. Zeynep focused on completing the front-end for the demo and assembling the solenoid circuit for demo and establishing the serial communication to send signals to the solenoids. She also fabricated the enclosures for the solenoids. Zeynep and Joshna are also working together to integrate front-end and back-end. Joshna worked on the database, integrating the front-end and back-end, and writing the translation function to translate from American English to braille to prepare for the demo. Some issues we ran into as a team is adjusting our design to now incorporate and arduino and RPi, and we received the incorrect linear rails for the gantry system.

This week, as a group, we primarily focused on planning our goals for the interim demo and engaging in discussions about the ethical concerns of our project. For our interim demo, our current stretch goals are to allow a user to input text into the notes feature of a finished web-app. We aim to display the braille translation and output these signals to our mechanical x/y system and our solenoid system. We will have these two systems decoupled for our demo and will work on integrating for our final product. For ethics we discussed, safety concerns of giving a blind user an electrical device and how it contributes to the welfare of our blind users.

As for the components of our project, this week we focused on our individual components. Zeynep worked on the front-end of the webapp, Becky finished the pcb and sent it out, and Joshna worked on setting up the rpi and the braille translation algorithm.

Overall, our design has had no major changes. We are currently working on integrating our back-end and front-end components building up the interm demo and are on track.

This week, our team primarily focused on submitting the design review document and refining our design following feedback from the design presentations. This included updating our number of solenoids from 2 to 4, accounting for tension needs of our braille embosser, and updating our back-end to ensure that it meets our user and design requirements. We also created many figures for our design document and spent most of the week writing our report. Due to fall-break, we did not accomplish too many team goals this week, but coming into next week, we are looking to finish PCB design, conduct user interviews of the web-app, and begin fabrication

Another change we made to our design was making the web-scraping off-line. We wanted our site to take about .5 s to display results. Doing the web-scraping online was taking far too long and no one on our team has the ML capabilities to speed up this process. As a result, we switched to having the web-scraping offline and incorporating the results into a database to preserve our required speed. The database will work through keyword look up and will run much faster than our initial web-scraping algorithm.

[BLOCK DIAGRAM FOR SOFTWARE UPDATE]

Some risks associated with this design change may be that the database could still be too slow. In this case, we will use a google search. In addition, instead of storing the text file of the web-scraping results directly on our site, we will be creating the database each time we run the code, which may make testing tedious. Another risk we have at the moment is whether our current 6 pin system will properly represent all the braille characters we need.   

This week, we worked on finalizing the design of the solenoid embosser, designing the x/y arm system to move the paper, setting up the web-app, and began working on the web-scraping algorithm.

These are the primary risks we identified for this week:

• The linear bearings of the x/y gantry must be manufactured to high spec. If they are not, this could impact the mechanical functioning of the braille embosser to not work as well.
  • Mitigation: Source parts carefully and make proper cost benefit analysis of cheaper parts.

• Downsized number of solenoids to a total of two solenoids. This change was made because after the number of solenoids passed 2 solenoids, the amount of time it took to emboss a single character begins to plateau. We chose 2 solenoids because it is most manageable without slowing down the overall system
• A large component of our design decisions was whether to couple or decouple the x/y gantry. We decided to decouple the gantry because it will be a simpler design overall, and will give us a bit more control and create a more stable system. Decoupling will reduce mechanical failure points and increases accuracy. It also appears to be cheaper than a non-decoupled system.
• We have also modified the webscraping methods. We will now only be webscraping from a select number of websites that already have products listed. This decision was made because of lack of supporting libraries in python.