Derivative Control

Today we learned about derivative control. Derivative control lets you control your mechanism factoring in the change in state.

We also talked about open- and closed-loop controls. So, all controls use some input to make decisions about some output. Open-loops do not factor in the current state of output to make decisions about future output. Some examples of open-loop controllers include the waffle-makers in our dining halls which only rely on time as input and the laundry machine in our dorms which also only rely on time as input. Closed-loops factor in the current state of the output to make decisions about future output. Some examples of closed-loop controllers include a hot water heater for tea which heats up water based a function of time and current temperature of the water and a thermostat which heats/cools a room based on the desired temperature and the current temperature in the room.

Then we... made another robot. This robot tried to stay a constant distance away from a light source. We built a robot that had a light sensor on the front and a light on the back.

Our robot

Our code. Note: ports A and C run our wheels and port B runs our light.
We could have left port B out of the loop, but we forgot to. 

We then tried to have a chain of robots following each other. This was not so good. Our original code did the opposite of what we had envisioned (it went backward when it sensed light and forwards when it sensed dark). This edition worked, sorta. However, our class got a few robots to go and follow each other.


Then we... made another robot! This robot used what we learned in control theory to roll up a ramp. Now, a casual observer might think that this is trivial, but we do not live in a perfect world. Our motors do not necessarily rotate the same amount, even when given the same instructions. So, we had to control for the potential arbitrary unevenness with our two motors.

Our code

A break-down of our design decisions:

• 42 just happened to be the optimal speed for both motors. It was not just arbitrarily picked, even though most of the times this particular number is used, it is.
• We used a closed-loop control for this. The difference in rotation is multiplied by a constant and added to 42 to control one motor. This way if there is zero difference between rotation, then each motor goes the same speed. If the motor A has rotated more than motor C, then C goes slightly faster than A. If C has rotated more than A, then C goes slightly slower than A.
• The constant .1 we also found through iteration. Higher and it over-corrected and moved off the ramp quickly. Lower and it under-corrected and moved off the ramp in the quickly.

Our robot - we had to add a giant weight in front so that

when going up the ramp, it does not flip over  like a dead cockroach.

A clip of our robot successfully going up the ramp

Line Followers

So, we spend many days creating robots which followed assorted duct tape lines all over the engineering labs. We did this to learn about control theory and to become more comfortable with LabVIEW.

First Iteration: basic
For this iteration, I worked with Juliette and Bryn.

Our Code

Our Robot

Side view

Our robot in action

Our robot sensed the edges of tape in order to stay on the line. This worked pretty well. I should note that while we built the robot during class and started the coding, that my groupmates finished the coding outside of class at a time when I could not be there (I had another class). 

Second iteration: proportional controlled

I worked with Juliette for this iteration.
The inspiration for this iteration was to simultaneously make our robot go faster and follow the line more accurately. I think we accomplished both of these goals.

Our code

Our code takes in as input a value from 0 to 100 measuring light going from light to dark. Then using that input, controls the speed of the car using a little algebra: 20 +/- ((52-lightVal) * .8)

• 52 represents the number halfway inbetween the dark tape and the light table. We found this by going up to the table and measuring it.
• 0.8 we found by iteration. We started with it being zero, then 1, then oscillated until we found this sweet spot.
• 20 represents the speed that each motor should go when the machine goes straight. We picked this number to be so low so that our robot would be more accurate. If we made this number higher, then there would be more movement between measurements, making our robot less precise.

A video of our robot - notice how much more efficient she moves

Here we used proportional control to get our motor to rotate exactly 90 degrees.
The different charts are using different constants,

Random other

None of these things really fit in with any other category or topic, but I think they are still worth mentioning. You might group them under potential tools for final projects, but I don't really think that my group used any of these tools directly.

Other #1: Camera manipulation

Code which shows moving objects

On this day we visited Tufts and Chris showed us around. We presented our two final ideas for our final projects. But, one of the coolest things we did was manipulate images in LabVIEW. Hande and I worked together. First we wrote code which displayed items from the camera in the computer. Next, we edited to only show moving objects by subtracting out the background. That code is above. We also wrote code which filtered everything but red. This was fun because Hande and I spend most of our time goofing off in front of our computer trying to see what would show up as red or how fast we could wave and have it still show up on the LabVIEW display.

