Link to documentation: http://cmuems.com/2018/60212f/airsun/11/08/airsun-shuann-automaton/
For this project, we created an automatic display that presents distinct gum and description pairs on a rotating base. Once the viewer approaches the machine, the belt located on the top of the white box will turn to display the next gum within the gum family. Simultaneously, the museum label facing the viewer will also turn to display the next story in association with the gum.
We really put a lot of thoughts into the development of the background stories for each gum, including their appearances, personalities, and background of how they ended up here in this gum collection. We also attempted to create an impactful contrast between the conventionally neat and clean museum display with gums, which people often associate with the opposite connotation.
Here is the list of gums' stories. For each gum, we will personalize a story for them based on their shape, color, and brand. The first card gives a brief introduction of the gum family, which serves as a museum label introducing the artwork.
We created a lollipop-licking robot for our automaton. The robot uses an IR distance sensor to pick up when someone has placed a lollipop into the lollipop holder, which initiates the robot's licking. A tongue made out of a sponge moves up and down (powered by a servo) while the lollipop rotates (powered by a stepper). The tongue dips into a tray at the bottom of its movement that is supposed to contain water to keep the tongue wet for its licking.
We came up with a couple of automaton ideas, but really couldn't settle on anything to begin with, so we went to the Center for Creative Reuse to get some inspiration. The entire project was inspired by sponges we found at there. The scale of the robot, the type of lollipop the robot was licking, and the movement were all based around using the sponge as a tongue. To keep the tongue wet, we had a couple of ideas. We first thought we might be able to wet the tongue once before it starts licking a lollipop, but we realized that this did not provide enough water to get through an entire lollipop. We then planned to have water dripping down onto the sponge from the top (and later from the side), but both ideas necessitated the use of some sort of valve, and we figured this was too complicated for the scope of the assignment. We then settled on the idea of using a stationary tray of water that the tongue could dip into when needed.
After settling on a design for the robot, we modeled the structure and shell in SolidWorks, accounting for the electronics that would be placed inside.
Despite our measurements, we failed to account for a couple of things. Most notably, we didn't account for the space needed for the servo's plug (we just made space for the Arduino on its own). As a result, our robot currently doesn't have its back. Also, we did not have time to seal the water tray, so our robot currently cannot hold water. The tongue knocks the the lollipop out of its slot sometimes (an issue that could be addressed by moving the tongue a couple of millimeters back and making the lollipop slot a little bit tighter). As a final point of improvement, the tongue's movement could be adjusted to make it a more natural movement.
Karen would like to speak to the manager about the quality of food in this establishment. Place a yummy snack into Karen's hand and watch her eat it because god damn it she's going to get her money's worth.
(Concept Development) This was very much a creation guided by material. Our original idea turned out to be unfocused and too hard to do with our limited Arduino skills, but we had this very realistic wig and some bugs. So we decided to have a pretty lady eating bugs. As we continued working, Alyssa pointed out that she looked like a suburban mom, and the aesthetics followed from there. We thought it'd be interesting to mock the uptight middle class soccer mom stereotype by making her do something unconventional.
(Technical) Golan suggested we look at Linkage for some simulations for scooping motions, and that's where we got the design for the arm apparatus(laser cut). The linear motion of the jaw was thanks to some 3D printed parts from the Physical Computing Lab. I ended up building and troubleshooting the arm mostly, while Alyssa worked on the jaw, and later the software to synchronize their motion. We worked together to assemble the whole thing and troubleshoot(so much....too much, my knees still quake at the memory).
The results are "jank," because we intended to add some things to cover up the wiring and tape. There were probably things that could have been done to make the arm more a part of the character, but we didn't have enough time. However, I think the arm mechanism works well and looks impressive. Alyssa painted the face, and I think it ties the whole set up together very well.
The happy coincidence of that, however, is that one can appreciate the possible implications. During the critique, Caroline mentioned the possibility of an interpretation of the housewife as a soulless machine cog. In general, the messiness of the presentation and interaction(the latter was intentional), made for some fun comments throughout our work, on how messy Karen is, as if she was a real character.
When we were first brainstorming ideas, we initially thought of creating a robot hand. We tried to pursue it in a couple different ways and printed/sculpted several different hand blueprints. Trying to make the hands look intricate and elegant was very difficult, as keeping track of and controlling all of the parts of a hand (the knuckles, joints, etc.) is not a trivial task. Eventually, we decided to scrap that idea and create a divided environment in the form of a divided box. The upper half represented land and its creatures, as the bottom half represented the sea. The stopping and restarting movements of the motors creates an illusion that makes each of them move or jitter and jolt to a stop.
The whole process was very time consuming because although thinking of an idea was alright, being able to execute them proficiently was much more difficult. Nicolas organized the overall structure of the project and did most of the coding job, like creating the environment, and I mostly handled the art. We had originally planned to incorporate other aspects (such as creating ridges surrounding our motor for our wires to jump up and down and move our animals), some of the logistics of the wire and the weight of the clay not adding up made that task difficult. Overall, creating a project with the Arduino for us was also new, frustrating, enjoyable, and rewarding.
Creating a blobfish:
Baking the clay with a makeshift hairdryer oven:
The idea for this project came gradually. After compiling bags of random objects from Pittsburgh's Center for Creative Reuse, Joe and I were initially drawn to the discarded doll parts. Originally, we wanted to work with the doll head as it captured the "creepy" factor we were going for, but the idea of a physical interaction with the automaton came up in the form of a high-five. Additionally, the idea of a creepy doll head seemed overused at the time so we decided against it. Thus, we ran with the high-five idea - utilizing multiple hands and arms to create a machine that started with a simple high-five.
Regarding our respective roles in this project, I worked on a lot of the hardware + crafty end of things while Joe contributed a lot to the coding of the project as he had some prior experience with Arduino. The idea and design for this project was pretty much an equally collaborative aspect as we finalized decisions through conversations we had together.
In order to interact with our automaton, aptly named "Handy Warhol", a user must initiate a high-five with it, which then triggers the machine to high-five itself and generate noise.
"Skipper's Dreamhouse" is a scary house that first reacts to movement at a far distance, then waits for the viewer to come closer. Once the viewer is at a certain close distance, a random timer is triggered and the deconstructed Barbie doll, Skipper, pops up to scare the viewer. Throughout making the project, various decisions were made often having to compromise aesthetic over practicality; however, on the whole the house fits the spooky, homemade, childish vibe. If we were to further this project, we'd love to add sound, either with sound effects or music that reacts to the viewer, etc. As for the title, we slowly created this narrative that Barbie's little sister, Skipper, wanted her own dream house and it is terribly spooky. We joked that it could represent somewhat of a critique on Barbie and the stigma surrounding her, as we have deconstructed the doll to just her flailing limbs, showing how her appeal consists only of mindless, emotionless body -- an ultimately ~spooky~ idea to be teaching little girls. We contributed equally to the concept of the project and problem solving, where Cassie contributed more to the Arduino software and Olivia to the outer appearance. Overall, although we hit a lot of speed bumps, it was fun and the problem solving resulted in a satisfyingly spooky project.
For this project, we originally intended to make a Google Home-like device that reacted to speech input. We thought that if we used 2-3 microphones, we could triangulate the location of the user's voice. We wanted to use this information to make a robot that turned its head towards a user/person, and would reply with 3 pre-recorded soundbytes. Unfortunately, we really struggled to get useful inputs from the Arduino speakers and eventually had to shift directions.
We started looking at ways we could use the tools in front of us in interesting ways. In the physical computing labs where we were working, we played around with K'nex and pipe cleaners and light bulbs.
The light bulb was another point of challenge for us as we couldn't quite figure out how to power it correctly.
Ultimately, we focused on the servo, stepper motor, IR sensor to see what we could come up with. The K'nex pieces were especially great for interesting motion as they kind of operate as gears that only require 1 motor. We decided to lean in on these and create an interactive creature made up of K'nex. As you approach the object, it will flap its wings faster, either in fear or excitement for a new onlooker.
Working on this project was an immensely informative experience for me. My partner Huw had a lot of prior experience with arduino and working with physical computation in general, while I was relatively new to working in that way. We went through many different ideas before we came up with the idea of a marionette drummer made of trash, playing in a whacky, improbable manner in a room also made up of disposable "trashy" material. We were inspired by the materials we were working with, such as the dirty-looking carpet fuzz sheets, carpet crumb, pieces of a broken nerf toy and colored felt.
It was the use of these unconventional materials that led to a source of conflict for me and my partner (chewie) as we were trying to figure out to what extent we should try to use our materials to emulate a representation of a real space, or stick purely to our materials and not try to hide what we were working with. At one point our automaton sported a costume, a paint job and went through a few different caricaturized heads. It was after a great deal of discussion that we concluded that this attempt to aestheticize our materials was actually just clashing with the rest of the project. We removed the costume and the paint and added in the tennis ball bobbing on a spring instead, to both of our satisfaction. On the other hand, using the playing cards to make a poster, dowels and scrap metal for the drums and carpet, cardboard and foam for the bed turned out to be pretty effective as a story-telling device. We took to calling our automaton Wilson (for obvious reasons).
As far as the division of labor went, I had been learning about puppetry in my video class and was able to apply those skills to making a simple marionette puppet. I then used code from the servo sweep example as well as the motor party example to get Wilson to play. I used the spare parts I had to put together a simple drumset. My partner (chewie) was instrumental in creating the room set, and without him our project wouldn't be nearly as sturdy, nor would our wiring work. He came up with the look for the interior too, for things like the poster and the unmade bed. The most valuable contribution chewie made however, was his unwavering perfectionism. I tend to let things slide and be ok with parts of my work not being effective. chewie made us iterate multiple times through elements of the piece that just weren't working. In addition to changing the costume and color, the initial armature for Wilson was rolled cardstock, the furniture was fully cardboard and the head was a sketched-in face of John Bonham with tacked-on hair. These were all either details that were lacking in thought, or they impaired the wild and free motion of Wilson, which was clearly the focus of the piece. I was surprised by just how much one can roll back and revert changes when working with physical objects. Although we had no CTRL-Z or Github to fix our mistakes, working with actual physical layers of materials felt like there was a concrete sense of version control after all.