We realized while testing the Sciborg that it consistently turned left if both wheels were on full power. This was due to the fact that wheel B was turning anywhere between 70-90 counts more than wheel B. To address this problem, we identified that 1 counta was equal to about 0.125 inches. As such, in order to reach 10 feet, we used that measurement to determine that it would take 960 counta-s. However, that only took the Sciborg 38.5 inches perhaps due to friction. With this new measurement, we then calculated it would take 2992 counta-s but this carried the robot 4 inches too short of the goal. At this point, the Sciborg had been turning slightly to the left and could possibly be the reason why it was stopping short of its goal. We decided to switch to countb which yielded a slightly straighter line and add 68 counts to let the robot achieve its goal for a total of 3060 countb-s. In order to make the robot travel straighter as well, we programmed the power of wheel B to turn down to 99% after it had traveled about a third of the distance. This was to allow wheel A to catch up to the other wheel.
I predict that if the robot showed signs of it skidding, it would travel slightly farther than when it was programmed to stop. To address this issue, I would have lowered the total number of counts to take this additional distance into consideration. I could also turn down the power of the Sciborg in order to reduce the amount of skidding. Our robot most likely showed signs of slipping since the calculated number of counts had to be adjusted three times to reach our total of 10ft with each time being too short despite what the calculations stated. To address that problem, we simply recalculated how much we needed to reach 10 feet and increased the number of counts.
Touch feedback:
We replaced the last command of stopping after having reached 3060 of countb with a touch command that stated it should stop if the touch sensor touched anything (sensor 1 = 0). Unfortunately the robot was not able to stop immediately when it touched the bin. This was due to the fact that the robot's momentum carried it forward after it was programmed to stop. However, the touch sensor had to be fully pressed before the robot would register that it had to stop and thus, resulted in this unavoidable result.
Again, we swapped out the sensor 1 command for the next sensor and reduced its sensitivity to be less than 1, the lowest sensitivity possible for our program and robot. Although the robot stopped a few inches away from the bin, it did not achieve its goal of stopping over the white line. However, it did achieve its overarching goal of stopping before it reached a solid object.
Line follower:
Personally, this was my favorite. I believe it's the most accurate of the three sensors. We had to turn the power of the robot down because we found that if it was on 100% power, it would still register that it had read the white line and adjust accordingly once it did not read the white line anymore. However, because the robot was moving too fast, the momentum would carry it forward and the robot was unable to adjust in time. This resulted in it traveling over the line completely and setting it off into the brown cardboard attempting to find the white line it had just crossed over.
Drive Straight:
This task proved to surprisingly be the most difficult. We determined that our robot would travel 10 ft using a mixture of the touch and light sensors. To adjust for the fact that Wheel B turned more times than Wheel A, we attempted to adjust a number of things to try to fix the problem. At first we tried setting the power of wheel A such that it was only 1% more than wheel B. That unfortunately made the Sciborg turn too much to the right. Next we tried to set a number of if-then statements. We specified if either of the counts became unequal, the robot should turn the power down on the wheel that is turning too many times so that the other wheel can catch up. The result was a robot that traveled 10 feet continued to veer slightly to the right. Throughout testing the robot, we realized that pushing the white button on the right side of the robot added a slight amount of friction to it and may have caused an initial turning point. Thus, we programmed it such that the touch sensor had to be activated first before the robot would move.
We tested this program on the lab floor, the carpet, and on the ramp. The robot continued to veer slightly to the right when it was on the floor. However, it continued to travel a distance of 10 feet. On the carpet, the robot traveled in a much straighter line but slower as well. It did achieve its final distance of 10 feet as well.
We encountered the most problems on the ramp. Because the robot had an affinity for turning slightly to the right, it was unable to make it up the 10ft ramp. We more often than not got it to travel about 3-5 feet before it fell off. We attempted to take this into account by programming the robot to turn off the wheel that was traveling too far so it would turn back to the other side. However, this was largely unsuccessful as well.
Traveling down the ramp increased the momentum of the robot which resulted in it moving at a much faster speed than what it was programmed to do. It essentially rolled down the plank and was barely able to react to the wheel counts because the robot was moving so quickly. As a result, when it reached the bottom of the plank, it was unable to read the line in time and could not stop in time. However, it did travel much straighter than when it was attempting to go up the plank and achieved its goal of 10 feet.
It would have been nice to have more time to perfect the robot so that it traveled straighter up the ramp. But in the end, testing out varying sensors and programming the robot to follow commands was an exciting experience. I was humored by the fact that I had to use my computer science skills to finish this lab but I thoroughly enjoyed finding a cross section between computer science and engineering since I find both so interesting.




I also really enjoyed the overlap between engineering and computer science. Our team had the same issue with the ramp, as it would curve significantly going up and skid a lot going down. Also, it seems everyone discovered the "trick" for the line following program -- and I'm interested in seeing how you'll do proportional control.
ReplyDeleteI liked how you tried out your fixed distance program with using multiple sensors. That was a good way to explore the program and get extra practice! My partner and I also had the problem on the white line following where our SciBorg was going too fast to recognize the line. We solved this by making the powers of the motors extremely low, but then the SciBorg would frequently get stuck. Good job with all your programs!
ReplyDeleteAlso, if you want to take a screenshot on a Mac, you can press command shift 4 all at once and then draw a box around the part of the screen that you want to take a picture of. Then the image is automatically saved to the desktop. Just in case you want to take screenshots instead of photos :) Either way works though!