Tuesday, April 29, 2014

Works like model updated and Looks like model

Works like model updated:

Since the last post, our rover has undergone several iterations both for the claw and for the body.

We tested the car on an uphill incline but was ultimately unable to climb it.  Thus, we changed out the smaller wheels for taller ones.  We then doubled the wheels because the weight of the vehicle and outer shell that was later developed made the wheels splay outward.  Further changes to the rover body to make the front lower to the ground and make the body bounce less allowed us to remove the previously placed Lego weighed blocks.  Thus, the front of the vehicle became more stable and the design used less pieces than before to achieve a new goal.

After this iteration, every part of the rover worked independently: the body drove successfully on flat ground while the claw was able to operate.  However, our biggest problem became incorporating the claw in a spot that would allow it to pick up our Mars rocks without a complicated code.  Previously, we placed the claw where the Sciborg bumper was.  However, that would have required the rover to bypass the Mars rocks and back up to identify the rocks, a largely difficult and complex process for what we were trying to achieve. We considered several different places to place the claw including having it hang off to one side.  However, that would have caused an imbalance on one side of the rover.  Thus, the only spot that made sense for the claw was to put it at the front of the vehicle.  Designing this would have required us to build an extension piece on top of the front-most wheels which would have extended above and over it.  This would have created a previously unforeseen problem: since the vehicle was being powered from the back two wheels, the rover would have been unreasonably long and unevenly distributed the weight with two separate heavy bodies attached in the center.  The vehicle would not have been able to drive successfully.

This forced us to remove the two front-most wheels to add room for the claw.  We were initially concerned that without these two front wheels the robot would not be able to go up or down hills.  However, it performed much better than expected especially since the wheels were much taller.  But we had to be careful in where we placed the claw and at what angle since it is the front-most piece of the rover.  During test runs, the claw sometimes became caught on the ground or posed a problem for when the rover was traveling up and down hills.  Several iterations of the claw resulted in a more efficient design and an interesting insight.  With our previous code, opening the claw resulted in a 50% success rate because the claw would open fully but then sag back to a half open state.  We later realized that if the gears reached 180-170 degrees, it would stay open.  But if the gears were less than that, the weight of the claws would naturally cause the gears to rotate and shut the claw.  Thus, tweaking the initial starting and ending angles of the claw jaws enabled us to solve this problem.

After several more test drives, the rover still had some difficulty making it up hills.  We suspected that the batteries may have played a role in this but was unable to change them until later.  Before then, we tested whether powering the vehicle from the front two wheels would solve the problem and were surprised and annoyed to discover that the rover traveled better with this option.  Thus, we iterated the design again to move the claw back to the back of the rover in a much more efficient design than before.

After several test runs on the landscape's hill, we were finally successful in getting the rover over the majority of the hill.  However, because of the claw's weight in the front combined with the motor weight in the middle, the rover would fall on its face when it drove downhill and was unable to rock back to its four wheels.  We attached some Lego weighed blocks in the back to try to counter the weight but were disappointed to find out that it didn't help solve the issue as it had done previously.  However, we were more surprised to realize that we could simply attach two rods to the front of the claw to push the rover back when it first hit the ground.

Of course there are still more things we would like to iterate upon that we will take the initiative to change between now and the first exhibition.



Looks like models:
We chose to add delrin pieces to the claw to increase its efficiency.  The claw features a small curve that was achieved by attaching the pieces via piano wire.  These pieces were then hot glued to the claw.

We also created a box to hide the Picoblock board and replicate the look of NASA's rover.  Thus, we researched the rover design and spray painted it to model the rover.  To replicate the camera head of the rover, we created a stand for Eunice's phone.  During the exhibition, we plan on video conferencing the user to the phone on the rover to simulate the experience of viewing Mars from the camera on the rover.

Our landscape went through several design changes.  We initially put several rock pieces together in the same area to make the landscape rockier.  However, we were concerned that the rover wouldn't be able to make it over all of them if the entire terrain was like that. Thus, we spaced them out more and included some larger rocks for aesthetic purposes.  However, when we tested the rover on the actual landscape, it had difficulty making it over some of them due to the ragged edges and required us to shave some of them down.

