PRE2018 3 Group13: Difference between revisions

From Control Systems Technology Group
Jump to navigation Jump to search
No edit summary
 
(145 intermediate revisions by 5 users not shown)
Line 1: Line 1:
<h4>Abstract</h4>
== Problem statement ==
<p>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.</p>
Globally, around 356.000 people are deafblind, which means they cannot hear nor see. The way to communicate with these people is with braille writing. Regarding leisure, obviously, there are a lot of restrictions. Take for example reading books. Only around 1% of all books has been translated to braille, which means that people who are deafblind have very limited reading material. People that are just blind often will revert to listening to audio books, because there are so little braille books.


<h4>Problem statement</h4>
=== Objective ===
<p>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.</p>
The objective for this project is to make it possible for people to read all books in braille writing, by making a real-time translator which converts digital files to tangible braille. This way, people whose only choice to read books is by using braille, can read any book they want to, without being limited to the small number of books that have been printed in braille writing.


<h4>Objective</h4>
=== Target group ===
<p>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.</p>
The group for which this project is relevant is deafblind people, as said. However, the people that will use the device that will be the solution to this problem will have to be able to read braille writing. However, this is not the only group at which the final product is aimed.


<h4>Who are the users?</h4>
Visually impaired people do not always enjoy listening to audio books. Perhaps the circumstances do not allow for listening to an audiobook, or reading braille is perceived to be more comfortable. These people are also an important target group which will be taken into account when designing a solution to the stated problem.
<p>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.</p>


<h4>What do they require?</h4>
== Abstract ==
<p>A way to convert (digital) text to braille.</p>
On this wiki page, the project of group 13 will be fully described and explained. As stated in the Problem Statement, this project has to be about robotics, while keeping in mind the USE aspects. In chapter 3, it is explained what goals are set and how these goals will be reached. A role division and a planning is made, so the process is structured and the work is divided properly.
<p>Solution:<br />
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.</p>


<p>Braille interface</p>
Chapter 4 will be about the user requirements. Of course, the users are a big part of the project and the user-friendliness will be one of the main points of focus. Thus, this chapter elaborates widely about different solutions to the posed problem, as well as researched the user experiences and preferences. This way, the user requirements can be set up to the user’s liking, so the end product will be as user-friendly as possible and therefore compliant with the USE aspects.


<p>Input<br />
In chapter 5, the end products of the project will be described. Since two final products were made, as well as a conceptual addition to the found solution, this chapter is divided in separate sections, each elaboration on the different end products and the tasks that came along with them, such as programming and modelling.
e-book / digital text</p>


<p>Output<br />
A project cannot be complete without recommendations on further improvements. In chapter 6, it is explained what can still be improved upon and which steps can be added to further improve the outcome of the project.
physical braille letters</p>


<p>Prototype<br />
(Finally, the group reflects on their own process and explains which parts of the project should have been done differently, what could have enhanced the group process and what other steps could have been taken to get to a better result.)
Manual digital letter input for testing first, outputs a single braille letter. Multiple letter output can be considered afterwards.</p>


<h4>Approach</h4>
 
<p>If we build a prototype of the mechanical part:
== Approach ==
<p>For the mechanical prototype:<br/>
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.
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.</p>
We make a concept to visualize our idea and eventually we will make a (physical) prototype that can be tested with our target users.</p>


<p>If we only focus on user-friendliness<br />
<p>For the user-friendliness:<br />
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.</p>
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.</p>


<h4>Milestones</h4>
=== Milestones ===
<p>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.
<p>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</p> length.
Choose the research topic
<ul>
Summarize a State-of-the-Art by performing a literature study
<li>Choose the research topic </li>
Find a contact person that fits our target user group to gather additional information regarding our case
<li>Summarize a State-of-the-Art by performing a literature study</li>
Create user requirements for the robot
<li>Find a contact person that fits our target user group to gather additional information <il>regarding our case</li>
Validate the requirements with the contact person  
<li>Create user requirements for the robot</li>
Design a concept build corresponding to the requirements
<li>Validate the requirements with the contact person </li>
Validate the concept with the contact person
<li>Design a concept build corresponding to the requirements</li>
Build a prototype of our concept and test it with the contact person
<li>Validate the concept with the contact person</li>
Produce a final presentation in which we discuss the process, design and prototype</p>
<li>Build a prototype of our concept and test it with the contact person</li>
<li>Produce a final presentation in which we discuss the process, design and prototype</li>
</ul>


<h4>Deliverables</h4>
=== Deliverables ===
<p>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.
<p>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:
User-friendliness consists of: </p>
Type of material to interact with
<ul>
Speed of the machine
<li>Type of material to interact with </li>
Possible physical interaction with buttons/triggers (functionality)</p>
<li>Speed of the machine </li>
 
