MATLAB Introduction: The Puzzle of Physical Modeling

Today in class, we were introduced to the wonderful world of MATLAB. The program is a way of modeling events mathematically. Although we've only just barely begun to scratch the surface of the program's potential, we did manage to complete some sample exercises.

We started by simply making a Fibonacci Script. We had to translate the Fibonacci expression into MATLAB, set n=10 and see if the answer (Fn=ans) was 55 to check our work.

Our answer was, indeed, 55. 

Our next challenge was to calculate the number of cars a dealership had in each of its two location each week. Each week, 3% of the cars in B move to Lot A, and 5% of the cars in lot A move to Lot B. Each Lot starts the year with 150 cars 

We achieved this by adding and subtracting the desired number of cars each week. In addition, we also had to remember that the amount of cars in each lot changed per week, so 5% of the cars in Lot A one week would be a different from 5% in any other week.

Once we had completed this, we moved on to leaning about loops in MATLAB. Our challenge was to create a loop for out car calculating program and make it run 52 times, so that we could see what each car lot would look like at the end of one year. We set our initial A and B values to be 150.

We achieved a long stream of random numbers on our screen, but it was clear that the program was working because each week the number of cars in each lot changed. Some of our numbers were decimals, however, and because we knew a lot could not contain 'half a car', we used the round command to make our cars whole again. 

To make our data easier to interpret, we learned how to plot a graph. 

The graph allowed us to visually understand exactly how our numerous results were trending over the 52 week period. We then compared Lot A to Lot B to see how the entire stock of 300 cars was trending over the year.

In general, the number of cars in Lot A decreased at a decreasing rate and the number of cars in Lot B increased at a decreasing rate. In other words, Lot A always lost cars, but how many cars it lost each week became less over time. Conversely, Lot B always gained cars, but the number of cars it gained dropped lower and lower each week. The result was the same, even when Lot A and Lot B initially began with 10000 cars each.

For our next challenge, we left the car rentals behind and returned to our Fibonacci sequences. Our challenge was to compute the first 10 numbers in the sequence (we would have to specify the first two, but after that everything else was computable). 

Using our previous code and our knew knowledge of forever loops, we managed to complete the task. By checking online to see what the actual values of the first ten numbers in the sequence were, we were able to confirm our results. Next, we had to adjust the code such that it could calculate the sequence to any number (n) beyond (or even below) 10, but not less than 2. 

 

We achieved this by defining i as a variable able to be changed by the user. The starting point, 3, would remain the same, but the user could change the end point to anything.

From here, we went one step farther in our Fibonacci fun. Using vectors, we determined the ratio to which that F(n+1)/Fn converges, as well as graphed it. 

 

By using the vector to store of Fibonacci numbers, we were able to graph the ratio and see that the sequence converges to approximately 1.62 as the value of 'n' increases.

Finally, we were charged with maximizing the range of a baseball. Given a script, we had to alter it to determine the launch angle needed to produce the maximum range. Using the equation,

d = ((v^2)*(sin2x))/g,

we graphed distance vs angle on a separate script to see what angle would produce the greatest range. 

 

The optimal angle ended up being 45 degrees. Our code has the pre-condition that the user run our fabricated script first to acquire the needed angle before running the code. Conversely, our script can also be used to find an angle for a different distance, or to determine the angle based off a known distance.

Final Project Initial Brainstorming: The Puzzle of What's Next...

Now that my fellow novice engineers and I have completed all our basic training, it is time to begin working on what will consume the rest of the semester.....the final project!

What is it, exactly? We don't know yet. The theme for this semester is education, so whatever my future partner(s) and I do, it will have to be able to teach someone something about what we've been learning this semester. We're begining to put together some idaes. On Friday we will be takin a trip to the Museum of Science in Boston for inspiration and meeting with an engineer there who works on the exhibits, Peter. Some potential question for him, or in general might be...

1.     What do kids seem most interested in?

