Gian Pablo @ ITP

The Arduino is a very popular and easy-to-use microcontroller development environment - however, projects can easily grow complex, and the limitations of the AVR processor become an issue. One of the key issues is using up all the memory, the subject of this article. (The other key issue is running out of I/O ports.)

In order to make the most of Arduino memory, it is important to understand how much, and what type, of memory is available. The AVR Atmega 168 chips used in newer Arduinos have 16K of Flash program memory, used to store programs. (The older Atmega 8 has 8k.) There is 1K of RAM, used to store program variables during execution. This RAM is cleared when the power is switched off. There is 512 bytes of EEPROM, memory which can also be used to store data for programs, but which is retained even when power is turned off. Finally, it is possible to extend the memory of an Arduino project by using external memory.

I'll cover techniques for making the most of all these. This is meant mostly as a survey of popular techniques, not an exhaustive tutorial. Please refer to the Arduino website for more details.

Continue reading "Making the most of Arduino memory" »

Posted by Gian Pablo at 09:51 PM | Permalink | Comments (0) | TrackBacks (0)

Are you using the Arduino Mini microcontroller?

Did you break it, and are wondering if you can "reformat" it?

Would you like your applications to start faster, without an annoying 10 second delay?

If so, then you might want to bootload your Arduino Mini!

I've written a tutorial on the Arduino site that explains how to do it, it is here.

Posted by Gian Pablo at 05:14 PM | Permalink | Comments (0) | TrackBacks (0)

Connecting the Arduino microcontroller with a computer is an extremely common task in Physical Computing, but often frustrating and difficult.

One of the best ways to do this is by using the Pduino package, by Hans Steiner (ported to Max/MSP by Marius Schebella).

This system consists of two parts: the first, a firmware package for the Arduino microcontroller that turns it into a dedicated sensor box, relaying the the status of all inputs and setting the outputs via MIDI-based commands; the second, objects for Max/MSP or PureData that interface with the firmware.

I had some problems with the initial release of the Max/MSP port. However, the latest versions, and the incremental update to the serial object in Max/MSP for Windows, have completely resolved those issues.

Attached is a screenshot of the Arduino test patch, showing all the various inputs and outputs.

Posted by Gian Pablo at 12:08 AM | Permalink | Comments (0) | TrackBacks (0)

Two pieces that I worked on have made it into the ITP Winter Show! It is usually quite rare for works from introductory classes to make it in, but at the last minute they made it.

The two projects are "Action At A Distance" (wireless lamps), and "Turing Machine", with Ruth Sergel, an interactive documentary about the life of Alan Turing.

Of course, this means the semester isn't quite over, as both projects need last minute tweaks.

Do check out the show in person, if you can come, and if not, enjoy browsing the project database.

Posted by Gian Pablo at 09:47 AM | Permalink | Comments (2) | TrackBacks (0)

"Action at a Distance" is my final project for the Physical Computing class.

It consists of four separate lamps, lit with multicolor LEDs, that display the same pattern of lights in response to gestures, no matter how widely separated. (Well, within radio range).

What do I like about the project?

* Gesture control of the lamps is fun, especially since the response is immediate.
* The instant synchronization of the lamps, all separated, is attractive and engaging.
* It's attractive - I would not mind having it in my house. (This was actually a primary design goal)

Click on the thumbnails below to see pictures of the lamps on display:

Read past the link for more detailed information, including links to related posts:

Continue reading "Action at a Distance - project overview" »

Posted by Gian Pablo at 11:58 AM | Permalink | Comments (1) | TrackBacks (0)

All four lamps are finished, and working!

Gestures in front of any lamp affect all the lamps. The lamps all show the same display, but it depends on which lamp generated the triggering event.

For those of you new to the project: the concept is "action at a distance", the lamps all react in unison regardless of distance (well, within a few hundred meters). Technically, quite complex: uses AD5206 digipots, Zigbee radios and Arduino minis, all held together with some elaborate software.

I am quite pleased with how it works, but can already think of a few improvements:

* Full state machine implementation
* Individual addressability
* Better discovery routine
* Time out routine
* Fading between LED settings

More info after the link...

Continue reading "Final project - all done (for now!)" »

Posted by Gian Pablo at 10:30 PM | Permalink | Comments (0) | TrackBacks (0)