<li>Possible physical interaction with buttons/triggers (functionality) </li>
</ul>
<p>Possibly a working prototype of one or several letters, that can be reset and configures itself to a given input.</p>
<p>Possibly a working prototype of one or several letters, that can be reset and configures itself to a given input.</p>


<h4>Who will do what</h4>
=== Role division ===
<ul>
<ul>
<li>Material choice <ul><li>Dennis</li></ul> </li>
<li>Material choice <ul><li>Dennis</li></ul> </li>
<li>User interface (layout, buttons etc.) <ul><li>Thomas</li></ul> </li>
<li>User interface and requirements <ul><li>Thomas</li></ul> </li>
<li>Converting feedback of test person to useful information <ul><li>Luc</li></ul> </li>
<li>Hardware modelling <ul><li>Luc</li></ul> </li>
<li>Hardware internals stuff <ul><li>Luc</li></ul> </li>
<li>Prototype builder <ul><li>Simon</li></ul> </li>
<li>Builder <ul><li>Simon</li></ul> </li>
<li>Programmer <ul><li>Dirk</li></ul> </li>
<li>Programmer if we build a 6-segment letter prototype <ul><li>Dirk</li></ul> </li>
</ul>
 
<h4>Planning</h4>
<h5>Week 1</h5>
<ul><li>Making the Plan</li>
</ul>
 
<h5>Week 2</h5>
<ul><li>Setting goals, working out the project plan</li>
</ul>
 
<h5>Week 3</h5>
<ul><li>User requirement list</li>
<li>Getting in touch with a Braille reader and validation UR list</li>
</ul>
 
<h5>Week 4</h5>
<ul><li>Designing concept</li>
</ul>
 
<h5>Week 5</h5>
<ul><li>Building concept</li>
<li>Feedback session</li>
</ul>
 
<h5>Week 6</h5>
<ul><li>Evaluating feedback, improving idea</li>
<li>Build new prototype</li>
</ul>
 
<h5>Week 7</h5>
<ul><li>Finalizing the prototype</li>
</ul>
</ul>


<h4>State-of-the-Art literature study</h4>
=== Planning ===
<p>We have a seperate page for the literature study, which can be found [[0LAUK0 PRE2018 3 Group 13 SotA Literature Study|here]]</p>
The planning of the project can be found [[0LAUK0 PRE2018 3 Group 13 Planning|here]].


<h4>Material study </h4>
== User requirements ==
<p>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.
We will need a way to convert (digital) text to braille and we can do it as follows: <br>


Materials
Create a robot which is able to translate e-books into braille so that the users can read it (with translate we do not mean to write a new book with the translation but instead some other form of reusable interface).
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.


In order to determine fitting user requirements, we have broken down our research into different sections in which we look at general literature studies, user focused research and materials for the braille interaction. From these sections we draw our overall user requirements, which can be found at: https://drive.google.com/open?id=1D0T3C2wYtNyWK7ZE4wtTIpXq9gRA280T4eBAQZk00WI


<h5>Metals </h5>
=== State-of-the-Art literature study ===
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:
We have a seperate page for the literature study which contains summaries of knowledge relevant to braille and its users. From systems, mechanisms to its perception and standards.
The page can be found [[0LAUK0 PRE2018 3 Group 13 SotA Literature Study|here]].


<h5>Chromoly steel with Cr  <= 9% </h5>
=== Material study ===
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[File:chromoly.png|right|]
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 elasticWith 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. Further in depth information can be found [[0LAUK0 PRE2018 3 Group 13 Material Study|here]].
Cost: $0.06 – 0.15 / kg
Elasticity: 29.7* 10^6- 30.9 * 10^6 psi [2]
<h5> Carbon steel </h5>
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]


=== User research ===
Besides the literature study, we would like more direct involvement from our target group as well. To involve them in the design and development process and in order to do so, we have attempted to contact several institutes and communities for blind people both through phone calls and online posts. Unfortunately, the amount of responses we got is low and we only managed to get a few of our survey filled in.
Therefore we have decided to look for existing surveys that relate to our users and questions. The results of all user surveys are on [[0LAUK0 PRE2018 3 Group 13 User Research|this]] page.


<h5>Polymers </h5>
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


<h5>Ceramics </h5>
== Final results ==
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.
In this chapter, the final results will be described, as well as the process of getting to these results.


=== Sentence (dummy) ===
We designed to demonstrate the look and scale of the braille surface, this involes 3d models and a somewhat simplified 3d printed product. More detail [[0LAUK0 PRE2018 3 Group 13 Dummy_sentence|here]].


