Monday, April 4, 2016

Simulating Thermal Systems using MATLAB (Part 1)

Day 18 (4/1/16)

Our next project to develop our computer coding skills and understanding was using MATLAB to model the behavior of thermal systems. We worked with our final project partner, in my case Sara, to model the behavior of a cup of coffee using different techniques and using different parameters.

Question 1: How does the behavior of the cup of coffee change when we vary the thermal resistance (Rth) and/or the heat capacity (C).

Answer:
To answer this question we can simply look at the equation for the change in temperature:

As you can see, both Rth and C are in the denominator of the equation. So, when either of them is increased, the temperature will change (dT) by less. In other words, an increase in Rth or C will slow the drop in temperature of the cup of coffee.

We can also see this result by writing a script in matlab and varying both of those parameters to see what happens. Here is the script we used:



I using this script, I ran it multiple times changing just Rth, then just C and then changing both variables. Here is the plot I got of the different behavior for changing just Rth (the value of Rth for each line is listed in the text box at the top):

Here are the different behaviors for just changing C:

And here are the different plots for varying both Rth and C ( I plotted all possible combinations for increasing and decreasing Rth and C values):

As the plots show, increasing C and Rth will slow down the cooling process for a hot cup of coffee.

Question 2: Calculate a good value for P (power) if we want our coffee to heat up to 84 degrees C (356 K).

Answer:
This question gave us the revised equation for dT that included the introduction of a power source. Here is the revised equation:


And here is how I solved this equation for P with known values for C, T, Tair, and Rth:



A reasonable power amount is 74 watts.

Question 3: Simulate a temperature controller that uses bang bang control to reach and maintain the desired temperature. Why is bang bang control appropriate for many thermal systems? When might it be insufficient?

Answer:
To modify the code to include bang bang control, we used an if else statement so that when the temperature is above the desired 357K, there is no power delivered to heating the coffee and when it is below the desired temperature, we deliver 74W of power to the temperature controller. Here is what the code looked like:



And here is the plot for bang bang control:

Bang bang control is appropriate for many thermal systems because temperature takes time to vary. A change in the temperature of something is not very abrupt, so it is easy to maintain the temperature around the desired value. Also, with a lot of thermal systems, it is not crucial that the temperature be exactly the single temperature, so the small variance caused by bang bang does not cause any problems. Bang bang control will be insufficient when an exact temperature needs to be obtained and maintained. Bang bang will cause some minor fluctuations in temperature by turning on or turning off an external heat source, so for high accuracy thermal systems, you need higher accuracy than bang bang.

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?

Answer: 
To use proportional control you have to apply the concepts I talked about in my previous blog post (Sciborgs Part 3)

Strength = k * error
where k is the gain constant
and error = goal - reality

When this is applied to the code, it becomes:




Here is the resulting plot for proportional control:


The main difference between the effects of bang bang control versus proportional control is that at small times, proportional control has much larger changes in temperature than bang bang. But, after that initial rapid spike in temperature, proportional control levels off quickly and approaches the target temperature at a much slower rate. Interestingly, proportional control undershoots the target value and slowly works its way towards it, where as bang bang goes until it reaches the target temperature and then reacts.

Question 5: Modify your program to include a delay time for when the temperature sensor records the temperature. 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?

Answer:
For the bang bang control, to add in the delay, all you had to do was set the initial time equal to the delay. So the new code looked like this:


Compared to without the delay this is how the function behaved. The red is without the delay and the blue one is with delay:


Apart from the sensor delay, we can expect delays from the changing temperature. As I mentioned earlier, changing the temperature of something is not an abrupt task, it takes time to heat something up or cool it down. The delays from the sensor and the changing temperatures would likely continue to add up making the bang bang control system less and less effective.

For proportional control, I did the same thing to add the delay. I just added a variable called delay, which was whatever time value the delay was, and then set the initial time to the delay. I wont show the code becuase it is almost exactly the same with the exception of the two lines I changed (the exact same ones as bang bang). Here is how the delay effected the results (once again red is no delay, blue is delay) :

For the proportional delay system, there will also be the temperature delay that I mentioned for bang bang. However, all in all I believe the proportional system will be less effected by delay and will be more accurate in the long run.



Friday, April 1, 2016

