SciBorg-Proportional Control

Drive Straight  We've tried to  make our SciBorg drive straighter before, but this time we needed to use proportional control. That means the intensity of the correcting turn depends on how severely the SciBorg is veering from a straight path. We used the equation newspeed = 150  + k*error, where error is the difference between the two motor positions. We had to play around with different values of k to figure out what worked best. If k was too small, newspeed wouldn't be different enough from 150 to make a difference, and if it was too big, newspeed would quickly max out at 255. We settled on a value of k=0.5. A big problem we had was that our SciBorg was constantly making a hard turn. We added print statements to our code that displayed the time, error, and new speed each time through the loop. We then saw that newspeed was constantly 0, even though error was nonzero.We found out that if newspeed was a decimal number, trying to set the motor speed to newspeed would make it default to 0. Therefore we made newspeed an int. We also made sure to make k a float so that we could try out decimal and integer k values. Below is our code and videos of the SciBorg.

On Lab Floor

On Carpet

For comparison, here is the SciBorg going straight on carpet using bang-bang control.

After I watched the above video, I thought that bang-bang worked just as well or even better than proportional control, even though I expected proportional control to be more effective. Then I realized that the SciBorg in the bang-bang video is going much faster (I believe about 75-100 whatever-the-units-are faster). The slower the SciBorg goes, the more time it has for the differences between the motors to accumulate, and the more apparent it will be that it is not going straight. If the bang-bang and proportional SciBorgs were going the same speed, it'd be easier to tell which one was really going straighter. 

Stop After 10 Feet Our next task was to use proportional control to stop the SciBorg after 10 feet. The farther from the target it is, the faster it should travel to get there. We decided to use the motor encoder to measure 10 feet. We timed how long it took the SciBorg to travel 10 feet at speed 150 and then connected the SciBorg to the computer and noted the average encoder position after this amount of time. After writing and uploading our code, we were very perplexed when the SciBorg when so far past the 10 ft line. Then we realized that since our SciBorg was not going at a constant speed, it would take longer than our measured time to reach 10 ft. We decided we needed a encoder position based off distance instead of time (number of encoder readings (not sure of units)/rotation instead of readings/second). According to our understanding of motor encoders, the motor position after 1 rotation should not depend on speed. (Hopefully our logic is sound.) In order to do this, we ran both motors at speed 225 and measured how long 10 rotations took. We did 5 trials and then took the average time. We then edited our script so that the motors would stop after that amount of time and noted the final encoder position. We did 5 trials and took the average. We then divided by the number of rotations to get a value for the encoder reading/rotation. We got 702.8 readings/rotation for motor 2, 704.4 readings/rotation for motor 1, and 703.6 readings/rotation as an average. Then we divided 10 feet by the circumference of the wheel to find the number of rotations needed and multiplied this number by 703.6 to get 12,647 for the encoder position at 10 feet. This method worked pretty well, and our SciBorg didn't need a whole lot of nudging. Below, see our code and a video of our SciBorg in action.

 

As you can see, the SciBorg ended up only a couple inches from the finish line. 

Nudge  Let's see if we can get our SciBorg to the finish line by adding a small nudge to our code! Below is the last piece of our code with an added nudge function. Unfortunately, we couldn't get the function to work because we kept getting the error "nudge was not declared in this scope."

We had to add a nudge without using a function in order to get it to work. 

Here is a video of our SciBorg going 10 ft with the help of an added nudge. 

Ultrasonic Following With Proportional Control  Can we get our SciBorg to follow an object using proportional control, so that the farther away the object is, the faster the SciBorg goes? Yep, piece of cake! Here's our code and some videos.

Follow Meba

Like Ducks in a Row

Line Following with Proportional Control  The reason why this blog post is so late is that we slaved over our proportional control line following code and couldn't get it to work. I thought if we took some more time and got instructor help we would be able to get it, but I have decided to accept defeat. It's been over a week extra and I just don't want to think about it anymore. It seems like our SciBorg isn't listening to our code, because it's not responding at all to changes in light, let alone responding in the way we want. It only drives in circles. There must be some explanation for this behavior, but we just don't know what it is. **

**While commenting my broken code in order to post a picture, I think I found the problem. I will try out the new code tomorrow and update this blog post on whether or not it works. I decided to leave the above paragraph because it shows how close I was to giving up before I found the solution. :')

I believe the problem was that the last conditional used to be a while loop (while (error != 0)), which means that once a nonzero error was detected, the SciBorg was stuck in that while loop and was  not updating the speed. This explains why the SciBorg was traveling in circles. Now that it is an if statement, the speed should update, and it will hopefully work!