More Progress on the Looks-like model

Today Ashley and I made a lot of progress on the aesthetics of the project. First, we completed the spheres, connected them to the wires they will hang from, added a light sensor to each, and sealed them shut.

They can now hang from their conveniently complementarily-colored wires!

The next thing we needed to tackle was the stand. We decided that it would not be too hard to make a wooden lamp stand using the laser cutter. After a few sketches, we created four Solidworks parts to create the stand.

Drawing of the base

Drawing of the platform

Drawing of the braces inside the stem

Drawing of the sides of the stem

Essie came in to help us print and we tested a set of notches in the wood we wanted to use before printing out the stand. After some troubles with positioning and issues with the laser not cutting all the way through, we had all the parts and our stand assembled very snugly!

Now, we will need to come up with a Lego platform for the cricket to rest above the three motors aligned above the three holes, and create a dome over the top to complete the look.

Looks-Like Model

After completing our program and adding a second "mode" in which the motors winch the lights up and down with a speed proportional to the light sensed, we focused on the physical design of the project. We had originally planned to house the lights inside of cardboard spheres, but these were not available. Instead, we created papier mache spheres formed around ping-pong balls.

These were cut in half and the insides were reinforced with glue at the suggestion of my roommate Cassie.

I made one extra as a test, and we poked LEDs into it and twisted wires to create a rough model.

We were a little scared at first to solder over the paper, but we got the go-ahead and created this much more sturdy version, complete with purple paint as well! 

We presented this as part of our looks-like model to the class.

The other part of our model was the winch and cricket assembly that will hold the hanging spheres. Our model is still crude because we have not decided on how we will raise these up, on some sort of stand, to have the spheres hang. For the moment we had them hang down from the edge of the table, though we want a "lamp" with a single stem so that it is more attractive and portable. 

Works-Like Model: Lights

On Tuesday, I tested how many LEDs we could light up with the cricket. At first, I found that it could light up up to 20 LEDs while still being pretty bright:

But then I ran into a problem. The on8 and on7 methods that Robbie wrote for us only work for one port at once, so we couldn't have port 7 and 8 on at the same time. To work around this, I made a block program that turns each port on for 2 ms at a time, switching back and forth. This means that they can both be on at the same time, but they will only be half as bright.
With both ports on the single LED connected to the yellow wires (port 7) is pretty bright:

 Here the green wires connect to port 8 and the yellow to port 7, so the bottom seven lights connect to port 8 and the top single light is port 7

But when only port 7 is running, it is REALLY bright:

I decided that 12 LED's is a good number to be bright while still having many lights in each group. On Wednesday, I asked Robbie about the ports not turning on at once, and he produced a magical solution (I say magical because changing the last '2' to a '4' in all the methods means very little to me).

Turns voltage high and low for ports 6, 7,  and 8

Excellently, we can now have multiple groups of light at full power at the same time.
I also wired the LED's into three groups of 12, as we want.

Next, I needed to have a way to change the brightness of the LED's. This can be done by having them only be on for a certain fraction of the time, cycling too quickly for the eye to see. I wanted an easy way to set the lights to brighter and dimmer levels, and I decided on levels 0-10, where the number indicates how many milliseconds out of ten it will be illuminated. I created blocks for each port that will go through one 10ms cycle of light and dark:

In the process, I learned very valuable things from Robbie about the way the Logo language works, for example the only mutable variables are the global ones, (which seem to be capped at 14 variables, problematically), and :num is only a number, not a variable within the method, so it cannot be set to another value. 

But I wanted all three lights to be on at once, at different levels. With this system, because it uses long waits, only one light can be cycling at once. Therefore, I made another block that will do the same thing, but with all three lights at once, by waiting 1ms ten times, and turning each group on or off at the appropriate moment. I ran into a few fencepost errors with levels 0 and 10 and was sad at the lack of >= (and comments), but came to a final version that worked:

