a final reflection

project description : automated shading system for tillandsia

Tillandsia is really easy to take care of. These plants need minimal water, they don't require dirt and therefore don't require repotting... they just don't like direct sunlight. So, we fixed that part.

Using recycled light bulbs seemed to fit perfectly with the theme of "follow the light". It was also much cheaper than buying special pre-made terrariums (and more eco friendly!) In addition, the small enclosure provided a good 'greenhouse' in a way- when watered, it tends to get pretty humid within the light bulb, which tillandsia loves! These bulbs that our plants are kept in are half painted. This is to provide a side that the direct sunlight won't go through completely. We used two light sensors: one on the front, clear side, and one on the opaque, white back. The light sensor in the front continually tests for whether or not there is direct sunlight- and when there is, it will command the bulb to turn and hand over the command for sensor two (there's a wait for the duration of the turn to prevent antagonistic commands within that turn). From there, sensor two will test to see whether or not the direct sunlight has gone away- and when it has, the bulbs will turn back. The turning mechanism is a simple gear rack attached to a motor. This motor is set to 'pulse' in two ways: using the shaft encoders, the motor will turn 180 degrees in response to direct sunlight, and then back 180 degrees when the direct sunlight has gone away. 

We did run into quite a bit of trouble while creating all of this though (as indicated by our joyous cries at the fact that our project actually worked when showing it to people).

Among the things that we changed from the initial conception of our device was most notably the turning mechanism - originally we favored a pulley system over a rack and pinion system. But the rubber bands slipped a lot due to just the weight of our light bulbs, and getting the rubber bands on just right was hard enough... luckily, we were inspired by Lynn to replace our pulley system with simple gear train! Other than that, a lot of aspects of our device stayed pretty close to our initial prototype, with just some small changes in dimensions/design of the box-frame. Unfortunately, our program was very finnicky up to the day that we presented. Luckily it worked... We're still not sure what went wrong there. Depending on the day/configuration, the motor would not turn a complete 180, or would go above 180 - this changed from day to day, even without the plants being attached. We would have to change the power/distance/gains a few times before getting it to work again. Oddly, it favored the same inputs for gain/distance/power every time- but we had to change it, run it a few times, and then change it back for it to work... In addition, we tried multiple ways to try and slow down the speed of the turn, but unfortunately, NXT would not let us do that. The only way to slow down the NXT motor is to turn down the power - unfortunately, lower power = no movement for our system, since there was a lot of weight/torque/friction involved. But we got a lot of laughs and gasps of adoration at the sudden turn that our bulbs took, so I guess that's a plus. To be honest, we never really noticed how silly it looked. We were more frustrated by it I suppose...

Overall, there are many improvements that could be made if given more time. Things we were considering during this process were creating the box-frame out of wood for a better aesthetic; delrin just seemed like a sturdier fix. We were also considering making the gear/axle/bushings ourselves for better over all integration- with the legos + delrin in our prototype, there was a lot of torquing and in balance because the bushings wouldn't sit flat on the gear shelf. We also considered putting the entire thing on an actual curtain rod, since this is what our actual design called for... but PVC pipe is much cheaper. With our current design, the PVC pipe can easily be removed and the entire motor box/display can be put onto a curtain rod anyway.

The white "shielding" paint of our bulbs also has an undesired effect- you can't actually see the plants from the inside of the window ! However, acrylic paint was the best and cheapest option we had on our hands at the time (aka FREE and already on hand), and it demonstrated the point well enough. Ideally, we would perhaps coat it with a thin layer of spraypaint (more clear) or even perhaps tint it with tinted window paint (for cars? or sunglasses?).

