Final Project Week 4 - 99 Problems and We Can't Fix One

This week we received the materials we ordered and incorporated them into our prototype.

We started with the music shield. We soldered the male headers to the shield so that we could connect it to our arduino. There was one section that we accidentally soldered on facing the wrong direction, so we had to borrow some tools from the physics lab to remove the headers and re-solder them in the right direction.

Next, we tried to get our hand washing song playing. We downloaded the shield's library and edited the code as instructed. The instruction manual didn't explain how to connect the speakers, but we figured they went inside the blue terminal blocks. When we ran the code, the music played, but it was very quiet, and changing the volume in the code had no effect. We also had trouble with the speaker wires falling out of the terminals, so we thought we might not have connected them correctly. We thought the screws in the terminals were supposed to be tightened onto the wires to hold them in place, but the provided wires were too thin. Amy instructed us to solder thicker wires onto the speakers, and those stay in the terminals just fine. We asked her for help with our volume issue, but when we tried to demonstrate the problem, the song would no longer play at all.

After troubleshooting the music issues and not getting far, we moved onto the rest of the circuit.  We got could get our LEDs to go through the pattern once when the button was pressed, but then on the second loop, the first LED would light up and the system would get stuck like that. We also got our servo to turn on only when the button was pressed, but it wouldn't follow the pattern we wanted it to. We wanted it to rotate back and forth through a set arc, but its behavior was erratic; it would rotate through different arcs at different times.

Next we tried out our Velostat with a single LED. The LED definitely got brighter when we applied pressure to the Velostat, but when no pressure was applied, the LED was still on. For our project, we need the LEDs, music, and servo to be completely off when no pressure is applied to the Velostat, because we don't want our system to be constantly running and driving the teachers crazy. We tried applying varying amounts of pressure, using varying amounts of Velostat, and using different resistors, but we still got the same results.

We didn't begin constructing our sign, but we thought we could use a clear plastic box for it. The front side could have the pictures (printed on copy paper) behind it, and the arduino, shield, and all the wires could go inside the box for protection. The hands could sit on top, and the speakers could be attached to either side. 

On Friday we went to present our prototype to the Becky at the CSC. We showed her the LEDs and Servo running through the program once when the button was pressed. We decided to leave the music component out since it would've been so hard to hear. We didn't get as far as we were hoping for our presentation, but based off the erratic behavior we'd seen from our system, we were glad we could get 3/4 outputs to perform adequately even once. 

While at the CSC, we had the chance to check out the bathroom again, take pictures, and begin thinking about where our system would be mounted. Instead of making our own pictures for the sign, we plan on asking Becky if she can send us a copy of the hand-washing sign already up in the bathroom so we can use pictures the children are familiar with. Next week we need to work on getting our song to play again, fixing the volume issue with our speakers, getting our Servo to follow the pattern we want, and figuring out how to get the program to run more than once without the system freaking out. We also need to laser cut our hands, build the box/sign, make our poster, and pretty much have our final product in working order by May 3rd. Let's go!

Final Project Week 3

This week we ordered materials and began working on our prototype.

On Tuesday we cut out some foamcore hands and connected them to motors with tape. We programmed them so that they would rotate back and forth. We plan on building a lego stand and figuring out a better way to connect the hands to the motors. Amy pointed out that we can laser cut the hands instead of 3D printing them since it's cheaper and there's no functional reason why they need to be 3D printed.

We also began to work on a code to get a few LEDs to light up repeatedly in a pattern, but then we set that aside to focus on ordering all the materials we needed.

We had planned on using a force sensor that actually measures the weight on it so we could determine if a child or adult was standing on it, but we couldn't find a reasonably sized and priced sensor online. We realized that we could use a button instead. Pressing the button, no matter the weight, would cause the program to run, so we could just instruct adults not to step on it.