Now, all three groups can be at at different levels.

Now the lights needed to be interactive. I connected a light sensor to each of ports 1, 2, and 3, so that each group of lights can have a corresponding sensor. 

I wrote a program that will proportionally control each group of lights, increasing the power to each group when the light to its sensor decreases. The lights will be completely off at an arbitrary sensor value "midlight," here, 300, or slightly dimmer than the ambient light in the room. 

Now, the lights can be brightened and dimmed by covering or shining light on the three sensors:

But it seems silly to have an arbitrary value involved. 

Now, the light at which the LED's will not turn on is set by two things. "Avglight" gives the average light the sensors are seeing when the program is started, i.e. the ambient light in the room. We want the lights to turn on to a certain level at the ambient light. This is taken care of by a new variable "offset" which is the desired light power at "avglight" times the gain. Finally, "midlight," the light at which the LEDs do not turn on, is avglight-offset. This works by making sure that the "error" at the ambient light level (aka "offset") sets the light to the level specified in "offset." Here that level is 2, so the lights will go to level 2 when the sensors are reading the ambient light level as measured when the device was turned on. So, whether the device is turned on in a bright or dim room, it will adjust its range to be appropriate to the surrounding light. 

Component Testing

On Friday, we tested the lights and built a basic winch system for our hanging lights.

Lights

Robbie showed us how to transform the sensor ports into outputs using the following code:

Using the on8 and off8 commands, etc. we can turn the current in ports 6, 7, and 8 on and off. To adjust brightness, we make the lights flicker on and off so quickly that it is unnoticeable. For example, this program makes the lights only have current for half the time, making them half as bright. 

On Tuesday, I went into the lab to test the number of LEDs we will be able to use. We wanted about 20 in each sphere, so I tried out powering 20 at once:

They were still satisfactorily bright, not nearly as bright as a single one would be, but more lights, rather than brighter lights, would be more appealing with our sphere idea. But, I wanted to compare the many lights to the brightness of a single light, so I connected one light to the next port. 

Here I ran into a problem. Turning on power to one port shuts off power to the other ports, so a program reading "on8 on7" would only turn on port 7. As far as I can tell from messing with the underlying code, they can't be turned on simultaneously, though I will have to ask Robbie about this on Wednesday. To solve this, I wrote a program that switches power between the two ports every 2 ms. However, this has the same effect as the dimming program from earlier. The ports can't be at full brightness at the same time, since power is switching back and forth. 

In this situation, the 20 lights are probably not bright enough:

From here, I experimented with smaller numbers of lights to see how many would be able to still be bright enough with only half-power.

It seems like 12 is a good number for each group of lights, since they can still be quite bright while sharing power with another group. 

Winch

We built a simple winch out of Legos with an NXT motor which models what we will use to hang the lights. We did not include any gears because the motor's speed can be controlled through programming. We had some trouble with where the fixed end of the string/wire (the end that will be plugged into the Cricket) should go, but we decided it should trail off parallel to the axle so that spinning the axle will not pull on the fixed end.

Plans for Moving Forward

This Wednesday, I will try to make a works-like model, probably on a breadboard, that integrates feedback and control from light and touch sensors. Since Ashley will probably not be there, this might be a hard goal to achieve, but hopefully the model will be satisfactory. Depending on whether we have hollow cardboard spheres for the LEDs, I may be able to make one or more light spheres to test with the winch. I am afraid that they will be too light to hang nicely from the string/wire, since the wire could be stiff.

Final Project: Brainstorming and Research

The goal of Ashley's and my project is "Art with Light and Shadow." On Friday, we made an attempt to narrow down that goal to an actual project description.

