3/1/11

After presenting our proportional line followers to the class, we continued learning about proportional controllers, this time with an added twist: derivative controls.  We learned that a derivative controller would let us get to our goal quickly, but without the oscillations that would usually accompany such speed.  It does this by incorporating the change in error into its equation (taking the old error and subtracting it from the new error), thereby reducing the error and making the oscillations smaller more quickly.  Today we also learned about open and closed loop systems--In an open loop system, feedback from a sensor has no effect on output, while in a closed loop system, there is a feedback system in place that affects the output.

We put our newly-learned information into practice with two small projects.  The first was to use a proportional controller and full closed loop system to create a hovering light sensor beam that would always hover at a certain, set distance from a white piece of paper on the table.  The idea was that, no matter how one manipulated the hover arm (pushing it up or down, or even moving the paper up or down) the arm would adjust itself and return to its set distance above the paper. 

We decided that a light value of 40 would be our goal hover-height, and wrote this program:

Our closed-loop proportional controller! (At this stage, without a derivative)

Movie:

If we had added a derivative, this would have become our new equation: m = Kp(40-l) + KdΔE



m = motor speed
Kp = gain of proportional controller
Kd = gain of derivative
l = light sensor value
ΔE = change in error

We would have had two gains to experiment with, instead of just one—the gain of the proportional controller and the gain of the derivative.  We didn't have time to add a derivative control to the hover arm before moving on, but we made our first one in the next mini-project!



Mini-Project number two brought us back to our line following robots.  Our challenge was to revamp our vehicles so that instead of following a line, they would be able to follow a small light on the robot in front of them.  Ideally, each robot would speed up if it was too far away, slow down to maintain a constant speed when it reached optimal following distance, and back up if it found itself too close to the light sensor in front of it.


We did not need to make many changes to our light arm program, but we did finally add a derivative!  We also changed the optimal light value from 40 to 30, our robot's light reading at what we determined was an appropriate distance from the car in front of it.

Initial program . . .

And with added derivative!

We updated our line follower so that the light sensor would be able to sense light in front of it, instead of from the ground, and added a small light on the back so that other cars would be able to follow it.

Revamped robot!

Rear view!

We took our robot outside for a trial run, and found that it had trouble following the lights on other robots.  We went back to our program and switched the LED aspect of our light sensor off, and that seemed to solve the problem!  This was our equation: KpE + KdΔE.  We found that with the added derivative controller, we could make the gain higher and our robot would reach its goal more quickly, but without as many oscillations!


Here are two movies our our robot in action:

 Follow the leader success! (Our robot is in the back)

And again:

Our robot (in the center) misbehaves slightly at the end of this clip (it got overwhelmed), but it successfully moved forward in a line of three!  In the first clip, it accelerated when it was too far away, maintained a constant speed at the optimal distance, and backed up when it was too close . . . success!