Another lamp built - two to go!

Today's lessons:

* Important: a Zigbee needs to hear a "wakeup" character (any character) to start sending. So before doing anything else, send it something, like a carriage return, or an "X".
* Also important: when putting the Zigbee into command mode, instead of setting the guard time to 1000 msec exactly, make it 1100 msec, before sending the "+++" command. 1000 msec is too exact, and sometimes does not trigger correctly.
* When two Zigbee radios try to talk at once, neither one is heard.
* Power matters. Voltage, amperage, etc. need to be taken into account.
* If it isn't broken...

Posted by Gian Pablo at 08:26 PM | Permalink | Comments (0) | TrackBacks (0)

For my final project, I am using the Zigbee radios all in broadcast mode, ie. all of them are transmitting to destination FFFF, so that all the radios in the network can listen at once.

This is useful for debugging (I can "listen" using a Zigbee and a laptop) and for simplifying the code.

However, it creates a problem: whenever the lamps receive a message, they send out an acknowledgement and a status report. If this report contains the letter "L", then the other Zigbees interpret it as a command, and send out their status reports.

So every command leads to a flurry of radio communications, and I guess some messages are lost or delayed.

Easy to fix, by forcing the lamps to ignore any line that doesn't start with an "L", but nevertheless something to keep in mind.

Posted by Gian Pablo at 09:14 AM | Permalink | Comments (0) | TrackBacks (0)

Some progress: I have completed physical assembly of the first lamp, and learned a lot in the process.

The lamp is shown below, with the LEDs lit in red, yellow, green and white.

Read past the link for more thoughts and observations.

Continue reading "Final project - first lamp assembled" »

Posted by Gian Pablo at 05:54 PM | Permalink | Comments (0) | TrackBacks (0)

I've defined a simple protocol for the lamps to communicate amongst themselves.

All commands start with the letter "L", followed by another letter and a series of parameters. The code for parsing the commands is pretty reliable, I will post it shortly.

Read past the link for a list of the commands.

Continue reading "Final project - lamp protocol" »

Posted by Gian Pablo at 02:01 AM | Permalink | Comments (0) | TrackBacks (0)

Spent a frustrating evening trying to get the Zigbee radios to work.

Update: There is a further solution to the problems described in this article. Basically, always send a "wakeup" character to the Zigbee before doing anything else, and set the guard time before a "+++" command to 1100 msec, not 1000.

The problem:

On one of my prototype boards, the Zigbee radio did not seem to be receiving commands from the Arduino, so it wasn't getting the right network ID, or setting itself to transmit in broadcast mode.

I programmed the Zigbee on my "modem" board, which connects it directly to a USB adapter, but nothing doing. It was clearly receiving via wireless, and ouputing the received signal to the Arduino, which changed the display, but nothing coming back the other way.

I spent several hours trying different things, including an incorrectly connected 12V power supply which killed one of the AD5206 digital pots, and nearly killed an Arduino mini.

I had made a mistake, in that I had not set the Zigbees correctly to multicast by using the PAN ID FFFF. I had used FF instead. However, that did not fix everything - one Zigbee still did not work.

What turned out to be problem? One of the Zigbees is defective, probably as a result of bad soldering by myself. It works fine as a "modem", but simply refuses to accept input from the Arduino mini. Two other Zigbee radios are working fine.

I uploaded the receive protocol software to two of the working prototype boards, and tried sending various lighting commands to them, which worked fine.

Of course, now I am behind: I still need to port over the sensor code & the state machine from the midterm, and physically assemble the lamps.

Posted by Gian Pablo at 01:53 AM | Permalink | Comments (0) | TrackBacks (0)

For anyone interested in working with the AD5206 DAC, follow the link for my code that controls 4 multicolor LEDs using two AD5206 chips.

The write_LED routine is particularly handy. It is for controlling multicolor LEDs by specifying red, blue & green values. It is designed to work with multiple AD5206s chained together, and will figure out which set of pins on which DAC are assigned to a given LED.

It divides the LED number by the number of LEDs per chip to get the chip number, then uses a small lookup table to map the red, green & blue pins of the LED to the output pins on the DAC.

I use Heather's spi_transfer routine, and all her setup code.

Follow the link for the code...

Continue reading "Final Project - Working with AD5206 digital pots - for the code junkies" »

