Speaker:       Mark Frauenfelder, Author;  Founder & Editor, Boing Boing;   Editor-in-Chief, MAKE
Time:             Wednesday, February 9 , 6-8pm
Location:      USC’s Robert Zemeckis Center for Digital Arts (RZC), Room 122
TITLE:            DIY 2.0:  21st Century Innovation

ABSTRACT:   In the last couple of years do-it-yourselfers have gained
access to a myriad of new tools and services to help them design,
prototype, fund, manufacture, and sell the things they make. Most of
these tools and services are free or very inexpensive, and they hint
at a future in which individuals and small collectives will offer
viable alternatives to mass-produced goods.
3D design programs like Google SketchUp, Blender, and Alibre PE are
not only much more powerful than the software I was using 25 years
ago, they are much cheaper, too. (Alibre PE is $99 and Google SketchUp
and Blender are free.) DIYers are using these programs to design
everything from bicycles to chicken coops to model rocket components.
And they are sharing their 3-D designs on websites like
Thingaverse.com, where other people can download the designs, modify
them, and then make their own versions of products using the models.
And the tools that they are using to make these objects are getting
more powerful and cheaper all the time, too. Remember when laser
printers, which cost $100 today, used to cost $10,000? A similar thing
is happening with manufacturing machines. Low-end laser cutters cost
about $7000, compared to $20,000 just a couple of years ago. And 3-D
printers, such as MakerBot Industries’ Thing-O-Matic (a rapid
prototyping machine that prints out objects in the same kind of
plastic that Lego bricks are made of) sell for about $1200.
Eventually 3-D printers will become as commonplace in people’s homes
and offices as laser printers are today. But in the meantime, websites
like Ponoko.com and Shapeways.com are the equivalent of desktop
publishing service bureaus. For a small fee you can send your 3-D
design to Ponoko.com and Shapeways.com and have them print out a model
in plastic, metal, or other material. These service bureaus will also
manufacture and sell your product to anyone around the world who wants
one.
Most of the things that DIYers make are funded out-of-pocket. But for
more ambitious garage entrepreneurs, websites like Kickstarter.com
allow DIYers to post requests for project funding. The next phase in
crowdsource funding will be small scale securities markets in which
individual investors will share in the profits of financially
successful project.
And finally, the Web itself has become the great enabler of
do-it-yourself innovation. It allows communities of interest to
communicate with each other, greatly accelerating the evolution of
designs of everything from amateur unmanned flying drones to cigar box
guitars. The Web also serves as an indexed surplus store where almost
anything anyone would want can be found with a simple search.
In the 19th century people made most of the things that they used ­
furniture, clothing, shelter, food. We may see a return to a world
where individuals make many of the things they use every day, but be
connected to other innovative individuals around the world who help
them realize their goals.

Skip ahead to around 4:40 if you don’t want to watch all the “making of” bits.

Big thanks go to Perry Hoberman and Nikita Pashenkov for getting me through all the technical aspects.

Press play to watch the video!

(You can also download this video here.)

I’ve had lots of struggles with Buddy. As you can see from this video, Buddy has definitely come a long way from his original inspiration. Unfortunately, Buddy has been constructed – and constructed pretty well for someone who has never undertaken a project like this at all since he no longer falls apart (I had a lot of trouble keeping his head from falling off whenever the servos in his head moved) – but does not actually work as intended. I am pretty sure that there are too many servos trying to draw power from the arduino at once. I had the servos moving his head when they were the only things connected to the arduino, and after more things were attached, I realized that the continuous rotation servos were not moving after I attached them to his body. I am still getting information from all of his sensors in the serial monitor in arduino, so I do not believe I fried the board. This is an undertaking I am going to pursue figuring out over the summer as well as to add sound to him and to perhaps give him an on and off switch or sensor so that when he is plugged into power he does not just fly out of the user’s hands (which I had been afraid of while putting him together.)

The latest version of “full” code I was using (though it is missing some of the interaction code when I could not get the autonomous movement code to work right) is here (.pde file)

and here (.rtf file). Despite these set backs, I do not feel that my robot creation has been a failure. On the contrary, the fact that I know to keep trouble shooting and that each piece worked separately and when in conjunction with some (but not all) other parts makes me confident that this issue is just something I did not foresee and not something I cannot overcome. I just need some more time to work out the kinks.

