PRE2018 3 Group13: Difference between revisions
No edit summary |
No edit summary |
||
Line 99: | Line 99: | ||
<h4>State-of-the-Art literature study</h4> | <h4>State-of-the-Art literature study</h4> | ||
<p>We have a seperate page for the literature study, which can be found [[0LAUK0 PRE2018 3 Group 13 SotA Literature Study|here]]</p> |
Revision as of 17:37, 20 February 2019
Abstract
A robot which is able to read a book/form of text and is able to translate it into braille so that deaf-blind people can read it.
Problem statement
In this world, there is an estimate of around 356.000 deafblind people internationally. Only around 1% of all books are translated in braille which means that people who are deaf-blind have small amount of available reading material. Even the blind people will most often need to resort to audio books if they want to read a certain novel.
Objective
Make it possible for people whose only choice to read books is using braille to read books which are not translated in braille and give a choice to blind people who prefer to read in silence to do so.
Who are the users?
The users of our device will be people with visual and/or hearing impairments who know how to read braille. For the people with both visual and hearing impairments, they will use this product in order to read novels. For the people with just visual impairments, they will use the product incase they prefer to read in silence. Most visual impaired people have to resort to use audio books because of limited availability braille books.
What do they require?
A way to convert (digital) text to braille.
Solution:
Create a robot which is able to translate e-books into braille so that the users can read it. (with translate do not mean to write a new book with the translation but instead some other form of reusable interface.
Braille interface
Input
e-book / digital text
Output
physical braille letters
Prototype
Manual digital letter input for testing first, outputs a single braille letter. Multiple letter output can be considered afterwards.
Approach
If we build a prototype of the mechanical part: Firstly, we will research braille on which we can base our user requirements on. We then look for existing patents and their mechanics on a Braille output system and look for possible trade-offs. Once we have detailed insight on the possible solutions, we devise our own solution based on our design decisions that correspond to the user requirements. We make a concept to visualize our idea and eventually we will make a (physical) prototype that can be tested with our target users.
If we only focus on user-friendliness
Firstly, we will research braille on which we can base our user requirements on. We then look for the most user-friendly materials and user-interface so we can improve the user-friendliness of the machine.
Milestones
Have digital text be the input of a reusable interface where the text is converted to braille. The braille can be projected per word or group of words, depending on their length. Choose the research topic Summarize a State-of-the-Art by performing a literature study Find a contact person that fits our target user group to gather additional information regarding our case Create user requirements for the robot Validate the requirements with the contact person Design a concept build corresponding to the requirements Validate the concept with the contact person Build a prototype of our concept and test it with the contact person Produce a final presentation in which we discuss the process, design and prototype
Deliverables
Compact, user-friendly and cost-efficient physical braille interface. The Braille interface should accept digital text and convert it to several Braille characters at a time. User-friendliness consists of: Type of material to interact with Speed of the machine Possible physical interaction with buttons/triggers (functionality)
Possibly a working prototype of one or several letters, that can be reset and configures itself to a given input.
Who will do what
- Material choice
- Dennis
- User interface (layout, buttons etc.)
- Thomas
- Converting feedback of test person to useful information
- Luc
- Hardware internals stuff
- Luc
- Builder
- Simon
- Programmer if we build a 6-segment letter prototype
- Dirk
Planning
Week 1
- Making the Plan
Week 2
- Setting goals, working out the project plan
Week 3
- User requirement list
- Getting in touch with a Braille reader and validation UR list
Week 4
- Designing concept
Week 5
- Building concept
- Feedback session
Week 6
- Evaluating feedback, improving idea
- Build new prototype
Week 7
- Finalizing the prototype
State-of-the-Art literature study
We have a seperate page for the literature study, which can be found here