We started out with the idea of a panel with LED's behind it, which would sense light falling on it and respond by lighting up in return. We came up with a lot of cool ways that the lights could respond to sensor input (for example, if the average light dropped suddenly, such as when the lights in a room were turned off, the lights could brighten momentarily, or moving your hand across the panel would leave a trail of dimness behind due to the shadow). However, when we asked about the feasibility of this project, it turned out that it would be impossible with the control mechanism that we have available (the Cricket). This issue became a theme in the brainstorming process that we went through for the rest of the class period.

Going off of the theme of "art with light and shadow," we brainstormed a series of ideas from "light tic-tac-toe" to "morphing light cube." We did a lot of google image searches to look for inspiration. We eventually narrowed our ideas down to four that seemed most workable.

1. Light Boxes
This idea involves a bright constant light (or lights) inside of boxes made of thin Delrin, nested together. The inner boxes would have designs cut into them, so that the light coming from within would cast shaped shadows on the outer box. These boxes would be able to rotate within each other, for a constantly changing shadow effect. The movements would be controlled by light sensors on each face of the box, so that the box could respond to being moved around, or having one or more faces covered up or lit.

2. Light Fountain
The light fountain would be similar to the original panel idea, but the sensors (a maximum of eight) would be lined up at the bottom of the panel, and when the sensors were activated, either by light or by shade, a "fountain" of light would appear on the panel from long series of LEDs behind it. This improves on the original idea by having only a few sections of LEDs to control, and each section would operate as a unit. The different sections could be different colors, for a gradient effect.

3. Independently moving lights

Another idea similar to the first, but there would only be ~3 lights behind the panel, each attached to a horizontal and vertical string attached to tracks around the edges, so that each light could move independently in any direction. There would be a few sensors as well behind the panel, so that the lights could move toward the darkest section of the panel or rudimentarily interact with each other.

4. Hanging lights

This idea involved several (~3) small spheres encrusted with LEDs (like tiny disco balls) that would hang from the ceiling on a string attached to a motorized winch at the top, so that they could be moved up and down. Each sphere would have a light sensor, so that it would be able to light up in response to darkness (for example, cupping the light in your hands would cause it to be come brighter). We also wanted them to have touch sensors, either in the winch, so they could respond to a tug on the string, or on the sphere itself. These touch sensors would change the sphere between being attracted to and repelled from light, so that the spheres would be able to interact with each other, either chasing or fleeing one another.

We put these four top ideas into a Pugh chart. Our criteria were ease of assembly, ease of programming, time required, interactivity (very important to us!), prettiness aka aesthetics, suitability (does it meet the project requirements?) and feasibility (our nemesis).

The Pugh chart

We quickly discarded "Light Fountain" because we couldn't come up with a way to incorporate a mechanism into the design. "Hanging Lights" and "Light Boxes" came out on top, and we decided on hanging lights because they seemed more fun and interactive.

Hence, we started to refine the hanging light idea. We initially thought they could hang from the ceiling, but then decided it would be even better if they were on a stand, making the assembly like a desk lamp. We then asked again about the feasibility of the design. It turned out that it is nearly impossible to use the Cricket to power both motors and lights, especially bright lights, at the same time. Only the A, B, and C ports generally produce "variable" current, though the sensor ports could be used to produce a small amount of current, and the USB ports can only be used with the bulky single LED boxes we used on the first day of programming cars. We will be testing using sensor ports to power lights on Friday.

Improved sketch of hanging lights

Since the hanging lights idea was seeming less and less likely, we switched our attention to Light Boxes. Brainstorming on Thursday, we came up with the idea of the box being a puzzle, so that the two inner boxes would create words, or a coherent picture, when perfectly aligned as a result of the external lighting conditions. We also expanded this idea to have a pyramid instead of a box that would open up when the inner parts aligned, making it a true puzzle box for storing secret engineering secrets.

puzzle box sketch

On Friday, we will test the LEDs with the sensor ports, and if this fails, we will start developing our light box idea and see how much light will shine through sheets of thin Delrin, or if we need a different material, as well as getting experience with the motors and mechanisms we will be using.

Heating and Cooling a Resistor: Part 2