My dream for a robotic creature has certainly come true, in spite of all the set backs. I learned that the hardest part of making a robot is actually putting all the pieces together after FINDING all the right pieces. I didn’t have a glue gun before this. I feel like my thesis project might be something robotic and I am glad I’ve got some handy tools for further projects – as well as to continue perfecting Buddy. He’s a pretty cute little seal and I want him to waddle around for me. The pleasure I think people could find in this project – a robotic animal friend – is in having something to interact with that you don’t need to feed and don’t have to worry about hurting itself. I have always had a deep love for animals (yes, everyone knows I have a bunny!) and some of the downfalls of real animals are made up for in a robot – like feeding them, cleaning up after them, bringing them to the vet, and, in the case of my rabbit, worrying about their blindness getting them hurt. Buddy can move around on his own and this makes him pretty smart. If he gets stuck, he won’t continue to slam against the wall. If you wave at him he’ll be interested in you. You can pet him and he’ll be happy. In future I’d like him to even be able to follow you around after you’ve interacted with him (but of course, first I’d like him to move like I expected him to!). I actually can’t wait to see what Maddy does when I have a robot following me around… I think she’ll be jealous!

After I’ve spent all these hours just trying to make a frame and make things that fit together, I’ve still got a lot of big dreams for the future. I want to make an artificial intelligence inhabit this robotic body. I want a robot that can decide what it wants to do. I know I’ll have to make increments – better autonomous movement that can be more random so it seems like he’s making decisions all on his own – but eventually I’d like to explore giving my robot a unique personality and a mind of his own.

I’m going to estimate that making his frame after first testing each part and writing little bits of code to help me test and understand each part (though I still don’t understand why the 180 degree servos make a scary humming noise when they are on) took me at least 3 times as long as I had originally thought it would take. I thought a full weekend of work (Thursday night to Monday morning) on a body would produce a frame. Do not be misled if you are building a robot like this – it takes WAY longer. And you will likely discover you need more of a material or something new you hadn’t anticipated in the process at least twice and have to stop working and go out and find that item. It took me longer than I anticipated just to find the right parts. And it took a week to have parts delivered from spark fun. All of this time adds up and if I had it to do over again, I might have set my goal a little smaller so I had a chance to reach it with a small robot that moved around very little. Nonetheless, I am glad I have this intensely huge start to finishing off my dream robot. He’s built! He might need some trouble shooting still, but he *actually exists now!*

Please enjoy the video even though it is not very elaborate. Buddy and I are off for a summer of more hard work (do robots hold up well on the beach??).

Our initial proposal was laid out in Josh’s blog a few weeks ago and since I forgot to put a link to it then, I wanted to make sure it was here now, so the curious can look at the progress of the piece.

The final presentation veered, as these things sometimes do, slightly away from the original proposal. In the original proposal, we were exploring the idea of historical reconstructionism, how when we look back on our past (Renaissance Faires, themed restaurants like Ed Debevic’s) we often romanticize the period we’re reconstructing, rather than strive for any sense of historical accuracy. In this vein, we imagined ourselves as archeologists from the future who, similar to the ventures mentioned above, were striving to capitalize on a romantic notion of the past.

Setting our presentation in the years after Peak Oil, we set up a future where the outside world is so toxic that humans are forced to live in hivelike cells, rarely venturing out of their small pods to interact with others; a world where physical travel and physical contact were as alien as travel to another planet would be today.

Our narrative set up imagined us as entrepreneurs bringing the lost notion of “traffic” to our contemporaries, in a soothing spa-like setting, with the data from a traffic stream “massaging” the user. Our initial proposal suggested a “tickling” effect for the user, but with research, this changed to the use of vibrating motors to give the more spa-like experience.

In order to fully realize this set up, we used a car seat outfitted with what the future entrepreneurs would envision “seat belts” to be (more narrow that a standard seat belt and set up in a cross-like fashion, closer to what one would find in a fighter jet than an automobile). Again, this was intentional to emphasize the idea of “getting the past almost right, but not quite correct.

Embedded in both the seat belt straps and the underside of the seat cover were small vibration motors, whose intensity was dictated by traffic data (obtained from Navteq), parsed by Processing and then fed into the Arduino board to control the output. To add to the presentation, Josh and I took on the entrepreneurial characters as Ed S’el and N’Ova, his assistant, completely dressing the part as future humans.

As N’Ova, Josh would announce the various freeways whose data were being input to the chair (“Hollywood Freeway”, “405 Freeway”, “Long Beach Freeway”) while I, as Ed S’el would encourage the user to relax and let the gentle flow of traffic overtake them.

