Posts Tagged ‘physical computing’

Scroll Roller – Verson 1.0

Friday, December 19th, 2008

I’ve been thinking a lot about the scroll roller over the past couple of days. Tims took it back to his place on the subway, and he tossed me an email saying that there were a lot of people who were very interested in it just from the way it looked, I thought that was really neat. With the show just occurring, I have also been giving a lot of thought to what it would take to make the scroll roller really ready for public demonstration. I’ll talk more about that later, but I figured it might help to talk about its current state first.

I’m going to include a bunch of pictures with explanations. These were all taken on the ITP light table. I have to say that a light table makes everything look better. I feel as if the scroll roller is far less impressive looking than these photos make it, but maybe that’s just over-exposure to the thing. Anyway, without further ado:

The scroll roller in its current incarnation is a very simple device: a potentiometer for control, run through a microcrontroller, which runs through an H-bridge to control a pair of DC motors which are connected to the axles the scroll is set on. Tiltng the lever hooked up to the potentiometer in one direction the scroll moves one way, and if you tilt the lever the other way the scroll moves the other way. The farther you tilt the lever the faster the scroll moves, so you can have both fine control and move quickly using a single input device.

This is what the scroll roller looks like before a scroll is hooked up to it

This is what the scroll roller looks like before a scroll is hooked up to it

Scrolls are (currently) mounted on specially prepared lengths of PVC pipe which have lugs attached to them that match up with the lugs on the axles connected to the motors. The axles are held in place by sliding latches, so all you have to do to get one is side the latch open and pop out the axle. Then you slide your scroll into place and lock the axle back down.

The scrolls simply slide onto the axles so removing and replacing them is easy

The scrolls simply slide onto the axles so removing and replacing them is easy

You get a device that looks, I happen to think, pretty good. Even in its current rough-prototype stage. Part of this is the way the light table makes things pretty, but it’s just a generally aesthetically pleasing object. I especially like the way that the roller seems to be a frame of sorts, accentuating rather than distracting from the scroll.

This is what the scroll roller looks like when everything's put together

This is what the scroll roller looks like when everything's put together

While this prototype has a number of problems on the technical end, I think they’re mostly materials-based. In fact, the core design seems very sound, hurt primarily by the fact that our motors suck. They were salvaged from a printer, and they just weren’t intended to exert significant force. They draw 100mA a pieace, which is enough to move a piece of paper, but not enough to pull a scroll very well. I mean, it moves, but really only at one speed: slow. This meas that the variable speed part of the design is pretty nonfunctional at the moment. Still, it does work, and I’m pretty happy with it as a proof of concept.

There’s a lot more work to do from here though. The obvious irst step s replacing the motor and gear assembly with one that can eet the physical demands of the device. I suspect that the next step will be the most technically difficult: running a barcode across the back of the scroll and rigging a scanning system on the device so that it can tell what section of the scroll is being displayed (actually we’ll probably need two readers, one at each end of the device, so that we can monitor the amount of tension on the scroll as well as allow for knowledge of display width if we have variable-width devices). Once that’s done a lot of new options open up: we can allow for “bookmarking” of sectionsof the scroll (local and possibly shared-across-the-net bookmarks), we can let the microcontroller automatically scroll through the scroll (either through specific scenes or simply throughout the entire length). Basically we can allow the scroll to become a traditional “hands-off” art object in addition to an interactive one. In addition to the additions in control hardware and software, there are some structural changes to make to te device. Three come to mind: first the light table made things look so much better that I figure that as long we have to power the device we might as well include a backlight, second we need to figure out how to handle wall-mounting the device as a means of display (this may mean lighter materials, but perhaps not), and third we need to figureout how we want to manage the input side of a much more complex device (go wireless with a remote control? eave it on the device directly even though it will take up more room and potentislly be more distracting?). Anyway, I’m still excited about the project and can’t wait to move forward.

Thomas

Almost done with the scroll roller

Thursday, December 4th, 2008

As of Wendesday night, the basic construction of the scroll roller is done.  We haven’t gotten a scroll in place to test it, but hopefully on Saturday we can get started with that.  The emergency stop mechanism was easy to design, and needs both testing and software implementation.  The latter’s just a few minutes of work, and the former is true of the rest of the system: testing required.

