Sunday, April 28, 2013

babysitting the plants

So gutting the bulbs might have been my favorite part of this project so far.
It involves a lot of broken glass/coaxing/brute force. One bulb broke in my hand because I squeezed it too hard (I had gloves on! and it was old). Another bulb got a hole punched through it due to an unwieldy blow with a screwdriver... you get the point. but I LOVED it.

anyway, Cabrina and Julie were away this weekend so it was my turn to baby sit our plants...




...which translates to instagram photoshoots. SO. CUTE.

Friday, April 26, 2013

looks like model IRL

Yay!


While I built our looks like model out of legos (so we could figure out good dimensions for the actual solidworks piece), Julie & Cabrina tried to fix the bug in our turning program with the added weights.

Here's a picture of me making it.


Thursday, April 25, 2013

looks like model sketch


solidworks side (x2)

**updated GEAR support shelf (x1)

motor/motherboard shelf

Tuesday, April 23, 2013

testing, testing, testing



programming.

The first thing that we had to program was to turn the motor, and thus the pulley, and thus the lightbulb-terrarium 180 degrees. This is our first shot at it, without really controlling the speed, other than having it proportional to keep it from wobbling back and forth once it completed the turn. We'll go back in a bit to work to change the speed, because as is, it'll probably be too fast of a turn which will cause the terrarium itself to spin and possibly get tangled and maybe hit each other and all sorts of undesirable stuff. But after testing a bunch of gains...


Now, to integrate these movement subprograms into the main light sensing program.


Choosing an arbitrary value for "direct sunlight" (values < 20), we programmed the motor to turn away. Once it turns away, it wait until the sensor on the opaque side of the bulb is no longer experiencing "direct sunlight". The wait is in there because once it begins to turn away and goes into the 'then' subloop, sensor 3 will begin picking up that it isn't in direct sunlight, because the bulb has JUST begun to turn, so of course it isn't experiencing direct sunlight yet. A wait for the amount of time it takes for the bulb to turn keeps this from happening.

Friday, April 19, 2013

our redone works like model

after presenting our works like model, Lynn suggested that we change our pulley system (that we tested on day 2) into a gear system...

This