2.     What do kids seem least interested in?

3.     What do kids understand very well?

4.     What aspect of the science (of any theme or item) is the least intuitive to kids?

5.     Do you hear any complaints/compliments about the hands-on exhibits?If so, what are these complaints and how can they be avoided?

6.   What makes an exhibit enticing to potential attendees? 

7.     What are kids allowed/not allowed to do in hands -on areas? I.E. What are the safety concerns when it comes to hands-on learning?

8.     What kinds of hands-on learning things are better for partners/large groups and what are better for just an individual?

9.     Even with exciting things, what can ‘bore’ kids and make them less interested? (What is the difference between hands on learning and teaching, where is the line, how involved should the instructor be?)

10. Do you have to consider the attention span of the viewer? IE they may want to do the hands on stuff, but not listen to instructions/educational stuff? They’re not bored, they just do not want to listen and prefer to dive right in. 

We know all the science, but maybe not all the people variables. After all you can take a

horse to water, but you cannot make it drink. The goal here is making the horse (or kids, or

adults, or anyone, really) want to drink.

The other thing we have to worry about is time. We only have so much of it and there are a

lot of things to see and do in the museum. So how do we narrow down our choices? After

carefully reviewing the list of current exhibits, I composed a small list based off which

exhibits were technology based and included hands-on aspects. I also kept an eye out for

any exhibits working with sensors.

The list goes thus...

  

1. Kinematics 
2. Computerplace (yes, spelled as one word)
3. Cosmic Light 
4. Innovative Engineers
5. Making Models
6. Nanotechnology
7. Take a Closer Look
8. To The Moon

All these exhibits integrate the perameters I layed out and i believe they will help us gain a

better understanding about hands-on learning and how it relates to our specific class. They

may also provide ideas for our final projects...

Speaking of which, below is a list (yes, another one) of the ideas I have generated so far.

1.) Mars Rover Retrieval! We could design our own miniature Mar's Rover to teach the kids about NASA deals with problems at distances. Just like in real life, we could pose a problem with the Rover on Mars (say, one wheel is stuck in a crevice), list all the sensors and movement possibilities available and let them try to determine a way to solve the problem. Essentially, play astronaut. We would have to have our own program that could un-stick the Rover. If we cannot solve the problem, we should not expect them to, after all.

NASA scientists working on Earth to solve a problem on Mars...

2.) Mars Rover Drop! Using the same Rover idea as above, we could simulate the drop the Rover underwent to actually get to Mars. We could, once again, list all teh sensors and movement possibilities available, pose a problem (safely getting the robot onto the ground, upright and undamaged) and let the learners figure it our on their own. Again, we should have  method of solving the problem. 

3.) Mars Rover Collection Process! Still Mars Rover...we could simply simulate one of the Rover's jobs: sample collection. We could have a variety of different coloered objects on teh floor, and the Rover has to retrieve only certain ones. It would incorporate multiple sensors to do this. We could state a directive (like get only the red legos), list all possible sensors and movement options and then let the lerners come up with their own ideas. 

4.)Mars Rover Mission(s)! Some combination of the above three options: plainly put, we could simulate an entire Mars Rover mission, or just certain aspects of it.  (see above for photos)

5.) Scuttling CrabBots! Design various legged robots (or wheeled ones) that incorporate different gear ratio and kinematic options. The object is to have the fastest little crab bot, so the learners would have to test various gear combination options to find the best one. Numerous options means they might want to learn a little about gears in order to minimize their search.

6.) Dance dance Robot Revolution! Using sound and ultrasonic sensors, we could build several bugs to follow each other, keep certain distances between them and react to sounds (like low beats in a song). The learners could program different responses and test them out to see the results. 

7.) Follow the Sound of My Voice! We could have a precise robot programmed with a variety of sound sensors on all sides. When the bot 'hears' certain sounds, like claps or shouts, it moves towards them or in some certain way. The trick is that the learners would have to understand the measurement of sounds and be able to define the parameters for each sensor. We would have to design an extremely accurate robot for this to work as well as it needs to.

