Design of the Cat Toy Base

Here is an update regarding the design of the base for the cat toy that I have been building for my Introduction to Physical Computing final project. This post is a long time coming - I planned to post this information several weeks ago but was forced to wait due to the general workload surrounding finals.

Unfortunately, I was not able to finalize this project by the end of the semester due to issues that I encountered with the stepper motors, and creating a system of gears and pulleys that are able to move the cat toy structure (I've already created a post with information regarding the stepper motor-related issues, I will review the issues encountered when creating the gear and pulley systems here). That said, first let's take a look at the design for the cat toy base.

The Design of the Cat Toy Base
When I started working on the design for this device I envisioned using an existing cat scratching post as the base for my creation. This was an ideal solution since these toys feature a strong base that can withstand the tug from cats. Unfortunately, I did not find any existing products in a form factor that can work with my vision of this toy.

Once I realized that I had to create my own base structure, I decided that I wanted to build it using recycled materials. Considering how much Sasha likes cardboard scratching posts and the amount of cardboard boxes that are discarded in NY, I decided to use cardboard as the primary material for the base. The main considerations that drove my design included: allowing sufficient space to house the arm, laser, speaker, and proximity sensor; creating a shape that would appeal to the cat and allow for easy scratching; and making sure that the base was stable enough to withstand a beating from Sasha.

Here are a few important notes about the sketch designs featured below: first off, the light brown areas illustrate the internal compartment of the toy base where the chips, sensors, and motors will be stored; secondly, the two protruding structures at the top of the base will hold the toy wand and the laser; lastly, for the initial version of the toy I have decided to remove the cat laser (this will of course be reflected in all future pictures related to this prototype).



The Structure that Supports Movement
The biggest challenge I have encountered in developing this prototype is designing and building the mechanism of motion for the wand. Once I was able to get the motors working properly (which was a challenge in and of itself), I started working on finding a solution for the structure that would hold the wand, and for transferring the motion from the motors to move the wand.

After a considerable amount of research I decided to purchase an erector to create the structure for the wand. The specific set that I purchased is pictured here. This is a great solution because the parts in this set can be easily combined and recombined to created a strong structure that supports different types of movement.

Finding a solution for the gear and pulley mechanism was much tougher. The first challenge was to understand how gears and pulleys work together, so that I could design a system and find the appropriate parts. After doing some initial research, I decided to use Lego Mindstorm gears to build my initial prototype. Unfortunately, this approach did not work because the gear connection to the shafts was too loose, especially after the motor heated up.



After talking to some colleagues at ITP (thank you Michael K), I realized that what I needed was gears with hubs and set screws similar to the one featured on this page. These types of gears can be fastened securely to shafts of slightly varying thickness. SDP-SI has by far the largest selection of gears and pulleys on the web. Unfortunately, these components are not cheap.

The solution that I ultimately selected was to purchase a set of gears from Eitech that is compatible with the shafts from my erector set. The Girders and Gears website was a great resource that helped me find this solution. This site features useful information about various types of building sets and related gears and pulleys. Unfortunately, I have not yet had a chance to test these new gears. I plan on doing so as soon as I return to New York in mid-January.

One additional approach that I considered was creating my own gears, using a 3D sketching program and a laser cuter. Here is a link to step-by-step instructions for designing and producing custom gear sets.

Creating a Collaborative Storytelling Experience

As luck would have it, I was assigned to present in Red's Application class during the last week of school. Needless to say, I was dreading having to juggles multiple final projects with this important assignment. This anxiety was only heightened by the stories of suffering from many of the groups that preceded us.

Now that I have lived through this insanely busy time I am happy to report that I thoroughly enjoyed working on this project. It gave me a chance to collaborate with an awesome group of people, we were provided with the opportunity to respond to a very interesting speaker, and we were able to create a fun and collaborative way to end of semester.

Our task was to create a response to Jake Barton's presentation, which focused on collaborative storytelling installations and projects. Here is a link to my detailed notes from this class. To get started working on the presentation we met right after Jake's presentation. We quickly settled on a general direction - creating a collaborative experience that engaged the entire class in a storytelling exercise.

Development and Execution of Installation


After meeting with Todd and holding some additional brainstorm sessions, we decided to focus our response on creating a platform for first-year students to contribute their ITP stories for the development of a meta-narrative. After additional discussions we decided to keep things low-tech, and to limit the activities to the time and physical space of the class itself (we did not want to give other student's "homework" during finals).

The design of our installation was focused around a physical timeline, to which students would add their own stories using stickies or by drawing directly onto the surface itself. To inspire our peers we added a few initial elements to the timeline and we created a video featuring work from first-year students developed throughout the semester. Below you will find a short video overview of our development process, along with the video we developed for the event itself, and some pictures from the event.

Video Featuring Work from 1st Year Students


Pictures from Collaborative Storytelling Event

Creating Movement for the Cat Toy

Over the past couple of days I have struggled in my attempts to set up a stepper motor. Late last week my struggle continued as I tried to set-up three new stepper motors that I received for the cat that I am building. Having come home defeated I decided that the best course of action was for me to do some research regarding how stepper motors work so that I can improve my understanding and conceptual model of this component.

In the last hour I have discovered two really good overviews of how steppers work. The first is Mike Cook’s overview on his instructional blog; this is the second time that I link to Mike’s blog, he has a lot of great content for beginner's like me. This tutorial helped me finally understand how the coils are arranged and organized within the motor and how the stepping sequence is able to move the motor rotor through different positions. In retrospect it all seems obvious.

Another website that has content that is worth checking out is stepperworld.com. The tutorial here does not provide as thorough an overview of the inner workings of stepper motors. However, it does a better job at providing guidance for figuring out the proper wiring sequence of a stepper motor.

So what the hell did I learn about the topics mentioned above? Here is a brief overview but for more in-depth information check out the two links above.

Structure of the coils inside the motor
The coils in stepper motors are wrapped around a structure that surrounds the rotor. The number of times that the coils are wrapped around the rotor determines the number of steps required for the motor to make one full rotation. For example if the coils are wrapped around 48 times, then the motor would take 48 steps to complete one full rotation. Here is an image from Mike Cook’s site that illustrates this design.

To move the motor the coils are energized in sequence. Motors can be used in two different modes: full-step and half-step. When two coils are energized at any given time the motor moves in full step, which provides greater torque but less precision. When the motor is energized one coil at a time it provides greater precision of movement (twice the number of steps per rotation) but less torque. Here is another image from Mike's blog that demonstrates how full-step movement works.

Now that I understood how stepper motors work, I had to figure out the proper step and wiring sequence to get the motor to work properly. I started by re-checking all wire connections to ensure that I attached the leads from the motors to the appropriate control pins (via the transistors) and power source pins. This was a good thing because I realized that I had attached one of the power wires to a control pin.

Once I the wiring was set-up properly I was still experiencing issues with the stepper motors. They would turn on and spin for 10 to 20 seconds, then they would stop working. I met with Xiaoyang, one of ITP's residents, regarding this issue. He recommended that I test the power source voltage and amperage. The motor’s rating is 5 volts at 1 amp. Based on Xioayang’s advice and my research online, I decided that I needed to find a power source that delivered twice the current required by the motor.

I purchased a 2 amp transformer from Radio Shack that can be set to output between 3v to 7v. It is a great little tool, and it brought my motors to life! I was dancing around the table when this happened. It seems like I may actually be able to bring my cat toy to life. My next challenge was getting multiple motors to run smoothly together smoothly. The code samples that I've found and the stepper motor library are not appropriate for controlling multiple motors - more on this on my next post on this subject.

[note: most of this post was written during last weekend on December 4th]

Wholesome Harry - No Good Very Bad Day

Earlier today I worked with my team to edit and finalize our short movie for Comm Lab class. I am excited to report that Arturo, Eric, Tamar, and I have a finished our short movie – Wholesome Harry No Good Very Bad Day.



We have been working on this project for the past three weeks. During the first week we focused on coming up with an idea, developing a storyline and creating storyboards (regarding this part of the process). On our second week we produced and shot the footage at my wife’s school. Finally, this past week we focused on editing the footage into a short movie.

My focus in this post will be the activities from the past two weeks – the production of the shoot and the editing process.

Producing the Shoot
Once we finished the storyboards and shot list our focus shifted to finding a location, enlisting actors, and getting the on- and off-screen materials for the shoot. We started working right away because we did not know when we would be able to shoot, so we wanted to be ready at a moment’s notice.

The original location that we scouted for our movie was the TV studio on the 12th floor of the Tisch building at NYU. Unfortunately, we were not able to get the studio so we shifted to plan b – using my wife’s classroom at Grace Church School for the shoot. We felt this location was a good choice because a local access TV show for children could easily be filmed in a public school.

The props for the shoot were mostly easy to come by. Arturo has a large selection of costumes from his own performance works. Most of the other props were from ITP (the crew’s equipment) or found on location at the school.

From an equipment perspective, we experienced quite a few challenges. First we arrived at the Equipment Room to find all of the non-HD Panasonic DV cameras with broken firewire connections. As a consequence we used HD cameras instead. This is not a bad thing per se, however, none of us were familiar with these cameras and they had fewer manually controllable features.

Our second challenge occurred during the shoot. The M-Audio recorded that we were using was not working properly. Therefore, we had one less audio source to work with. This could have been a much bigger issue. Fortunately, for the most part we were able to get good audio from the cameras.

Here is our full equipment list – as you can see it is quite long and extremely heavy (the equipment, that is).

• 2 cameras (DVX)
• 2 DTE
• Extra battery and/or plug-in for DTE
• 2 firewires
• 2 boom mics
• shock mount
• XLR cables
• 2 tapes
• 1 M-Audio
• 1 bi-directional
• 1 tri-pods
• 1 lighting kit (3 lights, 3 tripods, 2-3 umbrellas, cables)
• Headphone
• Extension chords

The shoot lasted for about 5 hours. We arrived at the location around 4:30; it took us about an hour to prepare the room by moving furniture, hang the billboard and set-up the lights. The shoot itself lasted about 3 hours and then it took us 45 minutes to clean up. At the end of it all we had captured over an hour and fifteen minutes of footage. The quality of video was pretty good, though we noticed some continuity pitfalls that we needed to watch for during the editing process.

Eric and Tamar took the lead on the camera (though we all shot for at least a few minutes). Arturo and I took the lead in front of the camera. Arturo’s experience working with video came in handy. He has a good intuition for capturing small and unique shots that I would not have thought of until the editing phase (when it is too damn late).

Editing the Footage
The day after the shoot Arturo, Tamar and I transferred and logged the footage. We also took this opportunity to set-up a project in Final Cut in preparation for the work ahead of us. Since we had been forced to use the HD camera (and since we had an HD-philiac in our group) we decided to make an HD video.

During the week Arturo and Tamar put together a rough cut of the initial scenes. Then we all met on Sunday to finalize the rough cut and take out sandpaper to smoothen it out. The process of working in Final Cut with Arturo and Eric was great. They are both very knowledgeable about this tool and were eager to provide tips. I am currently working on another project in Final Cut and look forward to applying my new knowledge (soon to be transformed into skills).

Having worked with Final Cut 7 over the past two weeks I am impressed (negatively) at how complex it is to use. I guess I’ve become too accustomed to the ease of use offered by iMovie. The file import process and the difficulties associated to working with movie files with different formats have been quite frustrating. I understand the additional power that Final Cut provides – I am finally starting to be able to take advantage of it. That said, I think this tool could be simplified.

[Regarding Final Cut – I am currently working on a post regarding using Final Cut Pro, I’ll update this blog post with a link once it is ready.]

Course Selection for Spring Semester

It is hard to believe that it is already time to register for next semester's classes. I have an appointment with my advisor this afternoon to discuss my initial course selection. In preparation for this meeting I selected my 10 course choices, which I have listed below.

The way the process works here at ITP is that each student selects their top 10 course choices. Once all students have received approval on their course requests from their advisors, the process is turned over to an evil or benign algorithm (depending on who you ask). This algorithm determines who gets into which class.

My Top 10 List

1. Dataflow Audio Programming
2. The Softness of Things
3. Nature of Code
4. Social Facts: Motivation
5. Big Games
6. If Products Could Tell Their Stories
7. Design Expo
8. Spatial Media
9. Exhibit Design: NY Hall of Science
10. Mechanisms and Things That Move

I am extremely excited about each one of these possibilities. It was hard to choose the 10 most appealing courses because the course offerings are diverse and amazing. I'm happy that I still have three semesters left to take advantage of many more course.

Monome Madness

For a long time I have wanted a Monome (check out the Wikipedia entry here). Initially, my desire to own one of these devices was based on the functionality it provides and its minimalist look, which oozes cool. I was thrilled at the beginning of this semester when Paul Rothman, one of my colleagues at ITP, took the lead on organizing a group of students to build Monomes.

The initial excitement continued to increase during the past several weeks. It reached a highpoint this week with the recent arrival of the components and the gradual arrival of these devices on the floor. I can’t wait for my build session that is scheduled for Saturday. I will assemble a “40h” unit that is similar to the one described here, though it will feature a different case.

The other factor that has greatly heightened my anticipation for the build was tonight’s visit from the Monome creator, Brian Crabtree. Brian's partner in crime, Kelli Cain, was not able to join this session. Here is a short video from Brian’s visit. I’ve captured part of his talk along with two short demos of the Monome in action.



Learning about the motivation and creative process associated to the design of the device and the production process was inspiring. The product and process are both manifestations of the value and belief systems held by Brian and his partner Kelli Cain. First and foremost, this product was born out of the desire to provide new possibilities for creativity through freedom. That is why it is an open source platform that has no pre-defined functionality.

The designs and prototypes, and later the machinery required to manufacture these devices, were developed with no help from corporate organizations. Equally important, local production partners are used to manufacture the Monome, and selection of these partners has been guided by a socially and environmentally conscious philosophy.

In my opinion Brian and Kelly are true artists. They have brought (and continue to bring) into the world amazing new possibilities on many different dimensions – the product, the process, the freedom, and the passion. That’s enough praise since I know I am starting to sound cheesy (as if I that was not the case already). I'll just reiterate once again - I am officially inspired. I know that many of my future projects will include this little box as a key interface element.

Starting to Learn Max/MSP

Earlier today I attended a Max/MSP tutorial run by one of my colleagues at ITP, Matt Ganechau. This one-and-a-half hour session was awesome. We went through the basic concepts that serve as the foundation for this programming environment, and then we developed our first Max patch – a simple 8-step sequencer. Here I will provide a brief overview of the main concepts that we covered along with a short video that features the sequencer I created.



Max/MSP is an object-oriented dataflow programming environment that enables artists to quickly and easily create prototypes. This language was created over 20 years ago to facilitate the creation of sound and music. One of its coolest features is that it includes powerful help functions that enable inexperienced users to quickly get up and running once they understand the following base concepts.

Objects in Max encapsulate functionality that can be re-used easily. Examples include dials, sliders, counters, etc. As in other OOP languages, users can create their own objects (called patches) that encapsulate additional functionality. Objects are identified by a green border and can be easily added to a program using a drag and drop interface. Once an object is added to the program, the user types in the object name to assign the object the desired functionality.

Objects in Max have nodes that are inlets and outlets. These nodes enable objects to connect to other objects. Inlets accept input, while outlets deliver output. When a user hovers over a node the Max environment will show a list of the possible objects and actions that can be connected to that node.

Aside from objects, Max/MSP also features messages. Messages transmit information between objects in Max and they can be integer and float values (there may be other types of messages that I have not explored yet).

Another important concept in Max is the “bang”. Everything in Max operates in response to bangs. Bangs are similar to pulses in an electric circuit, such as the Arduino. When a bang is initiated it goes through the system and activates sound and other activities.

Patches (or programs) can be locked or unlocked. Locked patches are in their performance state. In this mode the user can only interact with the patch as an interface – for example they can interact with sliders, toggles, etc. When unlocked the patch can be edited like a computer program.

The inspector enables developers to change the parameters of objects and programs. For example, on a slider object the programmer can change the range, color, and many other attributes. As expected the attributes and options available differ from object to object.

Interactive Cat Toy - Defining Requirements - IPC Final Project

On last Thursday I had a brief meeting with Tom to talk about my final project. Per my previous posts on this subject, I have decided to create an interactive cat toy. Over the past several days I have been working on the design of this device so that I can identify what parts I need to order. Here is a brief update regarding my toy concept, the new solutions and problems have arisen, and what components I am considering for this project.

Updates to the Concept
For the most part my cat toy concept has remained unchanged. The focus of the design is still the situated interaction between a cat and human and the main components have remained unchanged - the human participant will use an arcade-like joystick to control the laser, the sound and the arm. The cat will interact with these three elements of the toy.

Here is a quick overview of the changes that are under consideration: first, I would like to add an auto mode to this device to enable a cat to interact with the toy without human participation. The toy’s arm would self-activate and move randomly anytime it senses motion within a 40-cm distance. Second, I would like to create a game for the human participant when s/he is engaged with the toy. This will be a much bigger challenge that will likely not be addressed in my initial prototype.

New Solutions and Problems
Switching between modes: I have made a conscious attempt to limit the number of virtual modes provided by this device. For example, I have attempted to design this toy so that each joystick controls only one element of the toy. That said, the following modes will still exist in my design:

• On and off modes – as with most electronic gadgets, this cat toy will feature on and off modes that will be controlled by a rocker switch on the base of the toy.
• Interactive and automatic modes – as discussed in the “updates to the concept” section above, this toy will feature a secondary operation mode where it will sense and react to a cat’s presence/proximity. Control will be governed by a switch on the joystick controller.
• Game and freestyling modes – if a game-like element is added to the human participant’s interaction in the future, then we will want to provide the option for cat owners to select between a game and freestyle mode.

Controlling the sound: Earlier today Arturo, another cat lover from ITP, brought up an important consideration that I had previously ignored. Cats are sensitive to sound; this realization previously led to my decision to add bird sounds this device. However, I had not considered that the other side of this coin: cats are easily turned off or scared away by sounds. Therefore, I need to make sure to find a quiet motor for this toy so that it does not scare away cats.

Earlier today I carried out a small experiment to observe Sasha’s response to the servo motor’s sound. Check out the short video below for a quick overview of my observations.



Proximity sensing: In order to add the automatic mode that I envision for this device I need to find a proximity sensing solution. My main requirement is that this solution needs to enable the toy to identify when a cat passes a certain threshold so that the appropriate functionality can be activated. Per this description I only need a digital, rather than analog, solution.

Finding the Right Parts
Considering my goal is to have an initial working prototype by early next week, I have started to identify the specific components that I want to use on this project. Some of these items I have already ordered, while others will be ordered later this week once I decide what is the best option. Here is an overview of the selection process.

Movement and Motors
To move the arm and laser pointer I originally considered using servo motors. However, due to concerns regarding the sound generated by these types of components I am now leaning towards using stepper motors instead. I carried out a good bit of research to find a servo motor that is silent, unfortunately, this does not seem to be a coveted feature for these types of motors. Here are some of the best sources for servos that I found online – robotshop and servocity.

Another consideration regarding the movement of the arm and laser beam, is the need for a mechanism that supports both panning and tilting. I was able to find a few pan and tilt mechanisms for sale on the servocity website. These options seem robust and only a bit expensive. That said, since I have decided to use a stepper motor I will need to find other options or create my own.

Control and Switches
For the controller I have purchased the most important components – the joysticks and buttons. Where possible, I chose components that have an arcade-like or video game feel. Here is an overview of my selections:

This component has a great arcade like feel. It will be the main joystick on the controller and it will govern the movement of the arm with feathers. Cost and size considerations have led to my decision not to use this joystick for controlling the laser.

This small PS2-like joystick will be used to control the laser pointer. This joystick also incorporates a push button that will be used to turn on and off the laser device. The small size of this joystick denotes the secondary priority of this interaction element in comparison to the arm.

This light blue arcade-style button will be used to trigger the bird sounds. I have purchased 4 buttons in total, so that four separate sounds can be included in this prototype.

In regards to generating and controlling the sounds, I had originally planned to use one of the following two components: the WaveShield from Adafruit or the MP3 Trigger from Sparkfun. That said, based on advice from Tom (and my desire to minimize additional costs associated to building this prototype), I have decided to use my computer to generate the sound in the initial prototype. If all goes well with the user testing (or should I say cat testing) then I will likely add one of these components to the toy so that a computer does not need to be used.

To sense the cat’s presence/proximity I have decided to use a Sharp infrared range finder. This little component can sense ranges between 3 and 40 cm. It is ideal for my requirements because I plan to use this sensor for threshold detection within a small range only. It is much cheaper than the ultrasonic range finder options.

To turn the device on and off I plan to use a rocker switch similar to one pictured below from Sparkfun. To toggle between interactive and auto modes I will use a slide switch similar to the one from RadioShack that is featured in the picture below.

Additional Considerations
One additional consideration that I have not addressed is how to keep this cat toy “fresh”. Cats are extremely finicky animals and often grow tired of their toys after about 3 to 4 weeks. As I move forward with the design and development of my initial prototypes I will be looking for ideas on how to address this concern.

New Possibilities
In typical fashion, before I have even really gotten started with my current cat toy project I am already considering many improvements, updates, and related products. Here is a brief overview of two ideas I will consider incorporating into this or future projects (though not by finals time).

(1) I would like to use the toy as a medium for a game between the human and the cat. Initial ideas range from simple to complex. On the simple end we could add a counter to the proximity sensor and time the length of the cats presence in that proximity. We could also add a sensor to the arm so that it could sense when a cat is able to grab one of its feather. On the complex end we could use a video camera and together with a projector and the laser pointer, and have the human moving the laser beam around in an attempt to guide the cat to catch falling birds (which would be projected on the wall). The computer vision would be used to read images from the video camera to determine when the cat was able to catch the falling birds.

(2) Rather than have a cat toy that attempts to woe the cat, create a cat toy that can move around the room and is controlled via remote. I would still envision this cat toy having a remote controlled arm, though this arm would likely be designed differently (for example, it would have a 360-degrees motion since it would not be positioned against a wall).

IPC Class Notes, Communicating Wirelessly - November 11, 2009

In this week’s Introduction to Physical Computing class we had a brief discussion regarding microcontrollers, followed by and overview of how to use serial communications via wireless, then we briefly reviewed final project ideas.

Microcontrollers
When designing our final project Tom stressed the importance of taking into consideration the different form factors of Arduino and other microcontrollers available for our projects. These include:

The Arduino Family
There are several Arduino form factors available, and all are based on an AT Mega chip set. the Duenovemille is the standard unit that we have been using to date; the Nano is another standalone unit that features the same chip in a smaller form factor with a reduced number of pins; the Mini and Mini Pro are other small form factors that are designed to be mounted to a breadboard and features a chip with a bit less memory; the Mega is a larger unit that features considerably more memory and a large number of pins; lastly, the Lillypad is a chip designed for wearable computing projects.

Funnel IO and Gainer
Funnel IO (FIO) is an Arduiono clone that features an AT Mega and is integrated with an XBee on the back. Developed by Shigeru Kobayasho, FIO was created to work with Processing, ActionScripting, Max/MSP, Gainer and Wonderfl. Similar to the Arduino, FIO was created to enable artists and designers to integrate physical computing into their projects. Please note that the content on the Gainer website is mostly only available in Japanese – that said, it can be entertaining to use Google translation to read through it.

Illuminato X Machina
A new addition to the microcontroller offerings is the Illuminato X Machina. This chip attempts to add more capabilities and power to the world of microcontroller, without increasing the complexity of the development environment. This chip has an interesting design that is based on a cellular network. It allows users to increase the processing power by setting up networks of microcontrollers.

Serial Communications Using Wireless
Serial communication protocols are used by a large variety of components, including RFID, displays, motor and sensor controllers, to name a few. Wireless modules, such as the Xbee, connected to computers and Arduinos using serial.

To date, all of our explorations into serial protocols have focused on asynchronous types of communications. In order to use the XBee we need to use synchronous communications instead. Below is a brief refresher on these two concepts. It is important to note that many wired components also work with synchronous connections.

Asynchronous Communications
In asynchronous communications the connected devices each have their own clocks and send messages back and forward in an uncoordinated fashion, from a clock perspective. It is important to note that a programmer can use a coordination mechanism, such as call-and-response, to manage the communications.

Devices that are linked for asynchronous communications share three connections: two transmit and receive connections (each one set to an alternate direction), and a common ground.

Synchronous Communications
In synchronous communications the devices share a clock and send their messages in coordination with the clock pulses. Networks of devices that are connected synchronously, always feature a master and a set a slaves. The master is the device that sets the clock for all others.

Devices that are linked for synchronous communications share four connections: a Master In Slave Out (MISO) connection, a Master Out Slave In (MOSI) connection, a clock connection, and a common ground.

Components that can use synchronous serial communication have a pin called Chip Select. This pin enables the master device to connect to multiple devices using a single clock, MOSE and MISO pins, as long as it is directly connected to each slave chips Chip Select pins. In these types of circuits synchronous serial devices will only communicate on the MISO and MOSI pins if the status of the Chip Select pin is properly set.

Back to the Xbees
When setting up an Xbee on an Arduino you need to use the serial transmit (TX) and receive (RX) pins from each device. This will enable information to flow to and from both components. On the Arduino IO pins 0 and 1 are the RX and TX pins. It is important to disconnect the Xbee when uploading a program via serial to your Arduino. The reason being, if the Xbee is connected to the serial port then the Arduino can’t use this port to connect to the computer.

If multiple Xbees are connected to the same multimedia computer (or master) then each one of the chips will have its own address. Messages can be sent to a single address, or can be broadcast to all Xbee devices.

To set up an Xbee you first need to set it up using USB. For this you will need a USB to serial adapter for the Xbee, which converts data from traditional serial protocols (TTL and R-232) to the appropriate USB protocol. The most common adapter used for this task is the Xbee/USB breakout board (also called XB explorers).

Xbees use the AT Command Set, which was originally designed to drive modem communications. This protocol is widely known, and has been used for a long time. There are two different modes of communications used in the AT Command Set (and most similar protocols for that matter):

• Command Mode: communications to the modem.
• Data Mode: communications through the modem.

There are two different types of Xbees. They are not able to work together because they have a different stack above the AT Command Set.

• Series 1 uses 802.14.5 command set. This protocol is more limited than the series 2 but it is also much simpler. It provides more than enough functionality for most types of uses and is the right way to go for most applications.
• Series 2 uses a command set that supports mesh networking. It is much more complex to use than series 1. Mesh networks are made up of devices configured as “controllers” (c), “routers” (r), and “end-points” (e). The “routers” essentially act as post office boxes that hold and distribute messages to the end point. Since the end points don’t always have to stay on this is a more energy efficient system.

When you first connect an Xbee the device is in data mode. In order to enter into command mode you need to use a variation of the standard AT Command Set protocol: “+++” (rather than the protocol standard of “+++\r”). Here is an of the options that you need to set-up in order to get Xbees to start talking politely:

• Address of Xbee chips (destination)
• Address of multimedia computer (source)
• Pan ID that enables to join Xbees into groups, so that different groups of Xbees don’t conflict with one another. Check out the pan ID list available on the Physical Computing website at ITP to select an unused port.

To get two Xbees to talk to one another without including an Xbee attached to a multimedia computer the Xbees need to be set to API mode. This mode uses a totally different protocol that is not based on the AT Command Set.

When using Xbees it is advisable to use a handshake (call-and-response) method so that we don’t encounter delays associated to buffer issues. When using multiple Xbees the handshake logic of the code is the same as the example we previously explored in class, for the most part. The difference is that we need to add logic on the receiving end to confirm where the data was sent from, and to determine where to send the next request.

Bluetooth
Bluetooth is another wireless protocol that is often used for wireless communication. However, Bluetooth only supports one to one communications, so all Bluetooth devices can be connected to a multimedia computer only and not to one another. Bluetooth also sets up sessions when they connect with a device, which requires a few seconds for initiation and closing a connection.

Interactive Cat Toy Competitive Research - IPC Final Project

Over the weekend I decided that my final project for the Introduction to Physical Computing class would be a cat toy. I have wanted to design cat toys and furniture since before I came to ITP; I will even admit that I am a cat video offender. Nonetheless, this is the perfect opportunity for me to stop talking about wanting to create a cat toy and start actually doing it.

To start off the design process I did a bit of research regarding cat toys, focusing my attention on any interactive electronic offering I could find. I started off by looking at several previous projects from ITP, then I looked at commercial toys. Here is an overview of what I found:

Previous Cat Toys from ITP

The Hanimustv by Aram Chang
The Hanimustv is a cat toy that was developed as a thesis project for last year. It is a “peek” and “hide” game that is controlled by a small remote control with arcade-style buttons. Small wooden cylinders are raised out of a box in response to button presses on the remote. The cylinders return to their original position once the button is released.

From a technology perspective, this cool toy uses an Arduino connected to buttons that controls a set of solenoids, which move the cylinders. Check out this cool user test video - the users testing the toy were of course cats, rather than humans.

Toy characteristics:
- Interactivity between cat and human
- Movement of physical objects for cat
- Physical controls for human

The Meowzer by Gordie and Emily
Another ITP cat toy that I discovered is called Meowzer; it was developed last spring semester by Gordie and Emily. Meowzer has a rotating top part that holds five arms. Four of these arms have dangling strings that hold small fluffy cat toys (one of which has a laser light). The fifth arm holds a small bunch of feathers and is the only one that can move up and down. The toy is controlled by an application that runs on a laptop computer.

From a technology perspective, this toy uses an Arduino that is connected to the following main components: DC motor that rotates the top part; Servo motor that moves the fifth arm up and down; and a laser light attached to one of the cat toys, in the mouth position. The application that controls the toy was developed in Processing.

Here is a link to the documentation about this project from Gordie’s blog. The documentation is comprehensive and features a nice video of the finished product.

Toy characteristics:
- Interactivity between cat and human
- Movement of physical objects and light for cat
- Virtual controls for human

Unnamed Toy by Patrick Proctor
The last ITP-developed cat toy that I found was developed by Patrick Proctor for our Introduction to Physical Computing class. This toy was designed to enable two cats to interact. It essentially features two separate toys that are connected. The first toy is a tennis ball on a metal spring that is secured to a wooden base; the cat plays with it by batting the ball around. The second toy is a laser pointer that moves from side to side; the cat plays with it by following the laser light reflection on walls. The movement of the laser pointer is partially governed by interactions with the tennis ball.

Here is a link to a blog post from Patrick where you can find pictures and an overview of his project.

Toy characteristics:
- Interactivity between cat and cat
- Movement of physical objects and light
- Physical controls for cat (or human)

Consumer Cat Toy Examples

Here I will focus my exploration on electronic cat toys only. That is not to say that old-school cat toys (such as plush toys, scratching pads, crinkly balls, laser pointers, shoe laces, etc) will not serve as part of my inspiration for this project. Ultimately, I want to create an electronic cat toy that rivals the interactivity provided by a stick with a piece of shoelace tied at the end, which to this day remains Sasha’s favorite toy.

Run Rascal
This is the only cat toy from the bunch that I have personally owned. It is a remote controlled mouse. My cat, Sasha, liked this toy well enough. The only problem we encountered was that the mouse is not able to run on carpets, which is where sasha likes to hang out the most. It is definitely the most interactive electronic cat toy that I have seen on the market.

Toy characteristics:
- Interactivity between cat and human
- Movement of physical object for cat
- Physical controls for human

The electronic toys listed below offer minimal or no interactivity. That is not to say that they are not much enjoyed by cats.

FroliCat Bolt
This is a relatively new cat toy that is relatively simple. It amounts to a laser light mounted in a well thought out container that moves the laser around a room. The laser moves based on the movement of a reflective mirror, rather than the movement of the light source itself. This toy offers an interesting mechanism, though it is not truly interactive (unless you hold it in your hand and use it like a traditional laser pointer).

Toy Characteristics:
- Movement of light for cat
- Limited interactivity provided

Mouse in the House
This is a cat toy that looks like a small diorama of a living room and features a track on which small toy mouse runs. The timing of the appearance of the small mouse can be programmed to enable the toy to entertain unattended cats for long periods of time. For the most part the toy seems to appeal to cats, though pet owners complain about the loud noise of the motor. Though this toy does not provide direct interactivity, it does offer the toy owner the ability to program the frequency of the mouse movement.

Toy Characteristics:
- Movement of physical object for cat
- Limited interactivity provided

Comm Lab Video Project - Storyboard Development

Earlier today I worked with Arturo, Eric, and Tamar to develop the concept and storyboards for our Communication Lab class. We met up this morning at eleven in a coffee shop near the ITP floor. After brainstorming for 30 minutes we created a long list of possible inspirations for our story. Here is a link to a more readable version of this document.

After developing this list we identified a few main themes and explored many different storylines. We settled on the idea of creating a video that captures a news program host going ballistic. We were loosely inspired by Bill O'Reilly's famous freakout - I can't believe that I am admitting to being inspired by Mr. O'Reilly.



After developing the general arch of the story we headed back to the ITP floor to collaboratively draw the storyboards on the large rolls of paper from the studio. Here is a picture of our finished work (follow this link to view a more readable version).

ICM Class Notes - Using PHP - November 5, 2009

In today’s ICM class we reviewed basic concepts associated to PHP, and discussed when to use PHP (as a stand alone solution, or in conjunction with Processing).

PHP – Hypertext Pre-Processor Language

PHP was designed for server-side scripting – for development of applications that run on servers. In contrast, Processing (and Java on which it is built) was developed for client side applications – for development of programs that run on client-side computers. Originally designed to serve dynamic web content. In short, PHP enables us to store and capture information from a server more effectively and efficiently than Processing.

Here is an example of an application where PHP is used to store data for a Processing sketch. This code was written by Dan Shiffman, my professor at ITP, and it features a shared white board, where users can add new coordinates that can be viewed by all other users (anyone can also clear the board). PHP can also be used to develop a multi-user high score feature for a game developed in Processing.

How to Run PHP?

In order to run PHP you need a server or computer that is properly set-up. Most web servers support PHP, though the ones that are based on Microsoft solutions tend not to. That said, even servers that support PHP need to be properly set-up. Luckily for us, the ITP server is already set up for PHP. Many desktop and laptop computers can also be set-up to run PHP scripts.

PHP code is usually embedded in HTML documents. To embed PHP code into an HTML document the following identifiers are used: “” ends a code block. It is important to note that PHP code will not be present on the HTML source available via web browers. The reason being, the PHP code on the server is used to dynamically generate the HTML code that is sent to your computer, and viewable as source.

The Basic Elements of Coding – PHP Style

The basic concepts associated to PHP coding are similar to those used in Processing. PHP is an object-oriented language that features all of the same attributes: variables, conditionals, loops, functions, classes, etc. Here is a quick overview of some basic similarities and differences between these two tools.

Primitive Variables

All variables in PHP need to be defined/initiated by being assigned a value. To identify a variable the variable name needs to be preceded by the “$” character. However, unlike Processing, PHP does not require or support the typing of variables. This is a more flexible approach than Processing but it also opens the doors to more mistakes not being caught by the compiler.

Example variable definition code: “$ x = 5;”

Arrays

To make an array in PHP you just assign an “array(arrayElements)” to any variable name. As with primitive variables, there is no need to define the array type. To add elements to an array is simple simpler than in Processing, as shown below. It is important to note a PHP array can also hold different types of data.

• Creating an array: “$arraySample = array(0,1,2,3);”
• Adding an element to an array: “$arraySample[] = 5;”

PHP also supports associative arrays as well. These arrays indentify each data element by a name as opposed to an index number. These arrays can be used in interesting ways. They are available in Processing through Java.

• Using an associative array: “$arraySample[“fred”] = 50;”

Conditionals and Loops

The syntax for loops and conditional statements is identical to that found in Processing.

Functions and OOP in PHP

In PHP to define a function it name needs to be preceded by the identifier “function”. Similar to variables definitions, functions are not typed. Class definitions feature the same overall structure, though the constructor name is identified as “function _constructor()”. When working with instances of objects the “->” in PHP replaces the “.” in Processing.

Query Strings

Query string refers to HTML urls that reference PHP scripts and contain information that can be processed by the PHP script to dynamically generate content (HTML or other text-based documents). Since PHP primarily runs on web servers, this is the main way in which information is passed to PHP scripts. Here is an example where the identifier “name” contains data element “Julio”, “nationality” contains “brazil”, and “residence” contains “nyc”.

“http://……sample.php?name=Julio&nationality=brazil&residence=nyc”

Online, these query strings are most often used to transmit data captured from users via a web forms. Processing applications can generate query scripts that both request data and initiate other activities on the server side.

Reading Query Strings

To read values from query strings an associative array is used. PHP creates an associative array that pairs each identifier from the query string (which is always consistent) with a data element (which is variable). This array is called $_GET. Here is a sample line of code to read my name from the query string above into the variable $name:

“$name =$_GET[“name”];”

PHP Resources

• w3schools PHP tutorials
• PHP organization website
• Dan Shiffman's PHP tutorial

Miscellaneous

• Dan shared with us Coda, a development environment that enables programmers to access and edit PHP and HTML files on the server. Coda is a text editor and ftp application combined in one.
• In today’s class we got to see Josh K’s project, a sketch that generates a line that evolves in a 3D space using the principles of Perlin noise. It is a great looking visual, unfortunately, he has not yet posted the sketch online.

Media Controller Project (and ICM Mid Term) - Phase 3

During that last several days I have been working on setting up a Processing sketch that can work with my Physical Computing media controller and serve as my mid-term project for the Introduction to Computational Media course. Long before arriving at ITP I have been interested in the design and development of media controllers. This project provided the opportunity for me to start some hands-on explorations.

In my previous post I already discussed the process for choosing the solution for playing and controlling our audio – we have decided to use Processing (and the Arduino) to control Ableton Live. Today I will provide an overview of how I developed the code for this application and some of the interface considerations associated to designing a software that could work across physical and screen-based interfaces.

My longer term objective is to create MIDI controllers using for audio and video applications using touchscreen and gestural interfaces. The interfaces that I am designing would ideally be evolved to work on multi-touch surfaces. In regards to my interest in gestural interaction, this I hope to explore through my current physical computing project and future projects.

Developing the Sketches
Since the physical computing project requires three basic types of controls that are the foundation of the media interface for my computational media mid-term, I decide to start with a focus on writing the code for these three basic elements. I set out to create code that could be easily re-used so that I could add additional elements with little effort. Here is a link to the sketch on openprocessing.org, where you can also view the full code for the controller pictured below (v1.0).

The process I used to create these sketches included the following steps: (1) creating the functionality associated to each element, separately; (2) creating a class for each element; (3) integrating objects of each class in Processing; (4) testing Processing with OSCulator and Ableton; (5) creating the Serial protocol to communicate the Arduino; (6) testing the sensors; (7) writing the final code for the Arduino; (8) testing Serial connection to Arduino; (9) calibration of the physical computing interface (whenever and wherever we set it up).

I have already made two posts on this subject (go to phase 1 post, go to phase 2 post), however, today I can attest that I have completed the vast majority of the work. The last processing sketch that I shared featured a mostly completed Matrix object that included functions for OSC communication. The serial communication protocol had also been defined.

The many additions to the sketch include creation of button and slider elements (each in its own class), a control panel (that holds the buttons and sliders), and a version of the application that features multiple button and sliders. The main updates to existing features include changes to Serial communication protocol to support additional sliders and matrices), and OSC communication code updates to ensure that messages are only sent when values change rather than continuously.

For the slider object I used the mouseDrag() function for the very first time. I had to debug my code for a while to get the visual slider to work properly. The button was easy to code from a visual perspective. The challenge I faced was in structuring the OSC messages so that I was able to send two separate and opposing messages for each click. The reason why this is important is that Ableton Live uses a separate buttons for starting and stopping clips. So I had to find a way to enable a single button to perform both functions.

The serial communication protocol update was easy to implement, so I will not delve into it here. To change the OSC communication protocol required a bit more work. I created a previous state variable in each object class to be enable verification of whether a change had occurred. The logic was implemented an “if” statement in the OSC message function.

Evolving the Controller
Here is an overview of my plans associated to this project: I plan to expand the current media controller with a few effect grids and the ability to select individual channels to apply effects. In order to do this I have to create new functions for the matrix class that enables me to set the X and Y matrix map values. I also want to work on improving the overall esthetics of the interface (while keeping its minimal feel).

From a sketch-architecture perspective I am considering creating a parent class for all buttons, grids and sliders. It would feature attributes and functionality that is common amongst all elements. Common attributes include location, size and color; common functionality requirements include detection of mouse location relative to object, OSC communication.

Questions for Class
Here is a question that came up during my development of this sketch (Dan, I need your help here). Can I use the translate, pop and pushMatrix commands to just to capture the current mouse location? This would be an easier solution to checking whether the mouse was hovering over an object.

Media Controller Project - Phase I

I recently began to work on a media controller project with two colleagues from ITP, Zeven Rodriguez and Michael Martinez-Campos. After much discussion, and our fair share of agreements and disagreements we have decided to develop an interface for music modulation. This device is going to be composed of a square horizontal surface coupled with a physical mouse-like object. By sliding the object across the surface, a user is able to modulate two attributes of the sound that is being generated.

Ideally, we would like to make the axis of this surface assignable (e.g. you could choose the effect/modulation associated to each axis). Also, it would be great if we could provide the user with the ability to play multiple sounds simultaneously, and to choose whether to control all sounds, or just a single sound with this surface.

That said, this project is being developed as part of our Introduction to Physical Computing curriculum. For our initial deadline 2-weeks from now we have decided to keep things simple; if we get things done sooner we may try to integrate some of these features.

To help get things done efficiently we have divided our roles and responsibilities. Zeven is taking the lead on creating the physical surface and object. Mike is working on investigating the solutions for the sound generation through Processing. I am leading the development of what I am calling the middleware - the application that gets the data from the sensors and feeds it to the program that will generate the music.

Creating the Connection (and a Virtual Grid/Surface)
Earlier today I finished the initial version of the processing application that will be responsible for reading data from the serial port, interpreting that data, and sending it onto to the sound generator. This is an important step in the evolution of this project, though I know that many updates will have to be made to this app during the coming weeks.

Pictures of Arduino Input for Test


One of the biggest challenges in creating this sketch was setting up the serial communication between the Arduino and Processing - we need to find a way to send data from two sensors to the computer. We decided to use the handshake protocol because it minimizes response delays.

Since I just learned how to use this type of protocol, it took me a little bit to get it working properly. Below I’ve included a brief overview of the issues I encountered along with the code I wrote for the Arduino, and a link to the Processing application.

Using the Handshake Communication Protocol
To set-up the handshake protocol, the first thing I did was to create a syntax for the communications. Unfortunately, that syntax did not work so I had to update it a few times to smooth out all of the kinks. Below I have shared the original and revised protocols.

• Initial protocol: “valueOne.valueTwo. \n\r” (e.g. “224.200.\n\r”). The new line and carriage return characters are appended by the println() function that I used to send data for the my first attempts.
• Final protocol: “valueOne valueTwo.” (e.g. “224 200.”). After numerous frustrating attempts to get the initial protocol to work, I decided to simplify the protocol as outlined above.

Another challenging issue that I encountered along the way was resolving the source of an “array out of bounds” error. After some investigation I realized that this error was generated within the function I created to read serial data. Upon further investigation I realized that I needed to confirm that a connection had been established with the Arduino before I starting to process the data that was coming in from the Arduino.

Once I understood the problem it was easy to fix. The solution was to add an “if” statement to check whether a piece data received by the computer is the first piece of data in the communication stream. I noticed that the code sample from this week’s labs features a similar solution.

Processing Sketch


Here is a link to the processing sketch that I developed (please note that I've commented out all serial communications related functionality in order for this sketch to run online). Below you will find the code for the Arduino.

Code for the Arduino

int analogPin1 = 0;
 int analogPin2 = 1;
 int analogValue1 = 0;
 int analogValue2 = 0;

 void setup()
 {
   // start serial port at 9600 bps:
   Serial.begin(9600);
   Serial.write('.');
 }

 void loop()
 {
   // read analog inputs:
  if (Serial.available() > 0) {

   analogValue1 = analogRead(analogPin1); 
   Serial.print(analogValue1, DEC);
   Serial.print(' ');

   analogValue2 = analogRead(analogPin2); 
   Serial.print(analogValue2, DEC);
   Serial.print('.');

   Serial.read();
  }
 }

Setting-up an Accelerometer - Success!

Earlier today I met with one of the residents at ITP to discuss the issues that I have been encountering with my 3-axis accelerometer (ADXL335). After meeting for a mere 5 minutes, Ithai informed me that the issue was likely being caused by the fact that I did not solder the leads into the breakout board. My initial instinct to NOT solder the header pins to the board in case the accelerometer was not working proved to be overly cautious.

Here are the charts featuring the latest data I collected from the accelerometer


The good news is that the accelerometer is now working, and I only pulled out a few hairs in the process. Now that this accelerometer is working I have a few additional learnings and resources to share with anyone working on hooking up an accelerometer. I hope these can help you get up and running without any hair pulling:

1. Make sure that you have soldered the pins to your accelerometer breakout board before starting to test.
2. Use the AREF pin on the Arduino to set the reference voltage to 3v and improve the sensor readings.
3. Use a running average of all readings or some other stabilization algorithm to help reduce noise from accelerometer readings.
4. Check out the code samples below for different ways to test your new accelerometer.
5. Whichever axis is in vertical position will have a different sensor reading due to gravity, even when resting.
6. The sensor for each axis is only able to alternate resistance by +-15%.

Code Sample 1 – As Simple as You Can Get

int xAxis = 0;
int yAxis = 1;
int zAxis = 2;
int zInput = 0;
int yInput = 0;
int xInput = 0;

void setup () {
  Serial.begin(9600); 
}

void loop () {
  xInput = analogRead(xAxis);
  delay (10);
  yInput = analogRead(yAxis);
  delay (10);
  zInput = analogRead(zAxis);
  delay (10);
  
  Serial.print("Inpu (xyz): ");
  Serial.print(xInput);
  Serial.print(", ");
  Serial.print(yInput);
  Serial.print(", ");
  Serial.print(zInput);
  Serial.println(".");
}

Code Sample 2 – Capture Base Readings and Then Report Difference from Base
This sample was developed by Andy Davidson, and taken from the Arduino message boards.

/* ADXL335test6
 Test of ADXL335 accelerometer
 Andy Davidson
 */

const boolean debugging = true;    // whether to print debugging to serial output
const boolean showBuffer = false;  // whether to dump details of ring buffer at each
read

const int xPin = 0;  // analog: X axis output from accelerometer
const int yPin = 1;  // analog: Y axis output from accelerometer
const int zPin = 2;  // analog: Z axis output from accelerometer
const int led = 13;  // just to blink a heartbeat while running

const int totalAxes = 3;  // for XYZ arrays: 0=x, 1=y, 2=z

const int baseSamples = 1000;  // number of samples to average for establishing
zero g base
const int bufferSize = 16;     // number of samples for buffer of data for running
average
const int loopBlink = 100;     // number of trips through main loop to blink led

// array of pin numbers for each axis, so the constants above can be chnaged with
impunity
const int pin [totalAxes] = {
  xPin, yPin, zPin};


// base value for each axis - zero g offset (at rest when sketch starts)
int base [totalAxes];

// ring buffer for running average of data, one for each axis, each with  
samples
int buffer [totalAxes] [bufferSize];

// index into ring buffer of next slot to use, for each axis
int next [totalAxes] = {
  0,0,0};

// current values from each axis of accelerometer
int curVal [totalAxes];

// count of trips through main loop, modulo blink rate
int loops = 0;



void setup() {


  long sum [totalAxes]= {  // accumulator for calculating base value of each axis
    0,0,0        };


  Serial.begin   (9600);
  Serial.println ("***");

  // initialize all pins
  pinMode (led, OUTPUT);
  for (int axis=0; axis
    pinMode (pin [axis], INPUT);    // not necessary for analog, really

  // read all axes a bunch of times and average the data to establish zero g offset
  // chip should be at rest during this time
  for (int i=0; i
    for (int axis=0; axis
      sum [axis] += analogRead (pin [axis]);
  for (int axis=0; axis
    base [axis] = round (sum [axis] / baseSamples);

  // and display them
  Serial.print ("*** base: ");
  for (int axis=0; axis
    Serial.print (base [axis]);
    Serial.print ("\t");
  }
  Serial.println ();
  Serial.println ("***");

  // initialize the ring buffer with these values so the averaging starts off right
  for (int axis=0; axis
    for (int i=0; i
      buffer [axis] [i] = base [axis];

  // light up the led and wait til the user is ready to start (sends anything on serial)
  // so that the base values don't immediately shoot off the top of the serial window
  digitalWrite (led, HIGH);
  while (!Serial.available()) 
    /* wait for  */    ;
  digitalWrite (led, LOW);

}



void loop() {

  //increment the loop counter and blink the led periodically

  loops = (loops + 1) % loopBlink;
  digitalWrite (led, loops == 0);
  // get new data from each axis by calling a routine that returns
  // the running average, instead of calling analogRead directly

  for (int axis=0; axis
    curVal [axis] = getVal (axis, showBuffer);
    if (debugging) {
      Serial.print (curVal [axis]);
      Serial.print ("\t");
    }
  }
  if (debugging)   
    Serial.println ();

  // here we will do all of the real work with curVals

}



int getVal (int axis, boolean show) {

  // returns the current value on , averaged across the previous  
reads
  // print details if  is true


  long sum;  // to hold the total for aaveraging all values in the buffer


  // read the data into the next slot in the buffer and stall for a short time
  // to make sure the ADC can cleanly finish multiplexing to another pin

  buffer [axis] [next [axis]] = analogRead (pin [axis]);
  delay (10);    // probably not necessary given the stuff below

  // display the buffer if requested

  if (show) {
    for (int i=0; i
      if (i == next [axis]) Serial.print ("*");
      Serial.print (buffer [axis] [i]);
      Serial.print (" ");
    }
    Serial.println ();
  }

  // bump up the index of the next available slot, wrapping around

  next [axis] = (next [axis] + 1) % bufferSize;

  // add up all the values and return the average,
  // taking into account the offset for zero g base

  sum = 0;
  for (int i=0; i
    sum += buffer [axis] [i];

  return (round (sum / bufferSize) - base [axis]);

}

Linda Stone - Continuous Partial Attention and More

Earlier today I had the opportunity to hear Linda Stone speak at an Applications of Interactive Telecommunications Technology class. Linda has worked in the technology industry for over 20 years, having spent time at some of the sector’s biggest and most innovative organizations, such as Microsoft and Apple. Most recently, her attention has been focused on the phenomenon of “Continuous Partial Attention”.

Continuous partial attention refers to an artificial state of crisis that we create (that’s right we have to take responsibility here) because of our attempts to not miss anything and to be connected, always on, anytime, anywhere. This is a distinct phenomenon from multi-tasking, which usually connotes a focus on productivity (not the case with continuous partial attention). There is more information about this concept on Linda's blog.

Below I’ve compiled a brief overview of my notes from today’s event. My focus here has been to capture high-level ideas that may serve to inspire my future projects and research at ITP.

Top Three Ideas

• Our current always-on state of being is unhealthy and unsustainable
• Trend society’s focus moving from thinking and doing to sensing and feeling
• Opportunity to bring the body back into our interactions with computers

More Detailed Overview

The condition of continuous partial attention keeps people in a constant state of fight or flight at a low-level. This state is not healthy or sustainable.

• Physiologically, the chemical impact of remaining in this state for prolonged periods of time has a negative impact on our mental and physical wellbeing.
• Medical research shows that being in a chronic state of fight or flight has negative physiological and psychological impacts (e.g. depression).
• Breathing exercises and meditation are one of the many tools that we can use to manage state of mind (and upstate the parasympathetic nervous system).

To date, our interactions with technology have for the most part ignored physicality, which has had a negative impact on our lives.

• When we engage with computers we often have bad posture and even neglect to breath.
• Breathing is linked to attention and emotions. Thus physical ways to engage with computational devices can help us on these levels as well.

A new era is beginning, where people are going to be looking for technologies that provide quality of life (not just simplicity).

• Opportunities to explore how to use ambient or environmental technologies to create contexts that help people relax by stimulating/engaging our parasympathetic nervous system.

Technology can be used to change people’s behavior with the need for using incentives and punishments

• The Prius demonstrates how providing individuals with the ability to self-regulate is often sufficient to change behavior.
• The Fun Theory campaign from VW shows examples of how creating new interactions that are fun can also change the behavior of people. I've embedded one of the videos below.

Book Recommendations

• The New Science of Breadth by Elliott Stephen.
• Play by Steve Brown.

Stop Motion Video - Love Story

Earlier today Eric Mika and I presented our stop-motion movie to our Communications Lab class. This was my first ever stop-motion movie creation. We had a great time working on this project, though it was a lot of work. 


Our process included a two-hour planning session, another two hours for pre-production and casting (aka buying fruits), eight hours in production (including breaks), and four hours of post production. Here is the video that we created, followed by a more detailed overview of the process.

Stop Motion Madness


Planning and Story Development
The first activity we undertook during the planning phase was to brainstorm a few ideas. From the outset both Eric and I were interested in working with food. We explored a few other possibilities, including a herd of chairs and killer ethernet-cable snakes. However, we quickly settled on doing a food-based animation using fruits, and limes in particular.

Once our focus had been we honed we began to develop an outline of the story. We started with the idea of a lime coming to life and exploring the countertop. Then we added the element of interaction with another fruit as a means to make the story more interesting. At this point the story quickly started to descend into a love story, which was not the direction that either Eric or I had originally intended. This realization inspired the idea of a the knife splitting the lime.

We were still not fully happy with the flow of the story but we thought from a content perspective we were just about there. We briefly discussed the idea of adding a caipirinha recipe to the video but we did not commit to it until the day of the shoot. Over the next two days we collaborated remotely to develop descriptions of each scene and a list of materials that we would need for production (you can view the draft scene descriptions below, we made updates to these scenes on the fly during the shoot).

Storyboard

Frame 1 - Bag of limes is put on the counter: A see through plastic bag with limes is put on top of a counter that is filled with fruits, liquor bottles, sugar, a pestle and mortar and other bar-related items. The bag is put down near a cutting board. Behind the cutting board is a bottle of cachaca, the pestle and mortar and a container filled with sugar.

Frame 2 - lime rolls out of the bag and comes to life: A lime rolls out of the bag and grows a set of arms and legs. It opens its eyes and maybe its mouth, then rubs its eyes. The intent is to show disbelief and excitement. 

Frame 3 - lime sees something across the way: All of a sudden the lime notices something on the other side of the cutting board, and is visibly excited.

Frame 4 - lime thinks of "wow": Cut to shot of colorful fruit and papers creating a words that express the excitement of the lime. Words under consideration: "WoW" "Sweet" "Love". Second option - use drawing with colorful markers or pencils.

Frame 5 - cut to what the lime sees: Across the cutting board there is a strawberry or a red pepper (maybe smiling at him, or smoking a cigarette). 

Frame 6 - lime walks over to the strawberry: Cut back to the lime and follow the lime walking across to the strawberry/pepper. On the way the lime steps up on to the cutting board.

Frame 7 - lime gets cut in half when crossing the cutting board: When the lime is about half way across the board a knife comes down suddenly and cuts it in a half.

Frame 8 - pan out to see all of the caipirinha ingredients: Pan out and see all the caipirinha ingredients (and may be we could make a very fast stop motion video of me making the caipirinha).

Frame 9 - caipirinha recipe is drawn on a white piece of paper.

Supplies Needed

Technology
- DV Camera
- Lights 
- Tri-pod
- Firewire Cable

Art Supplies
- Putty (to hold up the lime, and make arms and legs)
- Wire (to hold up fruits)
- Large white paper (for background during word sections)
- Colorful paper

Fruits
- Limes
- Strawberries
- Apples
- Bananas
- Basil/parsley/mint (other leafy herb)

Things we already have
- Sugar
- Cachaca 

Pre-Production and Production
We did all pre-production and production on the same day. We started by meeting at ITP, where we finalized the story details and checked out a HD DV camera, lights, a tripod, and the proper cables. We spent some time testing the camera with the iStopMotion software. We had to play with the settings on the camera for fifteen minutes before we were able to get everything up and running.

Next up we cast the two main roles, and supporting fruits, at Whole Foods. We purchased limes, strawberries, bananas, mint, and apples (the only fruit that did not make the final cut). We got back home, found silly putty (which I already had), and set-up the "stage" on the kitchen counter. Next we set-up the camera, lighting and computer. Last we had to style our stars by adding eyes and getting them to stand up properly. We were only able to solve the later problem by cutting off a small piece from each fruit.

We started filming using the frame descriptions we previously developed as our guides. Eric and I were pretty much in agreement throughout the shoot. For the most part Eric took the lead behind the camera, while I took the lead in front of the camera. We were able to keep things moving pretty efficiently and there was only one scene that we had to reshoot. About two thirds of the way through production we had to create a caipirinha on video, so we took this opportunity to have a break and a delicious drink.

Post Production
By luck, in the night between the shoot and our editing session (which was also the day of class) I found the perfect song for our video. For post production we used Final Cut Pro, to edit the video and audio, and then Photoshop, for retouching and color-correcting specific frames.

Neither Eric nor I have had much experience using Final Cut before. We partnered together to recut the movie and add sound - unfortunately we did not learn how to use the marker until our class after we were done. To retouch the photos we used the batch retouching feature on Photoshop. After we had the video almost locked down we added the soundtrack. At this point we made minor adjustments to the flow of the story to better align with the music - the ending could still use some work.

Serial Input Lab and the Etch-a-Sketch Sketch

This week our lab for Introduction to Physical Computing focuses on using serial communications to enable the Arduino microcontroller to interface with other processors such as a multimedia computer. That said, this same process can be used to enable the Arduino to interface with a multitude of other microprocessors and microcontrollers.

To keep things simple, the lab exercise only requires that we set up a single analog input on the Arduino board – a potentiometer. This component is used to control a graph that is generated in processing and displayed on the monitor of the multimedia computer. I have decided to take this one step further, and to attempt to make a virtual etch-a-sketch.

Here is a link to the lab page where you can find the overview and code samples for the original lab. Another helpful link is this overview about Serial Communications from Tom Igoe’s blog. In regards to the etch-a-sketch, all of the Arduino code is included below, the processing code can be found here. But first, check out the quick video that I put together about this small project.

Managing the Communication
When communicating more than one piece of data it is important to create a syntax that can enable the receiving computer to parse out different commands.

I decide to use the following protocol for my messages to enable me to parse out the two readings from the potentiometers: The data from the first potentiometer would always be preceded by a period, while the data from the second would always be preceded by a space and followed by a period, which marked the beginning of the first data element. For example “.255 0.255 1.254 2.” And you get the point.

From the Arduino side, to make sure that I could read the serial input clearly I set the Serial.print() mode to DEC to transmit the information. Then, once the information was parsed on the other end I converted the values back to numbers (floats) so that I could use these values to determine the location of the drawing on the screen.

On the processing side I encounter more challenges than with the Arduino. The biggest problem that I had to solve was choosing a strategy for accurately reading the data from the serial port. At first I tried to read the input one character at a time, as outlined in the code sample below. I am sad to say that this approach did not work well enough because there was too much noise.

The Wrong Approach to Reading the Data

void serialEvent (Serial myPort) {
    // read the port
    readString = myPort.readChar(); 

    // if a period is found then set read the next characters as xPos values
    if (readString == char(46)) {
      readNow = "xPos"; 
      xPosString = "";

    // else if a space is found then set read the next characters as yPos values
    } else if (readString == char(32)) {
      readNow = "yPos"; 
      yPosString = "";

   // else if values have been set to be read as xPos
    } else if(readNow == "xPos") {
      if (xPosString == null) {xPosString = readString;} 
      else { xPosString = xPosString + readString;}
       xPosString = xPosString + readString;

   // else if values have been set to be read as yPos
    } else if(readNow == "yPos") {
      if (yPosString == null) { yPosString = readString;} 
      else {yPosString = yPosString + readString;}
       yPosString = yPosString + readString;
    }
} 

I was able to get things working right by learning how to set Processing’s buffer size, which governs how many bytes are received before your application calls the serialEvent function. I set the buffer size to 20 and decided to capture one full string of 20 characters at a time. Then I proceeded to read just one set of readings from each of these buffer strings. This greatly stabilized the user experience.

Unfortunately, since potentiometers have a narrow rotation range it is not possible to create the true etch-a-sketch feeling with them. On screen you can use the arrow keys to draw – at ITP we will user the small controller pictured below to play around with this (at least for a couple of days until I decide to use these parts for my next little project).

Final Arduino Code

 int analogPin1 = 0;
 int analogPin2 = 1;
 int analogValue1 = 0;
 int analogValue2 = 0;

 void setup()
 {
   // start serial port at 9600 bps:
   Serial.begin(9600);
 }

 void loop()
 {
   // read analog inputs:
   analogValue1 = analogRead(analogPin1); 
   analogValue2 = analogRead(analogPin2); 

   // reduce range to appropriate range for analog output by dividing by 4 
   analogValue1 = analogValue1 / 4;
   analogValue2 = analogValue2 / 4;
   
   // print values to serial port
   Serial.print(analogValue1, DEC);
   Serial.print(" ");
   Serial.print(analogValue2, DEC);
   Serial.print(".");

   delay(5 );                 
 }