SciBorgs: Day 1 -- Feedback and Control
Last week, my partner Tiffany and I began working with PicoBlock software. Having done some recreational and academic computer programming, I was pleasantly surprised to see how closely the system mirrored traditional program systems/vocabulary, e.g. If-then, If-then-else, etc. The "blocks" method was relatively easy to grasp,but it definitely challenged us at times: understanding Talk-to-abc versus Talk-to-b versus Talk-to-a; remembering to use forever to create a continuous loop of, for example, "print: counta;" or identifying the write sensor port for the right sensor system for data.
Part A: Basics
We began our exploration by creating basic commands for seven basic movement patterns: Forward, Backward, Brake, Spin-Right, Spin-Left, Bear-Right and Bear-Left. The first three programs? Plain and simple. The last four programs? Not so much. In those commands, we had to instruct the motors to do different things simultaneously. We finally figured out that the best approach was to give directions before they actually went forth to perform them, ensuring that the actions happen and begin together. For the Spin-Right and Sping-Left, my partner and I experimented with which motor to see what would cause the SciBorg to spin left or right. For Bear-Left and Bear-Right, (since we previously discovered which motor correlates with which direction) all we had to do was adjust the power of the motors. We tried out various power differences between the motors before we found the difference that would cause the SciBorg to bear in a direction instead of moving in a circle like Spin-R or Spin-L. In this case, we made a difference of 20 percent between the power in motors A and B.
Part B: Understanding Motors
In our original program, where the count is actually set to '1000' or '0,' the car consistently finishing 2 cm (CountB) to 4 cm (CountB) away from its initial spot, which is likely due to friction from the floor or the discrepancy in the power between the two motors. However, we really wanted to see if we could compensate for such a discrepancy and went a step further: my partner and I noticed that the reading of the count actually went past 1000 or 0 and then went to the next command. So, we thought that maybe signaling the bot actually before 1000 would help it reach closer to those 1000 spins and then reverse -- and the same for signaling at a greater number than 0 before it turned off..... It worked (particularly for CountB)! And the bot actually started and stopped in the exact location.
Overall, I am happy to getting closer to my field of interest (electrical and computer engineering). Next stop: Sensors. This isn't the first time I've worked with sensors, but I also don't expect it to be easy. Hopefully, I'll be able to use this language and others later on in our curriculum.
Part A: Basics
We began our exploration by creating basic commands for seven basic movement patterns: Forward, Backward, Brake, Spin-Right, Spin-Left, Bear-Right and Bear-Left. The first three programs? Plain and simple. The last four programs? Not so much. In those commands, we had to instruct the motors to do different things simultaneously. We finally figured out that the best approach was to give directions before they actually went forth to perform them, ensuring that the actions happen and begin together. For the Spin-Right and Sping-Left, my partner and I experimented with which motor to see what would cause the SciBorg to spin left or right. For Bear-Left and Bear-Right, (since we previously discovered which motor correlates with which direction) all we had to do was adjust the power of the motors. We tried out various power differences between the motors before we found the difference that would cause the SciBorg to bear in a direction instead of moving in a circle like Spin-R or Spin-L. In this case, we made a difference of 20 percent between the power in motors A and B.
Part B: Understanding Motors
After learning how to program basic commands, we moved on to the shaft encoder; the shaft encoders measure how many times the wheel for one motor (a or b) have been spun, which can translate into how far the bot has traveled. Two programs (See right) -- one for motor a and one for motor b -- tell the SciBorg as whole to drive forward until the shaft encoder of one of the motors measures 1000 and then drive backward until it measures 0 again. Theoretically speaking, it should start and end in the same place.
NOTE: After the count reaches 1000, we have instructed the motor waits for 200 ms (incorrect 2000 in this picture) before reversing, in order to prevent the RDS cricket board from crashing.
In our original program, where the count is actually set to '1000' or '0,' the car consistently finishing 2 cm (CountB) to 4 cm (CountB) away from its initial spot, which is likely due to friction from the floor or the discrepancy in the power between the two motors. However, we really wanted to see if we could compensate for such a discrepancy and went a step further: my partner and I noticed that the reading of the count actually went past 1000 or 0 and then went to the next command. So, we thought that maybe signaling the bot actually before 1000 would help it reach closer to those 1000 spins and then reverse -- and the same for signaling at a greater number than 0 before it turned off..... It worked (particularly for CountB)! And the bot actually started and stopped in the exact location.Overall, I am happy to getting closer to my field of interest (electrical and computer engineering). Next stop: Sensors. This isn't the first time I've worked with sensors, but I also don't expect it to be easy. Hopefully, I'll be able to use this language and others later on in our curriculum.
Comments
Post a Comment