8.)  Photosynthesis Simulation! We could build a model of flowers/grasses that respond to solar panels. The more sunlight they recieve, the more reaction the learners observe. This could teach the attendees about photosynthisis as well as solar power through visual aid. The learners could also engage in teh activity by changing gear ratios on the flowers to see how that would affect them.

9.) Once Upon a Gear Ratio! We could build a kinematic puppet show and have the learners interact with a story told by puppets mounted on sticks attached to various gear (they do not have to just be round). The way a puppet moves, its speed or the frequency of its appearance could be altered by changing the gears. The learners could learn about kinematics and gear ratios while simultaneously putting on a show for their own amusement.

10.) Type to Text! We could build a voice commanded typist. By programming very specific sounds to each key on the keyboard, we could have a robot interpret the sounds like battleship coordinates (or Cartesian plane coordinates) proceed to that spot on the keyboard and push downwards. The kids could learn about the measurement of sound as well as basics of computer programming and sound sensing. 

11.) Rainbow Connection! We could have a robot with a sensor that can differentiate between colors (either a light sensor or a brightness sensor) and the kids can program it t do different things depending on what color it encounters (spin, make cat noises, etc). Then, they could drive it over a multicolored surface ad observe the humorous results. 

 

I can't wait to find out what we do next!

 

SciBorgs Day Three and Four: The Puzzle of Proportional Feedback and Control...

After completing all of the tasks from days one and two, my partner and I were ready for new challenges. However, the next puzzles were almost identical to the ones we had already accomplished.

Almost...

We began to learn about Proportional Control.

Proportional Control is a response that measures the situation and then alters the programed maneuver to adequately adapt to the given situation. For example, if a woman is driving and car and begins to veer slightly into the wrong lane, she will simply turn the wheel a small fraction and the car will slowly adjust its alignment with the road. She would not violently jerk the car away from the opposite lane because now she is heading the wrong way again. Such a reaction would be dangerous and unnecessary. Instead, she would analyze the situation and decide how much of a response is needed.

That is what our bug had to do...determine how much a response was needed.


We started by trying to make it go ten feet.

The initial procedure was simple enough. We calculated the proportional control using error (how much our bug was off the mark by) and gain (a variable we could control)

P=(error)(gain)

We knew that ten feet was approximately 3060 rotations on countb. All we had to do was measure the error between ten feet and a 3060 countb run, calculate the gain and plug the variable into the motor power. We called this program proc (proportional control)

Once our bot was extremely close to the line, we added a small addition to our code called nudge. This helped the robot jerk forward slightly to bring it right to the line.

proc and nudge codes

One the lab floor, this process worked extremely well.

However, once we began to change the surface and incline, things became more complicated.

On the carpet in the hallway, we had to nudge twice in order to have the bug reach the ten foot mark. This was due to the excess friction caused by the
rug on the wheels. 

On the inclined plane, moving upwards, nudge had to be extremely adjusted. Even running at full power straight up was not enough to get the bug to the line. 

Moving down the inclined plane was another hassle. Even if we applied the breaks before the bug reached ten foot mark, the momentum it had built up caused it to slide until it hit the garbage can at the end of the plank. We adjusted nudge again, but this time the main difference was that we had it run in the opposite direction. Once the bug was a certain distance away from the line, the wheels began to run in reverse and succeeded in stopping it just before it flew over the line.

One of the early attempts. We Adjusted nudge to begin later so that the car would
be able to reach the blue line.

Each time, we were able to adjust our code to get the bug to be within 1cm of the desired distances, though some surfaces were more reliable than others. Going down the inclined plain is still a matter of luck. We could only fiddle with the nudge and gain variable. On the upward incline, we left the variable at 1 instead of 9/10 (which had worked on the floor) and it still could not reach, so we had to make nudge extremely powerful.