On Friday we continued our exploration of the resistor heating.

Deliverable 4: Proportional Control

Simulated proportional control

Proportional control

Proportional gain = 15, simulation in red, actual results in blue

• If the gain is too low, the temperature will never reach the target because there will be a point where the power given to the resistor (error*gain) is equal to the amount of power being lost through cooling, causing the temperature, and the power level, to become constant, but the system will not reach the target. 
• If the gain is high, the temperature of the resistor can overshoot the target and oscillate until it stabilizes. 
• The ideal gain seems to be between 5 and 15 W/K, since the final temperature can get up to 304.8 without overshooting and oscillating first. 

Deliverable 5: Proportional and Integral Control

Simulated PI Control

PI Control with plot of desired (not actual) power

Simulated (pink) and actual (red) use of  proportional gain of 5 and integral gain of 1

After writing our script for PI control, we had a long process of optimizing the gain. At first, we set the proportional gain to 5 and the integral gain to 1. We attributed the dip in the graph to a gust of wind or similar. We then tried doubling the proportional gain to 10.

Simulated (pink) and actual (red) use of  proportional gain of 10 and integral gain of 1

Strangely, the system took much longer to heat up, even though the gain was larger. We added power to the graph to see if we could see what the problem was. At first, we were graphing the percent power output, by setting values over 100 to equal 100 and those under 0 to equal 0. However, we just got a straight line at 100. At first, we thought it was an error in the way we were graphing, but we soon realized that the batteries might be failing, causing the resistor to heat so slowly that the integral gain was huge and the power was always over 100. To fix this, we changed our target temperature from 305 to the more attainable 280, and made our integral gain 100 times smaller.

Power (black), temperature (red) and target temperature (blue) for proportional gain 10 and integral gain .01

The peaks in the above graph are from blowing on the resistor. We decided our proportional gain was too big, since the power, even when we were not blowing on the resistor, was jumping up and down from 0 to 100 because the gain was too large to stabilize the power at a constant level that would maintain the target temperature. We then reduced the proportional gain to 5.

Power (black), temperature (red) and target temperature (blue) for proportional gain 5 and integral gain .01

Reducing the proportional gain allowed the resistor to stay at a more constant setting when it was not being blown on. However, the response was still pretty slow, as can be seen in the middle peak of the above graph. We decided that our batteries were simply not strong enough to have a quick response at T=280, since setting the power to 100 still produced a slow response. Therefore, we reduced the target again, to 260.

Power (black), temperature (red) and target temperature (blue) for proportional gain 5 and integral gain .01, target 260

When the target was set to an attainable temperature, we got good results even in fairly strong "wind." The desired power did not have to go above 200 because the system could respond more quickly to changes.

Heating and Cooling a Resistor: Part 1

Last Wednesday, we started collecting real world data of heating and cooling in addition to the simulations.

Deliverable 1: Experimental heating data

Heating curve for 100% power for 300 seconds

C= 8.879 Ws/K

Rth=11.97 K/W

Time constant = 106 sec

 

The expected time for the system to reach .63 of its asymptote is 106 seconds. Actually, this occurred at 73 sec, showing that we were close but far from perfect in our calculations of the constants. 

Deliverable 2: Simulation of heating

Simulation of heating at 100% power for 5 min

The simulation is a much smoother curve, since it has no external factors, and has no flat spot at the start due to a delay in the heating starting and registering in the sensor. It also comes to a slightly different temperature than the real version because our constants and the power in watts were only approximated. 

Deliverable 3: Bang-bang control

Simulating bang-bang control

Simulation in red, actual results in blue for bang-bang control

We changed the target temperature to 305K because our thermistor was not calibrated and the upper limit that the heater could reach was around 320. The real data showed significantly larger fluctuations, since the real system has sensor and heating delays, but reached the desired temperature faster than the simulation, implying that maybe our constants or power value were inaccurate.