Description

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

Details

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.

WHAT THIS IS:

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

HOW IT WORKS:

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.

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.

LESSONS LEARNED, AND UNEXPECTED THINGS:

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.

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!

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.

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.

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

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.

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.

Enjoy this project?

Discussions

Become a member

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

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

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.