However, since the button is so small, we'd have to build a larger platform for the child to stand on that would simultaneously press the button. We thought about using a squishy material like yoga mat for the base of the platform and cutting a hole for the button, then putting a hard material like a sheet of plastic or wood on top. When a child stepped on the platform, the mat would compress and the hard sheet would press the button.

We also considered two sheets of hard material that are hinged on one side, with a button/buttons in between the sheets on the unhinged side. Stepping anywhere on the platform would press the button(s). We didn't like this idea as much because the platform wouldn't be perfectly level and it would move, so it could be dangerous for the kids. However, we weren't sure if the yoga mat idea would work. Luckily, we didn't have to think about it for long.

Amy found an inexpensive material ($3.95) called Velostat that comes by the square foot (big and durable enough that we wouldn't have to build much of a platform) and changes resistance depending on the pressure applied. We could connect this material to our circuit and it would act as a resistor. When there was no pressure on it, the resistance would be high, so electricity would not be able to flow through the circuit and power the music, hands, and lights. When stepped on, the resistance would decrease so that electricity would flow and the program would run.

We also needed to order a music shield ($34.95) and speakers. We went with with 8 ohm 0.5 W speakers for $1.50. Lastly, we needed to order a micro SD card to store our song(s) on.

Final Project Week 2

This week we had to present our detailed proposal to Becky. We were hoping to visit the CSC to observe the children washing their hands, but unfortunately they were using hand sanitizer since there was a boil-water advisory.

Last week we had planned to have LEDs on the sink, soap, towels, etc. to represent the various steps in the hand washing process.  We decided it would be easier to make a sign with light-up pictures of each of the steps. This way we wouldn't have wires all over the bathroom.
The sign would be mounted on the wall and have pictures of the six steps:

1. Roll up sleeves
2. Get soap
3. Make bubbles (get water and scrub hands)
4. Rinse hands
5. Turn off water
6. Dry hands

The 3-D moving hands and the speaker would also be connected to the sign somehow so that everything would be in one place. The only thing that would be separate would be the force sensor.

When someone stepped on the feet-shaped force sensor on the ground, the program would only run if they were 50 lbs or less, so that adults wouldn't have to go through the process. The child's weight would trigger the hand washing song, the moving hands, and the light-up sign. When the child moved off the sensor, the program would end.

Goal: Help children remember all the steps in the hand-washing process and wash their hands for the proper amount of time.

Mechanism: 3-D printed, motorized hands will mimic hand washing to remind the children to wash their hands.

Sensing, feedback, and control: The reading from the force sensor determines whether a child or adult is standing by the sink and only initiates the program if it detects a child's weight. The program ends when the force sensor detects no weight.

What do we need to create? The 3-D printed hands and the sign. We also need to build our circuit.

What do we need to order? The music-playing equipment and the force sensor.

After our presentation, Becky had a chance to ask questions and voice concerns:

Will there be a way to mute this if it's quiet time?
We're thinking we can either add a small button to the sign that the teacher can press to mute or turn off the program, or we can add a potentiometer that can be used to control the volume.

What happens if the children splash water on the wires/speakers?
The wires will be insulated with tubing and we can either buy waterproof speakers, mount the speakers high on the wall, or build a protective encasement for them,

What if the children grab the moving hands?
They will be mounted high enough that the children shouldn't be able to reach them.

Will there be multiple songs to choose from so that the teachers won't have to hear one song over and over for months?
We can put multiple songs on the SD card and have the program rotate through them.

Thermal Systems Part 2

Instead of simulating a cup of coffee heating up, we got to use an actual thermal system today. It consisted of a heater (a 50 ohm resistor) with an 18 V supply, a thermal reservoir, and a temperature sensor.

Deliverable 1
First, we connected our system to the computer and ran a code called test_thermal which turned on the heater for 300 seconds to 100% power and then plotted the temperature as the system warmed up. Here's a picture of that code and the resulting graph.

The next step was to use this graph to find the thermal resistance, Rth, and the heat capacity, C.  We used Rth = delta T / P and the initial (y(1)=310.5602) and final (y(300)=344.6363) temperatures to find Rth = (344.6363 K -310.5602 K)/(6.5 W) = 5.24 K/W.  Then, we used C = P / (dT/dt) to find C. We used data from t=1s to t=11s because that was where the graph could be approximated by a line. We found dT/dt= (T(11)-T(1))/(11-1) = (313.8624 K-310.5602 K)/(11 s-1 s) =  0.3302 K/s. Then we found C = P / (dT/dt) = 6.5 W/0.3302 K/s = 19.68 J/K. The time constant is defined as the time required for the system to reach 63.2% of its final asymptotic value which was about .632*(344.6363 K-310.5602 K)= 21.54 K. By looking at the vector y, we found that the time to reach 310.5602K +21.54K = 332.1 K was about 93 seconds.  Our prediction was tau = Rth*C = 5.24K/W*19.68J/K=103.12 seconds. So, the actual time for the system to respond was less than the expected time.

Deliverable 2
Next, we edited the given code heatsim.m to reflect the newly calculated values, Rth = 5.24 K/W and C = 19.68 J/K, as well as the max power 6.5 W.  We ran this simulation and compared it to to our experimental data.

Here is our modified heatsim.m script.

We wrote this code so that we could plot the simulated and experimental data on one graph. The experimental data is plotted in blue and the simulated data in red. 

The y axis is temperature (K) and the x axis is time (s). In this graph, the experiment looks like it follows the simulation extremely well. 

               

However, when we zoom in by changing the y axis range from 200-500 K to 300-350 K, we can see that it's not as good a match as we thought. The experimental curve is much bumpier than the extremely smooth simulation curve. The experimental curve is pretty smooth until about 75 seconds, but then it starts to fluctuate and deviate farther from the predicted curve. This is because real-world systems don't operate just as ideal, hypothetical systems do. Us touching the reservoir may have caused some fluctuations, and perhaps the power from the heater and other variables aren't as constant as we thought they'd be.

Deliverable 3

Next, we implemented bang-bang control, so that if the system was below the ideal temperature, the heater would run at max power, and if it was equal to or above the ideal temperature, the heater would not run at all. 

Here's the code for our bang-bang simulation. 

And here's the graph.  It doesn't really look like bang-bang to us. It looks too smooth. We decided to zoom in to see if the "bang bangs" would be more visible. 

In the zoomed in version, you can see that the graph levels off at 340 K around 225 s. 

I edited the code so that the simulation would run for 600 seconds, hoping to see characteristic bang-bang behavior. Unfortunately, it stays at 340 K after 225 s. Once the temperature is equal to or less than 340 K, the power should be set to 0, which would cause the temperature to drop, which would cause the power to be turned back on and the temperature to rise. I'm not sure why the simulation levels out at 340 K.

We moved on to our bang-bang experiment, which turned out as expected. Unlike the previous graph, in the experimental graph you can see the variations in temperature as the power is turned on and off.  

Deliverable 4
Next we implemented proportional control so that the power provided by the heater was proportional to the difference between the actual and desired temperature. The farther from ideal the temp was, the more power would be provided by the heater, and the closer to ideal temp, less power would be provided so that it wouldn't overshoot the ideal temperature. Since we can't have a negative power or a power greater than the heater's capabilities, we set the minimum power to 0 and the maximum to 6.5 W.

We worked on this project over several days, using different sensors (we had to switch them out so that we wouldn't have to wait for one to cool down). The sensor we were using while working on proportional control read 300 K as the ambient temp instead of 310 K, so we changed our code to reflect this. However, our Rth and C values were calculated using an ambient temperature of 300 K. This may be one reason for our issues (which are discussed below our graphs).

K = 0.05

K = 0.2

K=0.5 

As you can see, the greater the K value, the h the higher the final asymptotic temperature. However, even when when we made K ridiculously large, the temperature never reached the ideal of 340 K. The only way we could reach a temp of 340 K is if we added a constant to our power equation. For the graph below, we used the equation P = 5 + k*error with k = 0.5. We thought these constants were optimal, so we also used them for our experiment.

K = 0.5, P = 5 + K*error

Note that this simulation starts from an ambient temperature of 310 K because we'd been using our sensor since we ran the last simulations and it hadn't cooled down completely. 

Here is our code for our experimental proportional control. This code differs from the simulation code because the heater power has to be set as a percentage of the max power. Therefore, after we calculated the power, we divided by 6.5 W and multiplied by 100 to find the percentage.

K = 0.5, P = 5 + K*error

Compared to our simulation, this graph seems to level off a bit sooner, around 100 s, and it's also a lot bumpier, due to factors not accounted for in the simulation. However, the simulation is overall a pretty good fit.

Final Project Week 1

This week we needed to brainstorm some project ideas for the CSC and narrow it down to two. We came up with a heart timer and an interactive hand washing program. 

Our first idea, and the idea we were initially most excited about, was the heart timer. One problem the CSC has it that since the kids don't yet understand the concept of time, they're always asking how long is left in an activity or until they get to go home. Becky wanted a way to help the kids answer these questions on their own. The heart would be made out of rows of LEDs and either have buttons representing set times (such as 5 minutes, 15 minutes, half an hour, a half day and a whole day) or a knob such as a potentiometer that could be adjusted to any time. After the time was set by an adult, the rows of LEDs would light up after certain time increments. An example can be seen here. Once the entire heart was lit, the kids would know that the time was up. In order to fulfill the mechanism component of the project, the timer would also have hands or wings that would wave when the time was up. Ultimately, we decided against this project because, although the concept of a child's yearning for their parents as the day progresses being represented by a growing heart made sense to us, it was much too subtle for a child. Instead of coming up with a more concrete way to represent time, we chose to work on the next project.  

Another problem the CSC has is that the children either don't wash their hands at all, don't wash them for long enough, or skip some steps. This project aims to provide a solution to all of those problems. When a child stands on a mat next tot he sink, a force sensor in the mat registers less than 50 lbs of weight and starts the program. A voice will walk the child through the steps of washing their hands, in addition to playing a cute song, such as the one found here. We would also 3D print some hands that would mimic a hand-washing motion to remind the kids to wash. We decided to go with this project because we thought it would be more challenging for us and more useful to the CSC.

Thermal Systems Part 1

Question 1: How does the cooling behavior change if we vary the parameters and C? Figure this out using intuition and the above equations, and then vary these parameters in your program to confirm your conclusions.

dE = -((T - Tair) / Rth) * dt
dT = dE / C
T = T + dT

Based off the the above equations, I expected an increase in Rth to decrease (the absolute value of) dE and therefore decrease dT, which means the cooling would be slower. A decrease in Rth would increase dE and therefore increase dT, whch means the cooling would be faster. An increase in C would decrease dT and therefore cooling would be slower. An decrease in C would increase dT and therefore cooling would be faster.

Below is a picture of the code for which we manipulated the values of Rth and C and pictures of the resulting graphs.

                       

Rth = 85

Cooling occurs slowly, as expected.

R = 0.085

Cooling occurs quickly, as expected. 

C = 10

Cooling occurs quickly, as expected.

C = 100,000

Cooling occurs slowly, as expected.

Add a heater

Now let’s explore what happens if we add a heater to the pot. Suppose the coffee starts out at room temperature (273 K) and we turn on a heating element that adds thermal energy to the system at a constant rate P. In this case we expect that:

Question 2: Calculate a good value for P if we want our coffee to heat up to the Starbucks ideal 84°C, using the Rth from the MATLAB script?

The easiest way to do this is to look at the equation right after the heater is turned on, at time 0. If we divide the above equation by dt, set it equal to zero and solve for P, we get P = (T-Tair)/Rth, which simplifies to 64/0.85, which is about 75 J/s. 

 We can find Rth by arranging the equation from the last question. Rth = (T - Tair)/P = (353 - 293) K / 75 W = 0.8 K/W. 

Since dT/dt = P/C at t = 0, we can find the slope of the graph where it is approximately linear, from about 0 to 250s. The slope is about (310-300)K/(250-0)s = 0.08 K/s. 

We can then estimate C as C = P/(dT/dt) = 75 W / 0.08 K/s = about 938 J/K. This is pretty close to the given answer of 1000 J/K, and it probably differs due to the estimations made from reading the graph. 

Question 3) Modify the above programs to simulate a temperature controller that uses bang-bang control to reach and maintain the desired temperature. Bang-bang control is a very common approach for thermostats. Why is bang-bang control appropriate for many thermal systems? When might it be insufficient?

We modified our code so that if the temperature of the coffee was less than the ideal 357 K, the heater would turn on at a full power of 200 Watts. If the coffee temperature was greater than or equal to 357 K, the heater would turn off. Here is our code and a picture of our resulting graph. 



   

As you can see on the graph, the temperature of the coffee fluctuates around 357 K as the heater turns on and off. Bang-bang control is ideal for thermal systems in which you want to get close to an ideal temperature, but precision isn't as important. However, for systems where a few Kelvin difference would have a big effect, it's not a good idea. For example, if someone picks up the coffee cup when it is at a max fluctuation, it could be 5 degrees Fahrenheit colder or hotter than they were expecting. This would be bad, especially if it was hotter, because they might burn their tongue.  

Question 4) Create a program that uses proportional control to reach and maintain the desired temperature. How does this approach compare to bang-bang control?

