In this post, I’ll discuss the design considerations and technical approach for a prototype device and submission for the New York City / Barcelona challenge Call for Innovation — Enhancing Mobility for Blind and Low Vision Pedestrians.
I worked with Thomas Logan (my brother-in-law; the founder of Equal Entry, an accessibility consulting company) to demonstrate that it is possible to build an Accessible Pedestrian Signal (“APS”; these are the beeping boxes you find at some crosswalks) with greater functionality than the current New York City implementation, for a fraction of the current cost. Our Open APS design uses public data, an open-source approach, and commodity consumer tools — we built our prototype using a Glowforge laser cutter and a Raspberry Pi.
Today, NYC spends an average of $43,060 per intersection for 8 APS devices (2 per corner). The installation costs are $985/pole; this implies that the remaining per-unit cost is $4465. By comparison, our cost of goods is just $66. By decreasing the per-intersection rollout costs by orders of magnitude, our hope is that the city can more quickly make streets safer for everyone.
In this post I’ll cover our proposal; design considerations for accessibility (low-vision, blind, color-blind, and deaf-blind people); tips for using a Glowforge laser cutter for accessibility prototyping; and attaching a Raspberry Pi.
Disclaimer: I’m a minor angel investor in Glowforge.
NYC has Accessible Pedestrian Signals (APS) at various intersections around the city. Here’s one:
There’s no doubt these signals help blind and low-vision people more safely cross intersections. While we applaud the city for installing these, we have two criticisms:
Thomas and I propose providing a free and open service for generating all the necessary asserts (signage, audio, software) to create an APS tailored to any particular crosswalk; hence the name “Open APS.” Hardware like a CNC milling machine can be used to create customized signs, and the software and audio would be included in a ready-to-use flash image for a Raspberry Pi (or any cheap computer).
To prove this, we built a working prototype using $66 of parts and a Glowforge laser cutter.
Prototype Open APS for the North-East corner of 7th Ave and W 23rd St, crossing W 23rd St.
We envision a workflow like:
The Open APS would need power (~3 Watts) and a hard-wired connection to the walk signal (to ensure safety, the actual signal light should be the source of truth). This device could operate in a reduced-functionality “orientation-only” mode if hard-wiring is unavailable or not necessary (e.g. in a park). Internet access is not needed.
The entire front of the signal box is a button that triggers audio when pressed.
Here’s an example of the long-press audio when the light is red.
Significant consideration is required for what, exactly, should be said and in what order. Our primary goal is safety, so we want to clearly disambiguate the cues for walk / don’t walk by using different word order:
Like existing APS devices, when the crosswalk is green our device will vibrate (for now, we use a piezo) and emit a “walk” beep tone. When the cross walk is not green, we will emit a “locator” sound instead.
Low-vision people may have trouble seeing the crosswalk light far way; and also, in New York City busses and trucks frequently block the signal. To help this problem, we also add bright “walk” and “don’t walk” LED lights to the top of our device. Note that the “walk” LED is not solid green to avoid red/green colorblind issues.
While it’s not directly an accessibility feature, we propose that we assign each device its own unique ID, with its own lookup URL. This URL is displayed as a QR code on top of the device, and is also broadcast as a BLE beacon (~2m/6ft range).
Top of device, with walk / don’t walk LEDs and etched QR code.
This has several potential benefits:
The entire prototype was built and assembled in my apartment in Brooklyn. The sign and and enclosure were designed in Inkscape and etched and cut using a Glowforge. Note that while the Glowforge was an awesome prototyping tool, it’s not what I’d recommend for the final Open APS devices; those will need weatherized enclosures and milled signs.
The sign on the front of the APS is etched into a 6" x 6" piece of black anodized aluminum. I glued on a white acrylic arrow, and also the braille which was etched into black acrylic (0.4" letters, on 5.3" x 0.66" piece).
The enclosure is a 6" x 6" x 2" black acrylic box.
The source graphic files look like:
Here’s a video of the Glowforge cutting the enclosure:
While the Glowforge is great for making high-quality Braille lettering in acrylic, there are a few considerations:
Here’s my process for making a Braille vector image in Inkscape. My goal is to produce a filled rectangle with circles cut out of it, so I can tell the Glowforge to engrave this as a single vector object where filled regions are removed and non-filled areas remain.
I printed this to the Glowforge using the deepest possible etch settings.
Inside the enclosure there’s a Raspberry Pi connected to USB-powered speakers, with GPIO pins attached to the push buttons and LEDs. For prototype purposes, we mocked-up the traffic light signal timing, but it would be straightforward to connect this to a wired signal.
The prototype software is very simple. We run stock Raspbian Stretch Lite, and fire up our Python script on boot. We have a JSON config file that drives all application behaviors; and a folder of audio assets (mp3 files). The only difference between each Open APS installation would be this config file and the audio files.
Audio is pre-generated using Google TTS, via the gTTS Python utility. We play sound using mpg123 (don’t use omxplayer; it cuts off the last half second of audio).
We set up a BLE Eddystone beacon following these simple instructions.
We submitted this proposal to the Call For Innovation Challenge on 11/1/17. If our proposal is accepted, we will work on several fronts:
Most of the time in this project went into iterating on the physical interaction model and design; the software and wiring was relatively straightforward by comparison. The design problems of deciding how much information to convey, and how, is made an order of magnitude more complicated when you consider different modalities and abilities. Thomas and I iterated on this many times until we settled on our prototype design. Having in-house maker tools like the Glowforge made this process much faster and more fun because we could keep trying various ideas while hanging out.
Many thanks to Chancey Fleet for her thoughts on existing APS solutions and areas for improvement; and to Karen Gourgey of PASS and the Baruch College Computer Center for Visually Impaired People for her consultation on pedestrian safety.