Peril-Sensitive Sunglasses

A version of the Peril-Sensitive Sunglasses (as described by Douglas Adams in The Hitchhiker's Guide to the Galaxy)

Similar projects worth following
The Joo Janta 200 Super-Chromatic Peril Sensitive Sunglasses have lenses that turn completely opaque at the first hint of trouble, thus preventing the wearer from seeing anything that might alarm him or her.

I believe it should be possible to make a functional version inspired by the originals, as featured in Douglas Adams' work.

One of the characters in the books actually uses them in a practical way, believe it or not. As he's going up (or down, I forget) a very long and perilous ladder with a stunning view of tremendous heights, he uses the sunglasses to blissfully block out the alarming visuals - in essence, taking the common advice to "don't look down".

The Peril-Sensitive Sunglasses are the opposite of technology such as Monster Glasses.

Kimmy the Cat is also on the team. She communicates by eating treats. example:

She indicated that this project be started (I was against it.)

This entry is a general writeup along with post-prototype observations.

TO READ THE PROJECT PROGRESS FROM START TO FINISH (WITH PICTURES), CLICK HERE and start reading from the BOTTOM. This will let you read how the project came to life, the decisions taken, etc.


A set of glasses whose goal is to help keep you calm and mellow.  It does this with lenses that turn dark at the first sign of Peril (to prevent you from seeing anything upsetting.)

It consists of LCD shutter glasses controlled by a block of handheld electronics I decided to call the PPDD (Potential Peril Detector/Decider.)


It uses an Arduino (UNO at 5V in my case) with a variety of sensors to detect Peril by taking regular sensor readings and looking for anomalies - sudden changes in brightness, sound level, movement, etc.  This project log discusses early ideas on how to detect Peril, and this followup sums up the final design decisions.

The glasses are 3D shutter glasses (see the parts list) whose lenses can be turned dark by the Arduino.


Obviously detecting Actual Peril (AP) isn't really possible.  We use sensors to measure a variety of things (motion, light level, sound level, etc) and go from there.  Conceptually the sensors measure things that might indicate the presence of Peril - loud noises, sudden light level changes, things of that nature.

These are considered Possible Peril (PP).  The software simply considers all PP (possible peril) to be AP (actual peril) even though that's a pretty big stretch.  But it works well enough to be fun!



  • The Pulse Sensor Amped was a bust.
  • The GSR Sensor works but isn't as responsive as I hoped.
  • Taking readings from sensors is easy. Processing the data to find what you want is actually pretty tough.
  • The shutter glasses work well but wearing them looks turbo stupid.
  • The lenses don't really go opaque. They get dark (even very dark) but not opaque.
  • The AI Chatbot team member was devoutedly non-commital in all decision making.


  • The lenses of the glasses briefly going dark as feedback to the user is pretty cool and useful.  For example, I blink the lenses at startup as well as to indicate mode of operation (1 blink = GSR disabled, etc.)  It is unmistakable and silent and doesn't interfere with vision or need additional parts.  It's very good feedback.
  • I tried a test where I made the glasses "blink" every few seconds - like eyes.  You're talking to a person and the lenses blink dark randomly - it is sort of weird and kind of neat.
  • I also tried a "reverse strobe light" test, where the glasses stay dark and only blink clear briefly (so sort of a strobe light effect, but in reverse.)  It doesn't really work - probably because the lenses don't go fully opaque so you don't have the same effect that you do with a strobe light going off in a pitch black room.

View all 8 components

  • Video Demo!

    Minimum Effective Dose04/27/2014 at 08:07 0 comments

    That's a wrap!  We're done, so let's leave you with a brief video demo of the glasses reacting to sound and light.

  • Don't Miss the Project Writeup

    Minimum Effective Dose04/27/2014 at 06:11 0 comments

    This project details entry has some added information I wrote up after designing, building, and testing the prototype.

    If you're interested in details about what worked, what didn't, and what was unexpected, give it a look.

  • Signal Processing Fine-Tuning in Progress

    Minimum Effective Dose04/19/2014 at 06:07 1 comment

    No pictures this update - but some information on the process of making the whole thing work.

    As seen in the last update, the prototype hardware construction is complete.  All the solder-y and nuts & bolts-y parts are done.  What's left is figuring out what exactly to do with all the data we are getting from the sensors.

    This is easier said than done.  I can read the sensors just fine but deciding what to do with the data at a high level is a bit tricky.

    Testing reveals that my current methods are good enough to tell the sensors are working -- but not well enough to reliably isolate anomalies. False positives (detecting Peril where there is none) and false negatives (failing to detect Peril) abound.  I need to re-evaluate my software.

    It helps to define the problem.  Here is what we want:

    Ignore slow and steady changes, and take action only on anomalous signals.

    To do this we need to:

    • Read sensors regularly and keep a history; from that we can establish what "normal" is.
    • Figure out what "anomalous" readings actually means for each sensor. (This can be different per sensor - is slow but steady change upwards for the past two minutes anomalous for Ambient Temperature?  What about for Ambient Sound level or Ambient Light level?)
    • Constantly re-adjust for one, and watch out for the other.

    No matter what method or thresholds we use for sensors, the common thread is that we need to take and keep accurate measurements over time.  Only by comparing what's happening to what has already happened can we make judgments about normal vs anomalous.

    The existing software does this, but as stated - not well enough.  Some software work should sort this out.  I'm reminded of why Signals Processing is an entirely separate discipline, because it's easier said than done!

  • Handheld PPDD (Potential Peril Detector/Decider) done

    Minimum Effective Dose04/16/2014 at 19:55 0 comments

    It's said that the difference between a hack job and a professional-looking unit is measurement and planning. This is the first kind.

    The electronics are now all packaged up into a handheld unit, and verified working.

    This version is also a lot bigger than it needs to be, because when making just one of something and wiring up off-the-shelf things, size is never optimized.

    Ideally the PPDD would be worn against the skin like a necklace, and powered by a compact lithium-polymer cell, but that's wishlist stuff.  Functional prototype comes first.

    I used the Solarbotics S.A.F.E. acrylic enclosure, with a 4xAA battery holder "backpacked" onto it.

    The two copper pads for measuring Galvanic Skin Response are placed such that it's natural for fingertips to touch them.

    Sound Sensor mic is inside and the temperature sensor is just peeking out the enclosure.  There are a lot of "vent holes" in the enclosure so the sound sensor should be fine.

    Next is actual testing and fine-tuning sensor response!

  • Off the Breadboard - making the PPDD (Potential Peril Decider/Detector)

    Minimum Effective Dose04/15/2014 at 18:56 0 comments

    It's time to move the hardware off the breadboard and turn it into a functional prototype.

    Because we're making only the one to play with and there's no time to do things like a custom PCB, we're going to need to use a protoboard, have wires everywhere, and generally wind up with an end result that is much larger than it needs to be.  But it will work the way it is intended!

    All the electronics and sensors will be in a centralized control box, except for the ambient light sensor.  I am trimming some plastic from the glasses and fitting it into the glasses frame.

    Here is the light sensor peeking out from a hole in the top of the frame.  

    It makes sense that the ambient light sensor needs to be out in the open. (All other sensors can be squirreled away to some extent.)

    The glasses will be connected via an umbilical to the main control/sensor box - the PPDD (the Potential Peril Decider/Detector)

    Here is the prototype PPDD all wired up onto an Arduino shield protoboard.

    Some wiring and testing needs to be completed first.  Hopefully I haven't screwed anything up in the process of moving from breadboard to protoboard.

  • Sound Detector Evaluation (Success) - last sensor!

    Minimum Effective Dose04/13/2014 at 08:53 0 comments

    The last sensor to work in is the Sound Detector Board.  I am using the ENVELOPE output, which is an analog representation of the volume of detected sound.

    I haven't actually given it a proper run-through yet but I'm confident it will work just fine.

    The ADC reads about 20-30 in normal quiet workshop conditions.

    Clattering a tool near the sensor on the bench shoots it up to about 100+.  Loudly clattering the tool intentionally can easily spike 150+.

    I don't see any reason the same treatment for other sensors won't work - regularly read values into a ring buffer and calculate a dynamic threshold to use based on the standard deviation of readings.  Slower, more gradual changes will be ignored but sudden changes will trigger the Peril-detection part of the code.

    This is the last sensor to fiddle with; I think the sensor suite is complete now with:

    • GSR (Galvanic Skin Response) sensor
    • Sound Sensor
    • Ambient Light Sensor
    • Accelerometer (including freefall detection)

    Peril will detected either reactively or pre-emptively based on the readings from these sensors.

  • Light Sensor Evaluation (Success)

    Minimum Effective Dose04/13/2014 at 08:43 0 comments

    The tiny light sensor board gives some nice and stable analog readings based on amount of ambient light.  It gives a "0" well ahead of full darkness however.

    Software-wise I treat it almost identical to temperature sensor - read values into a circular buffer and calculate "standard deviation" of past readings, then compare that to the most recent reading.

    It responds quickly to light changes so I can use past readings to generate a dynamic threshold - too high of a change in light value either high up OR down triggers the Peril-sensing part of the code.

    It needed only a little extra tweaking - the math for generating dynamic thresholds, etc doesn't work well at very low values so if the readings are already very low (e.g. ADC reading is less than about 10) I just substitute some known static thresholds instead.

    I think I'll try to mount this sensor inside the glasses frame.

  • GSR Sensor Evaluation (Jury's still out)

    Minimum Effective Dose04/12/2014 at 08:57 0 comments

    I attempted to make a crude GSR sensor (Galvanic Skin Response) consisting mainly of a voltage divider, two copper plates, and an analog input.  

    I used this wiring (source: )

    I can certainly get results from it and at first glance the data looks useful, but it's unclear whether I'm reading what I think I am.  I can certainly tell whether there is skin contact, at least.  But beyond that it's inconclusive.

    I subjected myself to various stimuli (consciously calming my mind, consciously tensing up, jabbing my hand with a screwdriver, hyperventilating, looking at pictures of pretty girls, and things of that nature) with the contacts applied to my skin but was unable to find any useful patterns besides "skin contact yes/no".

    More testing and study is needed if time permits.

  • Temperature Sensor Integrating (Success)

    Minimum Effective Dose04/12/2014 at 07:50 0 comments

    Integrating the TMP36 temperature sensor was simple, I've used it before.  It looks like a transistor and outputs a voltage proportional to temperature.  Adafruit has a thorough guide on its use.

    Making the sensor work was easy.  Using the temperature data to make meaningful decisions about detecting Peril is less easy.  Certainly, at a high level I want to assume Peril is present whenever the temperature rises or drops too suddenly, but how do you go about doing that, exactly? What temperature, exactly, does Peril drop in at? 

    The devil is in the details, and when you are building something new it's all details.

    I did choose a hard high and low temperature to use as "hard" Peril indicators (to detect, say, being engulfed in flames or ice) but I still needed to decide how to detect sudden, abnormal shifts.

    I realized that a "sudden" shift in temperature is really a temperature change (up or down) that happens too quickly.  To measure temperature is easy - read the sensor.  But to decide whether the temperature change is too quick requires comparing temperature change X to an amount of time Y.

    Change over Time is textbook calculus something.  It might definitely be a derivative, or maybe an integral.  Either way I don't know a lick more about it than that so I settled for a software framework that measures temperature regularly and creates rolling averages at different times.  A change of temperature in excess of X in time period Y is considered Perilous.   (X and Y values are a little up in the air right now but I'm sure a little fiddling will reveal something useful.)

    That about wraps it up for the guts of the Temperature Sensor.

    (Monitoring body temperature was out since it would require inserting a temperature probe somewhere into the body, which I'm fairly certain would be considered Perilous by other sensors, and the sunglasses would simply wind up being a self-fulfilling prophecy and possibly a paradox of some kind and that just wouldn't do at all.  So the temperature sensor remains more or less aimed at 'ambient'.)

    TIP: For reasons that have to do with the output of the TMP36 sensor being high impedence, reading the sensor regularly and frequently and rapidly with the ADC can be glitchy.  A solution is twofold: 1) when you read the sensor, pause 10 milliseconds or so after each analogRead() of it, and 2) every time you want to read the sensor, read the sensor twice and throw away the first result.

  • Accelerometer Evaluation (Success)

    Minimum Effective Dose04/10/2014 at 16:24 0 comments

    Tested the Accelerometer for usefulness, and things look good!  

    A basic software framework is taking shape as well.  

    In this case, when too much movement at once (like a jerk or a jolt) in any direction is detected, the system considers that to be an indication of Peril.

    The Arduino calculates a rolling average of each sensor (in this case, each of the 3 axes of the accelerometer).  The rolled average is used as the basis to calculate a dynamic threshold.

    When the read value of any axis exceeds that axis' rolling average value by at least 50%, that is considered to be too jerky, too sudden, or otherwise abnormal.  The software then sets the Peril Detected flag.

    The Accelerometer is a 3-axis analog output unit from Modern Devices which I had on hand:  The jumper visible is a simple hardware method of adjusting the sensitivity (6g - installed, or 1.5g - not installed)

    This unit also provides a digital output if 0g (freefall) is detected.  This is automatically considered Perilous.