The hill also took an incredibly long time to create.  The angle of the hill required several test drives and us to shave down increments.  The first hill I tried to create failed at the end because the last cut made the hill too steep and it became impossible to save it at that point.  Thus, I recreated the design using a much smaller piece to begin with and just taped two halves together instead of trying to shave off two sides of one piece.  This allowed me to keep the side that worked and create another half when the first didn't work out.

We also created a poster board with instructions on how to operate our rover and included some facts about the Mars rover program to educate our users on the topic.

There are always things to work on that we will definitely consider and implement before our first public exhibition.


Friday, April 18, 2014

Works like model

We were finally able to build and test all of the working parts for our rover.

The car drives pretty well with all 6 wheels.  We initially based the rover off of the Sciborgs that we used earlier this year in order to create a working vehicle.  The rover is powered from the back two wheels since the Sciborg board is only able to support three motors at once and we wanted to save one for the arm/claw.  Since we will be incorporating hills into the landscape that the rover will drive through and we wanted to stay true to NASA's rover design, we also incorporated a third pair of wheels in the front.  These wheels will allow the rover to travel up steep hills and lower itself gently into ditches.

We encountered a few problems with this initial design.  For one, the rover didn't drive in a straight line, a problem that was prevalent throughout the Sciborg project.  Another issue was that the rover was unable to drive up steep hills because of a protruding back piece that the Sciborg design incorporated.  We thought this back piece would be a cool way to prevent the rover from damaging itself if it ever backed up into anything.  However, it just hindered the movement of the rover in the end.  There were also extra pieces and structural parts that could have been built in a more efficient way.  Thus, when we iterated the rover, we removed the back bumper piece and redesigned some of the structural pieces, especially near the front two wheels.  After this iteration, the rover drove in a straight line and the back was no longer a problem.

Initial design Rover stuck

Initial design Rover


Sciborg that we based the Rover off of


Our second big component was the robotic claw.  Our goal is to incorporate this feature such that it will be able to pick up an object of our choosing.  Since we are using a motor, only one side of the claw can move.  Thus, we chose to make it the bottom jaw since the top does not need to move as much.  We plan on making this feature in delrin so our initial testing was focused more on creating the structure and code that would allow the claw to move successfully.  We also noted that if the claw were placed on the back, it would pose a problem when the rover drove up the hill.  Thus, we attached a small piece that would push the upper jaw upwards when the lower jaw encountered a steep slope.  I foresee this feature being replaced when the actual delrin pieces are created since there will be solid walls that can push on each other.

I forgot to save the code that we used to power the claw.  However there are two simple commands:

OpenClaw: Talk to c, set power = 40, motor on = 8 sec
CloseClaw: Talk to c, that way, set power = 40, motor on = 8 sec

Rover after iteration that incorporates the claw

 Protruding piece that pushes the upper jaw up

Friday, April 11, 2014

Thermal Systems II

Deliverables 1 and 2
The heatsim program produced a curve that has a sharper increase in temperature compared to the testthermal graph which is derived from heating the physical heater.  It appears that the physical heater increases at a gradual rate which makes sense given that metal increases its temperature at a gradual rate rather than at a sharp increase.

Using the formulas given to us from the previous lab and this lab, we determined that our heat capacity was 21.6W and thermal resistance was 2.05 if our heater ran at its maximum power of 6.5W
(313.25-300)/6.5 = 2.05 for Rth
C = P/(dT/dt) = 6.5/ [(3.5-312.3)/100] = 21.6w

Using the formula (Rth*C) to determine the time constant, the amount of time it would take to reach 63.2% of the heater's final temperature, we calculated that it was 26.65.  Our graph matches that estimate as well so we were assured that the values we calculated were correct.

Bang-bang control
In comparison to our heatsim, the actual heater yielded a much more gradual rise in temperature.  The heatsim program does not take material properties into account which is why the two yield different graphs. The difference is again most likely due to the fact that metal heats gradually rather than with sharp increases in temperature.

