MW-photo
April 11-14, 2007
San Francisco, California

Imagining the Internet: How Inexpensive Microprocessors, Cell Phones, and Solid State Servers Can Interact with the Physical World

Michael Edson, Smithsonian Museum of American Art, USA

Abstract

Most of us are conditioned to think of the Web as a network of expensive desktop computers and servers, but the standards that define the Internet and the Web can be interpreted in other ways and used with other technologies.

This paper complements a hands-on workshop where  participants will explore these questions by constructing and programming an Internet-enabled soda-vending machine. The machine will be built using inexpensive, readily available microcontrollers (small, solid-state computers) and will be able to communicate with and be controlled by Web sites, databases, cell phones, RFID cards, and even a television remote control. Workshop participants do not need to have any prior knowledge of programming or computer science: just curiosity and the willingness to challenge their own preconceptions about what the Internet is and does.

Keywords: internet, standards, Web, programming, robotics, mobile technology, physical computing

Imagine a Different Internet

On the surface, one might not think that microcontrollers would be relevant to a conference of museum Web professionals. Microcontrollers are plucky little computer chips that provide the brains for almost every electronic gizmo that beeps, wiggles, or controls something, and dealing with them is a far cry from the bread-and-butter activities of museum digitization, education, and outreach. But looking past the surface for a few moments is exactly what makes these little chips worth talking about.

In North America and Europe, we’re accustomed to thinking about the Internet as it’s defined by desktop computers networked to big servers with complex software - so accustomed that we almost never question it: that’s just what the ‘net is. Howard Rheingold pointed out this unconscious bias in Smart Mobs and observed that for millions of people in the developing world (and also notably Japan), the Internet is embodied not by personal computers but by mobile phones. In When Things Start to Think, Neil Gershenfeld mused about collapsing the boundaries between physical objects and information systems, and the relatively recent ZigBee protocol exists because somebody really needed to imagine corporeal objects forming their own quasi-Internet through low-power wireless mesh-networks. It’s all pretty strange, but it points out how powerful and malleable open-standards frameworks like the Internet Protocol are: who imagined 20 years ago that the same set of rules created for a nuclear-attack-resistant messaging network could spawn the World Wide Web and MySpace?

If I say, “go and buy a Web server,” you’ll probably start thinking of a hardware and software investment of thousands or tens –of thousands of dollars. Even if you’re an open source guru, you’ll know you have to start limbering up to muscle big, heavy, power-guzzling, beige-encased slabs of silicon and copper into racks. But what if I told you that you could buy a complete Web server that fits in the palm of your hand for $130 - and that it’s battery powered?! Both these visions of what a Web server is share a set of standards, but they use wildly different interpretations of those standards. The cheap palm-sized Web server isn’t a fantasy; it’s real, mass produced, and easily bought. A lot of other astonishing things are out there too, and a lot more can be dreamt up by people willing to look away from common conventions.

Figure 1

Fig 1: A Web server that fits in the palm of your hand.

With increasing frequency, when someone talking about “putting something on-line” may be talking about using microprocessors to put a physical thing on-line - not a digital surrogate (like a digital image of a work of art) - in some way extending a core attribute of the thing’s actual thingness on to a digital information network. Maybe it’s an alarm clock that wakes you up early if the surf is good (or lets you sleep if it’s not). Maybe it’s a piece of medical equipment that sends e-mail when it needs servicing. Or maybe it’s a scoreboard showing the most popular artworks in your museum as determined by pulling information from your Web site or sensing how many people are in each gallery. Make magazine is full of these kinds of projects, and apparently the sky is the limit.  That is exactly why I’m interested in this now.