View all 18 project logs

  • 1
    Step 1

    Disassemble the LCD shutter glasses.  This will expose the electronics.

  • 2
    Step 2

    These contacts will control whether the LCDs are dark or clear.  5V through a small resistor (56 ohms or so) to the "+" marked pads will darken the lenses.  ("-" should be connected to GND.)

  • 3
    Step 3

    Accelerometer is wired like this:

    In my case I used:

    Analog 0 = X axis

    Analog 1 = Y axis

    Digital 2 = 0g Detected

View all 9 instructions

Enjoy this project?



x3n0x wrote 04/17/2014 at 04:26 point
Looks like fun! Too bad I cant bear to destroy one of those horribly expensive 3d glasses sets I bought for my HT setup. Wait! Ive got it! I have some LCD shutter glasses from a long time ago, from a funny 3d thing I tried in the late 90s that hooked on the parallel port.... Could work...

  Are you sure? yes | no

Minimum Effective Dose wrote 04/17/2014 at 05:08 point
Happily the glasses I purchased (PS3 3D Shutter Glasses) were 9.99 each - and the store had rows of them on the shelf. Right at my "sure why not" price threshold!

  Are you sure? yes | no

andyhull wrote 04/15/2014 at 20:18 point
"The Hitchhikers guide" is a little thin on explanations regarding the underlying technology used in the Joo Janta 200 Super-Chromatics, there might be some mileage perhaps sending someone or something (I'm thinking the peril equivalent of the babel fish here) ahead of the wearer, so that the reaction of this entity can be used to protect the wearer.

Maybe you should be measuring the skin response or pupil response (or sphincter response, perhaps.. but may be that's pushing the limit's of technology too far) of the wearer's body guard, this would afford better protection in the sense that the wearer is completely protected from reacting to the peril (until that is the ravenous bug bladder beast of traal has finished snacking on the body guard, and turns its attention to the cool dude in the shades of course).

  Are you sure? yes | no

andyhull wrote 04/12/2014 at 11:35 point
Is there an SI unit of peril, if not, I suspect we need to propose one, otherwise it is going to be difficult to calibrate your design.

  Are you sure? yes | no

Minimum Effective Dose wrote 04/15/2014 at 16:34 point
Very true. And we kind of limit ourselves to detecting PP (Possible Peril) in practice - making inferences about AP (Actual Peril) rather than detecting it directly.

As discussed in an early project log ( telepathic technology doesn't yet exist, so we have to settle in various ways.

  Are you sure? yes | no

Eric Evenchick wrote 04/10/2014 at 18:59 point
"PERIL DETEECTED" is quite possibly the best debug message I've ever seen.

Looking forward to seeing your results with the pulse sensors. Too bad the Pulse Sensor Amped didn't work out.

  Are you sure? yes | no

Minimum Effective Dose wrote 04/10/2014 at 19:32 point
It's a pity but oh well. (A colleague of mine also gave up on the Pulse Sensor Amped for another application but I guess I just had to see for myself.) I hope to be able to integrate measuring Galvanic Skin Response which might help cover that biofeedback-ish angle.

  Are you sure? yes | no

Eric Evenchick wrote 04/10/2014 at 19:38 point
Nice, I guess the next step up for pulse sensing would be quite a bit more expensive...

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates