A Long Distance Lamp (Version 01)

Brief

What I am intending to do and why.

Long distance relationships are tough. There are many technologies that help to alleviate some of the difficulties of distance, such as video calling, instant messaging, even connected devices that simulate physical touching. Yet long distances remain hard.

The solutions above all require an ‘active’ participation, each person must be engaged in the video call, or on the message thread, or with the physical device.

With this project I posit there is a space for more passive presence, a subtle “I’m here, but not active”. My partner and I enjoy simply reading in bed next to each other, each minding there own business but aware of and comfortable with the other’s presence.

The ideal end goal of this project is a pair of connected reading lights, with each light giving subtle and noninterruptive cues that the other lamp is present. I also intend to offer the possibility of subtle interaction, similar to a light brush of the arm or momentary eye contact.

Present State

This section covers the current state of the light fixture, without any value judgement on the implementation. For more detailed evaluation of the implementation, see the Evaluation section further down.

Within the timeframe of the class project for Light and Interactivity, my goal is to create a single light fixture that simulates one end of the pair. The light must fulfill two requirements:

1. Act as a useful (i.e. dimmable) reading light (task behaviour)
2. Gently notify the reader of presence of and interaction with the “other light” (indicator behaviour)

As of presentation day, the task behaviour is implemented, and the indicator behaviour is ready to be implemented.

For the task light, aside from a slight jitter in the fade the behaviour is complete.

The indication behaviour still requires work. Presently the indicator lights exist within the physical device, and the framework to control them exists within the code. The work required involves cuing the indication (i.e. simulating a touch on the ‘other end’), and coding the particular fade profile.

There is one single interaction that controls all aspects of the light: touch. This light is definitely a prototype and the process of creating it has raised some important questions about the design (which I will discuss in detail later). At present touching the fixture activates a fade in/out cycle, offering rudimentary control of brightness. My original intention was for that interaction to trigger an indication on the connected lamp as well.

Process

Design

The light is intended to have two core features: act as a useful reading light and as a noninvasive interface for two people to be present with each other without being actively engaged in an activity.

To satisfy the second part of that, I settled on ‘touch’ being the focus of my interface. The least interruptive/active control I could think of is a gentle press on the light anywhere on its surface. My hope is that the light requires the least amount of engagement/thought to control.

In terms of the ‘useful reading’ aspect, at home I have an Ikea strip light installed above my bed as a reading light. I did this quickly and out of necessity, and it works fine as a reading light. The main problem I have with it is that unless I’m sitting straight up in bed, the bright LEDs are in my vision creating distracting bright spots.

Given that, with my light I definitely wanted something that gives off enough light to read by, but that also is gently on the eyes. Tom suggested I play around with diffusion or bounce, which was a great starting point for my prototyping.

Rapid Prototype (Fabrication)

• 

• 

• 

Given the intention to control the light by gently pressing it anywhere, capacitive touch seemed the most obvious place to start. And given capacitive touch as a mechanic, the fixture needed to be predominantly continuous metal. From the start I had in mind a strip light of some sort, so I got some relatively cheap extruded aluminium bars and started playing around with shapes.

The core questions of my prototyping process were:

1. What shape should the bar be?
   • I experimented with elbow and C shaped bars in different configurations. More on this below
2. Will a 12V warm white LED strip work as the Task Light ?
3. Will an RGB neopixel strip work as an Indicator Light?
4. What diffusion material should I use?

What I found was:

1. At first (pictured above) I attempted a ‘zigzag’ arrangement, where the task light pointed away from the reader (into the wall) and the indicator light pointed toward the reader. I immediately discovered that regardless of diffusion material the NeoPixels became discreet, which I did not like the look of. In the end I settled for a T shape where both strips point towards the wall.
2. 12V is plenty bright, but it looks best if I double up the strip so that one points directly into the wall and one points perpendicular to it (Fig 01)
3. Yes, but as mentioned before it’s best to hide the individual pixels with more than just diffusion (Fig 02).
4. At first I used paper but it quickly became greasy and damaged. I experimented with some photography lightbox diffusion material (Fig 01/ Fig 03) which worked okay. In the end, since I’m pointing the lights at the wall anyway, even though the fabric diffusion isn’t perfect, it’s good enough. It helps that the fabric is designed to diffuse light with the least amount of radiance lost (specifically this loses 1.5 stops)

Rapid Prototype (Circuit)