On the construction side, things are looking good.  Tims came up with a great way to secure things (small sliding latches) and it looks like with one small exception everything is in good working order.  That exception is, unfortunately, one of our gears.  The gear on our left-side axel has a couple of teeth which have been damaged.  I suspect this was caused by me while removing it from the printer.  It’s minor damage, and almost appears cosmetic, but it’s sufficient to cause the motor to jam when that part of the gear engages.  Tims managed to do some minor repair work, but I’m not sure how well it’ll hold up under strain.  The right-side assembly works fine, and we’re looking for a replacement gear, but if we can’t find one I think we’ll be okay.

Tims is working on getting us a scroll printed, and I’m trying to figure out precisely how we want to handle mounting of scrolls to the entire assembly.  I suspect it will be something involving PVC pipe.

After the eight or so hours of work on Wednesday I think we’re less than another eight from completion, so I feel quite confident about our schedule.  I suppose we won’t know for sure until we start testing and provide an opportunity for things  to go catastrophically wrong.  I’m sure there’ll be an update for that.

Thomas

Scroll Roller, the continuing story

Tuesday, December 2nd, 2008

Progress has been slow but steady on the scroll roller I’m working on with Tims for my final (as opposed to the cube).  Mostly things come in spurts.  But as of this evening I feel that we’re in good striking distance of done.

Over the weekend I learned some important lessons:

1. TIP120s are not very well labeled for BCE.
2. The cheap little potentiometers we got with our kits are… um… not rated for 1A of power.
2a. Trying to do this will break your potentiometer in bad ways.
2b. It turns out that it is possible to cause a potentiometer to flash-combust.  Sadly I have no documentation of this fact and am unwilling, at the moment, to demonstrate it again.
3. 20mA, despite my overly optimistic hopes, is not enough to spin a DC motor of any significant size.
4. A common ground works best if you connect ground to ground rather than 12V to 5V.
5. The junk bins in the shop are filled with some amazingly nice pieces of wood around finals time.
6. There are some engineering solutions which hot glue is not wholly adequate for.  It may end up being an integral part of the solution, but it is not sufficient on its own.

Here’s the basic state of things:

I have a pair of DC motors hooked up to TIP120 transistors which are controlled via Pulse Wave Modulation from an Arduino microcontroller.  Or, more simply, I have two motors which I can spin faster or slower depending on computer commands.  I have a potentiometer, which we’re going to try to build a spring-tensioned lever onto, that is used to control these motors.  When the potentiometer is centered, nothing happens.  As you turn it one way, the motor on that side spins faster and faster.  As you turn it the other way, the other motor spins.  From where I sit the software works great.  The only thing that I think might end up tweaked is that I might use some sort of logarithmic scaling function for speed adjustment instead of a linear one.

I have two paper rolling bars from an inkjet printer which have these extremely convenient gears at one end.  Gears which happen to have teeth which mesh with the gears on my motors.

At this point nothing is really put together, but Tims and I sat down and talked and once again I think he’s provided the solutions to most of our design problems.  The only one left of any significance is specific mounting of the paper rolling bars, and I think we’ve got a general solution there.

On the to-do list:

1. Show current work in class on Wednesday, solicit feedback regarding attachment options, bring up possibility of integrating Processing applet for digital scrolling.
2. Wednesday after class, finish physical mock-up.  Drill mount holes for, and actually mount, the motors.  Decide on working display area size.  Resolve bar mounting issues and figure out how to handle bar-scroll interface.
3. This weekend commence testing.  Problems are sure to arise, but if we’re lucky they’ll be small and manageable.
4. Obtain demo scroll.  I’m okay with demoing the entire thing with toilet paper, but I fear that a lot of the impact will be lost.
5. Clean up wiring.  This is purely optional, but I’d love to see the entire thing on a simple six wire ribbon cable.
6. Start looking ahead for this project.  Ability to identify the part that is being examined?  Memory?  Integrated controls between screen and physical display?

Let’s get cracking.

Thomas

New plan for the final

Monday, November 17th, 2008

It strikes me as somewhat ironic in light of my firm and detailed plans for the final that I’m going to end up doing something completely different.

I suppose it’s not that big of a surprise since I made no secret of the fact that I’d rather work on something with someone than do something on my own, and when Tims explained his plans to try building an automatic scroll roller I was interested. It probably helped that we’d had dinner the night before and had a long discussion about art and meaning and collaboration, but the project is an interesting one in its own right.

