SciBorgs Day One: The Puzzle of Feedback and Control

Today in class, we explored the mystery of feedback and control. There is a lot more to engineering than just visually seeing if a product works. Some products, like robots, use sensors and programs to interact with the environment and make decisions based on the data the sensors gather. Although today we only used a few sensors, like the touch and ultrasonic, other aspects of the robots, called SciBorgs in our case, can be minutely controlled, such as what motors turn when, how many times they turn, how much power each motor gets and so forth.

When it comes to feedback and control, we can get really specific with what we want our SciBorgs to do.

We Can Make a Light Flash and Change the Color!

Today, we started with the basics. For motion, we had to make our Borg move forward, backward, brake, spin-right, spin-left, bear right, and bear left.

To make it go forward , all we had to do was use the blocks talk to abc > move foreword for (10)

Backwards was [reverse > talk to abc > motor on for (10)]

Brakes were [talk to abc > motor on > chirp > motor off ]. We later changed this to [talk to abc > motor off]. The chirp and initial movement block were there so we could be sure it was the stop block that was making the movement end.

Spin right was [talk to a > this way > talk to b > that way > talk to abc > motor on for (10)]

Spin left was [talk to a > that way > talk to b > this way > talk to abc > motor on for (10)]

Bear right was [talk to a > set power (100) > talk to b > set power (90) > talk to abc > motor on for (10)]

Bear left was [talk to a > set power (90) > talk to b > set power (100) >talk to abc > motor on for (10)]

Experimenting with Code

Some of Our PicoBlocks Procedures

PicoBlocks Procedures

 Overall, our SciBorg worked very well in these initial tests and managed to complete all the tasks in an organized fashion. Next we moved on to shaft encoders. The encoders (thanks to lego) were built right into the motors. All we had to do was program them. Our challenge was to make the SciBorg go forward until counta reached 1000 and then to have it back up until counta was 0.

We coded [talk to abc > motor on > wait until counta = (1000) > motor off > wait (1) > talk to abc > reverse > motor on > wait until counta = (0) > talk to abc > motor off]

The wait (1) is a precautionary piece. If the SciBorg reverses direction too fast, it can cause the cricket board to fail. The lowest recommended wait time between direction reversals is .2 s, but we made it 1s, just to be safe. The Sciborg started and finished exactly where it began, going forward 1000 rotations, stopping, waiting, and then returning along the same path. The only discrepancy was that when it started, it had tendency to bear right. Fortunately, it maintained this tendency all along the path in both directions, so it did not alter the start and end points.

Countb Moving Forward Until It Reaches (1000)

 Next, we did the same procedure, but substituting countb in place of counta. There was not real noticeable difference between the two, except that when the SciBorg was running the countb version of the program, it traveled in a more straight line. Originally, we thought that an axle hanging out a little ways on the right side was the cause for the curved path, as it seemed to be rubbing up agains the right well, and therefore slowing it down. However, with the new program, the problem did not manifest. Maybe it is a problem with the counting inside of motor a, or perhaps the two shaft encoders are aligned differently. Aside from this, counta and countb were practically identical. 

Final Product of Code for Today