Other #2: Bluetooth

Code which receives messages via Bluetooth and runs a car

The task this day was to build a remote controlled car. On this day our class was grouped by project groups. Then our project groups were paired up. My group got paired with Bryn and Juliette. My project group worked on building a car and coding it to go forward. Bryn and Juliette coded the "joystick" which sent messages to the car, telling it how fast to go and in what direction. Then we had a competition between the our car and the other half of the class' car.

Other #3: Pickles

Our pickle intstrument

Today we worked with PicoCricket and we made a musical instrument using a delicious pickle. This device measured the resistance between the two resistors (what look like miniature jumper cables attached to each side of the pickle in the picture above) and translated that number into a frequency, and played the note corresponding to the frequency value. This was fun. We, however, did not use PicoCricket in our final project as it does not have the same ability to measure resistance.

However, this programming environment was much nicer and much clearer than LabVIEW.  Instead of wiring pieces together, you fit together the pieces which looked like puzzle pieces. So, the problems with LabVIEW, namely all programs turning into a scrambled mess of wires, did not occur in PicoCricket. I am sure that there are other issues when programs in PicoCricket become large, but our program here was fairly simple and this is the only programming that I have done in this environment.

LabVIEW simulations

We started our three day work on simulations by first working in an environment which we were reasonably comfortable with: LabVIEW. Our task was to model the movement of our motor going from 0 to 90 degrees. I worked with Bryn on the simulation module.

Here are some waveform graphs where we changed the value of our initial velocity and our constant. The different colors are from running it multiple times and recording all of the values on the same graph. These are actual graphs from recording values from our NXT. 

After we saw what happens in "real life" we started to simulate it on our own.

Our Code

The above code models a motor rotating 90 degrees. The inner for loop models one motor moving across time. The outer for loop lets us represent multiple constants on one graph and see which constant would be most optimal based on our constraints.

Here are the graphs that we generated from the code.

These graphs show different constants. However, notice that none of these simulations show any values above 90 degrees. To remedy this, we need to add more information to our code. We'll do this in Matlab.

Matlab Simulations

So, as our course description involves modeling in Matlab, our class spent two days doing various exercises in Matlab.

First task: fibonacci. [Aside: one of my other professors, Randy,  has this joke that goes something like this: if somebody were to guess the major problems in computer science by just observing exercises given, they would that they are fibonacci numbers, factorials, and the Towers of Hanoi numbers.]

Our fib program

This calculates the nth fibonacci number given the mathematical equation derived for the fibonacci numbers. A design decision that we made is we calculated the square root of five once, stored it as a variable, and then used it the three times in the equations that we needed it. We could have calculated the square root of five each of the times that we needed, but that would be less efficient. We also let the variable n be defined on the interaction panel so it was easier to test, since we could pick any arbitrary n without changing our code.

Second task: Car Update.

Our car update program

This program had some question that went something like this: a car rental company has two locations, A and B. Three percent of cars leaving B end up at A and five percent of cars leaving A end up at B after a week. So, this program changes the value of 'a' and 'b' which are the number of cars at each respective location. This program works for arbitrarily large or smFourtall values of 'a' and 'b' despite our professor's anxiety over dropping cars.

Third task: Car Loop

This program uses the car update script and calls it 52 times, simulating a year at the car rental company. This also plots the values on a graph.

Fourth task: Simple DC motor

DC motor code

Plot that this generates

This program simulated a DC motor as described on the page outlining the assignment. Here is a drawing stolen from that website:

Diagram of a Motor

Physics scares me, so it was nice that my partner, Bryn, was extremely comfortable and skilled at physics. She interpreted all of the scary symbols and equations, so the combination of our skills resulted in us being the first ones done with this painful excersize.

Fifth task: Develop a proportionally controlled motor.

Code for our proportionally controlled motor

It was an easy add-in to just add proportional controls to our code from the previous excersize. All we did was changed Vt to be (90 - alpha). [We also made our code after an amount of time, because we wanted to capture the oscillating tail of the motor.]

