MATLAB Introduction

Exercise 2.1: Fibonacci 1 (p.14)

For this exercise, we were told to enter the expression for the Fibonacci number in MATLAB and compute the 10th Fibonacci number. We were told that the correct answer should be 55.

The expression for the nth Fibonacci number was given as the following:

In order to make things look a little nicer, Christina and I decided to set the expressions inside the parenthesis (including the exponent) as variables a and b. We also set n as 10 as told in the problem.

Then we set the expression for Fn as ans so the console would print the Fibonacci number.

Here's a screenshot of our script:  

and the command window:

 As seen in the above picture, the Fibonacci number for n=10 is calculated as 55, which is the correct answer.

This exercise was pretty self-explanatory and was a good way to practice setting variables in MATLAB.

Exercise 2.3: Car Update (p.20-21)

Here's a quick recap of the given information:

We initially have 150 cars in both Albany and Boston. Each week, 5% of the cars in Albany are dropped off in Boston and 3% of the cars in Boston are dropped off in Albany. 

We started out the script by defining variable a as the initial number of cars in Albany and variable b as the initial number of cars in Boston.

Then, we defined new variables anew and bnew to reflect the number of cars in the next week. 

For Albany (anew), the equation would be the initial number of cars minus 5% of the initial number of cars plus 3% of the initial number of cars in Boston. 

For Boston (bnew), the equation is the initial number of cars in Boston minus 3% of the initial number of cars plus 5% of the initial number of cars in Albany.  

We used the 'round' command to round up the numbers to whole numbers (we are assuming that there are no fractional amount of cars)

Lastly, we re-defined variables a and b so that it equals anew and bnew. This simply means that anew and bnew becomes the new 'initial number of cars' for the next week.

Here's the command window after running the script shown above:

 The first a and b is simply the initial number of cars defined in the beginning of the script, and the second a and b is the number of cars in Albany and Boston after the first week. 

Now if we ran the same script over and over again, it would just give the same results because every time we re-run the script, we define the initial a and b as 150.

So if we get rid of the a=150 and b=150 after running the script once: 

the a would be defined as the number of cars in Albany after the first week and b would we defined as the number of cars in Boston after the first week.

Now if we run the script again, the 'new' a and b values is used to calculate the anew and bnew for the second week. Running the script repeatedly will give us the number of cars in Albany and Boston week after week. 

However, this process is very manual, and we would need to keep track of the amount of times the script was run in order to figure out which week the numbers represent.

  The first set of a and b shown in the command window above is the number of cars after 1 week. The second set of a and b is after week 2, and the third set of a and b is after week 3. 

To answer the question asked in the exercise, we thought the number of cars in Albany and Boston will eventually reach an equilibrium, where 5% of cars in Albany and 3% of cars in Boston is approximately equal.

We could prove this by repeatedly clicking the run button and looking at the results in the command window.

 