We edited our code so that the power of the heater changed according to how far the temperature of the coffee was from the ideal temperature. We experimented with several values of k and the initial constant and found that a k value of 20 and starting value of 75 K heated the coffee up the fastest and produced the smallest fluctuations from the ideal temperature.

         

             

Compared to bang-bang control, proportional control heats the coffee faster (200 seconds vs. 400 seconds to reach ideal temperature) and keeps it at the ideal temperature instead of fluctuating.

Question 5) Suppose there is a delay between the time the coffee reaches a given temperature and when the temperature sensor records that temperature. Modify both of your programs to include this effect. What is the impact of this “sensor delay” on your system in each case? What other delay(s) might you expect in your thermodynamic system, apart from sensor delays?

Proportional Control

       

         
         

       

There's a small bump at the beginning, but then the graph dampens out at a steady temperature. 

Bang-bang Control

         
           
           

When there's a delay with bang-bang control, the whole graph is affected instead of just the beginning (although I'm not sure if this is right). The temperature fluctuates between 350 K and 365 K, which is a much larger range than bang-bang without a delay. This shows that, especially when real-life issues like sensor delays are taken into consideration, proportional control is really important.

In addition to the temperature sensor delay, there might be a delay between when the heater is told to turn on/off and when it actually does.

SciBorg-Proportional Control