After we completed the fixed distances challenge, we moved onto the conga line. The goal of this challenge was to see if we could get the bug to follow something in front of it. It had to move forward when the object did, stop when it did and move backward if it did.

We started with a bang-bang version of the code before we implemented proportional control.

Conga Line Bang-Bang Code

Once our bug was able to make jerky stops and basically follow a Delrin board in front of it, we implemented proportional control. This addition to the code would help the bug start and stop more gradually instead of instantaneously by calculating the power supplied to the motors according to the distance between the bug and the object in front of it. If it was close, only a little power was needed. If it was far, the power could go up to one hundred.

Conga Line Proportional Control Code

It worked very nicely. Rather than jerking to sudden stops and stars, the bug approached the board quickly and then began to slow down the closer it got until it came to a gentle stop just before it. We could have balanced small objects on top of it and felt relatively confident that they would not be thrown off the by movement of the car,  but we were not ready in time to participate in the large group conga line due to a hardware malfunction. 

Finally, we began to work on the proportional control line follower. Everything we had learned up to this point had prepared us to make a line follower that could follow a white line, use only one sensor and run extremely straight.

We started simply by experimenting. 

We knew that the bug would have to use small amounts of power when it was very close to the line, but if it 'jumped the track' or made too wide a turn, it would need the full capacity of both its motors to bring it back around to the correct alignment with the line. 

Line Follower 2 Code 

Line Follower 1 Code

We experimented with two different types of code, the first set the power to each motor individually depending on the vale the brightness sensor detected. A vale above 400 had 250 subtracted from it and was divided by three. If the value was lower than 400, the it was subtracted from 650 and then divided by three. It took several attempts to get the right values to assure that the power could fluctuate between 70 and 100 for each motor. Line follower 2 was an attempt to set the power to each motor using one strand of code, but due to the massive differences in the read outs between the white tape and the dark floor, it would not work. One motor was always a little too fast while the other was two slow or did not move at all. Our gain variables were much smaller than the first challenge....about 1/3. Because the bug only had to be adjust by tiny increments, we fiddled more with the values the sensor value was subtracting/being subtracted from as these made smaller differences in the motor power output and made the bug very precise. 

Our little line follower worked exceptionally well, will noticeably less jerking and a much straighter path. Though the second code implemented the original bang-bang line follower code, it could not properly balance the power to each motor using only one line of code. Individual lines had to be constructed to accommodate the sensor value for each motor. Though this was more complicated, it worked far better. 

All of our final versions of our various code's can be seen below.

Final Fixed Distance Code with Nudge

Final Line Follower Code Using Proportional Control

Final Conga Line Code Using Proportional Control

If I could have changed one aspect of this exercise, I would have liked to have had less hardware problems. Our original bug had several issues and sometimes did not work or turn on altogether, even after a battery change. The frustration concerning the hardware detracted from the fun and excitement of the coding process. Then again, instant gratification and engineering never go together. 

Aside from this, the experiment was extremely fun and informative. 

Now that our little bug (Belle) has proportional control in it, I feel safer letting it drive around the lab. It doesn't crash into things (quite) as often as it used to.

SciBorgs Day Two: The Puzzle of Feedback and Control Continues...

The journey to understanding feedback and control continues...

For today's challenge, my partner Michelle and I had to make our SciBorg (Snow White) drive ten feet in a straight line. It sounded easy enough.

But it was WAY more difficult than we expected.

We started with a simple 'move forward' command.

Up a Little and to the Right...

Our particular bug had a tendency to bear right. If we were ever hoping to have a straight bug, then we would have to find a way to fix this. We decided to find out why this unexpected turning was happening. We needed to see what the difference was between motor a and motor b.

We achieved this by measuring the discrepancy between counts (at the moment an unspecific unit of measure). Over a distance of ten feet, countb measured 3056, while counta measured 2978.