Proportional control
We used the gains given to us to calculate the varying coefficients for each time.  For a gain of 0.05, the coefficient was 0.7679; for a gain of 0.2, the coefficient was 3.077; and for a gain of 0.5, the coefficient was 7.692.  We also determined that the proportionality ratio was 6.5/100 = 0.05a/x

However, using gains of 0.05 and 0.2 were insufficient for the heater to reach its desired temperature of 340.  Using a gain of 0.5 yielded the closest result.  However, as we saw with using proportional control in the heatsim, using this type of control is insufficient for achieving our desired goal.

Heatsim with proportional control:

Gain = 0.05
Gain = 0.2

 Gain = 0.5 


PI Control
The PI control utilizes both proportional control and integral control to heat the system.  It initially begins with using proportional control but then uses integral control to counter the error that the system encounters.  Using this type of control, the system responded instantaneously to any error.  We used the formula given to us: P_desired = Kp * error + Ki * integral error.  To get the temperature to 350, we had to use a Ki of 0.5 and a Kp of 11.


Brainstorming, Research, Goals

Eunice and I will be working on primarily building a rover for our Mission to Mars project over the next few weeks.

Goals:
  • To educate users about the Mars rovers and NASA's Rover program
  • Teach users how to program through Picoblocks
  • Teach users about how sensors work and the different types that exist
  • Possibly teach users about proportional and bang-bang control
    • This will depend on the amount of time we decide our exhibit should take for users, what our target user audience is, and what knowledge that we assume that they will have before they begin this exhibit
Our goal is to create an exhibit that will prompt users to program commands for the rover to accomplish using its sensors.  We plan on asking users to program the rover to leave the docking facility, travel across a ditch, collect a rock sample, travel up a hill, take a picture at the top of the hill, and return to the docking facility successfully.