Sixth task: Develop a derivative contolled motor.

Derivative Motor code

So this code is also not very different, even though it looks much longer. This is because we also added in a variable "last bad" which measures the last time that the change in angle was greater than .1 degrees. The derivative control part is we changed our angle to be some constant times 90 minus alpha plus some other constant times the change in angle. We found that that we minimized last bad to be .0430 when the first constant was 15.2 and the second was 1.3.

Plot of Motor using derivative controls - optimal

Wrapping Up - Final Project

So, here is an outline of the Wendy's functions:

• Follow people with eyes.
• Open and close eyelids to "sleep" when people are not around and be "awake" when people are in front of her.
• Perk up her eyebrows when people are around, and rest eyebrows when people leave.
• Talk to people when she hears people
• "come closer" when people are quiet
• "hi" or "hello" when people are louder followed by "Hmmm... interesting" or "Tell me more"

Here are some videos of Wendy interacting with people at the engineering demonstration at Wellesley. I should note that she worked much better at the craft fair on Saturday, but, alas, I have no video of this. We finally got her to sense better when our instructor procured a backdrop for us, but she still was not functioning as well as she did in the lab.

I would like to add some commentary at the end, as an overview of this whole project.

Next time, I wish we had concentrated on doing a few things really well instead of doing a lot of things. We wasted a lot of time doing things that we had no hope of completing (like turning the head 360 degrees which would involve constructing a neck, completely reconstructing Wendy's brain area, and programming something to tell it when and how to turn.) We could have used that time more constructively.
On a similar note, I wish I would have spent more time programming the eyebrows or thinking of something for them to do. I spent no more than 15 minutes programming the eyebrows including the time I spent thinking about coding the eyebrows. Maybe if I had spent more time, they would have done something interesting and unique.
Our group also wasted a lot of time on communication errors. I had a plan for the eyelids, but my group spent time fruitlessly working on them, time that they could have spent doing something else. I wasted time tinkering with Christine's eyeballs, and I'm sure there are more instances of this that I have blocked from my memory.
A related issue was that we had integration issues. It took us longer that we would have expected to assemble our head and it required some redesign. We also waited until the end to do things like add casing to the "brains", so we had no time to print our something with sheet plastic shelving and we had to settle with a few delrin rods to support all of our motors and gears.
As an overall reflection, it also would have been better to have spread out the work more evenly across the time that we had instead of waiting until the last few days before the puppet was due. We should have anticipated that it would take quite some time to put everything together.

Building - Final Project

I was responsible for constructing the eyebrows and eyelids, so I'm going to outline here the construction of those two elements and their integration into the rest of the head. I also took responsibility for the artistic side of the project, which I will also outline here.

Eyebrows:

The inside of her head

Her face

I originally planned on making the eyebrows out of delrin and painting them. However, my first set did not work (the hole was too big) and I ran out of time to iterate. So, instead I ran with an idea that Chris gave me. He suggested that I make them out of craft material and attach them using a lego connector piece. I made the eyebrows out of paper mache and them painted them with brown paint. I then attached, using a glue gun, a lego piece which connected a lego rod to the paper mache. As you can see, they broke sometime during our demonstration. After duct taping them back together, they worked. For the presentation at the craft fair, I cut new eyebrows out of a plastic plate, painted them, and used those instead of the paper mache ones.

To make the eyebrows move, I used a gear chain. This way, one motor could spin and rotate one gear, which would move both eyebrows. I had issues with this, as the gears would come apart and stop moving each other, which I solved by connecting the two long lego pieces which held the gears with legos holding them in place. This working was all dependent on the spacing of the two holes which the lego rods went through which were precisely 6 lego units apart.

Eyelids:

This was insanely difficult design problem. The design of the eyelids was constrained by the eyes and the face structure. Our first problem was cutting the ping-pong balls in half. We tried to hacksaw them in half, but that was not so effective because it was hard to cut the slippery, spherical ball precisely using a saw. What we ended up doing was starting the cut using the saw, and finishing using sharp scissors.
All of my ideas for opening/closing the eyelids involved a rod going through the diameter of the eyelid which they would rotate around. However, this posed many, many problems. First, this rod could not actually pass through the parts where the eyes are. Second, we could not drill a hole in the face.

After brainstorming and rejecting many bad ideas (the worst of which involved flipping the eyelids up instead of rotating them which would make the lids visible and in an awkward position covering the eyebrows when the eyes were closed), I constructed a compromised mechanism.

Eye mechanism from the side

Eye mechanism close up

I took a long piece of piano wire. Now, instead of having it go straight through the diameter of the eyelid, I curved it so it followed the curve of the ping-pong ball and then taped it in place using copious amounts of duct tape. I only did this one eyelid. I tried to do it with both, but the process of precisely curving the piano wire took a really long time and it would not be an efficient use of time. Instead, I taped it just inside the other eyelid using large quantities of duct tape and on the other side I taped inside a thumb tack, the top of which I cut off using scissors. Then I taped this mechanism on the back of the face using duct and masking tape.

My next task was to design the mechanism which would make the eyelids open and close. My first idea was to use string and wind it up and back. I never implemented this as I knew that there must have been a better way. My next idea was to use lego rods, but I needed something with variable length, so this idea was scrapped. The idea that I implemented was a combination of the two. The motor turned a rod which had smaller rods connected at a 90 degree angle. These small rods never touched the eyelid. Instead, duct tape connected the lego rod and eyelids. When the small rod rotates up, the top of the eyelid is pulled up, closing the eyelid. When the small rod rotates down, the top of the eyelid is pulled up, opening the eyelid.


Art-y things:

Wendy without paint or the back of her head or hair did not look like a person. First, Christine and I paper-mached a head. I made the structure which we paper-mached on using cardboard and a plastic bowl.

Our paper mache head - before we painted or cut it

Next, I painted the face. This took some time.  I also had to paint things multiple times, because the paint chipped easily. Furthermore, I'm not a very good painter, so I had to wipe things off and redo them often. Fortunately, this was easy when painting on delrin, because dry paint scrapes right off easily. After the head dried, like a day after we made it, I cut it out to fit over the head and painted it peach. Christine made the wig which we draped over the paper mache. We then decided that it looked like me, so we also added one of my hats (for those who don't know me, hats are kinda my thing).

