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