HCID Prototyping Class

S.A.S.C.R. is an open source Socially Awkward Self Charging Robot that I created in the fall of 2010. This robot was created using a Rumble Robot body and an Arduino ‘brain’. This post outlines the electronics used, schematic, and source code.

Electronics Used

• Arduino
• Rumble Robot body
• Red LED
• Green LED
• Blue LED
• Electric Microphone breakout board (found on SparkFun)
• Infrared Proximity Sensor (found on SparkFun)
• 2 momentary switches
• 2 100ohm resistors
• 3 560ohm resistors
• 1 22ouf 6.3v capicitor

Schematic

This schematic was made by me and used as a reference. The four motors seen are housed inside the Rumble Robots body and can be accessed via the Rumble Robots mainboard (tutorial).

Source Code

SASCR’s source code was developed by myself and is freely available for public use. The source code has a fully functioning SASCR robot, excepting the “self charging” parts, which I decided to leave out of my final prototype. Please feel free to use, modify, and distribute as you wish; though I would love to know how and when the code has been used.

Download the source code

For my project, I chose to use the Arduino Lilypad in order to become more familiar with “wearable” computing.  However, I put a twist on it. I made a scaled down version of a curtain that sense whether there is light outside or not. If there is light, the lights wouldn’t show anything; if it was dark, the lights would turn on.

I began by trying to understand the coding and schematics. I found this rather difficult. Also, unlike when I received my Arduino board, the Lilypad came with no extra instructions.  In a way, I was fumbling in the dark. After an attempt at understanding the concept of Arduino, I had to give up and just see what I could do.

The most difficult part of this project was using conductor thread. Conductor thread is necessary for a circuit; you can’t just use regular thread with the Lilypad. After sewing one LED in place, I was successful in getting it to light.  My next step was to add another LED and a light sensor.

LED light

Light Sensor

After adding three additional lights, for a total of 4 LEDS, I was having trouble getting the right response. I then realized that there are only certain numbers that I could use for analog outputs: 3, 5, 6, 9, 10, 11.  After correcting this mistake, the lights worked correctly.  I used two different colors: blue and green.  The outermost lights would just stay light and the inner lights would flash based on the light source. Another thing I learned during this project was that you don’t always have to sew one LED to a -/+.   I could sew two LED lights negative properties together which saved a lot of space and stitching which ultimately led to a better looking curtain.

During this project, I also purchased a temperature sensors.  In the future, I will be attempting to use both the light and temperature sensor.  Each sensor will have its own color of LED.  From this project, I learned that conductor thread is not easy to work and your knots should be extra tight. I now have a better perspective of what kind of layout I will need for the lilypad, sensors, and LEDS. I think this is a great way to take “wearable” computing and use it for ubiquitous purposes.

Video will be uploaded later due to network problem.

Before this project, my only experience with Arduino was in the Interaction Design Methods class in the first semester. My goal for this project was to understand the basic principles of how the board works, learn some coding and build up a working prototype.

To begin with, I studied the tutorial in the official Arduino website. Learning that there are different types of Arduino boards for particular purposes, I changed my original plan for a wearable prototype to a portable prototype because I did not have the Lilipad, which is the best one for wearable prototypes. I believed that using incorrect materials will diminish the advantages of creating a prototype in all aspects from use to communicating with others. And for this particular project, I wanted to maximize the resources I had since I had not much experience with the main material. Then I learned that controlling LEDs is one of the basic functions of prototyping with an Arduino, but it could be difficult, depending on how the prototyper digs into the skill. Keep exploring the control of LEDs, I found lots of exemplars on the internet were created by senior designers, which looked simple, but the effort was surprisingly attractive. Therefore in the second working day, I decided to work on a prototype that could control LEDs in some way but also is useful for some people.

Then I began to look at tutorials on Arduino with LEDs and conducted experiments such as turning LED on and off, keeping it blinking, changing its brightness and so on. After mastering controlling one LED, I began to experiment on multiple LEDs. One of the most inspiring experiments I did was in the picture below. I used a potentiometer to control multiple LEDs’ on and off. I felt that I could use this method to display messages on an LED matrix.

But making this matrix large enough to display a meaningful message will cost too many resources and the most important, it may not be portable enough. Talking about this idea with two alumni, Cheng Fan and Yuebo Wang, who had much more experience with Arduino and coding than I did, I made another progress. They showed me an exemplar, which was a fluorescent stick that people use in concerts. When the stick went from one side to the other, the light stayed in people’s eyes. In this way, I could save the large LED board and use only one line of LED to display messages. Cheng also showed me his previous work using this method. Each LED represented a dot in the digital message, like a pixel in the screen. Therefore in the last two working days, I sketched out different messages I wanted to show in the form of matrix. Finding that symmetrical message was the most easy to display because the LEDs for the letters in an unsymmetrical message would disturb each other’s shape when swinging back and forth or up and down, I decided to show the message “I ‘heart’(a shape) U”. With Cheng’s teaching me on coding, I did several experiments to determine which LED should be on at a certain time and which one should be off at a certain time. In order to make the effect more distinctive, I used black form board to make a case so the LEDs could be seen more easily even in a bright environment. Here it comes, the I-Heart-U-Bomb.