Drive Straight  We've tried to  make our SciBorg drive straighter before, but this time we needed to use proportional control. That means the intensity of the correcting turn depends on how severely the SciBorg is veering from a straight path. We used the equation newspeed = 150  + k*error, where error is the difference between the two motor positions. We had to play around with different values of k to figure out what worked best. If k was too small, newspeed wouldn't be different enough from 150 to make a difference, and if it was too big, newspeed would quickly max out at 255. We settled on a value of k=0.5. A big problem we had was that our SciBorg was constantly making a hard turn. We added print statements to our code that displayed the time, error, and new speed each time through the loop. We then saw that newspeed was constantly 0, even though error was nonzero.We found out that if newspeed was a decimal number, trying to set the motor speed to newspeed would make it default to 0. Therefore we made newspeed an int. We also made sure to make k a float so that we could try out decimal and integer k values. Below is our code and videos of the SciBorg.

On Lab Floor

On Carpet

For comparison, here is the SciBorg going straight on carpet using bang-bang control.

After I watched the above video, I thought that bang-bang worked just as well or even better than proportional control, even though I expected proportional control to be more effective. Then I realized that the SciBorg in the bang-bang video is going much faster (I believe about 75-100 whatever-the-units-are faster). The slower the SciBorg goes, the more time it has for the differences between the motors to accumulate, and the more apparent it will be that it is not going straight. If the bang-bang and proportional SciBorgs were going the same speed, it'd be easier to tell which one was really going straighter. 