I was unfortunately out of town for most of the week (left Wednesday after class, just got back at 2am), but we had a very productive post-class lunch meeting before I left. I still need to touch base with him, but we’ve laid out a sort of rough plan for development, and I’m pretty excited about that.

Hopefully we’ll have some data by Wednesday about paper stress in different situations that we can use to actually design the device. (Tims had the clever idea of using toilet paper for testing. It is already on a roll and it is extremely fragile, which means that it’s easy to tell if the paper is under significant stress.)

Thomas

Planning for the final

Monday, November 3rd, 2008

Having found the dancing cube project to be surprisingly compelling, I’ve decided to use it as the basis for my final. This will entail a number of feature sets rolledout in series.

1. Reconstruction of the servo assembly. This will involve the replacement of the burned out servo motor, some shifting of the linear gear assembly to increase the range of vertical motion, and potentially a redesign of the cube’s skeletal structure for greater stability.

2. Migrating the mic control code to the servo control board. This may involve a general rewrite of the mic code, we’ll see. The ultimate goal is to get the entire thing running on a single micro-controller and to debug the audio interpretation code to properly configure itself for ambient sound levels.

3. Introducing a better on switch. This actually ends up being rather complicated since I want to do this with a cuprox switch. I anticipate using a solenoid motor to flip a bigger physical switch. This is actually a pretty complex change since it involves playing with cuprox and solenoid as well as completey redesigning the power system (so that it isn’t all regulated by the microcontroller) and working up some shutdown code so that when the cube turns off it reaches its idle state instead of simply dying.

4. Switchable face-plates. Time permitting, I want set things up so that the cube has swappable face plates. Plates have different faces on them, and correspondingly different dance patterns stored on EPROM chips plugged into them. This will involve another re-write of the code to load patterns strictly from EPROM, as well as figuring out how to work with EPROM and integrating some sort of system to detect if a faceplate is plugged in. If it isn’t, the system needs to fail to start or go to idle and shutdown (if the faceplate is pulled while the system is already under power).

5. Potential redesign of the cube base. Again, time permitting, I think I want to take advantage of the increased range of vertical motion to increase the size of the cube’s base, the part that does not move. The orignal deign called for it to be about four times its current height, and while I don’t know if I’d want to go quite that big, I certainly feel like the base should be more pronounced. Additionally, a larger base should permit all of the control and power systems to be built into it in order to keep them hidden from view.

If all goes well, I can accomplish one of these per week. Steps 4 and 5 are optional, allowing me some wiggle room if something goes terribly wrong. Additionally, steps 1 and 2 can be done with parts on hand, meaning I can get to work immediately and allow plenty of time for the parts I need to be ordered.

In theory this will allow me to have a pretty cool little dancing cube by the end of the semester.

Thomas

Lazy Sunday

Wednesday, October 29th, 2008

This past Sunday I did something that I haven’t had time for since I moved in in August. I sat down and watched DVD commentries and featurettes. Being a huge media junky, my DVD collection, even in its currently-abbreviated state, is significant. Generally I will have seen a film at least twice within a week of obtaining it, but then I tend to take a break. If they are short or limited, I will often also watch the special features during one of the viewings. However, and to my delight, many DVDs come with commentary audio tracks these days. Often more than one. Since my time is limited, I generally put off viewing these until a later date.

I tend to try to block out a day or weekend and watch a large number of films with commentary on at one time. It often turns out that the commentary is worth the price of the DVD all by itself. You learn so much about the film-making process generally, and the construction of the film viewed in particular, that the entire package becomes that much more enjoyable. Among the stack I worked my way through this weekend was the brilliantOnce UponA Time in Mexico. Rodriguez’s commentary hed some fascinating light on the process of filming this story, but what I found most fascinating was hearing an explanation of the impact of HD filming, something I m too young to really remember the transition to, on the film-making process.

Being the age I am, and having gotten interestedin film when I did, I never really had a strong understanding of the conservatism that physical film tended to impose. My mindset is that of someone used to informational abundance. I think in terms of storage so cheap it might as well be free. Computer hard drives are almost down to $0.10/GB as I write this, for instance.