Wendy before paint and a jaw

Her face - painted

Wendy and I - I always did want a sister

Coding- Final Project

In order to build the eyes and eyelids, Christine and I needed the materials that Hande ordered. So, while we were waiting on materials, we started coding our eye movements in LabVIEW. However, in order to code our eye movements in LabVIEW, we needed to understand how the ultrasound sensors worked. So, we started there.

We tested the ultrasound sensors using some trivial code which said read the values of the sensor and print them out to the screen of the NXT until somebody physically stops the program.

Trivial code which reads the value of the sensor.
Lack of icons because the version of LabVIEW
on my computer is experimental, so I couldn't load the
NXT module. 

We found that the ultrasound sensors sensed pretty well. They printed out values between 0 and 255, where 0 is when you have your hand on the sensor and 255 is the maximum value. They were a bit sketchy when objects got too close (within a few centimeters of the sensor) and they would oscillate between the real value and the max value. However, we did not think that this would be a detriment to our project, since we would assume that nobody would walk within a few centimeters of our puppet. We also found that the sensors were extremely accurate and would pick up values when we waved our hands about half a meter in front of the sensors.

Ultrasound sensors configured to test values

So, after we tested our sensors, we started coding. However, minutes into our coding, we decided that it would be too complex to start with code. Rather, we decided to reason about our code on paper, and then translate that reasoning into LabVIEW.

An outline of our code

An outline of our design decisions:

•  Three sensors
•  5 angles for eyes based on which sensors are currently sensing somebody: -60, -30, 0, 30, 60.
•  The direction that the eyes move in depends on which angle the eyes are currently at and which sensors are currently sensing somebody
• For example: Wendy just woke up, so her eyes are at 0. However, Bob over to Wendy, and only is infront of the first and second sensors [sensors numbered in order]. So the eyes move to look at Bob, which means that the motor controlling the eyes goes backward until it registers -30 degrees. However, if Wendy hadn't just woke up and instead was watching Bob's friend Carol who was to the left of Bob, covering only the first sensor, the motor goes forward until it registers -30 degrees.

