This page discusses the possibility of creating an economical braille terminal,
using a set of vibrating push buttons.
Gene Dronek recently suggested the idea of adding some sort of tactile output
(e.g., a buzzer) to a push button.
Fingertips can certainly be used for both sensing and action;
why not consider ways to take advantage of this?
Although I haven't been able to find any products of this sort,
manufacturing some doesn't seem all that challenging.
A variety of refreshable braille displays
are commercially available.
, for example, shows more than a dozen products.
Most of these displays incorporate a "chorded" set of push buttons for entering braille,
based on the interface pioneered by the Perkins Brailler
Typically, there are three or four buttons for each hand,
allowing a braille pattern to be encoded by pushing the appropriate set of buttons.
Additional buttons allow the thumbs and/or the heels of each hand
to perform ancillary actions.
If each of the chorded buttons were equipped with a buzzer (etc),
the user could rest her fingertips on the buttons and sense braille patterns
using the same fingers that she would normally use to encode them.
And, because no movement is needed, the reading speed might be higher
than the encoding speed.
The layout of the chorded buttons is closely related to that of the braille cell.
Starting with a six- or eight-dot cell, leave the top-most dots in place,
but rotate their associated columns up to create a pair of horizontal line segments.
Thus, the index fingers handle dots 1 and 4, etc.
Proof of Concept
Using existing technology (albeit in an unusual manner),
it should be possible to test the basic concept.
Let's say that we have a 40-character braille display.
Using two cells for each fingertip, plus two inactive cells for spacing,
would only require 32 (4*8) cells total.
Additional inactive cells would lie between the hands,
filling out the 40-cell line.
On an 8-key braille keyboard, the dot positions are mapped
from two columns of four dots each to a pair of four-key rows.
So, for example, the top-left dot position (1) is mapped
to the cell pair under the user's left index finger.
Here is a layout, showing the 40 cells on the display
and the way that we are using them to represent a single character.
For clarity, underscores (_) represent cells containing spaces:
1 2 3 4
Here is a Braille ASCII
of the string "HI!".
77______22__11___________55_____________ H (1-2-5-7)
________22_______________44_____________ i (2-4)
____33__22_______________44______66_____ ! (2-3-4-6)
To try out this idea, we need a way to convert text characters
into lines of this sort and stream them to a braille display.
I've already got a start on this: en_us_c8.rb is a Ruby
that turns ASCII text into a variation on the format shown above:
- a pair of commas (,,) represents a dot that is off
- a pair of equal signs (==) represents a dot that is on
- a pair of spaces ( ) is used to separate active cells
Having a blank, wide dividing column in the middle of the display
seems like a waste of perfectly fine space.
So, I added some information that might be useful.
The left-middle column contains the input line number, modulo 99;
this could be useful for navigation.
The right-middle column contains the current character,
as a single ASCII character / Braille cell.
== ,, == == 1 H ,, == ,, ,,
,, ,, ,, == 2 e ,, == ,, ,,
,, == == == 3 l ,, ,, ,, ,,
,, == == == 4 l ,, ,, ,, ,,
,, == ,, == 5 o ,, == ,, ,,
,, ,, ,, ,, 6 , ,, ,, == ,,
,, ,, ,, ,, 7 ,, ,, ,, ,,
,, ,, == ,, 8 w == == == ,,
,, == ,, == 9 o ,, == ,, ,,
,, == == == 10 r ,, == ,, ,,
,, == == == 11 l ,, ,, ,, ,,
,, ,, ,, == 12 d == == ,, ,,
,, == == ,, 13 ! == ,, == ,,
Now that we have converted the input text to lines of "expanded" Braille,
we need to stream it to Braille terminal at a controlled pace.
We have considered a variety of possible approaches; feel free to suggest others.
However, please note that our delivery vehicle of choice is a MacBook Air,
which somewhat constrains the possibilities.
Using this C-language API (based on BrlTTY), we could write a stand-alone program, in C, Elixir, Ruby, etc. A message-based API (using sockets?) also appears to be available, as well as adaptors for programming languages such as Python. For more information, see the BrlAPI Reference manual.
"BRLTTY is a background process (daemon) which provides access to the Linux/Unix console (when in text mode) for a blind person using a refreshable braille display. It drives the braille display and provides complete screen review functionality. ..."
Although BRLTTY wasn't designed to do what we want to do, it may be possible to convince it to do so.
Assuming that the proof of concept is successful,
we can move on to creating a simple hardware prototype.
One plausible implementation would use a piezoelectric speaker
for each button.
These speakers are typically constructed from a metal disc
and a smaller, piezoelectric disc.
Running a DC
voltage through the latter causes the speaker to bend
(raising or lowering its center, with respect to its edge).
voltage can thus cause the disc to vibrate.
Using an embedded processor such as an Arduino Pro Mini
it should be possible to accept a data stream on a USB
convert the text characters to braille patterns,
and vibrate the discs.
The discs might also be able to sense pressure,
either by measuring generated DC voltages
or by detecting changes in their reaction to an incoming AC signal.
The total parts cost for such a device could be under $20,
allowing a production version to be manufactured quite cheaply.
This wiki page is maintained by Rich Morin
an independent consultant specializing in software design, development, and documentation.
Please feel free to email
comments, inquiries, suggestions, etc!