While there are a number of places where I am fully aware of the implications of the shift from scarcity to abundance, I found it to be an extremely useful thing to be reminded that the fields that use information are more varied than I tend to realize. This got me thinking about just how many fields have been using information which I should try to get a better understanding of in order to fully appreciate the shift to virtually-free information storage. So I compiled this little non-exhaustive list.

  • Media distribution (music, telelvision, film) – in the face of virtually-free storage, especially as capacities continue rising, the artificial limits on offering size disappear. For years the amount of stuff a “movie” or a “CD” contained was capped at the size limit, and generally approached that limit. I suspect there are some interesting changes in the way this is approached as data storage becomes so large that virtually no one has the content to fill it.
  • Personal libraries – In a number of ways, personal libraries are a sort of two-level luxury. You must be able to afford the media that populates them, but you must also have access to available physical space to store them in. This second requirement is beginning to disappear (allowing, for instance, me to keep an extensive library in a 10′x10′ bedroom).
  • Versioning – The current trend is that you purchase the final version of anything. Storage capacities are growing large enough that it’s possible to purchase all versions of a thing. It’ll be interesting to see if anyone does anything with that.

Of course the problem with generating these sorts of lists is that it requires me to know enough about a thing to recognize some of the impact that virtually free storage will have. You’ll notice that my list is populated by media concerns, and that makes sense because I’m a huge media junkie. Media is always on my mind. It is for the very same reasons that the revelation about film never occurred to me. Further, without someone pointing it out, the film revelation never would have occurred to me. I didn’t start working with film until after things went digital. By the time I got involved, the tyranny of the cost of film had fallen by the wayside. Filming had become free in terms of supplies, assuming you had the capital and the manpower. So now I need to start poking around and see who I should meet and get to know. I’m sure there are tons of people out there who have extensive experience in fields which are and will be revolutionized. I just need to meet them.

A project, perhaps, for another day.

Thomas

The digital Etch-a-sketch demo and guts

Wednesday, October 15th, 2008

I talked about the high-level stuff behind the digital etch-a-sketch earlier this week. Here’s a demo and then a breakdown to look at the guts of the thing.

First of all, here’s the very simple one-minute demo. It is… exciting.

Holding the camera with one hand meant that I couldn’t demonstrate the way that the program mirrors a real etch-a-sketch’s diagonal lines as pixelated. That part was cool.

Anyway, let’s break this down. Step one was mounting my two control potentiometers to a fixed surface so that they could be turned without needing to be held down. I snagged some crappy stuff out of the scrap box and drilled some holes. Then, using some nuts and washers, secured my potentiometers through the holes.

Mounted potentiometers

Mounted potentiometers

I had previously attached headers to these potentiometers, so it was pretty easy to simply plug them into the bread-board. Ditto for my accelerometer. The vast majority of this project was in software, so the circuit is super-simple.

Basic circuit

Basic circuit

With that done, all that was left on the hardware side was to wire it to my Arduino. Since I wanted the etch-a-sketch controller to be relatively free-standing, I got some lone wires for this. (Note that I’m only drawing data off one pin of the three-axis accelerometer.)

With wires!

With wires!

I had to decide what data I wanted to process on the micro-processor, and what data I wanted to process in the applet. I decided to simply send the raw potentiometer data to the applet so that t was easier to resize the applet window and still keep maximum resolution on input data. I also decided to simplify the shaking/not-shaking decision enough to allow it to be calculated on the micro-processor and then simply forward a boolean value.

I also needed to calibrate the accelerometer to account for gravity. I wanted it to calculate from a value of 0 while at rest, and different people might hold it at different angles. Here’s the exciting Arduino code:

int baseZ;

void setup()
{
baseZ = analogRead(2);
Serial.begin(9600);
}

void loop()
{
int leftPos = 1024 - analogRead(0);
int rightPos = 1024 - analogRead(1);
int zDiff = analogRead(2) - baseZ;
Serial.print(leftPos,DEC);
Serial.print(',');
Serial.print(rightPos,DEC);
Serial.print(',');
if(zDiff > 150) Serial.println(1,DEC);
else Serial.println(0,DEC);
}

Note the if-else at the very end of loop(). This handled sending the correct value to the applet about shaking.