instead of this:


 The gear system was actually a really great idea (I wouldn't expect less from Lynn I suppose.) While the pulleys did work pretty well, they did tend to get misaligned a bit (there was a lot of torque and friction/not enough friction and all of that nasty unideal stuff). With gears, although there was still a bit of the torquing problem, the gears turned altogether pretty nicely. Although we did get the solidworks files done before we realized that we wanted to make the turning mechanism out of gears rather than pulleys, it turns out that the large gears (x3) were the same size as our three pulleys, thus we only had to add two more holes for the smaller gears... thanks Lego, for being pretty consistent!

Wednesday, April 17, 2013

blogging is hard

I'm going to implement a slight change of format for the final project documentation... here's a little preview


more to come soon...

Tuesday, April 16, 2013

FOLLOW THE LIGHT!

Final Projects!


So, my final project proposal was to try to bring in more natural light into the engineering lab by using an array of mirrors of some sort to carry light down the tunnel and in through the window, or to somehow amplify the amount of ambient light that is already in the tunnel. Surprisingly, this idea was quite popular with other students. However, this wasn't quite exciting enough for me so... I was assigned to another more, erm, potentially aesthetically pleasing project. After a day of brainstorming...
Hanging Terrariums! Copyright All rights reserved by Old Chum
The "Little Hanging Possum" Terrarium. By Botany Factory

Lightbulb Terrarium. Via the Hipsterho.me

SO CUTE. AMIRITE???
Our idea is to basically create a (very aesthetically pleasing) system to take care of tillandsia. These air plants are particularly sensitive to direct sunlight and humidity. While they enjoy lots of humidity, direct sunlight is another story: though they need lots of bright light, they will basically dry out and "get cooked by exposure to direct sunlight" (quote from Tom @ the greenhouse!).  Thus, with our hanging terrariums, we want the bulbs or globes, to somehow automatically protect our plant from light thats too harsh.

I'll go into the how to next time (:

controlling thermal systems.

Figure 1. Experimentally measured heat curve. (K/s)

In order to properly model this thermal system, we needed to find Rth and C of our system. To do this, we measured the temperature of the system (using test_thermal.m) as we applied power over a five minutes, producing the heat curve in Figure 1. Then, solving for Rth & C...

Rth = (∆Tf/P) = (Teq - Tair)/P
Knowing that P = 6.5W
Tair = 303.72K
Teq = 426.56K

so Rth = 19 K/W

C = (P/initial slope)
Pt 1 = (10,308.8), P2 = (33,336.2)
Initial Slope = 1.187
C = 5.5 J/K

Now, plugging these new values for Rth & C into heatsim.m and running the simulation...

Figure 2. heatsim.m with new values of Rth & C. (K/s)

To compare Figure 2. to Figure 1., we will study the trend within the temperatures of focus aka room temperature (303K) and higher. From there, it looks like Figure 1. is a part of Figure 2. - the curves look very similar once Figure 2. passes room temperature. The highest temperature that both the simulation and the actual system get to is the same - approximately 426K. It seems like the value that we calculated model this system pretty well!

Now, to create a bang-bang control temperature controller for the actual system...

Figure 3. Bang bang temperature control program.

Figure 4. Graph of a bang bang temperature control. (K/s)

In our graph, we can clearly see the difference between the simulation and actual system. The temperature of the system oscillates, due to when the power is on/off, which is based on just whether the actual temperature of the system is above the desired temperature - 340K.

Now, implementing proportional control...

Figure 5. testthermal_prop.m Proportional Temperature Controller


 Figure 6.  Graph of Proportional Control  (K/s) (Gain =2.7)
When we set our gains to be very low, the control set point is never reached because there is not enough energy being put into the system- more energy is being lost, and thus, the system is cooling down rather than heating up or maintaining the ideal temperature. When the gain is too high, however, it overshoots the control set point because too much power is being applied in proportion to the amount it needs. However, we were able to find out the perfect gain for our system by calculating it, knowing that the system would never be able to go above and below certain temperatures. Our calculated gain was 2.7, and it worked quite well as you can see from the graph.

Now, for our final program, we implemented integral control.


Figure 7. Integral Control Program

To do this, we simply added another term to be accounted for in the error calculations- the integral error. You can see here that the frequency and the amplitude of the fluctuations in comparison to our proportional control graphs are both reduced- that is, the system gets closer, and stays closer to our target temperature of 340K. After testing out a few gains, we found that a good gain for our system was 0.35, after testing values that ranged from 0.2 to 0.5. We also adjusted our proportional gain to be 2, which slightly less than our "ideal" value of 2.7 in the proportional-control only program, since integral error will be added to and thus help "boost" the error correction.


Figure 8. Integral Control Graph 1. (K/s)

 Figure 9. Integral Control Graph 2. Blowing on the system. (K/s)

In this final graph, we blew gently on the system a few times over short intervals; the fluctuations are due to the cooling/heating up of the system. This graph shows that the system adapts pretty well: despite all the fluctations, it stays pretty close to 340K!

Tuesday, April 2, 2013

coffee cup with heater simulation

controlling the temperature of coffee with a heater. (bang-bang control)

Here, I modified the heatsim.m code a little bit in order to have the program always pick up any changes in the coffee temperature over the defined period of time. To do this, I made the ambient temperature and the initial temperature manual inputs, and added a variable to represent the desired temperature, as well as different values for power- basically power on or power off. Then, I added an if, then statement, telling the program what P value to use according to the current temperature of the coffee.
Using ambient temp = 293, current = 400, and desired = 340, the program produced a graph like this:
We can see the line is very wobbly/jerky, which is concurrent with bangbang control.

coffee cup simulation

Q1. How does cooling behavior change if Rth & C change?

Well, Rth is the thermal resistance of coffee... so it makes sense that if the resistance is increased, then it should take longer for the coffee to cool down, and if it is decreased, then it should also speed up down the cooling process. With C being the rate of change of thermal energy vs temperature rise, we should also expect the same relationship- if there is a positive change, then it should slow the cooling process since there is energy being added or increased in someway, while if there is a negative change, it should speed up the cooling process since energy is being lost.

Looking at the equation
dT= ((∆t)/(Rth*C))dt
We can see that Rth and C are in the denominator, thus if either of those values are increased, dt will be increased.

Q2. Adding a heater: What is a good P value if we want our room temp coffee to heat up to the Starbucks ideal 84 degrees?

This situation is governed (well, modeled) by the equation...
dT = dE/C = [ (P/C)-((T-Tair)/(Rth*C)) ] dt
 Since we know that Tair = 293K, and our ideal temperature is 357K, dT/dt will be = 357-293 = 64. Now, solving for P, we get a value of 75.36. Plugging this into our heat simulation program in MATLAB, we get this plot...
We can see that it levels off in the 350-360 range. Indeed, printing the final temperature value in MATLAB gave us 356... close enough (error due to rounding, probably.)



Monday, April 1, 2013

intro to modeling!

... of the mathematical type.
This is very handy for when we want an idea of how a system works without having to actually observe the real system itself (saving time, and money!).

Using MATLAB, we can model the movement of cars to/from car rental places in Boston to Albany. We are told that 5% of the cars that start in Albany end up in Boston by the end of a week, while 3% of the cars in Boston end up in Albany by the end of a week. We want to see how the total number of cars change by the end of the week where the total number of cars in each city start at 150- and the totals at the end of successive weeks, or even a year!

We can model this behavior in MATLAB very easily and pretty quickly, versus waiting around to count the actual cars a year later.

car_update



At the top I made a note to define the starting values of a & b to allow the first calculation to run successfully. Running this program again and again gives us the new totals at the end of each week. We can make a program to run this a certain number of times by making another program that calls car_update and makes it run... say 52 times, thus modeling the totals after an entire year.

car_loop


This program gives us 118 cars in Albany and 182 cars in Boston. It also gives us this nice little graph of car total versus i, the number of weeks.
We can see here that sometime after week 20, the rate of change of the car totals levels off... meaning Boston and Albany neither gain nor lose cars. We might say that it has reached equilibrium, since the number of cars leaving Boston to go to Albany exactly counterbalances the movement in the opposite direction, from Albany to Boston.

Typing this program didn't take so long, relative to the a year, which would be how long it'd take to actually observe these changes in real life. Thus, we see the benefits and ease of modeling the movement of cars mathematically, one useful aspect of MATLAB!