Stop After 10 Feet Our next task was to use proportional control to stop the SciBorg after 10 feet. The farther from the target it is, the faster it should travel to get there. We decided to use the motor encoder to measure 10 feet. We timed how long it took the SciBorg to travel 10 feet at speed 150 and then connected the SciBorg to the computer and noted the average encoder position after this amount of time. After writing and uploading our code, we were very perplexed when the SciBorg when so far past the 10 ft line. Then we realized that since our SciBorg was not going at a constant speed, it would take longer than our measured time to reach 10 ft. We decided we needed a encoder position based off distance instead of time (number of encoder readings (not sure of units)/rotation instead of readings/second). According to our understanding of motor encoders, the motor position after 1 rotation should not depend on speed. (Hopefully our logic is sound.) In order to do this, we ran both motors at speed 225 and measured how long 10 rotations took. We did 5 trials and then took the average time. We then edited our script so that the motors would stop after that amount of time and noted the final encoder position. We did 5 trials and took the average. We then divided by the number of rotations to get a value for the encoder reading/rotation. We got 702.8 readings/rotation for motor 2, 704.4 readings/rotation for motor 1, and 703.6 readings/rotation as an average. Then we divided 10 feet by the circumference of the wheel to find the number of rotations needed and multiplied this number by 703.6 to get 12,647 for the encoder position at 10 feet. This method worked pretty well, and our SciBorg didn't need a whole lot of nudging. Below, see our code and a video of our SciBorg in action.

 