While the user was experiencing these soothing traffic massages, he/she were surrounded by a net tent, implying a bright, sunny sky – clear of pollution and grime – while viewing a soothing randomized animation of cars moving smoothly and snakelike across the screen, while still being physically close together (another point of intentional incongruence on our part). While in the massage chair, the vibration motors on the seat belt straps not only massaged the body, but the vibrations also produced a humming buzz that could only be heard by the user in the chair, which added to further relaxation.

(Above: Work space after all crafty things were assembled… I dragged my desk which is really just a table into my living room so I could spread everything out – and good thing because by the time I was finished, things seemed to have been everywhere!)

Building a Buddy… From Scratch

It feels a little bit like being a mad scientist to say that and mean it. I am creating a Buddy from scratch. It sounds strange and feels funny to me, but I am doing it.

Checking in for a quick update on how it’s going building a robot for the first time – with a deadline. On the bright side, the deadline has been extended so Buddy is going to have the time to become a real SOMETHING. I have been worried that I wouldn’t have enough time with all my parts to make him work decently on the inside and look good on the outside, too.

I’ve had lots of troubles in acquiring all the right parts. I’m not sure how I’m going to pay any bills or rent, but I finally feel like I have everything. Buddy’s got a frame started and though I’m still working out how to make it all stay together, at least it’s started.

I’ve figured out how to use the servos for Buddy’s head, but I still haven’t worked the kinks out in how to keep him from breaking himself. I’m wondering if somehow I’m not seeing an easier way to put two servos together to make head movement because right now they move sort of violently and free themselves of the frame. Hopefully I’ll be able to fix that soon and finish his frame so that I can get everything attached and functional. I still need some test runs of him moving around so that I can get the code just right. I’m waiting on a couple parts that would help me enormously (like the 9V battery connector) so I don’t feel like I’m wasting time – I’m definitely still doing a LOT of other things while I wait to have free-roaming test runs.

Things I am thinking will not be up to snuff in time for final presentation:

Sound

On/Off Switch or Mode (I had thought vaguely of trying to give him a condition in which he would first start at when powered on that could be changed in order to make him start autonomous movement but as it is still a fuzzy idea on how it would be important to the robot other than to make it easy to take out the battery, it seems the right thing to scrap for now).

As to the sound, I have the sound module and a little speaker and I’ve got at least an idea on how to work it. I’d really love Buddy to have sound, but since I know I’m going to be working more on robotics this summer (I really am very interested and want to learn more) I am trying to convince myself that it’d be best to save this for after the assignment has been turned in.

For the Switch or Mode, I was thinking of dressing some sort of sensor (IR maybe?) in an object (a mini robot fish!) that when waved in front of Buddy would cause him to start up and then again to sit still.

Well, I think that’s all for now. Just a little update on what it’s like to build a robot for the first time. If for any reason, you read this post up to this point and didn’t get that while I’m very interested in robotics, I’m also overwhelmingly stressed out about meeting the deadline, now you’ve been disillusioned. This is a difficult project to take on in such a short space of time!

The goal of this piece was to construct a device with which someone could create a musical atmosphere using his/her heart beat and motion.

To accomplish this, I first attempted to implement a heart rate sensor. My original inclination was to do so using a standard heart rate monitor as the sensor. However, it was recommend that I look into detecting heart beats via infrared sensors.

The majority of my time on this project was spent on this facet of the device. Tweaking the code in both Arduino and Processing to correctly interpret the data from the infrared sensors ended up being a more complex process than originally anticipated. In addition, the device itself seemed to be rather unreliable (though this may have been due to the code). With the help of others and many online resources, I was able to get the sensor to report the general rate of the user’s heartbeat and translate that into what would become a steady beat background for the overall music to be generated by the device.

The second component of this piece was the accelerometer. With this sensor, the user could play one or two of four instruments (or tones) at one time.

The third output of this contraption was the music visualizer. With the visualizer, the user would be empowered to set the visual atmosphere of the room via his/her heart rate. Essentially, the visualizer would react to the beat audio sample triggered by the infrared data.

The final result was a piece in which the user could generate the beat and visuals via their heart rate and control the melody and harmony via their motion.

Granted, the end result did contain its fair share of bugs. The infrared sensor and accelerometer both remained to be generally unreliable – either due to hardware or code (both of which require further testing).

In addition to bug fixing, the next steps for this piece would include setting up the device to be wireless (via a Bluetooth Arduino) and embedding it within a stylish glove of which even the most swanky of DJs would be envious.

Below are images of the current iteration:

The device with the music visualizer (with thumb on infrared sensor).