MATLAB Introduction

Day 17 (3/29/16)

Today we started learning how to program in Matlab. By reading through chapters 1-4 of "Physical Modeling in MATLAB," by Allen B. Downey and going through some of the exercises, we were able to get a good understanding of MATLAB and some or its major functions.

The exercises are outlined below with screenshots of the code and the answers/graphs they produced if applicable.


Exercise 2.1: fibonacci1 script

The first exercise we did was come up with a script to determine the nth number in the fibonacci sequence.

Here is what the code looked like:


If you wanted to solve for the 10th value, you would input 10 when the command window prompts you for the value of n.



Exercise 2.3: car_update script

The second exercise we did was to create a script to update the number of cars in both Albany and Boston week to week. The conditions were that they both started with 150 cars and 5% of the cars from Albany go to Boston each week and 3% of the cars from Boston go to Albany each week.

Here is what the script looked like:


After running the script repeatedly, the number of cars finally reached an equilibrium after 24 weeks with 116 cars in Albany and 184 cars in Boston.

Exercise 3.1: car_loop script

The next task we did was update the car script to run it in a loop, rather than having to run the code for each week, we can specify the number of weeks we want to run the code for.

Here is what the new script looked like:


And here is what the loop returned after 52 weeks:




Exercise 3.2: car_loop script with plotting. Also try initial values of a & b = 10000

The next exercise we did was build on top of the car loop so that our data could be plotted to see the pattern. We did this by just adding a plot function in to the loop and specifying the shape and color of all of the points.

Here is what the script looked like:



Here is what the plot looked like for number of cars in Albany with an initial values of 150 at each location and a time span of 52 weeks:


And here is what the plot looked like for number of cars in Albany with an initial values of 1000 at each location and a time span of 52 weeks:


Exercise 3.5: fibonacci2 sequence script

The next exercise we did was to create a script using a loop to determine the nth element of the fibonacci sequence.

Here is what the code looked like:


For the 10th number in the sequence, the code returned a value of 144:



Exercise 4.6: plotting fibonacci ratios

The last exercise we had to do out of the book was to create a vector for both the fibonacci sequence and the fibonacci ratio (Fn+1/Fn). And then we had to plot the ratio.

Here is what my code looked like:


And here is what the plot of the fibonacci ratio vector looked like:


Unfortunately, I did not have time to get to the baseball problem, but I will take a look at it and try to work it out when I get the chance.

Tuesday, March 29, 2016

Sciborgs Part 3

Day 15 (3/15/16)

Our next assignment with the sciborgs was to do essentially the same tasks as before, except instead of using bang- bang control we had to use proportional control. Proportional control uses feedback to figure out how much power to supply to a mechanism based on how far off it is from the goal. We write the power in the form of:

Power = k * error
where k is the gain constant
and error = goal - reality

Task #9

The first task we had to do was to make the sciborg drive even straighter than when we used the bang-bang control. We did this by setting the constant k to 3 and the error to the difference in the positions of both of the motors. Here is what our code looked like:

By using the difference between the positions of the two motors we were able to devise a system so that one motor would speed up or slow down based on the position of the other motor. Unfortunately, we did not have enough time to test this code on different surfaces because it took us too long to devise the code and we needed to move on to the other tasks. I am guessing that the best results would be on the carpet because with the higher friction, the wheels are less likely to slip and so the motor encoder will be more accurate.

Task #10

The next task we worked on (and spent a lot of time on) was making the sciborg go 10 feet exactly and then stop. Once again, we used proportional control to make this happen. Here is what our code looked like:


We devised the original function so the sciborg could get close to the line. The sciborg, however did not make it all the way to the line, so we devised a nudge function to push the sciborg a little bit farther until it reached the line. Changing the gain changes the speed of the sciborg as it gets closer to the target. We determined that a smaller gain will get the sciborg the farthest because it will take longer to slow down.

This assignment gave us lots of problems and issues. We tried many things, and worked many hours just on this task, and we were not able to get it to perform perfectly the way we wanted.

Here is a video for the sciborg moving 10 feet using proportional control:


Task #11

The next task was to use the ultrasonic sensor to allow the sciborg to follow something using proportional control.