I had planned to have a variably-sized window in the applet with coordinate values scaled at start-up, but I got lazy. I decided that since I had a resolution of 1024×1024 on the potentiometers, I would have a drawing resolution of half that: 512×512. I defined my blank-state for the applet and wrote a function to generate this state. The function was called once during setup() (instead of duplicating the data in setup() itself) and then was called any time the shake boolean from the Arduino was true. Here’s that code:

import processing.serial.*;

Serial serialInputPort;
int xPos = 5000;
int yPos = 5000;
int[] inputValues;

void setup()
{
serialInputPort = new Serial(this, Serial.list()[0], 9600);
size(544,544);
clearBackground();
}
void draw()
{
}

void clearBackground()
{
background(250,0,0);
fill(250,250,250);
rect(15,15,514,514);
// background(250,250,250);
}

void serialEvent(Serial serialInputPort)
{
String inputString = serialInputPort.readStringUntil('\n');
if(inputString != null)
{
inputString = trim(inputString);
inputValues = int(split(inputString,','));
println(inputValues[0] + "," + inputValues[1] + "," + inputValues[2]);
int inputX = (inputValues[0] / 2) + 16;
int inputY = ((1023 - inputValues[1]) / 2) + 16;
if(inputValues[2] == 1) clearBackground();
else
{
if(xPos == 5000 || yPos == 5000)
{
xPos = inputX;
yPos = inputY;
}
else
{
stroke(10,10,10);
strokeWeight(2);
line(xPos,yPos,inputX,inputY);
xPos = inputX;
yPos = inputY;
}
}
}
}

And that’s that!

Thomas

Electronics are apparently primarily info-centric

Tuesday, September 16th, 2008

When we were discussing precisely how to spend our time observing people interacting with technology Neo suggested, and I quickly agreed, that walking up Broadway from ITP to Times Square would likely be pretty interesting. So that’s just what we did. We had planned to hit the road by about 15:00 on Sunday and catch the R train back to the program around 15:50 or so. We both ran a bit late, so we didn’t actually startwalking until just before 16:00.

The assignment was one that I had thought would be interesting when it was assigned. I like watching people, after all. But I was surprised by just how enlightening the whole thing was in some ways.

Earbuds, everyone has them so you don't notice that anyone does

Earbuds, everyone has them so you don't notice that anyone does

1. Earbuds are so ubiquitous as to be invisible. Both Neo and I had digital cameras and we sort of aimed to get shots of everyone using electronic devices as we walked. We realized that this would be difficult, but initially I had thought it would be due to simple volume. I was surprised to find out differently. See, the real difficulty came from the fact that I, personally, have reached a point where I simply don’t notice earbuds. This isn’t because they’re unobtrusive. After all, so many of them are that high-contrast white. No, what has happened is that so many people wear the tings that I’ve stopped seeing them. I find this revelation to be a fascinating sort of commentary on the way ubiquity becomes invisible as well as a sort of insight into my own psyche.

Notice that there are no watches here

Notice that there are no watches here

2. Watches: generational gap. Early in our walk Neo and I talked about how people didn’t seem to be wearing wrist watches. This makes sense since people are so likely to be carrying an important device that incidentally tells time (like a cell phone) that there’s no need for a dedicated time-telling device. There were two major exceptions to this trend toward fewer watches: the elderly, and the professionals. The elderly, I suspect, have wrist watch use so deeply ingrained in their habits that continued use is almost inevitable. It’s simply another instance of a generational/technological gap. The pprofessionals were something else altogether. It was quite fascinating to observe all their very nice watches. Watches that were really more fashion accessory than time-telling tool. This suspicion seemed to be pretty well confirmed by the observation of a businessman with a rather nice watch who pulled out his cell phone to check the time.

Visual information broadcast

Visual information broadcast

3. Electronics as inforation sources. By far the dominant use of electronic devices of all sorts observed were intended to transfer information, generally to the user. Cell phones and MP3 players are obviously informational devices, but it turns out that many other devices are too. Traffic lights, both vehicle and pedestrian, are, in an important sense, purely informational. They don’t actually control the flow of traffic, however we may say it. After all, they’re simply colored lights. What they do is signal to everyone in visual range precisely what rules people are expected to follow in an area. Other overtly information-conveying devices include the digital readouts on buses declaring their routes and the various electronic advertisement signs.

Private aural space

Private aural space

