The Louder Router – a low cost PC for the Blind

This post describes a project to build a very low cost PC for the blind using commodity router hardware. It has the potential to dramatically improve the lives of millions of blind people, especially in developing countries. We need some OpenWRT gurus and embedded hardware hackers to help this very worthwhile project!


A few months ago I attended BarCampAdelaide, down in the lovely sea-side suburb of Moana.

Moana beach

I was flicking through a pile of Make magazines that I think Kim Hawtin had brought along. Having never seen a Make magazine before it was a fascinating read – especially in the laid back, geeky atmosphere of a BarCamp.

I came across an article by the remarkable Fernando Botelho. Fernando has a dream – a $200 PC for the blind. Blind people currently need to pay close to $2000 to get a PC, speech synthesiser, and the commercial software they need to use a PC and connect to the Internet. So Fernando came up with the concept of a dedicated PC design just for the blind, that could be built for $200.

Light bulbs went on in my head. Hey – I know how to do this! So I contacted Fernando and with a small team we have been brainstorming this project and even prototyping some of the software on a WRT54GL router.

Blind PC Concept

This is the concept:

  1. There is a range of open source software for the blind, for example screen readers such as YASR, and extensions to emacs such as such as SpeechD-el and Emacspeak that provide a complete “Audio Desktop”. With these packages and a speech synthesiser a blind person can browse the web, use email, chat, and perform text editing.
  2. There are open speech synthesisers such as Festival and Flite that can be used instead of dedicated hardware synthesisers. Software synthesizers do not sound as pleasant as commercial hardware units however the price is right!
  3. Here is the cool bit. A PC for a blind person does not need a screen. Sounds obvious but this has several important implications. A screen is the most expensive part in any PC. No screen means no GUI, which is a major consumer of system resources such as memory, CPU cycles and dedicated hardware. No GUI means console-based applications – a perfect match for free and open source software. The low system requirements mean we can build a Blind PC for less than $50 using hardware similar to that in a commodity router, i.e. much cheaper than a conventional PC!

So the proposed PC will be a box like a small router or Ipod. It will have a headphone jack and possibly a speaker, and a socket for a full size keyboard. It will have a router-class CPU (say 200MHz), and possibly a wireless connection. We need plenty of flash (256 Mbytes minimum) to store the applications and data, but just a modest amount of RAM, say 16-32Mbytes. This sort of box could be mass produced for less than $50 using the same production lines as todays routers.

A Day in the Life of a Blind PC User

A blind person will be able to sit down at work and connect via the wireless or Ethernet. They can then answer email, use chat, and access the web. Imagine communicating with some one who owns one of these boxes. If your were chatting or emailing with them you would not know they are blind. In fact, I will guarantee they would outperform you in many tasks such as typing, memory, and comprehension of verbal information. This simple example shows how this device could make a blind person highly productive in an office environment. That means a job, and an income. All for just $50 and some open software.

When they leave work for the day they pick up their box and hop on the bus. While they are travelling they can play “audio books” or maybe listen to their email. When they get home they associate with their home wireless network and they can use the device to pay a few bills and catch up with friends on line.

A low cost PC for the blind can change the lives of many people. The $2,000 cost for the current solutions is simply impossible for blind children in developing countries. Worldwide there around 6 million blind children who will never be educated using todays expensive technology. A low cost blind PC will get them connected. Get them connected and they can communicate and be educated. They can raise their standard of living, have a great future, and the ability to earn a living.

Ported Software

To test the concept I have implemented chunks of the software on a WRT54G router using the OpenWRT kamikaze build environment. To get around the lack of audio I/O on a WRT I used various techniques to pipe the audio to my x86 laptop over a LAN. An alternative is to use a router with a USB port and a USB sound card.

Thank you very much to the OpenWRT community – I have had a lot of fun working with your software and found it well written and easy to use and modify.

Fortunately Flite (the Festival light speech synthesiser) was already supported. It runs at about 5 times real time on the WRT, which is fast enough for our needs. The speed of execution of Flite was a major concern as this is likely to be the most CPU cycle hungry part of the system.

