PRE2018 3 Group13: Difference between revisions

Revision as of 21:19, 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 2 (16 Dec - 22 Dec):

Task	Person responsible	Deadline	Remarks	Done
Creating planning	Everyone	14-02-2019
Researching different materials: Making a overview of different materials based on multiple aspects such as cost, smoothness, stretchability or other factors which could be important.	Dennis	20-02-2019		Needs to add the references and finish small parts. Will be done before the tutor meeting
Getting blind contacts, make appointment and creating a survey.	Luc	20-02-2019	Appointment date doesn’t have to be within the deadline	Didn’t create survey
Working out existing Braille mechanism solutions for six-dot cells and argue their (cost)effectiveness	Thomas	20-02-2019	Piezo-electro Electro-magnets Motor per pin
Creating system/process of taking .pdf text input and outputting Braille	Dirk	20-02-2019	Requires documentation First output to plain text and then to Braille
Look for possibilities of creating Windows program that outputs to Arduino	Simon	20-02-2019	Requires documentation on choices made
Discuss the survey contents	Everyone	20-02-2019		Content finished during meeting
Put the planning in the wiki	Simon	20-02-2019		Will do today

Week 3 (23 Dec - 29 Dec):

Task	Person responsible	Deadline	Remarks	done
Word context to Braille shortcuts recognition	Dirk	27-02-2019	Optimization of .pdf to Braille system
Finish survey layout and give it to our target group.	Luc	27-02-2019	Or interview them depending on the appointment
Define the user requirements based on the results of the survey.	Everyone	27-02-2019	First iteration of the user requirements
Defining the Braille mechanism	Luc	27-02-2019	Blueprint of how it should be constructed with calculations
Specifying the parts and create circuit diagram	Thomas	27-02-2019	Includes calculations electricity usage and resistors
Defining the output of Arduino to the Braille mechanism	Simon	27-02-2019	How to let the Arduino work correctly with the mechanism i.e. reversing polarity
Creating user interface concept with the current user requirements	Thomas	04-03-2019	This date may change depending on the user requirements
Choose and get the best material(s) and look into how to make a suitable dummy Braille.	Dennis	27-02-2019	Best materials will be based on the research and based of off multiple perspectives (such as cost, smoothness and stretchability)
Buying the components	Everyone	27-02-2019	Will be done during the meeting

Week 4 (29 Dec - 5 Jan):

Task	Person responsible	Deadline	Remarks	Done
Inquire users on the new user requirements and test the material usability	Luc	Depends on appointment date estimate: 06-03-2019	Second iteration of user requirements Let users touch materials to see preferences
Re-creating user interface concepts with new user requirements	Thomas	Depends on appointment date estimate: 06-03-2019
Testing the entire software with Arduino output	Simon & Dirk	06-02-2019
Creating different dummies to test usability without the material.	Dennis, Luc & Thomas	06-02-2019	The material should be able to be attachable to the dummy.

Week 5 (5 Jan - 13 Jan):

Task	Person responsible	Deadline	Remarks	done
Creating single cell prototype as a whole	Simon	13-02-2019	Finished software + Braille mechanism & Arduino
Test dummy and prototype with the users and note feedback	Luc	13-02-2019
Discuss feedback on prototype and dummy material	Everyone	13-02-2019
Change requirements/usability where needed	Thomas	13-02-2019	Iterative improvement process
Changing dummies based on the feedback	Dennis, Luc & Thomas	13-02-2019	Iterative improvement process

Week 6 (5 Jan - 13 Jan):

Task	Person responsible	Deadline	Remarks
Iterate prototype and dummy test with users and note the feedback	Luc	20-02-2019
Change requirements/usability where needed	Thomas	20-02-2019	Iterative improvement process
Discuss feedback from users	Everyone	20-02-2019
Changing dummies based on the feedback	Dennis, Luc & Thomas	20-02-2019	Iterative improvement process

Week 7 (5 Jan - 13 Jan):

Task	Person responsible	Deadline	Remarks
Finalize corresponding wiki sections	Everyone	27-02-2019
Create final presentation	Everyone	27-02-2019

State-of-the-Art literature study

We have a seperate page for the literature study, which can be found here

Braille mechanism

The idea of a mechanism that dynamically creates Braille output has been worked out in all kinds of ways by existing patents over the years. We will be discussing some of the more common mechanisms and eventually decide on the one that fits our scenario the most by looking at the trade-offs.

Piezo-electric actuators

Piezo-electric actuators for the use of Braille displays were introduced in 1979 and still mostly constitute the operating principle of commercially available Braille displays [1]. In order to get a complete view on the implementation of this actuating mechanism, we take the TactoBook [2] system which presents the use of piezo-electric ultrasonic actuation.

The dimensions they have taken for their Braille configuration is as follows: 2.54 mm spacing between pins 0.7 mm vertical strokes

Material study

For materials we’ll first look into materials which can act as a cover over the pins of the robot. For this to be possible, the material would need to be sufficiently elastic. With this approach we aim to provide a good user experience which might be hindered by the spaces and inconsistencies that a non-elastic braille display would provide. This inconsistencies might be created because of faults in the connection between the braille display and the pins or unintended deformation of the braille display. Based on the feedback we’ll receive from our interviews, we might look into the non-elastic materials. Materials For the materials regarding the display of the article, we’ve done some research as to which materials would be useable. Since the exact requirements of the materials are not yet calculated, the requirements will mostly based on estimates. The requirements of the materials are that they are sufficiently elastic, easily deformable, durable and have a low friction coefficient. We distinguish between the following material types: Metals, Polymers, ceramics and textiles.[1] For each of these material types we’ll discuss what they include exactly and if applicable which materials could be useable . Since both deformability,durability and friction coefficient are not easily specified, we’ll focus on the elasticity.