Of special interest is the division of public and private information devices. The majority of private devices are primarily aural: MP3 players, cell phones, and the like. While the majority of public devices are vsual: signs, signal lights. The aural component is more intimate and intrusive while being more easily distorted by distance and the visual component is less intrusive while being less distorted by distance so this makes sense. That said, I feel that there’s some interesting things to play with in this sort of aural/visual-private/public divide.

Money is an oft-overlooked form of information technology

Money is an oft-overlooked form of information technology

An interesting revelation that this line of thinking led to is that the ATM is also primarily a sort of information dispensing machine. Beyond the obvious functions involving relaying your bank balance to you, cash itself is really an information carrier rather than a good. A highly specialized inforation carrier, to be sure, but still just encoded knowledge.

An island of electronic silence

An island of electronic silence

4. The subway is a surprising zone of electronic silence. Not that I hadn’t noticed this before, but I had never given it much thought: a lot of the quiet that one finds on the subway is due to the fact that there is no cell reception down there. In any similarly crowded public space with cell reception you are virtually guaranteed to be unwilling participant to at least half a dozen conversations taking place on cell phones. There are numerous people on the subway with books, newspapers, and magazines. That much physically printed material is rare these days outside of a bookstore. After all, your average coffee shop, once a bastion of reading the printed word, contains more glowing-screened laptops than books these days.

Overall the observation exercise was an interesting one. Recogizing the dominance of electronic devices used for information has gotten me thinking quite a bit about what other possible uses we might be missing out on. Clearly we know that these things are good wiith data, but surely there’s more to them than that.

More work with analog and digital

Sunday, September 14th, 2008

When last we saw our hero (me), we had a sort of sketchy resistometer. The code is set up poorly and the LEDs don’t work properly. Let’s see if we can fix that.

The first thing we need to go over is the interaction of parallel and serial electric circuits. In our previous design the LEDs were all in parallel, and that parallel array is connected to a single resister. It looks something like this…

Diagram of parallel LEDs

Diagram of parallel LEDs

Here’s the problem: because behind each of these LEDs is the micro-controller, and each of the micro-controller pins provides separate power source, as each LED comes online the current flowing through the parallel circuits adds up as it hits the resister. While the voltage remained constant in theory, the increasing current across a single resister (thanks to Ohm’s law) pushed the voltage up. The single resistor creates a bottleneck that reduces the proportional power across the circuit as each LED comes online.

The solution is to give each LED its own resistor. Because I’m lazy and didn’t really want to cut a whole bunch of resistors, I scaled the design back from 8 LEDs to a mere 5. This meant rewriting the code with new intervals, but I had to do that anyway due to the greater-than/less-than confusion in the last version. So here’s my redesigned LED array:

LED array

LED array

Then I reconnected my input device, the potentiometer. Which excitingly looks like this:

The exciting new circuit

The exciting new circuit

Then the code needed to be rewritten, which was pretty easy:

void loop()
{
int inputValue = analogRead(5);

if(inputValue < 200) digitalWrite(6,HIGH);
else digitalWrite(6,LOW);
if(inputValue < 400) digitalWrite(5,HIGH);
else digitalWrite(5,LOW);
if(inputValue < 600) digitalWrite(4,HIGH);
else digitalWrite(4,LOW);
if(inputValue < 800) digitalWrite(3,HIGH);
else digitalWrite(3,LOW);
if(inputValue < 1000) digitalWrite(2,HIGH);
else digitalWrite(2,LOW);
}

And then we boot it up and we get this lovely little thing:

Exciting, right?

From here on out I'm going to be working on getting this thing converted from a resistometer to a deciblemeter which reads the volume of ambient noise. The output, and even the code, will probably be mostly the same. The hard part, or at least complicated part, is figuring out how to use a voltage-producer instead of a variable resistor as an input. I've got some emails out about that. We'll see what happens.

Thomas

Analog input on digital circuits

Sunday, September 14th, 2008

Digital circuit design is a really useful skill for someone who intends to be building electronic devices. Understanding the logic of binary states is something you certainly need if you want to do anything with a micro-controller, and if you want to integrate complex software controls with you tiny devices you do want to use a micro-controller.

However, most of the world is analog, not digital. While there are certainly a lot of interfaces you can design that are purely digital, there are many sorts of interactions that are analog only. Thus, in order to do some of the really interesting stuff in electronics design you need to understand analog inputs and how to handle them.