The device with hand holding the accelerometer.

Basically, the point of the game is to perform well enough on the guitar song to keep the robot pacified. When the performance is accurate, the wheels stop moving, and the Beast rises up and starts ‘dancing’, or moving from side to side. However, when the player starts performing poorly, the beast goes back into its crouch and the wheels resume movement, creeping toward the hapless player. Frets on Fire has its own losing criteria, which usually coincided with the Beast reaching the player.

Looking back, I feel that the project was pretty successful. The programs all worked as planned and the robot looked good and performed its function. I was pretty happy with the way it turned out. If I were to change something about the project, I would fiddle with the difficulty of the song. Never having made a Guitar Hero track before, it ended up being too difficult for most players (including me). Of everyone who tried it, only one person was able to play the game to completion.

Here are some videos of the in-class presentation of Orpheus: Tamin’ the Savage Beast.

Download file

Download file

Basically, the point of the game is to perform well enough on the guitar song to keep the robot pacified. When the performance is accurate, the wheels stop moving, and the Beast rises up and starts ‘dancing’, or moving from side to side. However, when the player starts performing poorly, the beast goes back into its crouch and the wheels resume movement, creeping toward the hapless player. Frets on Fire has its own losing criteria, which usually coincided with the Beast reaching the player.

Looking back, I feel that the project was pretty successful. The programs all worked as planned and the robot looked good and performed its function. I was pretty happy with the way it turned out. If I were to change something about the project, I would fiddle with the difficulty of the song. Never having made a Guitar Hero track before, it ended up being too difficult for most players (including me). Of everyone who tried it, only one person was able to play the game to completion.

Here are some videos of the in-class presentation of Orpheus: Tamin’ the Savage Beast.

Download file

Download file

PROPOSAL

Our original proposal was to create an organic-looking sculpture with dynamic light sources, based on certain natural oceanic inspiration such as kelp and jellyfish. Our main goal was to have a high quality of light in the sculpture, and interesting light behavior that would look and feel natural.

WORK

My first step in the process, while we were waiting for our electrical components, was to attempt to program some basic functional units of light behavior that could be combined later on. My initial approach was to create an array of “lit” lights, and an array of “to be lit” lights. The former would keep track of the lights currently lit, and the latter would keep track of the lights to be lit in the next time step. Every LED in the sculpture would have a numeric 2D array designation that described its strand number and position in the strand. This would allow us to push the LED values onto an array at each time step, and then pop them off as needed. The goal of this approach was to allow multiple strands to function simultaneously off of one Arduino.

Unfortunately, this proved to be too complex an approach for the given time constraints, considering the input nature of the shift registers we were using. In the end, I switched to a simpler method that could send one of five different light behaviors to one strand at a time, and then send a new behavior to a different strand only when the first one was finished. This was accomplished by connecting different shift registers to different strands, and then sending out the appropriate binary pattern to whichever shift register was controlling the strand in question.

While I was doing the basic programming, Amanda was gathering and experimenting with physical materials. She produced a number of quite interesting but ultimately unsuitable results from mold plastic and various other materials. Finally, she discovered some plastic fruit (tomatoes and grapes, mostly) at a flower shop that produced some very interesting light quality when placed over the LEDs. Amanda also shaped and built the base for the sculpture, and drilled it full of holes for the wires.

After we had accomplished each of these tasks on our own, we met and began to assemble and wire the sculpture together, as well as finish up some final material experimentation and light behavior trials. The sculpture assembly was incredibly time-consuming, as all the LEDs had to be assembled into their fruit, wired, labeled, and then wrapped together into their individual strands. We made most of our decisions about the final shape of the piece in this stage.

Finally, we met to wire up the project. This finalized the shape of the sculpture, and was also nightmarishly difficult. Many of the wires were too short, most of them had lost their labels in the assembly process and had to be individually tested to see where they came from, and we discovered that we did not actually have enough materials (mostly wires and resistors) to connect all of our LEDs. By this point we did not have time to search for additional materials, so we wired it as completely as we could and applied what light behavior we had.

FINAL PRODUCT

The final product contains three Arduinos and breadboards, 5 photoresistors, 42 LEDs, and over 100 wires. The light sculpture stands roughly a foot tall and contains 5 strands of colored lights, four of which react dynamically to photoresistors. The remaining strand, along with 9 blue and green LEDs in the base, stay on and do not react to the photoresistors. The photoresistors are planted on the base of the sculpture, among the white paper structures, in small purple domes to better include them in the sculpture as an artistic whole.

