Buzzy Brailler

This page discusses the possibility of creating an economical braille terminal, using a set of vibrating push buttons.

Background

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. This page, 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.

Note: 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.

Mapping

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
123456789_123456789_123456789_123456789_

77__33__22__11____________44__55__66__88

Example

Here is a Braille ASCII representation 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)

Conversion

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 script 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.

$ en_us_c8.rb
==  ,,  ==  ==     1 H    ,,  ==  ,,   ,,
,,  ,,  ,,  ==     2 e    ,,  ==  ,,   ,,
,,  ==  ==  ==     3 l    ,,  ,,  ,,   ,,
,,  ==  ==  ==     4 l    ,,  ,,  ,,   ,,
,,  ==  ,,  ==     5 o    ,,  ==  ,,   ,,
,,  ,,  ,,  ,,     6 ,    ,,  ,,  ==   ,,
,,  ,,  ,,  ,,     7      ,,  ,,  ,,   ,,
,,  ,,  ==  ,,     8 w    ==  ==  ==   ,,
,,  ==  ,,  ==     9 o    ,,  ==  ,,   ,,
,,  ==  ==  ==    10 r    ,,  ==  ,,   ,,
,,  ==  ==  ==    11 l    ,,  ,,  ,,   ,,
,,  ,,  ,,  ==    12 d    ==  ==  ,,   ,,
,,  ==  ==  ,,    13 !    ==  ,,  ==   ,,

Reproduction

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.

  • BrlAPI

    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

    "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.

Prototype

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). An AC 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 interface, 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!

Topic revision: r12 - 06 Jul 2016, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email