The first thing to understand is that while you may be using analog devices, if they are connected to a micro-controller then their inputs are being converted to a digital format. So while the number of states an analog device can have are actually infinite, when building circuits they are limited by the precision of your micro-controller’s analog inputs. The Arduino uses a 10-bit analog input system, which allows for 1024 (0-1023) possible states. Roughly: the Arduino can measure analog inputs to within about 0.1% precision.

In order to play around with this I decided to set up a series of LEDs (that is, multiple outputs) to indicate variable resistance levels. More LEDs light up as resistance increases.

Step one is setting up the LEDs. This is pretty simple. You might notice that I’ve got a single resister on the ground connector rather than one for each LED. The idea here is to use the sequencing features of electric circuits to save on resisters. This should result in the same effect as a separate resister for each LED. (Note: This is not actually true, as we’ll see later on in the post.)

LED array

LED array

Next we need to hook up our input: a variable resister. In this case we’re using a potentiometer. Like all variable resisters we need three connections: power, ground, and the input pin for the micro-controller. Here’s the potentiometer set up on the breadboard.

Add the potentiometer

Add the potentiometer

Now that we have our circuits put together, we need to connect them to the micro-controller. Remember that since each LED is lit separately, it needs its own pin on the board.

Connect it all to the Arduino

Connect it all to the Arduino

Now all that’s left is to do our code. It’s pretty simple: the Arduino can sense 1024 possibilities, round that off to 1000 for ease of use. There are 8 LEDs which gives each one an equal integral of 125 values. Simply divide them up and have a series of non-interfering IF statements.

void loop()
{
int inputValue = analogRead(5);

if(inputValue > 125) digitalWrite(9,HIGH);
else digitalWrite(9,LOW);
if(inputValue > 250) digitalWrite(8,HIGH);
else digitalWrite(8,LOW);
if(inputValue > 375) digitalWrite(7,HIGH);
else digitalWrite(7,LOW);
if(inputValue > 500) digitalWrite(6,HIGH);
else digitalWrite(6,LOW);
if(inputValue > 625) digitalWrite(5,HIGH);
else digitalWrite(5,LOW);
if(inputValue > 750) digitalWrite(4,HIGH);
else digitalWrite(4,LOW);
if(inputValue > 875) digitalWrite(3,HIGH);
else digitalWrite(3,LOW);
if(inputValue > 1000) digitalWrite(2,HIGH);
else digitalWrite(2,LOW);
}

Observant people will note that my code has an unfortunate little error: while my circuit theoretically measures resistance, lighting more LEDs as resistance goes up, what this code actually does is light more LEDs as resistance drops. This is easily fixed by swapping all greater-than symbols for less-than symbols in the IF statements.

Let’s watch this baby in action.

The key thing to note here is that as more and more LEDs are lit, they all get dimmer. This little problem had me banging my head against the wall until I thought it must be a simple power-drain problem with not enough current to light all the LEDs. Except this thing is running on a 500mA power supply, and there’s no way these things need 100mA a piece. The problem is actually one of the interaction between parallel and serial circuits, which I’ll talk about more in the next post.

Thomas

Physical Computing Lab 1

Thursday, September 4th, 2008

In less I hate the world news, here’s my first real project at ITP. Physical Computing Lab 1 is really more of a “get your feet wet” lab than anything else. The linked lab there is actually more complex than the one we actually were requested to execute.

We’re using the Arduino chipset and codebase for digital control, and the first project was just a “learn about digital design, do a tiny bit of programming”.

We were asked to design a system that, when a switch is activated an LED flashes on and off; when the switch is not activated, the LED stays off.

Most people come out of high school with at least a rudimentary understanding of electricity and thus know how to right a switch-to-light bulb circuit. That’s the first lesson that has to be unlearned for people doing digital work, and that’s probably the important bit (beyond “you can do it”) that this first lab teaches. See, in digital circuit design, inputs and outputs are independent circuits. Instead of rigging the switch to the light circuit, you design a switch circuit connected to the controller and a LED circuit connected to the controller. Their only link is that controller. It looks something like this:

Conceptual Diagram