The discrepancy between the two motors was approximately 78 counts when they were simply commanded to go forward at equal power levels.

After much guessing and checking, we finally managed to get the bug to go a full ten feet. We then measured the value of a count. The bug moved 3056 counts in ten feet. That's 305.6 counts per foot. Which is 25.47 counts per inch.

Although these measurements were accurate for this particular trial, we found that the discrepancy between the motors and the distance in counts covered in ten feet varied depending on where the bug ran, how fast it ran and how much friction there was between the wheels and ground. Certain areas of the floor were bumpier than others, and even though the lab floor provided the lowest friction possible for our bug, it still had an effect. Any skidding or slipping that occurred was reflected when we measured the discrepancy multiple times. If the discrepancy was smaller, slipping occurred, because more rotations happened. If the discrepancy was larger, skidding occurred because fewer rotations were counted.

We then wrote a program to try to account for these variables.

Go Ten Feet and Account for Count a and b Discrepancy

Entitled GoStraight, the program gave specific commands depending on where the car was and how large the discrepancy was between counta and countb. When the bug was one third of the way along the track, the power to motor b would drop to 99%. 

Mistakenly, however, we dropped the power on the wrong motor. After checking Snow White, we discovered that it was motor b, not motor a, that was running slower. We tried switching out the count to reflect this correction, but then the bug began turning left.

We needed a more complicated program that effectively accounted for the differences between motor a and motor b. 

Go Ten Feet and Account for Count a and b Discrepancy Version 2

We dropped the power to both motors to 90%, set the counts both at 0 initially, and had motor a drop to 89% one third of the way along the route. 

Better...Sort Of

Snow White definitely went straighter. However, it still had a tendency to veer slightly rightwards the farther away from the starting point it moved. 

Moving into the feedback portion of this challenge, we tried turning respective motors off whenever the counts were uneven to see if the car would continually correct itself along its path. 

The bug did continually correct itself, but along a rightward trajectory. Even turning only motor a off for a small interval of time could not correct this behavior. We returned to our original program, fiddled with the power allowed to each motor, but always our bug had a slight rightwards tendency when it traveled over long distances. We decided to see if sensors and more feedback could potentially fix this problem.

Because ten feet was placing us in the way of other working groups, we lowered our track distance to five feet and tried to see how close we could get the car to adhere to this distance. 

We started with the touch switch on the from of the bug. When the button could either read 999 (unpressed) or 0 (pressed), so it was a simple measuring device. Basically, it asked a yes or no question. 

Go Ten Feet and Stop When Touch is Pressed

Entitled gtfst (go ten feet stop touch), our program ran the previous course, but after a while, a sensor was activated, that when the button was pressed, would stop all power to the motors. 

The sensor worked. When the car came into contact with the bin, however, it moved slightly over the line. Because the car had momentum when it encountered the box, it could not immediately stop, so the box was moved a little. However, if the box had been a solid wall, the car may have bounced off it, or even sustained some damages as as result of the collision. Additionally, the button had to encounter the object dead on. Any turns or odd angles of contact might now have provided the proper force to activate it.

We moved on to the ultrasonic sensor. Entitled, gtfu, this program had the robot stop initially one hundred units from the box. After we were sure it worked properly, we lowered the distance to 1 unit, which should have placed the bug right on the line before the box. 

Go Ten Feet Stop with Ultrasonic

Even with the unexpected left arch, the bug was still a few inches away from the line. Because 1 was the lowest possible setting for the ultrasonic sensor, we could not rely on it to place our bug exactly on the line if the box was close to it. It could not effectively approach the wall. However, the bug did stop effectively, and without the requirement of contact with the wall to stop it, there was no risk of Snow White breaking. The lower the power was on the motors, the more precise the stop. Even though the bug did not have to hit the wall, it still had some momentum when the sensor tells it to stop and tended to jerk and then stop rather than stop immediately. In an annoying twist, we ended up having to tie our wires down more securely because whenever they fell in front of the ultrasonic sensor, the bug ground to a halt. Despite its setbacks, this sensor had potential to be useful for our program.