We have ported (well partially ported) several new packages to OpenWRT:

  1. A full Emacs implementation. That’s right – full blown emacs operating on a WRT! You can even play tetris (M-x tetris) through a terminal! This was tricky to port – emacs uses a bootstrap method during the build procedure which doesn’t map well to a cross compilation environment. So at the moment I just run temacs, which takes a while to start as all the .el files need to be loaded. I also place temacs and the LISP files on a nfs drive, as the internal WRT flash is too small.
  2. Eflite. This is a middleware server that glues applications like Flite and EmacsSpeak together.
  3. Yasr (Yet another Screen Reader). This is a screen reader developed by Michael P. Gorse. It actually works quite well on the WRT. It also uses eflite to access the speech synthesiser. I actually cheated a little bit here and ran the eflite server on my desktop. This was because I couldn’t get the speech samples from eflite to net-cat over my LAN correctly, it worked out easier to run eflite on my PC. I feel comfortable with this hack, as I had already demonstrated eflite and Flite operating on the WRT OK, it’s more a configuration issue that I needed to work around.
  4. I attempted to get EmacsSpeak working on the WRT. The build process for emacspeak requires a bunch of LISP code to be compiled using emacs. Now this is fine when you are building Emacspeak on the same machine as where it will run. However in our case we need to build it on a PC and run on the WRT. So I need to work out a way to run part of the build process on the target WRT system. Tricky, but not impossible. I am sure with some help we can get EmacsSpeak running on the WRT.
  5. Speech-D-el

    Speech-D-el requires a server/middleware package called Speech Dispatcher. However I ran into a snag here – glib version 2 is required for Speech Dispatcher which hasn’t been ported to the WRT (at least not yet). Porting the actual speechd-el code looks straight forward.

    By using the trick of running the speech-dispatcher server on my laptop, I managed to get speechd-el running on the WRT. As explained above this gets us around porting a big library to the WRT (glib 2), which is OK for proving the concept.
    The current problem is that speechd-el runs slooooowly, you press a key and have to a few seconds for the speech. I am not exactly sure why but I have some ideas:

    1. The router processor might not be up to the job.
    2. I may not have built emacs correctly.
    3. I haven’t byte-compiled the speechd-el lisp code (it is suggested in the docs that I do).
    4. Perhaps the fact that I am running the speech dispatcher remotely, there some unwanted buffering going on. Or perhaps the use of NFS for the LISP files.
    5. Emacs by itself runs OK, I can type at normal speed, e.g. I can play games like the built in tetris OK.

    Curiously, Yasr was fast enough. So I guess the speed issue is probably a configuration problem, I can use emacs fine on my old 133MHz Pentium and this router has a faster processor. How much CPU can be involved in processing emacs code for one key stroke?

    Of course more testing is required, I have just typed a few things and not really explored the functionality of speechd-el yet.


    So we have demonstrated the viability of building a low cost Blind PC using commodity, router-class hardware. Several important packages have been partially ported and important functionality (Flite, emacs etc) has been demonstrated.

    Now we would like to open the project for community input. To progress the project further we would really appreciate some help from some people with skills in OpenWRT and embedded hardware.

    Development Plan

    We have three phases planned:

    In Phase 1 we would like to plug together a commodity router, USB sound card, USB memory stick, and a USB keyboard. This is the fastest path to getting a useful product deployed. OpenWRT configuration and software gurus are really need here. We have named this device the Louder Router.

    In Phase 2 we would like to develop a small USB or Ethernet peripheral (e.g. a dongle) that combines sound output, 256M of flash memory, and a keyboard interface. This would reduce the “number of boxes” required to build the system to just two (the router and the dongle). People experienced in microcontroller development would be very useful in this phase – I think a small PIC or Atmel would do the job.

    In Phase 3 we intend to develop a full-custom product and put it into mass production. This will be a neat single box solution at the lowest possible price. Given my experience with similar board-level designs on the Free Telephony Project I am sure such a box can be built for less that $50 in modest volume. Would any hardware/embedded linux people out there like to work on developing this hardware?

    Getting Involved

    We are adopting an open hardware and software approach. This technology can and should be free to all.

    The Blind PC project is hosted on the LouderLinux site (cool name I think). LouderLinux is a community supporting the development of assistive technologies for the blind.

    What we really need are OpenWRT, C, and hardware developers who can can help us integrate and develop the current prototype code into a Louder Router that is deployable to Beta users over the next few months.

    Please email Fernando Botelho for general enquiries and especially if you would like to help out. For technical questions, please contact David Rowe.


    Louder Router Blind PC Project

12 thoughts on “The Louder Router – a low cost PC for the Blind”

  1. You guys should do some market research in the blind community. I know that there are products out there that they are already using. The could probably be cheaper.

    I know a blind PC user. He’s a sysadmin for a successful ISP near me. He uses a little computer that connects to the keyboard and monitor output of an existing computer. It has a set of headphones and he listens to TTS at Warp factor 50. Its so fast that there is no way I could possibly understand it. He types at approximately a gagillion words per minute and is super at customer facing phone stuff, too. Quite a kick-ass admin.

  2. Thanks for your input Rich, market resaerch is an excellent suggestion. Could you please forward a link to this post to your friend and ask him to comment? I would really like to meet him.

    We do have blind people on our team who are aware of the current products, however more end-user input would be very welcome.

  3. Hi Kim,

    I have submitted a proposal on the embedded asterisk stuff, but not at this stage on this work.

    – David

  4. Almost 3 years after… and yours is the only “openwrt emacs” entry with some information. I would also like to have emacs in my OpenWRT and am wondering how you did it. Could you share your tricks? And by the way, an excellent idea you had!

  5. Hi Ruben,

    It’s been a while, but I remember some of the tricks. At the end of the emacs build process, emacs is used to compile itself to some sort of byte code which makes booting faster. This is tricky if you are cross compiling, as the x86 host can’t run the target system binary. So I skipped this step and ran the initial un-compiled binary (temacs) each time. I also put emacs on a NFS share to get around memory issues on my WRT.

    – David

Comments are closed.