Skip navigation

5. Code

For our installation we prototyped different parts with different coding. We decided to project footsteps from Processing linked to the Arduino and the switches and we tested also the mechanical hand-crafted projector.

Footsteps code

The main aim of the coding was to have a realistic simulation of the experience keeping the core part of the programming as simple and flexible as possible. Therefore, we coded in Processing basing on the switch (case) structure.

In this way, it was possible to first create the core elements of the interaction and later add or adjust parts of the program without changing lots of the code.

Somehow, this kind of structure can be compared to the MovieClip structure in Flash AS3: it’s easier to create small parts of the program and then combine them together, rather than trying to build a cathedral in a single day.

A great advantage of this kind  of structure is that people can have a general idea at a glimpse of what it is happening when they look at the code, while a disadvantage might be that to pass through each single line of code could take some time. In the same way, using quite a lot of tabs to separate the code was worth while because it was easier to focus on a single issue, but might make a novice to this program feel lost.

Crucial to the success of the installation was timing, which took quite a long time to manage. We needed to synchronize the sound of footsteps with their projection; since they are very simple and clear elements, they needed to be timed properly to give the feeling of a guide preceding the user. From a technical point of view, in order to trigger the subsequent actions we used timers that cued a time in the future, so when it was reached the program switched to another mode.

A complex and time consuming part was the graphical compensation of the footprints, since we had to project them obliquely.

First we mapped the footsteps in Adobe Illustrator in order know the pixel size of each footstep and step length. This mapping was not as useful as we expected because when we transferred the measurements in Processing they didn’t work perfectly so we had to “polish” each footprint.

To do so, we defined a unique identity to each step by counting the steps in each phase of the program. To have a glipse of how the installation would work, we first simulated a user’s behaviour on screen, then mapped the length coordinates with swiches hidden under the floor, which triggered the different parts of the program. Finally we combined the communication from Arduino to Processing to have a working prototype.

Projector code

The code for the hand-crafted projector was developed only after we could understand how it would work. For a physical prototype is important to understand how the various parts are related before writing code. To be sure not to make big mistakes, we went step by step, making different experiments and looking at various examples on the web. In this way we could be sure that each component worked well before adding another. We started controlling the servomotors, something new to us, and then added the LEDs.

At the beginning of the code we declared all the variables for servomotors and LEDs.

To control the servomotors we had to include the Servo library, an Arduino standard library. We tried others but this was simple and complete enough for our purpose.

Both servos and LEDs needed to be attached on PWM (Pulse Width Modulation) pins: We used pins 9 and 10 for servomotors and pins 5 and 6 for LEDs. Actually, we managed to use pins 9 and 10 for servos after some problems. The Arduino reference says that the Servo library works only on pins 9 and 10 in Arduino 0016; we used Arduino 0017 and servomotors worked also on other PWM pins, but following this tip we avoided other strange interferences.

The names of the variables end or start with left/right, referring to left and right footstep: This helped us to understand and check if everything was ok.

In the “setup()” function, we had to set up every component of the system to be ready to work: servos, LEDs and serial communication. We needed a serial communication to be able to control the prototype behavior from the computer.

In the “loop()” function we wrote the code to control the various parts of the prototype. Since it loops consecutively, we could activate the ‘action’ using the serial communication. Servomotors positions are stored in the pos array and recalled when needed. This was very simple to manage, rather than changing each single value in the main function.

To control the LEDs we wrote a separate function, recalled together with the servomotor movement.

At the beginning we put the LEDs on two PWM pins: this is because we needed the lights to fade to give a more realistic footstep impression. The “ledOnOff()” function fades out the already active LED and fades in the other LED at two different speeds: the fading out is longer than the fading in.

You can download the full code in the downloads section.
_

To control the hand-crafted projector in a “friendly” way (not using the Arduino Serial Monitor), we prepared a graphical mockup that helped also to understand how this projector should work. We made it in Processing to communicate easily with the Arduino board (after the animated_footsteps sketch is uploaded to the Arduino board, you don’t need to run Arduino software on the computer, Processing makes everything!).

When the “person” is in a particular point of the alley (the “sotoportego”), it activates the projection. The mockup draws an halo on the person when it is in this activating area, and shows the part of the floor on which the projector will project.

The code checks where the person is and was (this double-checking is to avoid false inputs). When it is in one of the activation areas, it writes ‘32′ on the serial port, that is like ’spacebar’ in the Arduino Serial Monitor. If “animated_footsteps” sketch is uploaded on the Arduino board, this input will activate the footsteps projection. The double-checking of “personWasInActiveArea” and “personInActiveArea” let Processing send just one input (and not more).

The rest of the code is just visual mockup, drawing the background, the person and its behaviour.

For more about sounds in Processing click here.

For more about how the communication from Arduino to Processing works click here.

You can download the full code in the downloads section.

Routes | Concept | Experience | Prototype | Technology | Code | Early Experiments |
Critical Reflection | Downloads | Credits