The breadboarded circuit (partially seen in Fig 04 was, as usual, a mess of wires that came together by adding and testing without too much thinking. I tested three things individually and then together:

1. Capacitive touch (using the CapacitiveSensor library and circuit)
2. Addressable RGB LED strip control (using Adafruit’s NeoPixel library)
3. 12V LED strip control (using TIP120 and PWM)

There was a brief moment of panic when putting everything together. I discovered that the 12V LEDs caused a bit of interference with the capacitive touch, and at first that was a problem with the rudimentary example code I was using to test. Fortunately the solution was relatively simple, in that most of the noise could be filtered out, and the reading difference that human touch created was still high enough to reliably read as human touch.

In other words, the 12V strip did cause on average a higher reading on the capacitive sensor than with no 12V strip, but that reading could just become the new baseline against which to measure for human touch.

Here’s a diagram of the working circuit:

Rapid Prototype (Code)

As mentioned briefly above, a lot of my problems went away when I started using filters. Tom demoed the SimpleKalmanFilter library in class, which worked really well at smoothing out the incoming capacitor values.

The process for code was far more experimental and less directed than the fabrication and circuit, so instead of walking through the process I’ll point out some things I discovered/found interesting. For more detailed info on the code, the full commented code is on GitHub.

1. CapacitiveSensor. Early on I discovered the CapSense library really slows down the loop, especially when the sensor is being touched. This is because the process is physical: the Aduino is waiting to see how long it takes for voltage to change on the sensor. The library offers an adjustable sampling rate; more samples means slower execution but higher accuracy. Since I’m only interested in a threshold value, and I’m using a filter, I can set the sample rate very low to get back a little speed.
2. SimpleKalmanFilter. Mentioned above, this library filters out noise. I used it to filter the capacitive sensor readings. Since the filter is a mathematic process rather than a physical one, using few samples and then filtering is far more efficient than using many samples and not filtering.
3. DeltaTime. In retrospect there’s a much easier way to implement this, but I took this concept from game development and think the implementation is worth a mention. Since the CapSense library delays the loop by an undetermined amount of time, getting a fade that’s of a consistent time is a little more involved than the simplest fade implementation: using delay() and a fraction of the total fade time. What I do is keep track of the amount of time the previous cycle took to complete (by comparing its start and end millis(), and then use that value as a multiplier for the fade increment in the next loop. So, if the previous loop took a long time, the multiplier is high, and the increment is also high. Vice versa if the previous loop was quick, then the next increment is small. It’s a quick and easy way to keep fades proportional, and I was excited to successfully implement it! However in retrospect I realised you could do the same thing by just using millis() as your fade offset…

Putting it together (version 001)

Though the light is yet to be anything near a connected pair of devices, I figured I’d put it in a neat package to demonstrate (and use!) as a simple reading light. The following is a pictographic overview of that process.

Evaluation

Right now what I can confidently say I have is a reading light that is dimmable. The process of creating a finished working version has raised a few questions, however.

Is the current implementation the best dimming interaction for a reading light? The answer is probably not. I find it quite satisfying to hold the light and watch it fade, but if I was reading and trying to increase the brightness and it started decreasing first, I would likely become frustrated. This is an important consideration as the lights usability for reading in the next iteration.

Given that there’s only one possible interaction (touch the light), how am I going to separate ‘sending a message to the other’ with ‘changing my own’? Although I haven’t focussed on the connectivity, my assumption throughout has been it’s fine that a message is sent when you change your light. After all, isn’t the point that the other is present, each lamp occasionally (gently) reminds the other of its presence. However what I didn’t fully consider until later in the process was “what if I want to send a message, but I don’t want my current light level to change?”. I think that when I begin on version 002 (an actually connected version), I will have to separate the ‘change mine’ from the ‘ping theirs’ interaction. This is unfortunate because I do like the simplicity of 1 single interaction, but I imagine this is a case of for the best results I must kill my darlings.

I could consider this project a failure in that I have not got any connection whatsoever, and I have not even implemented a successful simulation of a connection.

I could also consider this project a success in that I have created a not-too-bad looking reading light (in my opinion) that solves my frustration with my current reading light (glare from the LEDs), and sets up the possibility for a connection to a pair.

Instead, I will consider this project a great technical and creative learning journey, a wonderful prompt to think about the nature of and opportunities for long distance relationships, and perhaps the first physical computing project I’ve ‘completed’ that is both stable and useful enough for me to take home and use for a long time.