This task was a bit easier than the others because we had two different modules from the first two tasks to use. We used the same concepts from task 9 and 10 to control the sciborg using the sensor. This time however, instead of using the motor encoder, we were using the ultrasonic sensor to determine how far away the sciborg was from the target (the delrin board or another sciborg).

Using proportional control is a little more effective then bang-bang control because the speed is related to the distance and the sciborg is constantly taking in to account the distance from the target.

Here is the code we put together for the ultrasonic sensor proportional control:



Here is a video of the sciborg following a delrin board:


And here is a video of a few sciborgs following each other in a row:



Task #12

Our final task was to get the sciborg to follow the path (white strips of tape) using only proportional control. For this task, we were not able to get very far in the execution of this task. We were able to devise our first draft of the code which did not work at all. Here is what the first draft looked like:



If we had more time, I would use a different logic to come up with a proportional equation to make one wheel turn faster or slower than the other depending on the reading from the ultrasonic sensor. The target reading is around 90 for the sciborg following on the line. So, the error  would be 90 - the reading from the sensor. If the value is higher, the error will be negative so the wheel will move slower. If we use this equation for the speed of motor 2, this proportional equation would control the sciborg in the correct direction. If the value is lower, the error will be positive, wheel 2 will move faster and turn the sciborg in the other direction.


Monday, March 14, 2016

Feedback and Control Systems

A feedback and control system is a mechanism that uses a combination of sensing, computation, and actuation.

A sensor is something that measures or detects something. It can measure a digital or analog signal and acts as an input for the mechanism. Computation takes data from the sensor and does something with it. Actuators are things that move (mechanically or electrically), like a piston or a light going on.

For this assignment, we were tasked with identifying and analyzing four feedback and control systems. They are described below.

System #1:

The first feedback and control system I analyzed was the swipe locks on the outside of all of the college buildings. They look like this:


When you swipe your one-card, the door will either unlock or not, depending on your specific access. The sensor of this mechanism receives a signal by reading the magnetic strip on the one card. This is likely a digital signal because it will either open the lock or not. Certain people's one cards will either be coded with access or not for a specific door lock.

The computation piece of this feedback and control system will take the reading from the magnetic strip and either unlock the door or leave the door locked.

The actuators of this system is the lock itself. When the system receives the digital signal for unlock, the lock will open and the green led light will turn on. If the system receives the digital signal for don't unlock, the red led will turn on and the lock will not be opened. When the system receives no signal, the yellow led light will show.

System #2:

The second feedback and control system I analyzed was the water dispenser. These water dispensers are all over the sports center and in the science center. They look like this:



The sensor for this system is a digital sensor. The sensor is either on or off- there is either something in front of sensor and it is turned on, or it is off if there isn't anything in front of the sensor.

The computation part of this system tells the water to turn on when there is an object in front of the sensor or to keep it turned off.

The actuator part of this system turns the water on when it gets the signal for "on"or it leaves the water off when the signal is "off".

System #3:

The third feedback and control system I analyzed was the fire alarm and sprinkler. These are in all of the dorm rooms and they look like this:


The sensor on this system is an analog sensor because it takes readings on the air in a room. It measures the amount of smoke in the room and once it measures a certain amount of smoke the actuator will activate.

The computation part of this system is the system that determines if the sensor is detecting high amounts of smoke or not, and then telling the sprinkler to turn on or stay off.

The actuator part of this system is the sprinkler turning on or off depending on the signal that the sensor is getting.

System #4:

The fourth feedback and control system I analyzed was the motion sensing lights in the observatory. When the lights are on in the "project room," a specific room in the observatory, the lights will turn off automatically after a specific time if no motion is detected. They will also turn back on if they detect motion.



The sensors for this system are quite obviously the motion sensors. These are digital signals-- either they detect motion or they do not. These motion sensors, in this room particularly, are located in the front by the door and in the back.

The computation part of this system is what the system does with the signal. If it detects motion, it tells the lights to turn on, if it doesn't sense motion for a while, it tells the lights to turn off.

The actuator part of this system are the lights turning on or turning off. Depending on the signal and the computation piece, the lights will turn on or turn off.

Friday, March 11, 2016

Sciborgs Part 2

Day 13 (3/8/16)