<h5> Textiles </h5>
==== Casing (dummy)====
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.  
The second part of the dummy will be the casing. This casing refers to the outside of the dummy which is used to provide an estimate of the size of our robot and a base on which the other parts will be attached to. Since we focus more on the reading aspect, for the base a simple box would be sufficient. The dimensions of this box will most likely depend on the needed estimated space for the hardware and the size of the braille display. An important thing to take into consideration when creating the casing, will be to consider interaction between the braille display dummy and the casing itself. For example, in case you want to change the letters of braille on the display, the casing should allow for a display to be removed and reattached.
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. </p>


=== Letter (solenoids) ===
For the function prototype we have created one functional letter. This letter accept pdf intput and displays the text one by one letter controlled by a button. The letter is represented by solenoids and the software shows its workings on the connected computer. More details on the functioning and the creation process are  [[0LAUK0 PRE2018 3 Group 13 Letter_software|here]].


=== Concept interface ===
We have created a conceptual interface for how the product would look in reality, this mostly concerns where the buttons for refreshing and toggeling automatic refreshing have to be placed. More detail [[0LAUK0 PRE2018 3 Group 13 Concept_interface|here]].


== Further improvement and future work ==
We are happy about our one letter prototype but if our product was to be produced, the refreshable braille display would obviously contain more letters. This would be easily achievable with a larger budget, as it is basically creating multiple single letter displays and connecting them. As for functionality, it would mostly stay the same.


<h5>Sources </h5>
We would also change the size of our prototype. For our one-letter prototype we prioritized accessibility over compactness, since we had limited time and a limited budget. We chose to get the solenoids that we could easily acquire in a short period of time. There isn’t much choice for different sizes on the market. If our product were to go in production we would ideally be able to make (or have access to) custom sized (smaller) solenoids so we could fit everything in a much smaller case. Same goes for the batteries, we would use smaller lithium battery packs, as opposed to multiple AA batteries that take up lots of space. We would then incorporate our design idea for the casing into the product, with the letters and buttons positioned conveniently for the reader. We would add a “previous” button, to return to the previous line, and optionally a motion sensor for continuing to the next line.
<p>http://www.campaignforwool.org/about-wool/ </p>
<p>http://bieap.gov.in/Pdf/CGTPaperII.pdf </p>
<p>https://global.kyocera.com/fcworld/charact/strong/rigidity.html </p>
<p>https://www.engineeringtoolbox.com/ceramics-properties-d_1227.html </p>
<p>http://www.dynacer.com/properties/ </p>
<p>http://www.newworldencyclopedia.org/entry/Elastomer </p>
<p>https://www.britannica.com/science/elastomer</p>
<p>https://en.wikipedia.org/wiki/Thermosetting_polymer</p>
<p>[3]http://burncentrecare.co.uk/about_burned_skin.html https://www.orfit.com/faq/what-are-low-temperature-thermoplastic-materials-lttps/</p>
<p>https://en.wikipedia.org/wiki/Thermoplastic</p>
<p>[4]https://agmetalminer.com/metal-prices/carbon-steel/</p>
<p>https://www.onealsteel.com/carbon-and-alloy-steel.html</p>
<p>https://www.metalsupermarkets.com/what-is-chromoly/</p>
<p>[2]https://www.engineeringtoolbox.com/young-modulus-d_773.html</p>
<p>https://www.economicshelp.org/blog/301/concepts/understanding-elasticity/</p>
<p>[1]https://www.the-warren.org/ALevelRevision/engineering/Materialclasses.html</p>

Latest revision as of 23:59, 10 April 2019

Problem statement

Globally, around 356.000 people are deafblind, which means they cannot hear nor see. The way to communicate with these people is with braille writing. Regarding leisure, obviously, there are a lot of restrictions. Take for example reading books. Only around 1% of all books has been translated to braille, which means that people who are deafblind have very limited reading material. People that are just blind often will revert to listening to audio books, because there are so little braille books.

Objective

The objective for this project is to make it possible for people to read all books in braille writing, by making a real-time translator which converts digital files to tangible braille. This way, people whose only choice to read books is by using braille, can read any book they want to, without being limited to the small number of books that have been printed in braille writing.

Target group

The group for which this project is relevant is deafblind people, as said. However, the people that will use the device that will be the solution to this problem will have to be able to read braille writing. However, this is not the only group at which the final product is aimed.

Visually impaired people do not always enjoy listening to audio books. Perhaps the circumstances do not allow for listening to an audiobook, or reading braille is perceived to be more comfortable. These people are also an important target group which will be taken into account when designing a solution to the stated problem.

Abstract

