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.