Metals

Metals refers to a group of materials that that consists of elements that readily forms positive ions and has metallic bonds. In general, metals conduct electricity and heat relatively well and are overall a popular material type to use. Depending on the type of metal, they could be easily deformable and in our situation durable. The main problem with metals regarding our robot is that in general their elasticity is low. This means that if the material is deformed too much, it will not revert back to its original form. We assume our design would need a decently high elasticity and for these reasons we’ll look into the metals with the highest elasticity. We found the following metals:

Chromoly steel with Cr <= 9%

Chromoly steel is an alloy including both chromium and molybdenum. Chromoly is often used when the strength of mild carbon steel is not enough. You often see this material used in things such as bicycle tubes, molds, pins and chain links. Cost: $0.06 – 0.15 / kg Elasticity: 29.7* 10^6- 30.9 * 10^6 psi [2]

Carbon steel

Carbon steels refers to a steel which contains carbon elements up to 2.1% of its weight. Carbon steel has many different uses based on the percentage of carbon. The higher the percentage of carbon, the stronger the material is. Because of this carbon steels has a range of uses from constructing small things such as fences to construction of buildings and bridges. Cost: $0.86 – 1.03 / kg [4] Elasticity: 29.3* 10^6- 29.5 * 10^6 psi [2]

Polymers

A polymer refers to a type of material in which the material is made from long chains of molecules which may have cross linking bonds affecting flexibility and stiffness. Polymers can be categorized in three different categories. The first category is thermoplastics. Thermoplastics refers to a polymer which can only be flexible or moldable above certain temperature. The thermoplastic with the lowest moldable temperature is 60 °C. Since the temperature is too high for long term exposure to the skin, we can conclude that there are no thermoplastics which can be used for our robot. The second category is thermosetting polymers. Thermosetting polymers refers to polymer which is irreversibly hardened. Once hardened the thermosetting polymers cannot be changed in form. For this reason thermosetting polymers are not usable for our robot. The third is elastomer. Elastomer refers to polymers that are capable of recovering their original shape after being stretched or deformed to great extents. This polymer type can be used in our design because of its high elasticity. A good choice for the material for our design would be a certain type or rubber. Rubber is an easily obtainable material and because of its general high elasticity, it could be used in our robot. The main problem with using rubber is that rubber generally has a high friction. When the user would use our robot to read over the letters, the high friction will most likely cause a bad experience for the user. This could be solved by applying a low friction rubber coating to the robot to reduce the friction coefficient. Cost: $ 3.46 / kg

Ceramics

Ceramics are solid materials which are composed of inorganic compounds of metal, non-metal and covalent bonds. Ceramics are hard materials which are known to have an even lower elasticity at room temperature than most metals. Because of this, we will assume for now all ceramics will be unusable for our robot.

Textiles

Textiles are any material ,which can be used to create fabrics , cloth or the resulting material. An example of textiles are cotton or wool. There exists multiple kinds of textiles in which each of them has his own characteristics. Depending on how the materials are created, textiles could be elastic and thus be used in our robot.

A good candidate for our robot is the textile wool. Wool is a fibre formed of sheep fur which is both elastic and durable. Since wool made up of multiple threads, there could be some hindrance when reading the braille points. This is because threads will have to be spun and thus will not be a perfectly flat layer. This will have to be tested with the users in order to verify the viability of this material.

Braille to Arduino

We're using an Arduino Uno with 6 outputs which represents a braille character. For testing purposes, we'll be using LEDs for these 6 outputs. Serial Monitor is used for input. Enter the numbers of the LEDs you want to enable (eg. 1256). After you press “send” on the interface or “enter” on your keyboard, the lights corresponding to the number input will light up. We've also added a button and by pressing it, you can reset all lights (the Braille output).

converting a pdf file to braille code

Using http://braillebug.afb.org/braille_deciphering.asp for general braille rules.

We can describe a 6-pin braille symbol by the position of the ‘active’ pins. In order from top to bottom and then left to right. We can represent this as a boolean vector or equivalent binary number. The symbol ‘a’ for example becomes 100000.

Conversion rules:

Each letter in the alphabet and some symbols are converted to the corresponding braille code. (using a table)
A capital letter is made by adding 000001 in front of the normal code.
A capitalised word is made by adding the 0000001 symbol twice before it. (what if the only non-capitalised symbols in a word are not letters?)
A number is made by placing 001111 in front of the symbols for the letters that correspond to the digits. For example a=1,b=2 so 12 = 001111 100000 110000
000011 must be placed between a number and a letter if the letter directly follows the number
Some groups of letters get contracted to a single symbol or multiple (but less) symbols. (using a table)

Currently we have written a program in java that accepts a pdf file and outputs a txt file with the text translated symbol by symbol to braille. The braille is encoded as described above.

TODO: Apply word context dependent rules including the number and letter prefixes. Add a way for the user to supply character translations so that things like language specific translation can be added when needed. Pass the translation to the arduino.