Today we started to delve deeper to understand the functions and uses of different sensors and feedback and control systems, specifically related to our sciborg (which we recently named Creepy Crawly Jr.). Nanaki and I immediately got to work on our new tasks which are outlined below.


Task 1 - Motor Encoder:

Our first task was to learn about the motor encoder. First we downloaded the code from the class website and adjusted if for our needs. The original program looked like:



The original code depended on the time the program had been running. Since the loop was set up to adjust the "previousMillis" to the new time, the code wouldn't start back at time=0 so the position would be the total position the motor has moved. It wouldn't restart the position each time the loop ran, it would just add the positions each time. We changed the code to no longer depend on the time the program has been running and set the limits of the loop according to the motor position.

We ran tests of different versions of the code using different position limits on the motor to figure out what distance corresponds to the specific value for the motor position. We figured out that the sciborg will move 10 inches with the corresponding motor position of 1,000. We then did a calculation to determine what the motor encoder will read to correspond to 10 feet. This value ended up being about 12,000, so we set the motors to run at full power until the motor position read 12,000 and then stop. Here is what our code looked like:


After running this code several times, we determined that the sciborg was off by kind of a lot (almost a foot). This is likely due to the uncertainties in our measurements for the conversion from motor position to actual distance traveled. Also, every run with the sciborg is different and most don't go completely straight. Here is a video of our sciborg controlled by the motor encoder:



Task 2 - Touch Switch: 

Our next task was to control the sciborg using the touch switch at the front of the robot:


To do this, we downloaded the code given to us on the class website and then included the motors in to the code. It was set up so that if the switch was pushed in, the sciborg would stop and if it wasn't, the sciborg would move ahead at full speed. Here is what the code looked like:


We figured out that we could put a barrier 10 feet from the starting position and the sciborg would travel at full speed until it hit the barrier and would stop at 10ft.

Here's how the switch worked:


Task 3 - Light Sensor:

Our third task was to learn how to use the light sensor and figure out a way to make the sciborg move 10 feet using the sensor as the feedback in the feedback and control system.

First we once again downloaded the code and tested it out to see what it did. Before we included the motors in the code we did tests to determine how accurate the sensor is. The range of the scaled value of the sensor was from 0 to 98. We determined that the light sensor would be accurate enough that it could be of use to us for later tasks when it is a few centimeters from the ground.

One extra function that the light sensor had was a guide LED light. You could turn the LED on or off and this would change how the light sensor worked and measured its values. After testing the differences in values between the white tape and the brown board we determined that the light sensor was more accurate with the LED turned off. 

Here is what the code looked like for the light sensor:


To make our sciborg go the 10m and then stop using the light sensor, we determined that we could lay down a piece of tape 10m from where the sciborg started and set it up that the sciborg would run at full speed when the sensor was reading the values that correspond to the dark ground and once the sensor detected the smaller number of the white tape, the motors would stop.






Task 4 - Ultrasonic Sensor:

Our next task was to learn how the ultrasonic sensor. First we downloaded the code and set it up with the motors. We then ran tests to determine how accurate the sonar is and what distance the readings correspond to. We determined that with a sonic reading of 3, the sciborg will be about 10in from the barrier. Also we determined that the sensor was accurate with about an inch of error.

Here is our resulting code to control the motors:


We set up a barrier 10ft 10in from the starting point of the sciborg and set the motors to run until the sensor read a value of 3 and then turn the motors off. Here is how it worked:



Task 5 - Drive straight:

To accomplish this, Nanaki and I used the motor encoder code. What we did is when the position of the motor on the left was less than the position of the motor on the right, we would turn up the power of the left motor and turn down the right motor. This way, the sciborg would correct for the difference in motor position by turning. Here is what our code looked like:



And here is how the code worked:



Difficulties we faced:

Throughout this phase of the project, we faced many challenges. First off, the sensors are not completely accurate, so there will always be a margin of error when using sensors. Also, the sciborg doesn't travel the same during each run.

One of the biggest things we struggled with was the ball bearing catching on the ground and messing up the positioning and the timing of the sciborg. To fix this we removed the ball bearing and lubricated it to make it run smoother:


After all of these tasks, we came up with some good ideas to have the sciborg follow a path. I will discuss these ideas further in my next blog post.