On this wiki page, the project of group 13 will be fully described and explained. As stated in the Problem Statement, this project has to be about robotics, while keeping in mind the USE aspects. In chapter 3, it is explained what goals are set and how these goals will be reached. A role division and a planning is made, so the process is structured and the work is divided properly.

Chapter 4 will be about the user requirements. Of course, the users are a big part of the project and the user-friendliness will be one of the main points of focus. Thus, this chapter elaborates widely about different solutions to the posed problem, as well as researched the user experiences and preferences. This way, the user requirements can be set up to the user’s liking, so the end product will be as user-friendly as possible and therefore compliant with the USE aspects.

In chapter 5, the end products of the project will be described. Since two final products were made, as well as a conceptual addition to the found solution, this chapter is divided in separate sections, each elaboration on the different end products and the tasks that came along with them, such as programming and modelling.

A project cannot be complete without recommendations on further improvements. In chapter 6, it is explained what can still be improved upon and which steps can be added to further improve the outcome of the project.

(Finally, the group reflects on their own process and explains which parts of the project should have been done differently, what could have enhanced the group process and what other steps could have been taken to get to a better result.)


Approach

For the mechanical prototype:
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.

For the 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 <il>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.

Role division

  • Material choice
    • Dennis
  • User interface and requirements
    • Thomas
  • Hardware modelling
    • Luc
  • Prototype builder
    • Simon
  • Programmer
    • Dirk

Planning

The planning of the project can be found here.

User requirements

We will need a way to convert (digital) text to braille and we can do it as follows:

Create a robot which is able to translate e-books into braille so that the users can read it (with translate we do not mean to write a new book with the translation but instead some other form of reusable interface).

In order to determine fitting user requirements, we have broken down our research into different sections in which we look at general literature studies, user focused research and materials for the braille interaction. From these sections we draw our overall user requirements, which can be found at: https://drive.google.com/open?id=1D0T3C2wYtNyWK7ZE4wtTIpXq9gRA280T4eBAQZk00WI

State-of-the-Art literature study

We have a seperate page for the literature study which contains summaries of knowledge relevant to braille and its users. From systems, mechanisms to its perception and standards. The page can be found here.

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. Further in depth information can be found here.

User research

Besides the literature study, we would like more direct involvement from our target group as well. To involve them in the design and development process and in order to do so, we have attempted to contact several institutes and communities for blind people both through phone calls and online posts. Unfortunately, the amount of responses we got is low and we only managed to get a few of our survey filled in. Therefore we have decided to look for existing surveys that relate to our users and questions. The results of all user surveys are on this page.


Final results

In this chapter, the final results will be described, as well as the process of getting to these results.

Sentence (dummy)

We designed to demonstrate the look and scale of the braille surface, this involes 3d models and a somewhat simplified 3d printed product. More detail here.

Casing (dummy)

The second part of the dummy will be the casing. This casing refers to the outside of the dummy which is used to provide an estimate of the size of our robot and a base on which the other parts will be attached to. Since we focus more on the reading aspect, for the base a simple box would be sufficient. The dimensions of this box will most likely depend on the needed estimated space for the hardware and the size of the braille display. An important thing to take into consideration when creating the casing, will be to consider interaction between the braille display dummy and the casing itself. For example, in case you want to change the letters of braille on the display, the casing should allow for a display to be removed and reattached.

Letter (solenoids)

For the function prototype we have created one functional letter. This letter accept pdf intput and displays the text one by one letter controlled by a button. The letter is represented by solenoids and the software shows its workings on the connected computer. More details on the functioning and the creation process are here.

Concept interface

We have created a conceptual interface for how the product would look in reality, this mostly concerns where the buttons for refreshing and toggeling automatic refreshing have to be placed. More detail here.

Further improvement and future work

We are happy about our one letter prototype but if our product was to be produced, the refreshable braille display would obviously contain more letters. This would be easily achievable with a larger budget, as it is basically creating multiple single letter displays and connecting them. As for functionality, it would mostly stay the same.

We would also change the size of our prototype. For our one-letter prototype we prioritized accessibility over compactness, since we had limited time and a limited budget. We chose to get the solenoids that we could easily acquire in a short period of time. There isn’t much choice for different sizes on the market. If our product were to go in production we would ideally be able to make (or have access to) custom sized (smaller) solenoids so we could fit everything in a much smaller case. Same goes for the batteries, we would use smaller lithium battery packs, as opposed to multiple AA batteries that take up lots of space. We would then incorporate our design idea for the casing into the product, with the letters and buttons positioned conveniently for the reader. We would add a “previous” button, to return to the previous line, and optionally a motion sensor for continuing to the next line.