We spent a really long time iterating on our code for a variety of reasons.

• We originally planned on our range being only 90 degrees, instead of 120 degrees. However, this was not that noticeable for people who were just left or right of center. This was the easiest fix we made, as we just had to change our constants.
• In our first version of our code, we measured rotation every single time we wanted to use it. Now, this is absurdly inefficient. Measuring rotation is expensive, and doing it two to four times every single time around [I would assume] would make our eyes too jerky and not particularly creepy. So, instead of measuring rotation every single time we wanted to use it we just wired the value to every spot that we used it. I realized this strategy was too inefficient when we were not particularly far into it, so we never actually came close to completing or testing this code.

Second Iteration of our code

• So, the second (and the first for that matter) version of our code was coded under the assumption that only boolean values could be entered into case structures, an assumption based on experience with other programming languages and lack of experience with LabVIEW. So, these values were generated by comparing the rotation value to the our target values. We then made a really complicated case structure combined these booleans with other boolean values which asked is there somebody in front of my sensor to determine whether the motor for the eyes should go forward, backward, or brake. However convoluted this scheme was, we did not know a better way, until in class the next day, Chris suggested a new way.
• Our third version of the code entered the rotation value into the case structure. This way, we could make cases based on ranges, like 3-27 degrees instead of teasing out the ranges from a bunch of booleans. [Tip: the code will not compile if all cases are not covered. For True/False cases, it comes already preset. If you use numbers as input, like we did, you either need a case called "default" or cases that cover +/- infinity, by having one case that goes from ..-minVal and another case that goes from maxVal-.. . The ".." signifies and to infinity.] We still had nested case structures, to tease our which sensors were currently detecting something. We also changed the values of our rotations to be not the actual value, but the value mod 360, which made this value reflect the angle on the circle. When we ran our code after making this one change, our eyes kind of followed our hand, a great improvement from our previous iterations.

Third iteration of the code- this case is simpler than most

• The only differences between our third iteration and what we ended up at the end were minor.
• Instead of aiming for a singular target value, we aimed for a target range, from +/- 2 or 3 from the target value.
• We got rid of the shift registers. We tried to implement some proportional controls, and that made our code work even worse, so we gave up on ever implementing derivative controls.
• We noticed that sometimes the first value was not particularly accurate, so we decided to throw away the first reading.
• We also noticed that sometimes, when there was not a hard background behind her, that she would always register that somebody was in front of her, so I added a case structure that said if the value is greater than 180, that is if there is no close background, then just let 180 be the background. Else, let the measured background be the background value. This makes the code more modular, since it will work regardless if there is a close background or not.
• I also connected the pink wires into the case structure. This really didn't change anything, at least from observation, but it makes the code more logical, since the pink wires show sequence.

Final iteration of code broken up into two parts because
it did not entirely fit on one computer screen.
The other case structures control the brows and lids.

After exhausting all of my time on they eyes, I did not really have that much time to invest in creative coding for the eyebrows and eye lids. My first iteration was did the exact opposite of what I wanted (close eyelids when somebody was there, and open when nobody was). My second iteration worked. The code for the eyebrows and lids are almost the same. They are proportionally controlled and move only based on whether any sensor is sensing somebody or no sensor is sensing somebody. I should note that the code assumes that the eyelids start closed. We ran into issues here when we reset Wendy without resetting her eyelids. However, I cannot think of a good solution to fix this - the NXT automatically resets the rotation to zero whenever it is restarted. I could have assumed that the eyes start open, but this makes no sense.


Jaw:

So, I was in no means responsible for the jaw. However, I did help out in the coding. [Also, all of the sound recordings are my voice.] Hande coded all of the individual phrases, moving the jaw to mimic the motion that a human's jaw would. I helped her integrate all of the phrases into one file "mouthGo.vi". Here is the design process from after Hande coded all of the individual phrases until we finished:

• We needed to hook up the jaw some kind of sensor so her speech wouldn't be completely routine. Also, we could not use the three ultrasound sensors because each NXT device only has room for running 3 motors, and the NXT hooked up to the ultrasound sensors was also hooked up to 3 motors (eyes, eyelids, eyebrows). So, we decided to use a microphone. We wanted to have a different sensor and our options at the last minute were limited. It was also fun to try out a new sensor. We also could use this to have three states: "not present", "quiet but present" and "present and talking".
• "not present" -> do nothing
• "quiet but present" -> say "come closer"
• "present and talking" -> start a conversation
• Next we tested the microphone. We found that the microphone was extremely sensitive and the difference in background noise between different places made it impossible to have an absolute range for "quiet but present" and "present and talking". So, we used the difference between the current value and the background value for input, rather than just the current value. We also noticed that the variablity in any given place was about 20 units, so we set our "quiet but present" to be 15-30 above background, and anything above that to be "present and talking."
• Finally we combined everything into one big while loop. So, every time around, we measure current sound. Then we subtract off the background value and hook that number into a large case structure. We had 3 cases corresponding to the three states defined above.
• "Not present" was empty.
• In "quiet but present" we pasted in the code for "come closer."
• "Present and talking" had the largest amount of code. We had two case structures: one for the greeting and the other for the talking. However, we weren't sure what to put in the case structure. My first thought mod-ing a random number by 2. But, I couldn't find a random number so I used the sound, since this number was random enough. So, we hooked up this number mod two to the greeting block. If the number was equivalent to 0 mod 2, then she says "hi", else she says "hello." She then waits for awhile for the person to talk back to her. Then if the floor of the number divided by 2 was equivalent to 0 mod 2, then she says "hmm... interesting" else she says "tell me more."

First half of the final code

Second half of the final code

I've embedded some tips, but here are some more general tips.

• LabVIEW lets you label your code, so it makes it a lot more clear if you use that feature. I wasted hours and hours looking for a bug that probably could have been avoided if I had labeled everything.
• Before going intense bug hunting, first check that all of your ports are labeled correctly. Incorrectly or forgotten port labels were the majority of our bugs. Sometimes it is execution, not design.
• Notice, that the "clean-up" button does not always clean-up the same way. In addition, with our final version of the code, when you press that button repeatedly, it swaps all the elements around and sometimes makes the area larger or smaller. This makes it confusing to resume working exactly where you ended. So, be very careful right after you press that button, so you don't end up changing a large chunk of code. I did this. It took me hours to undo.
• It's easier to code things in chunks in different files and copy the contents of each of the different files into a new file. Hande did this with the code for the jaw, where each phrase was coded in a different file and combined in the final file. Christine and I did this in the eye code by coding up the brows and lids separate from the eyeballs and pasted them all together in a final file.