Posted by Gian Pablo at 11:25 PM | Permalink | Comments (0) | TrackBacks (0)

Today I finished wiring the first of two prototype boards, and started testing code to work with the AD5206 digital potentiometer. This is a chip that takes serial input on two wires, and uses it to set a variable voltage on up to 6 output pins. You can chain them together, using an additional line to select the chip you want to address.

I am using two of these in each lamp. This lets me control 12 variable outputs using only 4 lines on the Arduino (clock, serial data, select chip 1, select chip 2).

Fortunately, Heather (another ITP student) has written a tutorial on working with the AD5206. Very helpful.

Here are the AD5206s in all their glory:

Read past the link for some weirdness and lessons learned...

Continue reading "Final Project - Working with AD5206 digital pots" »

Posted by Gian Pablo at 11:08 PM | Permalink | Comments (0) | TrackBacks (0)

At my age, memory is not what it used to be, so I find it helpful to help it out with copious documentation.

One thing I have found helpful is to make and print little cards with pinouts of all the pieces that I am using. I have put them online here: http://www.villamil.org/images/pcomp-pinouts/

Please feel free to use them. Right now is mostly documentation for Arduino mini, Xbee radio, and AD5206 digital pot.

I also make little cheat-sheets for different parts of my projects. For example, here is how I will connect multicolor LEDs to the AD5206 digital pot in my final project:

It saves a lot of time, and is less distracting than keeping laptop open to look for datasheets all the time.

Posted by Gian Pablo at 09:26 AM | Permalink | Comments (1) | TrackBacks (0)

I've decided to go ahead with the cluster of lamps idea for my final project.

Basically, it is four lamps capable of responding to gestures, connected wirelessly so that their response is synchronized. This is an evolution of the midterm project, which involved a single lamp. I was quite intrigued by the fluidity of the gesture control system, and wanted to do more with it.

Since the radios are quite powerful, it is possible for the lamps to be quite far away from each other. This has a practical impact: they can be used as a communications device, by interacting with a lamp you can send a message to someone next to a distant lamp. I also like the reference to the quantum physics concept of "action at a distance", where in some way the lamps are "entangled" and always in sync.

Since the lamps will be able to respond to any commands coming in over the Xbee radios, it should also be straightforward to write a program on the laptop that will talk to them and help them do more complicated things.

Keep reading for further information on implementation.

Continue reading "Final project - description & plans" »

Posted by Gian Pablo at 07:42 PM | Permalink | Comments (0) | TrackBacks (0)

I built a simple MIDI "theremin", using an ultrasonic rangefinder.

I had an initial false start, when I soldered the leads on the MIDI connector incorrectly.Once resolved, everything worked fine. Click here for a picture of the MIDI connector.

The picture also shows a multi-colored LED, which I am testing for another project.

Keep reading past the link for the code for the MIDI theremin.

Continue reading "MIDI lab - a MIDI Theremin" »

Posted by Gian Pablo at 09:18 PM | Permalink | Comments (0) | TrackBacks (0)

Just received my order of Arduino Minis for my final project.

I've written up some quick installation tips. Below is a picture of the Mini together with the Mini USB adapter (on the left).

A couple of notes:

* The yellow and blue cables going off to the right are connected to an XBee radio module.

* Note the 10K resistor connecting the reset pin to +5V volt. This is to keep the reset pin high, until the reset button is pushed. The reset button is visible on the right, it is connected to the reset pin via a blue lead which is under the Arduino mini board, to save space.

* I have connected a red LED to pin 13, this pin is flashed by the bootloader whenever the Arduino is reset, and acts like a simple health check.

Continue reading "Getting started with Arduino Mini" »

Posted by Gian Pablo at 09:07 PM | Permalink | Comments (0) | TrackBacks (0)

Here is the Arduino code for the Physical Computing Midterm, the Intelligent Restaurant Lamp.

It is based on three major code blocks: an event detection routine, an implementation of a finite state processor, and a state-dependent display routine.

Continue reading "Code for Intelligent Restaurant Lamp" »

Posted by Gian Pablo at 07:48 PM | Permalink | Comments (0) | TrackBacks (0)

Shinyoung (Rona), Younghyun & myself took the "intelligent restaurant lamp" to a restaurant. We've documented our experience, and some lessons learned, after the link. Please also look at Rona's blog and Younghyun's blog.