Design:
We plan on building a rover that is similar to the one used by NASA to help gather interest in the program
(Taken from http://marsrover.nasa.gov/gallery/artwork/rover1browse.html)

Our rover will be primarily built from Legos for the wheels and lower body section.  However, we also plan on incorporating Delrin pieces for the body of the rover and possibly PVC pipes for the head.  We also plan on simulating the Mars terrain by creating a landscape for the rover to travel across.  This terrain will be built out of Styrofoam and will contain a ditch and hill as mentioned in one of our goals.

For the sensors, we will use the ultrasonic and touch sensors.  It wouldn't make sense to include the line sensor since there are no lines on Mars for the robot to follow.  Since one of our goals is to have users collect a rock sample, we will build a mechanical arm on the robot for that purpose. The arm will be built out of lego gears, lego parts, a motor, and some delrin for some parts. 

Friday, April 4, 2014

Thermal Systems

Question 1: The cooling behavior of the coffee cup simulator depends on the change in behavior for the thermal resistance and heat capacity.  A decrease in thermal resistance and heat capacity causes the coffee cup to cool in a shorter interval while an increase in both causes the coffee to cool at a longer interval.

Question 2:
dT is assumed to be 0 because there is no rise in temperature.  Thus, we are also able to eliminate dt when we multiply it by 0.  After some calculations, I was able to determine that a good value for P is about 71.7647.

Feedback and control program

Question 1:

% Simulation of heating coffee
% heatsim.m
C = 1000; % heat capacity
Tair = 293; % ambient temperature
Rth = 0.85; % thermal resistance
T = Tair; % initial coffee temperature
t = 0; % starting time
tmax =10000; % duration of simulation
dt = 100; % time step
%P = 85; % power added by heater

clf % clear old figure
clc % clear command center
hold on
axis([0 tmax Tair (T + 100)])
xlabel ('time (seconds)') % axes labels
ylabel ('temperature (K)')

while t < tmax
    if (T-Tair<337)
        P = 100;
    else 
        P = 0;
    end
    
    dE_in = P * dt;
    dE_out = ((T - Tair) / Rth) * dt;
    dE= dE_in - dE_out;
    dT = dE / C;
    T = T + dT;
    t = t + dt;
    plot(t,T,'ro')
    drawnow
end

We added if else statements to the code.  When the temperature of the coffee cup reaches room temperature, the heater turns on to warm the cup to its desired temperature.  We could have also adjusted the temperature in the if else statement to make it higher than room temperature so that the coffee doesn't go completely cold.  However, we chose room temperature because it is a definite point at which the coffee needs to be heated.

Bang-bang control is successful for thermal systems because as soon as the temperature reaches the set temperature, the system is able to rapidly revert that state back to a desired state.  In this example, the coffee was able to be kept at a near 84C.   This system may be insufficient because while the coffee did stay at around 84C, it was constantly fluctuating around the point rather than at 84C.  However, the system ultimately achieved its goal, unlike the proportional control as we will see next.



Question 2:

% Simulation of heating coffee
% heatsim.m
C = 1000; % heat capacity
Tair = 293; % ambient temperature
Rth = 0.85; % thermal resistance
T = Tair; % initial coffee temperature
t = 0; % starting time
tmax =10000; % duration of simulation
dt = 100; % time step
%P = 85; % power added by heater

clf % clear old figure
clc % clear command center
hold on
axis([0 tmax Tair (T + 100)])
xlabel ('time (seconds)') % axes labels
ylabel ('temperature (K)')

while t < tmax
    if (T-Tair<357);
        P = 0.99 * (357- T);
            else 
             P = 0;
         end
    
    dE_in = P * dt;
    dE_out = ((T - Tair) / Rth) * dt;
    dE= dE_in - dE_out;
    dT = dE / C;
    T = T + dT;
    t = t + dt;
    plot(t,T,'ro')
    drawnow
end


We incorporated the proportional control equation into our code.
P = k * error  The error being (357-T).
In order to determine the best k value, I played around with varying levels of it to see if it would yield something close to the desired Starbucks temperature.  However, even after setting it at 0.99, I was unable to get the temperature to raise to 357.  Thus, proportional control cannot work for this type of system since it cannot achieve its goal of getting the system to its desired level.


Proportional control with delay

% Simulation of heating coffee
% heatsim.m
C = 1000; % heat capacity
Tair = 293; % ambient temperature
Rth = 0.85; % thermal resistance
T = Tair; % initial coffee temperature
t = 0; % starting time
tmax =10000; % duration of simulation
dt = 100; % time step
%P = 85; % power added by heater
delay = 5; %seconds

clf % clear old figure
clc % clear command center
hold on
axis([0 tmax Tair (T + 100)])
xlabel ('time (seconds)') % axes labels
ylabel ('temperature (K)')

for i = 1:500
    if (i - delay > 0);
        P(i) = 0.99 * (357 - T(i-delay));
    else
        P(i) = 0;
    end
      
    dE_in = P(i) * dt;
    dE_out = ((T(i) - Tair) / Rth) * dt;
    dE= dE_in - dE_out;
    dT = dE / C;
    T(i+1) = T(i) + dT;
    t(i) = i * dt;
    plot(t(i),T(i),'ro')
    drawnow
end



Bang-Bang control with delay

% Simulation of heating coffee
% heatsim.m
C = 1000; % heat capacity
Tair = 293; % ambient temperature
Rth = 0.85; % thermal resistance
T = Tair; % initial coffee temperature
t = 0; % starting time
tmax =10000; % duration of simulation
dt = 100; % time step
%P = 85; % power added by heater
delay = 5; %seconds

clf % clear old figure
clc % clear command center
hold on
axis([0 tmax Tair (T + 100)])
xlabel ('time (seconds)') % axes labels
ylabel ('temperature (K)')

while t < tmax
    for i = 1:500
        if (i - delay > 0);
            if (T-Tair<337) ;
            P(i) = 100;
            else
            P(i) = 0;
        end
        end
    dE_in = P(i) * dt;
    dE_out = ((T(i) - Tair) / Rth) * dt;
    dE= dE_in - dE_out;
    dT = dE / C;
    T(i+1) = T(i) + dT;
    t(i) = i * dt;
    plot(t(i),T(i),'ro')
    drawnow
    end
end





it appears that the biggest effect that the delay has on the bang-bang and proportional control is that the initial onset of the effect is delayed by the designated delay time.  For the bang-bang feedback, it reduced the amount of variation around 84C since the system had to wait to respond to the changes.  Thus, instead of vacillating around a set point, the system only had time to respond to the change which eliminated that problem.  For the proportional control, the system was still unable to reach its goal of 357K.  There was the initial delay period followed by a short period in which the temperature of the coffee went over its goal.  However, it quickly centered itself at a lower rate than desired.

Other delays in the thermodynamic system include a delay in temperature change.   There must be enough energy added to the system in order to get the temperature to change.  If the system does not have enough energy, it either will not change at all or will change slowly to reflect the amount of energy in the system.

Tuesday, April 1, 2014

MATLAB Introduction

Exercise 2.1 fibonacci1 script

(1/(5^0.5))*((((1+(5^0.5))/2)^n)-(((1-(5^0.5))/2)^n))

This seems like a lot of parenthesis for just this line of code.  If there's a more efficient way to write this, I would be glad to hear comments about it.  I could alternatively write this through variables like:

a = (1/(5^0.5));
b(((1+(5^0.5))/2)^n;
c((1-(5^0.5))/2)^n;
a*(b-c)

But it doesn't seem as efficient either.

Exercise 2.3: car_update script

For this, I initially assigned a and b to be equal to 150 and stored the values through the prompt.  My script is as follows:


%car_update updates the number of cars in each location from
%one week to the next.  Precondition: variables aStor and bStor contain
%the number of cars in each location at the beginning of the week
%Postcondition: a and b have been modified to reflect the number of cars
%that have moved

aStor=(b*0.03)+a - (a*0.05)
bStor=(a*0.05)+b - (b*0.03)
a = aStor
b = bStor

a represented the number of cars in Albany while b represented the numbers of cars in Boston.  Since there is a 2% difference between the transfer of cars in each city, Boston ended up with the majority of cars after a few weeks.

Exercise 3.1: car_loop script

%car_loop updates the number of cars in each location via a for loop from
%one week to the next.  Precondition: variables aStor and bStor contain
%the number of cars in each location at the beginning of the week
%Postcondition: a and b have been modified to reflect the number of cars
%that have moved


a = 150
b = 150

for i = 1:52
    aStor=(b*0.03)+a - (a*0.05)
    bStor=(a*0.05)+b - (b*0.03)
    a = aStor
    b = bStor
end

I borrowed the code that I used from exercise 2.3 but I've always preferred for loops over recursion.

Exercise 3.2: car_loop script with plotting
a = 10000 % or 150
b = 10000 % or 150

for i = 1:52
    aStor=(b*0.03)+a - (a*0.05)
    bStor=(a*0.05)+b - (b*0.03)
    a = aStor
    b = bStor
    hold on
    plot (i, a, 'o')
    plot (i, a, 'ro')
    plot (i, b, 'bd')
end




Exercise 3.5: fibonacci2 sequence script


%creates the Fibonacci sequence using for loops instead of recursion.
%Precondition: n represents the level that the sequence is on.  a, b, and
%c represent sections of the Fibonacci sequence while Fx represents the
%entire equation.  Postcondition: the 10th element is assigned to the
%answer.

for i = 3:10
    n = i
    a = (1/(5^0.5));
    b = (((1+(5^0.5))/2)^n);
    c = (((1-(5^0.5))/2)^n);
    Fx = a*(b-c);
end
Fx = a*(b-c)

I later adjusted the code to allow users to compute the nth element for any value of n.  However, users must set the n before the script is run.

n = 3   %user can change this number
for i = n
    a = (1/(5^0.5));
    b = (((1+(5^0.5))/2)^n);
    c = (((1-(5^0.5))/2)^n);
    Fx = a*(b-c);
end
Fx = a*(b-c)