Class: 2/25/11 (cont'd)

Backtracking a wee bit to the beginning of class today:

Before attempting to make the line follower itself proportional, we completed a variety of mini-projects in class to introduce us to the idea of proportional controls, and the under, over, and critical damping that comes with them.

We learned that damping reduces the size of the oscillations that occur in a system.  Therefore, when a system is under-damped, it reaches its target with a velocity that is too high and experiences many large, overcompensating oscillations as the system keeps over-correcting itself as it tries to reach its target.  The higher the system’s gain, the more out of control and under-damped its oscillations will be.  When a system is over-damped, it decelerates too slowly, and therefore reaches its target too slowly, or not at all.  A critically damped system reaches its goal as efficiently as possible, decelerating appropriately, so that the system’s velocity when it reaches its goal will require few and small oscillations, if any.  We learned that fiddling with the gain affects how damped a system is, since it dictates how much the system will react to a certain change in error.

To learn about these principles, we made:

1. A 90 degree rotator

The goal of this mini-project was to have our motor rotate exactly 90 degrees, we found that a gain of 2 generally allowed this to happen.  With a higher gain, the system overshot with large oscillations, and with a lower gain the system undershot 90 degrees.

Rotating arm program: gain (2), optimal rotation (90)

In action:

2. Rotating control wheel

The goal of this mini-project was to create a system in which the motion of one motor was mirrored by the other.  In this case, changing the gain affected the speed with which the mirroring motor (gray Lego part) mimicked the movement of the original motor (wheel), and the oscillations it went through after its initial movement.

In action:

Line Follower: Day 2—2/25/11

After successfully presenting our line follower to the class, we moved on to phase two of the project: making it proportional.  This meant that our line follower would need to adjust its speed proportionally depending on how far it was from its goal of following the line.

After some explanation from Chris, we found that this could be accomplished by creating a relatively simple mathematical equation, and after learning how to add, subtract, and multiply on LabView, we set to work.

Instead of having two light values as we had in our original line follower equation, one for the tape and one for the floor, we took the average of the two and made it our optimal light value—i.e. if the LED sensor recorded this ideal value, our robot would be on the line,and would therefore start to follow the line more closely.  We originally found this optimal value to be 34.

Our first attempt at a proportional line follower: Optimal Light (34), Gain (1), Base motor speed (25)

Error: Distance of LED sensor’s reading from the ideal value (34)
Gain: Factor of multiplication—larger gain means the speed difference between the two motors will be proportionally larger as the error increases.  We started with a gain of 1, because we wanted to see how our robot moved without the added effect of the gain.

Our equation multiplied the error by the gain, and then added the resulting value to the base speed of one wheel while subtracting it from the base speed of the other wheel.  The end result of this equation is that, the larger the error, the greater the difference in speed of the two wheels will be, and therefore the bigger the robot’s sweeps will be.  This means that ideally, when the LED sensor reads the target value, the error would be zero and the robot would move in a straight line, since multiplying the error by the gain would result in zero difference between the speeds of the two motors.

The factors we needed to play with were the gain, the base power values for each gear, and the exact optimal light value.

We went through a lot of trial and error as we attempted to find the best combination of gain, base power, and optimal light value.  We found that a gain of 1 was over-damped (not enough sweeping occurred when the robot was not on the line), and that a gain of 4 was under-damped (the sweeps were too large).  Gains of both 2 and 3 worked, but we found that 3 was better because with that gain the robot more reliably made all of its turns.  We experimented with base speeds for the two motors, and found that 25 was too fast (missed turns due to delayed light readings), 15 unnecessarily slow, and 20 just right.  For light values, we found that 34 was too low (the robot barely reached the line before jumping quickly off of it), 36 too high (it took too long for the robot to start moving in the other direction when it did find the line), and 35 just right.

Gain of 1--Over-damped:

Gain of 4--Under-damped:

Final code for floor tapeline:

Gain (3), Optimal Light Value (35), Base motor speed (20)

In action:

 Although these seemed to be the best values we could find using our program and the line of tape on the floor, as you can see from the above movie, our proportional line follower had the potential to be much better.  Lyn suggested that we move from the floor to the table, since the white to black contrast of the electrical tape on the table was much more stark than the white to gray contrast of the masking tape on the floor.  We took his advice, and after some quick readings and trial and error, found our new optimal light value to be 39.  We played with the base speed, and found that 15 was too slow, 20 too fast, and 17 seemed just right.  We knew the gain needed to be smaller, since the error had become bigger due to the larger light value difference between the white table and the black tape, but some trial and error was needed to figure out the exact value.  .5 was over-damped, 1 was under-damped, and .8 seemed just right.

New and improved program:

Optimal light value (39), Gain (0.8), Base motor speed (17)

 In action:

We were very happy with our proportional line follower, and its much-improved ability to follow a line.  I feel like I learned a lot during this project.  One key point that I took from the project was about compromising and sacrifice.  We had to make many choices when programming our line follower, and these choices reflected the specific goals we had set for it.  It became clear that focusing on one feature could sacrifice another.  For example, creating a robot that follows lines very closely would also mean creating a robot that would not have the ability to successfully make sharper turns, and vice versa.  We had to strike a balance that we were happy with, and I feel that we did this with our final product.  Our robot follows the line closely, but not so closely that it cannot make relatively sharp turns--it easily made the required 45 degree turns, and could successfully make much larger turns (from the outside of the track).  Our robot did a good job of going straight when it found the line, and sweeping back and forth enough to make large turns.  To improve our robot, I might try to alter the program so it could function both on the inside and the outside of a line (at the moment it only functions on the outside, which was our initial objective).  Currently, it functions on the inside of the track, but cannot make many of the sharper turns.  I would also improve the way the small front wheel is attached to make it more stable, because every few runs it came loose and needed to be reattached.  One more improvement could be to try to reduce the amount of sweeping that occurs right before and right after a turn, but this change would probably reduce the size of the turns our robot is able to make.

Line Follower: Day 1 Continued

My partner and I met outside of class to fix up and figure out our line follower.  Since we now understood that we needed to create a sweeping motion, it did not take too long to get our code written and our robot tracking!

Our Final Program

We chose to write this code so that our robot would follow just one edge of the line of tape.  This meant that our robot changed direction as soon as its light sensor detected the near edge of the line of tape, as opposed to waiting to sense the floor again on the other side of the tape before switching directions.  We created the sweeping motion  by constantly alternating the powering and braking of the two motors.  As the picture of our program shows, each swap was spurred by the change in brightness brought on by switching from the tape to the floor, which we determined occurred between brightnesses of 33 and 34.  We also lowered the power of each motor to 25%.  These lower powers gave the LED sensor more time to read and process light values--when the power was too high, the light values didn't process in time, and our line follower often missed parts of the line.  Since our left wheel powered up first while the right wheel braked, one definite constraint of our line follower was that it needed to be placed on the left side of the line in order to track successfully.  As long as we started our line follower on the left side of the line, however, it did a great job of following the line--even successfully navigating relatively sharp angles!

Our successful line follower! Slightly slow, but definitely steady!

Line Follower: Day 1—2/22/11

Today we started our third project—building a line follower.  Our challenge was to create a robot that could, without any outside assistance, successfully follow a line of tape on the floor or a table using an LED light sensor.  We were to do this by creating an NXT robot with two motors, no more than two large wheels, a light sensor, and whatever other Lego parts we wanted, and then using LabView to write a program that would allow our creation to successfully follow the line.

After receiving our assignment, my partner and I headed over to the Lego table to begin building our physical model.  We attached a motor and one large wheel to either side of the NXT, one small wheel to the front for support and maneuverability, and attached the light sensor so that it protruded out in front of the rest of the vehicle.

Our first model

We decided to try to make our line follower follow a line of white masking tape on the gray floor, and brought this first model over in order to take preliminary light readings.  We quickly discovered various weaknesses in our design.  First, the light sensor itself was too far above the ground to take an accurate reading—the area the LED sensor covered was too large to be able to quickly and successfully distinguish between the light tape and the darker floor.  Second, the large wheels were positioned too far behind the vehicle, thereby making maneuvering less accurate and potentially creating a problematic center of gravity.

We took these factors into consideration and headed back to the Lego table.  With regards to our LED sensor, we wanted to make sure that it was as close to the ground as possible for an accurate reading, stable, and far enough forward that its readings would not be blocked by the rotation of the small wheel.

After much tinkering, here is the much-improved fruit of our labors:

Model #2

LED attachment close-up

After successfully building our model, it was time to move on to the real challenge—figuring out how to use LabView to make our creation intelligently follow a line.

Our first idea was to have one wheel perpetually going forward, and the other rotate forward or backward depending on the readings from the light sensor.  Our hope was that the adjustments of the light-dependent wheel would turn our follower as necessary in order for it to follow the line.  We took our creation to the line of tape on the floor to make light sensor readings, and discovered that the tape reading was about 37-40, and the floor readings were about 31-34.

Early Code

The idea of this code was that our robot would rotate until it found the line (light sensor reading of 38).  When this happened, both wheels would move forward, sending the robot in a straight line, until it found the floor (light sensor reading of 33) and began circling again to find the line.

This code has many problems. First, the circular motion in the beginning means that our robot will not be able to find the line unless it is within rotating distance (see movie).  Second, and more importantly, we had programmed our robot to simply go straight whenever it found a line.  This strategy would not work, because unless our robot happened to be angled exactly along the line, it would be sent in a straight line away from its goal line, since the LED sensor takes some time to process readings.  This factor, combined with our robot's inability to find a line more than a rotation away, was a recipe for line following disaster.

Watching our program's results and listening to Lyn's words of wisdom easily convinced us that we would need to spend time developing a robot that followed its line using a sweeping motion.  Doing so would give our robot much more calculated movements, and allow us to ensure that it moved in the correct direction.

Introduction to LabView—2/18/2011

After presenting our birds at the beginning of class (gearbird did a great job!), we had our first introduction to intelligent design! (Not the anti-evolution kind . . .)  Clara and I were partners again today, and we were first faced with the challenge of building an NXT robot that moves itself across the ground using two rotators, but no wheels.  This would be our first experience using LabView to write a program that would allow our robot to move by itself.  After watching the awesomely inspirational videos Chris showed to us, Clara and I set to work.  We walked over to the Lego table and quickly fell in love with the claw-like parts that we found there—we knew right away they must be part of our creation. We first connected our claws to just one rotator, and when we turned it on we were pleased and slightly terrified to watch the vigor with which the claws whipped around.  We quickly discovered our creation’s favorite food was cord, since it did not hesitate to wrap itself in any that happened to cross its path (although it certainly did not object to the occasional finger or arm).
In giving life to the claws, we had our very first experience with LabView, programming our little robot to move its rotators forward when we pushed a touch sensor once, and to stop when we pushed it again.  A very simple program, but it was still very exciting to see it work, especially since it was our first one!  We built our other claw and discovered that we had to change our program so that one rotator moved forward and one backward, so that the claws would move together and hopefully propel our creation in the correct direction.  We deemed our creation the Bucking Bronco.

Bucky

Stage one of building time was over, and it was time for a race! Bucky did not let us down—he pulled out ahead, kept his strong lead, and crossed the finish line first! We were very proud.

After the race we returned to our computer with the new goal to make our creations stop of their own accord when they reached the white finish line.  Clara and I at first wanted to use an LED light sensor to indicate the difference between the dark carpet and the light tape and send the stop signal accordingly, but before we got too far with our idea, Chris kindly informed us that Bucky, being what he was, would probably fling off the LED sensor, or at least make it very difficult to get an accurate reading.  We decided to switch tactics and switch our stop signal to a certain amount of time, since we knew the distance Bucky would have to travel.  We went out to the hallway to time a few of Bucky’s runs, but unfortunately his carefree movements did not lend themselves to being measured, since his time varied to an extreme degree each run we timed. (He was slightly off balance despite our stabilization attempts, and sometimes decided to veer off in random directions.)  We did our best to take an average of his time, and ended up with ten seconds.

When the trial began, Bucky ended up veering of course and therefore ten seconds ran up before he got to the line, so he stopped early.  On the bright side though, he came nowhere near knocking over the granny Lego person on the other side of the white finish line!

Here is our program—It uses forward, wait for touch, and stop commands, as well as a fore loop.  Each claw is controlled separately (one rotates forward, the other backward), and both stop after 10 seconds.

Here is a movie of Bucky's attempt to stop at the line:

Although our timed stopping attempt did not work with Bucky, after quite a bit of trial and error and attempting to figure out the functions of the plethora of Lego pieces of many shapes and sizes, I really feel like I learned a lot about LabView and am starting to understand the many things it is capable of doing.