In this project, I did learn a lot, especially the electronic principles and basic coding skills. Preparation is really important when prototyping with such high fidelity tools because there are so many accessaries. One can create unlimited functioning prototypes with those various parts. Thus most of the time will be spent testing all kinds of improper materials if a prototyper started with nothing. For the purpose of learning about Arduino, I succeeded. But I did spent lots of time experimenting and changed my plan several times afterward. For example, using an Ultra Bright LED worked as just opposite as I expected, people were blinded because of the brightness. One can prevent this by familiarizing himself/herself with the meaning of units, value or data related to the Arduino board and its accessaries. Also, seeking help from one who have sufficient experience will greatly push the project forward since a person’s demonstration was much more clear and to the point than a text book.

After this project, I feel like falling in love with using Arduino to prototype. It is so flexible that I could build so many fancy prototypes with it. But the most important is that it gave us so much fun when we saw each other’s progress, it was not done suddenly, but we kept testing the working prototype step by step, if it did not work or work awkwardly, it was the time when we laughed together and helped each other.

Concept

Intended as a multiplayer game, this Arduino project is a first step toward building a laser tag system. Unlike most systems which rely on multiple wearable components (e.g. a vest coupled with the gun), this system houses all hardware into the gun itself. The gun shoots an Infrared signal to be decoded by an opponent. Upon receiving it, the opponent is notified of being hit via a physical rumbling and a reduction in health, marked by a LED array. The shooter likewise haptically notices a shot fired and a second LED array indicates a reduction in ammo. Inspired by the Halo Xbox games, if a shot player hasn’t been shot for several seconds, health automatically increments to an indicator sound. Likewise in an effort to simply interaction, the ammo automatically reloads after several seconds of expiring a magazine.

Process

Since both partner Wes and I share little experience with electronic hardware, we incrementally propelled the project via small experiments. After discovering a library to decode Infrared signals, we attempted to test what signals could be received from an IR detector. However, after much trial-and-error, we realized the two-pronged hardware utilized could only detect the presence of Infrared. A three-pronged Infrared receiver diode containing hookups for power, ground and signal worked as intended. An Apple laptop remote acted as an impromptu Infrared emitter, as it already broadcasts signals unique to the pushed button. Second, the provided code to sound tones was modified to accept any number of songs, rather than a single default. Third, power channeled to the rumble motor for a select duration. By relying on a timing event rather than the easier DELAY() function, processing of the code could continue, and thus, not interrupt the interaction of the system. Fourth, rerouting the control of LED arrays into Integrated Circuit (IC) components, code was optimized and fewer Arduino pins were utilized. While originally wanting to use a 7-segment display to visualize a digit for ammo indication, the component was never able to illuminate; this could have been due to poor hardware or poor component documentation, rather than erroneous wiring.

Wes and I experiment connecting the Arduino hardware and software components.

Reflection

At the end of this presented version, all software and hardware worked as intended. The next step is to experiment and measure how the hardware will house within its plastic Nerf gun case. Wes experimented positioning the rumble motors in various locations, moving it from the handle to the back stock. Second, in order to work within the physically tight constraints of portable modern weaponry, all electronics will need to be mounted to a solder-board, rather than the experimental, less robust breadboard. Third, the gun will be repainted and textured for maturer audiences.

Overall, it was very rewarding learning how to read electronic schematics and becoming comfortable handling the components. Wes and I worked wonderfully as a team, as he specialized in hardware and I in software. Despite four-weeks of work, it still felt the project was rushed. Given another two class weeks, we could have had enough time to complete two fully enclosed and working laser tag prototype guns. As we individually understand our vision for the project, it will most likely casually continue into the coming months.

Download

• Arduino Laser Tag code (PDE)

What is Arduino?

“Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It’s intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments.” (http://www.arduino.cc/, on 11/14/2010)

Arduino’s can sense the environment around them via digital and analog sensors. They can also control various electronics, lights, motors, etc.

S.A.S.C.R.

My project for prototyping with Arduino was to build a robot that I named SASCR. SASCR stands for Socially Awkward Self Charging Robot. The basic idea was the this robot would listen for noises and move away from them, in a fashion much like a socially awkard person might. Further, SASCR would eventually have to recharge his batteries and would have to get over his fear of people and come out into the light to charge up. My goal was to prototype the socially awkwardness of the robot, put him in a room full of people, and see what happens. While my focus was on building the robot, I was also very interested in understanding how people might view a robot that was socially awkward and ran away from them.

In order to build SASCR I used a Arduino as the ‘brains’ and a rumble robot as a body and wheel set. I built SASCR in multiple stages and tore down and rebuilt him many, many times. I started with a quick sketch, went on to learning how to control motors, built up the audio sensor system, and finally put everything together on a new body.

This is a quick sketch of my initial idea of SASCR

Learning about motors and light sensors

Foam prototype of SASCR

Rebuilding SASCR’s body

Adding Audio Sensors

A Working SASCR!

Overall, I learned how important it is to have a clear idea up front. Sketching out the basics of my project allowed me to more fully understand it. Quickly prototyping a body allowed me to understand the look and feel I wanted. Further, building the basics one-by-one allowed me to fully understand each individual working componet of SASCR. In this project I learned about the limitations of sensors, how to quickly build parts and piece them together, as well as basic electronics. In furthering this project I would like to add multiple audio sensors for directional sound detection, as well as a better obstical avoidance system.

In a following post, I will outline the electronics utilized by SASCR, provide a schematic for building this prototype, as well as an open source version of the code powering SASCR.

The ability to apply micro-controllers to other electronics opens an infinite possibility of options when looking to manually override a given system and its functionality. My experience with arduino has improved my ability to not only manipulate given systems and their functions, but it has assured me of my actions when considering logic. What I mean by this, is that I was very nervous when hooking the power up to the arduino. This nervousness came from my experiences in Shaowen’s class, where others, without electrical engineering experience, managed to fry their kit. Having spent nearly $100 on everything, and since I am rather frugal with money, I didn’t want to fry my board. The anxiety of having something incorrectly placed on my board made me delay testing my robot for nearly 3 days. After I had actually took the plunge, I realized that I should trust my first intuitions more often. Of course, double checking my electrical design would be a bright idea, however, seeing my anxiety fade based upon a action that was required was very comforting.

My previous arduino experience includes making a LED blink for a few seconds and turn off. This is likely the source of my anxiety when talking about frying my board. I had never electrically engineered something so fundamental before, and relying on third party tutorials from the internet, and tailoring it to my needs, meant that there was a gap for misunderstanding or mistake. Having completed a ‘semi’ functional 4-wheeled robot gave me some comfort into what the possibilities are in the future in terms of applying my skills to entertain or solve a given problem, using arduino.

It is clear to me that I will not have my robot finished to my standards by tomorrow. My robot is designed to turn towards the most amount of light in the room, and to find homeostasis, then cutting its own power. Unfortunately, when the sensors are disconnected from the breadboard (essentially killing the circuit to ONLY the sensors) the robot still turns in the direction that said sensors should have determined. Since it is obviously not the sensors that are giving the arduino the data to turn in the arbitrary direction I will have to continue to debug my code. Although I have already re-written it in a way that I thought would have fixed it, I continue to find the same issues within my robot’s movement.

The concept in my video prototype is from my capstone, which is an mobile application that helps foodies to discover new and good food around their location through the social network. The design is aiming at providing more authentic experience of one’s food to another. In order to reach this goal, the application is integrating the reality with the mobile network by emphasizing the pictures of the food in the interface. Activating the camera with geographic service in the smart phone will facilitate the user of the application to provide the information: location and the experience of the food. Also a gallery of tasted food helps user keep track of their eating history and makes the provided information more trustworthy because of social bonding.

In the brainstorming section, I decided to take this opportunity to make a video prototype for my capstone project. To get started, I made a storyboard of what I was going to shoot. During the process of storyboarding, I had several iterations on the storyboard. I wanted to use a whole narrative story of my persona to show the interaction experience of the app. But at the end I decided to make the video as a demonstration of the app’s functionality because the design was an app for iPhone, whose screen was too small in a storytelling video, so I believe showing a bigger working interface align with actors using it would promote a better communication with the end users.

A quick and easy way to take advantage of the storyboard is to scan them in the computer, edit them as slides and voice over them, so I could know how long I should take for each shot as well as how the general video would look like. In this way, I could change the storyboard easily and saved a lot of time because I did not have to make the video first and reshoot if I were not satisfied. Actually this made me feel storyboarding was the most important part when making a video prototype. A detailed storyboarding helped me organize the setting, camera, items, actor and timing, saving time for me to edit video, which was most time-consuming.

As for shooting, I only have paper-prototype for the actors, which I believe was fair because it was quick. But what I would have done better was to explain more clearly about the design and the scenario to the actors so they would get more from what the experience of using the app would be, which would lead to a more authentic acting. This was where a clickable prototype might work better than a paper prototype. If the actor actually got the experience of the design, the acting in the video would influence the audience more.

For editing, I used iMovie and Premiere. iMovie was easy and quick, it was my favorite video editing tool. But its functionality was limited. When I made the picture in picture demonstration, I had to go to Premiere, because iMovie only had fixed frame that took too much space in the screen. Premiere had more advanced features but it took time to learn and manipulate the video too. Which tool should be used really depends on what a designer wants the video looks like.

Overall, I really like making video prototype even it’s time-consuming, but it is a great tool to communicate with fellow designer, managers and end-users because the knowledge is transfer directly from visuality and audio, which is the easiest way for audience to perceive the experience of the design. My opinion is using video prototype in the later part of the product circle like after several iteration or when the product is ready to put into the market, because you would have the working prototype for the actor and make the experience from the video more real to the audience.

Concept

The popular restaurant franchise, The Counter, offers extensive options for customers to build their own burger. The custom burger options can be daunting when viewing each step of the process at once due to the volume of options. This tablet application provides a more interactive experience of building a burger.

Production

Having eaten at The Counter in the past, I understand the trouble of examining all of the options while building a burger and I made sure to analyze the current process. The task is broken down into five steps;
1. Choose a burger
2. Choose a cheese
3. Choose up to 4 toppings
4. Choose a sauce
5. Choose a bun.

The steps laid out the narrative for my video and I used Adobe Illustrator to create the user interface for the application. I used a piece of foam core board cut to 12×9 to represent the tablet and spray painted it black. I then staged a photograph of the tablet next to a glass of water to give some context that it might be used while in a restaurant.

I created a green screen rig to record my hand gestures using the application. I used a bright green sheet of poster board and placed two tall lamps on each end. I suspended foam core between the two lamps using coat hangers and cut a hole for my camera to rest on the foam core and could shoot straight down. I captured 2-3 takes for each screen of my application so in post production I could choose which one looked best.

The majority of my editing took place in Adobe After Effects were I combined the staged photo of the tablet, green screen hand gestures, and tablet UI. After keying out the green color I created the motion graphics for the application animations. I made sure to time the animations as close as possible to the hand gestures to make the interaction as realistic as possible.

Reflection

My final video is a compromise of what I had planned for the application but I feel it strongly shows the interaction of working through the menu in a tablet application. Ideally i would have liked to show the burger being built on the left side of the screen while the user was selecting options. If I had the proper photo resources this could have been a great visual for the application.

Future iterations of the app would use recommendations based on flavor profiles to create the ultimate burger for customers.

Video prototype of the HareBottle concept.

Concept

Intended to assist a hare who lays trail for a group of social runners called hashers, this container measures in realtime the trail’s complexity, length and estimated duration to the container’s virtual map.

Production

After writing a brief narrative, storyboards sketched on sticky-notes allowed painless rearrangement of story segments. The narrative explains the meaning of the device in relation to the running culture for which it was designed; how it’s utilized; and the benefit to the individual laying the trail. A Flip MinoHD recorded all scenes. Adobe Soundbooth recorded and cleaned the voiceover narrative. Adobe Premiere handled all post-production tasks.

Reflection

Originally, the initial seconds of the film would showcase video of hashers running the November 13 Bloomington hash. However, shooting those segments was logistically impossible, so photos of the event were used as substitution.

With minimal experience filming with the Flip MinoHD, I was not familiar or considerate of its focus range. When filming the bottle’s animated UI from one-foot away, only the grassy background was in focus. Since the LCD display is so minimal, clearly reviewing the film live is impossible with this device. By the time the video was transferred, there was insufficient time for a second take.

Also due to time constraints, the narrative was recorded with the built-in Apple MacBook microphone. For higher quality audio, an external microphone should ideally be positioned within a soundproof or sound-resistant room. Retaining the subtle hiss of the wind as background noise, it very weakly set the tone for the piece. Time spent researching suitable background music could make the content more aesthetically and emotionally attractive.

In accordance with the deliverables for this particular project, I ended up creating my very first edited video. I am quite pleased with all that I’ve learned. I focused primarily on learning the fundamentals of video editing.
I used lynda.com tutorials to familiarize myself with the environment that I opted to work with, which was Adobe Premiere. I went though multiple iterations, slowly tailoring my video to my pleasing.
My original video was long, with silent moments within. My second iteration aimed to correct these two problems. I created shorter cuts and inserted background music. When reviewing, I realized that the music was overpowering, and so for my third iteration I lowered the overall volume and had the chorus of the song play as I was running up to the ‘study group.’
Although I think that my portrayal of an interaction was weak (the use of OCR to satisfy the users needs); I am particularly proud of the quick improvement from my first iteration to my last, considering it was my first time doing this sort of thing. Next time I will be able to fully dedicate my resources, time, and effort, to the overall plot of the video, because I will not need to worry about learning an entire new piece of software

First iteration

Final iteration