As you can see, the SciBorg ended up only a couple inches from the finish line. 

Nudge  Let's see if we can get our SciBorg to the finish line by adding a small nudge to our code! Below is the last piece of our code with an added nudge function. Unfortunately, we couldn't get the function to work because we kept getting the error "nudge was not declared in this scope."

We had to add a nudge without using a function in order to get it to work. 

Here is a video of our SciBorg going 10 ft with the help of an added nudge. 

Ultrasonic Following With Proportional Control  Can we get our SciBorg to follow an object using proportional control, so that the farther away the object is, the faster the SciBorg goes? Yep, piece of cake! Here's our code and some videos.

Follow Meba

Like Ducks in a Row

Line Following with Proportional Control  The reason why this blog post is so late is that we slaved over our proportional control line following code and couldn't get it to work. I thought if we took some more time and got instructor help we would be able to get it, but I have decided to accept defeat. It's been over a week extra and I just don't want to think about it anymore. It seems like our SciBorg isn't listening to our code, because it's not responding at all to changes in light, let alone responding in the way we want. It only drives in circles. There must be some explanation for this behavior, but we just don't know what it is. **

**While commenting my broken code in order to post a picture, I think I found the problem. I will try out the new code tomorrow and update this blog post on whether or not it works. I decided to leave the above paragraph because it shows how close I was to giving up before I found the solution. :')

I believe the problem was that the last conditional used to be a while loop (while (error != 0)), which means that once a nonzero error was detected, the SciBorg was stuck in that while loop and was  not updating the speed. This explains why the SciBorg was traveling in circles. Now that it is an if statement, the speed should update, and it will hopefully work!