This means that two separate circuits need to be designed: an LED circuit and a digital switch circuit. The LED circuit is simple, and doesn’t require explanation of the difference between analog and digital switching, so let’s start with that.

An LED circuit is almost precisely identical to the classic light bulb circuit. It takes power from some source, feeds it through an LED, and runs that to ground. You’ve probably seen this before. There, is, however, an important exception here. See, the current that the Arduino puts out is actually too high for a standard LED and would burn it out. This means we want to slow that current down so we use a resistor. 220ohms is about right for our purpose here, so we end up with a circuit that looks a lot like this:

Diagram of the LED circuit

Of course I didn’t have a 220ohm resistor handy, so I did the next best thing: I grabbed a pair of 100ohm resistors and linked them in series. When you line resistors up like this in a circuit, you add their resistance together. It’s quite convenient. So the actual circuit I built looks like this:

Alternate LED circuit diagram

My actual design is very exciting. It looks like this:

Image of my LED circuit

With the LED circuit completed, the next step was to design a switch circuit. The traditional analog switch is simple: a switch with a power source at one end and ground at the other. Unfortunately, digital switches are a bit more complex. See, digital switches are constantly looking for an input. If they sense one then they are “on”, if there is no input then they are “off”. For analog purposes an open switch doesn’t let enough current across to do anything significant, but in a digital switch system an open switch may still allow static electricity or power generated by magnetic interference flow to the sensor, confusing it. This means that all digital switches need to be grounded in order to keep them at zero current when they are open.

It’s the “when they are open” part that gets problematic because we need to ensure that when the switch closes that the current doesn’t flow into the ground, but into the digital sensor. We accomplish this with a huge, ginormous resistor. When the switch is open there is a single loop: sensor to ground. This means that no matter how big the resistor is, the loop stays closed and the sensor is grounded out. When the switch is closed, however, the current from the switch has two potential directions: to the sensor, or to ground. By putting a large resistor on the ground side we ensure that the power flows to the sensor, switching it on.

Another diagram (it’s worth noting that in this particular circuit the system is so low on resistance that you can use just about any resistor you want here):

A diagram of a digital switch

Since I didn’t feel like getting out an actual switch, I built my own… sort of. I simply left an exposed section of wiring at the end of my power lead, and another one between the resistor and the micro controller. The switch is “closed” whenever I touch the exposed wires together, and “open” the rest of the time. It looks like this:

This totally \"awesome\" switch I designed.

Now all we have to do is connect our two separate circuits to the controller. We already know how to do this with the switch since it’s wired to an input, and doing it with the LED is just as simple. Since we want the LED to be an output of the circuit instead of an input, we want to connect the power end of the LED circuit to one of the controller pins.

What we get looks something like this:

Combined circuit diagram

What we have here are two circuits linked by a micro controller. The first circuit is a simple light: when the controller gives the signal, the light turns on. The second circuit is a simple switch: the controller constantly listens to see if there is power flowing across the switch or not. Using my amazing breadboard-less skills, it looks like this:

The modern sculpture of my complete design!

Now that we have our exciting digital system, we need to do something with it. There are all sorts of possibilities now because we have a switch and a light. We could make the light simply turn on when the switch is closed, we could make it flash, we could even make it flash at a rate based upon how long the switch has been closed. For now let’s just do something simple, but at the same time let’s do something that actually requires a micro controller to do. That means no flash rates based on how long the switch has been closed, but it also means no simple “close the switch, turn on the light” since we can do that in pure analog systems. Leaving us with the second option: “when the switch is closed, the light pulses”.

With the circuit designed, the actual command system is entirely software-based. Arduinos use a very simple codebase, so here’s all we have to code up:

void setup()
{
pinMode(2,OUTPUT); // Set this pin as an output,
// It is where we plug in the LED
pinMode(3,INPUT); // Set this pin as an input,
// It is where we plug in the switch
}

void loop()
{
if(digitalRead(3)) // If there is current on the switch's pin
{
digitalWrite(2,HIGH); // Output current to the LED
delay(1000); // Wait one second
digitalWrite(2,LOW); // Stop outputting current to the LED
delay(1000); // Wait one second
}
} // Repeat the loop code indefinitely

Load that code into the Arduino and you’re all set to go. With a little work, you too can have an amazing circuit like mine. Here’s a nice 30 second video of it in action:

Thomas