Click here for the demo movie.

Interestingly, the waiter told us that two years ago a similar product had been tested in the restaurant, a button-like object that lit up red or green, according to whether the customer wanted to order or ask for the check.

He did not think his restaurant was big enough to justify such a product, and thought the staff was quite alert. However, customers at the next table disagreed, and thought the lamp would be a good idea!

Continue reading "Midterm project completed - field report & lessons learned" »

Posted by Gian Pablo at 11:06 PM | Permalink | Comments (0) | TrackBacks (0)

Inspired the correct functioning of the midterm project (an intelligent lamp for restaurant patrons), I have been thinking about ways to take it forward.

I am thinking of moving things in several directions:

1) More decorative lighting than practical tool, which means replacing the LEDs with brighter bulbs

2) Networking several lamps together - lighting one lights all, in sync and/or having them put on a synchronized show

3) Adding sound, perhaps with little bells or gongs triggered by solenoids

Posted by Gian Pablo at 09:58 PM | Permalink | Comments (0) | TrackBacks (0)

We have now completed the "intelligent restaurant lamp", at least a first version.

It responds correctly to gestures, all controls are working. Still working on timeout and display routines.

Here is a picture:

We've learned that IR sensors are very fiddly to work with: the IR LED transmits a very narrow beam, and the receiver sees a very narrow field of view. Therefore, the two components have to be angled towards each other so that when an object is in front of them, the IR beam projected by the LED is visible to the sensor. A tiny variation in the position of the transmitter or receiver has a huge impact on the values returned. Here is a picture of the emitter & sensor mounted.

I think using the finite state machine concept for programming has been very helpful: we were able to define all states completely, in a very reliable way. I will use this technique again, whenever feasible.

I actually like this device, and would spend the time & effort to make one for myself! I would replace the LEDs with actual lightbulbs, to make it more lamplike, and make a slightly more elegant mount for the sensors.

Working with Shinyoung & Younghyun was a great experience. We understood each other very well, and shared our tasks effectively. Shinyoung actually wrote the code for processing the state machine table, Younghyun and I physically constructed the lamp.

Posted by Gian Pablo at 04:16 PM | Permalink | Comments (0) | TrackBacks (0)

My team's midterm project for Physical Computing involves lots & lots of wires. It occurrs to me that a way of making this attractive (and somewhat obscure) would be to weave the wires together, into a sort of textile, where in some way the colored patterns formed by the wires would represent the circuit itself.

Posted by Gian Pablo at 04:08 PM | Permalink | Comments (0) | TrackBacks (0)

We have moved along further with the restaurant lamp. We now have the physical structure built, have tested the sensor, and have completely defined the gestures and responses.

Here is illustration of the state transition diagram, which shows how the lamp processes upward and downward sweep gestures to get to an "order" and "check" state.

We now need to finish Arduino coding, and wire up the lamp.

Posted by Gian Pablo at 02:52 PM | Permalink | Comments (0) | TrackBacks (0)

I had some further discussion with my midterm group for Physical Computing, and we have converged on something that works.

Initially, we wanted to do a "mood indicator" for people working with laptops. However, this did not have a clearcut application, or interaction with the user. Frankly, it didn't resonate with any of the team members.

The new idea is much better: a gesture controlled lamp that is used to send messages to wait staff at a restaurant, such as wanting to order, pay the bill, etc.

We've noticed that in the US there is no clear way to get the attention of wait staff at restaurants that isn't interpreted as rude. Yelling is not well regarded (unlike Japan & Korea), and gestures are often not seen, or ignored. An intelligent lamp will be able to get attention in a polite way, and "escalate" the request automatically on behalf of the customer.