After multiple (couldn't keep track of the exact number) runs, the numbers reached equilibrium at a=118 and b=182.

Exercise 3.1: Car Loop (p.26)

For this exercise, we were finally allowed to use the for loop and asked to calculate the number of cars in Albany and Boston after 52 weeks (as continuation of the previous exercise). Using a for loop makes our lives much easier because we wouldn't have to manually run our script 52 times.

In the script, we simply defined the initial number of cars in Albany and Boston (as variables a and b) before the for loop.

Then, we let the for loop run from i=1 (after 1 week) until i=52 (after 52 weeks) and ran the car update script (the commented out parts under the car_updatescript shows what the car update script is)

 After running the script, the command window showed a long list of all the 52 a and b values. 

Just  to make the a and b values a little easier to view, I made a new script using vectors:

Here, i=1 is defined as the index for the initial number of cars (150) in both Albany and Boston. So when i=2, it actually displays number of cars after the first week and when i=53, after 52 weeks.

The vectors 'Albany' and 'Boston' displays all of the a(i) and b(i) values from i=1 to i=53:

 As predicted in the previous exercise, the number of cars reach equilibrium after about 21 weeks.

  

Exercise 3.2 Car Loop Plotting (p.27)

In order to make a plot of number of cars vs i, we modified the script from Exercise 3.1 so that it would plot a point every time it goes through the loop.

 We simply added a plot function within the for loop so that it would plot i vs a as a red circle and i vs b as a blue diamond.

The resulting graph definitely made it easier to see that the numbers reach equilibrium. The equilibrium values displayed in the graph (a~120, b~180) agrees with the values obtained from the previous exercise (a=118, b=182) and we also see that i~20 when numbers reach equilibrium.

We also plotted a graph for initial values a & b=10000

As the graph shows, the equilibrium is reached at a slower rate. The numbers seem to reach equilibrium around i=50, and in order to verify this, I ran the loop from i=1:100 and plotted the results:

This new graph clearly shows that equilibrium is reached after about 50 weeks. The approximate equilibrium values are a=12,500 and b=7,500.

Also, the graph is smoother and resemble exponential functions.

I was curious to see what the plot looked like for low initial values, so I decided to make a plot with initial values of 50.

As the graph shows, the number of cars change linearly with i until it reaches equilibrium around i=7 (7 weeks).

From this, we can conclude that the higher initial values will require more time to reach equilibrium and low initial values will require less time to reach equilibrium.  

Exercise 3.5: Fibonacci 2 (p.30-31)

The assignment asks us to create a loop that computes the first 10 elements of the Fibonacci sequence and assign the final answer as the 10th Fibonacci number.

  

We started out by defining the first and second Fibonacci numbers as 'prev1' and 'prev2'. Since we already have the first and second numbers, the loop was run from i=3 to i=10 in order to compute the next 8 numbers.

Inside the loop, the Fibonacci number was defined as F_i and was set equal to prev1 + prev2. This is simply a restatement of the definition given in the text. 

Then, the value for prev2 was re-defined as prev1 because for the next Fibonacci number, the value of F(i-1) becomes F(i-2). Prev1 was re-defined as the Fibonacci number because the Fibonacci number becomes F(i-1) for the next loop.

For example, in order to compute F(3), we need F(2) and F(1). In order to compute F(4), we need F(3), which is simply the Fibonacci number computed previously and F(2), which is F(i-1) in the previous computation but F(i-2) in this computation.

The command window displays 55 as the 10th Fibonacci number, which is what we expected to get.

To make the script more general, we simply defined a variable n that represents the order of the Fibonacci number that we want to calculate. Then, we replaced 10 with n in the for loop.

In order to test the script, I set n=29 and compared to answer to the number that I Googled.

 The command window tells me that the 29 Fibonacci number is 514229, which agrees with the Googled value.

Exercise 4.6: Plotting Fibonacci Ratios (p.46)

To start off, the Fibonacci sequence was re-written as vectors and we were able to display a beautiful vector of the first 10 Fibonacci numbers.

Using vectors to define the Fibonacci sequence is a lot less confusing and easier to understand. We simply define F(i) as F(i-2) + F(i-1) and run the for loop. Since the first two Fibonacci numbers are given, we can start the loop from i=3. I defined 'sequence' as the vector F so that it would display all the values of F. 

 Now, it's time to calculate the Fibonacci ratios.

At the very beginning of the script, I defined a variable n, which is equal to the number of Fibonacci numbers we are calculating. The number of ratios being calculated is equal to n-1. 

The first for loop simply calculates the Fibonacci numbers until the nth number. 

The second for loop calculates the Fibonacci ratios. Since we are defining the Fibonacci ratio as F(i+1)/F(i), we need to run the loop from i=1 to i=n-1 because F(n) is the maximum Fibonacci number calculated from the first loop and F(i+1) would be undefined if i=n. 

We could also have defined the ratio as F(i)/F(i-1) and set i=2:n.

The script tells the console to display 2 vectors defined as 'sequence' and 'ratio'. These are vectors of the Fibonacci numbers and Fibonacci ratios.

In order to plot the ratios, I define a new vector 'N' that goes from 1 to (n-1). So when N=1, the ratio is F(2)/F(1), and when N=n-1, the ratio is F(n)/F(n-1). 


We first started out by plotting the ratios when n=10:

The graph shows that the numbers converge, but we wanted to get a better graph by having more data points. 

So we set n=20.

When n=20, we can clearly see that the ratio converges around 1.6. 

Looking at the vector for the ratio, we could get a more accurate value at which the ratios converge:

As seen in the above picture, the ratios converge at 1.6180.

Exercise: Baseball Trajectory

(Not drawn to scale)

The last assignment is based an a typical physics problem that is summarized in the above picture.

We basically need to find the initial batting angle that maximizes the range of the trajectory.

After a lot of thought, we came up with a plan. 

1. First, we calculate the trajectory and the range (which is just the final x value in the already given while loop) for angles 0 to 90 in 1 degree intervals.

2.  Then, we would make a vector of all the ranges at different angles and use a command to find the maximum range and the angle corresponding to that range

3. Lastly, we plot trajectories at 10 degree intervals because plotting trajectories of all angles from 0 to 90 would just look very very messy 
(*I later decided to re-plot the maximum range trajectory with a different color so that it would stand out)

  

 In order to calculate the trajectory at different angles, I nested the while loop inside a for loop.

Since the index for the for loop can only start from 1, the i ranges from 1 to 91, where angle(1) is defined as 0 degrees and angle(91) is defined as 90 degrees.

After defining the angle(i) as i-1, the rest of the script (until the end of the while loop) is the same as the script given in the assignment with the exception of the iteration index for the while loop.

Since i is already being used as a iteration index for the for loop, I defined j as an iteration index for the while loop.

The while loop calculates the x and y positions of the ball in intervals of 0.1 seconds. I realized that the definition for the y position was missing a term (1/2)gt^2 and decided to add it just for accurate physics. Even without drag force, there is acceleration due to gravity in the y-direction. (I ran the final script both with and without this term and they give the same angles)

After the while loop, I defined the i-th range (range(i)) as x(j), which is the final x value calculated from the while loop.

Then I ended the for loop and looked up commands in MATLAB that would allow me to print the largest element in an array.

According to the MathWorks website (http://www.mathworks.com/help/matlab/ref/max.html), the command [C,I]=max(A) finds the maximum value of array A and assigns it to the variable C and the index of the maximum value to the variable I. 

This was incredibly helpful because it was exactly what I needed to do in order to find the maximum range and the angle corresponding to the maximum range.

Using the command [maxRange index] = max(range), I was able to find the maximum value in the array 'range' and made the console display both the range vector and the maxRange value. 

Angle corresponding to the maxRange value can be printed just by typing 'angle(index)' and since angle(i)=i-1, the angle is going to be 1 less than the index value.

Here's a picture of the command window that displays all of the values:

   
The maximum range is 258.96m and the corresponding angle is 44 degrees.

   
 Now that we've knocked #1 and #2 off the list, it's time to work on #3 and plot the trajectories.

Since 44 degrees is the angle that maximizes the range, I decided to plot the trajectories at angles 4, 14, 24, 34, 44, 54, 64, 74, and 84.

In order to do this, I copied the exact for-loop from the previous part and changed the indices from i=1:91 to i=5:10:85. 

This will run the loop at intervals of 10 from i=5 to i=85, which corresponds to angles 4-84 degrees.  

After the while loop, I added a plot function and plotted the trajectory (x and y positions) from the initial j value until the final j value. I connected the points with a blue line.



I wanted to do something special for the trajectory at 44 degrees since it gives the maximum range. 

So this time I took out the for loop and defined the radians using the angle(index) (which is the angle that gives the maximum range)
This would allow the while loop to run just for this particular angle.

I plotted the trajectory at 44 degrees and connected it with a magenta line. 

I also wanted to label the axis of the plot and define the minimum and maximum values, so I used the commands title(), xlabel(), ylabel(), axis([]). 
(http://www.mathworks.com/help/matlab/titles-and-labels.html)  (http://www.mathworks.com/help/matlab/ref/axis.html)

Here's a picture of our graph:

I tried to label each trajectory with the corresponding angles, but could not figure out how to do that in MATLAB so I thought it would be easier to just label it using Word.

 The graph looks a little chaotic but it clearly shows that 44 degrees gives the maximum range.


Since the y-axis is so zoomed out, it actually looks like the starting y position is at zero, but if you zoom into it, it clearly starts out at y=1

We can actually see a very nice trajectory of angle=4 degrees in this picture (Even though it is definitely not to scale)

 For this particular problem (with no air drag), it is easy to just calculate the angle by hand, but I can see how using MATLAB would be useful in cases where we need to consider drag forces, because it would be very painful to try to solve complex differential equations.



 

Final Project Initial Brainstorming

Questions for the Museum Trip

Before getting into the questions, I wanted to start out with a little personal anecdote. The first time I went to the museum of science was when I was about 4 years old, and I remember being fascinated by all the different things I could play with and how realistic the movies were at the IMAX theater. I have gone back multiple times after my initial visit, and even as I grew older, there is always something to learn from the exhibits.

For the purpose of this class and the final project, I would like to focus my attention on recognizing how effectively different types of exhibits/demonstrations get their points across to the audience. There are many exhibits that draws the attention of the visitors instantly and effectively teaches the science behind it without throwing in too much technical information.  It would be interesting to get some statistics on the most and least popular exhibits in order to determine what topics/types of exhibits that visitors enjoy.

Most of the time, visitors (especially those of younger age groups) enjoy hands-on activities rather than reading the blurb or watching a video. I realize that it is difficult to demonstrate certain scientific concepts as an hands-on activity, but it would be interesting to think about ways to change certain non-hands-on exhibits to a more interactive and intuitive exhibit that would draw more people.

I am especially interested in looking at the exhibits 'Physics Play ground' (I forgot the exact name), Cahners Computer Place, 'Take a Closer Look', 'The Light House', and 'Making Models'. 


10 Ideas for the Final Project
Even though this is just an initial brainstorm, coming up with 10 different ideas was quite challenging. I have been racking my brain trying to remember all of the different science topics I learned over the years and apply it to the project.

1. Defying Gravity
My first Idea was to have a magnetic object float in space by balancing the gravitational force of the object (mg) and the induced magnetic force from the coil. There would be a light source and a light sensor, and the control mechanism would try to alter the amount of current flowing through the coil depending on whether the object is level with the light source or not. There are many E&M topics that can be learned from this project. 

2. Magnetically Levitated Train
This is another magnetism-related project idea, and it involves a train that moves using the magnetic force of the magnets. There would be a sensor that detects whether the train is above the sensor or not, and if it detects the train, it would allow current to flow in the coil in front of the train, pulling the train forward by attracting the piece of aluminum that is attached to the bottom of the train. At the edges of the train body and on the edges of the tract, there could be same pole magnets that would allow the train to be levitated.   

3. Swings and Resonance
For this idea, I was thinking about how moving your legs in a certain direction allows you to swing higher at the playground while moving your legs in another direction makes you slow down to a stop. This has to do with resonance and damping, and I wanted to create a device that demonstrates both. For example, in order to create resonance (make the swing go higher), the sensor would detect which direction the swing is going and apply a force in that particular direction. If we wanted damping, the force would be exerted in the other direction. I have not really worked out the details of how I would do this, but it was just a thought.

 

4. Regions of the Brain/The Human Sensory System
In order to demonstrate what parts of the brain control the different senses on our body, I wanted to make a model brain that lights up in different colors when certain sensors are activated and provides an action according to what the sensor reads. I was also thinking that I could use sensors besides the touch and ultrasonic sensors by making new sensors that represent different sensory organs on our body.

5. Decoding the Computer Language
A bit is the basic unit of information that can be represented by 0 or 1 in the computer. In order to represent a single bit, we would use a light bulb that can either be turned on or off. On the other side of the bulb, there would be a light sensor that detects whether the particular bulb is on or not. By assigning different letters of the alphabet to different combinations of the light bulb sequence, we can make secret codes and translate then into letters.

6. Plants and Photosynthesis
I was inspired by my biology class and came up with the idea of having a model plant leaf and chloroplast that has humidity and light sensors. Depending on the relative humidity and the amount of light that the plant is exposed to, the leaf would change the number of stomata openings, transpiration rate, and CO2 exchange.

7. The Artistic Robotic Arm
I haven't figured out how to apply this to create an educational experience, but I had the idea of creating a 'robotic arm' holding a pen and use the motors to move the arm around. Using the brightness sensor, the arm would detect different patterns on the floor and depending on what the pattern is, it could move the motor in different amounts and draw something on a piece of paper.

8. Sugar Levels and Index of Refraction
Our body responds to different sugar levels by producing insulin or glucagon. In order to detect the different amounts of sugar in water, I thought I could use the index of refraction. With a laser pointed in the cup with the solution, we could have a sensor at the bottom of the cup and determine how refracted the laser is compared to the control (having just water as the solution). More refraction would mean that there is more sugar in the solution, and we could have a device that spits out insulin if it detects a solution that has a high concentration of sugar.

9. Loop de Loop
This is rather simple and I don't think it could be a project just by itself, but I wanted to put it out there anyway. Using the conservation of energy, we can calculate the initial height of the ramp needed for the cart (or the roller coaster) to go through the loop de loop without falling off. We could have a sensor at the top of the loop to detect whether the cart passes through the sensor. When it doesn't pass through the sensor, the cart must have fallen off before making it through the loop, and the motor that is connected to the loop would adjust accordingly until it finds the perfect height. We can compare this height with the theoretical height to see if the conservation of energy actually holds!

 

  
10. Detecting an Unknown Underwater Object
Lastly, I thought of making a device that can be used to manipulate the ultrasonic sensor above a tank filled with opaque water. Any flat object can be placed at the bottom of the tank and the ultrasonic sensor can be used to detect at what 'coordinates' the object is present and generate an image on the computer to identify the shape of the object. 

 



 

SciBorg Day 3-4 Proportional Line Following Video

SciBorg Day 3-4

Fixed Distance with Proportional Control
In the previous fixed distance mechanism (Day 2), the SciBorg was allowed to go straight at a constant speed for 10ft until it came to a sudden stop. For this assignment, we implemented proportional control that could vary the power of the motors according to the distance that the SciBorg has to travel. 

  First, we determined the number of count a it takes for the SciBorg to go ten feet. With some measurements and calculations, we determined that count a must be 3100. 
We started out with a forever loop and set up a variable n that is equal to the total number of count a the car needs to go (3100) minus count a. This is our error value, and we set the power to equal the error value because if we multiplied it by a number greater than 1, the power was set at maximum for most of the 10 ft. 
Then, we set up an if-then statement that gives greater power to motor b is count a is greater than count b and greater power to motor a if count a is not greater than count b. This was an attempt to make our car go straighter. 
With this code, we were able to make our SciBorg go faster at the beginning and gradually slow down and stop at exactly 10 ft. 

Compared to the previous fixed distance control, the proportional fixed distance control allowed the car to gradually slow down, giving it a longer time to stop. Even though it is less noticeable in SciBorgs, if we consider a real car, this would cause less damage to the wheels and safer for the person inside the car. 



Conga Line Bang-Bang Control
The mechanism behind the Conga line bang-bang control is pretty simple. We let the SciBorg go forward when the ultrasonic sensor reads a number greater than 20, and stop when it is less than 20 (when there is a piece of delrin close to the front of the car). 

We were successful at implementing this control and the SciBorg moved straight at constant speed until it recognized a piece of delrin in front of it. Just like other bang-bang controls, it does not have any subtle controls on speed, which could possibly make the motions a little jerky. However, the code is very simple and it incorporates the feedback mechanism (ultrasonic sensor).


Conga Line Proportional Control
We decided to implement proportional control in both forward and backward directions. 
When the SciBorg senses an object very close to the ultrasonic sensor (with a reading less than 15), we wanted to make it go backwards and vice versa. However, instead of simply going forwards and backwards, we wanted the SciBorg to vary its speed according to how near or far the object is. For example, if there is an object extremely close to the sensor (say sensor reading=2), it would move backwards faster than when the object is not as close (sensor reading=10). Similarly, the SciBorg would move forward faster if the object is very far away compared to when it is somewhat far away.

First, we set the 'turning point' sensor reading to be 15. If the reading is less than 15, the car would back up and if the reading is greater than 15, the car would go forward. 
     

 When sensor reading is less than 15:
We wanted the SciBorg to go backwards faster is the reading is smaller. Therefore, we set a variable n that is equal to 14-(sensor reading) (This is not shown in the picture above because it is hidden behind the arrows). Then we set the power to nx10 (the multiplier value was determined through trial and error). This way, when the sensor reading is very low, the n value would be high and the power would be higher. Then we used the 'that way-motor on' commands to turn on the motor in the reverse direction. 

When the sensor reading is greater than 15:
In this case, we want the car to go forward faster when the sensor reading is greater (when the object is further away). Therefore, we simply set the power so that it is equal to the sensor reading times 4 (again, the multiplier value was determined through experimentation). Then we turned on the motor so that the car goes forward. 

This worked out very well, and it allowed the SciBorg to smoothly speed up or slow down depending on the location of the object (or a piece of wood in this case).
Our SciBorg was also successful at following other SciBorgs, although it became a little chaotic when there were multiple SciBorgs going in different directions.

Compared to the bang-bang conga line, the proportional conga line control gave us more control over the movement/speed of our SciBorg and I feel like it made use of the feedback mechanism more efficiently.


Proportional Control Line Following

Our initial idea for the proportional line following was to have our SciBorg follow the edge of the tape and when it senses that it is off the edge, have it turn in the correct direction with the amount of turn being proportional to the difference in the sensor readings. In other words, if the SciBorg is only slightly off from the edge reading, it would only turn slowly until it finds the edge again and vice versa.  

 The NXT sensor reading for the edge of the tape was 460 and we wanted the SciBorg to follow the right edge so we made a code that allowed the SciBorg to turn right when the sensor reading was less than 460 (meaning that the sensor is on the tape) and turn left when the sensor was reading a value that is greater than 460 (meaning that the sensor is on the melamine).

However, when the sensor is only slightly off the edge (making the difference small), the power was so low that the SciBorg refused to move. 

As a solution to this problem, we utilized if-then-else statements (as shown below).  

 At the start of the code, we made an if-then-else statement that separates the two cases: sensor is on the tape, sensor is on the melamine. 

When the sensor reads a value greater than equal to 460:
Since the sensor is on the melamine, we need to make the car rotate counterclockwise. We first set a variable n that is simply the error value (sensor reading-460). Then, we made another if-then-else statement that accounts for the situations when the error value is low. When the error value is lower than 15, we simply set the power of motor a to 75 so that it would rotate left. When the error value is greater than 15, we set the power of motor a so that it equals the error value times 5. These values might seem arbitrary, but it was determined after multiple trials. 

When the sensor reads a value less than 460:
Since the sensor is on the tape, we need the car to rotate clockwise. The mechanism is pretty much the same as the previous one, with the exception of setting power on motor b instead of a. 

To our surprise, the proportional line following worked very well, and it was much less agonizing than getting the bang-bang line following to work.

 In general, using the proportional control required more programming but worked a whole lot better than bang-bang control. Although the benefits of proportional control might be less obvious when working with SciBorgs, there are many cases in real life where proportional control provides more efficiency and greater control. (If we imagine our biological systems to be bang-bang, it would actually be very difficult to maintain homeostasis). 



 


 

 






 
 

SciBorg Day 2 Line Following Video

SciBorg Day 2

The second SciBorg assignment required a lot of patience and time.

Fixed Distance
In order to make our SciBorg go exactly ten feet, we used count a. First we allowed the SciBorg to go forward for 3000 counts and measured the distance to be 117.5 in. Since there are (3000/117.5)=25.5 counts per inch, we calculated that there would be 3,063 count a's in 10 ft.

 The code for this was pretty simple. The Sciborg was told to go forward (F) until count a reached 3063 and stop (Br). This method is great if we want the SciBorg to travel a certain distance, but there are no feedback invovlved (it's an open loop control).

We had some trouble making the car go straight no matter how many times we adjusted the motor powers and it remained a consistent problem throughout the assignment. Through trial and error, we found out that the car seemed to veer right when two motor powers are equal, so setting the power of the left motor to a lower value seemed to help a little.

Next, we used the touch switch sensor to make the car stop when it runs into an obstacle. 

 The sensor reading was zero when the switch was pressed. So we made a code that allowed the car to drive forward until the sensor reading zero and stop afterwards.
This feedback mechanism is very simple and easy to code for because the touch sensor reads 0 every single time it hits an obstacle. However, it might not be so practical for certain devices especially if it is going at very high speeds or runs into an obstacle that has a significantly greater mass than the device, because it would cause a lot of damage to the device.


Using the ultrasonic sensor that detects the presence of obstacles by emitting waves, we made a code that stops the car when it gets to a fixed distance from the wall.

 Prior to making the code, we tested out the ultrasonic sensor. The sensor read 10~15 when an object was about 2,3 inches away. The code allowed the car to move forward until the sensor reads a value under 10, and stops afterwards. 
The car followed the code accurately, and stopped just before it ran into a wall. This mechanism seems more practical than the touch sensor control, because it there is less probability of the device getting damaged from running into an obstacle. 

Lastly, we used the NXT brightness sensor to allow the car to stop at the white line on the floor. 

The NXT brightness sensor read ~700 when it was on a white tape, so we made a code similar to the previous ones where the car was told to go forward until the sensor reads a value less than 700 and stop when it does. 
This method is great if there is a pattern on the floor that the car wants to follow, but it would be hard to use in a very dark setting.

Using a combination of sensors, we can make the SciBorg go a certain fixed distance (counting), but stop when it senses an obstacle (using either the touch and ultrasonic sensors).


Drive Straight
Making the car go in a straight path was a more difficult task than it seemed. Setting the motor b power to 62 and motor a power to 60 seemed to work best because the car tends to go right when the powers are equal. 
Implementing the bang-bang control, we allowed the car to bear left when count a was greater and bear right when count b was greater. 

 

 As seen in the picture, we set the power of b to a lower value because the car tends to go right.

On the lab floor, the car moved pretty straight if we positioned the front wheel correctly. On the carpet, it was going less straight due to the friction on the wheels but we could make it go straighter by changing the motor powers accordingly. 
The ramp posed a greater problem for us because the car would go in different directions even with the same code. On the first attempt, the car went perfectly straight up the ramp. Unfortunately, that was pretty much our only successful attempt (and we couldn't get in on video!!). We think that this mostly due to the front wheel moving in all directions. We even tried making it go backwards so it would be a 'front-wheel drive' but that did not seem to help very much.
Going down the ramp gave pretty similar results as going up the ramp.

Here's a video of a semi-successful attempt in going up the ramp:

 
To sum it up, the car went the straightest path when there was less friction on both wheels. If there was friction on one wheel preventing that wheel from spinning as much, the car went in a particular direction. Our results are not very reproducible because the car wanted to go in random directions even with the same code.


Bang-bang Line Following
This part of the assignment gave us the most trouble. Our first idea was to make the car bear left until it goes off the tape and bear right until it goes back on the tape. The NXT sensor read ~634 for the tape, ~720 for the melamine, so we tried to make the car bear left until the sensor reads a value that is greater than ~640 (we changed around this value multiple times to make it work better) and bear right until it reads a value less than 640. We tried using both the 'wait until' and 'if-then' statements, but the car would either go off in one direction without stopping, or go through the loop once. We were told that changing a direction of the car suddenly can cause problems, so we added a wait between each bear lefts and bear rights but later found out that it was the reason why it was causing problems for us. Another big reoccurring problem was that our car refused to go straight.
After many many attempts, we even tried attaching the sensor at different points on the SciBorg and made the SciBorg go backwards, but that wasn't making much of a difference.
We tried making the car go straight until it went off the tape and rotate in one direction until it found the tape again, but given our problem with the car not going straight it was difficult to make it work
We also found another strategy, where the car would follow the right edge of the tape (sensor reading of ~651) and when it senses that it is on the tape, it would bear right and when it senses that it is on the melamine, it would bear left. It was a great idea in theory, but executing it was a lot harder. Our coding made perfect sense but when we tested it out on the melamine it would give bad results. Sometimes, the car would simply refuse to move and most other times it would just choose a direction and go off forever. 
Finally, with the help of Juliette, we were able to figure out a way that worked. It was very aggravating to know that after all of the unsuccessful attempts, the one that actually works was the method that we had started out with. Basically, we made the car go right if it's on the tape and left if it's off the tape without any breaks in between. The car was able to zigzag through the course using this method.

The whole process was quite the struggle because we invested many hours to get it to work. The bang-bang control seemed very inefficient because it did not have any subtle controls and the car would jerk left and right throughout the course.       

(Ignore the block 'wait until' and everything after it)