Aesthetics aside, there is still one pretty big issue that we'd definitely like to fix given time. The turn of the bulbs is still slightly too fast for our liking. This can be easily fixed with a gear train to slow it down- the reason that we didn't do this is because we already had our gear support shelf printed out. An alternative solution would be to drive the system with a different motor that applied the same amount of power but turned at a slower rate. Either of these changes would make for a steadier motion, which would allow us to replace the (ANNOYING) piano wire with twine or hemp... for better aesthetics. (I'm a sucker for good looks I guess.)

Other add ons to our project would be perhaps a small solar panel array on the shelving box to power the entire system, which would make it very sustainable and much easier to go battery/cord free! In addition, we'd probably want to add a different controlling mechanism for deciding when to turn- instead of bang/bang control (aka, if it goes above a certain value, then turn), perhaps we'd have it check over a period of time to see what the change was like- if it was a cloudy, windy but sunny day, it wouldn't necessarily turn at a brief flash of bright sunlight. Another possible mechanism would be to add a temperature sensor and integrate those two things together.

Regardless of all the things we could have done, I'm very satisfied with my project. I feel accomplished, but it's great to know that there are so many possible ways of making this project even better. It was tiring and painful and frustrating, but the end product is something that I'm very proud of - and was very proud to show off during the exhibition!

All smiles! 

- Julia Um, Cabrina Kang, Julie Barron

FINALLY. FINALLY.

so, after our in class exhibition... we ran into a few problems.

EVERYTHING STOPPED WORKING. EVERYTHING.
The bulbs would turn when they weren't supposed to, they turned too far, they wouldn't turn when they should... the piano-wire suspension system was twisting and pulling in all the wrong ways... the hemp tied around the neck of the bulbs ripped... everything went wrong.

After a lot of frustration we figured out that the weird bulb movements were due to a problem with our soldering. The only problem was... we had already super glued everything.

shoot. me.

So a very long (and pretty) Saturday was spent indoors in the lab away from the nice sunshine ( i really wish the light tunnel project people had a working life-sized model that day), fixing EVERYTHING.
 Basically, we had to un-epoxy, unsuperglue, cut, rip, snip everything and then re do everything.
I'll skip the excruciating details... I already had to live through it once.

TO THE HAPPY ENDING.

putting it all together

After a few notch trials/printing... we finally got to put the whole thing together.

Over the weekend, Julie worked out the solidworks/laser printing, while I superglued the bushings to axles and assembled the gear shelf. I also replaced the hemp string that hung the bulbs with piano wire in order to get rid of the spinning bulb problem... which was basically a disaster waiting to happen (the spinning bulbs. and the bending/manipulation of piano wire... many nicks/cuts were sustained). Cabrina was brave and soldered our light sensors!

THE (SEMI) FINAL PRODUCT

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.

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.

looks like model sketch

solidworks side (x2)

**updated GEAR support shelf (x1)

motor/motherboard shelf

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.

- the final project -

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!

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...

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!  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!

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.)

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!

line following!

here's a little look at what our picoblocks program looks like...

The idea behind our program is that if we consistently start the robot on one side of the taped line, it will only ever have to turn in one direction if it moves off the line. Technically, this is more of an edge following technique rather then line following... but it has the same effect basically. Using a light sensor, we programmed our cyborg to go forward within specific values of the light sensor- when it was half on the tape and half on the masonite. When the path curves off to the left, the robot will end up on the masonite, which has a different value than the tape+masonite. Thus, we programmed it to turn to the left until it found the tape+masonite again. However, if the tape path veers to the right, then the robot will find itself on just the taped path, which also has a different value from the masonite+tape and masonite alone. Thus, we programmed it to turn to the right until it found the tape+masonite values again. 

picoblocks !

feedback & control.

After lots of building and tinkering with actual physical objects, we're now moving into a less physical (but equally exciting) block of EXTD160...

programming!

Using Picoblocks, an interesting, and very visually pleasing programming language, we are now writing programs for cyborgs... All named after disney princesses of course.

Meet Pocahontas.

She's very persistent. Well, we programmed her that way.

In the above video, we played around with the touch sensor; We programmed our cyborg to move forward until the touch sensor was activated; then we told it to back up for a small amount of time before heading forward again. Pretty useless program, but it was amusing. We changed it up a bit afterwards though, commanding Pocahontas to back up and then turn for a little bit after hitting something.

off on a tangent

This was my final art project last semester. What's the "idea" behind it, you ask?

Well, I'll answer that next week!

transforming motion

 Here are two examples of how rotary motion can be turned into rectilinear motion...

What I find interesting is that in Figure 114, they were able to create a "back and forth" linear motion by just removing the right number of teeth on the gear. Basically, the little "pinion" only acts on one side of the rack at a time, which forces entire rack to move in one direction, rectilinearly. Then when it runs through the entire side of one rack in less than a full revolution, it starts acting on the other side of the rack, and forces the entire rack to move in the opposite direction. 

In contrast, Figure 115 uses two pinions to help move a larger rack at once. While I can't quite picture what 115 does when it reaches the end of the rack...But I do see how it would drive the rack with equal force and velocity on both sides, which seems more reliable than just having one side being push/pulled by the mutilated pinion in Fig. 114!