It’s time to throw out old assumptions and innovate. The boundaries between physical and virtual erode a little every day. Hackers and hobbyists are finding a common vocabulary in making stuff with microprocessors. There’s probably a Dorkbot group (http://dorkbot.org) in your city. Linux and open source thrive. Social networks, the Web 2.0 platform, and Long Tail markets are turning a lot of conventional business models on their heads, including, perhaps, the ones that have provided sanctuary to museums for the last 150 years. Where this is all headed is as inconceivable as where we are now compared to 20, 10, or even 5 years ago, and while it’s true that museum professionals have extremely important work to do in core digitization, documentation, and elucidation, it’s also true that we’re a curious and precocious bunch. Building things with microprocessors is a heckuva lot of fun and dealing with their many surprising attributes puts one in a state of mind to question and discover. And that’s good. Let’s begin.

What’s a Microcontroller?

In the rest of this paper I’ll take beginners through a high-level tour of designing and building an Internet-enabled soda-vending machine. I’m assuming my audience has only a passing familiarity with hardware and software design. I won’t present all of the data or recipes needed to build the machine, but at the end of this paper readers should have a pretty good idea of how to get their own investigations of microcontrollers started.

First, a disclaimer. Spread your hands apart so your left hand is as high in the air as possible and your right hand is as low to the ground as possible. You’ve just made a graphic representation of how my knowledge of microcontrollers relates to that of the experts. I’m down where the left hand is and there are tons of people whose knowledge is up where your right hand is.

Andy Lindsay in What’s a Microcontroller (2003, Parallax) says

A microcontroller is a kind of miniature computer that you can find in all kinds of gizmos…If it has buttons and a digital display, chances are it also has a programmable microcontroller in it.

He continues to describe the way in which digital processors are teamed up with other components to constitute an “embedded system”, commonly called a microcontroller.

The microcontroller I have in front of me is called a Basic Stamp and it’s made by Parallax (http://www.parallax.com). The processor itself is tiny - about the size of a child’s fingernail. The processor has been fastened to a playing-card sized plastic circuit board that connects it to a battery, a serial port for hooking it up to your computer while programming and debugging (and for communicating with other things that can understand serial protocols), and a grid of tiny sockets that let you connect the processor’s digital signals to other electronic things, kind of like an old-time telephone switchboard. This whole setup can be manufactured by you for $20.00 or so, or you can do what I did and buy it already put together in a kit that includes some sensors, motors, lights, and displays, with a well-written book that tells you how everything works. I got my BASIC Stamp Activity Kit at my local Radio Shack, but you can get it direct from Parallax too.

Mention the phrase “Hello World” to programmers and they’ll know you’re talking about the way new programming environments are tested by trying to get the systems to just print those words to a terminal screen. The equivalent exercise for my Basic Stamp is hooking it up to a computer and writing a program that says “Hello World” to a debugging/output window that pops up on the computer screen.

The first and second lines tell the programming environment what kind of microcontroller you’re using and what language you’re programming in. When this program is loaded on to the chip, the third line tells it, “open up a connection to the computer you’re connected to and tell the programming environment to open a new debugging/output window and print the words Hello World on it.” Once you’ve written these three lines you compile the program (convert it from English, which you understand, to bytecode, which the processor understands) and get the file on to the microprocessor by clicking a button on the programming editor’s toolbar. With any luck the program runs, opens a window, and types Hello World in it. That’s all there is to programming this kind of microcontroller, and variations of these steps are at the foundation of every microprocessor-controlled device in the world.

Getting a Microcontroller to do Work

Microcontrollers embody the saying “software is language that does work”, but how do we turn Hello World into a blinking light, spinning motor, or responsive sensor? The key is a series of software-controlled circuits within the microcontroller that turn on or off, change their voltage, or pulse in extremely fast and highly controllable ways. Manufacturers of motors, lights, and sensors tailor their products to the operating capabilities of microcontrollers (and visa-versa) making things pretty straightforward once you figure out the general scheme of things.

Want to write a program that blinks an LED ten times? Hook the LED to circuit 1 (also called “pin 1”) and write a program that says (in pseudo code):

Send 5 volts to pin 1

Wait ¼ second

Send 0 volts to pin 1

Wait ¼ second

… & etc…

Want to get a servo motor to move a lever when you press a button? (Servo motors are a motors that don’t spin typically but move an arm across an arc of motion. They are frequently used in robotics, and we’ll use one in our soda machine.) Consult the data sheet that comes with the motor to see what kind of electric pulses make it move. Then hook the button to pin 1 and the servo to pin 2 and write a program that says (in pseudo code):

Wait until the button is pressed

Send some pulses of 5 volt current pin 2 to make the servo rotate from 12-o’clock to 2-o’clock

Infrared sensors (like the one in your TV that responds to your remote-control), RFID readers, temperature/humidity sensors, and other widgets of this ilk are similarly integrated and controlled, usually after a process of trial-and-error and consulting the documentation that comes with them. For example, to read temperature from a digital thermometer chip and sound an alarm if it exceeds 60 degrees, get the chip and a 5-volt buzzer, hook them up, and write some something like this (in pseudo code):

Repeat every 10 seconds forever:

Set up a data connection to the thermometer
on pin 1

Set up a data connection FROM the thermometer
on pin 2

Tell the thermometer to wake up (send wakeup data to pin 1)

Ask the thermometer for an update (send request to pin 1)

Listen for the data from the thermometer

If the temperature > 60 then send a 2-second long pulse of 5-volt current to pin 3 (the buzzer)

Of course, I’m omitting a lot of detail in the electronics and programming, but this is really the way it all works. Getting from Hello World to controlling a sophisticated Internet-enabled contraption is just a matter of adding depth and refinement - and often less depth and refinement than one would imagine.

Functional Requirements for Internet-Enabled Soda Vending

To demonstrate the capabilities of microcontrollers and help conference attendees start their own exploration of them, we’re going to build an Internet-enabled soda vending machine. Any good design begins with some requirements, and the following 10 sum up ours. I’ll reemphasize that this document won’t provide a comprehensive bits-and-atoms blueprint for building your own Internet-enabled vending machine, but it will show enough of the high-level terrain so that readers can begin their own experimentation without getting disoriented too frequently. (We’ll sweat the details in the workshop though.)

The Vending machine must:

  1. hold a minimum of 6 standard 12 ounce cans of soda
  2. provide a mechanism for vending cans and inserting new cans
  3. vend a can in response to user input through a Web page
  4. report how many cans are in it through a Web page
  5. vend a can in response to commands from a television remote-control
  6. vend a can in response to being touched with an RFID card
  7. vend a can in response to an SMS text message sent to a phone number
  8. display its status
  9. have exposed parts so people can see how everything works
  10. be strong enough to survive being shipped from D.C. to San Francisco

One final requirement is that the whole thing should not look like a terrorist device - I don’t want to get arrested by Homeland Security on my way to or from the conference.

Analysis

A glance at the requirements tells us that we’re going to have to build some kind of frame to hold the sodas and provide support for whatever electrical/mechanical devices are needed for the brains and muscles of the system. A series of doors or gates are needed to hold cans in place when the system is at rest and to let just one can through when an order is received.

We’ll need some component to provide the muscles that open and close the vending gate and the other gate that temporarily restrains the other cans, something that can receive and interpret Infrared (IR) signals from a remote control, and something that can read and interpret radio frequency identification (RFID) tags. We’ll need an interface that lets us receive and process SMS messages, and some way to show status like an LCD display or a series of lights. And we’ll need a Web server too. Last, but not least, this operation will need some brains - something to converse with and coordinate the IR, RFID, and SMS components, the gates, and the Web server, keep track of the can counts, and decide if and when to dispense a can. What sounded so simple in concept seems kind of daunting now!

Design

Fortunately, we don’t have to forge all of this from raw materials.

Starting with the brains first: surprise-surprise, microcontrollers fit the bill perfectly! A BS2 Basic Stamp kit from Parallax will get us up and running quickly and will be good for prototyping and experimentation at the conference workshop.

For the IR sensor, there’s a small component from Parallax called the IR Buddy (part 28016) that can read and store IR signals until the stamp is ready to read them. (IR communication uses a complicated protocol that would be too messy to use directly in a project like this)

The RFID challenge can be handled in a similar way with a circuit board that has an RFID antenna that energizes RFID chips commonly found in ID cards and merchandise inventory-control tags, reads the resulting signal radiated by the card or tag, and streams the data out to be read by - you guessed it, a microcontroller! Parallax has a good one (part 8140) that can plug right into my Basic Stamp’s circuitry. I found a nifty article in Make magazine (volume 6, RFID for Makers) that shows how this component works.

The SMS design challenge is somewhat similar: we just need some way to interface with a mobile phone and ask it to tell us when it receives an SMS message and send us the message text. Nokia makes a line of cellular phones that allow you to control them with a PC or microcontroller through a serial data cable called an F-Bus connector. I’ll track down a Nokia 3310/3315 (suggested by http://www.embedtronics.com/nokia/fbus.html) and order a cable.

The displaying-status requirement can be fulfilled with an off-the-shelf LCD character display that Parallax sells specifically to be integrated with microprocessors and which comes with sample code that works on the Basic Stamp. (Part 27976)

To provide the muscles for the gates, I chose a Parallax Standard Servo motor (part 900-00005), and I’m planning on scrounging the parts needed to make the actual gates that retain and dispense cans.

For the frame and gates, I’ll sketch out a wooden ramp with two sides to keep the cans in and a wooden hood over the bottom end of the ramp to support the mechanism that controls the vending. Cans will be held in place or released by two pins made out of an old bicycle spoke. At rest the system will tell a servo motor to push one pin down to stop the cans from rolling down the ramp, and when vending the servo will pull up one pin (releasing one can) while lowering the second pin to prevent subsequent cans from rolling out.

Fig 2

Fig 2: A section-view representation of servo-controlled retaining and vending a can.

The Web server integration seemed like the most daunting piece initially, but the embedded Web server from Parallax, the Parallax Internet Netburner Kit, or PINK (part 30013), and others like it, are really just customized microprocessors themselves and appear to have specifications that are compatible with our project. The PINK server has the ability to store variables and display them on Web pages with a simple markup language similar to HTML tags, and it can also communicate with the Basic Stamp to get and set variables.

fig 3

Fig 3: A Web page that controls the PINK Web server and

Our final design has the following components:

A schematic of the whole thing put together should look something like this:

fig 4

Fig. 4: Schematic diagram of Internet-enabled vending machine.
The Basis Stamp microcontroller runs the show.

Pseudo code for the project will be something like this:

Set the initial number of cans

Repeat forever:

Update the LCD display with a description of system status

Ask IR receiver if there’s new data

Ask Web server if there’s new data

Ask RFID reader if there’s new data

Ask cell phone if there’s new data

If there’s new data from any devices and it’s a request to vend a can, then tell the servo to let a can out and update the number of cans available

If there’s new data and it’s from the Web server and it’s a command to update the number of cans in the machine (because you’ve added some), then do that

Enjoy!

Construction

I was able to get the Internet-enabled soda-vending machine up on and running in about a week by picking away at for an hour or two at a time. (Writing this paper took a lot longer than making the machine it’s about.) I’ll post schematics and source code before, during, and after the workshop.

The hardware/software integration - getting this thing to listen and react - was facilitated by the fact that almost all of the individual components could be built and tested independently, so I never had to deal with more than a few variables at a time. In addition, while the technology behind all of these things is pretty hard-core geeky, the components themselves only do one or two things and they’re either doing them, or not doing them - once they’re doing them, they pretty much chug along forever until you pull the power. The stability and simplicity of microprocessors and related components is one of the reasons why they’re used in so many commercial products.

So now I can sit in my home or office confident that anybody with a cell phone or anybody on the Web can connect to my vending machine and get a soda, or that I myself can get one with a swipe of my RFID card or a poke with my remote control. Working on this has helped me dream up one home project and two or three work projects, and I can’t wait to find an excuse to go back to parallax.com, sparkfun.com, or Radio Shack to find some new gizmo.

I was an art major in college and a creative guy for many years after, and I avoided acquiring most of the engineering, math, and physics knowledge - not to mention computer science skills! - that many of my geekier colleagues take for granted. Experimenting with microprocessors has been an eye opener. It’s made me more aware of the way standards, good open standards, foster innovation and stimulate creativity; it’s made me more aware of how computers actually work; and it’s made me infinitely more sensitive to the extraordinary unrealized potential of the Internet and the Web. Where data, software, physical objects, and the human mind can interact freely, interesting things are bound to happen.

fig 5

Fig 5: A working Internet-enabled vending machine. The Basic Stamp is on the lower left and the PINK Web module is on the lower Right. Note the servo motor and pivot-arm that controls the vending pins at the top of the wooden case.

References

Gershenfeld, Neil. When Things Start to Think (1999). New York : Henry Holt

Grand, J. (2006). RFID for Makers. Make Volume 06, p. 160.

Lindsay, A (2004). What’s a Microcontroller? Rocklin, CA: Parallax.Also on-line at http://www.parallax.com/dl/docs/books/edu/wamv2_2.pdf (accessed 1/30/07)

Make Magazine. http://makezine.com

O’Reilly, Tim. He nicely summarizes the tenets of Web 2.0 in What is Web 2.0? at http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html?page=1 (Accessed 12/10/2006)

O’Sullivan and Igoe (2004). Physical Computing. Boston, MA: Thomson. Not referenced in this article but enormously useful.

Rheingold, Howard (2002). Smart Mobs, The Next Social Revolution. Cambridge, MA: Perseus.

Stevens, Ted. Series of tubes was a metaphor used by United States Senator Ted Stevens (R-Alaska) to describe the Internet in a Wednesday, June 28, 2006 speech about network neutrality (Wikipedia, http://en.wikipedia.org/wiki/Series_of_tubes, accessed 1/29/2007)

 

Cite as:

Edson, M., Imagining the Internet: How Inexpensive Microprocessors, Cell Phones, and Solid State Servers Can Interact with the Physical World, in J. Trant and D. Bearman (eds.). Museums and the Web 2007: Proceedings, Toronto: Archives & Museum Informatics, published March 1, 2007 Consulted http://www.archimuse.com/mw2007/papers/edson/edson.html

Editorial Note