Input will be by making a sweeping gesture in front of sensors embedded in the vertical lamp. An upward sweep to order, a downward sweep to pay. Up and down sweeps would cancel each other, ie when showing "order" state a downward sweep would cancel the state. (Alternatively, we may include a dedicated "cancel" button. When signalling a state, and too much time passes, the lamp will signal urgency by starting to flash. There may also be light sensors to read overall light levels, and perhaps modify behaviour of the sensors in the lamp.

Our design concept is of a vertical paper lantern with three or four segments, each segment casting light in a different color. The sensors will be embedded in the side.

We will carry out observations this weekend, of how customers in restaurants attract attention, and we will also work out the state table that describes the behaviors.

Posted by Gian Pablo at 07:34 PM | Permalink | Comments (0) | TrackBacks (0)

Finally got to version 4 of the ultrasonic sonar scanner!

This one now has fully functioning comms between the Arduino microcontroller and a Processing program working on the laptop.

There are some minor glitches: servomotor motion is somewhat jerky (possibly a data rate issue) [fixed!], sensor readings lag somewhat, readings are sometimes a bit erratic. I understand that it may be possible to improve quality of the readings by decoupling the signal line, using a capacitor.

Next big step: analyzing transitions & changes in the sensor data in order to trigger MIDI (sound) events.

Keep reading for source code of the Processing and Arduino projects.

Continue reading "Ultrasonic scanner v.4" »

Posted by Gian Pablo at 07:20 PM | Permalink | Comments (0) | TrackBacks (0)

For part 2 of the observation assignment, I observed people using laptop computers at Dunkin Donuts on Second Avenue. Since this place provides free wireless access, has plenty of outdoor tables, and is cheap, there are often lots of people there using computers.

Almost always the pattern of interaction with the laptop was the same: a lot of doing nothing, some stroking of the lower part (using a pointing device probably), and even less frequent bursts of typing. The big exception was when more than one person was interacting with the device, in which case there was a lot of pointing at the screen, and touching. I thought this was very interesting.

What most struck me was the body language and stance of people using the laptops. Rapid bursts of typing were accompanied by an "attention" stance, sitting up in a chair and leaning forward, while the bulk of the time the user was in a "relaxed" stance, sitting back. There were some brief times where the user was in an "attention" stance while not doing anything, or maybe sipping coffee while staring at the screen. There was almost no variation in the focus of attention while using the laptop, save occasionally reaching for coffee.

There was a remarkably consistent pattern that preceded putting the laptop away, which involved looking around, touching the laptop, looking again and then packing it away.

Continue reading "Observation Assignment - Part 2" »

Posted by Gian Pablo at 10:57 AM | Permalink | Comments (0) | TrackBacks (0)

Our team had an initial brainstorming regarding the midterm project. Pictures of our notes are here.

This is based on situations we've seen at ITP, and at other locations during the observation assignment.

We are converging on the idea of a device for indicating whether or not a user is in a communicative state, with sensors to signal the approach of others, and uncomfortable noise levels. This may take the form of an "intelligent laptop pad" or a hat, or both.

The interactions we are hoping to capture are:

* sensing presence of the user, and turning on lights
* allowing user to indicate "mood" - contactable, busy, hungry
* sensing approach of others, and responding automatically according to user mood
* sensing noise levels, and responding automatically
* burglar alarm
* sensing darkness and proximity, and lighting up to help location

Posted by Gian Pablo at 06:38 AM | Permalink | Comments (0) | TrackBacks (0)

I made my observations on a route that went from my home, down Astor Pl., Broadway, then up to 25th St. in Chelsea and back home via Second Ave. This is a composite of three consecutive days of observation, mostly to fill in the number of laptop users at Dunkin Donuts on 2nd Ave.

General observations: iPods and mobile phones predominate. Lots of solitary use of devices (ipods, phones laptops). People holding their iPods in hand even when they have bags. Change in device mix from place to place, though this might also be a function of time-of-day. The ratio of iPod to phone is the most variable. Almost all the people I saw with iPods and phones were walking. Laptops only visible in places where connectivity is available, and never used (or visible) while moving.

Keep reading past the link for detailed observations.

Continue reading "Observation assignment - Part 1" »

Posted by Gian Pablo at 06:52 PM | Permalink | Comments (0) | TrackBacks (0)

I made a very simple circuit + program, basically a general purpose sensor testor. What it is made of:

a) 6 LEDs organized like a scale, connected to digital-out pins on the Arduino
b) a toggle switch for calibration mode, connected to digital-in
c) a sensor, connected to analog-in

What it does:

1) If the toggle switch is closed, then the program watches the sensor and records the minimum and maximum values.

2) If the toggle switch is open, then the program reads the sensor and uses the value to light a scale of 6 LEDs.

3) If the sensor has not been calibrated, then when the switch is open all the LEDs are flashed, as a warning.