The light strands react dynamically to the light from specific photoresistors. Each photoresistor controls the speed of one of the four strands (one photoresistor is not used – it was intended to control the overall light strength of the base LEDs, but we did not have time to implement this). The different strands have slightly different light behaviors, but each of them have variable activation speed for that behavior based on the ambient light of their own resistor.

DEBRIEF

One of our biggest problems ended up being lack of hardware. We discovered upon our final wiring that our existing wires were too short, and we did not have enough to comfortably wire our hardware outside of the sculpture, resulting in a very tight squeeze to wire everything directly under the sculpture’s base. We also did not have enough resistors to safely wire all the LEDs (due in part to my misunderstanding of how to wire multiple LEDs into a single circuit), so we unfortunately were not able to wire up all the base lights, which I think was one of the most interesting light effects as part of the overall sculpture. In addition, many of the parts we ordered, including the LEDs, didn’t come in until halfway through the last week of the project, which greatly impeded our ability to get work done in a timely fashion.

If we’d had more time, I would’ve liked to get more hardware and wire everything properly and comfortably distant from the base. I also would’ve liked time to complexify the light behavior, perhaps even going back to the original setup in order to manipulate multiple strands at one time. We also could perhaps have had more dynamic behavior if we’d had more Arduinos and other hardware available.

Overall, I was very happy with how the physical sculpture turned out, particularly the quality of the light. The thistles were my personal favorite, as they gave a faint green glow that was just visible beneath their bristles. The LEDs in the base were also very interesting, and I believe the overall sculpture would have been greatly improved in appearance if we could have lit them all. In the end though, I’m happy with how it turned out for the time, budget, and materials we had available.

0. Overall

The project’s goal is to make toys that can express their feelings on music and ambient sound by dancing on the sound’s beats. Another goal is to make toys as easy as possible to add or remove on the dancing stage so that from a single dancer to a dancing troop is possible.

1. Processing

Minim sound library is used to detect sound beats. Minim library’s beat detection algorithm is here. However, the problem is, as the author mentioned, that ‘beat’ is a more abstract concept which is not easy to be explained in known mathematical equations. The initial plan was to detect three different beats only in frequency domain but I found that simple detecting algorithm in time domain is better than in frequency domain. (The basic algorithm in both domains is the same but specific frequency bands to detect beats can be selected in frequency domain. Even though there are some sophisticated beat detecting algorithms, most of them was not plausible for this project because they need whole data of a song to find out beat patterns which disables on-the-fly detecting.)

As a result, detecting in the time domain and two pre-selected frequency bands (40~80Hz, 100~400Hz) are used in this project. One byte of beat information, whose lower 1st~3rd bits are designated to each beat and set to 1 if that beat is detected, is composed and sent to Arduino every frame via serial cable. Only the master toy receives this data from Processing and dances along with it.

2. Arduino

Each toy has one Arduino board and 3 servos, 1 IR emitter and detector are connected to the board. More specifically, servos and IR emitter are wired to MCU Port outputs and IR detector is wired to MCU comparator’s input. The master toy is directly connected to Processing and slave toys communicate each other via IR signal.

In terms of the master toy, each servo is mapped to each beat bit of received byte. If the bit is 1, the servo rotates small angle (15°) or rotates for a short time(80ms) switching its direction. When a byte is received, the master toy sends IR signal to the slave toy. IR signal’s duration is proportional to the byte’s value. As it is designed that value 1 has 5ms duration, IR signal duration varies from 0ms to 35ms (max 00000111 byte = 7*5ms)

As IR detector’s output is analog, it is connected to slave toy’s MCU comparator input in order to make use of comparator output edge interrupts. On the rising edge of comparator’s output, the slave toy’s interrupt function is called to save the time using millis() function and its IR emitter is turned on to send signal to other slaves. The same thing is done on the falling edge (IR emitter is turned off) and the time difference between two saved times is converted to the servo control signal. The inevitable delay from the master to a slave is maximum 35ms but there’s no delay between slave toys because of interrupts driven IR detector and emitter.

However, I found that the continuous servo is not appropriate for this kind of project that servos rotates for a short time and switches its direction frequently. The torque of continuous servo while it is rotating was so weak that the bottom servo couldn’t support the whole weight of a toy and two other servos. Moreover, unlike 180° servos, continuous servos were very hard to accurately rotate and stop as much as it is programmed. For these reason, the bottom servo, which is mapped to 100~400Hz beats, was disconnected in the presentation.