Finally, we tested the brightness sensor. We had to measure the difference between a light and dark color so that the brightness sensor could know what to 'look' for. We found that a dark color was in the 500s range while lighter colors, like white, were in the 300s. We set the middle ground as 400. If the sensor recognized anything above that, it let the motors run, Anything below 400 caused the motors to turn off.

A Nice Stop

Go Forward and Stop with Brightness Sensor

Go Forward and Stop with Brightness Sensor

The brightness sensor worked extremely well. So long as the sensor eventually ran over the line, it did not matter if the bug's path was perfectly straight. Additionally, the large discrepancy between the light and dark colors of the floor and line made it easy for the sensor to distinguish the two. However, if the power on the motors was set anywhere above 85, the bug ran the risk of overshooting the line. Even though the sensor would see it, and the bug would stop momentarily, the bug would be moving so fast the sensor would end up on the opposite side of the line, see the floor, and tell the bug to keep going. So long as the power was low, however, the brightness sensor worked well. It stopped right on the five foot line, whereas the touch sensor landed the car one inch over and the ultrasonic had it stop several inches too short. The brightness sensor worked the best by far. 

To get the bug to reach an exact distance of ten feet with minimal turning, we used both a touch and brightness sensor. Whenever we turned the bug on, the act of pressing the small white button put extra force on the right side wheel. In order to reduce friction and help with the turning problem, we instead activated our code by pushing the touch sensor. The bug moved forward and stopped when it found the line. We also incorporated our original code that changed the power settings to the motors after a set distance. We called this procedure sbb (straight bang bang).

Go Ten Feet Exactly and Stop

We then tested this procedure on a variety of different surfaces. It ran relatively straight on the lab floor, although by the time it reached ten feet it was still bearing a little bit to the left. On the carpet, it performed just as well, though the white line needed to be thicker to prevent the bug from overshooting.

It was the ramp that presented the most difficulties.

When it was traveling down the ramp, the bug had very little grip on the smooth wood and effectively slid the entire way down. It it could not stop itself when it saw the line (we changed the sensor settings so that when it saw a dark color the motors would turn off). 

Where are the brakes on this thing?!?

We were afraid at the speed it was going that if it hit the trashcan at the bottom it might break. It did make it all the way down the ramp without falling off, though.

Going up the ramp was even harder than going down it.

The rightward tendency was more pronounced going up the ramp than it was on any other surface. On every attempt the bug eventually tumbled over the right side of the ramp (we caught it each time, fortunately).

We Tried Again...

and Again...

and Again...

and Again...

...

...

...

...you get the picture

On one attempt, we managed to get our bug to traverse more than half the distance, but ultimately our procedure that worked on the ground could not work on the inclined plane. We tried using the brightness sensor to help the bug know when it was crossing over the edge, but the gap did not register correctly or consistently enough to work sufficiently. It is possible that the friction between the wheel was different depending on the side. Even with dramatic right turns and the power on motor a reduced to 75%, the bug still toppled over the edge. 

Finally, we attempted to make a line follower. Surprisingly, despite the procedure's more complicated program, it was actually easier to make. We used a simple if-then-else statement to activate the motors. When the brightness sensor registered a light color, one motor turned on and the other turned off. When it registered a dark color, the opposite happened. In addition, we also reduced the power on the motors to 80% so that the bug would not overshoot the line.

Bang Bang Line Follower

Needless to say, it worked extremely well. 

If we had more time, I would have liked to have fiddled more with the uphill procedure, as several other groups demonstrated that a successful procedure is possible. Aside from this, I was happy with our results, even if our little Snow White had a tendency to pull to the right. If we just lay tape down all over the floor, she can travel perfectly straight.