I wanted to make a general purpose circuit that allows me to not worry about specific sensor values, and instead work with a min & max that are read from the sensor.

This turned out to be unexpectedly useful - I had been using a voltage regulator (unnecessary with Arduino) so all my voltages were only reaching 2.3v, not 5v. However, the calibration made this irrelevant.

I spent a bit of time wiring up two variable resistors with nice dial-like controls, that came out of an answering machine. One had range in the magnitude of 10K ohms, the other 1K ohms. I think they were meant to work together, one to set a gross value and the other to fine tune, with the resistances simply added together. In any case, I fit the appropriate resistors, now both of them return comparable ranges which are easy to scale in software.

Keep reading to see the source code for the sensor tester. Something's not quite right with the scale function - see if you can find it.

Continue reading "Sensor tester" »

Posted by Gian Pablo at 05:57 PM | Permalink | Comments (0) | TrackBacks (0)

I went ahead and made Simple Simon v2. It now has fully debounced input, it echoes user input, and blinks while waiting.

Still haven't gotten around to the harder/easier routine, and the fancy win.

Read more for the complete source code...

Continue reading "Simple Simon v2" »

Posted by Gian Pablo at 08:19 PM | Permalink | Comments (0) | TrackBacks (0)

Here's what I'll do next to the Simon game:

• Polish the code, fix in-line constants, etc...


• Write a much better input routine that debounces, echos the input, and signals the input state


• Do the fancy "win" song & dance

In terms of aesthetics, I might braid the cables from the switch panel, and run them to 4 pin headers, also do the same for the LED cables.

Posted by Gian Pablo at 06:57 PM | Permalink | Comments (0) | TrackBacks (0)

I got this thing to work, and am very pleased!

Pictures are here.

It's basically a Simple Simon game. The LEDs blink in random order, then the player has to press the buttons in the same order. If you get it right, the green light blinks (and in future, the game gets harder). If wrong, the red light blinks (and game gets easier).

The hardware was straightforward - just a bunch of LEDs and a row of switches salvaged from a busted answering machine in the junk pile. (Potential pitfall of stuff from the junk pile - it was thrown away for a reason, maybe stuff won't work.) I wrote a simple program to test the switches by lighting the corresponding LED.

Hardest part was getting to grips with C syntax, which is new to me. My structured programming techniques from 20 years ago worked well. In fact, I think structured programming techniques apply to hardware design as well. I tried to be tidy in order to keep things organized and easy to manage.

It still has a couple of bugs to be worked out - however, I am thinking of leaving it as-is. Why? Because the stories people create to account for the game's malfunction are far more interesting than the reactions when it works correctly. When it works fine, people can play for a bit, see how it works, and then get tired and walk away. They don't need to really engage. Howerver, a sporadic malfunction is a puzzle: the players have to think hard about what might account for a strange behavior, and this is a much richer interaction than simply playing the game.

I still need to:

* implement debouncing code for the switches, which are sometimes giving double responses
* define constants for the number of LEDs and switches - currently hard-coded in two loops
* implement makeHarder and makeEasier routines - I will work with the amount of error and the time taken to respond
* implement a time-out routine when waiting for input
* implement a blink routine when waiting for input
* make a fancier song & dance for success

Keep reading to see the complete source code for the project.

Continue reading "My first project - Simple Simon game!" »

Posted by Gian Pablo at 09:45 PM | Permalink | Comments (1) | TrackBacks (0)

I built my first breadboard circuit today, learned a lot.

First learning, thanks to Roy: when making your power connector, don't bother trying to solder the ends of your lead to the straight headers. It's fiddly and difficult, and you'll end up melting the plastic part of the header. Instead, use pliers to pull out the header pins, and feed through the stripped ends of the wire. Use a blob of glue to secure it. Much tidier.

Second learning: if your multimeter is set to measure AC voltage, and you touch it to a DC circuit, it seems you will kill your LEDs instantly. The instructions on the class note are a bit confusing: if you follow them with the multimeters that are sold at the NYU computer store, they will lead you somewhat astray. Specifically, they suggest moving the red lead, which is actually not necessary. Doing this will set you up to measure AC voltage.

Posted by Gian Pablo at 12:36 PM | Permalink | Comments (0) | TrackBacks (0)