[As a side note, the coding part of this project reminded me of this comic: http://xkcd.com/844/. ]

Modeling - Final Project

So, after we decided that we were going to construct a Wendy head, we defined the scope of our project and split up the tasks. I will spend the majority of the rest of this blog detailing the parts that I was responsible for, the eyelids and eyebrows, and the parts that I played a major role in developing, namely the eyes. I will also touch upon the parts that I did not have a direct hand in, namely the jaw and the structure of Wendy, which Hande was responsible for.

A preliminary sketch of Wendy (sketched by Christine)
Note: this was sketched after Lyn walked by and
after we had scrapped our two-dimensional eye ideas, as modeled below.

So, first we thought about our particular parts individually.

The eyebrows were fairly straightforward because they are isolated from any other moving parts and my first idea of having them made out of delrin sheet plastic, but having a (tight fit) hole in the middle to put a rod connected to some connected gears, one of which would be hooked up to a rotating motor. This design would change as time progressed, but only slightly. These changes will be outlined later.

The eyelids were not as straightforward and their design completely depended on the design of the eyeballs. Christine's first idea for the eyeballs was to have them be two-dimensional. As you can see in the prototype below, the cornea of the eye would be a gear, perhaps covered in paper or something. Then the whites of the eye would be paper. The eyes would move when the gears moved across the track. The two-dimensionality of the eyeballs I tried to reflect in my design for the eyelid. I imagined them as an almost like the curtain in my dorm room which would roll in and out when she blinked her eyes. However, before I worked out all of the details, our professor walked by and suggested that we try to make the eyelids/eyeballs three-dimensional. This totally changed Christine's design, which turned into balls rotating on sticks. I decided to punt the design of the eyelids until after the design of the eyeballs, as to design the eyelids, I needed to know the constraints that the eyeballs would add. However, we needed to buy supplies (a task that Hande took on) and so I arbitrarily decided that the eyelids would be made out of ping-pong balls. However, I also knew that if ping-pong balls didn't work out, then I could try to work something out of materials scrounged out of the craft table in the lab. 

An early prototype of Wendy

Brainstorming - Final Project

After we chose partners, our first task was to brainstorm ideas for our final project. This project was left very open-ended; our only constraints were that it had to be a kid-appropriate puppet that used everything we learned this semester, or at least used pieces cut out from the laser cutter and some "smart" functions.

So, Christine, Hande, and I went back and forth with ideas. Here are our four main contenders and our reasoning for rejecting our three rejected ideas.

1.) "Wendy Wellesley" She would be a bust of a person. She would interact with whoever walked by her in her display case in many different ways; she would follow them with her eyes, make faces at them, offer words of condolences, and rotate her head 360 degrees. These actions would be triggered by her sensing her surroundings using a camera to sense where the people in front of her were, and a microphone to sense the words that people are saying. We considered trying to sense what people were saying, but we really don't have the expertise to do such sentiment analysis.

We ended up going with a version of this puppet. We heavily modified this plan and a description of what we ended up with will follow in future posts.

2.) Dancing Elephant. This elephant would have a repertoire of learned dances such as the Macarena, YMCA, shopping cart, Tunak Tunak Tan, etc... When a person called out a dance, he would dance that particular dance to music. Also, when he wasn't dancing, he would have some other reactions to people. Originally, we also thought that this elephant would have mannerisms similar to our professor, but our professor told us that it would be too creepy to do so.

This idea was the most popular with our classmates. However, after consulting with our professor, we were fairly certain that this idea was way out of reach. We then tried to modify this idea to make it more feasible (by turning the elephant into a marionette puppet and only having one dance, or perhaps instead of learning a particular dance, having one side of the marionette controlled by the user and the other side controlled by a program) but these ideas did not resonate the same way that the original did.

Sketch of dancing elephant - courtesy of Christine

3.) (Dancing?) Shadow Puppets. I love shadow puppets and thought it would be cool to make a shadow puppet. This puppet would consist of delrin sheet plastic connected by delrin rods on the pivot joints. The motors would control each of the limbs of our puppet directly (we were afraid of using string, because dealing with tangled string would be too much of a headache). All of the plastic would be in a box behind a sheet and a light would shine on the sheet, revealing only the shadow of the plastic. This puppet would execute a predetermined show. I thought it would be a little easier to execute, because we wouldn't have to cover the delrin plastic with anything and nothing would have to be three-dimensional. It would be tricky to hide the motors, but that would be one of the only concerns.

This puppet wasn't very popular with our class and therefore we abandoned it. We also thought that it would be too simple, because it did not use any complicated sensors; it just would use a simple touch sensor which would signal the start of the show, but that would be the extent of the interaction.

4.) Sock Puppets. This project was inspired my dad. I used to complain that I did not have a radio in my room and to compensate, he used to throw sock puppet shows to get me to bed, complete with songs and everything. So, for our project, we would have some puppets made of plastic controlled by some motors which would be covered by some socks. These puppets would interact with each other and the audience, which it would sense with a camera, and give an interactive show similar to the interactive shows that my dad use to throw. We also thought it might be fun to have them be male and female puppets where the male puppet would react to low voices and female puppet would react to high voices.

This puppet idea also wasn't popular with our class. We also did not have a really clear vision of exactly what kind of show we wanted to throw. For any given show idea, only 2 of the 3 members of the group agreed, so we did not have a clear direction. For the above reasons, our group decided to drop this idea.

Sketches of 1,3,4 - courtesy of Christine