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