Team Status Report for 10/7

This week we focused on finishing up the design presentation and began working on our design review report. We have been working on consolidating our documents, refining our requirements and testing plans, and will continue to work on it throughout the week.

Design Changes/Risks/Mitigation Plans

We conducted more user interviews this week, which impacted some parts of our software implementation. One suggestion was to include a dictation option for users who may not have a braille display. We are currently looking into implementing this option. Another topic that came up through our user interviews was contracted vs un-contracted braille. Un-contracted braille is a near one-to-one translation and is a very simple form of braille. Contracted braille is for more advanced readers. Braille readers read both contracted and uncontracted braille. We were initially only going to incorporate contracted braille. We are now looking into having both options available to users. We also learned that there are two braille codes: one that uses 8 pins and one that uses 6. 6 is the more common form of braille. However, we do not want to risk losing information if we don’t use 8 pins. We are currently doing more research into whether we will need to add the two extra pins. If we do make a switch from 6 to 8 pins, we will need to update our timing analysis. The design of the system itself, however, will remain unchanged.

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.   

Please enumerate one or more principles of engineering, science and mathematics that your team used to develop the the design solution for your project.

Two engineering principles we used to develop our design were testability and maintainability.

  • Testability
    • To ensure an easily testable design we focused on creating a very modular design from the electromechanical hardware component all the way to our software implementation. The electromechanical embossing system is made up of many individual components that can be tested on their own before we integrate the system together as a whole. For example, the solenoids act as their own system that are attached to the x/y gantry. The x-axis and y-axis components of the electromechanical printing system are also separate components that can be tested by themselves. The software has each component of our algorithm in separate components as well: the translation, web-scraping results, UI, output encoding can all be individually tested. Overall, we designed our system to be tested easily to ensure success of our project.
  • Maintainability
    • Our product is made for visually impaired users. It is often difficult for visually impaired users to be able to quickly fix something if one of their devices breaks. From one of our user interviews, we learned that every time a part breaks or there is a malfunction in a device, the user needs to go through the complicated process of sending the product out and waiting at least a couple of weeks to get it repaired. We wanted to design a device that would either be easy to repair or very strong against wear-and-tear. As a result, we chose cheaper and more maintainable parts–for example opting to laser-cut our enclosure rather than 3D printer. We also chose our parts specifically such that they were reliable against wear-and-tear.
    • On the software side, we are including both a database with recipes/product information in addition to a search option. The database with product options provides more ease of use to the user however does involve frequent updating from our end as there are endless products that could be put out on the market. The  database allows us to maintain updated information on products rather than having to constantly add more websites to an online web-scraping alogorthim.

Leave a Reply

Your email address will not be published. Required fields are marked *